Archivo de la categoría: Philanthros

No habrá Philanthros 3

Openbravo, Philanthros

El otro día estuve hablando con la gente de Philanthros y les comenté que tienen un problema si pretenden migrar Philanthros a Openbravo 3. Pero antes hagamos un poco de historia.

Philanthros es un proyecto que se encargó a Openbravo, y que hasta donde yo se, fué realizado directamente por ellos sin ningún tercero de por medio. La primera versión se desarrolló para Openbravo 2.40 y el año pasado fué migrada, también por Openbravo, a la versión 2.50.

Philanthros se apoya en varios módulos funcionales pero principalmente en el módulo de proyectos y servicios.

Para la organización que encargó Philanthros es de suma importancia que el ERP sea libre, y que además su implantación sea rápida y económica ya que la idea era promover el producto entre las cientos de fundaciones y organizaciones no gubernamentales que existen.

Ahora lo que ha sucedido es que Openbravo ha decidio cerrar el módulo funcional de proyectos y servicios y distribuirlo en su siguiente versión con su licencia privativa OBCL. A partir de aquí os cuento mi opinión personal.

Me parece una tomadura de pelo y de las gordas haber invertido tanto dinero en un proyecto para que en la siguiente version te cambien la licencia y no puedas migrar, o no quieras, ya que no se dan las condiciones iniciales por las que se eligió este ERP. Las opciones que quedan son o bien migrar Philanthros a la nueva versión utilizando el módulo privativo, que para el caso hubiera dado igual haber empezado directamente con un software privativo, rehacer el proyecto desde 0 desarrollando un módulo de proyectos libre, o quedarse en la versión 2.50 hasta que termine el ciclo de vida.

Vistos los diferentes escenarios parece que los responsables del proyecto no tienen la menor intención de migrar Philanthros a la versión 3. Mi recomendación ha sido que se mantengan en la 2.50 hasta final de soporte y mientras tanto que vayan pensando que harán después.

Cheli

Los problemas de siempre con merges en Openbravo ERP

Openbravo, Philanthros, ,

Ya hablé en su día de porqué el sistema de módulos no aportaba nada nuevo al desarrollo de Openbravo ERP. Entre otras cosas hablaba del problema de los merges y como se trasladaba el problema del core a los módulos. Esta vez me ha tocado sufrirlo en un módulo de Philanthros ERP, pero hagamos un poco de historia.

Philanthros ERP es un desarrollo que se encargó a Openbravo para la versión 2.40. Openbravo también ha sido el encargado de migrarlo a la versión 2.50 y generar las plantillas y módulos actuales. Aunque digo que es Openbravo el que ha desarrollado Philanthros no os penséis que son los encargados del desarrollo del core, ni mucho menos, los encargados fueron los que pertenecen a lo que Openbravo llama Custom. Esto no es más que tener su propio equipo de consultoría y desarrollo dentro de casa, vamos lo mismo que puede hacer cualquier consultoría al uso de las que ya conocemos. De hecho se nota mucho que han sido estos quién han hecho el desarrollo por algunas chapucillas la baja calidad del código en muchos aspectos. Informes mal internacionalizados, estilo de código caótico y que no sigue la guía de estilo de Openbravo, código insertado a pelo (hard coded), etc.

Estos días se ha abierto una incidencia sobre el proceso de completar factura de compras en Philanthros ERP. Al revisar el código me he dado cuenta que en su día se personalizó el pl/sql que se ejecuta en este proceso y se renombró como CUS_INVOICE_POST (el original se llama C_INVOICE_POST), este a su vez se insertó en un módulo llamado sales. Pues bueno, cada vez que se ha ido actualizando el core se ha ido parcheando progresivamente el pl/sql orginal, pero el que se personalizó como es natural no ha estado afectado por estos cambios. ¿Qué he tenido que hacer? pues revisar los 33 parches que se han aplicado al archivo original desde septiembre de 2009, que es cuando se creó este fork por llamarlo de alguna forma, e ir integrándolos en la versión en uso.

No os podéis ni imaginar el trabajo de chinos que ha supuesto realizar todo este trabajo al estar tan desvirtuado el archivo personalizado que desarrolló Openbravo, pero bueno, parece que al final lo he conseguido.

Este es el problema de siempre, que cuando personalizas un archivo del core tienes que integrar manualmente los cambios que se le hagan.

Cheli

Nueva versión de la máquina virtual de Philanthros 2.50MP24

Philanthros, Software Libre, ,

En esta nueva versión se actualiza a MP24 y se actualiza Philanthros ERP a la última versión del trunk. Algunas novedades son:

  • Internacionalización del selector de producto.
  • Se ha corregido el módulo de esquema contable. Ahora carga el esquema contable sectorial para ONGs.
  • También se han corregido los módulos con datos de referencia que no funcionaban como por ejemplo el de impuestos.

Philanthros 2.0 con MP24 Virtualbox.

Cheli

Internacionalización del selector de producto

Módulos de Openbravo ERP, Philanthros, Software Libre

Para Philanthros queríamos tener internacionalizado el nombre de los productos de forma que fuera posible guardar el nombre en cualquier idioma y que este se cargara en función del idioma de la sesión. Para ellos nos apoyamos en la pestaña Traducción que aparece en la ficha de producto en datos maestros, y efectivamente en el campo producto de cualquier ventana este aparecía en el idioma de la sesión siempre que este existiera y en su defecto con el nombre en la ficha principal. El problema vino cuando nos dimos cuenta que en el selector de productos aparecen los productos tal y como los añadimos en la ficha principal, haciendo caso omiso a las traducciones.

Al considerar que esto era un bug de Openbravo ERP abrimos una incidencia en soporte, pero la respuesta fué que la pestaña de traducciones no tiene ese propósito y que por tanto no iban a corregirlo, también nos dijeron que posiblemente para la versión 3.0 lo añadirían.

Como no podíamos esperar y viendo que no era difícil de corregir lo hemos hecho para Philanthros. La instalación es tan sencilla como bajarse el archivo tar.bz2 y md5, comprobar la suma de control y descomprimirlo en srcClient. Luego compilamos con un “ant smartbuild -Dlocal=yes” y listo.

¿Por que en srcClient y no como módulo?. Primero porque hasta donde yo se no puedes crear una clase ya existente en un módulo para que machaque la original del core. Por lo tanto deberías crear una nueva clase y cambiar el mapeo del selector de productos de Openbravo lo cual es un poco engorro. El segundo motivo es porque nosotros lo consideramos un bug del core por lo que utilizar srcClient es una forma elegante de integrar el parche mientras Openbravo no se digne a arreglarlo, cuando esto suceda simplemente borras los archivos de srcClient y actualizas el core.

¿Por qué 4 archivos si sólo se han modificado 2?. Porque si algún día se actualiza el core y modifica alguno de los 2 archivos restantes se podría romper el código. Si se machacan siempre los 4 el selector en principio debería funcionar sin problemas.

¿Cómo funciona?. El selector intenta recuperar el nombre del producto en el idioma de la sesión, si este no existe entonces lista el nombre que aparece en la ficha principal. Lo mismo sucede con el filtro, intenta filtrar por el nombre del producto en el idioma de la sesión, si este no existe entonces filtrará por el nombre de la ficha principal.

 

 

Licencia: GPL v3

Precio: 50€ (Incluye actualizaciones de por vida)

 

Actualización: Se han integrado los cambios hasta 2.50MP34. También se ha refactorizado el código.

Actualización: He añadido la internacionalización del selector ProductComplete y he corregido un problema en el que cuando había un producto seleccionado en el campo producto y se volvía a lanzar el selector, siempre cargaba la clave a buscar en inglés.

Actualización: He añadido también la internacionalización del Multiselector de productos.

 

Cheli