Archivos de la categoría 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