OpenERP

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

Módulo product_pricelist_fixed_price en Openerp 6.1

El módulo product_pricelist_fixed_price nos permite indicar un precio fijo a un producto en una regla de tarifa. En realidad este módulo no es necesario ya que puede simularse con las reglas estándar de las tarifas, pero resulta muy útil al simplificar mucho la regla ya que sólo habrá que indicar el precio fijo del producto.

Si utilizamos una regla estándar deberíamos poner:

 

Nuevo precio = precio base * (1 + -1) + precio fijo

 

De esta forma conseguimos que el precio base termine siendo anulado al multiplicarse por 0 y por tanto sólo se sumaría el precio fijo.

 

Pero si instalamos el módulo product_pricelist_fixed_price entonces es mucho más sencillo, en la regla tenemos un campo nuevo en el que indicamos el precio fijo y listo.

 

El problema que tiene este módulo es que ha sido desarrollado haciendo un fork del método price_get_multi de la clase product_pricelist. ¿Qué significa esto?, pues que tenemos uno de los problemas más clásicos en el mundo del software libre, el tener que mantener un fork.

El resultado es que este módulo deja de funcionar correctamente en la versión 6.1 al no existir una rama extra-addons para dicha versión y en consecuencia no haberse adaptado el módulo a la misma. ¿Qué significa no haberse adaptado?, pues principalmente que todos los cambios aplicados en el método price_get_multi en la versión 6.1 de OpenERP no están aplicados en el fork que utiliza el módulo.

 

Si queréis utilizarlo en vuestra versión 6.1 os dejo un parche que soluciona el problema. Para aplicarlo es tan sencillo como copiar el archivo a vuestro directorio addons y luego ejecutar:

 

patch -p0 < product_pricelist_fixed_price.diff

 

Obviamente tendréis que tener instalado el módulo previamente.

 

Nota: Está basado en la versión de la rama extra-6.0, revisión 5869. Si lo aplicáis sobre una revisión posterior en la que se hayan hecho modificaciones al módulo posiblemente tendréis problemas.

 

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