Internacionalización del selector de producto

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

El caramelo envenenado de Openbravo ERP

Cada día que pasa los acontecimientos se van sucediendo. No se desde cuando Openbravo viene utilizando la licencia OBCL, pero lo que si he podido observar es que cada vez más módulos de los que ofrecen directamente en su versión profesional y cuyo autor es la propia Openbravo están licenciados con esta licencia, lo que al final me hace preguntarme ¿es Openbravo ERP realmente libre?.

La pregunta viene porque aunque el módulo core está licenciado con la MPL (OBPL) y por tanto con rigor deberíamos decir que Openbravo ERP si es libre,  OBCL es claramente una licencia no libre. Si miramos la retahíla de módulos con esta licencia sin los cuales la mayoría de proyectos no pueden implementarse entonces podríamos decir que el core es simplemente un caramelo envenenado para poder proclamar que son una empresa de Software Libre (u Open Source como le gusta llamarlo a ellos), pero que en realidad no lo son.

Algunos ejemplos con licencia OBCL:

  • Cuaderno 43
  • Spain AEAT Modelo 347
  • Tax Report: Modelo 303 (Spain)
  • Modelo 349
  • Advanced Payments
  • Apparel Product Technical Specification
  • Facturación Electrónica – Facturae 3.1
  • Camerfactura
  • Condiciones de pago
  • Easy Extensible Attributes
  • Formas de pago
  • Gross Amounts in Invoices and Orders
  • Initial Data Load
  • Incoterms
  • Inter-company Documents
  • Intrastat
  • Invoices Register Book
  • Mass Advanced Paymen

Y no sigo porque la lista sería interminable. Si a esto le sumamos que hace poco anunciaron que iban a eliminar módulos funcionales de la versión comunidad pues creo que está claro hacía donde tira Openbravo con su estrategia comercial. ¿Qué licencia le pondrán finalmente a estos módulos? ¿hacemos apuestas?

Cheli

Cojer

Estaba leyendo un pl/sql que desarrolló un programador de Openbravo para un proyecto en el que estoy colaborando y de repente ha aparecido esto.

BEGIN

v_client_id         := '1000002';

v_ad_org_id         := '1000014';

v_doctype_id        := '10001278'; -- Temporalmente pongo a XXXX

v_doctype_target_id := '10001278';

FOR Cur_Doc_V       IN

(SELECT DISTINCT (documentno) FROM i_cus_fp_invoice

)

LOOP

BEGIN

-- Cojemos de la primera línea los datos de la cabecera

SELECT MIN (line)

INTO v_min_line

FROM i_cus_fp_invoice

WHERE documentno = Cur_Doc_V.documentno;

Al margen de que hay variables establecidas a mano (hardcoded) y que los comentarios están en castellano y no en inglés, nos aparece de repente un bonito «Cojemos». Entonces he pensado, este debe ser el famoso coger del que hablan por latinoamérica 😀

También me recuerda al Cojer que aparecida en Virtualbox cuando querías seleccionar el archivo de imagen.

Cheli

Openbravo capa la versión comunidad

El anuncio ya es oficial y lo podemos leer en esta entrada del planet. Hasta la versión 2.40 no había ninguna diferencia entre la versión comunidad y la profesional, y a partir de esta se permitía instalar ciertos módulos solo si estabas subscrito a la versión profesional. Pues bueno, a partir de la siguiente versión 3.0 Openbravo va a quitar algunos módulos funcionales como los de MRP, Producción o la gestión de facturas y cuentas en proyectos.

Tienen pleno derecho a hacer este cambio pero no creo que a la gente que ha contribuido a mejorar y corregir errores en estos módulos y que no estén subscritos a la versión profesional les haga mucha gracia.

¿Qué será lo próximo?

Cheli