Si tenéis pensado ir a una universidad rusa tenéis que tener claras dos cosas. La primera y más importante, no hay cerveza en las cantinas :D, de hecho no venden alcohol en todo el recinto. La segunda es que hay control a la entrada. El control consiste en unos rodillos como en el metro y unos guardas que los custodian, lo que implica que si no tienes la correspondiente tarjeta es difícil entrar. Lo primero que pensé fué, ¿y aquí como asistes de oyente o consultas la biblioteca?, por lo que parece tiene toda la pinta de que si no estás matriculado no es posible.
Sinceramente, no se si en Rusia existe algo como la SGAE pero lo cierto es que no lo neceistan. ¿Por qué? pues sencillamente porque en cada entrada a un recinto cultural tienes dos opciones, o comprar la entrada normal o comprar la entrada con derecho a hacer grabaciones
Otro detalle, tampoco necesitan el turismo, en este caso el motivo es que a los extranjeros les cobran el doble que al resto, por tanto si consideramos que la entrada rentable es la que le cobran a los rusos necesitan la mitad de turismo que en el resto de países. Por descontado en Rusia también cobran por ir al servicio.
Si es que estos rusos son más listos que el hambre, me parece que voy a empezar a aplicar estas tácticas comerciales en España 😉 .
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.
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?
Las principales novedades son que se ha actualizado a MP22 y se han añadido todas las correcciones pendientes. Quizá la funcionalidad más destacable es el nuevo importador de nóminas, ahora genera una liquidación manual con un efecto por cada tercero en vez de generar un único efecto, así se evita el problema de no poder partir ese efecto mediante la herramienta de «liquidación» con lo que podemos pasar individualmente los efectos de cada tercero por banco o caja.
Llevo unos días en Moscú y aún tenía pendiente acercarme al Centro español. El sábado pasado como estaba cerca me animé a visitarlo y cual fué mi sorpresa, después de andar buscándolo y finalmente encontrarlo, al ver que como buenos españoles tenían cerrado los fines de semana 😀 . Al menos me pude hacer una foto de recuerdo.
Lo que aún no se es a cual de los tres botones se referían con lo de ¡Toquen el timbre! 😀 .
Esta vez quería hablar de un proyecto en el que estoy colaborando, Ong Libre. Se trata de desarrollar y promover herramientas preferentemente en software libre para la gestión de Ongs. En princpio se ofrecen dos:
Philanthros: Adaptación de Openbravo ERP para cubrir las necesidades del tercer sector.
Gong: Promovida por el Cenatic es una herramienta que desde el principio ha sido diseñada para la gestión de Ongs.
La que mejor conozco obviamente es Philanthros, sus características son:
Está desarrollada como una plantilla con módulos funcionales para Openbravo ERP 2.50
Licencia GPL v3
Tenéis acceso público a la forja basada en Redmine donde podéis acceder al historial de incidencias y al código en Subversion.
Actualmente hay 5 Organizaciones utilizándolo, aunque lo que se pretende es fomentar y modernizar el resto de organizaciones existentes en el mundo.
Hay una cosa curiosa que es la propuesta y aprobación de nuevos módulos. Cada organización puede proponer nuevas funcionalidades y estas se someten a votación, las más votadas pasan a desarrollarse gracias a la financiación de todas las organizaciones subscritas al proyecto.
Desde el principio me pareció un proyecto interesante, a ver si va creciendo y se adhieren más organizaciones.
