Estado actual de la localización española. Versión 6.1 y 7.0. Comunidad vs. OpenERP s.a.

Jornadas OpenERP 2013

27 de junio de 2013

Estado actual de la localización española.

Versión 6.1 y 7.0. Comunidad vs. OpenERP s.a.

● Localización española

● Historia de la localización

● Estado actual de la localización

● Futuro de la localización

● Versión 6.1 y 7.0

● Comunidad y OpenERP s.a.

● Dudas y preguntas

Presentación >> Índice

Presentación >> Localización española

“La localización española es un proyecto de la comunidad española de OpenERP con el objetivo principal de hacer OpenERP usable

en España”

- Traducción desde el inglés a los idiomas usados en España: español (principalmente), catalán, gallego y vasco.

- Adaptación de los requisitos legales españoles (contables, fiscales, bancarios...).

- Adaptación de otras peculiaridades españolas.

COMUNIDAD ESPAÑOLA DE OPENERP

Es una organización informal, no reglada, que

agrupa a todos aquellos con algún interés en

OpenERP: integradores, partners, usuarios...

Se basa en la participación desinteresada de los

mismos por el interés y bien común y regida por los

principios de las comunidades de código abierto.


COMUNIDAD ESPAÑOLA DE OPENERP


MÉTODO DE COMUNICACIÓN

El único método de comunicación “oficial” de la comunidad española es la lista de

distribución [email protected]

En ella, se comunican acciones de la comunidad, se pregunta sobre cuestiones

específicas de la localización, se informa de errores, se debate sobre mejoras, se

informa de las jornadas OpenERP ...


mailto:[email protected]

¿CÓMO COLABORAR?

Traduciendo...

https://translations.launchpad.net/openobject-serverhttps://translations.launchpad.net/openobject-addonshttps://translations.launchpad.net/openerp-web


OpenERP, s.a. tiene disponible en el repositorio de código que utiliza(LaunchPad), una parte para la traducción de las cadenas

de texto, denominada Rosetta.

https://translations.launchpad.net/openobject-server

https://translations.launchpad.net/openobject-addons

https://translations.launchpad.net/openerp-web

¿CÓMO COLABORAR?


Traduciendo...

¿CÓMO COLABORAR?


Traduciendo (bien)...

● Traducir adecuadamente según contexto (género, acción o estado...).

● Homogeneizar la traducción del mismo término en distintos lugares.

● Intentar no utilizar anglicismos.

● Repasarlas cuando se usa el software.

¿CÓMO COLABORAR?

Informando de errores...


Los errores (o bugs), pueden provenir de distintos sitios: el núcleo del sistema, los módulos oficiales, los módulos de la comunidad o los módulos de la

localización española. La mayoría se pueden reportar en los correspondientes apartados de

Launchpad:

https://bugs.launchpad.net/openobject-serverhttps://bugs.launchpad.net/openobject-addonshttps://bugs.launchpad.net/openerp-webhttps://bugs.launchpad.net/openerp-spain...

https://bugs.launchpad.net/openobject-server

https://bugs.launchpad.net/openobject-addons

https://bugs.launchpad.net/openerp-web

https://bugs.launchpad.net/openerp-spain

¿CÓMO COLABORAR?

Informando de errores...


¿CÓMO COLABORAR?

Informando de errores (bien)...


● Asegurarse de que el problema es real, y no algo derivado de la instalación en concreto.● Investigar el proceso completo que lleva al error.● Dar el máximo de información sobre el error (versión de OpenERP, traza, etc).● Reportarlo en el lugar adecuado (server, addons, web, localización española, etc).

¿CÓMO COLABORAR?

Colaborando en el desarrollo...


La magia del código abierto es que todo el mundo puede ver la implementación y modificarla, y la

localización española es código abierto.

Cualquiera con conocimientos de Python y OpenERP puede contribuir con mejoras al proyecto o... financiar a alguna empresa desarrolladora para que lo haga (que tampoco pasa nada por rascarse

el bolsillo un poco).

¿CÓMO COLABORAR?

Compartiendo conocimiento...


Un ERP se compone de muchas áreas funcionales, y aunque se domine la parte técnica, tener el

conocimiento específico de todas esas áreas no es sencillo. Por eso, muchas veces algo no se puede implementar (aunque se tengan los conocimientos

técnicos), si no se conoce cuál es la mejora forma de hacerlo.

Abogados, contables, expertos en producción, en logística, etc, están invitados a aportar su experiencia

laboral y sus conocimientos al proyecto.

¿CÓMO COLABORAR?

Ayudando en general a lo que se pueda...


Cuando OpenERP era TinyERP, en su versión 4.2, la comunidad española estaba...

Presentación >> Historia de la localización

Y tuvo que actuar como...


La cosa fue creciendo, adaptándose, hasta decir...


¡He creado un monstruo!

La localización española en la actualidad cubre las siguientes funciones:

Presentación >> Estado actual de la localización

● Impuestos y plan contable actualizado (l10n_es y l10n_es_igic).

● Adaptaciones para los usos tradicionales de la contabilidad española (l10n_es_account).

● Informes contables legales (l10n_es_account_balance_report).

● Gestión de activos española (l10n_es_account_asset).

● Exportación a formatos de la AEAT (l10n_es_aeat...).

Presentación >> Estado actual de la localización

● Ciudades, provincias y comunidades autónomas de España (l10n_es_toponyms...).

● Cierre contable español (l10n_es_fiscal_year_closing).

● Bancos españoles y otros datos de terceros (l10_es_partner).

● Remesas bancarias en formatos AEB (l10n_es_payment_order).

● Gestión de la LOPD (l10n_es_lopd).

● Extractos bancarios en formato C43 (l10n_es_bank_statement).

● Algunas utilidades más...

Si se quiere que la localización sea mantenible en un futuro inmediato, habría que buscar:

Presentación >> Futuro de la localización

Aprovechar nuevas funcionalidades introducidas con las nuevas versiones.

Por ejemplo: la herencia de planes contables, impuestos, etc para el mantenimiento de los múltiples planes españoles en l10n_es.



Aligerar lo máximo posible el código fuente, aprovechando lo existente en el estándar y los mecanismos de herencia de Python y OpenERP.

Por ejemplo: la refactorización del módulo l10n_es_account_asset en la versión 7, heredando sólo las funciones que modificaban su comportamiento.



Utilizar los estándares de facto de la comunidad, para beneficiarse de mejoras comunes y seguir convenciones estándar.

Por ejemplo: la refactorización del módulo l10n_es_toponyms, utilizando el módulo base_location, consensuado en la comunidad en la rama partner-contact-management.

Presentación >> Versión 6.1 y 7.0

● Versión aparecida en febrero de 2012.

● Se supone que iba a ser una versión intermedia entre las dos LTS (6.0 y 7.0), pero...

VERSIÓN 6.1

● Introdujo un cliente web reescrito en JavaScript.

● Introdujo opciones de comunicación vía correo electrónico.

● Interfaz TPV.


● Versión aparecida en diciembre de 2012.

● Nuevo diseño del cliente web.

● Potenciación de la función social.

● En teoría, pocos cambios a nivel funcional.

● Versión LTS.

VERSIÓN 7.0


● En la 6.1, las posibilidades eran muy limitadas y no muy bien pensadas.

● La versión 7 supone una gran mejora por:

LA COMUNICACIÓN

● Granularidad en la selección del comportamiento.

● Posibilidad de “discusiones”.

● Interfaz estilo redes sociales.

● Funciones útiles desde interfaz y código


● La versión 6.1 fue la última versión que soportó el cliente GTK.

● Supone ahorro de tiempo cuando se realizan tareas repetitivas (entrada masiva de pedidos de venta o asientos contables).

● Interfaz “anticuado”.

● Requiere instalación.

EL CLIENTE GTK


● Sin soporte para todas las plataformas (tablets, móviles, etc.).

● La solución pasa por, en lugar de anclarse a ese cliente, mejorar el cliente web universal para obtener las funcionalidades del cliente GTK:

EL CLIENTE GTK (II)

● Ventajas de teclado.

● Velocidad de respuesta.

● Selección extendida...


● Para gustos, los colores, pero...

● Supone una presentación más limpia de los datos, y con posibilidad de destacar ciertos valores.

● Los últimos ajustes realizados en pantallas con muchos datos lo hacen más usable.

● La barra de búsqueda es una mejora sustancial.

● Las posibilidades de extensión son mayores.

EL INTERFAZ


● De manera tapada, se introdujo en la 7.0 un nuevo modelo de datos para res.partner.

● Todos los elementos habituales (direcciones, empresas, contactos) pasan a ser registros del mismo modelo.

● Establece una jerarquía entre ellos.

● Responde a la nueva visión social del ERP.

LOS “PARTNERS”


● Cambia totalmente la visión tradicional de estas estructuras de datos.

● Al principio, no se pensó bien en efectos laterales dentro incluso del propio núcleo.

● En migraciones de datos, hay que pensar más cómo trasladarlos a la nueva estructura.

● A la larga, permite diseñar más situaciones y con más control que la estructura tradicional.

LOS “PARTNERS” (II)


● La versión 7.0, a excepción de los cambios en res.partner, no cambia mucho funcionalmente.

● En este medio año, se ha estabilizado mucho.

● La versión 6.1, lleva más tiempo estabilizada, aunque ambas siguen compartiendo bugs.

● La versión 7.0 es una LTS.

ESTABILIDAD DE CÓDIGO

Presentación >> Comunidad y OpenERP s.a.

OPENERP S. A.● OpenERP s.a. es una compañía belga que está detrás del desarrollo principal de OpenERP.

● Tiene intereses comerciales en la explotación de servicios alrededor del ERP.

● Libera todo el software como código abierto, sin partes premium, aunque sí otros servicios o complementos.

● OpenERP cuenta ya con millones de usuarios.

● Hay grandes empresas integradoras en todo el mundo con más de 7 años de experiencia.

● La Web 2.0 facilita su comunicación, coordinación, visibilidad...

COMUNIDAD DE OPENERP


● La única que lo decide es OpenERP s.a.

● Han ignorado en muchas ocasiones sugerencias de partners reputados.

● Está cambiando el rumbo de las cosas, considerando ya a los partners bastante maduros, como la petición de sugerencias para los cambios logísticos de la 8.0.

RUMBO DEL PROYECTO


● Es un servicio pagado.

● No se considera algo necesario dentro del esquema de código abierto.

● Se vuelve a un esquema de pago por usuario, como en los privativos.

● La respuesta de la comunidad es OpenUpgrade.

MIGRACIONES ENTRE VERSIONES


● Es un servicio pagado, lo que es lógico...● Pero sólo se repara sobre la última versión, aunque el error afecte a todas.● Parches aportados por la comunidad también son sólo aplicados sobre la última versión.● Se realiza así por dos razones: economía de recursos y estabilidad de código de versiones anteriores. ● La respuesta de la comunidad son las ramas comunitarias (OCB).

REPARACIÓN DE ERRORES


● Es el último ejemplo de la política de OpenERP s.a.

● El problema no ha sido el fondo (aunque para muchos es discutible), han sido las formas.

● Una comunicación más eficaz y algo de trabajo en lugar de “que se apañe la comunidad con sus cosas” hubiera ahorrado gran parte del descontento.

CAMBIO DE RES.PARTNER


Estado actual de la localización española. Versión 6.1 y 7.0. Comunidad vs. OpenERP s.a.

Business

Transcript of Estado actual de la localización española. Versión 6.1 y 7.0. Comunidad vs. OpenERP s.a.