OPENTIA, OpenERP Partner España

OpenERP, OpenERP España, gestión empresarial, Nuxeo, Gestión Documental, interoperabilidad y software libre

 

Histórico de cambios

Fecha

Cambio

2012-10-18

Versión inicial

2012-10-19

Primeros ajustes y correcciones según el feedback de la comunidad.
Mención al motor de informes basado en BIRT, tal como lo indicó Christophe Chauvet.

2012-11-09

Versión española por OPENTIA (manteniendo enlaces originales, en su mayoría a páginas en francés)

Sobre el autor

El autor y el software libre

Soy un apasionado del software libre. Hice cursos sobre VideoLAN cuando era estudiante, donde principalmente me ocupé de la documentación, del sitio web, de la organización de eventos y de la puesta en producción de VideoLAN en el campus de mi escuela. Como entonces no tenía experiencia en programación, no codifiqué mucho (excepto por el soporte de IGMPv3 y de MLDv2 en VLC). VideoLAN me ha permitido "vivir" un software libre desde adentro y me ha enseñado muchísimo sobre la filosofía del mismo, la motivación de los desarrolladores y el funcionamiento de las comunidades.

Soy autor o co-autor de otros dos documentos sobre software libre:

Mi interés, hoy, es la utilización de software libre en las empresas. Ya he dado testimonio varias veces de esto con una presentación llamada Une PME en logiciel libre de A à Z? (¿Una PYME con software libre de la A a la Z?).

También soy tesorero de la asociación Asterisk-France, cuyo objeto es la promoción de Asterisk en Francia y los países francoparlantes.

La experiencia con OpenERP del autor

Soy co-fundador de Anevia, empresa de equipamiento de telecomunicaciones francesa especializada en servidores de video sobre IP. La fundé en 2003 con tres compañeros de la escuela, "ex-alumnos" del proyecto VideoLAN como yo. En Anevia tenía la resposabilidad administrativa (contabilidad, nómina, declaraciones), de producción y logística, y de la informática interna (aunque, al principio, dado que estos dominios no me consumían todo mi tiempo, también me desempeñé como ingeniero comercial y de soporte).

En los comienzos, para ayudarnos, adopté herramientas de gestión básicas y simples:

  • Ciel Compta para la contabilidad (software mono-usuario para Windows, que se puede comprar en Fnac por 200 €),

  • Hojas de cálculo OpenOffice múltiples y variadas para la administración de ventas, facturación a clientes, producción de equipos, gestión de envíos, etc. en un entorno Samba,

     

  • que es una base de contactos cliente/proveedor desarrollada internamente con PHP/MySQL.

Quiero hacer notar que Anevia siempre llevó internamente su contabilidad.

Estas herramientas simples y de bajo coste eran las correctas para una empresa que empezaba. Pero, a medida que fuimos creciendo y tuvimos más empleados, éstas mostraron sus límites:

  • Mucha duplicación de datos y mucho re-ingreso de información, con el consiguiente riesgo de error. Por ejemplo, la dirección de un cliente estaba repetida en al menos 4 lugares: ¡En la base de contactos, en las propuestas OpenOffice, en los remitos de OpenOffice y en las facturas de OpenOffice! Peor aún, el total de una venta era ingresado 4 veces: Una vez en la propuesta, otra en la factura, otra en la hoja de cálculo que aunaba las facturas a los clientes y una última vez en la contabilidad de Ciel Compta !

  • Temas de gestión de concurrencia. Por ejemplo, nuestra hoja de cálculos OpenOffice de envíos de producción y atención al cliente era utilizada por ambos responsables de la administración de ventas y técnico de logística. Cuando uno tenía el documento abierto en su ordenador, el otro tenía sólo acceso de lectura, con lo que tenía que llamar por teléfono para pedir que el otro lo cerrase ¡para así poder hacer modificaciones! Otro ejemplo: Ciel Compta era un software de usuario único: desde mi puesto de trabajo yo no podía ver los asientos contables que había hecho el contable. ¡No era fácil trabajar de a dos en estas condiciones!

Ante esta situación, se hizo urgente cambiar nuestras herramientas... Hacía falta un ERP.

Desde que me hice fan del software libre, me interesé por los ERP libres. He leído artículos en Internet, hablé en eventos, etc. En ese momento, en 2007, los ERP de software libre de los que se hablaba eran:

Compière era el más visible a todo nivel en los medios de comunicación y contaba con una importante comunidad de experimentados integradores franceses por lo que estaba mostrando referencias sólidas. Por consiguiente, era un buen candidato. El gran inconveniente era el hecho de que Compière usaba una base de datos Oracle, que era muy sorprendente para un software de código abierto ya que entonces ya había una amplia gama de bases de datos de código abierto, algunas de las cuales tenían muy buena reputación en cuanto a fiabilidad y rendimiento y referencias de prestigio. Con Compiere, sentimos que ¡"El Software libre es bueno, pero el software privativo es mejor" !

En esa época, OpenERP todavía se llamaba TinyERP. Su mensaje no era muy contundente, no tenía un integrador francés de fuste y sólo estaba disponible usando la interfaz GTK, que no era súper sexy para demos. Había leído que TinyERP había sido escrito en Python, lo cual me llamaba la atención porque pensaba que Python era un lenguaje de script (Python se suele utilizar para escribir scripts, pero yo no sabía en ese momento que también podría ser adecuado para aplicaciones completas). En cualquier caso, yo no me veía convenciendo a mis compañeros para elegir TinyERP, un software Tiny-empresas, ¡cuando teníamos la ambición de construir una PYME que no fuera pequeña toda la vida!

Mi preferencia era OpenBravo, que tenía un mensaje más claro, un método "full-web" seductor que permitía hacer demostraciones muy llamativas. OpenBravo era un desprendimiento de Compière, donde se había abandonado el cliente Java en favor de uno "full-web" y se estaba a punto de añadir soporte oficial para PostgreSQL, además de Oracle. OpenBravo mostraba metas ambiciosas importantes y su editor estaba cerca, porque se basa en España. OpenBravo no tenía aún integrador francés, pero la compañía parecía muy activa. Decidí matricularme en una semana de entrenamiento funcional, organizado por la editorial de OpenBravo en Barcelona en marzo de 2008.

Después de ese entrenamiento, ​​llegué a la conclusión que Openbravo probablemente no era una buena opción para Anevia. Aclaración: Mi opinión sobre OpenBravo data de marzo de 2008 y está ciertamente anticuada. Igualmente deseo compartirla con ustedes para que puedan entender mi elección:

  • Las fortalezas de OpenBravo eran:
    • Un verdadero entorno de software libre, lo que marcaba una diferencia real con Compière. El editor estaba haciendo regularmente comunicados públicos, el proceso de desarrollo estaba abierto (bug tracker público, propuestas públicas, reuniones IRC, hoja de ruta (roadmap) pública disponible en el wiki, lo mismo que la documentación). Las traducciones en diferentes idiomas y sistemas contables para diferentes países también estaban disponibles bajo una licencia libre (que no era el caso de Compière).
    • La comunidad parecía dinámica a primera vista y el editor se aseguraba de mantener buenas relaciones con la misma.

    • La elección de la interfaz "full-web", fue visionaria para su época (ni Compière ni OpenERP tenían una interfaz web en ese momento).

    • Las opciones técnicas propuestas por el editor (Java y PostgreSQL) me parecían buenas entonces (más tarde me enteré por Raphael Valyi que el código "central" de Openbravo se componía principalmente de procedimientos almacenados escritos en PL/SQL, y que Java que se ha utilizado poco).

    • Proximidad geográfica (Barcelona).

    • Planes ambiciosos de desarrollo y un equipo simpático.

  • Desafortunadamente, durante esa semana de entrenamiento, pude percatarme de una serie de deficiencias:

    • El software estaba mucho menos maduro de lo que pensaba: varios bugs fueron corregidos durante el entrenamiento, ¡que fue especialmente impactante para mí!

    • El alcance funcional me decepcionó. No había CRM (se estaba considerando el desarrollo de un conector con SugarCRM, pero todavía ese desarrollo no había comenzado), no había noción de agenda o calendario, no era posible obtener un balance analítico que mostrase tanto el plan de cuentas analítico y el plan general de contabilidad (cosa muy básica que todo software de contabilidad, incluso Ciel Compta).

    • Algunas de las características más básicas estaban ausentes. Por ejemplo, no había un campo donde asentar el idioma nativo del cliente, a fin de precisar si los documentos para este cliente (presupuesto, albarán, factura) deben ser emitidos en francés, inglés o castellano... o en el idioma que fuese Esto era obviamente una funcionalidad muy básica requerida por Anevia. Le pregunté al entrenador sobre ello y me dijo que se trataba de un pequeño desarrollo específico no muy complicado. Pero mi entendimiento era que, si se empezaba a financiar desarrollos específicos para funciones tan básicas, entonces no tendríamos presupuesto para desarrollar las características específicas del trabajo de Anevia, como la gestión de contratos de mantenimiento.

    • Sentí que OpenBravo era una máquina grande que no sería fácil de dominar. Ver la lucha del instructor durante media hora con Tomcat durante la primera mañana de la formación no fue de lo mejor... mi ignorancia del entorno Java hizo el resto.

    • OpenBravo todavía no tenía ninguna referencia en Francia y por lo tanto no tenía integrador francés que ya hubiese completado una implementación.

Después de esta experiencia decepcionante con OpenBravo, me dije que si consideraba que los ERP libres que yo estaba analizando para satisfacer las necesidades de Anevia no estaban a la altura, entonces tendría que analizar ERPs privativos.

Me puse en contacto con algunos de esos ERPs para las PYMEs, como Sage, Cegid o Divalto. En este estudio muy breve, me di cuenta de lo difícil (¿imposible?) que era encontrar un ERP privativo para una estación de trabajo Linux. Sabiendo que en Anevia dos terceras partes de los puestos de trabajo eran Linux -empezando por la mía- esto era, obviamente, un criterio de selección. Todos ofrecían pesados clientes Windows. Divalto contaba con una interfaz web, pero sólo para el CRM. Cegid proponía una interfaz web sólo compatible con Internet Explorer... y cuando traté de acceder al sitio demo que hace la presentación, lo primero que me propuso es descargar un plugin... ¡como un archivo exe! Cuando les consulté sobre la cuestión del acceso al ERP desde una estación de trabajo Linux, su respuesta era siempre la misma: no hay problema, ¡sólo tiene que instalar un servidor Citrix! ¡Bienvenidos al reino de la liviandad! Por no mencionar el costo...

Mi revisión rápida de los ERPs también me hizo descubrir algo importante. En el caso Divalto, un integrador especializado había desarrollado un módulo para administrar los contratos de mantenimiento. Este módulo era propiedad del integrador y no del editor, por lo que era desarrollado, mantenido y comercializado por el integrador. Esto tenía dos consecuencias:

  • Anevia ¡no tenía opción de integrador! Por lo tanto, la competencia entre integradores de Divalto...

  • Anevia tendría con su tecnología ERP una doble dependencia, tanto con el editor como con el integrador. Si bien depender del editor del ERP privativo parece normal, yo no esperaba ser tecnológicamente dependiente TAMBIEN del integrador, que era una pequeña empresa francesa de una docena de personas sobre la que no sabía nada.

Me di cuenta más tarde de que esta práctica era común en el mundo de los ERP cerrados, donde los integradores desarrollan negocios verticales (privativos también) para asumir un cuasi-monopolio de la implementación del ERP en cuestión en ese sector y asegurar la fidelidad obligatoria a sus clientes.

A mediados de 2008 conocí a Raphael Valyi, quien en ese momento trabajaba en Smile y que acababa de terminar de escribir el Libro Blanco Smile sobre ERP libres. Como parte de su misión de observación de la tecnología, pasó varios meses evaluando muchos ERP libres disponibles, y se tomó el tiempo para instalar, mirar el código fuente, evaluar el alcance funcional, etc .. . Su conclusión fue clara: OpenERP (que había cambiado su nombre abandonando el antiguo TinyERP) era el mejor. Me di cuenta de que Python no era un lenguaje de scripting simple, sino un verdadero lenguaje de desarrollo orientado a objetos. El editor acababa de publicar un libro para aprender a utilizar OpenERP. ¡Fue el primer libro sobre un ERP libre! A pesar de que puede parecer anecdótico, siempre pensé que esto era importante, ya que puede reducir significativamente la barrera de entrada para alguien que quiere descubrir el software: en lugar de pagar 2500€ por una semana de entrenamiento, ¡ahora podría pedir el libro en Amazon a 40 €! Al reducir la barrera de entrada al software, el editor estaba dispuesto a ampliar significativamente la distribución del software, por lo que se aseguraba una comunidad más grande, que es un criterio muy importante para el éxito de un software libre.

Raphael Valyi me explicó las cualidades de OpenERP. Él fue capaz de mostrarme a través de una demostración de que las características cuya ausencia me habían sorprendido en OpenBravo estaban incorporadas en forma nativa en OpenERP: cruce del balance analítico con el plan general de contabilidad, tenía un control integrado del idioma en los archivos de cliente para la edición de documentos (presupuestos, albaranes, facturas), tenía un CRM nativo, etc. Raphael tenía un conocimiento técnico muy fuerte y no era un comercial diciendo mentiras para vender su chatarra. Cuando me dijo que, teniendo en cuenta las necesidades de Anevia, era posible implementar con éxito OpenERP, le tuve confianza.

Pude convencer a mis compañeros para hacer la elección para OpenERP para Anevia y la decisión fue tomada oficialmente el 10 de octubre de 2008. El trabajo se inició en torno al 20 octubre de 2008. Entre los módulos específicos para desarrollar había un módulo de gestión de contratos de mantenimiento. Teniendo en cuenta el ambicioso cronograma de paso a producción habíamos dejado abierta la posibilidad de desarrollar este módulo después de entrar en productivo. Dado que Raphael era un desarrollador con experiencia y el marco de OpenERP permitía desarrollar muy eficientemente, el módulo de gestión de los contratos de mantenimiento se pudo desarrollar antes de entrar en producción. La entrada en productivo tuvo lugar el 1 de enero de 2009 con OpenERP 5.0, que todavía estaba en beta (OpenERP v5.0 fue liberado el 8 de febrero de 2009) con el siguiente alcance:

  • Gestión de inventarios (inicializados con el stock de fin de año)

  • Administración de Ventas

  • Contabilidad

El proyecto despegó... Formé mi equipo en el trabajo y la organización se adecuó con ese fin. Como yo era personalmente responsable de la contabilidad, administración de ventas y producción / logística en Anevia, las cosas eran más fáciles porque personalmente era el encargado de todas las personas afectadas por el lanzamiento del ERP. Sabía perfectamente cómo trabajaban y era yo el que había desarrollado sus métodos y procesos (¡y también era yo su reemplazo cuando estaban ausentes!).

El arranque en producción de OpenERP en Anevia generó un artículo en el sitio erp-infos.com .

Después de este exitoso comienzo, hemos seguido ampliando el alcance funcional de OpenERP para Anevia. Entre el pasaje a la producción el 1 de enero de 2009 y hoy, hemos añadido:

  • Emisión de presupuestos,

  • Gestión de RMA,

  • Importación automática (me refiero a "no volver a entrar") de los asientos de nómina,

  • Gestión de préstamos de equipos a clientes,

  • Gestión de notas de gastos,

  • Establecimiento de DEB (Declaración de Bienes de Cambio) y DES (Declaración Europea de Servicios),

  • Importación automática de datos de Coface, que es la aseguradora de crédito de Anevia,

  • Gestión de las solicitudes de licencia para los empleados con sede fuera de Francia,

  • Conexión con Pentaho para Inteligencia de Negocio (Business Intelligence),

  • Conexión con Asterisk (software de código abierto para PBX IP) la funcionalidad de plug Click2Dial

  • En curso de implementación: conexión a PrestaShop para dar a los clientes la capacidad de ordenar en línea.

Dejé mi trabajo en Anevia funcional a principios de 2010. Raphael Valyi había dejado Smile a mediados de 2009 y había puesto en marcha su empresa Akretion en Brasil, con el objetivo de convertirse en integrador OpenERP y el lanzamiento del software en el mercado brasileño. Raphael rápidamente me propuso crear el hermano gemelo de su empresa en Francia. Con Sébastien Beau, que estaba de vuelta en Francia después de su estudio de prácticas en Akretion Brasil, me formé en el desarrollo de Python en el marco de OpenERP y comenzamos a desarrollar la actividad en Akretion Francia.

O sea que, desde finales de 2010, me he convertido en integrador OpenERP.

Esta sección de mi historia personal con OpenERP es un poco larga y muy egocéntrica, pero me pareció que era importante hacerla porque, como os presento mi visión personal sobre OpenERP en este documento, los lectores deben tener la información necesaria para poner en perspectiva mi opinión.

Las contribuciones del autor a OpenERP

Mi contribución a OpenERP ha sido principalmente mediante desarrollo de módulos para la comunidad. He desarrollado:

  • el conector OpenERP-Asterisk , ¡que es el primer módulo que he desarrollado en OpenERP!

  • Pleno apoyo de la Declaración de Intercambio de Bienes (DEB) y la Declaración Europea de Servicios (DES), que son obligatorios para las declaraciones aduaneras (véase este enlace )

  • El soporte a las transferencias de crédito SEPA en OpenERP

  • Una serie de módulos para agregar un nivel de acceso Viewer (Visor) de OpenERP, que da acceso de sólo lectura a las diversas áreas funcionales

  • Pequeños módulos especializados, en su mayoría destinadas a mejorar el uso de la contabilidad de OpenERP: módulo account_analytic_required, el módulo account_reversal, el módulo sale_partner_bank, el módulo account_move_csv_import, el módulo currency_rate_date_check , etc.

  • También participé en muchos módulos de la comunidad: el conector OpenERP, PrestaShop , el módulo product_serial, el módulo fleet_maintenance, el módulo product_variant_multi, etc.

También aprovecho el tiempo para hacer mejoras en los módulos de OpenERP oficial, mantenidos por el editor. Aquí están mis principales contribuciones en forma de propuestas de fusión :

  • Localización francesa mejorada de OpenERP (en equipo con Frédéric Clementi de Camptocamp): 1 ª ronda y ronda 2 ,

  • Agregado de la opción de elegir el procedimiento de redondeo en los impuestos OpenERP (el redondeado de la suma vs la suma de los redondeos)

  • Mejoras en el código para que sea fácilmente extensible para generación de facturas, manteniendo el buen desempeño: la introducción de funciones _prepare_invoice* , consulte la fusión y un presente .

  • la adición de un código analítico sobre las líneas de impuestos en las facturas,

  • y muchas otras mejoras pequeñas: la capacidad para mostrar la moneda de la cuenta bancaria (combinación 1 , 2 y 3 ) la capacidad para definir tanto los datos bancarios a la vez en formato RIB e IBAN (véase la fusión ), limpieza de código para permitir una mejor gestión de variantes, etc...

Por último, trato de participar tanto como puedo en los informes de fallos (bug reports), ofreciendo parches para corregirlos cuando están a mi nivel

Sobre OpenERP

Corta historia de OpenERP

Fabien Pinckaers comenzó TinyERP (el antiguo nombre de OpenERP) en 2001-2002, cuando todavía era un estudiante en la Universidad de Louvain-la-Neuve. Creó la empresa Tiny SPRL para comercializar sus servicios en el entorno de TinyERP.

El lanzamiento público de TinyERP fue en 2004, y las sucesivas versiones fueron a un ritmo acelerado:

  • la primera versión fue publicada el 6 de julio de 2004 bajo licencia GPL, el anuncio indica que el software ya se utilizaba en producción en tres empresas belgas.

  • La versión 2.0 es liberada el 25 de marzo de 2005 con mejoras funcionales y la simplificación del procedimiento de instalación,

  • La versión 3.0 se libera el 2 de septiembre de 2005 con la adición de un módulo de gestión de producción (MRP) y una mejora en la gestión de datos multilingües,

  • La versión 3.1 (15 de octubre de 2005), incluye la posibilidad de diseñar informes (presupuestos, facturas, albaranes) con OpenOffice y la posibilidad de heredar los objetos nativos de Python,

  • La versión 3.2 (29 de enero de 2006) cuenta con un módulo de contabilidad completamente reescrito para soportar la contabilidad general y analítica,

  • La versión 3.3 (4 de mayo de 2006) con más versiones localizadas, gestión multi-empresas y un cliente GTK completamente renovado,

  • La versión 3.4.1 (19 de septiembre de 2006) con un manual gratis para los usuarios, cuando el anterior era sólo de pago.

  • La versión 4.1 (13 de junio de 2007) con una primera versión de interfaz web llamada eTiny ,

  • La versión 4.2 (octubre de 2007 - si alguien puede encontrar un anuncio oficial hecho por el editor, me interesa)

En el período 2005-2006 llegan los primeros integradores, incluyendo Camptocamp que empiezan a trabajar en la localización de TinyERP, que consiste en la adaptación del ERP específico para las especificaciones jurídicas, contables y fiscales de cada país.

Bajo la presión de sus integradores, TinyERP adopta la plataforma Launchpad en 2008 para facilitar el desarrollo de la comunidad OpenERP. En junio de 2008, TinyERP cambia de nombre para convertirse en OpenERP y publica su primer libro con la editorial Eyrolles. El año 2008 también estuvo marcado por el lanzamiento de Tryton , una escisión de OpenERP, iniciada por dos ex empleados de Tiny SPRL, que sigue estando activa en la actualidad, y sigue creciendo independientemente con desarrollos colaterales de OpenERP. La motivación de esta escisión parece ser la necesidad de dar prioridad a la limpieza del código funcional en lugar de dispersar característica "bling-bling" tipo "tenemos un Webmail con OpenERP" (verdad, consulte el anuncio de la versión 5.0 ). Otra prioridad era trabajar en la mejora del framework mediante la corrección de sus defectos principales en desmedro de un cambio en la API que necesitaba un ajuste mayor en los módulos funcionales. Claro que también había una causa humana, debido a los desacuerdos entre el jefe y los dos desarrolladores TinyERP en cuestión.

En febrero de 2009, la liberación de OpenERP versión 5.0 marca un salto importante con la interfaz web mejorada, la introducción de los diagramas de Gantt y el editor de flujo de trabajo y muchas mejoras en el código funcional.

A principios de 2010, la compañía Tiny SPRL, que más tarde se convirtió en OpenERP SA, anuncia la suscripción de 3 millones de euros por parte de Sofinnova (una empresa francesa de capital de riesgo), Xavier Niel (fundador de Free) y Olivier Rosenfeld (miembro del Consejo de Administración de Iliad). Hasta entonces, la compañía se había financiado con recursos propios sin que fuera necesario accionista externo alguno. Incluso después de este aporte de fondos, Fabien Pinckaers sigue siendo el accionista mayoritario de OpenERP SA. Antony Lesuisse, que había ayudado a Fabien, y había continuado su carrera en otras empresas, vuelve a OpenERP SA incorporándose como Director de I+D. Bajo su liderazgo, el desarrollo de OpenERP se profesionaliza y marca el final de una tendencia desafortunada para OpenERP de desarrollar algunos componentes de software como propios en lugar de adoptar los componentes de software existentes bajo una licencia libre.

En enero de 2011, la liberación de OpenERP 6.0 marca un nuevo salto cualitativo importante con mejoras en el código funcional, la reescritura del CRM y la mejora de la interfaz web. Esta versión es la primera en ser liberada bajo licencia AGPL , en reemplazo de la licencia GPL.

En febrero de 2012, la liberación de OpenERP versión 6.1 presenta una nueva interfaz web, reescrita desde cero bajo la dirección de Antony Lesuisse. Se utilizan modernas tecnologías web usando bibliotecas libres establecidas y maduras, generando un rendimiento tal que se vuelve tan rápido como el del cliente GTK.

Los desarrolladores están trabajando actualmente en la elaboración de OpenERP versión 7.0. La principal innovación técnica es la introducción de una nueva API para el desarrollo de módulos (pero podría pasar a la versión 7.1). Esta nueva API promete corregir las limitaciones y deficiencias de la API actual, (la cual tendrá el soporte con que cuenta hoy, sin embargo). OpenERP versión 7.0 también introducirá muchas mejoras en cuanto a ergonomía y facilidad de uso.

Tryton, la escisión de OpenERP, continúa su desarrollo por su lado y se prepara para cambiar a Python 3 . He hablado con los principales desarrolladores Tryton durante PyconFR 2012 , la reunión anual de la comunidad de Python francoparlante. Les pregunté cuáles eran las principales fortalezas de Tryton en comparación con OpenERP (no les he preguntado cuáles eran sus debilidades... ¡hubieran sido menos objetivos!), Aquí van sus respuestas:

  • Un mejor framework. Tryton ya ha corregido muchas de las principales deficiencias del framework de OpenERP aunque admite que Tryton aún no ofrece una interfaz web (se está desarrollando). OpenERP se compromete a ponerse al día con la nueva API proporcionado en la futura versión 7.0 ó 7.1.

  • un código "limpio" en los módulos funcionales. Tryton cuenta con una cobertura funcional menor que la de OpenERP (no hay gestión de informes de gastos, por ejemplo), pero se ha hecho un gran esfuerzo para simplificar el código estándar de módulos funcionales de Tryton .

  • Un proceso de migración de la base de datos integrada, lo que facilita enormemente el cambio de versión y no requiere utilizar el contrato de mantenimiento vendido por el editor para la migración de la misma, como en OpenERP.

  • Mejores pruebas que cubren un alcance funcional más amplio. Para ilustrar la importancia de las pruebas unitarias en los desarrolladores de Tryton cito el hecho de que las pruebas unitarias con OpenERP son de 15 minutos mientras que en Tryton demoran casi una hora.

El modelo de negocio del editor

El editor de OpenERP es la empresa OpenERP SA, con sede en Bélgica y oficinas en la India y los Estados Unidos. Las tres fuentes principales de ingresos para el editor son (en términos más o menos iguales):

  • La venta de contratos de mantenimiento de OpenERP, antes conocido como OPW y que ahora se llama OpenERP Enterprise (aunque el nombre antiguo se sigue utilizando).

  • Integradores de servicios - a menudo llamados partners: los integradores de OpenERP, que quieren figurar en el sitio web de la editorial y convertirse en un integrador "oficial", tienen que pagar una cierta cantidad cada año (al editor). El editor también ofrece a los integradores una amplia gama de servicios para ayudarlos a llevar a cabo su trabajo.

  • Proyectos de integración OpenERP que están gestionados por el editor. El editor tiene a veces el papel de integrador ante proyectos de gran tamaño.

Además de estas tres fuentes principales de ingresos, el editor se gana la vida vendiendo cursos de formación técnica o certificados: estos cursos son dictados por el propio editor o por los partners, quienes pagan parte del precio al editor por el suministro de materiales de capacitación y el acceso al examen que permite a los estudiantes obtener la certificación oficial.

La editorial también publica una serie de libros en inglés de OpenERP, si bien utiliza estos libros como medio de difusión de OpenERP y no como una fuente de ingresos, lo que explica que la versión electrónica de la mayoría de estos libros está disponibles como PDF gratis (a cambio de un tweet o mensaje de Facebook).

¿Cómo seguir las noticias de OpenERP?

Para aquellos que quieran seguir las noticias de OpenERP "de lejos", sin mucho tiempo de sobra, les aconsejo suscribirse a los siguientes blogs (RSS) disponibles:

  • El blog de OpenERP, que es la comunicación oficial de la editorial.

  • El blog de ​​la comunidad de OpenERP, que agrega los blogs de los miembros de la comunidad OpenERP (validados por la editorial). Por ejemplo, si un integrador como Camptocamp o Akretion hubiesen puesto en línea un post en su blog, esta entrada del blog aparecerá en la comunidad OpenERP sólo si la valida el editor.

Para aquellos que desean seguir más de cerca las noticias de OpenERP, otras fuentes de información, en orden de importancia, son:

  • Twitter , la suscripción a algunas cuentas de los empleados o colaboradores OpenERP activos a la comunidad (por ejemplo, puede inspirarse en la lista de cuentas que tengo, ver mi cuenta de Twitter, )

  • los flujos RSS de Launchpad que siguen los "commits", las ramas estables y las ramas de desarrollo. Por ejemplo, para seguir los commits de la rama principal (la de desarrollo) del servidor OpenERP, utilice la URL http://bazaar.launchpad.net/~openerp/OpenObject-server/trunk/atom ; para la rama de 6.1 (que es la rama estable actual), la URL a utilizar es http://bazaar.launchpad.net/~openerp/openobject-server/6.1/atom,

  • la listas de correo comunitarias que están en Launchpad: existe una lista comunitaria principal y las listas de correo especializadas, como la lista de correo para los expertos en framework ,

  • los informes de errores en Launchpad

  • Las propuestas de fusión y planes en Launchpad.

Vistazo general de OpenERP: Diagrama DAFO

Siempre he pensado que esto de DAFO (Debilidades, Amenazas, Fortalezas, Oportunidades) era era una tontería en la escuela, y ¡ahora lo estoy usando!

Fortalezas

Debilidades

  • Buen marco (framework) de desarrollo: el marco de OpenERP integra un ORM, la gestión de los derechos de acceso, motor de flujo de trabajo (workflow) y un motor de informes. (*)

  • La disponibilidad de una interfaz web completa y - desde OpenERP 6.1 - rápida, que funciona con Chrome, Firefox y Safari. Es una alternativa al venerable cliente GTK, disponible para Linux y Windows.

  • Elección de Python: un lenguaje orientado a objetos diseñado para ser fácil para el desarrollador.

  • Ligereza y modificabilidad: OpenERP no es un monstruo, es un software bastante ligero y muy fácil de entender para los desarrolladores. Con OpenERP, si usted tiene algún conocimiento técnico, llegará con relativa rapidez a un punto en el que ya no siente que el ERP es una caja negra enorme, sino que sentirá que tiene el control. Además, los requisitos de hardware para ejecutar el servidor OpenERP son modestos.

  • Ergonomía y facilidad de uso: el editor, bajo el liderazgo de su fundador Fabien Pinkaers se centra especialmente en los temas de "usabilidad" y el progreso es visible con cada nueva versión.

  • Modularidad: OpenERP es muy modular. El código funcional se distribuye en varios módulos (contabilidad, gestión de inventario, ventas, compras, CRM, gestión de producción, gestión de proyectos, notas de gastos, gestión de vacaciones, etc.) y es posible instalar sólo los módulos que necesite. Este enfoque modular, junto con la noción de herencia, puede cambiar el comportamiento nativo del ERP y enriquecerlo sin tener que cambiar el código de los módulos oficiales: podemos enriquecer las propiedades de los objetos nativos, cambiando las vistas y el comportamiento de las funciones nativas de módulos específicos sin alterar los módulos oficiales. (*)

  • Una comunidad vibrante, amable y que escribe código, o sea, que no se limita a reportar bugs y solicitar funcionalidades por parte del editor. La comunidad OpenERP probablemente sea la mayor comunidad entre todos los ERPs de código abierto. Creo que la comunidad ha alcanzado un nivel de contribución y experiencia tal en el propio código que podría continuar con el desarrollo del software en caso de quiebra de la empresa editora, lo que es una garantía de durabilidad.

  • Una marca (OpenERP) y una imagen sexy que es mucho más profesional, si bien la editorial no publica muchas historias de éxito (la razón es la dificultad de obtener el permiso de la empresa usuaria).

  • Hay sólo una versión de OpenERP y está disponible completamente gratis. No hay una versión de "Premium" de pago y una "comunitaria" gratis, con menos funciones, como sucede con Pentaho o JasperSoft.

  • la licencia AGPL que contamina los módulos: Los módulos se distribuyen necesariamente bajo AGPL. No hay, pues, ningún módulo OpenERP por el que haya que pagar a diferencia de lo que sucede, por ejemplo, con PrestaShop o Magento. (*)

  • Módulos oficiales "débiles". OpenERP tiene el mínimo en cada área. (*)

  • La falta de madurez, lo que se refleja en el tiempo dedicado a corregir errores (algunos de los cuales son muy básicos). (*)

  • El editor no le da suficiente prioridad a la mejora funcional y a la corrección de los "errores funcionales" (en contraposición a las características más "bling-bling")

  • La falta de disponibilidad del editor para aprobar (o rechazar) las propuestas de la Comunidad en las ramas oficiales de desarrollo, a pesar de que el editor se reserva el monopolio de los "commits" en esas ramas.

  • Las correcciones de errores para los clientes que han suscrito el contrato de mantenimiento con el editor se demoran mucho en ser fusionadas en la rama estable de OpenERP, lo que perjudica la estabilización general del ERP a nivel mundial. (*)

  • La falta de disponibilidad de integradores con experiencia que tienen buen nivel técnico y funcional.

  • La editorial no publica scripts de migración de los módulos oficiales: hace que haya que pagar en forma de servicio.

Oportunidades

Amenazas

  • Convertirse en el líder de los ERPs de código abierto.

  • Desarrollo de scripts de migración con el proyecto comunitario OpenUpgrade .

  • Algunos buenos contribuyentes de la comunidad OpenERP han pasado a Tryton.

  • La mala gestión de los derechos de autor por el editor de los módulos oficiales que podrían llevar a los contribuyentes de la comunidad para impugnar la validez de la licencia. (*)

 

Las entradas marcadas con (*) se muestran con más detalle en las siguientes secciones.

OpenERP, licencias y derechos de autor

OpenERP estaba inicialmente disponible bajo la licencia GPL, y luego pasó a estar bajo licencia AGPL en octubre de 2009 para las ramas de desarrollo. Así resultó que la primera versión de OpenERP liberado bajo licencia AGPL fue la versión 6.0 lanzada en enero de 2011. La licencia fue modificada de nuevo en junio de 2011 (véase el anuncio de la nueva oferta OpenERP Enterprise, concomitante con el rediseño de la página web) para transformarse en licencia "AGPL Especial", (explico el aspecto "especial" más abajo).

En su versión actual, OpenERP consta de los siguientes componentes de software:

  1. Servidor OpenERP, cuyo código fuente está disponible en la Launchpad, proyecto OpenObject-server (OpenObject es el antiguo nombre dado al framework OpenERP, pero como este nombre fue la fuente de mucha confusión para mucha gente que se preguntaba cuál era la diferencia entre OpenObject y OpenERP, esta denominación fue abandonada oficialmente, pero el nombre "técnico" del proyecto Launchpad no se ha modificado)

  2. El cliente GTK, cuyo código fuente está disponible en Launchpad, proyecto OpenObject-client ,

  3. Interfaz web, que está integrada en el servidor, y cuyo código fuente está disponible en Launchpad, proyecto openerp-web (por ejemplo, la interfaz web ha sido completamente reescrita desde cero para OpenERP 6.1, y se ha creado un nuevo proyecto en Launchpad y es por ello que lleva un nombre sin la palabra OpenObject)

  4. Los módulos oficiales, llamados addons , cuyo código fuente está disponible en Launchpad, proyecto OpenObject-addons ,

  5. Módulos comunitarios que se agruparon inicialmente en una rama de Launchpad dentro del proyecto OpenObject-addons llamada extra-addons. La mayoría están ahora disponibles en proyectos Launchpad específicos nombrados según la funcionalidad a la que apunta el módulo.

Los primeros 4 componentes (servidor, cliente GTK, la interfaz web y los módulos oficiales llamados addons) son mantenidos por el editor y los programadores del editor son los únicos que tienen derecho a hacer "commit" de la versión oficial sobre estos componentes. Más específicamente, en la organización actual, los desarrolladores del departamento de I+D de la editorial tienen el derecho "commit" en las ramas troncales, es decir, las ramas del desarrollo que será la próxima versión de OpenERP, mientras que los desarrolladores del departamento de soporte pueden hacer "commit" en las ramas estables, es decir los sectores correspondientes a las versiones de OpenERP ya liberadas (versión 5.0, 6.0 y 6.1).

El último componente (los módulos comunitarios) es propiedad de sus autores y los derechos de commit son específicos para cada proyecto de módulo comunitario.

El paso de la licencia GPL a AGPL en octubre de 2009 fue en general bien recibido. La licencia AGPL es como la GPL, pero introduce una cláusula adicional: si una persona utiliza el software en modo SaaS, puede exigir que la persona que aloja el servidor le transmita el código fuente que se ejecuta en el servidor (el usuario de software bajo licencia GPL puede exigir que el software se le distribuya/transmita, pero, en el caso de un software SaaS donde se utiliza a través de una interfaz web, el software permanece en el servidor y nunca se distribuyó ni transmitió... ¡no puede exigirse el código fuente!).

Entonces OpenERP volvió a cambiar su licencia en junio de 2011 para pasar a una especie de doble licencia:

  • los usuarios con contrato de mantenimiento vigente tienen licencia AGPL + uso privado,

  • los usuarios que no tienen un contrato de mantenimiento cuentan con licencia AGPL normales.

Esta licencia AGPL + uso privado permite desarrollar módulos privados, es decir módulos de los cuales el usuario no puede solicitar el código fuente. Esta posibilidad queda estrictamente controlada porque la licencia establece que si el módulo en cuestión se distribuye a un tercero, entonces debe ser licenciado bajo la AGPL normal. Fue introducido a petición de algunas grandes empresas que utilizan OpenERP que desean mantener en privado algunos módulos desarrollados por ellos (de lo contrario, estos módulos hubieran sido "contaminados" por la licencia AGPL) porque dicen que algunos módulos que han desarrollado implementan secretos comerciales, lo que les da una ventaja competitiva sobre sus competidores.

El tema de la licencia sigue siendo un tema sensible para los desarrolladores de software libre. Dado que este cambio de licencia introduce la posibilidad de desarrollar módulos privados bajo ciertas condiciones, una controversia estalló entre los desarrolladores de la comunidad OpenERP. Esta controversia ha puesto de manifiesto dos puntos importantes.

El primer punto se refiere a la compatibilidad entre el uso de los módulos de la comunidad y la cláusula especial de "uso privado". Los módulos comunitarios están generalmente disponibles en licencia AGPL normal. Sin embargo, si el servidor utiliza módulos de OpenERP y módulos comunitarios con licencia AGPL normales, entonces el conjunto está bajo licencia AGPL normal sin "uso privado". En otras palabras, si usted ha suscripto un contrato de mantenimiento y utiliza los módulos de la comunidad, no le será posible desarrollar módulos privados... excepto que se ponga en contacto con los autores individuales de los módulos comunitarios y les pida que, posiblemente, previo pago, se le conceda una licencia AGPL + Uso privado de su módulo.

El segundo punto que requiere mayor explicación, se refiere a la propiedad de derechos de autor de los cuatro componentes en poder de OpenERP SA (servidor, cliente GTK, la interfaz web y los addons). ¿Qué sucede si un miembro de la comunidad desea cambiar el código fuente de uno de los cuatro componentes en poder de OpenERP SA?

  • Si se trata de una corrección (bug fix), se debe abrir un bug en el proyecto Launchpad apropiado y adjuntar el parche correspondiente. Si todo va según lo previsto, un desarrollador del equipo de I+D del editor tratará de reproducir el error en la rama troncal , examinará el parche y, si considera que es bueno, se aplicará a la rama troncal . Sólo los desarrolladores del equipo de soporte del editor tienen el derecho de aplicar los parches en las ramas estables, y lo hacen sólo cuando son solicitados por un cliente que ha comprado un contrato de mantenimiento.

  • Si se trata de una mejora, es necesario crear una nueva rama en Launchpad que contenga su mejora y solicitar que la misma sea fusionada con la rama troncal correspondiente (las novedades sólo son aceptadas en las ramas troncales y no en las ramas estables). Esto es un pedido o propuesta de fusión . Si todo va según lo previsto, un desarrollador I+D estudiará la propuesta de fusión y la aceptará o rechazará.

Por estos dos medios,hay código fuente escrito por la comunidad de desarrolladores en los cuatro componentes en poder de la editorial. Dado que el editor no ha implementado un acuerdo de colaborador, donde se aclara que los derechos de autor de los colaboradores de la comunidad, se transfieren al editor cuando su código fuente es aceptado en uno de los cuatro componentes en poder del editor, derechos de autor tanto del editor como de colaboradores en estos cuatro elementos. Ciertamente, en estos cuatro componentes, el editor tiene, con mucho, la mayor parte de los derechos de autor, pero todavía hay una pequeña parte de los derechos de autor propiedad de la comunidad de desarrolladores.

Pero el editor parece pensar que tiene todos los derecho de autor en estos cuatro componentes, ya que le permite cambiar la licencia sin necesidad de la aprobación previa de los desarrolladores de la comunidad que han contribuido a su desarrollo. Esto crea un riesgo: si tiene un contrato de mantenimiento y aprovecha la oportunidad para desarrollar módulos privados, uno o más colaboradores de la comunidad que hicieron contribuciones a uno o más de estos cuatro componentes, podría demandarle por la violación de la licencia porque está utilizando la licencia AGPL + Uso privado mientras que estos contribuyentes pueden afirmar que han contribuido con código licenciado bajo AGPL normal. .

Es sorprendente que el editor de OpenERP no tome más en serio la cuestión de los derechos de autor, tema sobre el que los desarrolladores de software libre están muy sensibilizados. Ciertamente implementar un acuerdo de contribución y exigir a todos los colaboradores habituales y ocasionales de la comunidad OpenERP adherir al mismo es tedioso, pero muchos proyectos de código abierto lo hacen (KDE y Asterisk, por ejemplo).

Como anécdota, parece que esta falta de rigor en torno a la licencia es muy viejo, porque el problema ya estaba presente en la primera versión de TinyERP (6 de julio de 2004), ver el comentario publicado por snspy en la noticia del anuncio de la versión 1.0 de LinuxFR!

El framework (entorno de ejecución)

Distinguir los projectos framework de los proyectos ERP

Insisto a menudo en este punto cuando presento OpenERP: hay que distinguir entre los "proyectos del framework" y los "proyectos del ERP". ¿Qué quiero decir con un "proyecto de framework"? Este es un proyecto en el que sólo se utiliza el framework de OpenERP y donde los módulos oficiales (contabilidad, inventario, ventas, compras, CRM, producción, gestión de proyectos) no se usan o sólo uno o dos de los mismos. En el caso de un "proyecto de framework", la empresa podría optar por desarrollar su aplicación en PHP / MySQL, Ruby-on-Rails o Python / Django, pero se optó por desarrollar su aplicación en el framework de OpenERP.

De hecho, casi todas las grandes referencias de OpenERP son "proyectos de framework". Referencias como La Poste, Veolia Transport, Free, etc. son todos casos de este tipo.

La compañía que hace esta elección se aprovecha de los beneficios del framework de OpenERP: ORM, la gestión de los derechos de acceso, motor de flujo de trabajo, el motor de informes, interfaz web y cliente GTK. De hecho, a partir de mis conversaciones con algunos integradores que suelen trabajar en proyectos framework, parece que algunos tomadores de decisión, no necesariamente muy conscientes de las realidades técnicas, han elegido expandir sus aplicaciones de negocio en el framework de OpenERP, ya que contiene la palabra mágica "ERP", por lo que se puede decir "Cuento con un sistema ERP para gestionar xxxxxx", lo que implica que ya ha utilizado el software para esta función con algunos desarrollos para los ajustes necesarios. pero, de hecho, lo que hizo fue un desarrollo específico enorme, donde todo el código funcional es totalmente personalizado, lo que significa que va a tener que soportar él solo el costo de los cambios y el costo de la migración del código si quiere aprovechar las mejoras del framework.

Esto también significa que estas grandes "referencias framework" no utilizan la gestión de las existencias de OpenERP, etc. Esto limita el ámbito de aplicación de estas referencias. Sí, se demuestra que el marco OpenERP es bueno, ¡pero eso de poco sirve!

De hecho, en el marco de "proyectos de ERP", vemos que OpenERP es adecuado para su uso en PYMEs de decenas a cientos de empleados, pero resulta que estas PYMEs son poco conocidas por el público, ¡con lo cual no cuentan como referencias muy válidas!

Una excepción a esto: el uso de OpenERP realizado por Danone. Obviamente, Danone utiliza SAP ¡y no está dispuesto a cambiar! Pero Danone decidió implementar OpenERP en 3 filiales recién creadas en Colombia y Australia (2 plantas en Colombia de entre 5 y 10 usuarios, 1 instalación en Australia para 20 usuarios). En vez de aturdir a sus filiales en la etapa de lanzamiento con SAP, prefirieron instalar OpenERP para gestionar la administración de ventas, compras, inventario, etc. Puede encontrar más información sobre esta historia de éxito en este artículo sobre 01net.

Las ventajas del framework

Yo no soy el más calificado para hablar de las ventajas del framework OpenERP porque no he desarrollado en los frameworks de la competencia, así que no puedo hacer comparaciones precisas. Sin embargo, todavía se puede decir que el framework OpenERP se destaca en los siguientes puntos:

  • ORM: desde su creación, OpenERP dispone de un ORM, incluso cuando la tecnología no estaba muy extendida. El ORM proporciona una capa de abstracción sobre la base de datos, gestiona los derechos de acceso y evitar tener que escribir código SQL donde usted tiene que hacer de nuevo todas las relaciones entre las tablas con JOIN. OpenERP ha hecho evolucionar su ORM con las versiones, pero sigue utilizando su propio ORM y no se ha cambiado a un ORM libre "estándar" como SQLAlchemy por ejemplo. Sin embargo, todavía es posible utilizar consultas SQL en el código de OpenERP, por ejemplo, en partes del código donde el rendimiento es muy importante. Pero cuidado, ¡el hecho de utilizar una consulta SQL en el código omite la gestión de derechos de acceso de OpenERP! El ORM de OpenERP sólo funciona con PostgreSQL, si bien el editor había añadido una rama de prueba de soporte a MySQL, como parte de una alianza con Sun Microsystems (después de la adquisición de MySQL por parte de Sun y antes de la adquisición de Sun por parte de Oracle), pero esta rama nunca ha sido unificada con la rama oficial y nunca se ha vuelto sobre el tema. Esto no es un problema en absoluto, sino todo lo contrario; PostgreSQL es una base de datos grande, mucho mejor que el "bling-bling" MySQL. PostgreSQL es reconocida por su seriedad, profesionalidad en su modo de desarrollo y rendimiento. PostgreSQL es utilizado por ejemplo por leboncoin.fr (ver el testimonio ), el Fondo de Asignaciones Familiares (véase este enlace ) o por Météo-France (ver el testimonio ). El soporte a una sola base de datos mantiene un código simple y proporciona un OpenERP con instalaciones uniformes.

  • Acceso generalizado a través de servicios web XML-RPC. Todos los objetos de OpenERP (Ejemplo de objetos: pedidos, facturas, registros contables...) se puede acceder a través de servicios web, ya sea leer, escribir, crear y borrar. Lo mejor: todas las funciones de OpenERP son accesibles como webservices. Esto significa, por ejemplo, que cualquier clic en un botón en la interfaz de OpenERP (por ejemplo, el botón Crear Factura o el botón Validar los movimientos de stocks ) se puede hacer desde un servicio web. En cuanto al acceso a través de servicios web es una función natural del framework. Si desarrolla un módulo específico que crea un nuevo objeto, por ejemplo, alumno , y un nuevo botón, por ejemplo, asignar una hora de castigo , entonces este objeto y este botón estarán automáticamente accesibles como servicios web accesibles sin que usted necesite escribir código específico para ello.

  • El motor de flujo de trabajo (workflow): OpenERP tiene un motor de flujo de trabajo sencillo, pero suficiente para las necesidades de las PYMEs. El motor de flujo de trabajo es específico de OpenERP.

  • La inteligencia de OpenERP está del lado del servidor; no hay inteligencia en el cliente. A veces usamos el término "cliente pesado" para referirnos al cliente GTK, a diferencia de la interfaz web que se designa con el término "cliente delgado". En realidad, el cliente GTK no tiene nada de pesado, porque simplemente existe para hacer una pantalla gráfica que se ha generado en el servidor OpenERP con XML. Cuando el usuario hace clic en un botón en la interfaz del cliente GTK, envía la información al servidor que la procesa. Es por esta razón que el desarrollo de la interfaz web de OpenERP fue posible en un período muy corto, ya que el cliente es un simple motor de renderizado de gráficos. Fue suficiente con sumar un elemento que permitió convertir en pantallas HTML el XML generado por el servidor OpenERP. ¡Este desarrollo se completó en sólo seis meses en OpenERP 5.0!

  • La interfaz web de OpenERP se lanzó con OpenERP v5.0. Se ha mejorado en OpenERP v6.0 y fue reescrita por completo en OpenERP v6.1, bajo el liderazgo del nuevo Director de I+D, Antony Lesuisse. La interfaz web de OpenERP 6.1 es mucho más rápida que la anterior, hasta el punto que es tan veloz como si se usa el cliente GTK-RPC con protocolo Net-RPC (el más rápido de los protocolos disponible con el cliente GTK). Funciona bien en Firefox, Chrome y Safari, lo que simplifica la adopción como ERP multi-plataforma (Windows, Mac, Linux... ¡pero también para iPad o tabletas Android!). La interfaz web tiene una versión "móvil" en versión beta, adaptada a las pequeñas pantallas de los teléfonos móviles y que permite acceso de sólo lectura al ERP.

  • El framework de OpenERP utiliza el lenguaje Python , más precisamente, se requiere que los módulos estén escritos en Python y el framework en sí mismo esté en Python. Python es un lenguaje de programación de código abierto y orientado a objetos, que es fácil de leer y fácil/natural de usar para el desarrollador. Este es un lenguaje conciso, como lo demuestra la comparación entre el lenguaje Python y ABAP de SAP en el libro "OpenERP evaluation with SAP as reference" página 56 (libro descargable de forma gratuita) la misma función que requiere de 111 líneas de código ABAP ¡se resuelve con sólo 13 líneas de Python! Viene con un depurador integrado que puede funcionar con eficacia en los errores. Es un lenguaje interpretado y no compilado, lo que significa que es mucho más lento que los lenguajes compilados como C o C++ y un poco más lento que lenguajes semi-compilados como Java. Python tiene una gran comunidad, que proporciona acceso a una amplia gama de bibliotecas, muy maduras la mayoría de ellas.

  • El framework de OpenERP tiene una gestión integrada de módulos y puede trabajar por herencia. Como expliqué en el diagrama DAFO OpenERP tiene código modular y funcional (contabilidad, gestión de inventario, ventas, compras, CRM, gestión de producción, gestión de proyectos, notas de gastos, módulo de gestión de vacaciones, para la localización francesa, para la localización brasileña, etc.). Algunos módulos implementan un área funcional mientras que otros módulos simplemente añaden una opción (por ejemplo, el módulo product_visible_discount añade una opción para que el porcentaje de descuento sea visible para el cliente en lugar de estar directamente integrado en el precio por unidad). Los módulos tienen dependencias entre ellos, y, al instalar un nuevo módulo, OpenERP maneja la instalación de las dependencias necesarias. Pero lo más importante es que se puede cambiar el comportamiento de los módulos nativos de OpenERP o añadir funcionalidad de módulos independientes que trabajan a través de herencia. Por tanto, es posible heredar objetos (órdenes, facturas, las ubicaciones de stock,...), vistas y funciones. Esta es una herramienta muy poderosa que permite, cuando el programador la utiliza correctamente, modificar, con precisión, el comportamiento funcional de módulos nativos estándar. Por ejemplo, en un módulo específico (soy el autor), por ejemplo, se puede:

    1. Heredar el objeto ORDEN y el objeto FACTURA con el propósito de agregar un campo de tipo de proyecto , que se utiliza para hacer estadísticas por tipo de proyecto, es decir, que es un campo que el usuario selecciona según un valor de una lista.

    2. Heredar la vista de las órdenes y de las facturas para que ese campo sea visible para el usuario y se le puede asignar un valor.

    3. Heredar la función de crear la factura a partir de la orden para que el valor de este campo de tipo de proyecto se copie de la orden a la factura.

    Este modo de operación por herencia permite no tener que modificar el código del módulo de gestión de ventas oficial: todo el código de gestión de ventas de mi proyecto se recoge en un módulo específico. Este método de trabajo es muy apreciado por los desarrolladores de OpenERP, ya que es imposible implementarlo en un ERP privativo ¡donde el código fuente es cerrado!

El mejor ejemplo de la calidad del framework de OpenERP es la adición de datos cartográficos en OpenERP, que fue hecho por el integrador Camptocamp. En 2011, Camptocamp ha cambiado el framework para añadir soporte para las vistas de mapas. Con un clic en OpenERP, puede por ejemplo ver a todos sus clientes en un mapa, como se muestra en

.

Los defectos del framework

Es raro encontrar un framework perfecto y por cierto el de OpenERP no lo es. Éstos son los defectos más molestos:

  • Cuando un usuario se conecta a través de un cliente GTK a OpenERP, no hay noción de sesión. Esto significa que cada acción del usuario en el ERP, el login y la contraseña se envían al servidor. El cliente GTK cuenta con tres protocolos: Net-RPC, XML-RPC y XML-RPC SSL. Los dos primeros no son seguros: ¡la contraseña del usuario se transmite en claro por la red! El último, como su nombre lo indica, está asegurado por el uso de SSL. Pero como no existe el concepto de la sesión, ¡se vuelve a crear una sesión SSL nueva con cada acción del usuario en el ERP! Esto hace que sea un protocolo muy lento, como lo demuestran los puntos de referencia que hice en octubre de 2011. Este protocolo es tan lento que rara vez se utiliza. Mediante la interfaz web hay una solución a este problema, ya que existe la noción de la sesión nativa cuando se conecta a un servidor Web. La interfaz web OpenERP no maneja SSL de forma nativa, por lo que se la deberá posicionar detrás de un servidor proxy que servirá de intermediario entre el navegador Web del usuario y el servidor web OpenERP. Este servidor proxy se conecta por un lado con HTTP al servidor OpenERP y por el otro lado con HTTPS al navegador del usuario. Casi todos los servidores web pueden cumplir esta función, y esto es particularmente el caso de Apache y Nginx .

  • Herencia de on_change cuando se necesita agregar argumentos. Para entender este problema, usted debe haber hecho ya un cierto desarrollo en el framework de OpenERP. Para aquellos que tienen esta experiencia, me estoy refiriendo al siguiente problema: cuando se necesita agregar argumentos on_change a un campo, se hereda la vista para agregar argumentos. Si dos módulos deben heredar el mismo on_change para agregar argumentos, entonces esto representa un gran problema, y muchas veces nos vemos obligados a añadir una dependencia entre los dos módulos. Así es como he tenido que añadir una dependencia en el módulo fleet_maintenance con respecto al módulo product_loan. Debería ser posible instalar el módulo product_loan sin fleet_maintenance . Afortunadamente, el editor es consciente de este problema y la nueva API en OpenERP 7.0 o 7.1 se supone corregirá este defecto, y los on_change serán eliminados y reemplazados por un concepto totalmente diferente.

  • El problema de campos de sólo lectura, que no se escriben en la base de datos. En OpenERP, se puede declarar un campo como de sólo lectura. El editor considera que, si el campo es de sólo lectura, su valor no tiene que ser escrito en una base de datos. Sin embargo, a menudo sucede que, cuando se desarrolla un módulo, puede ser necesario para asegurar que un campo tiene un valor determinado por el cambio en el valor de otro campo (por ejemplo, cuando se cambia el producto en una línea de la orden, quiero que cambie el precio unitario. Esto se hace a través del mecanismo de on_change ) y queremos que su valor no sea editable por el usuario. Sin embargo, para que sea así, se debe poner en sólo lectura... pero entonces no se escribe en la base, ¡de modo que el valor de este campo no se conserva! Para obtener más información, consulte el informe de error correspondiente . Personalmente, me encuentro con este problema con bastante frecuencia. Hay varias soluciones, pero son pesadas ​​y difíciles de aplicar. Se espera que la nueva API que llegará con OpenERP 7.0 o 7.1 resuelva este problema.

  • El marco de OpenERP no es compatible con IPv6, sólo con IPv4. Sin embargo, es posible conectarse a la interfaz web de OpenERP IPv6 mediante la interposición entre el navegador web y el servidor OpenERP un proxy HTTP que entienda IPv6.

  • El ORM de OpenERP no está libre de defectos. No es capaz de guardar en caché peticiones de lecturas de datos, lo que podría proporcionar una mejora de rendimiento (ver este hilo en la lista de correo de los expertos de la estructura, incluyendo la respuesta de Rafael Valyi).

  • El motor de informes por defecto usado por OpenERP, basado en el lenguaje RML, no está a su altura. Me pasé decenas de horas luchando con esta utilidad y no hay manera que vaya a usarlo. Como hay mucho que decir acerca de los motores de informes en OpenERP, le he dedicado una sección más adelante.

Para concluir esta sección sobre las fortalezas y debilidades del framework OpenERP, los invito a leer este interesante artículo de un programador habituado a codificar aplicaciones de negocio en Lotus Domino y que tuvo una semana de capacitación técnica para aprender a desarrollar en el framework de OpenERP. En él se compara la estructura de los dos y da su opinión sobre lo que es mejor de uno en relación con el otro enlace al artículo .

La elección del motor de informes

Este es un resumen de los motores de informes para su uso con OpenERP.

 

Nombre del motor de informes

Módulo

Mantenedor

Herramienta de diseño

Posibles formatos de salida

RML

incluido en OpenERP servidor + módulo oficial base_report_designer . Este es el motor por defecto.

OpenERP SA

Codificación manual en RML o diseño en OpenOffice

SXW, HTML, PDF, TXT

Jasper

proyecto openerp-JasperServer de Syleam o proyecto OpenObject-jasper-reports de NaN-tic

Syleam (integrador francés) y NaN-tic (integrador español)

Jasper iReport

Soporta todos los formatos de Jasper

Aeroo

Módulo comunitario report_aeroo

Alistek (integrador letón)

LibreOffice

Todos los formatos soportados por LibreOffice: ODT, PDF, HTML, DOC,...

Webkit

Módulo report_webkit , se hizo oficial con el OpenERP 6.0

Camptocamp (integrador suizo)

Editor HTML

HTML, PDF

Para ser bien abarcativo, hay también:

  • Un proyecto que utiliza el motor de informes de Pentaho, ver las diapositivas presentadas durante las jornadas comunitarias OpenERP 2012.

  • Proyecto report_birt alojado en github, que utiliza el motor de informes de código abierto BIRT , cuyo desarrollo inicial fue financiado por la Asociación CARIF-OREF de la Isla de La Reunión. ¡La página de Github menciona que este proyecto está en estado alfa temprano !

La profusión de opciones en los motores de informe para OpenERP explica en parte los defectos en el motor de informes utilizado por defecto en OpenERP, lo que llevó a la comunidad a desarrollar alternativas.

El motor de informes RML - usado por defecto por OpenERP

Este motor está basado en el lenguaje RML (Report Markup Language), que es un estándar desarrollado por la compañía británica ReportLab . Por desgracia, este lenguaje no se ha impuesto y su uso en la industria del software se mantuvo confidencial. La compañía ha desarrollado una versión ReportLab de código abierto limitada y otra privativa (de pago) con un RML más completo (véase la "comparación de características" en esta página ). OpenERP ha desarrollado su propia implementación del lenguaje RML mediante el desarrollo de una herramienta para convertir RML a PDF y RML a HTML. Esta aplicación está disponible en el servidor de OpenERP (ver los directorios server/openerp/report/render/rml2html/ y server/openerp/report/render/rml2pdf/ ). Por desgracia, esta implementación no es completa y muchas etiquetas RML no son compatibles. Para evitar que los desarrolladores tengan que aprender RML, OpenERP tiene una herramienta de conversión SXW (el formato de archivo de OpenOffice.org 1.x) a RML, que se encuentra en el módulo de base_report_designer oficial addons (cf directorio addons/base_report_designer/openerp_sxw2rml/ ). Como es fácil imaginar, esta aplicación de conversión de SXW a RML no es completa... ¡esto también podría ser una tarea titánica!

Hay dos maneras de utilizar este motor de informes:

  • Codificar directamente en RML. Esto implica aprender el lenguaje, (no es muy complicado pero tampoco es muy divertido). ¡Este método es un poco "a la brava"!

  • Diseñar el informe en OpenOffice o LibreOffice y transferir el archivo SXW resultante al módulo OpenERP. El archivo se almacena en formato SXW y se convierte a RML. Luego hay dos posibilidades:

    • Si el formato de salida del informe es el formato SXW, el servidor OpenERP leerá el archivo SXW, sustituirá los campos por su valor y envíará el archivo SXW resultante al cliente OpenERP. Entonces no hay conversión de formato (el documento tiene formato SXW desde el diseño hasta su uso), por lo que el diseño y los estilos utilizados en el desarrollo del informe con OpenOffice / LibreOffice se conservan perfectamente .

    • Si el formato de salida del informe es PDF o HTML, el servidor OpenERP leerá el archivo RML generado desde el archivo SXW, entonces sustituirá a los campos por su valor, y usará su motor de conversión RML2PDF o RML2HTML para convertir el archivo a PDF o en formato HTML. El informe se ha sometido a dos conversiones de formato entre su diseño y utilización (SXW -> RML -> PDF / HTML). Sin embargo, como estas conversiones son realizadas por los motores de OpenERP específicos que no tienen una implementación completa de estos formatos (de nuevo, una implementación completa de la conversión de formato es una tarea de enormes proporciones), se pierde información de formato, de estilo, etc. y el documento resultante es bastante diferente de lo que el desarrollador pretendía al diseñar el informe.

Sin embargo, debemos decirlo, hay dos casos en que el motor de informes da buenos resultados:

  • Para informes con poco diseño o que tienen un estilo muy básico. Este es el caso por ejemplo de los informes contables.

  • Para los informes cuyo formato de salida es SXW (sin conversión de formato, por lo que el diseño y el estilo no son alterados).

Tomemos, por ejemplo, el caso de un informe de presupuestos. Algunas empresas quieren dejar que sus vendedores puedan cambiar todo lo que quieran en la oferta generada por el ERP. En este caso, el informe se configura para el formato de salida SXW en cuyo caso el motor por defecto de OpenERP dará el resultado deseado. Cuando el vendedor haga clic en el botón "Reporte de Oferta" en el cliente de OpenERP, LibreOffice/OpenOffice abrirá el archivo SXW generado por el ERP. Entonces se podrá cambiar cuanto quiera y exportarlo a cualquier formato compatible con LibreOffice/OpenOffice y enviarlo al cliente. Si, por otro lado, la empresa no quiere que el vendedor altere la estimación generada por el ERP (el caso más común, de lo contrario existe el riesgo que el empleado cambie manualmente en LibreOffice/OpenOffice información esencial de la oferta, y, por ende, la oferta que se envía al cliente ya no corresponde a la estimación almacenada en el ERP -en términos de productos, precios o cantidades, por ejemplo-), entonces se configurará el sistema para que genere salidas en PDF (se trata de la opción por defecto). La compañía seguramente querrá configurar o adecuar el diseño y el estilo de la oferta generada por OpenERP... y allí empiezan los problemas:

  1. El desarrollador adecuará el diseño del informe en LibreOffice/OpenOffice.

  2. Entonces subirá el nuevo informe al servidor de OpenERP.

  3. Por último, se conectará a través del cliente de OpenERP para ver el resultado en una oferta en particular... y se encontrará que su gran diseño y hermosos estilos que utilizó han sido masacrados.

Me pasé decenas de horas jugando a ese juego. ¡Y no fue para nada divertido! Entonces, todavía no había alternativa comunitaria al motor de informes de OpenERP... Ahora entiendo por qué la comunidad OpenERP estaba tan motivada para desarrollar alternativas, lo que hizo ¡y con creces!

Reportes con Jasper

JasperReports es un motor de código abierto escrito en Java. Es parte de la solución de Inteligencia de negocio de JasperSoft . Es el motor de informes de Openbravo . Es una solución madura y eficaz. El diseño de los informes se hace con iReport , que es parte de la suite de Jasper. Esta herramienta es todavía un tanto técnica y requiere un cierto aprendizaje, a diferencia de LibreOffice por ejemplo, por lo que hay que tomarse el tiempo para interiorizarse en esta herramienta. La representación la realiza el servidor de Jasper, que debe instalarse en el equipo que aloja al OpenERP. Hay dos módulos (competencia entre sí) desarrollados por Syleam y Nan-tic, que facilitan la interconexión entre el servidor del ERP y el de JasperReports. Esta es una solución que conozco muy poco, porque nunca la he usado... No puedo hablar de la misma en detalle.

Reportes con Aeroo - el que yo uso ahora

Aeroo Report es un motor de informes basado en LibreOffice (u OpenOffice), que es similar a la solución utilizada por defecto en Tryton. Es el motor de informes al cual pasé todas mis implementaciones de OpenERP reemplazando el motor de informes por defecto. Lo conozco muy bien. Es compatible con muchos formatos de entrada y de salida:

 

Formato de entrada

Formato de salida

Herramientas necesarias en el servidor

TXT / CSV

TXT / CSV con elección del juego de caracteres

Genshi

HTML

HTML

Genshi

ODT

ODT

Genshi + aeroolib

ODS

ODS

Genshi + aeroolib

ODT

PDF o DOC

Genshi + aeroolib + LibreOffice

ODS

PDF, XLS o CSV

Genshi + aeroolib + LibreOffice

Los dos principales casos de uso de Aeroo son:

  • Diseñar un informe en ODT con salida ODT. En este caso, el usuario puede modificar a voluntad en una PC el documento LibreOffice generado por OpenERP. Técnicamente, del lado del servidor sólo se usa Genshi (paquete Debian python-Genshi ) para reemplazar los campos por su valor correspondiente. LibreOffice no es necesario en el servidor (si no hay inclusión de subinformes).

  • Diseñar un informe en ODT con salida PDF. Técnicamente, esto requiere que LibreOffice (u OpenOffice) esté instalado en el servidor, y se ejecuta en modo de fondo "headless" (sin servidor X) escuchando a la interfaz localhost puerto 8100 (puerto por defecto). Cuando un usuario solicita el informe en formato PDF, el módulo report_aeroo usará primero aeroolib (una biblioteca de Python desarrollada para el proyecto Aeroo Report disponible en Launchpad ) y luego Genshi para reemplazar los valores de los campos que correspondan. El archivo ODT resultante será enviado por el módulo de report_aeroo en localhost:8100 al servidor LibreOffice que está en espera. LibreOffice convierte el archivo a PDF en el servidor. Como la conversión a PDF se realiza del lado del servidor LibreOffice, el PDF resultante es idéntico a lo que se hubiera obtenido al transformar un archivo ODT a PDF con LibreOffice instalado en su PC. Esto significa que el diseño y estilos están perfectamente conservados.

En resumen:

  • los puntos fuertes de Aeroo:

    • Fácil desarrollo de los informes con LibreOffice, que permite que sea usado por personas que no sean expertos en informática.

    • La amplia gama de formatos de salida.

  • Debilidades de Aeroo:

    • La necesidad de desarrollar una especie de perro guardián para reiniciar LibreOffice ejecutándose en segundo plano en el servidor cuando se planta. Akretion ha desarrollado uno de estos "perros guardianes" en el módulo report_aeroo en esta rama , y esperamos que nuestra contribución sea aceptada en la rama oficial de Aeroo.

    • Rendimiento. Esta solución no está diseñada con el fin de tener el mejor rendimiento posible. Esto no es un problema para los informes de una o dos páginas como ofertas, facturas, albaranes, órdenes de compra o notas de gastos, que generalmente son los informes que las empresas quieren personalizar con más asiduidad. O sea, Aeroo ¡no sería apropiado para generar un informe de todo un libro contable en formato PDF, el cual puede ser de cientos de páginas!

Reportes con Webkit

El motor de informes Webkit fue desarrollado por la empresa suiza Camptocamp, que es pionera en la integración de OpenERP y ha hecho muchas contribuciones importantes y de alta calidad. Webkit es el motor de renderizado de HTML libre utilizado por Google Chrome y Safari. Es un competidor del Gecko usado por Firefox. Es conocido por su excelente rendimiento. Ha sido desarrollado por Camptocamp para un cliente en OpenERP 5.0 que tenía una cantidad muy importante de facturas al principio de cada mes. Por lo tanto, era necesaria una herramienta eficiente, capaz de dar salida a muchos documentos en masa con formato no editable (o sea ni en ODT ni en DOC). Con Webkit, el informe debe ser desarrollado en HTML/CSS y sólo hay dos posibles formatos de salida:

  • HTML: En este caso, el módulo report_webkit usará Mako (un competidor de Genshi) para sustituir los campos por su valor en el código HTML, y el documento HTML resultante se envía al usuario.

  • PDF: En este caso, el módulo de report_webkit también usa Mako para reemplazar los campos por su valor y luego envía el documento HTML resultante al programa wkhtmltopdf (un componente del proyecto Webkit) que convierte documentos HTML en archivos PDF. El programa wkhtmltopdf requiere un servidor X, pero como los servidores de Linux normalmente no tienen un servidor X, se debe utilizar las soluciones aportadas a este efecto como xvfb .

Camptocamp logró convencer al editor para incluir el módulo report_webkit entre los módulos oficiales, lo que se llevó a cabo en OpenERP 6.0. Esto le da una gran visibilidad e implica que el módulo está cubierto por el contrato de mantenimiento ofrecido por el editor. En resumen:

  • Las fortalezas principales de Webkit son:

    • Rendimiento.

    • Que se convirtió en módulo oficial, aunque no se instala por defecto y los informes proporcionados (también por defecto) en OpenERP siguen usando el formato RML.

  • Sus debilidades son:

    • La ausencia de formato de salida fácilmente editable: Webkit no genera documentos ODT que luego puedan ser retocados por los usuarios (con LibreOffice, por ejemplo).

    • La necesidad de diseñar el informe en HTML/CSS. Como los informes son requeridos a menudo en PDF y después se los necesita imprimir en A4, es necesario conocer los métodos para desarrollar HTML/CSS para A4...

Nunca he usado Webkit, a pesar de que creo que es, sin duda, un buen motor de informes para OpenERP. Como este documento demuestra, soy bastante malo con HTML/CSS, y la idea de tener que desarrollar en HTML/CSS un documento, que en última instancia debe ser A4, siempre me ha parecido ser algo increíble... pero eso es probablemente ¡porque no conozco todas las posibilidades de CSS!

¿Qué interfaz utilizar: el cliente GTK o la interfaz web?

Con la introducción de la nueva interfaz web reescrita "desde cero", OpenERP, usando un navegador, se ha vuelto tan rápido como cuando se usa GTK, consulte esta referencia que escribí en octubre de 2011. Con esta nueva versión, la interfaz web de OpenERP no sólo tiene un diseño limpio, sino también moderno. Hoy, las innovaciones en la interfaz de usuario se desarrollan en la interfaz web, y no se implementan en el cliente GTK. Este es, por ejemplo, el caso de Kanban introducido en OpenERP 6.1 (ver las láminas 39-46 en este vídeo ), que está disponible en la interfaz de web, pero no para el cliente GTK. Este cliente ya no está desarrollado activamente, y simplemente se mantiene, es decir que los únicos cambios se dan en las correcciones de errores relacionados con el código y los cambios de menor importancia para asegurar que sea compatible con las nuevas versiones del servidor OpenERP.

Pero la mayoría de los usuarios de OpenERP histórico sigue siendo fiel al cliente... GTK ¡Ciertos hábitos tardan en morir! También hay que señalar que el cliente GTK mantiene algunas ventajas sobre la interfaz web ya que está disponible en OpenERP 6.1:

  • Soporte multi-pestañas: Con la interfaz web de OpenERP 6.1, no es posible abrir fácilmente una nueva pestaña con una nueva vista en el navegador. Esta limitación se habrá corregido en OpenERP 7.0 (versión en desarrollo) donde se podrá hacer clic derecho> Abrir en una nueva pestaña , lo que hace que la interfaz web versión 7.0 sea mucho más agradable de usar que la versión 6.1.

  • Vistas modificables: Las listas editables son mucho menos cómodas de usar en la interfaz web en el cliente GTK. La vista editable más conocida es la de las líneas contables.

  • Cuando usted está en una vista de formulario que integra un objeto one2many una vez pasado al modo de edición, no es posible obtener el formulario para el one2many con el propósito de modificar algunos campos que no están disponibles en la vista de lista. Este es, por ejemplo, el caso de las notas de entrega de pedidos después de instalar el módulo comunitario product_serial (este módulo facilita la gestión de inventarios con trazabilidad por número de serie en OpenERP).

  • Y un pequeño detalle: en la interfaz web, no se puede establecer un valor predeterminado para un campo en un asistente (wizard), por lo que es posible con el cliente GTK.

A nivel técnico, la interfaz web tiene varias ventajas sobre el cliente GTK:

  • Es posible cifrar la comunicación entre el navegador y el servidor mediante HTTPS a través de OpenERP sin degradación del rendimiento (si se necesita encriptar la comunicación entre el cliente GTK y el servidor OpenERP, el rendimiento se degrada mucho, consulte sección defectos del framework).

  • Es posible utilizar SSO (Single Sign On) mediante la instalación de un módulo web. Ya existe un módulo para OpenID (módulo auth_openid disponible en addons) y no existe, que yo sepa, para CAS.

  • Es fácil utilizarla desde una tableta tipo iPad, y como he explicado anteriormente, hay una versión beta para teléfonos móviles que proporciona acceso a los datos de OpenERP en modo de sólo lectura.

El cliente GTK se puede instalar directamente bajo Linux y el editor proporciona un programa de instalación de Windows. Para las versiones 5.0 y 6.0, algunos miembros de la comunidad han trabajado para poner a disposición un paquete para Mac OS X (consultar aquí ). Por ahora, este trabajo no se ha hecho para OpenERP 6.1. Los usuarios de Mac OS X que deseen conectarse a un servidor de OpenERP 6.1 por el momento no tienen otra opción: se debe utilizar la interfaz web.

La nueva interfaz web de OpenERP es todavía bastante nueva y, a veces nos reserva algunas sorpresas, como el error (bug)

que le pertenece. ¡Para ver y escuchar!

Plataforma y requerimientos de hardware para el servidor

OpenERP no es ávido de recursos. Para implementar un servidor OpenERP y su base de datos PostgreSQL en una PYME de decenas de personas, normalmente se puede hacer ¡con un procesador decente y 512 MB de RAM! Pero también hay que tener en cuenta los recursos requeridos por el motor de informes. Si elige Jasper o Aeroo debe proporcionar más memoria RAM para ejecutar el servidor Jasper con Java o LibreOffice en modo "headless" en el servidor.

Dado que Python y PostgreSQL son multi-plataforma, es posible implantar el servidor OpenERP en el sistema operativo de su elección: Linux, Windows, Mac OS X, etc. Lo mejor es, probablemente, implementar en el sistema operativo de servidor que mejor conoce, porque es usted quien luego administrará el servidor, configurará la seguridad, hará copias de resguardo, etc. En casi todas partes, OpenERP se ejecuta en Linux... un sistema operativo libre para acoger un ERP libre, ¿qué podría ser más natural? Es también en esta plataforma donde le resultará más fácil contar con la ayuda de la comunidad OpenERP.

No es posible hoy en día implantar OpenERP en un servidor de producción a través de paquetes, ya sean los paquetes de las distribuciones de Linux, los archivos de tipo tarball o instaladores todo-en-uno Windows. De hecho, lo más seguro es que tendrá que aplicar parches a los módulos funcionales para corregir algunos errores, lo que sería muy incómodo si ha instalado paquetes de OpenERP, a través de la distribución de Linux, por ejemplo. Además, el editor ya no hace versiones más pequeñas de OpenERP es decir, la versión principal 6.1 no es seguido por más liberaciones más pequeñas como 6.1.1 y 6.1.2 menor, etc. Yo aconsejaría implantar OpenERP en el servidor de producción con bazaar , que es la herramienta de gestión de versiónes de Launchpad.

Inteligencia de Negocio (BI) con OpenERP

Inteligencia de Negocio (BI) es una forma pomposa de nombrar a la forma de "hacer hablar" a los datos almacenados en su base de datos, a través de las estadísticas, que pueden adoptar la forma de gráficos, tablas dinámicas (decimos OLAP en lenguaje "BI"), tableros de control, etc.

OpenERP había puesto en marcha un proyecto para desarrollar su propia funcionalidad de BI (vemos acá la vieja costumbre del editor de volver a desarrollar componentes de software que ya existen en la comunidad de software libre), que ya ha sido abandonado. Es posible desarrollar gráficos directamente en OpenERP, pero las posibilidades son muy limitadas al punto que el editor ha reconstruido de cero la herramienta de gráficos en OpenERP 7.0, ver este post en el blog oficial .

Hay muchas soluciones de BI en software abierto. Las cuatro más conocidas y maduras son:

Siguiendo el consejo de Sylvain Decloix de ATOL CD (que dirige el blog OSBI.fr ) Anevia eligió Pentaho. Esto fue así porque Pentaho es la solución que ofrece la mayor riqueza de funcionalidades en su versión OpenSource gratuita. De hecho, las primeras tres soluciones mencionadas anteriormente tienen una versión libre OpenSource (también llamado Versión comunitaria), y una versión con cargo ("Enterprise") que ofrece más funciones. Al final de este post mostramos una tabla comparativa del blog de ​​OSBI.fr donde se enumeran las funciones disponibles en la versión comunitaria de estas soluciones. Akretion ha adoptado Pentaho para sus otros clientes.

La funcionalidad más ampliamente usada es OLAP, que es un tipo de tabla dinámica que obtiene sus datos directamente en una base de datos. Pero también es posible utilizar Pentaho para elaborar informes complejos con gráficos, cuadros de mando, metadatas a "objetos de negocio", etc. No voy a entrar en detalles en la funcionalidad de BI de Pentaho, porque no es el propósito de este trabajo, pero quería hacer hincapié en que si usted quiere tener capacidades de BI más avanzado que el nivel mínimo de subsistencia proporcionada por OpenERP, le convendrá investigar las soluciones de BI de código abierto.

Módulos

La cantidad de módulos

En primer lugar, es necesario diferenciar los módulos oficiales de los módulos comunitarios:

  • Los módulos oficiales son módulos que forman parte de addons que están disponibles en la rama de Launchpad lp: OpenObject-addons . Son un poco menos de 200. Son mantenidos por el editor, es decir, es la empresa OpenERP SA quien es responsable de portar el código a cada nueva versión. El editor tiene el control del código fuente o sea que la comunidad no tiene derecho a hacer "commit" de estos módulos. Las sugerencias para las mejoras de los miembros de la comunidad deben ser aprobadas por una persona del grupo I+D de OpenERP SA (estas sugerencias se llaman propuestas de fusión -merge proposals-). Sólo los módulos oficiales están cubiertos por el contrato de mantenimiento comercializado por el editor.

  • "Módulos comunitarios" son módulos desarrollados por la comunidad de desarrolladores. Históricamente, estaban disponibles en una rama de Launchpad llamada extra-addons , pero como esta rama se convirtió en un verdadero desastre, el editor instó a la comunidad a no utilizarla, sino a crear proyectos Launchpad dedicados a cada módulo o conjuto de módulos comunitarios. No hay una regla en particular para la gestión de los módulos de la comunidad: algunos son controlados por un integrador, otros son controlados por un consorcio de integradores (por ejemplo, los módulos de los proyectos conector Magento y conector PrestaShop , que son mantenidos por un consorcio que incluye a Camptocamp y a Akretion)y otros tienen derechos abiertos de "commit" a cualquier miembro de la comunidad.

Todos estos módulos están listados en el sitio de aplicaciones OpenERP (OpenERP Apps) . Este sitio le permite buscar por palabras clave y los módulos para ver su descripción y los comentarios (muy raro) dejados por los usuarios.

Una de las cosas que más me molesta sobre lo que se puede escuchar de OpenERP es que "hay 1500 módulos funcionales disponibles" . Es probable que existan 1500 módulos de OpenERP disponibles en Launchpad, por lo que esta afirmación no es falsa a priori en el sentido estricto. De los 1500, hay 200 módulos oficiales que son mantenidos por el editor, y luego 1300 que serían los módulos de la comunidad. De estos 1300, creo que el 80% de los módulos es inutilizable debido a:

  • Que no son genéricos, es decir que fueron desarrollados para un cliente específico, para sus particulares necesidades que no se encontrarán en otra empresa.

  • Que se han desarrollado para una versión anterior de OpenERP y nunca han sido portados a versiones posteriores.

  • Que se codificaron "llorando" por una necesidad particular y nunca han sido actualizados desde entonces.

Yo solía decir: "¡Mientras no hayamos probado un módulo OpenERP, no sabemos lo que vale!"

Entre los módulos comunitarios, existen todos los niveles de calidad. Si tuviera que clasificar en orden ascendente, mi clasificación sería:

  1. Los módulos poco genéricos (que son demasiado específicos para un caso particular).

  2. Los módulos genéricos pero no mantenidos como corresponde. O sea que sólo soportan una vieja versión del OpenERP.

  3. Los módulos genéricos y mantenidos, pero que no han sido terminados, como los módulos que crean nuevos objetos sin haberse ocupado de las ACL (Access Control List) relacionadas y/o cuya capacidad de uso es un desastre o no se ajustan a los estándares de ergonomía de OpenERP

  4. Los módulos genéricos, mantenidos, que se terminaron y refinaron... ¡no son tantos!

  5. El grupo de elite lo componen los módulos genéricos, mantenidos, refinados y que tienen un conjunto de pruebas de regresión automatizadas ya desde el momento del desarrollo. Yo no conozco muchos. Hay algunos de Camptocamp y el conector Magento-OpenERP que es co-mantenido por Camptocamp y Akretion.

En esta selva de módulos, donde lo mejor convive con lo peor, a menudo es difícil encontrar el rumbo. Al inicio del trabajo de integración de OpenERP en Anevia, estuvimos dos veces a punto de entrar en desarrollos específicos antes de darnos cuenta... ¡que esa funcionalidad ya estaba disponible en la comunidad! Saber cuáles son los "buenos" módulos de OpenERP es decir, aquellos que realmente funcionan, que están codificados correctamente y cuya cobertura funcional es interesante, es un conocimiento valioso y que lleva mucho tiempo adquirir. Y como nadie puede conocer todos los módulos o menos tener el tiempo para probarlos, los expertos en OpenERP tienen la costumbre de intercambiar su experiencia con módulos buenos y malos.

Los módulos oficiales: el mínimo en cada área

No se imagine que OpenERP compite con sus módulos oficiales contra los ERP privativos en áreas funcionales. OpenERP proporciona el mínimo en cada área funcional, casi me atrevería a decir que... ¡ la mínima vital!

Una de las conclusiones a las que llegué al observar las prioridades de la editorial y discutir con su equipo, es que es parte de la filosofía de OpenERP. OpenERP SA, con sus módulos oficiales, establece un mínimo básico de cada área, así como el framework de OpenERP está diseñado para que pueda ampliar fácilmente el alcance funcional a las necesidades mínimas de cada cliente.

En otras palabras:

  • En un ERP privativo de primera línea, usted encontrará un amplio alcance funcional, con una gran cantidad de parámetros para lograr que la gran masa de código (que constituye ese amplio alcance funcional) pueda operar de acuerdo a sus propias necesidades. Como el alcance funcional es amplio y se destina a cubrir las necesidades de la mayoría de las empresas con perfiles muy diferentes, el código es muy grande. En realidad, la compañía utilizará una pequeña parte de esa masa de código... y se espera que para las necesidades especiales de su trabajo, le bastará con una parte de esta masa.

  • En OpenERP, los módulos oficiales son tan básicos que van a servir para las pequeñas empresas con necesidades muy sencillas y estándares. Para las medianas empresas y/o compañías con necesidades especiales relacionadas con su tipo de trabajo, será necesario ampliar el ámbito funcional de los módulos oficiales a través de módulos adicionales. Tal vez ya exista un proyecto comunitario que ofrece módulos adicionales de los que su empresa necesita o tal vez la empresa tenga que financiar el desarrollo de estos módulos. Al final, la empresa tendrá un ERP base en las áreas donde no tiene necesidades especiales, y un ERP mejorado con módulos adicionales en áreas donde su trabajo es especialmente complejo. La filosofía de OpenERP es que esta solución es mejor que tener... ¡un ERP complejo en todas las áreas!

Estos son algunos ejemplos de "lagunas" funcionales que no están cubiertas por los módulos oficiales:

  • Contabilidad:

    • No se puede exportar el balance de comprobación o balance analítico en formato CSV

    • No soporta transferencias o débitos directos SEPA

    • Ninguna actualización automática de los tipos de cambio a través de Internet

    • No hay posibilidad de configurar un bloqueo o de advertencia cuando la tasa de cambio utilizada es demasiado antigua (por ejemplo, al validar una moneda o divisa de la factura, OpenERP usa la tasa de cambio más cercana a la fecha de la factura... ¡incluso si se trata de una de varios años atrás!)

  • Aduanas:

    • No hay soporte de la DES (Declaración Europea de Servicios).

    • Aplicación muy parcial y muy limitada de DEB (Declaración de Bienes de cambio).

  • Gestión de inventario:

    • No podemos saber en qué lugar de almacenamiento se encuentra un número de serie (número de serie es un lote de producción en idioma OpenERP).

    • No se puede obtener la lista de los lotes de producción ubicados en un lugar determinado de almacenamiento (sin embargo, es muy útil y no sólo para el inventario).

  • Productos:

    • No hay gestión de variantes de productos (por ejemplo, una camiseta está disponible en 3 tamaños y 2 colores: es un producto con 6 variantes). El modelo de datos está diseñado para soportar las variantes de productos, pero el código funcional no está presente en los módulos oficiales.

Para casi todos los ejemplos de "carencia" funciónal mencionados más arriba, hay uno o más módulos comunitarios que proporcionan la función. Es muy raro que se hagan implementaciones de OpenERP utilizando únicamente módulos oficiales.

Otro ejemplo para ilustrar el minimalismo de los módulos oficiales: esta es la lista de todas las características que tuvimos que agregar en Anevia en un módulo específico para extender la cobertura de notas de gastos oficial. (módulo hr_expense):

  • Adición de gestión de kilometraje cuando un empleado utiliza su vehículo personal para viajes de negocios: en su ficha personal, se configura la matrícula y el precio por kilómetro (que depende de la potencia fiscal del vehículo), sus datos se copiarán en su nota de gastos, y cuando añada una línea de gastos de kilometraje, el precio por kilómetro se agregará y bloqueará.

  • Los informes de gastos se consignan en OpenERP incluyendo todos los impuestos. En ciertos gastos de expensas (no todos, se debe hacer referencia a las normas fiscales), es posible recuperar el IVA. Para ello, fue necesario añadir una visualización de una cantidad neta y el importe del IVA correspondiente al importe del impuesto ingresado por el usuario para que pueda controlarse si se está utilizando el tipo correcto de IVA.

  • Revisión completa del flujo de trabajo de las notas de gastos (si alguien puede explicarme cuál es la lógica actual, ¡que me lo haga saber!). La modificación incluye también que los gerentes no pueden validar los que no sean gastos de su equipo.

  • Adición de notificaciones de correo. Por ejemplo, el gerente recibe un correo electrónico cuando necesite validar el gasto de una persona de su equipo;

  • En Anevia, el nivel analítico es por desagregación por departamentos de la empresa. Se añade un parámetro código analítico por defecto en el registro utilizado. Este es el código analítico que se utiliza de forma predeterminada en cada línea de gastos, lo que evita que el empleado tenga que volver a introducirlo cada vez (siempre se puede cambiar, por ejemplo, cuando se ha incurrido en un gasto en un departamento diferente de aquel en que trabaja).

  • Desarrollo a nuevo del informe de gastos: el informe ha sido reescrito utilizando el motor de informes elegido por Anevia (Aeroo), y añadiendo los campos específicos descritos anteriormente (placa, cantidad neta y el IVA ,...) y con un diseño mucho más agradable y ordenado.

Espero que con los ejemplos que he dado se puede entender lo que quiero decir cuando digo "los módulos oficiales proporcionan el mínimo en cada área" . Insisto un poco en este punto, porque creo que es muy importante entender OpenERP. Si hay una cosa para recordar es esta: OpenERP es un ERP sencillo y minimalista, con un buen framework que permite extender fácilmente su funcionalidad en las áreas en las que se necesite desarrollar módulos adicionales que utilicen el mecanismo de la herencia.

Esto me recuerda lo que mi padre me dijo (en ese momento trabajaba con ERPs privativos) cuando empecé a buscar un ERP para Anevia: "si un vendedor te dice que tendrán que hacer desarrollos específicos para cubrir las necesidades de tu empresa, ¡escápale como a la peste!". Al decir esto, se refería al alto coste de los desarrollos específicos, con ERP privativo, además del importante costo de licencias de software. De hecho, cuando te metes en un desarrollo específico en cualquier ERP, se necesita contar:

  • El costo inicial de implementaciòn de las funciones solicitadas.

  • El costo de terminar el módulo, para que sea intuitivo y ergonómico, añadir las políticas de seguridad, desarrollo de pruebas automatizadas para evitar regresiones (por desgracia, los presupuestos para desarrollos específicos raramente permiten esto porque el tiempo de implementación inicial ya es significativo).

  • El costo de la traducción (si la hubiera).

  • El coste de las mejoras/modificaciones que inevitablemente serán requeridas por los usuarios (o impuesta por los cambios legislativos o por cambios en la actividad y procesos de la empresa) una vez que el módulo comienza a ser realmente utilizado.

  • El costo de mantenimiento de estos módulos, de una garantía sobre la corrección oportuna de los errores que han encontrado los usuarios.

  • El costo de portar el código cuando la empresa quiera migrar a una nueva versión de OpenERP.

Como se puede ver, la decisión de realizar un desarrollo específico no debe ser tomada a la ligera, ya que requiere importantes recursos. Sin embargo, en el caso de OpenERP, es parte del método de implementación, cuando uno se embarca en tal actividad en empresas medianas y/o en compañías que tienen necesidades que son un poco fuera del ámbito de aplicación de módulos funcionales básicos. Afortunadamente, una serie de proyectos comunitarios aspiran a desarrollar una verticalización por áreas de negocio de OpenERP publicando una serie de módulos para extender el alcance funcional nativo (para algunos sectores, claro). Si tiene la suerte de ser parte de uno de estos sectores, esto le ayudará a evitar tener demasiados desarrollos específicos.

Esta es, por ejemplo, la razón de por qué mi empresa Akretion Francia, ha optado por desarrollar y mantener dos mercados verticales con OpenERP:

Akretion Francia hace implementaciones de OpenERP sólo en estos dos sectores. Esto permite a las empresas en estos sectores no pagar muchos desarrollos específicos y por lo tanto tienen un costo razonable de entrada a OpenERP, teniendo una buena cobertura funcional de su actividad.

Los módulos utilizados en Anevia

Publico aquí la lista de los módulos de OpenERP 6.1 utilizados en Anevia. Esto le permite ver:

  • Qué módulos oficiales usamos,

  • Que módulos comunitarios han sido elegidos para complementar los módulos oficiales,

  • Qué módulos específicos se han desarrollado.

Luego se analizará la distribución entre los módulos oficiales, comunitarios y específicos.

 

Nombre del módulo
Tipo de módulo
Soportado por
Rama
# de parches aplicados
# de líneas de código
Características y comentarios
base
oficial
OpenERP SA
lp: openobject-addons/6.1
0
16098
El módulo proporciona los objetos básicos: usuarios, países, divisas, socios...
account
oficial
OpenERP SA
lp: openobject-addons/6.1
5
21405
Módulo de facturación y contabilidad. De los 5 parches aplicados, 2 son de mis propuestas de combinación que conseguí sean aceptados en OpenERP 7.0, y los otros tres son corrección de errores: 1019324 , 1045424 , 1058390 .
account_accountant
oficial
OpenERP SA
lp: openobject-addons/6.1
0
21
Mini módulo que permite que el administrador tenga acceso a la contabilidad.
account_cancel
oficial
OpenERP SA
lp: openobject-addons/6.1
0
38
Módulo que permite la cancelación de una factura en caso de error.
account_followup
oficial
OpenERP SA
lp: openobject-addons/6.1
0
933
Módulo de gestión de seguimiento de clientes.
account_invoice_layout
oficial
OpenERP SA
lp: openobject-addons/6.1
1
602
Módulo que añade opciones para el diseño de las facturas, notas, secciones, líneas de separación, etc.
account_payment
oficial
OpenERP SA
lp: openobject-addons/6.1
0
1.292
Gestión de pagos del módulo de proveedores.
account_voucher
oficial
OpenERP SA
lp: openobject-addons/6.1
0
2.987
Agrega un método de pago entre cliente y proveedor (en lugar de usar directamente los asientos contables del diario bancario).
product
oficial
OpenERP SA
lp: openobject-addons/6.1
2
3.294
Módulo que contiene los objetos para los productos y los objetos anexos. El primer parche corresponde al bug No. 955051 y el segundo puede considerarse como específico de Anevia.
sale
oficial
OpenERP SA
lp: openobject-addons/6.1
0
3.940
Módulo de gestión de ventas (presupuestos, pedidos).
sale_layout
oficial
OpenERP SA
lp: openobject-addons/6.1
1
373
Módulo que añade opciones de diseño en los presupuestos: secciones, sub-totales, notas, líneas de separación, etc. El parche aplicado corrige un bug crítico , si no se aplican, usted puede terminar con una estimación donde el total no coincide con la suma de las líneas... ¡suficiente para ganarse la insatisfacción del cliente!
product_visible_discount
oficial
OpenERP SA
lp: openobject-addons/6.1
0
190
Hace posible que el cliente vea directamente el descuento (en la cotización y en la factura), en lugar de que se lo integre directamente en el precio unitario (que es el comportamiento por defecto de OpenERP).
purchase
oficial
OpenERP SA
lp: openobject-addons/6.1
1
2.898
Módulo de gestión de compras a proveedores. El parche corrige una incoherencia del parámetro o flag NOUPDATE en comparación con otros módulos: he tratado de corregirlo de manera más general en esta propuesta de fusión .
stock
oficial
OpenERP SA
lp: openobject-addons/6.1
4
7.717
Módulo de gestión de inventario. Los cuatro parches aplicados corresponden a los bugs: 1027819 , 1029537 , 1030880 , 1066127 , (los dos primeros son bloqueantes).
delivery
oficial
OpenERP SA
lp: openobject-addons/6.1
0
934
Módulo de gestión de entregas.
mrp
oficial
OpenERP SA
lp: openobject-addons/6.1
0
4.285
Módulo de gestión de la producción.
mrp_subproduct
oficial
OpenERP SA
lp: openobject-addons/6.1
0
129
Permite múltiples productos de salida a partir de una nomenclatura.
edi
oficial
OpenERP SA
lp: openobject-addons/6.1
0
1.214
Módulo de soporte de EDI. Anevia no utiliza el EDI de OpenERP EDI, pero este módulo se instala automáticamente por las dependencias en juego.
crm
oficial
OpenERP SA
lp: openobject-addons/6.1
0
6.914
El CRM de OpenERP.
crm_claim
oficial
OpenERP SA
lp: openobject-addons/6.1
0
832
Añade soporte para las quejas de los clientes en el CRM. El módulo fleet_maintenance utiliza este módulo para gestionar los RMAs.
l10n_fr
oficial
Comunidad francesa de OpenERP
lp: openobject-addons/6.1
0
10112
Contiene la localización francesa de OpenERP: contabilidad general, impuestos, regímenes fiscales, etc. La definición del Plan General de Contabilidad en XML representa el 80% del código del módulo.
users_ldap
oficial
OpenERP SA
lp: openobject-addons/6.1
0
250
Módulo que autentica a los usuarios a través de LDAP.
email_template
oficial
Inicialmente escrito por Openlabs para el proyecto comunitario Poweremail luego tomado por OpenERP SA para los addons
lp: openobject-addons/6.1
0
1.128
Módulo que permite desarrollar plantillas para los mensajes que se envían durante una acción particular (la validación de un pedido, la validación de una factura, etc.).
fetchmail
oficial
OpenERP SA
lp: openobject-addons/6.1
0
364
Módulo que permite descargar los correos almacenados en una cuenta POP3/IMAP y utilizarlos como punto de partida para un proceso de ERP (ejemplo: correo electrónico enviado a la dirección Esta dirección de correo electrónico está siendo protegida contra los robots de spam. Necesita tener JavaScript habilitado para poder verlo., lo que dará lugar a la creación de una reclamación en el CRM). Este módulo se instala automáticamente como prerequisito del CRM. Anevia no lo usa.
hr
oficial
OpenERP SA
lp: openobject-addons/6.1
1
1.198
Módulo básico para la gestión de los recursos humanos. El parche corrige una incoherencia en el parámetro o flag noupdate , como en el módulo purchase .
hr_expense
oficial
OpenERP SA
lp: openobject-addons/6.1
0
1.066
Módulo de gestión de notas de gastos.
hr_holidays
oficial
OpenERP SA
lp: openobject-addons/6.1
0
1.692
Módulo de gestión de vacaciones.
hr_timesheet
oficial
OpenERP SA
lp: openobject-addons/6.1
0
937
Módulo de gestión del cargas horarias.
hr_attendance
oficial
OpenERP SA
lp: openobject-addons/6.1
0
1.079
Módulo de gestión de presentismo. Este módulo se instala automáticamente como prerequisito al instalar el módulo hr_timesheet y no se utiliza en Anevia.
document
oficial
OpenERP SA
lp: openobject-addons/6.1
0
3.578
Módulo que permite almacenar archivos del ERP en el sistema de archivos antes que almacenarlos en la base de datos (la que sería mucho más grande si utiliza muchos archivos anexos al ERP).
google_map
oficial
OpenERP SA
lp: openobject-addons/6.1
0
77
Módulo que le permite ver una dirección en Google Maps con un solo clic. Muy práctico y por lo tanto... ¡indispensable!
base_action_rule
oficial
OpenERP SA
lp: openobject-addons/6.1
0
501
Módulo para disparar automaticamente ciertas acciones en el ERP. Se puede utilizar, por ejemplo, para enviar un correo electrónico a algunos empleados ante la creación de un nuevo producto en el ERP. Se instala automáticamente como prerequisito del CRM.
report_webkit
oficial
Camptocamp
lp: openobject-addons/6.1
0
932
Módulo que proporciona soporte de Webkit , que se describe más arriba en la sección dedicada a los motores de informes .
anonymization
oficial
OpenERP SA
lp: openobject-addons/6.1
2
590
Módulo que permite anonimizar su base de datos antes de enviarla a OpenERP SA para una migración a una versión superior de OpenERP. Este módulo también permite des-anonimizar la base de datos devuelta tras la migración. El primer parche es una corrección de errores, la otra corresponde a la adición de la capacidad de leer el archivo de des-anonimización desde el sistema de archivos (filesystem) (para evitar tener que subirlo a través de la interfaz, que requiere mucho tiempo cuando se trabaja a través de Internet).
Módulos Web
oficial
OpenERP SA
lp: openerp-web/6.1
0
no se cuentan
La interfaz web utiliza módulos de OpenERP para la operación: web_dashboard Web, web_gantt, web_mobile, web_calendar, web_diagram, web_graph, web_kanban, web_process, web_tests . No he contado estos módulos en el número de líneas de código de los módulos funcionales.
Módulos ocultos
oficial
OpenERP SA
lp: openobject-addons/6.1
0
11403
Muchos módulos están clasificados como oculto (Hidden) o dependencia (Dependancy) y se instalan por un tema de interdependencia o prerequisito. Ejemplo: l10n_fr_rib, analytic, process, board, base_setup, mail, etc.
report_aeroo
comunitario
Alistek
lp: aeroo/openerp6.1.x
2
2.736
Soporte para Aeroo, que se describe en detalle en la sección de este documento dedicada a los motores de informes . El primer parche aplicado es una corrección de errores en el código de barras EAN13, el segundo es el desarrollo alcanzado por Akretion para añadir un disparador (watchdog) de LibreOffice (si LibreOffice no responde, se ejecuta un script que lo reinicia), ver esta rama .
report_aeroo_ooo
comunitario
Alistek
lp: aeroo/openerp6.1.x
0
488
Complemento del módulo anterior, permite el uso LibreOffice en el servidor para generar informes en formato PDF.
report_aeroo_printscreen
comunitario
Alistek
lp: aeroo/openerp6.1.x
0
59
Sustituye la función printscreen nativa de OpenERP. Permite exportar las vistas de lista en formato ODT en lugar de PDF, lo que las hace más fáciles de manejar.
fleet_maintenance
comunitario
Akretion, financiado principalmente por Anevia
lp: fleet_maintenance
0
1.651
Proporciona gestión de los contratos de mantenimiento de los equipos. Este módulo ha sido desarrollado para las necesidades de Anevia, pero genéricamente.
sale_layout_fleet_
maintenance
comunitario
Akretion
lp: fleet_maintenance
0
50
Módulo para la compatibilidad entre el módulo fleet_maintenance y el módulo sale_layout .
account_invoice_layout_
fleet_maintenance
comunitario
Akretion
lp: fleet_maintenance
0
17
Módulo para la compatibilidad entre el módulo fleet_maintenance y el módulo account_invoice_layout .
fleet_serial
comunitario
Akretion
lp: fleet_maintenance
0
33
Módulo que muestra si un lote de producción está cubierto por un contrato de mantenimiento o no.
product_serial
comunitario
Akretion
lp: openobject-addons/extra-6.0
0
483
Módulo que facilita la gestión de inventarios con trazabilidad por número de serie. Este módulo fue desarrollado originalmente para las necesidades de Anevia y ha sido ampliamente adoptado por la comunidad.
product_variant_multi
comunitario
Originalmente desarrollado por OpenERP SA, ahora mantenido principalmente por Akretion
lp: openobject-addons/extra-trunk
0
667
Módulo que permite gestionar variantes de producto.
product_variant_
multi_advanced
comunitario
Akretion
lp: openobject-addons/extra-trunk
0
123
Módulo que añade ciertas funcionalidades al módulo product_variant_multi que no son necesariamente útiles para todos.
product_hardware_revision
comunitario
Akretion, financiado por Anevia
lp: ~ openerp-community/openobject-addons/trunk-addons-community
0
178
Facilita la gestión de revisiones de hardware en los productos en OpenERP.
product_loan
comunitario
Akretion, financiado por Anevia
lp: ~ openerp-community/openobject-addons/trunk-addons-community
0
706
Permite la gestión de los préstamos de equipos a los clientes de forma gratuita.
intrastat_base
comunitario
Akretion (codificado bajo mi responsabilidad)
lp:new-report-intrastat
0
351
Módulo básico para el soporte de DEB (Declaración de Bienes de Cambio) y DES (Declaración Europea de Servicios).
l10n_fr_intrastat_product
comunitario
Akretion (codificado bajo mi responsabilidad)
lp:new-report-intrastat
0
1.643
Proporciona soporte completo para DEB, incluyendo la generación de un archivo XML para ingresar en el sitio ProDouane .
l10n_fr_intrastat_service
comunitario
Akretion (codificado bajo mi responsabilidad)
lp:new-report-intrastat
0
336
Proporciona soporte completo para el DES, incluyendo la generación de un archivo XML para ingresar en el sitio ProDouane.
sale_partner_bank
comunitario
Akretion (codificado bajo mi responsabilidad)
lp: openobject-addons/extra-trunk
0
64
Módulo útil si tiene varias cuentas bancarias y desea asignar cada cliente a una de sus cuentas para cuando hagan sus pagos por transferencia.
coface_credit_insurance
comunitario
Akretion, financiado por Anevia
lp:openerp-Coface-connector
0
619
Permite la importación automática de las calificaciones de Coface sobre los registros de los socios comerciales. La Coface es una de las aseguradoras de crédito más importantes de Francia.
board_coface
comunitario
Akretion, financiado por Anevia
lp:openerp-Coface-connector
0
31
Proporciona un tablero de control para seguimiento de los plazos de presentación de informes para cumplir con Coface en caso de impago del cliente.
account_move_csv_import
comunitario
Akretion (codificado bajo mi responsabilidad)
lp: openobject-addons/extra-trunk
0
228
Permite una fácil importación de asientos contables en formato CSV. Se utiliza principalmente para importar asientos de pago que vienen de otro programa.
account_analytic_required
comunitario
Akretion (codificado bajo mi responsabilidad)
lp: openobject-addons/extra-6.0
0
64
Se puede forzar (o prevenir) la entrada de una cuenta analítica cuando el asiento contable utiliza ciertas cuentas de la contabilidad general. Es útil para las empresas que utilizan de forma rutinaria análisis de todos sus cargos, o de sus productos.
account_reversal
comunitario
Akretion (codificado bajo mi responsabilidad)
lp: openobject-addons/extra-6.0
0
136
Permite hacer una reversión contable sin intervención manual.
asterisk_click2dial
comunitario
Akretion (codificado bajo mi responsabilidad)
lp: openerp-asterisk-connector
0
864
Proporciona la conexión entre OpenERP y Asterisk. Muy conveniente para todas las empresas que tienen un PBX basado en Asterisk, ya que le permite utilizar OpenERP como guía de teléfonos de la empresa, e incluye características Click2Dial y visualización de una ficha en un solo click.
asterisk_click2dial_crm
comunitario
Akretion (codificado bajo mi responsabilidad)
lp: openerp-asterisk-connector
0
161
Otras funciones para el conector Asterisk-OpenERP para el CRM.
currency_rate_update
comunitario
Camptocamp, donde hice algunas contribuciones
lp: c2c-financial-addons/6.1
0
616
Permite importar tipos de cambio diarios desde una selección de sitios web.
currency_rate_date_check
comunitario
Akretion (codificado bajo mi responsabilidad)
lp: openobject-addons/extra-trunk
0
71
Asegura que el ERP no use un tipo de cambio muy viejo en comparación con la fecha de la transacción.
account_financial_
report_webkit
comunitario
Camptocamp
lp: c2c-financial-addons/6.1
0
3.223
Contiene los famosos informes financieros Camptocamp. Este módulo sustituye a los nativos de OpenERP.
account_banking
comunitario
Comunidad de Addons bancarios, especialmente Stefan Rijnhart de Therp
lp: ~ akretion-team/banking-addons/trunk-banking-addons-sepa
0
5.916
Proporciona un framework para la importación de estados de cuenta y la generación de archivos para la transferencia o pruebas en diversos formatos.
account_banking_sepa_
credit_transfer
comunitario
Akretion (codificado bajo mi responsabilidad)
lp: ~ akretion-team/banking-addons/trunk-banking-addons-sepa
0
380
Permite la generación de archivos con formato de transferencia SEPA XML (implementación de la norma SEPA Credt Transfer, específicamente el formato PAIN).
account_iban_preserve_
domestic
comunitario
Therp
lp: ~ akretion-team/banking-addons/trunk-banking-addons-sepa
0
40
Se instala automáticamente para cumplir dependencias al instalar el módulo account_banking .
partner_world_area
comunitario
Anevia
lp: ~ openerp-community/openobject-addons/trunk-addons-community
0
100
Permite establecer las regiones del mundo y asociar a un país con cada una de esas regiones. Útil para las estadísticas por región.
sale_layout_cleanup
comunitario
Akretion (codificado bajo mi responsabilidad)
lp: openobject-addons/extra-trunk
0
45
Permite utilizar el módulo sale_layout directamente y de una manera simple desde un punto de vista técnico, sin tener que utilizar el módulo analizador (parser) de sale_layout .
scheduler_error_mailer
comunitario
Akretion
lp:~akretion-team / + junk / scheduler_error_mailer
0
64
Se puede enviar un e-mail en caso de no haberse llevado a cabo una tarea programada de OpenERP. ¡Muy conveniente para el administrador!
7 módulos *_viewer
comunitario
Akretion (codificado bajo mi responsabilidad)
lp:openerp-viewer-groups
0
78
Estos 7 mini-módulos añaden un nivel con derechos visor (viewer) (sólo lectura) en las áreas funcionales clave (ventas, compras, gestión de inventarios, planificación de necesidades y contabilidad), además de los niveles de usuario y administrador . Los 7 módulos son sale_viewer, purchase_viewer, stock_viewer, account_viewer, account_voucher_viewer y sale_mrp_viewer mrp_viewer .
bi_invoice_company_
currency
comunitario
Akretion (codificado bajo mi responsabilidad)
lp:~akretion-team/+junk/business_intelligence_fields
0
105
Alta en los importes de las facturas en la moneda de la empresa (y no sólo en divisas). Útil para la alimentación de Inteligencia de Negocio para las estadísticas de facturación.
bi_invoice_payment
comunitario
Akretion (codificado bajo mi responsabilidad)
lp:~akretion-team/+junk/business_intelligence_fields
0
104
Agrega en la factura información de su pago. Útil para alimentar la BI a fin de manejar estadísticas sobre los pagos de los clientes.
bi_expense_company_
currency
comunitario
Akretion (codificado bajo mi responsabilidad)
lp:~akretion-team/+junk/business_intelligence_fields
0
62
Añadido, en las líneas de importes de gastos, de los montos en la moneda de la compañía. Útil para alimentar BI en lo que respecta a estadísticas sobre las notas de gastos.
bi_build_datawarehouse
comunitario
Akretion (codificado bajo mi responsabilidad)
Anevia interno (que se publicará tan pronto como tenga tiempo)
0
372
Se utiliza para generar el almacén de datos (data warehouse) para BI.
sale_no_dashboard
comunitario
Akretion
lp:~akretion-team/+junk/addons-no-fluff
0
8
Este mini-módulo inhabilita el tablero de control de ventas nativo de OpenERP. ¡Esencial cuando se desea utilizar la interfaz web de OpenERP! De hecho, en la interfaz web, el tablero de control se muestra por defecto cuando usted va al menú Gestión de Ventas. El problema es que este tablero de instrumentos es muy lento si cuenta con un volumen de datos de ventas importante en el ERP, ¡lo que hace que la interfaz web sea inutilizable!
stock_no_dashboard
comunitario
Akretion
lp:~akretion-team/+junk/addons-no-fluff
0
8
Similar al anterior pero para inventarios.
stock_move_always_
allow_cancel
comunitario
Akretion (codificado bajo mi responsabilidad)
lp:~akretion-team/+junk/stock_misc
0
27
Mini-módulo que permite la cancelación de un movimiento de stock en todos los casos (por defecto, OpenERP no permite cancelar un movimiento de stock confirmado).
stock_prodlots_by_location
comunitario
Akretion (codificado bajo mi responsabilidad)
lp:~akretion-team/+junk/stock_misc
0
25
Mini-módulo que le permite ver la lista de los lotes de producción que están en una ubicación dada de inventario.
base_external_referentials
comunitario
Akretion (e inicialmente OpenLabs)
lp: ~ extra-addons-commiter/openobject-extension/oerp6.1-cleanning
0
2.757
Para asignar (mapear) objetos de OpenERP a objetos de programas externos. Requerido por el conector OpenERP-PrestaShop.
base_onchange_player
Comunitario
Akretion
lp: ~ extra-addons-commiter/openobject-extension/oerp6.1-cleanning
0
30
Requerido por el conector OpenERP-Prestashop.
base_pop_up
Comunitario
Akretion
lp: ~ extra-addons-commiter/openobject-extension/oerp6.1-cleanning
0
103
Requerido por el conector OpenERP-Prestashop.
base_sale_multichannels
Comunitario
Akretion (e OpenLabs, inicialmente)
lp: ~ extra-addons-commiter/e-commerce-addons/oerp6.1-cleanning
0
1.335
Funciones básicas necesarias para ventas multicanal. Requerido por el conector OpenERP-PrestaShop.
base_sale_export_partner
comunitario<
Akretion (codificado bajo mi responsabilidad)
lp: ~ extra-addons-commiter/e-commerce-addons/oerp6.1-cleanning
0
68
Funciones básicas necesarias para exportar un socio a un software externo. Requerido por el conector OpenERP-PrestaShop.
base_sale_export_product
comunitario
Akretion
lp: ~ extra-addons-commiter/e-commerce-addons/oerp6.1-cleanning
0
96
Funciones básicas necesarias para exportar un producto a un software externo. Requerido por el conector OpenERP-PrestaShop.
sale_automatic_workflow
comunitario
Akretion
lp: ~ extra-addons-commiter/e-commerce-addons/oerp6.1-cleanning
0
276
Requerido por el conector OpenERP-PrestaShop.
sale_exceptions
comunitario
Akretion
lp: ~ extra-addons-commiter/e-commerce-addons/oerp6.1-cleanning
0
349
Requerido por el conector OpenERP-PrestaShop.
sale_quick_payment
comunitario
Akretion
lp: ~ extra-addons-commiter/e-commerce-addons/oerp6.1-cleanning
0
261
Requerido por el conector OpenERP-PrestaShop.
product_custom_attributes_
shop
comunitario
Akretion
lp: ~ extra-addons-commiter/e-commerce-addons/oerp6.1-cleanning
0
207
Requerido por el conector OpenERP-PrestaShop.
product_images_sync
comunitario
Akretion (codificado bajo mi responsabilidad)
lp: ~ extra-addons-commiter/e-commerce-addons/oerp6.1-cleanning
0
20
Requerido por el conector OpenERP-PrestaShop.
product_custom_attributes
comunitario
Akretion
lp: ~ extra-addons-commiter/product-extra-addons/oerp6.1-stable-product-images-renamed
0
594
Requerido por el conector OpenERP-PrestaShop.
product_images
comunitario
OpenLabs y Akretion
lp: ~ extra-addons-commiter/product-extra-addons/oerp6.1-stable-product-images-renamed
0
302
Agrega gestión de imágenes al producto. Requerido por el conector OpenERP-PrestaShop.
product_m2mcategories
comunitario
OpenLabs
lp: ~ extra-addons-commiter/product-extra-addons/oerp6.1-stable-product-images-renamed
0
30
Permite que un producto pueda pertenecer a varias categorías. Requerido por el conector OpenERP-PrestaShop.
product_sequence
comunitario
Zikzakmedia
lp: ~ extra-addons-commiter/product-extra-addons/oerp6.1-stable-product-images-renamed
0
53
Requerido por el conector OpenERP-PrestaShop.
prestashoperpconnect
comunitario
Akretion y Camptocamp
lp: prestashoperpconnect
0
691
Principal conector del módulo de OpenERP-PrestaShop.
prestashoperpconnect_
catalog_manager
comunitario
Akretion
lp: prestashoperpconnect
0
232
Módulo que permite gestionar el catálogo de productos en OpenERP y sincronizar con PrestaShop (sin este módulo, el catálogo de productos se gestiona con PrestaShop y se sincroniza con OpenERP).
prestashoperpconnect_
export_partner
comunitario
Akretion (codificado bajo mi responsabilidad)
lp: prestashoperpconnect
0
35
Módulo que permite exportar un socio de OpenERP hacia PrestaShop (sin este módulo, los socios sólo se exportan en el sentido PrestaShop - OpenERP).
anevia_base
específico de Anevia
Anevia
Interno de Anevia
-
75
Mini-módulo que completa el módulo base . No tiene gran cosa.
anevia_partner
específico de Anevia
Anevia
Interno de Anevia
-
102
Módulo que añade o modifica algunos campos de los socios: agrega el campo SIREN en los socios, agrega el campo país en el formulario de vista y además cómo se calcula el mismo (de manera predeterminada, el campo País es igual al país de la primer dirección de este socio, lo que es demasiado simplista para Anevia). Añade una notificación por correo interno al crear un nuevo socio.
anevia_sale
específico de Anevia
Anevia
Interno de Anevia
-
374
Impide que los usuarios cambien manualmente los impuestos en las líneas de un presupuesto (se debe utilizar la posición fiscal ¡y nada más!). Requiere que los usuarios seleccionen un producto de una línea de la cotización (por defecto, el campo producto no es necesario). Agrega un paso al flujo de trabajo de una orden para diferenciar la recepción de un pedido y su aceptación por parte de la empresa (por ejemplo, un nuevo pedido de un cliente que tenía una vieja factura sin pagar se incorpora al workflow como orden recibida pero no como orden aceptada). También añade el paso Proforma al workflow de órdenes (agrega el título Factura Pro-Forma al presupuesto), de manera que los comerciales puedan enviar una factura proforma para los clientes que lo soliciten sin alterar el circuito administrativo. Además de algunos detalles propios de Anevia.
anevia_stock
específico de Anevia
Anevia
Interno de Anevia
-
321
Cambio en la gestión de los números de seguimiento y del embalaje. En OpenERP, en forma predeterminada, el número de seguimiento es una propiedad de expedición. Sin embargo, algunos portadores (UPS y otros) asignan un número de seguimiento al bulto. También agrega un campo calculado cuya generación es requerida para los formularios de aduanas (EUR-1 y ATR).
anevia_purchase
específico de Anevia
Anevia
Interno de Anevia
-
72
Complementa el módulo oficial purchase . Añade un campo Condición de pago a las órdenes a los proveedores, con un comportamiento similar al campo Condición de pago de las órdenes de los clientes. Este módulo no será necesario con OpenERP 7.0 si mi merge proposal de agregado de condiciones de pago a las órdenes a los proveedores se acepta (¡ya estoy en la cuarta versión de esta propuesta y tengo esperanzas!).
anevia_account
específico de Anevia
Anevia
Interno de Anevia
-
384
Complementa el módulo oficial account . Añade un enlace entre las líneas de las facturas y las líneas de las órdenes. Mi propuesta en este sentido ya ha sido aceptada, en dos partes: addons y servidor) para OpenERP 7.0.
anevia_followup
específico de Anevia
Anevia
Interno de Anevia
-
26
Complementa el módulo oficial account_followup: definición de algunos campos adicionales para administración de seguimiento de clientes.
anevia_mrp
específico de Anevia
Anevia
Interno de Anevia
-
15
Contiene una pequeña modificación del módulo oficial mrp .
anevia_crm
específico de Anevia
Anevia
Interno de Anevia
-
97
Agrega una función para enviar un email generado a partir de una plantilla de correo electrónico cuando se pasa a la etapa siguiente en el CRM.
anevia_product
específico de Anevia
Anevia
Interno de Anevia
-
254
Añade campos específicos para Anevia en las fichas de producto. Emite una notificación por correo interno al crear un nuevo producto (a través de base_action_rule).
anevia_product_variant
específico de Anevia
Anevia
Interno de Anevia
-
173
Agrega algunas funciones específicas para Anevia a nivel de la generación de variantes de productos (a partir de una plantilla).
anevia_hr
específico de Anevia
Anevia
Interno de Anevia
-
85
Añade un enlace inverso desde la ficha usada hacia la ficha usuario (de forma nativa, el enlace sólo existe en la otra dirección). He conseguido que este enlace se agregue al módulo hr oficial de OpenERP 7.0. Añade una notificación por correo interno al darse de alta un nuevo empleado.
anevia_hr_expense
específico de Anevia
Anevia
Interno de Anevia
-
623
Adición de muchas características en la gestión de las notas de gastos que figuran en la sección titulada los módulos oficiales: el mínimo en cada área.
anevia_hr_holidays
específico de Anevia
Anevia
Interno de Anevia
-
132
Personalización de la transición de derechos en el workflow de validación de vacaciones. Adición de una notificación por correo cuando la solicitud de licencia es presentada por el empleado y cuando es aceptada o rechazada por su gerente.
anevia_hr_timesheet
específico de Anevia
Anevia
Interno de Anevia
-
271
Pequeños cambios específicos para Anevia para facilitar la entrada de tabla de tiempos o asistencia. Agregado de un informe complementario.
anevia_
prestashoperpconnect
específico de Anevia
Anevia
Interno de Anevia
-
7
Pequeños cambios específicos para Anevia del conector OpenERP-PrestaShop (cambiar las asignaciones de campos y valores por defecto).
anevia_sale_process
específico de Anevia
Anevia
Interno de Anevia
-
116
Adición de campos específicos de Anevia para seguir el proceso de ventas del cliente: se les incorpora en el presupuesto, luego se los copia en la factura y se los vuelve a copiar en al Haber. Este módulo también añade el enlace de la factura a datos de inventarios y a las órdenes. LP NOV 04
asterisk_click2dial_ldap
específico de Anevia
Anevia
Interno de Anevia
-
111
Sincroniza la información telefónica de la ficha del usuario en el LDAP de Anevia y OpenERP.
anevia_profile
específico de Anevia
Anevia
Interno de Anevia
-
48
En este módulo se declaran las dependencias entre todos los demás módulos utilizados por Anevia. También contiene una serie de normas de seguridad: creación de grupos específicos, la eliminación de una serie de ACL nativas y la modificación de otras ACLs nativas.
10 módulos
report_aeroo_*
específico de Anevia
Anevia
Interno de Anevia
-
751
10 módulos que contienen información de formato personalizado para Aeroo: report_aeroo_account, report_aeroo_delivery, report_aeroo_followup, report_aeroo_hr_expense, report_aeroo_product, report_aeroo_product_loan, report_aeroo_purchase, report_aeroo_sale, report_aeroo_stock, report_aeroo_terms_of_sale .

 

Para contar las líneas de código, he usado el programa cloc con el siguiente comando:.... cloc - exclude-dir = lib - match-f = "* \ $ py | * \ xml .. $ | * \ js "- no-match-f =" __ openerp__.py |.. _xsd * \ $ py "path_to_module .

La distribución del número de líneas de código entre los módulos oficiales, los comunitarios y los específicos es:

 

Tipo de módulo

# de líneas de código

Porcentaje del total

Oficial

111 000

76%

Comunitario

30420

21%

Específico de Anevia

4.040

3%

Total

145 460

100%

¿Qué podemos aprender de esta lista?

  • He dicho que OpenERP es un ERP muy modular... ¡contando los módulos ocultos, no son menos de 150 los módulos que Anevia usa!

  • la cantidad de líneas de código en los módulos específicos y los comunitarios es importante. Esto da una idea del esfuerzo en cuanto a migración a una versión superior de OpenERP.

  • Encontramos, en general, las mismas empresas (y autores y encargados de mantenimiento) en lo que a módulos comunitarios se refiere. Por ejemplo, para los módulos usados por Anevia vemos los nombres de Camptocamp, Alistek, Akretion y Therp. Por supuesto, éstas no son las únicas cuatro empresas que hacen el mantenimiento de los módulos, ni mucho menos, pero creo que es una ilustración del hecho de que hay un núcleo de colaboradores formado por un pequeño número de empresas, que no tiene nada que ver con el gran número de integradores oficiales de OpenERP.

Aprovecho esta sección para extenderme a hacer un análisis global de la cantidad de líneas de código en OpenERP:

 

Componente

# de parches aplicados

# de líneas de código

Porcentaje del total

Método de recuento

Servidor

0

27740

12%

Módulo base excluido dado que se lo cuenta entre los funcionales

Módulos funcionales

véase la tabla anterior

145 460

65%

Detalle presentado en la tabla anterior

Interfaz Web

0

31590

14%

Incluyendo los diez módulos web , que no han sido contados en los módulos funcionales

Cliente GTK

0

19390

9%

El código de SpiffGTKWidgets se excluye del recuento

Total

224 190

100%

La madurez de OpenERP

OpenERP, ¿es un ERP que maduró? Es una pregunta crucial... pero voy a tratar de responder objetivamente, basándome en los errores que he encontrado personalmente en OpenERP 6.1 desde su lanzamiento el 22 de febrero de 2012. En mi opinión, la mejor manera de darse cuenta de la madurez de un proyecto es analizar los errores que encontramos: si el proyecto está maduro, encontraremos pocos errores (y ocurren en escenarios específicos) y, en general, fuera de lo común. Por el contrario, si encontramos fallos en los escenarios y las normas básicas, no podemos decir que el software esté maduro.

Así que hice una selección de los errores encontrados en OpenERP 6.1 desde su publicación, clasificándolos en:

  • Críticos,

  • Fáciles de entender,

  • Las condiciones para ser afectados por el error o bug son muy comunes.

 

Área funcional

Condiciones para verse afectado por el bug

Resumen de la ocurrencia del error

Informe de fallo

Fecha del informe

Disponibilidad de la solución

Autor de la solución

Fecha de integración de la corrección en la rama estable.

Contabilidad

Utilizando el cliente GTK (que es mucho más cómodo de usar para asientos contables que la interfaz web)

Es imposible hacer una entrada en un diario

Bug 944079

?

?

OpenERP SA

9 de mayo de 2012

Contabilidad

Haber activado la opción Group invoice lines en el libro de registro ventas o compras (opción que no está activada de forma predeterminada) y tener algunas facturas en moneda extranjera

La agrupación de líneas de factura en el registro contable se lleva a cabo, las cantidades de débito y crédito son correctas, pero el monto en divisas no lo es (es igual a una de las filas agrupadas en vez de ser igual a la suma de todas las líneas agrupadas)

Bug 1019324

29 de junio de 2012

29 de junio de 2012

Yo mismo

17 de agosto de 2012

Ventas

Tener instalado el módulo sale_layout , que añade opciones para las especificaciones de diseño en los presupuestos (líneas de pedido, secciones, subtotales, etc.)

Si elimina una línea de un presupuesto (y no hace nada más), el importe total no se vuelve a calcular. Así resulta un presupuesto con un total que no coincide con la suma de los ítems del mismo.

Bug 856291

?

25 de julio de 2012

Yo mismo

27 de agosto de 2012

Inventarios

Usar trazabilidad por lotes de producción (es decir, por número de serie)

En un documento de expedición de productos con seguimiento por lote de producción y de productos sin seguimiento, al validar la lista de los productos que salieron del stock, la columna de lote de producción no aparece en pantalla, lo que impide una entrega parcial, ya que para ello debería seleccionar los lotes de producción de pantalla afectados por la entrega parcial

Bug 1027819

23 de julio de 2012

23 de julio de 2012

Yo mismo

Todavía no se hizo

Inventarios

Usar trazabilidad por lotes de producción (es decir, por número de serie)

Si se hace una entrega parcial que contiene productos con trazabilidad, se bloquea al hacer la validación de la entrega.

Bug 1030880

30 de julio de 2012

30 de julio de 2012

Yo mismo

Todavía no se hizo

Contabilidad

Poner un descuento en una línea de factura con una cantidad elevada de unidades

El importe que figura en la factura (base imponible) no es igual al total de la factura sin IVA.

Bug 1058390

29 de septiembre de 2012

29 de septiembre de 2012

Todavía no se hizo (aunque el parche fue aceptado en la versión troncal)

Para completar esta lista, puede ver una lista de todos los errores reportados por Anevia contra OpenERP 6.1 a través del contrato de mantenimiento que tiene con el editor (llamado OPW ) en el documento de Google Docs llamado Anevia OPW bugs followup (en inglés), que Anevia ha aceptado compartir. Como Anevia empezó a preparar su trabajo de migración a OpenERP 6.1 en diciembre de 2011, un poco más de 2 meses antes de la liberación, el primero de la lista fue hallado antes del lanzamiento (¡pero todavía estaba presente en la liberación 2 meses más tarde!). Los errores en la tabla pertenecen a esa lista.

Dado los errores que encontré, mi opinión es que OpenERP no puede ser considerado hoy en día como un software maduro. Lo considero más bien como un software en maduración.

Algunos ejemplos de errores que he detallado anteriormente pueden dar miedo a un novato en OpenERP. De hecho, es preocupante, no hay que ocultar la realidad. Pero también debe tenerse en cuenta que, para la mayoría de ellos, son fáciles de arreglar por un desarrollador medio de Python con un buen nivel de experiencia en el framework de OpenERP. Yo no soy un desarrollador de Python con mucha experiencia (ni mucho menos), y me puse a codificar en el framework de OpenERP sólo a partir de finales de 2010, y que he sido capaz de arreglar la mayoría de los errores indicados más arriba por mí mismo. Para ver la lista de los errores que he podido corregir, consulte la columna Patch supplied by Akretion/Anevia en Anevia OPW bug followup cuyo enlace ya he dado más arriba. Se necesita paciencia y lleva tiempo, pero es bastante asequible.

De hecho, esta falta de madurez tiene, para mí, varias consecuencias prácticas:

  • Debe preverse tiempo para arreglar los errores en la fase de integración de OpenERP y después de la puesta en producción. El tiempo que hay que dedicarle no es despreciable, por lo que debe ser previsto tanto el el plan del proyecto y el presupuesto.

  • Debemos conocer y utilizar la metodología a adoptar cuando se encuentra un error en un software libre.

    1. Compruebe que el error ocurre cuando se utiliza el código más actualizado y sólo usando los módulos oficiales (si el error se refiere a un módulo comunitario, intente reproducirlo utilizando únicamente módulos oficiales y el comunitario en cuestión y sus dependencias). Esto asegura que el error no es causado por módulos específicos. O sea, ¡que el error no esté en nuestro propio código!

    2. Ver que el error no aparezca en la lista del gestor de fallos de OpenERP en Launchpad. Si este es el caso, lea el informe del error y cualquier comentario que hubiere, ya que tal vez haya un parche o una solución.

    3. Si el fallo no se ha resuelto, no tenga miedo de entrar en el código para solucionarlo usted mismo, utilizando el depurador de Python (que se activa al ejecutar OpenERP con la opción -debug )

    4. Una vez que la solución se encuentra, se debe abrir un informe de error (bug report) en Launchpad: una descripción detallada en el mejor inglés posible, describiendo el escenario específico que permita reproducir el error y adjuntar el parche con todas las explicaciones necesarias.

    5. Habrá que hacer gestiones varias para que el informe de error sea considerado por el editor o el autor del módulo y que el parche se integre en la rama oficial (el parche podrá ser el suyo o el de otra persona... porque el autor del módulo u otros miembros de la comunidad pueden tener un mejor idea sobre cómo solucionar el error).

    En concreto, cuando corrijo un error en OpenERP, los pasos 1-4 me llevan, en promedio, 2 horas.

  • Poder acceder a los servicios de uno o más integradores competentes y experimentados de OpenERP (no son muchos, consulte la sección dedicada a la elección del integrador) y conocer a las personas adecuadas para ponerse en contacto dentro de la comunidad en función del tema. En lo que respecta a módulos comunitarios, no dude en ponerse en contacto con el autor del módulo o de su empresa.

  • Tener el valor de elegir OpenERP a pesar de todos sus errores... ¡que no siempre es fácil!

Esta realidad acerca de los errores en OpenERP contradice, me parece, el discurso de marketing de la editorial, en el que, a veces, afirma que habrá "1000 pasajes a producción de OpenERP por día" . Si hubiera muchas empresas que realmente utilizan OpenERP en productivo como ERP (excluyo los proyectos framework) ¿cómo es que Anevia, una PYME de 40 personas, tiene tantos errores para corregir en OpenERP 6.1, sabiendo que la mayoría de los errores nunca se habían reportado? No. Esto simplemente significa que el número de empresas que utilizan realmente OpenERP como ERP es modesto, si bien es cierto que este número está creciendo rápidamente.

Ante esta situación, el editor debe poner las correcciones de errores en las ramas estables entre sus prioridades. La teoría es que las correcciones de errores para los clientes con contrato de mantenimiento se fusionarán en ramas estables. Por desgracia, el editor tiene un enorme atraso en el tema, como se ve en la lista de errores reportados por Anevia para OpenERP 6.1 a través del contrato de mantenimiento. Sólo 5 de los 16 errores corregidos, o sea el 31%, se fusionaron en la rama estable al 18 de octubre de 2012 (véanse los casos en rojo en la columna Merge in stable branch). Esto dificulta la estabilización de las muchas ramas estables, ya que en realidad impide la mutualización de los esfuerzos de corrección de errores en la versión estable de OpenERP a nivel mundial. Concretamente, esto significa que la mayoría de los errores solucionados por Anevia no benefician a otras empresas, a menos que se pasen el día en el bug tracker para recuperar parches OpenERP, ¡lo que es obvio que no hacen!

La contabilidad con OpenERP

¿Es posible llevar la contabilidad de su empresa en OpenERP? ¿Con qué resultado? Estas son las preguntas a las que voy a tratar de dar algunas respuestas.

Los dos escenarios

Si le pregunta a una empresa "¿Ustedes usan la contabilidad de OpenERP?" y le contestan que sí... sólo tiene una parte de la respuesta. En efecto, hay que distinguir dos tipos de uso de la contabilidad:

  • Escenario 1: OpenERP se utiliza como un generador de asientos contables, que luego son transferidos a un software de terceros. En OpenERP, cuando se valida una factura de cliente (o una factura de un proveedor), el asiento contable en el diario de ventas (o compras) se genera automáticamente. Por lo tanto, si todas las facturas de clientes y facturas de proveedores se encuentran en OpenERP, entonces los libros de ventas y de compras estarán bien generados. Si todos los pagos de clientes y todos los pagos a proveedores se ingresan el el ERP (lo que es necesario si deseamos que las facturas pagadas sean marcadas como tales en el software), entonces el libro de bancos también será generado. Las empresas que están en el escenario 1 en realidad llevan sus cuentas con software de terceros, que está en lo de su contable. Pero se beneficiarán del uso de OpenERP en el sentido que el ERP genera el registro de las ventas, el de compras y, posiblemente, el diario de bancos de manera que no haya que re-ingresar la información manualmente en el software de contabilidad y simplemente se hará un asiento contable de transferencia entre OpenERP y el software de contabilidad. La referencia contable de la sociedad (es decir, el lugar donde reside toda la contabilidad de la compañía) no se encuentra en OpenERP sino en el software de contabilidad. Este escenario es muy común por la sencilla razón de que la mayoría de las PYMEs tienen sus cuentas mantenidas por contables públicos.

  • Escenario 2: OpenERP es el referente contable de la sociedad es decir, todos los registros contables de la empresa están en OpenERP. Si la nómina o los activos se mantienen en un software de terceros, entonces, los asientos contables generados por dicho software se exportarán hacia OpenERP. El cierre contable anual se llevará a cabo en OpenERP, y la declaración de impuestos se generará a partir de los datos de OpenERP.

Estas dos situaciones son en realidad muy diferentes:

  • El escenario 1 es el más común. Pero esto no es lo que yo llamo mantener su contabilidad en OpenERP . En este escenario, prácticamente ninguna de las funciones de contabilidad OpenERP se usan. Este escenario es el escenario más fácil desde el punto de vista de OpenERP. De hecho, este escenario corresponde a un OpenERP que se usa para la facturación, pero no realmente para la contabilidad. Los principales inconvenientes de este escenario son:

    • Duplicación de la información: la lista de clientes y proveedores se duplica entre los dos programas, por ejemplo.

    • Se debe desarrollar un tipo de conector entre los dos programas para llevar a cabo la transferencia de los asientos contables. Esto, en general, no es tan complicado dado que es muy habitual que los programas de contabilidad se intercambien asientos contables a través de simples archivos CSV. Pero igual es una funcionalidad que hay que desarrollar y cuyo correcto funcionamiento debe verificarse en cada actualización de OpenERP o del software de contabilidad.

    • Debe asegurarse, periódicamente, que no haya discrepancias entre los datos del ERP y el software de contabilidad. Específicamente, deben conciliarse, regularmente, los estados de cuentas de clientes y proveedores entre lo que se encuentra en OpenERP y el software de contabilidad.

  • El escenario 2 es mucho menos común. Este es el más ambicioso en términos de OpenERP. Sólo en este caso, en realidad, se puede decir que se utiliza la contabilidad de OpenERP . Y es sólo en este escenario donde uno se enfrenta con los errores y problemas de la contabilidad de OpenERP. Anevia está en el escenario 2.

Las consecuencias de esta confusión de escenarios son las siguientes:

  • Tendemos a sobreestimar el número de empresas que mantienen su contabilidad en OpenERP realmente, porque se cuentan las empresas en el escenario 1 y en el escenario 2, mientras que sólo deberíamos tomar en cuenta a las que están en el escenario 2.

  • Si elige el escenario 2 para su empresa, asegúrese de que el integrador tiene ya referencias de implementaciones en ese escenario... si no, su integrador no tendrá experiencia real en la contabilidad de OpenERP. Sin embargo, como hay mucha experiencia que debe ser adquirida en cuanto a mantener realmente su contabilidad en OpenERP, si su integrador no la tuviere en el escenario 2, le sugiero que contrate un segundo integrador que sí la tenga (en lo que hace al manejo e implementación del aspecto contable de OpenERP). La mayoría de los integradores franceses tienen sólo la experiencia del escenario 1. Los integradores franceses que en realidad tengan experiencia en el escenario 2 se pueden contar con los dedos de una mano (y de nuevo, ¡no soy capaz de citar 5!).

¿Cómo usar la contabilidad de OpenERP?

En esta sección y las secciones siguientes, voy a discutir el escenario 2, donde OpenERP es la referencia contable de la sociedad.

Tomaré como ejemplo la forma en que Anevia utiliza esta contabilidad de OpenERP, lo que se esquematiza a continuación:

Contabilidad

Si la contabilidad se lleva en OpenERP, ¡esto no quiere decir que OpenERP lo hace todo! La nómina en Anevia se maneja con un software específico (en este caso en una plataforma SaaS paga), y el registro contable de la nómina mensual se exporta del software de nómina como un archivo CSV que luego es importado por OpenERP , utilizando el módulo account_move_csv_import que he desarrollado. Desde OpenERP 6.0, hay un módulo de nómina para OpenERP, llamado hr_payroll , pero estamos sólo al comienzo de un sistema de nómina bajo OpenERP y todavía no conozco de ninguna empresa que lo use en producción.

Mientras tanto, los activos se gestionan también con un software dedicado (en este caso un privativo bajo Windows), y se generan los asientos contables en formato CSV que también OpenERP importa. Desde OpenERP 6.1, el módulo de gestión de activos account_asset módulo se convirtió en oficial. Este módulo había sido escrito a toda prisa por el editor hace mucho tiempo, pero se consideró (con razón) que no estaba listo para convertirse en módulo oficial de módulo (yo lo probé en su momento y tuve varios "accidentes" durante mis pruebas). La comunidad había comenzado a ayudar y a limpiarlo hasta que la editorial se puso a trabajar nuevamente para liberarlo como un módulo oficial en OpenERP 6.1. No lo he probado a fondo, pero después de las presentaciones que me han hecho y las respuestas que he visto, parece que puede usarse en casos simples:

  • Nada de activos complicados con desagregación (hay una noción de activo padre/hijo, pero no estoy seguro de que sea suficiente).

  • Nada de métodos de depreciación complicados: sólo están disponibles los métodos lineales y decrecientes.

  • Hay que estar preparados para lidiar con un activo que se elimina antes que finalice el período de amortización.

La mayoría de las PYMEs (excepto tal vez las industriales) tienen activos fijos simples, sin desagregación y con amortización lineal. Para las PYMEs que caen en este caso y que no cuenten con un software para gestión de activos, la utilización de OpenERP para gestionarlos me parece posible, aunque es probable que se requiera algún tiempo de desarrollo para añadir un sistema de numeración de activos (que no existe en el módulo nativo) y un informe correspondiente al "Plan de amortización", que no es necesariamente fácil de diseñar. En el caso de Anevia, el módulo account_asset sería suficiente, a priori, si se contara con estos dos desarrollos adicionales, pero Anevia ya tiene un software para gestión de activos desde antes de migrar a OpenERP 6.1 (julio de 2012).

En cuanto a la declaración de impuestos, a veces oímos: "No se puede utilizar la contabilidad de OpenERP en Francia porque OpenERP no sabe generar declaraciones de impuestos" . Esto es obviamente falso, y quienes dicen esto no suelen conocer bien los métodos de trabajo y las herramientas habituales de contabilidad. En realidad, la declaración de impuestos se maneja a menudo en un software específico que necesita ser actualizado (léase "volver a pagar" ) cada año debido a que los formularios de impuestos cambian cada año. Los desarrolladores de software de declaraciones de impuestos suelen ser los mismos que editan paquetes de contabilidad fiscal, y se aseguran de dar la ilusión de que los dos programas están integrados... mientras que en realidad son dos productos separados que se comunican a través de un archivo de texto o similar. Los productos de software impositivos son, a priori, siempre usables independientemente del software de contabilidad, sea o no de la misma editorial. Para empezar a usarlo, al software de declaración de impuestos debe exportarse (desde el ERP, por ejemplo) el balance contable del último ejercicio fiscal.

Si desea saber más sobre software de declaraciones de impuestos, que por lo general se trata de software privativo bajo Windows, aquí hay algunos nombres que le ayudarán en su búsqueda:

Los precios comienzan en 300/400 euros (sin IVA) para versiones de una sola empresa, y hasta 600/900 euros (sin IVA) para las versiones para multi-empresa -hasta 10 empresas-. A veces hay que sumar a este precio un plus, en caso que queramos hacer en forma electrónica la declaración de impuestos (el servicio Ciel directDéclaration fiscal de Ciel)... y sí, ¡hay pequeños beneficios en el maravilloso mundo del software privativo!

Tomo estas explicaciones sobre las declaraciones de impuestos para hablar en contra de otra leyenda urbana que regularmente escuchamos: "No tenemos el derecho de utilizar la contabilidad de OpenERP en Francia, ya que OpenERP no está certificado por el DGI (Dirección General de Impuestos) " . Esto es falso. El software de contabilidad no tiene que ser certificado por la DGI para que pueda ser usado en Francia. Usted puede mantener sus cuentas con la herramienta de su elección. Si quiere llevar la contabilidad en un cuaderno cualquiera y no hay necesidad de preguntar si este modelo de cuaderno está homologado por la DGI. Como el software de nómina que no tiene que ser certificado por la URSSAF para ser utilizado en Francia. Esto no significa que usted puede llevar su contabilidad como quiera. Cualquier herramienta que utilice, debe respetar las leyes y los textos oficiales que estipulan cómo debe llevarse la contabilidad. El que sí debe adecuarse efectivamente a las especificaciones de la DGI es el software de declaración de impuestos. Puede incluso haber una certificación formal pero no me he informado sobre ello. Esto es comprensible, ya que la declaración de impuestos es un documento oficial concebido por la DGI, y los paquetes de software que la implementan deben ajustarse íntegramente al formato requerido, así como el formato de la transmisión electrónica para evitar posibles problemas de interoperabilidad con los servidores de la administración tributaria.

En realidad, ¿es realmente usable?

Si, la contabilidad de OpenERP se puede utilizar si se dan varias condiciones:

  • Se debe ser un pragmático de la contabilidad y no un ortodoxo. Algunas maneras de llevar la contabilidad en OpenERP son un tanto inusuales, lo que dará un shock o escandalizará a un ortodoxo, pero será aceptable para un pragmático. Por ejemplo podemos mencionar el hecho de que en un asiento contable generado automáticamente por OpenERP (durante la validación de una factura, por ejemplo), las etiquetas de las líneas contables no son únicas (el texto varía de una línea a la otra): varios contables me dijeron que ésto no se condecía con la práctica corriente, pero no por ello era una inhibición total. Se debe estar dispuesto a aceptar algunas incoherencias, como las columnas de "Débito" y "Crédito" invertidas en el balance analítico, algo que los desarrolladores del editor justifican con argumentos que sólo ellos entienden.

  • Se debe ser bueno en contabilidad. El uso de la contabilidad en OpenERP no es adecuado para los principiantes. El software dedicado a la contabilidad a menudo tiene interfaces más intuitivas y con más seguridad para evitar que se cometan errores. Debe ser capaz de verificar determinadas entradas contables generadas por OpenERP para asegurarse de que estén bien, lo que requiere alguna experiencia en contabilidad. Estoy pensando en usar OpenERP multi-moneda, que no siempre es fácil... pero no creo que sea mucho más fácil en otro software.

  • Se deben utilizar los informes contables de Camptocamp que vienen con el módulo account_financial_report_webkit , aunque no sea un módulo para tener un rendimiento aceptable cuando se edita un libro con mucha información, para tener acceso a todas las opciones necesarias para la edición de informes contables de una manera bien cuidada.

De hecho, su nivel de satisfacción con el uso de la contabilidad en OpenERP dependerá en particular de:

  • ¿Cuál era el software de contabilidad que utilizaba antes? Si usted tenía un software específico de software de contabilidad es decir, que no hacía otra cosa que llevar la contabilidad y que ha sido diseñado exclusivamente para ello, probablemente se sentirá decepcionado, porque no encuentra todos los refinamientos de software dedicado al tema. Si utilizaba la contabilidad de otro ERP, es probable que quede menos decepcionado porque muchos otros ERP no tienen las mejoras encontradas en el software específicamente contable, o sea que no es una carencia única de OpenERP.

  • Volumen mensual de asientos contables. Si se daba que su volumen mensual de asientos contables es importante y que usted no tenía un ERP, entonces tenía una enorme cantidad de entrada manual para los diarios de ventas, de compra y de bancos. OpenERP le ahorrará mucho tiempo, ya que le permite automatizar la generación de estos registros. El ahorro de tiempo que esto significa bien vale la pena como para hacer algunas concesiones en cuanto a ergonomía y refinamientos. Esto también le permitirá relativizar el hecho de que la interfaz de entrada manual de asientos contables en OpenERP no es muy práctica y rápida... pero esto no es sorprendente. Si está usando bien OpenERP, no la usará mucho. De hecho, una vez que el flujo de compra y venta se configuran en OpenERP y se haya implementado la importación de los extractos bancarios, ya no tendrían que quedarle muchos asientos bancarios para hacer a mano excepto las OD (Operaciones Diversas).

Para quien tiene previsto implementar OpenERP en su empresa: consejos y preguntas frecuentes

¿Qué integrador elegir?

Como he indicado en el apartado La experiencia con OpenERP del autor , ahora estoy trabajando en Akretion , que es un integrador de OpenERP, por lo que mi consejo sobre cómo elegir un integrador probablemente no sea completamente objetivo.

Van aquí algunos consejos para elegir bien a su integrador de OpenERP:

  • Si usted necesita OpenERP para un mercado dado y la verticalización ya existe, debe utilizar los servicios de la empresa que mantiene este mercado vertical con OpenERP. ¿Quién mejor que el autor del módulo en sí mismo sería capaz de ayudarle a ponerlo en práctica? El autor del módulo tiene varias ventajas sobre sus competidores:

    • Conoce muy bien el código, por lo que es más rápido que cualquier otro si tiene que depurarlo o cambiarlo.

    • Si necesita nuevos desarrollos en relación con lo que ya existe y que estas necesidades son de carácter genérico, se puede asumir que estas mejoras sean parte de la rama principal del módulo. Parte de ese código no será parte de sus desarrollos específicos, y por lo tanto usted no tendrá que soportar solo el costo de mantenimiento, corrección de errores, la migración a nuevas versiones, etc. Si utiliza a un tercero, puede hacer mejoras en el módulo de código (este es el principio del software libre), pero no puede garantizar que estas mejoras se fusionarán en la rama troncal: eso dependerá de la decisión del encargado del mantenimiento del módulo. Si llegare a la conclusión de que el código no está limpio, el modelo de datos no es bueno, que la ergonomía deja que desear o la evolución no encaja en su visión del módulo, él es libre de negarse a incluir esta mejora en la rama principal del módulo.

  • Para ser un integrador oficial y por lo tanto que se haga referencia en la página de socios del sitio del editor, el integrador debe pagar un monto anual a la editorial, y algunos integradores no quieren entrar en esta lógica y, por lo tanto, no se hace referencia a ellos en el sitio web de la editorial. Los integrador OpenERP pertenecen a una de tres categorías - Ready , Silver y Gold - y la categoría sólo depende del volumen de negocios generado por el integrador y sus clientes a la editorial a través de la venta de contratos de mantenimiento con la editorial o la subcontratación de la misma para desarrollos específicos. Básicamente, un integrador oficial de OpenERP tiene, por defecto, la categoría de Ready, si genera más de x decenas de miles de euros en volumen de negocios anual para la editorial, pasa a Silver , si genera más del doble de esa cantidad, pasa al nivel Gold . Algunos integradores son incluso incorporados directamente en el nivel Silver sobre la base de las previsiones de ingresos, por lo aunque nunca haya hecho ninguna implementación de OpenERP en producción. Por lo tanto es claro que estas tres categorías de ninguna manera reflejan el nivel de contribución del integrador a OpenERP, su participación en la mejora del código del producto, su ayuda en la resolución de errores, o en desarrollo de módulos comunitarios, etc.

  • Para determinar la cuantía de la participación de un integrador de OpenERP en forma de módulos comunitarios, se puede ver la clasificación Top Authors que aparece en la columna izquierda de la página principal del sitio de OpenERP apps . Esta clasificación se genera automáticamente y se basa en los campos de autor de módulos de OpenERP. Por ejemplo, Akretion figura en este momento en la tercera posición de este ranking, por detrás de Camptocamp y Zikzakmedia. En general, puede ser un buen método para darse una idea de un integrador el controlar los módulos con los cuales ha contribuido a OpenERP.

  • Hacer la diferencia entre los integradores de OpenERP bastante especializado en el framework y los que son más especializados en el ERP . De hecho, algunos integradores llevan a cabo esencialmente proyectos OpenERP framework (véase la sección Distinguir los proyectos framework de los proyectos ERP ). Estos se encuentran muy cómodos cuando se trata de un desarrollo de código de aplicación empresarial a partir de las especificaciones del cliente pero saben muy poco sobre el funcionamiento y la complejidad de los módulos funcionales y los módulos comunitarios. Estos integradores especializados en el framework , cuando se les pide llevar a cabo un proyecto de ERP, tienen la desafortunada tendencia, cuando se enfrentan a una limitación de los módulos existentes, o algo que no entienden en los mismos, de volver a codificarlos desde cero. En algunos casos, puede ser una buena solución, pero entonces usted puede encontrarse con un gran desarrollo específico. Y cuyos gastos de mantenimiento serán sólo suyos.

  • Si va a llevar la contabilidad de su empresa con OpenERP, elija un integrador que tenga referencias de compañías que usan contabilidad de OpenERP en el escenario 2

  • Pregúntele que solución complementaria de Inteligencia de Negocio ofrece para los datos de OpenERP datos (por ejemplo, Akretion ofrece Pentaho Business Intelligence para los datos sobre OpenERP, pero hay otras buenas soluciones de BI de código abierto).

  • No dude, si es necesario, de hacer uso como integradores de varias personas que tengan áreas de especialización complementarias. Después de todo lo que he descrito anteriormente, es probable que sea difícil encontrar la joya que combine todas las cualidades necesarias. Es posible tener un integrador principal y uno o más integradores secundarios. Por ejemplo, si el integrador principal no tiene referencias con compañías que usan contabilidad de OpenERP en el escenario 2, es probable que sea mejor utilizar los servicios de otro integrador que tenga la experiencia para ayudarle en aspectos contables de OpenERP (por desgracia, no son muchos). Otro ejemplo: si tiene previsto implementar un módulo comunitario y va a necesitar mejoras o apoyo técnico en este módulo, es probable que sea mejor, en coordinación con el director de su integrador, que se ponga en contacto con la empresa que mantiene el módulo en cuestión para pedirle que haga las mejoras necesarias y exigir, si estas mejoras son genéricas (no específicas de su proyecto), que se integren eventualmente en la rama principal del módulo.

  • Los buenos integradores de OpenERP están muy ocupados y con frecuencia un poco sobre-exigidos. Para trabajar con estos integradores, se debe planificar el futuro y anticiparse a sus necesidades. Un proyecto ERP en una PYME de decenas de personas a menudo dura seis meses o más. Por tanto, es poco probable que un integrador de OpenERP con experiencia pueda comenzar un nuevo proyecto inmediatamente.

La elección de OpenERP, ¿es de por vida?

Muchos tomadores de decisión tienen miedo de elegir un software libre porque piensan que no es una opción permanente. Ellos dicen: "Sí, los ERPs privativos a veces abusan en los precios, pero por lo menos son empresas con fondos, que no van a la quiebra de la noche a la mañana." Mientras que un editor de software libre, que no tiene ingresos por licencias...

Es verdad, es muy raro que el proveedor de ERP privativo con una buena cuota de mercado vaya a la quiebra. De hecho, el factor limitante de la vida de un ERP privativo no está en la bancarrota ¡sino que su editorial sea comprada por otra con más fondos! A menudo, el editor que ha completado la adquisición se apresura a anunciar que el ERP adquirido se seguirá manteniendo, sólo para tranquilizar a los clientes. Pero después de unos pocos años, la lógica económica le hace dejar de forma activa el desarrollo de dos bases de código para dos ERPs que proponen las mismas funciones. A continuación, deja de mantener dos bases de código y alienta (¿obliga?) a los clientes de una de sus plataformas a migrar a la otra. Los clientes con el ERP abandonado deberán, por ende, cambiar y gastar una fortuna para rehacer todos los desarrollos específicos y el trabajo de iimplementación.

Este es por ejemplo el caso de Amaris, un ERP especializado por industria, comprado en 1997 por Cegid. Véase la página de Wikipedia de Cegid , sección La croissance externe comme levier de développement . Cegid ha tomado todo el equipo de desarrolladores de Amaris, con el objetivo de volver a desarrollar la funcionalidad ofrecida por Amaris en el ERP principal de Cegid. Tan pronto como la nueva implementación se completó, fue ofrecida a los clientes de Amaris existentes con un concepto de alta gama con respecto a lo que existía (es decir: precios más altos). Algunos clientes han tenido que asumirlo y han optado por el aumento del costo de las licencias. Otros clientes no querían adoptar las nuevas funciones y prefirieron quedarse con las del código básico de Amaris, que ya no cambia ni cambiará. Esto no es sin problemas, claro. Por ejemplo, el software del cliente Amaris no funciona bajo Windows 7. Son numerosos los ejemplos de este tipo. El que cito es un poco viejo... pero cuando se ve la larga lista de adquisiciones Cegid tal como lo muestra su página de Wikipedia (24 compras), dudamos que el escenario no se haya repetido muchas veces (o que se repita en el futuro). El Grupo Sage, un importante competidor de Cegid también ha realizado varias adquisiciones de ERPs privativos competidores, ver la página de Wikipedia de Sage, en las secciones Principales acquisitions de Sage Group (14 compras) y Acquisitions de Sage en France (12 adquisiciones ).

Con un ERP libre, el editor en realidad puede quebrar o ser comprado. Si el evento se produce, puede ser que la editorial abandone el código. Entonces la comunidad tiene la oportunidad de continuar su labor teniendo en cuenta el mantenimiento y mejora del código de base: esto es una de las grandes ventajas del software abierto o libre cuando se lo compara con el software privativo (también denominado, en otros casos, propietario). Para que esto sea posible, es necesario que la comunidad de desarrolladores sea lo suficientemente numerosa y tener un profundo conocimiento del código, y no sólo de algunas áreas. Claramente podemos decir que este es el caso hoy en día con la comunidad de OpenERP.

¿Ahorraré dinero eligiendo OpenERP en lugar de un ERP privativo?

¡La segunda cuestión crucial! Sin embargo, intentaré dar algunos elementos para que usted pueda elaborar su respuesta.

El perfil ideal de la empresa para la implementación de OpenERP sería:

  • No existe una solución disponible, implantable inmediatamente (out-of-the-box) para la línea de negocios de la empresa, sin necesidad de desarrollos específicos para adecuar los paquetes de software comerciales o ERP privativos a un precio razonable.

  • Ya existe una verticalización madura y bien matenida bajo OpenERP para el tipo de empresa como la suya.

  • La empresa tiene puestos de trabajo Linux o Mac que necesitan tener acceso a los sistemas ERP (son muy pocos los ERP privativos que tienen un sistema Linux o Mac o una interfaz web que se ejecute en algo que no sea Internet Explorer excepto... los ERP privativos que se ofrecen bajo la modalidad de SaaS).

  • La compañía tiene, en sí misma, gente de IT con los conocimientos suficientes como para hacer ciertas adaptaciones sencillas de OpenERP (o sea se pueden encarar desarrollos internos con Python).

Si su empresa tiene una o más de las características enumeradas anteriormente, es probable que usted ahorre dinero eligiendo OpenERP en lugar de un ERP privativo.

En general, en el supuesto de que no exista una solución vertical para su negocio y que haga falta hacer mucho desarrollo para alcanzar su funcionalidad comercial, la elección de OpenERP probablemente no le significará economías en el corto plazo (es decir, el primer año, el de implementación), ya que el dinero ahorrado para comprar licencias de software se invertirá en el desarrollo de módulos de OpenERP para ampliar el alcance funcional nativo del ERP.

Debido a que los ERP privativos se tasan por usuarios (o por usuario concurrente), si la empresa tiene muchos empleados, los ahorros realizados en licencias de software -optando por OpenERP- serán importantes. Pero, en general, cuanto más grande sea la sociedad, mayores y más complejas serán sus necesidades. Esto lleva a asumir, con lógica, que también serán mayores los costos asociados a los desarrollos específicos para complementar las funcionalidades básicas de OpenERP.

Pero en el mediano y largo plazo, OpenERP debería ser más económico. Esta fuente de economía no es específica de OpenERP sino como concepto básico en lo que hace al uso de software libre:

  • Se tiene mucha más libertad en cara al editor que si ha elegido un ERP privativo. El editor puede abusar de su posición dominante como ya se ha visto en el mundo de los ERP privativos (por ejemplo, SAP, consulte este artículo -en francés- u Oracle, consulte este otro artículo en inglés).

  • Uno es libre de suscribir o no el contrato de mantenimiento con la casa de software. A diferencia de un ERP privativo, no se sufrirá un chantaje del tipo, "Si usted no está de acuerdo con nuestro contrato de mantenimiento, entonces no tendrá acceso a las actualizaciones requeridas por los cambios regulatorios" u otro argumento de tipo falaz como, "Imagínese que encuentra un error que impide, de repente, editar sus facturas de clientes..." . Dado que el código fuente está abierto, puede corregir los errores usted mismo o hacer esa rectificación con una persona no relacionada con el editor del software que cuente con el nivel técnico requerido.

  • Usted contará con un ERP abierto y moderno, totalmente controlable a través de XML-RPC y basado en estándares y componentes de código abierto (PostgreSQL, Python,...). Si necesita intercambiar datos con software de terceros, su trabajo se verá facilitado en gran medida así como la reducción de costos. Algunos ERPs privativos cobran bien caro el acceso a sus APIs de desarrollo, lo que encarece, por ejemplo, la creación de un portal para el intercambio de datos con el software de terceros. Tenemos el caso de Salesforce.com, un software de CRM en modo SaaS, que cobra muy caro la posibilidad de acceder a su API: se debe estar en el nivel Enterprise para poder acceder a sus APIs, un nivel que es dos veces más caro que el estándar Professional que es adoptado generalmente por las PYMEs, consulte el aquí el precio de Salesforce .

En todos los casos, excepto para las empresas muy pequeñas con necesidades muy estándar, es aconsejable disponer de un presupuesto importante para la fase de implementación de OpenERP, ya que, como se explica en Los módulos oficiales: el mínimo en cada área, no se hace mucho con el OpenERP estándar (out-of-the-box).

Unas palabras para terminar

Para aquellos que aún no han experimentado con OpenERP y estudian la posibilidad de adoptarlo, espero que, a través de este documento, pueda haber podido darles un matiz diferente al del discurso de marketing idealista que circula. Cuando estaba por hacer la elección sobre un ERP para Anevia estaba buscando este tipo de pruebas, pero son particularmente difíciles de encontrar. Tuve la suerte de haberme relacionado justo en ese momento con Raphaël Valyi, que me dio una visión realista, propia de los ingenieros no comerciales, y me permitió hacer una elección informada lejos de las mentiras y exageraciones comerciales.

En conclusión, y caricaturizando un poco, yo diría que OpenERP es un paraíso para los desarrolladores y un infierno para los expertos funcionales. De hecho, el desarrollador puede aprovechar de un código fuente relativamente simple, legible y conciso y un buen framework basado en herramientas de probada eficacia y calidad (PostgreSQL, Python,...). Por el contrario, el experto funcional que no tiene conocimientos de programación pasará hambre a causa del bajo alcance funcional de OpenERP y se molestará bastante a menudo al encontrarse con problemas de código que no sabrá resolver y siempre estará esperando el trabajo de su colega desarrollador en cuanto a corrección de errores o desarrollo de nuevas características.

También debe tenerse en cuenta que si bien hablo en este artículo de algunos defectos que pueden hacer parecer a OpenERP como preocupante para una persona que tiene la intención de implementarlo como ERP (como lo que he descripto en cuanto a la falta de madurez y ejemplos de errores), no hay que olvidar que los ERPs privativos que se comercializan también tienen sus defectos y puntos negros. La diferencia es que con OpenERP usted tiene la libertad: la libertad de corregir los errores usted mismo (¡increible! ¿no?), la libertad de mejorar los módulos funcionales, la libertad para modificar su comportamiento nativo, la libertad de personalizar su sistema con todo lo que quiera, etc. Esta libertad es valiosa porque permite que usted se apropie de su ERP y retome el control. Pero para eso, hay que prestar mucha atención a los aspectos técnicos y no dudar en colaborar con el editor de OpenERP y la comunidad. Por esta razón, parece preferible tener ya una o más experiencias de implementaciones exitosas con otros paquetes de software libre en su empresa antes de empezar una implementación de OpenERP.

No dude en enviarme sus comentarios por correo electrónico para hacerme saber de su propia experiencia y/o su opinión sobre este documento. Si encuentra un error o falta de ortografía, ¡estoy interesado!



 

OPENTIA I+D+i

Opentia Investigación, Desarrollo e Inversión (e Innovación) 

OPENTIA I+D+i es una innovadora factoría de software dedicada a:

  • Programación OpenObject (Odoo/Tryton)
  • Programación Django y Python
  • Programación Arduino
  • Programación Android e iOS
  • Migración a software libre
  • Virtualización de servidores
  • Clusters Linux
  • Tecnologías libres
  • Seguridad informática
  • Informática forense
  • I+D en tecnologías disruptivas
  • Creación de los nuevos productos y servicios de Opentia

Experiencia

  • OpenERP, gestión empresarial integrada
  • Nuxeo, gestión documental inteligente
  • Zimbra, correo electrónico y colaboración
  • Magento, tienda de comercio electrónico avanzado integrada con OpenERP
  • Prestashop, tienda de comercio electrónico integrada con OpenERP
  • Jasper Reports, informes de negocio personalizados
  • Pentaho, inteligencia de negocio / Business Intelligence
  • Liferay, gestor de contenidos web avanzado en Java
  • Django, desarrollo web avanzado en Python
  • Drupal, gestor de contenidos web en PHP
  • Moodle, gestor de cursos de formación electrónicos
  • LibreOffice, suite ofimática libre alternativa a OpenOffice y Microsoft Office
  • Linux Ubuntu, Debian, RedHat, SuSE, CentOS, Slackware

Comunidades TIC

Participación de opentia en comunidades empresariales y profesionales

 

Patrocinamos

_________________