Cuánto tiempo que no escribía en openerpsite. Me apunto que debo retomar la costumbre.

Comentaros que hemos recibido este correo de Nacho anunciando las jornadas OpenERP 2013 que este año se celebrarán en Valencia organizadas por Domatix.

Hola a todos,

Tal y como ya sabéis algunos, las Jornadas de OpenERP de 2013 serán este año en Valencia, en las fechas 27 y 28 de Junio.

Os dejo acceso a la plantilla del Google Doc que hizo Ana el año pasado, para rellenar quienes queráis la hoja de patrocinios y sugerencias para charlas:

https://docs.google.com/spreadsheet/ccc?key=0AtLY1SK96QwJdHBYMy1MZGgyUVJ5RzFKYl83UXBYRnc&usp=sharing

El importe del patrocinio será de 180 euros + IVA. El que quiera patrocinar por favor que rellene la hoja de Google Docs y nos envíe datos fiscales y logo de su empresa en vectorial (svg o pdf únicamente). 

Cualquier duda o consulta, quedamos a disposición.

Saludos,

Esperamos con ilusión que llegue la fecha para pasárnoslo estupendamente igual que en años anteriores. Espero veros a tod@s por allí!!!

FORMULARIO DE INSCRIPCION A LAS JORNADAS: http://jornadasopenerp2013.eventbrite.com

Cordiales saludos:

Ana

• http://www.openerpsite.com/cuarto-aniversario-de-openerpsite-y-openerp-7-0/

A pesar del llamamiento, no hubo muchos voluntarios para abordar la tarea de realizar la tarea de migración de los módulos de localización de 6.X a 7.X por lo que actualmente 7.X sigue estando sin adaptar a las leyes españolas.

Durante las últimas semanas y gracias al apoyo de Jaime Catalán(jca) (nuestro account manager) y Olivier Dony(odony) (increible como siempre) hemos dado algunos pasos adelante para mover el tema y conseguir no sólo tener la localización migrada, sino abordar también la tarea de limpieza y optimización de código de la misma (será árdua tarea que requerirá el apoyo de todos).

Después de una primera reunión con OpenERP que falló técnicamente, en la que los partners y las personas de la comunidad a las que se invitó no pudimos expresarnos, se organizó una segunda reunión mucho más productiva donde se establecieron las tareas a realizar y las pautas a seguir.

• Para aquellos cuya excusa es “no sé colaborar” y por tanto “no lo hago”, se han enviado varios correos aclaratorios, cuya copia posteo abajo.
• Para aquellos que estaban esperando la lista de cosas a revisar en la localización que prometió OpenERP en su momento y no llegaba.. posteo un mail de Olivier Muy Detallado en respuesta a varias preguntas que le hice sobre la 7.0. Por lo que YA tenemos unas pautas para aplicar de base.
• Para los partners y gente que no conoce la localización española y se quieran unir al grupo, comentar que no es necesario hacer nada especial más que seguir la lista de localización, aportar en lo que uno pueda y ya está. No hay un “carnet comunitario” para los miembros, ni hay que realizar acciones o menciones especiales para estar dentro. Simplemente hay que aportar y trabajar.

Y dicho esto… voy al lío.

TRADUCCION DEL MAIL DE OLIVIER CON PAUTAS PARA OPTIMIZAR LA LOCALIZACION ESPAÑOLA

(quizás también aplicable a otras localizaciones del mundo)

SOLICITUD/SEGUNDA PREGUNTA ANA:

RESPUESTA OLIVIER:

Es un asunto muy complicado Sabes que tenemos unas guias genéricas de desarrollo para móudlos de localización [1], pero esto no provee un modo de juzgar lo ques “buen código” y lo que es “mal código”, especialmente en módulos de extensión l10n_xx__*

SOLICITUD/TERCERA PREGUNTA ANA:

RESPUESTA OLIVIER:

• El módulo ‘web’ de OpenERP no puede ejecutarse él solo (por ejemplo un openerp server a través de la red). Esto elimina una funcionalidad no usada y cerca de 1000 líneas de código.
• Una nueva vista de búsqueda unificada basada que automáticamente reemplaza las vistas multicampo de 6.1 para mejorar en usabilidad(la mayor parte de usuarios encuentran la vista de búsqueda como un formulario). El código de las vistas de búsqueda existentes no necesita ser cambiado – ver  http://doc.openerp.com/trunk/developers/web/search_view/
• Los wizard de estilo antiguo  (extendiendo wizard.interface y declarado usando <wizard> tag) no se soportan más. Todas las vistas deben ser reemplazadas por orm.TransientModel ones (i.e. osv_memory). Ver la guía de conversión: http://doc.openerp.com/v6.1/developer/04_wizard.html#guidelines-on-how-to-convert-old-style-wizard-to-new-osv-memory-style
• Funcionalidad importante ha sido reescrita: – see the new base_import module. The import_data() method is still API-compatible. See http://doc.openerp.com/trunk/developers/server/06_misc_import/ –Z
  
• Translatable terms extraction between server/addons/web has been unified – standard export wizard will now export web/js terms as well
• `active` flag added to record rule and ACL entries (courtesy of Akretion)
• Behavior of parameter passing for `on_change` calls has been slightly improved and unified – see also http://doc.openerp.com/trunk/developers/server/06_misc_on_change_tips/
• OpenERP now implements its own multi-process monitor. The server can now take advantage of multi-core hardware natively (i.e. without third-party tools like gunicorn). See `–workers` server parameter.
• Mail handling code has been reviewed, unified and cleaned up (for OpenChatter features)
• Uninstall system has been improved and now works in almost all cases (it can handle workflows, constraints, FKs, m2m relationship tables)
• res.users/res.partner were heavily refactored (res.partner.address merged with res.partner, res.users now inherits from res.partner) – this is likely to require specific adaptation in custom modules. (base_contact 7.0 module will be available soon via OPW)
• Form view architecture is now more permissive when `version=”7.0″` is added to root element (in particular to allow more HTML-friendly views, including custom HTML content with external CSS styling). See examples in official addons for the recommended v7 form view structure (including a <header> and <footer> section, plus a <sheet> wrapper when the form is supposed to represent a paper document)
• Inherited form views that have no `version` attributes will be applied on any parent view and should continue to work in most cases, but if `version` is specified on the root element of the inherited view, the parent version must match.
•  the `statusbar` widget for selection fields can now be made clickable to set the value by adding clickable=”True” to the field (in addition to the existing statusbar_visible and statusbar_colors attributes)
• List/Tree view now support a new attribute to change the font, similar to `colors` – see http://doc.openerp.com/trunk/developers/server/06_misc_list_font_style/
• “Need-action” feature has been added, it can show the list of items with new notification (i.e TODO) on the right of a menu item – see http://doc.openerp.com/trunk/developers/server/06_misc_need_action_specs/
• Python unit-tests are now run in addition to the YAML tests upon installation with the `–test-enable` flag – see http://doc.openerp.com/trunk/developers/server/05_test_framework/
•  The documentation is now part of the different projects repositories, under a /doc subdirectory, and published on http://doc.openerp.com/trunk/
•  `fields.char` now has optional size (defaults to no size, just like postgres’s VARCHAR). The `size` parameter should only be passed when there is a good business reason for limiting the input size. Otherwise it’s just useless and does not make any performance or disk space difference.
•  Some special cases of o2m domains using negative operators have been changed to make them more logical (see the ORM tests if you care about this)
• `ir.actions.act_window` now has an explicit `res_id` column to directly open the form view of a given record – previously it was only possible to pass `res_id` for dynamic actions.
• `ir.filters` now has an extra `is_default` attribute (lets users choose a default filter), and the user_id field can now be left empty to make a filter global to all users (used to make it only usable by the system)
• m2o and o2m fields have an extra `auto_join` experimental parameter that modifies the way OpenERP domains are implemented – see http://doc.openerp.com/trunk/developers/server/06_misc_auto_join/

El cliente GTK Client no va a ser mantenido más y no será directamente compatible con la funcionalidad de 7.0 definida arriba. La comunidad es libre de solicitar la propiedar y comenzar el mantenimiento (ver la relevante discusión en la lista de la comunidad)

——

Hasta aquí, los correos de Olivier.

Aquí los correos enviados a los asistentes a la reunión con OpenERP, SA

El primero de Ignacio Beas:

Hola,

Tal y como se ha comentado un primer paso es darse de alta en las listas y proyecto launchpad.net. A continuación pongo los diferentes enlaces:

- Proyecto Launchpad: https://launchpad.net/openerp-spain

- Lista para hablar de temas específicos de la localización: http://groups.google.com/group/openerp-spain?hl=es
openerp-spain@googlegroups.com

- Lista de usuarios de España, que se trata otros temas que no sean especificos de la localización pero que puede enriquecer nuestros conocimientos:

http://groups.google.com/group/openerp-spain-users?hl=es

opener-spain-users@googlegroups.com

En cuanto solicitéis todos sereis bienvenidos a la comunidad, muchos hacemos más que pocos. Alusión a la descripción de TEAM de Jaime.

Saludos,

Ignacio

—–

Otro Mío:

Buenas…
Para los recién llegados y para los que buscaban información y pautas sobre cómo funciona la comunidad española, os paso unos links. Quizás la información esté un poco desactualizada y algunas cosas hayan cambiado, sobre todo en la estructura de ramas de launchpad y demás…
Estaría bien que fueseis reportando lo que veais que está incorrecto para actualizarlo en las respectivas webs.

http://www.openerpspain.com/comunidad
http://www.openerpsite.com/erp-proyectos-openerp/

Y aquí la rama comunitaria donde también teneis las pautas de colaboración en inglés.
https://launchpad.net/openerp-spain

Cualquier duda sobre localización, preguntais en la lista de google y se os atenderá.

Esperando os sea de utilidad,

Cordiales saludos!!
Ana

Notas de Ana:

Los puntos del mail de Olivier no traducidos, hacen mención únicamente a temas técnicos que atañen a desarrolladores y entiendo por tanto que todos ellos pueden leerlo directamente en Inglés.

Además, en la reunión se habló de retomar la asignación de tareas en el google docs: https://docs.google.com/spreadsheet/ccc?key=0Ar3nmWPwwBaWdE1mODdiMWZsYzVHMkExb0N3dlRxQnc#gid=0

Si alquien quiere editar, que solicite acceso pero la solicitud no se atenderá hasta el próximo 1 de abril por vacaciones.

Y esto es todo, que es muchísimo. Sois libres de hacer vuestros comentarios y de aportar ideas.

Gracias Jaime y Olivier por vuestro apoyo.

¿Cuatro años??????? Han parecido cuatro suspiros…

Ha llovido mucho desde aquel 2008 en el que empezamos. En aquel tiempo había un entorno social y laboral en el que apenas se mencionaba la crisis. Estábamos llenos de ilusión por empezar algo nuevo, aunque siempre existía aquella incertidumbre de si OpenERP cuajaría en el mercado español, siendo software libre, habiendo muy poquitas empresas integradoras, casi nada de documentación en castellano y un búscate la vida total que hoy día parece mentira que fuese así. Aún peor lo teníamos en nuestro caso que estamos en medio del silicon valley de los ERPs propietarios, en un pequeñito pueblo gipuzkoano. Pero… apostamos por OpenERP y aquí seguimos. A pesar de la crisis, a pesar de los cambios… Nos sentimos más fuertes, con más ilusión que nunca por hacer cosas nuevas, con un equipo crecido, formado y dispuestos a seguir dando caña, evolucionando y adaptándonos a lo que depara el futuro.

Y … ¿qué hay de nuevo últimamente?

Por supuestísimo, la publicación en poquísimos días de la nueva versión OpenERP 7.0. Según se dice, será la versión definitiva que revolucione el mercado de los ERPs. OpenERP será el primer ERP social del mundo. Íntegramente accesible mediante su refactorizado interfaz Web, proveerá de funcionalidad “social” a una herramienta concebida inicialmente para solucionar lo más aburrido… la gestión de la empresa.

OpenERP 7.0 Release Notes

Ahora bien… Con el nuevo enfoque de OpenERP desde su base, tenemos mucho que hacer y desde aquí hago un llamamiento a “esta nuestra comunidad” para ponernos en marcha con la lista de tareas pendientes que debemos hacer entre todos si queremos empezar el año usando OpenERP 7.0. Si dejamos de lado algunas de ellas… tardaremos muchos meses en poder usarla de forma habitual en nuestro país.

1. Traducciones: A fecha de ayer había más de 5000 términos sin traducir en launchpad. Unos poquitos minutos al día de cada uno y para final de año podemos tener la herramienta traducida al 100% como en versiones anteriores. Aquí enlace por si os queréis unir al grupo de traducción: https://translations.launchpad.net/openobject-addons
2. Migrar la localización a la nueva versión. Para los neófitos, diremos que si no se adapta la herramienta legalmente a un país, no se podrían usar sus módulos de contabilidad (efectos contables, transacciones bancarias, remesas de cobros/pagos… etc) Esta debe ser una de las tareas prioritarias de la comunidad a fin de que se pueda utilizar lo antes posible en producción. Para ello, tal y como ya he mencionado en la lista de localización, debemos pensar en si seguir “parcheando” los módulos para simplemente adaptarlos y que funcionen en la nueva versión o bien pensar en una refactorización y mejora a fondo. Veremos lo que se decide en próximos días. Si lo hacemos ordenada y repartidamente, podríamos tener algo decente en unos pocos meses.
3. Nuestros propios módulos. Es decir, la mayoría de los integradores y colaboradores de OpenERP tenemos módulos personalizados desarrollados y publicados. Habría que ir pensando también en migrar dichos módulos y adaptaciones verticales a la nueva versión, pero claro, esto ya depende de la disponibilidad y necesidad de cada uno.
4. Testeo: Por experiencias anteriores, en el momento de publicar una nueva versión pasan un par de meses antes de que sea relativamente estable y varios meses antes de que sea estable del todo. Os animo a probar la trunk y publicar los bugs que encontreis en launchpad a fin de afinarla lo antes posible. Aquí link para publicar bugs: https://code.launchpad.net/openobject-addons
5. Acostumbrarnos al nuevo interfaz Web porque en la versión 7.0 ya no se soportará más nuestro viejo compañero de viaje… el interfaz GTK. Lo echaremos muuucho de menos y personalmente creo que es lo que más me costará cuando empecemos a usar 7.0. De hecho, espero y deseo por favor que la comunidad mundial de OpenERP recoja el testigo y lo sigan manteniendo vivo.

Como dice Fabien: The official release is planned for the 21th of December. As the Mayas predicted it, this is the end of an age, the old ERP dinosaurs.

El lanzamiento oficial está planificado para el próximo 21 de Diciembre. Como predijeron los mayas, este es el final de una  era, los viejos ERPs dinosaurios.

A pesar de que a muchos seguramente no les gustará que hable en ocasiones de forma tan cruda, a mí me ha encantado y por ello, he decidido traducirlo y publicarlo en castellano para toda la comunidad hispano-parlante. He realizado la traducción a toda mecha y sin revisión posterior por lo que admito cualquier aportación de la comunidad al respecto.

También he de comentar que a pesar de que para España, coincido en un porcentaje elevadísimo en las experiencias y consejos que ofrece Alexis en su reportaje, la situación de la parte contable de OpenERP en Francia, parece que esté menos evolucionada que la situación que tenemos en España donde numerosas empresas utilizan OpenERP como base contable de su empresa. Es decir, empresas que Alexis cataloga como en “situación 2″.

A lo largo de los próximos días me encantaría completar este artículo con aportaciones de la comunidad española intentando definir las situaciones similares y las que no coinciden en los 2 paises.

Agradecer a Alexis esta magnífica aportación que intenta de forma objetiva mostrarnos la situación del ERP más versátil del mercado.

Aquí teneis el artículo original en francés: http://people.via.ecp.fr/~alexis/openerp/

Y aquí el artículo traducido al castellano: http://www.openerpsite.com/experiencia-openerp-francia

1. bajar la última versión de la rama para la que es el módulo, si es para la 6.0
$ bzr branch lp:~openerp-spain/6.0  (o bzr branch lp:~openerp-spain/6.1)

Aquí va el resumen con opiniones (subjetivas) sobre cada una de las presentaciones y su link correspondiente en Slideshare (NOTA: Incluyo solo los que nos dejaron copia de su presentación. El resto, por favor, enviádmela para publicar o pasadnos link si lo publicais vosotros mismos).

Programa

Jueves 31 Mayo 2012

Horario     Charla

10:00 – 10:30    Presentación. Introducción a OpenERP

Rápida introducción en vistas a dar una visión general de lo que es OpenERP a los alumnos de la universidad presentes en la sala.

10:30 – 11:00    Gestión de granjas (Nan-Tic)

Nan nos presentó una completa solución para granjas de cria de animales, con control de trazabilidad tanto si se gestiona por individuos únicos, o grupos de ellos.

Gestión de granjas: http://www.slideshare.net/NaN-tic/vertical-de-granjas-openerp

11:00 – 11:30   Vertical para universidades y centros de formación (Avanzosc)

Presentamos la adaptación y extensión de los módulos de training de OpenERP para cubrir los procesos de Pre-inscripción, matrícula, facturación, gestión académica, docencia, relaciones internacionales, prácticas de una Universidad privada española.

http://www.slideshare.net/Avanzosc/vertical-universidades-openerp

11:30 – 12:00    Nuevos módulos para la gestión de proyectos siguiendo los estándares del Project Management Institute (Eficent)

Interesantísima presentación de Jordi Ballester de Eficent, donde nos muestra cómo ha extendido los módulos standar de proyectos de OpenERP, para incluir funcionalidad adicional como planificación, tareas precedentes y posteriores, hitos, camino crítico… etc, etc.

http://www.slideshare.net/jordieficent/eficent-jornadas-openerp-2012-gestin-de-proyectos-con-openerp-siguiendo-los-estndares-del-pmi

12:30 – 13:00    Kafka db y BABI (Nan-Tic)

Interesantes Herramientas para migración de datos y business intelligence para OpenERP

http://www.slideshare.net/NaN-tic/babi-basic-business-intelligence-for-openerp-13190950

http://www.slideshare.net/NaN-tic/kafkadb-13190976

13:00 – 13:30    Tryton, diferencias técnicas, estado de localización… (NanTic)

Estado de situación actual de Tryton con respecto a OpenERP.

http://www.tryton-erp.es/blog/presentacion-de-tryton-en-las-jornadas-de-openerp

http://www.slideshare.net/NaN-tic/tryton-13191036

13:30 – 14:00    MongoDB como backend complementario (ElGas)

ElGas, empresa proveedora de suministro eléctrico en las islas baleares, nos presenta una original solución para el manejo de millones de registros de datos en tablas simples, utilizando mongoDB como backend o bbdd complementaria para OpenERP.

http://www.slideshare.net/Avanzosc/grupelgas-donosti2012

16:00 – 16:30   Aspectos legales de la AGPL (Acysos)

impartida por Helena Fuentes Herrando de PWC

http://www.slideshare.net/Avanzosc/aspectos-legales-13183279

16:30 -  17:00    Vertical Granja de Huevos (Avanzosc)

Vertical de OpenERP para granjas de huevos. Gestiona consumo de cereales y producción de pienso + compra y control de lotes de gallinas, ubicando los lotes de gallinas en naves + consumo de pienso y producción/paletización/envío de huevos a cliente.

http://www.slideshare.net/Avanzosc/presentacion-nueva-granjacastellano

17:00 – 17:30    Operaciones de Almacén (Domatix)

1. http://www.slideshare.net/domatix/operaciones-de-almacn-con-openerp

2. http://www.slideshare.net/domatix/conector-openerp-mrw

17:30 – 19:00    DEBATE/preguntas generales del público. Varios ponentes

Este fue uno de los dos debates interesantes que hubo en las jornadas. La temática  se inició gracias a un email enviado por Ignacio Navarro a mi correo, que posteo a continuación (entiendo que no le importe, ya que resume perfectamente la forma en que iniciamos el debate)

Le comenté a Ana que sería muy interesante buscar un hueco para una reunión de los usuarios. Allí podríamos compartir nuestros problemas y nuestros éxitos. No para los que quieren iniciar una instalación sino para los que estamos metidos en OpenERP con un mínimo de por ejemplo seis meses o un año.

No conozco un canal organizado de escucha a los usuarios.

De lo que se trata es de que los usuarios nos conozcamos.

Quizá una posible idea sería que nos presentásemos los usuarios que asistimos indicando lo que hacemos, los grupos de módulos que utilizamos de OpenERP, la versión de OpenERP, el número de trabajadores, el número de puestos con OpenERP, las dificultades actuales que tenemos o algo así.
La propuesta es crear un club o foro de usuarios, saber cuantos somos y la entidad que tenemos. A nivel global de OpenERP España, yo al menos no tengo la menor idea de si somos 100 o 1000. Si en conjunto tenemos 100 puestos de trabajo o 10000. No conocemos la dimensión del uso profesional de OpenERP en España.
Más que preguntas se trata de saber quien es quien en España. Igual sería interesante a nivel global de OpenERP.

Lo ideal sería tener el grupo albergado en algún sitio de OpenERP con un resumen de la instalación y con la persona de contacto quien quiera ponerla, pero al menos, aunque sea de forma anónima ese resumen. Por ejemplo: empresa de Valencia, sector industria química, 45 trabajadores, 22 puestos de trabajo, contabilidad, fabricación, ventas, CRM, compras, 120000 movimientos de almacén anuales, 100000 movimientos contables anuales,…

Es importante informar a los usuarios que debemos reportar los bugs, enseñar claramente como hacerlo. También colaborar en la traducción de la wiki y describir los módulos que cada uno de nosotros hemos ido modificando y mejorando. (Nota de Ana: Lo pongo en negrita por el interés que tiene)

Me comentó Ana que algo así presentó a OpenERP en petit comité en Bélgica. No solo somos los usuarios quienes tenemos este tipo de falta de información sino también los implantadores. Sería para los implantadores conocer qué módulos están haciendo otros, cuales son los más usados, cuales requeridos en un país… importantísimo.

Ya que OpenERP va a venir el viernes, sería interesantísimo recoger un pequeño informe con todas estas inquietudes y pasárselo.

Y lo recogimos. Aquí va en 4 líneas lo que apuntamos para preguntar/comentar a OpenERP. Dudas e inquietudes recogidas tanto de implantadores como de usuarios que estaban en la sala (si me dejo alguna, me decís) y que se plantearon a Rubén y Frederick de OpenERP aprovechando que estaban presentes durante el debate.

• Definición “oficial” de LTS y política de publicación de versiones –> Se comenta que 18 meses es corto tiempo para una LTS. También se comenta que no se tienen en cuenta los bugs y parches reportados por la comunidad para versiones anteriores, dandose prioridad únicamente a los reportados en la última versión estable.
• Mejoras en el ORM para optimizar el rendimiento de algunas aplicaciones al manejar grandes volúmenes de datos –> Se comenta que en procesos puntuales al manejar grandes volúmenes de datos, la aplicación se ralentiza.
• Falta de información sobre el proceso de migración –> Desde nuestra visita a Bélgica, esperamos ansiosamente la publicación “oficial” sobre las migraciones de versión. Aunque en su momento entendimos como era, la comunidad espera que se publique un informe técnico detallado tal y como nos prometieron que se haría.
• Listado de Modificaciones técnicas a realizar a los módulos de localización para que se incluya en el proceso de migración: Segunda promesa que esperamos recibir de OpenERP en breve. Un listado de tareas técnicas a realizar para que la localización cumpla los standares técnicos marcados por OpenERP. La cuestión es que los módulos de localización funcionan y están implantados en todos los clientes españoles que utilizan OpenERP pero… cierto es que técnicamente algunos de ellos son mejorables y arrastran código desde versiones anteriores que puede ser optimizado. Necesitamos tener la lista de lo que hay que cambiar para ponernos a ello.
• Mejora de la documentación o más información sobre el acceso a la misma: se comenta que no se ha publicado mucha documentación sobre los cambios técnicos que se están realizando para la 7.0. Agradeceríamos un link a la misma tan pronto se publique.

Viernes 1 Junio 2012

10:00 – 12:00    Resumen de lo visto en los OpenERP days (OpenERP)

Rubén nos presentó algunos datos sobre número de descargas y visitas desde España a la web de OpenERP, siendo el cuarto país del mundo más interesado en la solución.

Frederick, nos muestra las mejoras en usabilidad y comunicaciones que se incorporarán en la nueva versión 7.0, además de un vistazo rápido al nuevo módulo POS (point of sale, TPV)

http://www.slideshare.net/Avanzosc/jornadas2-13183887

12:30 – 13:00    l10n_es_gestion_comercial nuevo módulo para localización (Soluntec)

NUEVO MODULO DE LOCALIZACION ESPAÑOLA para la gestión de efectos comerciales (cobros y pagos)

http://www.slideshare.net/Avanzosc/soluntec

Actualizo con correo de Nacho Torró, tal cual:

Solo comentar que he subido a launchpad la versión del modulo del Gestión Comercial de Efectos en el estado en el que se presento en las jornadas.
Se puede encontrar en:
https://code.launchpad.net/~soluntec/+junk/Gestion_Comercial
Recordar que es un módulo todavia en desarrollo aunque debería ser mas bastante funcional. Quiero durante esta semana hacerle un sprint para acabar las funcionalidades que faltan (ver el ciclo para pago a proveedores y el descuento de efectos) y pulir algunos detalles y si me dais el visto bueno veremos de subirlo a la rama de la localización cuando veamos que es estable..
Os ire escribiendo en este hilo los progresos..
Saludos

13:00 – 13:30    Módulo LOPD (Compuservice)

Completísimo módulo que se podría considerar un vertical para empresas que implantan la LOPD, válido también para empresas que quieran llevar un registro exhaustivo de todo lo requerido para cumplir la ley en su empresa. Fue una Live demo. No tenemos presentación. Lástima. A ver si los chicos de Compuservice, pudiesen montar aunque sea un resumen con pantallazos del módulo para publicarlo.

13:30 – 14:00    Dos módulos nuevos y Caso de Exito Rentalia (Factor Libre)

Tampoco tenemos la presentación sobre el caso de éxito de Rentalia.

Fue una lástima que la red de la Universidad no permita el acceso a otras redes privadas, por lo que nos quedamos con ganas de ver funcionando in-situ la conexión de la Web contra OpenERP.

16:00 – 17:00    Espacio para charlas relámpago

Se abrió un espacio para que los asistentes pudiesen presentar o hablar de lo que quisieran en  charlas relámpago de 5-10 minutos. Pudimos escuchar a:

• Daniel Campos (Avanzosc): Gestión de trazabilidad de ruedas de vehículos
• Susana Izquierdo (Abartia): Gestión de recursos para actividades lúdicas. Acampadas, piragüismo. Lástima que tampoco pudiésemos ver la demo in-situ
• Albert Cabedo(Gafic): Ofreció un nuevo servicio con OpenERP. El gabinete/gestoría de Albert lleva la contabilidad a varias empresas de forma externalizada, accediendo directamente a la instancia de OpenERP de dichas empresas.
• Alberto Barrionuevo(Opentia): Presentó OpenERP B2B.
• Angel Moya (Domatix): Presentó el enlace de OpenERP con una agencia de transportes (Presentación arriba)
• Omar (Pexego): Gestión Documental. Omar, presentó una interesantísima solución para poder gestionar e imprimir el expediente completo de un pedido de venta. Esto es, todo el historial de pedidos, albaranes y facturas para una determinada venta. Imprescindible probarlo. Presentación: http://www.slideshare.net/pexego/gestion-documental-openerp

• Jordi Esteve (Zikzakmedia): Presentó los últimos módulos publicados por Zikzakmedia

17:00 -19:30    Introducción al estado actual de la localización española.

Workshop adaptación a la versión 6.1; Nuevos desarrollos.

http://www.slideshare.net/Avanzosc/localizacion-espaola-openerp

Segundo interesante debate de las jornadas donde pudimos volver a debatir distintos  aspectos de la situación actual de la localización y varios enfoques de oferta de servicios a nuestros clientes finales. Hay varios puntos de vista sobre este aspecto:

1. Hay empresas que desean seguir ofreciendo servicios de OpenERP a sus clientes, como lo han venido haciendo hasta ahora. Es decir, siendo miembros de la comunidad española de OpenERP pero sin entrar en la “vía oficial” del partnership y sin ofrecer OpenERP enterprise. Es decir, sin ofrecer garantía de Bélgica para soporte y migración de los módulos del core, ofreciendo por tanto únicamente su propio catálogo de servicios y sus propias garantías.
2. Hay otras empresas que incluirán en su catálogo de servicios la garantía oficial de Bélgica para los módulos del core pero incorporando a su vez garantía para los módulos de localización y los que se construyan a medida para el cliente.
3. Por último, hay empresas que deseando incluir en su catálogo de servicios la garantía oficial de Bélgica, están esperando a que se publique un post técnico detallado sobre las migraciones de versión y la herramienta que se provee para realizarlas además de que Bélgica provea la lista de cambios técnicos a realizar en los módulos de localización para su adaptación a posteriores versiones.

También se planteó la posibilidad de fundar una asociación, empresa, fundación que de forma “oficial” dé soporte a la localización. Somos el único país del mundo donde la localización es mantenida de momento, por una comunidad y no por una empresa. En principio, esta idea, no fue aceptada, por lo tanto, cada empresa de forma individual decidirá las condiciones y la forma de dar soporte a su cliente final en cuanto a los módulos de localización y por supuesto, de los módulos que construya a medida para dicho cliente.

Creo que con esto se resume gran parte del debate.

19:30 : Clausura del evento por Iñaki Morlán profesor titular de ATC

——————-

AGRADECIMIENTOS:

A Iñaki Morlan y a la UPV/EHU por su magnífico apoyo en la organización del evento. Muchísimas gracias

A Amparo y Josune de la facultad de Informática por su amabilidad y eficiencia en la preparación del catering y las comidas de los 2 días.

A Nelva Ramirez del restaurante del Hotel Ezeiza por su exquisito trato y calidad en el servicio de cena del día 31.

A todos los ponentes por su profesionalidad y buen hacer.

A todos los patrocinadores porque sin ellos no hubiese sido posible. (Especialmente a Q2k por el original diseño de los carteles y los Flyers)

A Ruben y Frederick por venir desde Bélgica y aguantar algún que otro chaparrón.

A todo mi equipo de Avanzosc (Juani, Dani, Ainara, Ibone, Iker, Xabi, Mikel, Alfredo, Ainara G)…  porque… son la leche!!!

Gracias a todos!!!

Ana

EDITO a Miércoles 6/06/2011

Links a otros artículos que hablan de las jornadas OpenERP 2012:

http://www.domatix.com/reflexiones-tras-las-jornadas-openerp-2012

Aquí os  dejo un resumen con extractos de los párrafos más interesantes y una genial conclusión de Santi de Pexego y ahí paro, ya que la siguiente reflexión de Jose Prieto, tiene fácilísima solución y a mi entender no aporta demasiado. Si te falta algo NO PIDAS a otros que lo hagan. Busca clientes que lo financien y subcontrata lo que necesites o hazlo tú mismo. Fundamento del software libre. Repetimos por enésima vez en estos días que ninguno somos ninguna ONG.

Espero que a los recién llegados también les aclare ciertas dudas sobre la parte financiera/contable de OpenERP en España. También invito a nuestros clientes y a los de todos a leer en detalle este hilo al completo directamente en nuestra lista de correo de localización: openerp-spain@googlegroups.com

Cordiales saludos!!

Ana

JM: Hola a todos, Estoy interesado en utilizar la opción que ofrece OpenERP en la modalidad SaaS pero me preocupa los relativo a la localización española ya que en la modalidad SaaS no tienes acceso a instalar módulos. Me imagino que en el SaaS utilizarán el módulo estándar l10n_es, y no se si con eso es suficiente ya que no conozco las diferencias con el l10n_es_pyme_account.

RE: El módulo l10n_es sólo añade el pla contable español. Relativo a todo lo otro, debes añadir la larga lista de 20 módulos que empiezan por l10n_es. En www.aulaerp.com encontraràs documentación cada uno de ellos (o los más comunes)

Más información sobre módulos l10n_es: http://www.zzsaas.com/es/modulos

AJ: Es que el SAAS “oficial” de OpenERP no incluye ni módulos de localización, ni módulos a medida de los clientes. Solo tiene los módulos oficiales y por tanto sólo incluye el módulo básico de la localización l10n_es “certificado”. Como te dice Raimon, la localización española tiene más de 20 módulos l10n_es que no están “certificados” por Bélgica, ni se incluyen en la versión “oficial”.
No obstante tienes alternativas varias, entre ellas zzsaas, como te comenta Mario.

JM:Una cosa más: ¿veis viable en la práctica trabajar solo con el módulo básico de la localización española?
¿Se podrían presentar los impuestos telemáticamente solo con el módulo básico?

IB:Sinceramente, si utilizar solo el módulo básico pierdes gran parte de la funcionalidad que tiene la localización españoa. Este módulo solo carga el plan contable, posiciones fiscales e impuestos. Faltan módulos que en mi opinión son bastante necesarios para la contabilidad española: recibos 19,32,34 y 58, extractos con la norma 43, modelos 340,347 y 349, aunque el 340 de momento no es obligatorio para todas las empresas,
informes financieros y aunque no imprescidible pero muy util la base de datos de bancos y municipios.

La presentación telemática de impuestos no esta en el módulo básico. Son módulos a parte que te he comentado antes. Yo te recomendaria utilizar una empresa española para el servicio Saas o montar tu propio servidor en la nube con los módulos que precises.

Los modelos 340, 347 y 349, exportan a fichero de texto que es compatible con la presentación telemática de Hacienda

JM: Entonces ¿la función de OpenERP que permite exportar a fichero de texto para la presentación telemática del modelo 340 y demas no está?Lo digo porque como la presentación telemática de impuestos (con esos ficheros de texto) es obligatoria, si el modulo básico no permitegenerar estos ficheros entonces no es que se pierda funcionalidad si no usas la localización española, es que es directamente inviable trabajar solo con el módulo básico. ¿estoy en lo cierto?

Y TAMBIEN LA MIA… al 100%

3 días, aproximadamente 600 participantes de mar de 60 países, más de 40 presentaciones!

Acabamos de volver de nuestros 3 días del encuentro anual en Bruselas. Ha sido una magnífica oportunidad para el equipo de openERP compartir la nueva funcionalidad de V7.0, nuestra visión y estrategia para el 2012, trucos para gestionar proyectos de OpenERP y mucho más. Yendo más allá, también ha sido una gran oportunidad para vosotros, nuestra comunidad y partners ver en qué se ha estado trabajando tanto sean desarrollos nuevos o casos de éxito.

Presentaciones: http://slidesha.re/9zuI5o.

Fotos del evento: http://on.fb.me/J3Sk9p

Tweets durante el evento: http://bit.ly/HQImsU

Vuestra opinión es bienvenida : event@openerp.com

Queremos agradecer a todos los participantes por haber venido y compartido nuestra visión y de verdad esperamos que volvais el próximo año a otro encuentro de OpenERP, si cabe, aún más excitante.

Especial agradecimiento a todos los miembros de la comunidad y partners que han presentado algún tema y han contribuido a este increible encuentro de OpenERP: Clientes, comunidad y partners.

Desde OpenERP Team,

Nicoleta Gherlea and Charline Louis

Las jornadas de este año ya están en marcha. Como todos los años por estas fechas, ya empezamos a entusiarmarnos con la idea. Por si aún no habeis leído la noticia, este año serán en Donosti (San Sebastián, Gipuzkoa) organizadas por Avanzosc

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