Openbravo ERP vs Odoo, Actualizaciones

Estaba viendo los vídeos de las Jornadas de Odoo (Antiguo OpenERP) en Granada y en algún momento tocaron el tema de las actualizaciones, lo cual me ha recordado que tenía este punto pendiente en la comparativa entre Openbravo vs OpenERP 2014.

 

A día de hoy hay una diferencia fundamental en cuanto actualizaciones entre estos dos sistemas, Openbravo desde la versión 3.0 utiliza una especie de rolling release y Odoo sigue sacando una versión completamente nueva y disruptiva respecto a la anterior más o menos cada año y medio. En Openbravo la situación era similar a la de Odoo hasta la versión 3.0 pero a partir de ahí armaron una buena base y decidieron que en lugar de planificar grandes cambios a medio o largo plazo iban a ir mejorando paulatinamente esta versión y empezaron a sacar una nueva revisión cada mes con corrección de errores y si se daba el caso con algunas nuevas funcionalidades. Digo empezaron porque desde el segundo trimestre de este año ha cambiado la política y, aunque sigue siendo de rolling release,  han decidido actualizar el mapa de ruta y ahora las publicaciones pasan a ser trimestrales.

En Odoo hasta donde yo se no ha cambiado sustancialmente el proceso de actualización. Saben que tienen un problema porque tener versiones completamente diferentes y en las que se rediseña y reescribe parte del código de módulos enteros crea graves problemas de compatibilidad ya que rompe mucho del código propio que escriben los implantadores. Una de las soluciones propuestas es OCA, ¿y qué es OCA? es una asociación para que los proyectos de la comunidad estén por una parte mejor integrados con el núcleo del producto y por otra parte para repartir los esfuerzo tanto económicos como de talento entre los diferentes socios interesados, con esto consiguen convertir módulos que inicialmente serían propios de un implantador en semioficiales y como consecuencias tanto su diseño como código estarían auspiciados por la propia Odoo y soportados en el proceso de actualización. Como veis en realidad no solventa el problema, lo suaviza un poco.

 

Vayamos a la parte técnica, Openbravo utiliza una librería llamada dbsourcemanager que consigue manejar los cambios en cuanto a diccionario y estructura de la base de datos, y la realidad es que a día de hoy esta herramienta funciona realmente bien. Si una actualización está bien diseñada y testeada el proceso de actualización es prácticamente transparente y de hecho nosotros siempre tenemos a todos nuestros clientes actualizados a la última versión sin grandes problemas.

En cuanto a Odoo, el diseño y estructura de la base de datos se maneja a través del ORM, esto significa que si cambiamos el modelo siempre lo tendremos que hacer mediante el ORM. La consecuencia es que no puedes aplicar la nueva estructura de la base de datos mediante este proceso cuando hay muchos cambios porque se empieza a romper todo, primero porque los módulos empiezan a ser incompatibles con el núcleo del sistema, segundo porque el ORM no es muy fino en como realizar esta actualización sin romper entre otras cosas la integridad referencial, etc. Lo que propone entonces Odoo es que contrates un servicio que consiste en que le envías tu base de datos, le dices de que versión a que versión quieres actualizar y ellos te migran la base de datos. Una vez tienes la nueva base de datos la tienes que probar y si encuentras errores vuelves a enviar repitiendo el proceso de forma iterativa hasta que la nueva base está depurada. Al parecer ya funciona también una herramienta de la comunidad que realiza la misma función, pero siempre tiene que tener mucho cuidado con los módulos no oficiales ya que para estos no suelen existir los scripts.

 

A parte del problema técnico tenemos otro problema que es el cambio y adaptación funcional al nuevo sistema. En Openbravo no hay trauma, como he dicho ellos utilizan la base de la 3.0 y la han ido mejorando con lo que no han habido grandes cambios funcionales y los que hay no requieren un gran esfuerzo en cuanto a formación para adaptarse. En cuanto a Odoo si lo ha habido, empezando porque por ejemplo en la versión 7.0 desapareció el cliente de escritorio y únicamente podías utilizar el web o que el cliente web se ha reescrito varias veces. La buena noticia es que desde la versión 6.1 el cliente web aunque ha sufrido bastantes cambios no han sido tan drásticos como los anteriores. Otra cosa que ha pasado es que han refactorizado algunos módulos y rediseñado otros a nivel funcional con la consecuencia que muchas cosas funcionan de forma completamente diferente o que para acceder a una opción seguramente ahora esté en otro sitio diferente. Desde mi punto de vista Odoo en este sentido ha metido bastante la pata y sigue sin haber una solución definitiva ya que su proceso de desarrollo al parecer va a seguir siendo el mismo.

 

En resumen, en cuanto a este apartado desde mi punto de vista Openbravo ERP lo tiene bastante mejor solventado que Odoo, ahora falta esperar como evoluciona OCA, que va a aportar realmente a este proceso y qué va a hacer Odoo a partir de la versión 8.0, si va a empezar a estabilizar el sistema base o va a seguir con sus ciclos tan agresivos de lanzar nuevas versiones disruptivas respecto a la anterior.

 

Cheli

Openbravo ERP vs OpenERP, lo que dice Google

Hace dos años y medio ya hablamos de las tendencias de google con respecto a Openbravo vs OpenERP, entonces ya adivinamos el crecimiento que estaba teniendo OpenERP y como Openbravo ERP empezaba a caer irremediablemente. Me he puesto a revisar esta tendencia y este ha sido el resultado:

 

Openbravo vs OpenERP

Como véis la tendencia se ha acentuado aún más, curiosamente el punto de inflexión ocurrió justo en el momento que Openbravo empezó a cerrar su código. Por lo que parece la gente prefiere lo libre a lo privativo.

Un saludo.

 

 

Openbravo ERP vs OpenERP, Licencia

Este es el primero de una serie de artículos en los que voy a explicar el estado actual desde mi conocimiento de las diferencias entre Openbravo ERP y OpenERP. Si queréis ver todos los artículos podéis utilizar la etiqueta Openbravo vs Openerp 2014.

 

En cuanto a licencia nada nuevo bajo el sol, Openbravo sigue tienendo una licencia libre MPL (Mozilla Public License 1.1) para el core y una licencia privativa para la gran mayoría de módulos adicionales, entre ellos algunos de los que la propia Openbravo distribuye en su versión profesional. Como ya dije en su día Openbravo es una empresa de software privativo que dice que hace un ERP libre y eso no ha cambiado. Lo que pretende Openbravo es que la comunidad aporte código y que ellos y sus partners se aprovechen de este código mientras lo único que aportan por su parte como software libre es un core capado que generalmente no es suficiente para una implantación.

 

OpenERP por su parte tiene una licencia AGPL v3 y sólo relicencian con una licencia privativa en ciertas circunstancias muy particulares. Esto quiere decir que tanto el core de producto como todos los módulos que podamos encontrar, generalmente a través de launchpad, son libres. Al utilizar esta licencia OpenERP asegura que cualquier derivado de su producto siga siendo libre y además público.

 

Cheli

Curso de Desarrollo en OpenERP

Estoy ofreciendo cursos de desarrollo en OpenERP. He empezado con una modalidad de mini cursos con el siguiente temario:

 

Sesion 1: Introducción a OpenERP

  • Arquitectura de OpenERP.
  • MVC de OpenERP.
  • Integración de Módulos.
  • Extendiendo el Modelo (herencia).
  • Extendiendo la Vista (herencia).
  • Definición de un módulo.
  • Objetos, atributos y métodos.
    •  ORM
  • Vistas.

 

Sesion 2: Ventanas 1

  • Extender una ventana.
  • Tipos básicos.
    • Añadir un campo.
    • Eliminar un campo.
    • Modificar un campo.
  • Tipos relacionales.
  • Crear una ventana nueva.
  • Internacionalización.

 

Sesion 3: Ventanas 2

  • Más tipos relacionales.
  • Gestión del modelo mediante métodos del ORM
    • Crear (create).
    • Borrar (unlink).
    • Modificar (write).
    • Recuperar (browse).
  • Disparadores.

El precio de cada sesión es de 110€, haciendo un total de 330€ si se quiere realizar el curso entero. El curso consta de varios vídeos explicativos en los que se proponen una serie de ejercicios prácticos. Cada vez que se completa una sesión se os envían las diapositivas utilizadas en las explicaciones y el código de las soluciones a los ejercicios. Adicionalmente se pueden realizar preguntas sobre las explicaciones que se resolverán por correo-e o por conferencia.

 

Cheli

OpenERP, módulo «Purchase Quotation from Sales Quotation»

Antes de explicar qué hace este módulo y porqué lo hemos necesitado os tengo que explicar el problema que intenta resolver y concretamente el problema que nosotros teníamos.

Mi último proyecto es una empresa subsidiaria de otra y realmente lo que hace es vender en Europa el producto. Por tanto necesitaba que cada vez que se realizara un pedido de venta se generara un pedido de compra a la empresa raiz. Esto en OpenERP es sencillo, simplemente debes parametrizar el producto de forma correcta y si además utilizas el módulo mrp_jit entonces ese pedido de compras se genera automáticamente. Entonces ¿cuál es el problema?, pues que en realidad lo que hace OpenERP es generar necesidades de material por producto, según la parametrización le podemos indicar que el modo de abastecimiento es compra y por tanto genera el pedido, pero lo que hará es generar un pedido por cada necesidad de material y consecuentemente si nuestro pedido tenía 20 lineas con 20 productos diferentes entonces generará 20 necesidades de material y sus 20 pedidos diferentes, uno por cada producto.  Esto es un problema importante, ya que luego hay que  fusionar los pedidos y es un follón.

 

Me puse a buscar módulos que solucionaran el problema, que fueran capaces de generar un único pedido de compra por cada pedido de venta, pero todos añadían funcionalidad como diferentes esquemas de abastecimiento pero siempre basándose en la idea que se debe generar necesidades de material y estas a su vez dispararán la generación de pedidos de compra, por lo que no solucionábamos el problema. Entonces encontré un módulo que hacía justo lo que necesitaba, el módulo en cuestión se llama «pq_from_so» aunque en la descripción aparece como «Purchase Quotation from Sales Quotation«. Este módulo añade un botón en el presupuesto de venta para que puedas generar un presupuesto de compra con las mismas lineas.

 

Cuando creía que lo tenía todo solucionado apareció un problema, este módulo no tiene en cuenta los impuestos de los productos para generar las lineas de pedido de compra. Esto no sería un problema en sí si no fuera porque esos impuestos luego se arrastran a la factura. Otro problema es que necesitábamos que tuviera en cuenta los impuestos según la posición fiscal del proveedor, así que me puse manos a la obra y generé el parche para corregirlo.

 

Aquí os dejo el parche.

 

diff

 

Para aplicarlo previamente deberéis tener instalado el módulo. La forma de aplicarlo es tan sencilla como copiarlo al directorio donde habéis instalado el módulo, típicamente el directorio addons, y ejecutar

 

patch -p0 < pq_from_so.diff

 

en dicho directorio.

 

Actualización 29-08-2012:

Se ha corregido un problema cuando no hay producto en la línea o el producto no tiene proveedor. Cuando esto suceda ya no se producirá el error pero la línea tampoco se añadirá al pedido de compra.

 

Cheli

 

Diferencias técnicas entre OpenERP y Openbravo 2 (MVC)

Ya hablamos anteriormente sobre las diferencias en arquitectura entre Openbravo ERP y OpenERP. Hoy vamos a hablar de sus  soluciones en cuanto al patrón MVC (Modelo, vista y controlador).

 

El MVC de Openbravo podría resumirse en el siguiente esquema.

 

MVC de Openbravo ERP

 

En el modelo tenemos por un lado la base de datos a la que podremos acceder por sqlc. Sqlc es una herramienta que nos genera clases java en base a una definición en xml de sentencias sql, de este modo podemos tener una clase en la que cada método nos permitirá ejecutar una sentencia sql diferente. Esta es la herramienta de acceso a datos y persistencia utilizada historicamente en Openbravo. A partir de la versión 2.50 se añadió una capa DAL (Data Access Layer) implementada con Hibernate.

Respecto al controlador, esta es quizá la parte más oscura de Openbravo ya que la lógica de negocio se reparte entre código Java y código Pl/sql en base de datos lo que complica bastante tanto el desarrollo como la independencia del SGBD (Sistema de gestión de bases de datos), esto también provoca que la base de datos se vuelva muy lenta.

En cuanto a código Java existe principalmente una clase de la que herada cualquier otro servlet, luego tendremos nuestras propias clases y métodos en java y por último, y ya hablando de código en base de datos, tendremos una serie de triggers, funciones y restricciones.

 

La vista está compusta por código estático en html, css y javascript. Además dipsonemos de una herramienta llamada xmlengine que viene a ser un rellenador de plantillas. Por ejemplo, si tenemos un html con una tabla y queremos rellenar esa tabla con datos xmlengine nos puede ser útil.

 

Si estamos desarrollando una ventana mediante el modelo MDD prácticamente no nos enteraremos de que tecnologías se están utilizando por debajo. En realidad lo que se hace es leer el diccionario y generar código mediante la herramienta WAD, esta internamente genera código para sqlc, DAL, los html, css, javascript, los servlet java, xmlengine, etc. El problema es que hay muchas cosas que no se pueden desarrollar mediante MDD, en esos casos tendremos que picar a mano nosotros todo este código.

 

El MVC de OpenERP es mucho más sencillo.

 

MVC de OpenERP

Unas de las principales diferencias entre OpenERP y Openbravo ERP es que en OpenERP no hay código en base de datos, la base de datos está completamente limpia y eso tiene muchas ventajas. El modelo está compuesto por una base de datos pero lo que nosotros veremos a nivel de desarrollo será únicamente el ORM, de hecho hasta la fecha no he necesita tocar nada de la base de datos, ni siquiera añadir una columna o una restricción. ¿Y como es posible esto?, pues porque cualquier clase en OpenERP deriva de la clase osv.osv y está implementa el ORM. A este puedes indicarle los atributos que necesitas, de que tipo son y él se encargará del mapeo haciendo totalmente transparente el acceso a datos.

La parte del controlador es completamente código python. Por un lado tendremos las clases que dan sustento a nuestras ventanas y si queremos extenderlas por ejemplo añadiendo o sobreescribiendo métodos es muy sencillo, simplemente hay que utilizar herencia. Además nadie nos impide crearnos nuestras propias clases para hacer lo que se nos ocurra.

En cuanto a la vista esta se define en xml. Hay que recordar que en la arquitectura de OpenERP teníamos un servidor al que nos conectábamos por xml-rcp/net-rpc, esto quiere decir que el servidor le envía los datos al cliente en xml y este será el encargado de construir la interfaz en base a esos datos. Por tanto lo único que tenemos que hacer es definir esos xml que representan a la interfaz, muy sencillo todo.

Como cualquier aplicación software tanto Openbravo ERP como OpenERP tienen sus ventajas e inconvenientes, las dos plataformas de desarrollo son muy potentes pero desde mi punto de vista OpenERP tiene una arquitectura mucho mejor definida.

Nota:

Estoy ofreciendo unos mini cursos de desarrollo en OpenERP por 200€.

 

Cheli

Localización española para OpenERP 6.1

Como os prometí en este apunte os voy a explicar la instalación de los módulos de la localización para España de OpenERP 6.1. Lo primero que tenemos que hacer es obtener los módulos desde el repositorio de bazaar en Launchpad.

 

bzr branch lp:openerp-spain/6.1 openerp-spain61

 

Esta orden nos creará el directorio openerp-spain61 con los módulos. Una vez tenemos los módulos tendremos que parar el servidor y copiarlos al directorio addons del mismo.

 

service openerp stop

cp -R openerp-spain61 /usr/lib/pymodules/python2.7/openerp/addons

 

Si no sabemos cual es el directorio de addons de nuestro servidor lo podremos averiguar mirando el registro de arranque.

 

cat /var/log/openerp-server.log | grep "addons paths"

 

En este punto tenemos dos posibilidades, la primera consiste en arrancar el servidor pasándole como parámetro la opción --update=módulos, donde módulos son los módulos a actualizar separados por comas. Nosotros le pasaremos los módulos de la localización. La segunda consiste en entrar en OpenERP y pinchar en la opción «Settings», aquí pinchar en «Define default users preferences» y en la opción «Interface» elegir extended. Ahora ya podremos seleccionar la entrada del menú «Settings->Modules->Update Modules List».

Tanto si hemos elegido la primera como la segunda posibilidad ya podremos ver nuestros módulos, sólo queda instalarlos y listo.

 

Nota:

Estoy ofreciendo unos mini cursos de desarrollo en OpenERP por 200€.

 

Cheli

Instalación de OpenERP 6.1 en Debian / Ubuntu

El proceso para instalar OpenERP 7.0 es exáctamente el mismo.

La forma más sencilla de instalar OpenERP 6.1 en Debian / Ubuntu es a través del paquete disponible en la página de OpenERP. Lo primero que tenemos que hacer es descargarnos el paquete.

Para la versión 6.1:

wget http://nightly.openerp.com/6.1/nightly/deb/openerp_6.1-latest-1_all.deb

Para la versión 7.0:

wget http://nightly.openerp.com/7.0/nightly/deb/openerp_7.0-latest-1_all.deb

Después como root lo instalamos.

dpkg -i paquete.deb

Si nos falta alguna dependencia fallará. Lo más seguro es que nos sugiera un «apt-get -f install» para solucionarlo, si es así lo ejecutamos y seguimos. El problema es que el paquete deb no tiene como dependencia el servidor de Postgresql ya que este podría encontrarse en otra máquina. Nosotros lo vamos a instalar en la misma máquina que el servidor de OpenERP.

apt-get install postgresql-9.1

Nota: En mi caso el paquete se llama postgresql-9.1 pero esto puede variar ligeramente en vuestra distribución.

Tendremos que configurar postgresql para que autentique correctamente en local, además tendremos que crear un usuario para nuestra base de datos. Editamos el archivos /etc/postgresql/9.1/main/pg_hba.conf y cambiamos la linea:

local   all             all                                     peer

por

local   all             all                                     md5

En vuestro caso la linea puede ser ligeramente diferente. Después tendremos que reiniciar el servidor.

service postgresql restart

Añadimos el nuevo usuario a la base de datos. Primero nos autenticamos como usuario postgres (administrador de Postgresql por defecto).

su - postgres

Y luego creamos el usuario:

createuser --createdb --username postgres --no-createrole --pwprompt cheli

Le damos una contraseña, en mi caso cheli, y le indicamos que si sea super usuario.

Por último tenemos que editar el archivo /etc/openerp/openerp-server.conf y dejarlo así:

[options]
; This is the password that allows database operations:
admin_passwd = admin
db_host = False
db_port = False
db_user = cheli
db_password = cheli

Al reiniciar el servidor de OpenERP este ya podrá conectarse a la base de datos.

service openerp restart

Una vez haya arrancado el servidor tenemos que crear la base de datos, esta tarea la realizaremos desde el cliente web. Abrimos la siguiente url desde el navegador:

http://localhost:8069/web/webclient/home

Y pinchamos en el enlace «Manage Databases». En la nueva ventana pinchamos en «create» y rellenamos los campos:

admin (por defecto a admin, tal y como lo pusimos en el archivo de configuración)

cheli (le damos un nombre, en mi caso cheli)

English (US) (en mi caso English US)

Admin password: cheli (le damos una contraseña de administración)

cheli (repetimos la contraseña)

Si queremos que se cargue con datos de ejemplo entonces seleccionaremos la opción Load Demostration data.

Cuando se termine de crear la base de datos se autenticará automáticamente y ya estaremos en nuestro OpenERP completamente limpio. Las siguientes veces tendremos que autenticarnos con usuario y contraseña admin / cheli.

En el siguiente apunte os explicaré como cargar la localización para España, así que atentos.

Nota:

Estoy ofreciendo unos mini cursos de desarrollo en OpenERP gratuitos.

Cheli

Diferencias técnicas entre OpenERP y Openbravo 1

A primera vista hay dos grandes diferencias técnicas entre OpenERP y Openbravo, la primera es la arquitectura. Mientras openbravo está desarrollado en Java JEE y se ejecuta sobre Tomcat (es el recomendado por Openbravo) y por tanto su arquitectura se podría resumir en este gráfico.

 

Arquitectura Openbravo

 

OpenERP tiene una arquitectura en la que separa claramente las diferentes capas, por una lado tiene el servidor que maneja la lógica, al igual que Openbravo tiene la base de datos, y en un tercer nivel tenemos las diferentes vistas. En este caso se ha utilizado Python para desarrollar las diferentes capas.

 

Arquitectura OpenERP

 

 

Las desventaja que tiene Openbravo en cuanto a arquitectura es que su interfaz (vista) está centrada en el web. La única forma de conseguir una interfaz diferente a una básada en tecnología web es utilizandos servicios web, este es el caso por ejemplo del TPV (Terminal Punto de Venta), es la misma tecnología que podríamos utilizar para integrar cualquier otro sistema externo. En el caso de OpenERP el acceso al servidor está estandarizado, esto significa que podemos desarrollar el cliente que queramos pero todos accederán de forma estándar al servidor.

 

La segunda gran diferencia es el hecho de que Openbravo utilice mucho código en base de datos en forma de funciones (procedimentos almacenados pl /sql), triggers y restricciones. En el patrón MVC (Modelo Vista Controlador) de Openbravo se desplaza gran parte de la lógica (Controlador) a la capa de de acceso a datos (Modelo), esto genera varios problemas.

 

Postgresql Openbravo

Por una parte se dispersa la lógica entre el controlador (código java en el contenedor de servlets Tomcat) y el Modelo (código pl /sql, trigger y restricciones en la base de datos). Otro problema es que la independencia de base de datos queda casi descartada, además el matenimiento del código de base de datos se complica hasta tal punto que migrar de una versión del gestor de base de datos a la siguiente puede resultar un problema. Por ejemplo, Openbravo 2.50 no soporta oficialmente postgresql 9.1, que es la última versión.

Openbravo intenta solventar parcialmente este inconveniente con DBSorucesmanagement, que permite estandarizar de forma más o menos elegante el código en base de datos y exportarlo a xml. Hasta el momento soportan Postgresql y Oracle y aunque no es perfecto, no suelen haber muchos problemas graves, y los que hay suelen solucionarse sin excesivas complicaciones, eso si, hay que generar el código pensando en esta compatibilidad.

 

En OpenERP no existe código en base de datos, por lo que la independencia de base de datos es mucho más fácil de conseguir. Además en OpenERP actualizar de una versión de la base de datos a la siguiente es casi inmediato. Pero entonces ¿dónde está el código?, pues es sencilo, la lógica está toda en la capa de controlador.

 

Postgresql OpenERP

Ya iremos desgranando más diferencias en otros apuntes.

Nota:

Estoy ofreciendo unos mini cursos de desarrollo en OpenERP por 200€.

 

Cheli