Hola Ana,

Este tema ha sido uno de los más hablados, el que más discordia ha creado en la comunidad y el que más preocupados nos tenía a los partners.

Para aquellos que llegais ahora o no entendeis nada de lo que estoy diciendo, intento resumir.

• La mayoría de los editores de software que llegan al nivel de expansión de OpenERP en el mundo, deciden optar por un modelo mixto de módulos “licenciados” o de pago como estrategia de negocio. Lo que sería una versión comunidad sin coste de licencias y una versión “enterprise” con módulos de pago, o con una licencia particular. Por contra, OpenERP siempre ha defendido la publicación libre de todos sus módulos y por tanto, la diferencia entre la versión comunidad y la versión enterprise, es la contratación o no de la garantía de OpenERP, la cual incluye soporte a errores (bugs) y migración de versión.
• En su momento, OpenERP decidió NO publicar sus scripts de migración de datos, de una versión a otra, lo cual es totalmente lícito (cualquier empresa del mundo requiere definir sus líneas de negocio, si no, no serían empresas sino ONGs) pero trajo innumerables críticas tanto de partners como de la comunidad ya que la única forma de migrar OpenERP de una versión a otra, era contratando la garantía. Hasta aquí perfecto y sin problema siempre y cuando un cliente utilizase los módulos del core.

Pero se da el caso de que NINGUN cliente utiliza SOLO los módulos del core, sino que además, existen módulos no oficiales (denominados módulos de localización) que adaptan el sistema a los requerimientos fiscales de cada país y por tanto su instalación es imprescindible en cada uno de ellos. Así, en españa tenemos la localización española, en Venezuela la venezolana, en Suiza la Suiza…

Además de los módulos de localización, la mayoría de los clientes suele adaptar el sistema a sus necesidades específicas por lo que solicitan módulos a medida o también pueden requerir otros módulos publicados por la comunidad o por partners de OpenERP. Estos módulos al no ser parte del core, evidentemente, no se incluyen en el contrato de garantía.

No obstante era posible solicitar la migración de TODOS los módulos de una instalación, sea esta cual sea y tenga los módulos que tenga, siendo el precio de 800€ por cada 1000 líneas de código extra por CADA implantación. Cada cliente que solicitase el servicio debía pagar esta cantidad. Esto era comprensible para módulos específicos de un cliente que los haya mandado desarrollar pero no para los módulos de localización, ya que son requeridos en cada una de las implantaciones que hacemos. Casualmente, la localización española es una de las más maduras y fuertes que existen y el número de líneas es considerable, con lo cual el importe a pagar por cada uno de nuestros clientes en cada versión (cada 18 meses) no era asumible. Por tanto, determinamos que el servicio ofrecido por OpenERP, NO CUBRIA las necesidades de nuestros clientes y nos empezamos a preocupar.

Después de 2 años … innumerables emails, reuniones, skypes y todo lo habido y por haber… nuestra percepción era que OpenERP no nos escuchaba. La percepción de OpenERP era que nosotros íbamos por libre y a nuestro aire, sin contrubuir a su estrategia de negocio y sin apoyarles en su expansión, lo cual en bastantes ocasiones en los últimos meses nos ha llevado a situaciones tensas y malos ratos innecesarios.

Hasta aquí, el pasado… ahora… el futuro:

• El no liberar los scripts de migración es decisión de OpenERP, es su estrategia de negocio y están en su perfecto derecho de definir dicha estrategia
• OpenERP asume que los módulos de localización española son requeridos por todos los clientes españoles por lo tanto, se incluirán como módulos NO Extra en las migraciones. Es decir, no existirá coste extra en la garantía “oficial” para estos módulos. No obstante, en toda migración se requieren servicios extra para validar, testear y probar la migración con lo cual CADA PARTNER decidirá el coste extra que incluirá en la garantía oficial para asumir las horas de servicio para realizar la migración.
• Los módulos que sean específicos de un cliente podrán ser migrados de 2 formas:
  • El  partner asume la migración –> OpenERP no incluye coste extra para las líneas incluidas en estos módulos
  • OpenERP asume la migración de estos módulos –> El cliente deberá asumir el coste de 800€ por cada mil líneas de código en módulos personalizados.

• Si un partner demuestra que un módulo extra o desarrollado a medida es utilizado por más de 10 clientes con garantía, entonces el partner podrá proponer el módulo para que sea incluido dentro del contrato de garantía, con la migración incluida sin coste adicional (como hemos dicho antes, esto sólo sería necesario si el partner prefiere que openERP realice el trabajo de migración del módulo).
• EN TODOS ESTOS CASOS, tanto la garantía de soporte (bugs) de los módulos de localización como los que se desarrollen a medida deberá ser asumida por el partner y la inclusión de los módulos se refiere UNICAMENTE a la migración de datos. No al soporte técnico de los módulos.

Como veis el escenario cambia totalmente. En este caso, el contrato de mantenimiento con OpenERP pasa a ser una garantía real, requerida y necesaria. Por fin vamos a poder ofrecer a nuestros clientes OpenERP enterprise con garantía. Una vez resuelto el tema con OpenERP S.A, ahora solo hemos de ver si es necesario cambiar algo internamente en la forma de organizar la localización o el sistema actual sigue siendo válido, pero esto es ya otra historia distinta a definir entre nosotros.

Por último, daros una pincelada sobre cómo funciona técnicamente el servicio ofrecido por OpenERP porque lo cierto es que hasta ayer ninguno lo habiamos entendido bien. No entendíamos cómo en caso de no querer asumir el coste de 800€ por cada 1000 líneas de código podiamos asumir nosotros parte de una migración y OpenERP otra. Ahora sí lo entendemos. Aquí va:

Entendamos primero en qué consiste una migración de datos entre versiones:

• En una instancia a migrar tenemos 2 partes: módulos python + BBDD postgresql.
• En principio, supongamos módulos python de una versión y bbdd postgresql de la misma versión. Si por algún motivo hubiese cambios en la lógica de la aplicación sin cambios estructurales en la base de datos, no hay ningún problema ya que el sistema internamente provee de un proceso automático de actualización, es por esto que en la migración de versiones menores (6.0.1, 6.0.2), no existe ningún problema. Solo cambia la parte python, por lo con ejecutar un “actualizar todos” desde el propio interfaz, el sistema queda actualizado.
• El problema viene cuando hay cambios estructurales en la base lo cual es inevitable cuando se publica una versión mayor ( esto es 5.0 a 6.0, o en su caso 6.0 a 6.1 ). En este caso, es necesario transformar una estructura en la otra, sin perder los datos que previamente se hubiesen cargado. Esto es lo que ofrece el sistema de garantía de OpenERP.

Veamos ahora cómo sería el proceso a seguir:

• OpenERP provee una herramienta que nos permite “subir” una bbdd de una versión y devuelve la misma base de datos “migrada” a la nueva versión. SOLO las tablas correspondientes a los módulos del core serán migradas. Todo el resto de tablas, será mantenido exactamente igual que estaba. (Nota: A fin de proteger la confidencialidad de datos de los clientes, la base de datos se sube y se recibe encriptada)
• OpenERP migra SIEMPRE los módulos python oficiales a la nueva versión.
• Bien OpenERP(con el coste antes mencionado) o bien el partner migra los módulos python no oficiales, sean de localización o sean a medida, para que puedan ser instalados en la siguiente versión. (Para facilitar el trabajo al partner, OpenERP provee de una herramienta denominada runbot, donde el partner puede testear los módulos los cambios que serán necesarios realizar en el código python)
• El partner, realizará la instalación de la nueva versión con los módulos python migrados, desencripta la base de datos recibida y lo sube a la nueva instancia creada. Reinicia el servidor con Update==ALL.
• En este punto, la migración en sí, ya está realizada.
• Por último, el partner con su cliente testea los datos y cada uno de los procesos funcionales que utiliza para verificar que todo ha quedado correcto. Si hubiese algún problema o proceso que el sistema automático ha generado, se reporta a OpenERP como bug. El arreglo de este bug en el proceso de migración está incluido en el contrato de garantía.
• El proceso puede ser repetido tantas veces como sea necesario, es decir, el partner puede subir la base de datos encriptada de su clientes tantas veces como se requiera, hasta que se obtenga la validación de la migración por parte del cliente, hasta llegar al grado de depuración requerido.

Creo que estos son los puntos más importantes, aunque si los que estuvisteis en la reunión, veis que falta o me he equivocado en algo, por favor, no dudeis en ponerlo en los comentarios para que pueda rectificar o ampliar el post.

Por último, comentaros que muy en breve tendremos un post en el blog de OpenERP donde nos explicarán en detalle el proceso de migración y ampliarán la información que doy aquí de forma resumida. Prometo traducíroslo en cuanto se publique.

No me queda más que agradecer a OpenERP y en especial a Fabien y Marc el tiempo que nos dedicaron. Mención especial también a Rubén, por “meter caña”

A Nhomar de Vauxoo, por su apoyo y su valiosa intervención en la reunión. A Nacho de Alfa90, el haber expuesto con suma claridad el problema por parte del cliente, lo cual ayudó en gran medida a que OpenERP entendiera (por fin!) nuestra visión del tema. Y como no… a Santi de Pexego, figura imprescindible en la localización española con quien la mayor parte de las veces comparto la forma de ver las cosas.

Muchas gracias a todos:

Ana

P.D: Edito a 17/04/2012 para incluir el link que sobre el mismo tema ha escrito Santi en el blog de Pexego. Merece la pena:

http://www.pexego.es/blog/2012/04/15/openerp.-sobre-vision-y-modelo-de-negocio

Zikzakmedia en su blog nos anuncia un nuevo servicio válido para aquellos clientes arrancados en OpenERP 5.0 que requieren migrar a OpenERP 6.0.

Os paso link a la entrada donde explican el servicio ofrecido:

http://www.zikzakmedia.com/blog/servicios-de-migracion-de-openerp-5-openerp-6

Este servicio se aplica a los datos de su base de datos, no sólo módulos oficiales, si no también módulos de localización española como módulos del repositorio de Zikzakmedia.

Gracias por la información!!

El siguiente anuncio de OpenERP, me parece tan importante e interesante que voy a proceder a traducirlo entero.

http://www.openerp.com/node/698

Este era uno de los puntos de debate entre OpenERP y la comunidad. Su nuevo enfoque de abordar las migraciones me parece un paso importantísimo de OpenERP, S.A. y por mi parte significa 2 cosas.

Una… que aunque a veces tarde… escuchan a la comunidad. Uno de los principales problemas para contratar con Bélgica mantenimientos o servicios “oficiales” como el de migración de versiones era que hasta ahora, el servicio estaba limitado únicamente a los módulos oficiales. Por tanto, en nuestro caso ( ratificado y Twitteado por varios miembros de peso en la comunidad mundial) el servicio aunque interesante, no podiamos contratarlo para nuestros clientes por no cubrir nuestras necesidades reales. Tened en cuenta que ni una sola de las instalaciones realizadas por nosotros hasta el momento en clientes cuenta únicamente con modulos oficiales, sino que también incluyen módulos de localización española, extra-addons, community y cualquier otro módulo aportado por la comunidad que consideramos interesante.

Y dos… que esto abre una puerta a que el resto de servicios sean también adaptados a las distintas necesidades de todos los partners de todos los paises y que poco a poco podamos ir incluyendo en nuestros catálogos, la seguridad que puede ofrecer un servicio ofrecido directamente por la casa madre o indirectamente por mediación de sus partners. Esperamos tomen buena nota de la iniciativa y de alguna manera puedan extender la oferta a otros servicios que actualmente también están limitados únicamente a módulos certificados.

A nuestros clientes que están pensando en migrar a 6.0 recomiendo que estudien seriamente esta nueva alternativa.

Cordiales saludos!!

Ana

Migration for non-certified modules

Debido al gran número de solicitudes de varios partners, lanzamos un nuevo servicio extra para la migración de bases de datos que incluyen módulos “a medida”.

Este servicio no está incluido en el actual servicio de garantía del editor OPW (OpenERP Publisher Warranty) sino que debe ser contratado como un extra. El servicio de migración que se incluye en el servicio de garantía solo aplica a módulos oficiales, los módulos “a medida” son generalmente gestionados por partners.

Por lo que, nos complace anunciaros que podemos adaptar y migrar cualquier database que contenga módulos “a medida” de la V5 a la V6 por el precio de 800€ por cada 1000 líneas de código. En caso de que tenga usted, 5 módulos con un total de 2000 líneas, le costaría 1600€ migrar su base de datos con todos los módulos “a medida”. Como ha podido apreciar, el precio es por bloques de código. Pero, para otras versiones, pregunte por un presupuesto puesto que el precio diferirá también en función del nivel de complejidad.

¿Qué incluye el precio?

Nosotros:

• convertiremos su módulo a V6 y lo adaptaremos a los nuevos standares (wizards, reports, nueva estructura de menús, vistas de búsqueda, etc.)
• haremos la migración de todos los datos para usted, por lo que puede fácilmente migrar una base de datos con módulos oficiales y “a medida”

Esto significa que usted solo tiene que enviarnos su base de datos y código de implementación de su versión 5 y nos encargaremos de todo.

Migramos el código y los datos a la versión 6 a precio fijo y bajo coste

Esto es realmente revolucionario para los clientes. Ningún editor de software ERP es capaz de proveer este servicio. No solo gestionamos todo, sino que lo hacemos a un precio realmente asequible.

Con este nuevo servicio, los partners puede escoger:

• Utilizar el servicio de garantía del editor para migrar su base de datos y gestionar sus módulos a medida ellos mismos(adaptar el código a la nueva versión 6 y realizar ellos la migración de los datos de módulos “a medida”)
• Utilizar el servicio de garantía del editor con esta opción extra para migrar su base de datos y todos los módulos “a medida” a un precio muy asequible. No queremos competir con nuestros partners solo queremos hacerles la vida más fácil.

Oferta OpenERP garantía del editor

También queremos recordarle la promoción hasta el 31 de marzo. Si decide comprar nuestro servicio de garantía del editor posterior a esa fecha, aplicaremos un 80% de incremento para clientes que están en una versión inferior a la V6. La razón principal para este incremento es que el coste de mantener una versión antigua es mucho mayor.

Lea más detalles en how migration works y lo que ofrece el servicio de garantía del editor OPW offers.

Migrar datos de un único sistema ya es complejo, pero migrar desde varios es sumamente complejo. A nivel técnico, pocas aplicaciones cuentan con herramientas potentes para migraciones y en la mayoría de los casos, la tarea suele realizarse construyendo los procesos directamente contra la base de datos.

En el caso de openERP lo recomendado para realizar migraciones de datos complejas es utilizar TerminatOOOR(de Akretion.com) + Kettle

Aquí un post de zikzamedia donde nos explican un caso de éxito real,  donde se han migrado  diferentes bases de datos (Sage, Agora y ficheros CSV) a OpenERP, con esta tecnología.

http://www.zikzakmedia.com/ca/bloc/openerp/191-migracion-de-datos-a-openerp.html

Raphaël: Currently busy packaging OOOR + Kettle you’ll see, this is a revolution.
ETL that can just do anything in OpenERP pull/push data, access workflow, composed objects, do anything along with the flow of data… and Kettle can connect to about anything Excell, Access, ODBC, JDBC, Salesforce…

Ana: I think we need a list of problems solved with your solution to have an idea of what it is

Raphaël: the reason we are using it now is:
importing bank paiment files and exporting account move lines but it will solve any integration problem for instance integration with OpenbravoPOS

Ana: With online stores? prestashop?

Raphaël: yes, it’s doable for online shops too, provided Kettle can eeficiently connect to them which was not the case with magento(Kettle does no generic XMLRPC)for OpenERP, OOOR does the XML/RPC specifically for OpenERP

Auí el link por si quereis saber más:

http://github.com/rvalyi/jripple
OpenERP + Kettle OOOR + JRuby

Esperando os sea de utilidad:

Ana

Os paso el link: http://www.aulaerp.com/aula/course/view.php?id=24

El objetivo de este curso, es poder ir añadiendo distintos tipos de archivos, de distintos objetos que funcionen con formulario/importar del menú de OpenERP. Este es el inicio y esperamos que entre todos, consigamos formatos de carga de Pedidos, Albaranes, Facturas, Centros de trabajo, Usuarios… o cualquier otro objeto susceptible de ser migrado a OpenERP desde otros sistemas…

Esperamos vuestras aportaciones.
Cordiales saludos!!
Ana