En esta ocasión es una limpieza de código de la función pl/sql C_INVOICE_POST que se ejecuta al completar una factura. Lo curioso es que este bug lleva abierto casi año y medio pero bueno, más vale tarde que nunca.
Cheli
Openbravo aceptó mi parche
No se si os acordáis que hace algunas semanas abrí un par de parches en Openbravo. En el primero sugerí una solución por la simplicidad de la misma, y en el segundo envié el parche. Parece ser que han corregido el primer error, eso si, con matices, y han aceptado mi parche en el segundo.
El primer error consistía en que un campo «booleano» (excluir retenciones en lineas de factura) que en Openbravo se representa como un char(1) en el que únicamente se permiten valores (‘Y’, ‘N’) permitía valor null. El problema es que al utilizar el método «Copiar lineas de», ese campo se ponía a null. Mi sugerencia fué que debía restringirse el valor a (‘Y’, ‘N’) y por tanto ser not null y que al utilizar este método se pusiera a ‘N’ por defecto en lugar de a null. La respuesta de Openbravo ha sido, vale, vamos a ponerlo a ‘N’ en lugar que a null al utilizar este método pero no vamos a añadir una restricción not null porque esto rompería nuestra API (entendiendo como API que un módulo de openbravo que haya puesto a null el valor de este campo incorrectamente igual que lo hacía el «Crear lineas de» se rompería al aplicar el cambio.
En el segundo error envié el parche, y este parece que lo han aceptado. Consistía en que no se calculaban los campos de base imponible para impuestos y impuestos en lineas de factura cuando se utilizaba la función «Crear lineas de». Lo que hice es que se aplicara el mismo cálculo de estos dos campos al ejecutar el proceso «Crear lineas de» que cuando se guardaba una linea de factura.
Estoy contento porque como ya comenté en mi anterior apunte Openbravo no suele aceptar correcciones o parches que no vengan de Partnes (que pagan). Yo estoy en contra de las políticas que ha tomado la emrpesa (empresa con modelo de negocio privativo con licencia del core libre para aparentar) y que creo que la están hundiendo. Pero bueno, esto demuestra que aceptan cosas externas y es de agradecer, ¿quizá se estén dando cuenta de su error?, error desde mi punto de vista claro.
Cheli
Parcheando Openbravo
Aunque ya hemos decidido que todos nuestros nuevos proyecto van a ser sobre OpenERP, aún tengo clientes con Openbravo. En un proyecto que tengo ha surgido un problema derivado de unos bugs del core de Openbravo, por suerte el core sigue siendo libre y he podido parchearlo. El problema es que el proceso «Crear lineas de», que nos permite trasladar lineas desde un pedido o albarán a una factura no calcula ciertas columnas de la linea de factura resultante.
Digo por suerte porque tradicionalmente en el software privativo lo único que puedes hacer es abrir una incidencia y esperar a que los desarrolladores la corrijan, siempre y cuando les convenga corregirla. En el caso de Openbravo ellos por lo general sólo corrigen bugs abiertos por sus clientes de la versión profesional, de hecho yo he abierto muchos bugs, algunos incluso proponiéndo la solución y llevan más de año y medio abiertos.
Como no podía esperar para uno de los problemas lo he corregido (una posible solución), he creado el parche y lo he subido como archivo adjunto de la incidencia. Ya os contaré si lo integran o no en la versión del core.
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.
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.
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.
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.
Ya iremos desgranando más diferencias en otros apuntes.
Nota:
Estoy ofreciendo unos mini cursos de desarrollo en OpenERP por 200€.
Cheli
Openbravo 2.50MP31
Si estás interesado en aplicar la actualización sin perder datos puedes contactar conmigo enviando un correo-e a “cheli en sofre punto es”.
Cheli
¿Openbravo y Red Hat tienen el mismo modelo de negocio? Segunda parte.
La primera vez que me planteé está pregunta Openbravo vendía un producto empaquetado con un contrato de soporte asociado. Desde entonces el panorama ha cambiado mucho y actualmente Openbravo vende un servicio de subscripción por usuario concurrente.
En esencia las diferencias entre Red Hat y Openbravo siguen siendo las mismas, Red hat vende software libre y Openbravo vende software privativo con ciertos elementos libres. Lo que ha cambiado es la estratégia, antes Openbravo vendía un paquete donde venía el sistema operativo y la pila de herramientas necesarias para ejecutar Openbravo, y en dicha pila había elementos privativos (Oracle), además existían ciertos módulos de terceros que también podían serlo. Ahora Openbravo vende una subscripción profesional en la que se cobra por usuario concurrente.
La nueva estrategia ha consistido en reducir el core que es libre y migrar ciertas funcionalidades a módulos privativos o módulos sólo disponibles en la versión profesional, al final el resultado ha sido que tenemos un core cada vez más limitado bajo una licencia MPL y una serie de módulos en su gran mayoría privativos. Openbravo se basa en la idea de tener este core bajo MPL para poder decir que Openbravo ERP es libre.
En lo que Openbravo si ha copiado a Red Hat es en poner limitaciones artificiales a sus productos para delimitar sus servicios profesionales. En el caso de Red Hat podría ser el número de sockets y en el caso de Openbravo serían los usuarios concurrente. También le ha copiado en sacar una versión de pruebas para 30 días, dos ideas en las que yo no estoy muy de acuerdo.
En cualquier caso el modelo de negocio de Red Hat es un módelo válido, ellos venden software libre y ofrecen servicios sobre sus productos libres. Sin embargo el modelo de Openbravo es vender software privativo enmascarándolo en un core cada vez menos funcional al que licencia bajo la MPL.
Cheli
¿Trial en una aplicación libre?
Openbravo se ha empeñado en seguir con sus trampas, yo nunca había visto que una aplicación que dice ser libre, ya sabemos que Openbravo ERP no lo es, publique un trial. Pues bueno, Openbravo ha enviado por correo-e publicidad para que pidas el trial para 30 días de su versión profesional. Siguen sin enterarse de nada, continuan utilizando tácticas comerciales del software privativo pretendiendo decir que venden software libre.
Cheli
¡Ea ea ea, la gente se cabrea! con Openbravo
La nueva trampa de Openbravo 3.0
Como ya comenté en su día Openbravo capó la versión comunidad, lo pudimos ver en su día en esta entrada del wiki. Ahora dan una nueva vuelta de tuerca, desde hace no se cuanto tiempo han cambiado el wiki y dicen que sí, está capada pero que la licencia de los módulos de MRP, Producción y Proyectos son libres pero sólo disponibles en versión profesional. Esto me plantea un dilema legal pero como no soy abogado la verdad es que no se la respuesta, la cuestión es que ahora hasta donde he podido ver de la versión 3 Openbravo publica y por tanto distribuye la versión comunidad con el código fuente de estos módulos ya que por ejemplo aparecen las tablas en la base de datos y la definición de tablas, columnas, ventanas, pestañas y campos en el diccionario. Según la primera cláusula de cualquier licencia de software libre, y un software MPL lo es, es que puedes entonces utilizarlo para cualquier propósito pero Openbravo nos dice que sólo puedes utilizarlo si contratas y pagas la versión profesional. Me imagino que los abogados de Openbravo habrán revisado esto y como yo no tengo los conocimientos necesarios para estos temas no se si incumplen o no su propia licencia.
Lo que esta claro es que como también dije en su día Openbravo es una empresa que desarrolla y vende software privativo, ese es su modelo de negocio, pero que pretende engañar a sus clientes diciéndoles que les vende software libre para luego no tener la obligación de respetar las cuatro libertades básicas. Si quiere vender software libre que sean claros y hagan como hacemos todos los que nos dedicamos a esto, que es vender servicios y desarrollo de productos pero siempre respetando su licencia. Y si lo que quieren hacer, que es justamente lo que están haciendo es vender software privativo pues que lo digan también, pero que no engañen a la gente.
Cheli
Openbravo sigue perdiendo momento
Después de comprobar que la versión 3.0 salió tal y como nos habían anunciado más capada que nunca y más privativa que nunca ha llegado el momento de migrar a OpenErp. De momento seguiremos desarrollando para la versión 2.50 ya que tenemos varios clientes en esta versión, pero los nuevos proyectos queremos realizarlos ya sobre OpenErp, antes de eso tendremos que formarnos bien. Así que, manos a la obra.
Cheli