Refactorización de l10n_es para OpenERP v7

Introducción

Una de las cosas que más me llamó la atención cuando entré en el mundo de OpenERP y en concreto en el desarrollo de la localización, fue el que cada vez que cambiaba algún impuesto (lo que, desgraciadamente, ha ocurrido demasiado frecuentemente en esta época de crisis), era necesario tocar en varios sitios para que esos nuevos impuestos estuvieran disponibles para los dos posibles planes contables: el PGCE (Plan General Contable Español) completo, y el PGCE para PYMES. Luego llegó como aportación un tercer plan, que es el que deben utilizar las entidades sin ánimo de lucro, y la tarea entonces se triplicaba.

Había dos razones principales para que esta cuestión no cambiara:

  • Por un lado, una cuestión técnica, ya que OpenERP no incluía ningún mecanismo para poder compartir esos datos. Con la versión 6.1, y sin demasiado bombo, se introdujo en el core de OpenERP la posibilidad de que los planes contables pudieran tener padre, y heredaran de esa forma ciertas cosas del mismo, como cuentas, impuestos, etc, lo que abría una puerta a simplificar nuestros datos. Pero la implementación no terminaba de ser lo suficientemente buena, tanto en la 6.1 como en la 7.0, y gracias al excelente trabajo como siempre de Olivier Dony, conseguimos mejorarla para que cubriera la casuística española, introduciendo en la revisión 9499 de openobject-addons el parche necesario para que todo funcionara correctamente.
  • Por otro, había que editar la cantidad ingente de datos XML que componían todos los archivos, lo cual es una tarea muy pesada y bastante proclive a errores, pero que con algunas automatizaciones, mucha paciencia, y sobre todo, comprobaciones posteriores, se ha logrado hacer.

Estructura del nuevo l10n_es

El nuevo l10n_es se compone de cuatro planes contables: l10n_es_common , l10_es_full , l10n_es_pymes y l10n_es_assoc . El primero es un plan contable común que no es visible para el usuario, y que reúne todos los datos comunes que tienen los otros tres planes contables: códigos de impuestos, impuestos y cuentas comunes. Los otros tres, que heredan del primero, corresponden respectivamente al plan completo, al de PYMEs y al de asociaciones (entidades sin ánimo de lucro).

Hablando de archivos, el módulo tiene la siguiente estructura:

  • account_chart_template.xml : Definición de los cuatro planes contables.
  • account_chart_template_post.xml : El contenido de este archivo, con el resto de la definición de los planes contables (la raíz de los impuestos y las cuentas por defecto), se ha tenido que separar del primer archivo para su carga al final, ya que no se pueden definir dichos datos si aún no están cargados, pero a su vez tampoco se pueden añadir si no se tiene ya cargado el plan de cuentas, porque contienen una referencia a él.
  • account_type.xml : Tipos de cuenta, que se utilizarán luego para el cierre contable.
  • account_account_common.xml : Cuentas comunes para todos los planes.
  • account_account_assoc.xml : Cuentas exclusivas del plan contable para asociaciones.
  • account_account_full.xml : Cuentas exclusivas del plan contable completo.
  • account_account_pymes.xml : Cuentas exclusivas del plan contable para PYMEs.
  • fiscal_templates_common.xml : Posiciones fiscales, que son comunes a todos los planes.
  • tax_codes_common.xml : Códigos de impuestos, igualmente compartidos por todos.
  • taxes_common.xml : Impuestos, que también se definen sólo una vez.

Mejoras introducidas

Como ya se ha comentado, una de las principales mejoras en esta refactorización es que cuando cambien de nuevo los impuestos o las posiciones fiscales, sólo habrá que definir una vez en lugar de tres esos nuevos impuestos.

También se ha aligerado mucho el nº de registros introducidos en la BD al eliminar los códigos de impuestos, los impuestos y las posiciones fiscales por triplicado, pero sobre todo las cuentas que compartían los tres planes, pasando de 4743 registros a sólo 1926 (un 40%). A la vez que revisaba los árboles de cuentas, he descubierto también varias erratas en los mismos que he pasado a corregir, como nombres incorrectos o padres de las cuentas equivocados.

En los impuestos, había algo que se había tomado siempre bastante a la ligera: la dualidad de los campos name y description . Se supone que el campo name está destinado a guardar un código para identificar al impuesto y que, como tal, debe ser único. El campo description ya sirve para poner el nombre completo del mismo de manera legible. En la anterior definición, en algunos casos sólo estaba relleno el primer campo, pero no el segundo, o en otros estaban rellenos los dos con el mismo valor, apareciendo en algunos informes o pantallas una cadena larguísima resultante de la concatenación de ambos. Por eso, he nombrado a cada impuesto con un código corto que lo identique, al estilo de 'P_IVA4_BC', y colocado en el campo description la cadena completa del impuesto. Además, he homogeneizado la nomenclatura de todos los impuestos, ya que por ejemplo en algunos sitios se hablaba de "operaciones corrientes" y en otros de "bienes corrientes". Este renombramiento tal vez pueda ser conflictivo para alguno de los módulos de la AEAT, si los mismos utilizan el nombre del impuesto para sus cálculos, pero lo comprobaré a continuación.

Como añadido, he dado un repaso a los tipos de cuenta, eliminando tipos que ya se encuentran de manera estándar en OpenERP 7, y renombrando los otros para que sean más fáciles de reconocer.

Por último, he incluido un script de migración para que todos aquellos que ya tenían el módulo l10n_es para la versión 7 instalada, puedan actualizar sin problema.

Próximos pasos

Ahora, la refactorización debe ser incluida en los correspondientes repositorios. He hecho una propuesta de inclusión en el repositorio de la localización española:

https://code.launchpad.net/~pedro.baeza/openerp-spain/7.0-l10n_es-refactorized/+merge/196807

como primer paso, aunque tengo el compromiso por parte de Olivier Dony de incluirlo en el repositorio oficial, por lo que no sería ya necesario mantener el módulo en la localización española. Aquí está la propuesta de inclusión en dicho repositorio:

Se agradecería el que lo revisarais y aportarais vuestros comentarios a ambas propuestas.

Actualización 03/06/2014:

He actualizado y pasado al nuevo CVS (GItHub) la solicitud para la inclusión del módulo en el core, y ha sido aceptado casi sobre la marcha:

https://github.com/odoo/odoo/pull/329

Un saludo.

Pedro M. Baeza

Comentarios

# Joaquin Gutierrez 27-11-2013 11:43
Hola Pedro:

Grandioso el trabajo y la explicacion quedando claro el porque y el como de todo.

Gracias por tu trabajo.
Responder | Responder con una citación | Citar