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
Hombre, has vuelto a Openbravo ? Me extraña sobremanera verte trabajando sobre este proyecto al cual tanto has criticado.
Qué ha pasado con tu experiencia con OpenERP? Hace mucho que no hablas de este proyecto en tu blog. No ha ido bien ?
Jejejeje, bueno uno a veces tiene oportunidades de participar en proyectos interesantes, la única condición que pongo es que todo el código que escribo debe ser libre. Has dado en el clavo en una cosa, hace tiempo que no escribo sobre Openbravo ni OpenERP. He decidido escribir una serie de artículos puestos al día de qué cosas buenas y malas tiene cada uno desde mi punto de vista, que como ser humano siempre puede estar equivocado claro, así que los comentarios son bienvenidos. Ahí ya te cuento.