Archivo de la etiqueta: Openbravo

El WebPos privativo de Openbravo

Openbravo tiene una solución de Punto de Venta o POS por sus siglas en ingles, este tipo de software en España se suele conocer como un TPV (Terminal Punto de Venta).

La versión antigua del TPV de Openbravo estaba desarrollada en Java para escritorio y tenía licencia GPL, ahora la nueva versión que utiliza tecnología web tiene la licencia privativa de Openbravo. Hasta ahora no le había hecho mucho caso porque no había tenido la necesidad, pero hace unas semanas me ofrecieron participar en otro proyecto aquí en Ecuador y necesitan el TPV. Lo primero que hice fué releerme la licencia para ver si cabía la posibilidad de poder almenos desarrollar módulos propios bajo una licencia libre de nuestra elección, de hecho es lo que podemos hacer sobre el core de Openbravo ERP gracias a que este está bajo la MPL (Mozilla Public License 1.1). Cuál ha sido mi sorpresa al comprobar que esta licencia especifica que se puede usar, reproducir y modificar el trabajo original, y hacer derivados pero siempre limitado al propósito de tu propio negocio. Por si acaso en otro punto especifican que no se puede redistribuir, sólo en caso de que sea para el propósito del negocio y ponen algunos ejemplos como demos, presentaciones, etc y simpre que tengas bien controlado a quíen se lo cedes.

Una de las premisas que pongo siempre para participar en cualquier proyecto es justamente que todo mi código debe publicarse bajo una licencia libre y con la licencia que tiene el TPV privativo de Openbravo me quedo fuera del proyecto, bueno podré participar en la parte de la trastienda (backoffice) que funciona con Openbravo ERP pero no en la de TPV. En cualquier caso hubiera sido como cuando no existía una implementación de Java libre y usable, tu podías desarrollar tu software en Java y ponerle una licencia libre pero al final tenías que ejecutarlo en la máquina virtual privativa.

 

Es una pena, era un proyecto muy interesante, de hecho aquí en la oficina no paran de preguntarme todos los días si he cambiado de opinión y voy a participar pero ya les he dejado claro que no lo haré mientras Openbravo no cambie su licencia y mi código pueda ser libre. Cómo véis a esto me refería cuando hablaba del caramelo envenenado de Openbravo, mejor prueba que esta no váis a encontrar.

 

Un saludo.

Parche para el issue 24800 aceptado por Openbravo

Openbravo ha aceptado el parche que envié en el issue 24800. No es gran cosa pero nos evita tener que hacer un fork del core. En esta ocasión tenía un problema para hacer una personalización de la contabilidad de la factura de compra, si quería replicar fielmente el proceso original que contabiliza la factura de compra era necesario que dos métodos de la clase DoInvoice fueran public. Una vez replicado el comportamiento original ya podíamos hacer la personalización.

 

Cheli

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

Calidad del Soporte de Openbravo

Llevo unos meses trabajando con Sidesoft en un proyecto bastante grande de implantación de Openbravo ERP en la empresa Flopec (La flota petrolera ecuatoriana). En todo proyecto y más cuando son de esta envergadura surgen problemas, por suerte el core de Openbravo sigue siendo libre (licencia MPL) y siempre que he tenido un problema he podido arreglarlo por mi cuenta y presentarle una solución a mi cliente. El caso de Sidesoft es el ideal ya que la localización ecuatoriana la hemos desarrollado nosotros y está licenciada bajo la GPL3, gracias a ello no necesitamos ningún módulo privativo de Openbravo ERP, esto le posibilita a Sidesoft como implantador el poder ofrecer a sus clientes la posibilidad de no tener  que adquirir la versión profesional, lo cual abarata muchísimo los costes. Esto sería prácticamente imposible en una implantación española ya que la localización es propiedad de Openbravo y la versión completa sólo está disponible en la versión profesional, además de ser privativa.

El problema en realidad no son los costes, el problema es que la versión profesional no nos aporta mucho por regla general (ya tenemos lo que necesitamos en Ecuador) y lo que ofrece es generalmente módulos privativos que por una parte nos limitan (no se pueden redistribuir ni reutilizar siempre que no se pague una versión profesional en cada implantación), no siguen nuestra filosofía de ofrecer software libre lo  que nos quita la ventaja competitiva de cara a nuestros clientes y por otra parte el soporte no suele ayudar mucho, de entrada por mucho que pagues es lento y casi siempre tenemos que desarrollar nosotros mismos una solución de emergencia.

En el caso de Flopec el cliente decidió contratar la versión profesional así que teníamos la posibilidad de acceder al soporte. Voy a exponer uno de los problemas que tuvimos y lo que ha pasado de momento con el soporte.

 

El primer problema es que en la nueva ventana de gestión de cobros y pagos avanzados que surgió como módulo en Openbravo ERP 2.50 y que finalmente sustituyó a la anterior forma de gestionar la cartera en la versión 3.0 tiene un inconveniente que consiste en que no es posible filtrar que usuarios pueden cobrar o pagar según la cuenta financiera. Por ejemplo, si tengo un departamente que gestiona los pagos a un banco y no quiero que este departamente pueda gestionar los cobros y pagos por otro banco no tengo ninguna opción que me permita limitar por usuario/rol quien puede acceder a uno u otro. Después de reunirnos con nuestro equipo funcional diseñamos la forma de hacerlo, básicamente consistía en atar a las cuentas financieras los usuarios/roles que tendrían acceso y luego en la ventana de pagos filtrar según el criterio anterior las opciones disponibles.

Se le envió el desarrollo a un programador junior el cual al terminar su desarrollo vino a consultarme porque sólo le funcionaba en ciertas circunstancias. Su desarrollo era correcto, había utilizado la opción de regla de validación tal y como se le indicó y con eso debería funcionar pero no lo hacía. Las reglas de validación sirven para añadir opciones a la cláusula where del select que rellena un combo, de esta forma pretendíamos que sólo se mostraran las opciones de cuenta financiera disponibles para el usuario. La validación era correcta y funcionaba bien, el problema es que tras ejecutarse la select con la validación y rellenarse el combo se ejecutaba un callout (proceso que se ejecuta en el evento onblur de un campo) de otro campo y este rerellena el combo de nuevo con los valores sin filtrar. En seguida pensé que eso sería lo que estaba sucediendo y me puse a revisar los callouts de las ventanas de cobros/pagos y lo corregí. Mi solución consistía en sacar esa parte del callout y sustituirla por una validación en la definición de la referencia “table” de forma que la regla de validación estandar siguiera funcionando, al final las dos validaciones se añadirían a la cláusula where del select. Esa misma mañana tenía la solución, y por la tarde abrí un issue en Openbravo con el parche. Eso fue el 16-01-2014 y tras semanas sin respuesta, Openbravo si no pagas no suele atender los issues ni aunque le des la solución, decidimos utilizar el soporte de la versión profesional. Abrimos la incidencia en soporte oficial el día 18-02-2014 y lamentablemente a día de hoy, tras 12 días, todavía no tenemos respuesta al margen de la típica de “hemos recibido la incidencia y la vamos a atender”.

En teoría lo único que tenían que hacer era revisar el parche, ver si tiene algún problema que posiblemente sí lo tenga (ellos lo pasan por su departamente de calidad en el que tienen su sistema de integración continua con sus test, etc) y aplicarlo en el core en caso de que todo hubiera ido bien. Todo este proceso no les debería haber tomado más de dos o tres días exagerando para darnos al menos una respuesta.

 

Para nosotros no es un problema porque ya lo tenemos solucionado, entonces ¿por que abrimos un issue y después una incidencia en soporte?. Pues porque nunca es buena idea mantener un fork del core para únicamente tener todos los parches que Openbravo no quiere aplicar en su versión, nos toca hacer el doble de trabajo de mantenimiento del código.

 

Esperemos que esta semana por fin nos contesten a esta y a las otras 2 incidencias que se abrieron el mismo día a las que de momento tampoco han contestado.

 

Actualización 8: Finalmente no entró en el PR14Q2, habrá que esperar 3 meses más para tener la solución de forma oficial, de momento tendremos que parchear el core por nuestra cuenta.

Actualización 7: Hoy 7 de abril, 48 días después de abrir la incidencia han empujado la corrección al control de versiones. A pesar de ello sigue planificada para el PR14Q3, esperemos que les de tiempo a que entre en el PR14Q2.

Actualización 6: Ayer 3 de abril Jon Alegría que es uno de los ingenieros de Openbravo se puso en contacto conmigo para comentarme un posible problema con mi parche. El tema era el siguiente, yo en mi parche saqué del callout la validación y la añadí en un table, el motivo de cambiar el tabledir original por un table fue justamente para poder añadir la validación sin tener que hacerlo desde una regla de validación y así dejar esta opción completamente libre para un desarrollo nuevo. Según me comentó Jon había un pequeño inconveniente, mi parche estaba bien pero la consecuencia de cambiar un tabledir por un table por lo que entiendo es que el tabledir utiliza los identificadores para rellenar el combo y el table utiliza el campo que tú le indiques más el value en caso de que exista y lo marques. En este caso querían que se mantuviera la divisa como valor a rellenar en el combo y al cambiar al table se perdía. Me preguntó que si me parecía bien que el tabledir se mantuviera y que la validación se creara como una regla de validación en lugar de en el table, el inconveniente en este caso es que el desarrollador para añadir una validación debe quitar la regla de validación del core y poner la suya, que casi por obligación debe ser idéndica a la del core y a la que le añades tu parte, técnicamente esto se conoce como hacer un fork de la validación. Los forks hay que intentar evitarlos porque hay que mantenerlos (en cada actualización del core hay que revisar que la validación no ha cambiado y si cambia actualizar tu fork en base a esta) pero bueno, en este caso podría ser una opción válida y le dije que bien, que era una opción y que si preferían hacerlo así adelante. También me dijo que intentarían empujarlo estos días para que con suerte entrara en PRQ2 🙂 . Muchas gracias por todo Jon, eres un crack.

Actualización 5: Ayer 31 de marzo replanificaron la versión en la que tendrán resuelta la incidencia original con la que abrí este apunte, ahora en lugar de liberarla en la actualización PR14Q2 (abril) la tendrán lista en el PR14Q3 (julio). Eso significa que según su planificación la incidencia estará lista y publicada unos 5 meses después de abrirla en soporte oficial, de momento llevan mes y medio.

Actualización 4: Hoy 11 de marzo, 21 días después de abrirla en soporte, han solventado una de las incidencias que básicamente consistía en aplicar un parche que les habíamos pasado para declarar dos métodos de una clase como public, esto era necesario para poder hacer personalizaciones en la contabilidad de la factura. Nos han contestado indicándonos que el parche era perfectamente correcto, que ya han hecho el commit en su mercurial y que aparecerá en una de las próximas actualizaciones. Además se han puesto en contacto con nosotros para aclarar cual era el problema en otra de las incidencias.

Actualización 3: El día 18, un mes después nos contestaron a otra de las incidencias indicándonos que ellos consideraban que ese era el comportamiento correcto y que en tal caso podría ser una nueva característica para la siguiente versión.

Actualización 2: Hoy 10 de marzo, 20 días después de abrirla en soporte, han actualizado la incidencia reasignándole el responsable.

Actualización 1: Hoy 6 de marzo por fin han contestado para disculparse por la demora y decirnos que esperan tener solucionadas las 3 incidencias a finales de semana o a principios de la semana que viene. Justo hoy hace 16 días que se abrieron estas 3 incidencias.

 

Cheli

 

Curso de Desarrollo en Openbravo ERP

He preparado un Curso de desarrollo en Openbravo ERP en formato vídeo que consta del siguiente temario.

Sesión 1

  • Sistema operativo, usuarios y permisos.
  • Instalación desde apt en Ubuntu.
  • Pila de herramientas necesarias para el desarrollo en Openbravo ERP.
  • Postgresql.
  • Apache Tomcat y Apache Httpd.
  • Apache Ant.
  • Sistema de control de versiones.

Sesión 2

  • Principales conceptos funcionales
  • Modelo de la base de datos.

Sesión 3

  • Definición del archivo “Openbravo.properties”.
  • Estructura de los componentes de Openbravo ERP (Arquitectura del sistema).

Sesión 4

  • Modelo de desarrollo (MDD, WAD, DAL, Sqlc, Xmlengine…).

Sesión 5

  • Tareas ant.
  • Estructura del código.
  • Introducción al diccionario de la aplicación.

Sesión 6

  • Introducción a la modularidad.
  • Cambios en el módulo core.

Sesión 7

  • Generación de ventanas con WAD.
  • Distribución del diccionario.
  • Tablas y columnas.
  • Ventanas, solapas y campos.
  • Modificar un campo existente.
  • Eliminar un campo.
  • Añadir un nuevo campo.
  • Añadir una nueva ventana.

Sesión 8

  • Último repaso al diccionario. Elementos del sistema.
  • Triggers.
  • Restricciones.
  • Procedimientos almacenados en pl / sql.
  • Mensajes.

 

A parte de las explicaciones en video se permite realizar hasta 10 preguntas. El curso tiene un precio de 450€, si estás interesado puedes dejar un comentario o ponerte en contacto conmigo a través de correo-e.
Cheli