Archivo de la etiqueta: Openbravo

Calidad del Soporte de Openbravo 2

Tenía mucha curiosidad por saber cual era la tabla de nivel de soporte de Openbravo y finalmente he tenido acceso a ella. Cómo a Openbravo le gusta mucho compararse con Red Hat me he puesto a mirar una y otra a ver que diferencias había.

 

Red Hat SLA

 

Openbravo SLA

 

A simple vista se ve la influencia de Red Hat, Openbravo copia el mismo esquema pero lamentablemente ahí terminan las similitudes. Mientras que los tiempos de respuesta de Red Hat se miden en horas o días los de Openbravo se miden en días o semanas, y yo puedo dar fe de ello. Y no creais que es porque el soporte de Openbravo es más barato, más bien lo contrario. Por poner un ejemplo, la suscripción de Red Hat Enterprise Linux Server para 2 sockets, 1 nodo físico o 2 virtuales en la modalidad de suscripción estándar cuesta $799 al año. Una suscripción de Openbravo estándar para el back-office cuesta $500 al año por usuario concurrente, si le añades el WebPos privativo entonces son $175 más por terminal y año.

A ver si en una próxima ocasión comparamos los precios de Openbravo con los de OpenERP. Ya os adelanto que en este sentido los dos van muy parejos, eso sí, las propuestas son diferentes, OpenERP ofrece soporte sobre su sistema tanto alojado en su nube como en una instalación en nuestras dependencias mientras que Openbravo sólo ofrece la segunda opción, almenos hasta donde yo se.

 

Cheli

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.

Podéis encontrar el curso en la comunidad Devirtualize donde podréis hacer preguntas sobre el mismo.

Cheli

Finalmente Openbravo se queda sin forja

Hace unos días hablaba sobre la posible pérdida por parte de Openbravo de su forja, pues hoy he entrado y finalmente la han perdido. Actualmente aparece un mensaje indicándonos que efectivamente está caida y que están intentando migrarla o un sistema nuevo, también nos comentan que esperan tenerla funcionando en noviembre.

 

Y yo me pregunto ¿en noviembre?, saben desde septiembre que iban a perder la forja por contratar un servicio externo, no conozco los detalles del contrato pero visto lo visto debe ser un servicio tipo SAAS en el que pagas por el servicio pero en el que ni el software ni la infraestructura nunca son tuyos, no tienes ningún control sobre el sistema. Como ya comenté en la anterior entrada, choca ver que una compañía como Openbravo que vende software privativo disfrazado de un core libre haga lo contrario a lo que pretende que hagan sus clientes. Ellos venden Openbravo como un producto libre aunque no lo sea, y ponen como ventajas las que todos sabemos y entre ellas se encuentra la independencia del proveedor, pero cuando ellos van a contratar un servicio entonces contratan un SAAS privativo. Esto me recuerda cuando vendían la versión profesional únicamente sobre Oracle alegando que era mucho más madura y fiable que Postgresql, por entonces yo decía, eso es como decir que compren mejor Navision porque es mucho más madura y fiable que Openbravo, totalmente absurdo.

Aún así, ¿no son capaces de restaurar su forja sea con el sistema que sea y necesitan almenos dos meses?, como ellos mismos dijeron, en septiembre ya sabían que iban a tener este problema y ahora dicen que esperan tenerla de nuevo funcionando durante el mes de noviembre, me parece demasiado tiempo. Estan danto muy mala imágen por la pésima gestión de la situación, el tiempo de respuesta tan alto y principalmetne porque sin forja quitan a sus socios y desarrolladores la herramienta para desarrollar y gestionar sus módulos.

 

Así es Openbravo, un mar de contradicciones, mientras tanto publican conferencias de sus gurús como algo digno de ver cuando son estos los que al fin y al cabo toman este tipo de decisiones. Todo muy al estilo de los políticos, economistas y banqueros actuales.

 

Cheli

¿Openbravo perderá su forja en octubre?

Anoche antes de irme a dormir vi esta advertencia en la forja de Openbravo:

 

IMPORTANT NOTICE

Dear Openbravo Forge User,

As you may know the Openbravo Forge is developed with the platform provided by Essentia. Our Forge was introduced in 2008 and we consider it time to renew it. For this purpose we are working on a more modern version of the Forge.

Till we are ready to launch the new Forge we – under normal circumstances – would continue to use the current Forge on the Essentia platform. For that purpose Openbravo has been negotiating with Essentia regarding a contract renewal to continue with the collaboration on this project. Unfortunately, due to an unexpected change in the position from Essentia these negotiations are not progressing as expected and we have now reached a point where we cannot assure the continuation of service past this coming Sunday, September 30th.

For that reason, we are informing you about the current situation and we recommend all of you to make contingency plans to migrate or host your projects at a duplicate location, if it isn’t already. In particular, we recommend that:
1) You make a copy of any critical wiki article you might have published
2) You make a copy of the source code that you might have stored in the SVN or HG repositories for your projects.
Published modules are stored in a separate repository and will not be affected. The publication of new modules or new versions of exisitng modules might be, however, disrupted. Similarly, since the Forge also acts as single user repository, the write access to issues.openbravo.com and wiki.openbravo.com will be temporarily disrupted.

For your convenience we have already created a new wiki page (http://wiki.openbravo.com/wiki/Forge_Migration) where we will publish more detailed instructions shortly, and we have created an email list / group (forge.migration@openbravo.com / https://groups.google.com/a/openbravo.com/d/forum/forge.migration) to send your questions about migration that we will monitor and answer.

In case the current Forge is shut down by Essentia we will come back as quickly as possible with a temporary platform to cover the critical role OpenbravoForge has been – and continues to play – for Openbravo and for all of you in our Community.We will punctually inform you as soon as we get more information on this issue.We apologize for any inconvenience this may cause.The Openbravo Forge Team
Que viene a ser algo así como:

 

NOTICIA IMPORTANTE

Estimados usuarios de la Forja de Openbravo,

Como sabéis la Forja de Openbravo está desarrollada con la plataforma proporcionada por Essentia. Nuestra Forja fue lanzada en 2008 y creemos que es hora de renovarla. Por eso estamos trabajando en una versión más moderna de la Forja.

Hasta que estemos listo para lanzar la nueva Forja continuaremos – en circunstancias normales – usando la forja actual en la plataforma de Essentia. Para ese propósito Openbravo ha estado negociando con Essentia con el objeto de renovar el contrato y continuar con la colaboración en este proyecto. Desafortunadamente, debido a un cambio inesperado en la posición de Essentia estas negociaciones no están prosperando como esperábamos y hemos llegado a un punto donde no podemos asegurar la continuidad del servicio después de este domingo, 30 de septiembre.

Por ese motivo, estamos informándoos de la actual situación y os recomendamos realizar planes de contingencia para migrar o alojar vuestros proyecto en otro lugar,si no lo habías hecho ya. En particular recomendamos que:
1) Hagáis una copia de cualquier artículo crítico que podáis haber publicado.
2) Hagáis una copia del código fuente que tengáis guardado en  los respositorios de SVN o HG de vuestros proyectos.
Los módulos ya publicado están guardados en un respositorio a separado y no no estarán afectados. La publicación de nuevos módulos o nuevas versiones de los módulos existentes puede ser, sin embargo, interrumpida. De forma similar, como la Forja actúa como repositorio de usuario único, el acceso de escritura a wiki.openbravo.com estará temporalmente interrumpido.

Para vuestra comodidad hemos creado una nueva página de wiki (http://wiki.openbravo.com/wiki/Forge_Migration) donde publicaremos instrucciones detalladas y breves, y hemos creado una lista de correo-e / grupo (forge.migration@openbravo.com / https://groups.google.com/a/openbravo.com/d/forum/forge.migration) para que enviéis vuestras preguntas acerca de la migración que estaremos monitoreando y contestando.

En caso que la Forja actual sea cerrada por Essentia volveremos ta rápido como sea posible mediante una plataforma temporal para cubrir el papel tan crítico que OpenbravoForge ha supuesto – y continua jugando – para Openbravo y para todos vosotros en nuestra Comunidad.Puntualmente os informaremos tan pronto obtengamos más información acerca de este tema.Os pedimos disculpas por las molestias que os pueda causar.El equipo de Openbravo Forge.

 

Estos son los peligros que tiene relegar todo a una plataforma privativa o en su defecto a un servicio en la nube tipo SAAS, si te cortan el grifo estás perdido porque no tienes ningún control ni de la infraestructura ni de los datos. Por eso yo siempre utilizo software libre, porque tiene mil y una ventajas sobre el software privativo como que legalmente nadie me va a impedir recoger todo el despliegue del software y montarlo en otro sitio, no contratas un derecho de uso sino que la instancia que estás utilizando en la práctica es tuya.

Lo más gracioso del tema es que a una compañía como Openbravo que vende software privativo pero que dice que es libre le pasen estas cosas.

Cheli

Diferencias técnicas entre OpenERP y Openbravo 2 (MVC)

Ya hablamos anteriormente sobre las diferencias en arquitectura entre Openbravo ERP y OpenERP. Hoy vamos a hablar de sus  soluciones en cuanto al patrón MVC (Modelo, vista y controlador).

 

El MVC de Openbravo podría resumirse en el siguiente esquema.

 

MVC de Openbravo ERP

 

En el modelo tenemos por un lado la base de datos a la que podremos acceder por sqlc. Sqlc es una herramienta que nos genera clases java en base a una definición en xml de sentencias sql, de este modo podemos tener una clase en la que cada método nos permitirá ejecutar una sentencia sql diferente. Esta es la herramienta de acceso a datos y persistencia utilizada historicamente en Openbravo. A partir de la versión 2.50 se añadió una capa DAL (Data Access Layer) implementada con Hibernate.

Respecto al controlador, esta es quizá la parte más oscura de Openbravo ya que la lógica de negocio se reparte entre código Java y código Pl/sql en base de datos lo que complica bastante tanto el desarrollo como la independencia del SGBD (Sistema de gestión de bases de datos), esto también provoca que la base de datos se vuelva muy lenta.

En cuanto a código Java existe principalmente una clase de la que herada cualquier otro servlet, luego tendremos nuestras propias clases y métodos en java y por último, y ya hablando de código en base de datos, tendremos una serie de triggers, funciones y restricciones.

 

La vista está compusta por código estático en html, css y javascript. Además dipsonemos de una herramienta llamada xmlengine que viene a ser un rellenador de plantillas. Por ejemplo, si tenemos un html con una tabla y queremos rellenar esa tabla con datos xmlengine nos puede ser útil.

 

Si estamos desarrollando una ventana mediante el modelo MDD prácticamente no nos enteraremos de que tecnologías se están utilizando por debajo. En realidad lo que se hace es leer el diccionario y generar código mediante la herramienta WAD, esta internamente genera código para sqlc, DAL, los html, css, javascript, los servlet java, xmlengine, etc. El problema es que hay muchas cosas que no se pueden desarrollar mediante MDD, en esos casos tendremos que picar a mano nosotros todo este código.

 

El MVC de OpenERP es mucho más sencillo.

 

MVC de OpenERP

Unas de las principales diferencias entre OpenERP y Openbravo ERP es que en OpenERP no hay código en base de datos, la base de datos está completamente limpia y eso tiene muchas ventajas. El modelo está compuesto por una base de datos pero lo que nosotros veremos a nivel de desarrollo será únicamente el ORM, de hecho hasta la fecha no he necesita tocar nada de la base de datos, ni siquiera añadir una columna o una restricción. ¿Y como es posible esto?, pues porque cualquier clase en OpenERP deriva de la clase osv.osv y está implementa el ORM. A este puedes indicarle los atributos que necesitas, de que tipo son y él se encargará del mapeo haciendo totalmente transparente el acceso a datos.

La parte del controlador es completamente código python. Por un lado tendremos las clases que dan sustento a nuestras ventanas y si queremos extenderlas por ejemplo añadiendo o sobreescribiendo métodos es muy sencillo, simplemente hay que utilizar herencia. Además nadie nos impide crearnos nuestras propias clases para hacer lo que se nos ocurra.

En cuanto a la vista esta se define en xml. Hay que recordar que en la arquitectura de OpenERP teníamos un servidor al que nos conectábamos por xml-rcp/net-rpc, esto quiere decir que el servidor le envía los datos al cliente en xml y este será el encargado de construir la interfaz en base a esos datos. Por tanto lo único que tenemos que hacer es definir esos xml que representan a la interfaz, muy sencillo todo.

Como cualquier aplicación software tanto Openbravo ERP como OpenERP tienen sus ventajas e inconvenientes, las dos plataformas de desarrollo son muy potentes pero desde mi punto de vista OpenERP tiene una arquitectura mucho mejor definida.

Nota:

Estoy ofreciendo unos mini cursos de desarrollo en OpenERP por 200€.

 

Cheli