Archivo de la etiqueta: Openerp

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