Localización española

Introducción

La localización española son una serie de módulos (18 actualmente), que permiten adaptar Odoo a las necesidades específicas de las normas de contabilidad españolas.

Los módulos oficiales de Odoo proveen información de utilidad para el departamento financiero, como pueda ser la contabilidad analítica o presupuestaria, informes de estado, etc. Además, los módulos de localización española permiten realizar las declaraciones oficiales a la A.E.A.T, cierre anual, etc. ofreciendo las funcionalidades de la normativa española.

Funcionalidades cubiertas

Los módulos de la localización española cubren actualmente las siguientes funcionalidades:

• Definición de plantillas para poder crear planes contables según las normas oficiales, tanto estándar como PYMEs, en su versión PGCE 2008.
• Definición de plantillas de impuestos: IVA, recargo de equivalencia y retenciones IRPF.
• Y, definición de las distintas posiciones fiscales necesarias para cubrir los distintos casos de IVA: régimen general, intracomunitario o extracomunitario.
• Generación de los informes necesarios para su presentación al cierre de año:
  • Balance de situación (Normal, abreviado o PYMEs según PGCE 2008).
  • Cuenta de pérdidas y ganancias (Normal, abreviado o PYMEs según PGCE 2008).
• Cierre de ejercicio, con creación de asientos de regularicación, cierre y apertura del siguiente ejercicio.
• Inclusión de un asistente para la generación automática de cuentas contables según el código de cliente/proveedor.
• Generación de las declaraciones para la Agencia Tributaria:
  • Modelo 303: IVA. Impuesto del Valor Añadido. Autoliquidación.
  • Modelo 340: Declaración informativa de operaciones incluidas en los libros registro.
  • Modelo 347: Declaración anual de operaciones con terceras personas.
• Inclusión de las comunidades autónomas, provincias, municipios y códigos postales españoles.
• Mejoras en la ficha de empresas (clientes y proveedores), incluyendo los siguientes cambios:
  • Adición del nombre comercial.
  • Adición de un nombre de mayor longitud, CIF y web a los bancos.
  • Inclusión de los datos de las entidades registradas en el Banco de España.
  • Validación de los dígitos de control de las cuentas bancarias.
  • Adición de los campos de registro mercantil (registro, tomo, libro, folio, sección y hoja).
• Importación de extractos bancarios según la normativa C43 de la Asociación Española de Banca, lo que permite la conciliación automática de cobros y pagos a través de banco.
• Generación de ficheros según las normativas AEB 19, AEB 58 y AEB 34, que permiten ordenar recibos domiciliados, anticipos de crédito y transferencias respectivamente a las distintas entidades bancarias.

IV Jornadas OpenERP

ACTUALIZACIÓN: IV Jornadas OpenERP. Presentación y exposición del estado de la localización española realizada por Borja López en Slideshare.net.

ACTUALIZACIÓN: Tal como se ha estado debatiendo en éstas últimas fechas en el grupo de la localización española de google-groups y como indico Pedro Manuel Baeza en un excelente resúmen, el estado técnico de la localización española para la versión 7.0 de OpenERP es el siguiente:

Módulo principal

• ln10_es: Módulo principal de la localización. Incluye las plantillas para planes de cuentas, códigos de impuestos e impuestos que se manejan aquí en España. Se compone únicamente de archivos XML, pero supone un gran porcentaje del nº de líneas de XML que mostrabas en tus estadísticas, ya que el nº de cuentas e impuestos que se maneja en España es muy elevado, y además ese número se triplica, al haber tres plantillas de planes (el completo, el reducido para PYMEs (SMEs) y uno especial para asociaciones sin ánimo de lucro). Estado de la migración: Migrado y fusionado en el core de la 7.0, pero existe un pequeño bug que aún no se ha solucionado. En la rama openerp-spain sí que dicho bug está solucionado. Refactorización: Gracias a una pista que me dio Olivier Dony, estoy llevando a cabo una refactorización para intentar eliminar duplicidades en los XML. Por ahora, he podido hacerlo con los impuestos, pero un bug y una duda me impide que esto funcione al 100%. Estoy en espera de la contestación por parte de Olivier. Con las cuentas contables, no debería haber especial problema.

Módulos de ciudad y datos en diarios

• city: Este módulo es una utilidad de la que echa mano el módulo l10n_es_toponyms, que permite completar automáticamente todos los campos de la ciudad (city, zip, state, country) a partir de un nuevo modelo. Se intentó incluir este módulo en la rama partner-contact-management, pero no hubo mucho interés ni éxito, ya que el debate se centró más en la versión 7. Puesto que la versión 6.1 ya está fuera del foco de desarrollo, se decidió incluirlo aquí para que la gente no tuviera que recurrir a repositorios privados. Estado de la migración: Como resultado de un gran trabajo de colaboración de la comunidad, se consiguió un nuevo módulo denominado base_location, que es en el que se basa el l10_es_toponyms de la versión 7.
• l10n_es_toponyms: Este módulo se compone básicamente de datos (más un asistente para su importación escogiendo unas mínimas preferencias), y coge como base de esos datos el módulo mencionado anteriormente. Aunque no es imprescindible, ya que la gente puede teclear los datos de las ciudades cogiéndolos de otras fuentes de información, sí que es altamente recomendable. Estado de la migración: Completamente migrado y funcional. Refactorización: Se ha rehecho el asistente para que herede de res.config.installer y se ejecute automáticamente. También se han creado nuevos scripts para obtener los datos actualizados de todas las poblaciones. Más info.
• nan_account_invoice_sequence: Este módulo añade otra secuencia en los diarios, que es la que se asigna como nº de factura en lugar de la habitual, ya que en España es obligatorio llevar una numeración consecutiva para todas las facturas. Por tanto, su uso en la localización es imprescindible. Estado de la migración: Completamente migrado y funcionando. 

Módulos financieros

• l10n_es_partner: Contiene algunas personalizaciones de nuevos campos en el res.partner y en los bancos. Incorpora además los datos de todos los bancos españoles. Su uso también es altamente recomendable, aunque no imprescindible. Estado de la migración: Totalmente migrado y probado. Refactorización: Pequeños cambios realizados para mejorar su uso en la v7.
• l10n_es_account_asset: Módulo que permite manejar activos en España, ya que el método de cálculo y la fecha de imputación no son los mismos que el estándar. Para aquellos que utilicen la contabilidad y gestionen activos, es totalmente imprescindible. Estado de la migración: Completamente migrado y funcionando. Refactorización: Ha sido una de las refactorizaciones más grandes realizadas hasta ahora, ya que en su momento, por falta de tiempo para desarrollo, se realizó un fork del módulo account_asset, haciendo dichos cambios en él. Ahora, se ha heredado del módulo estándar, sobreescribiendo los métodos correspondientes para minimizar lo máximo posible el código a utilizar.
• l10n_es_account_balance_report: Este módulo incluye datos que, utilizando como base el módulo account_balance_reporting que se generó en su momento con propósito genérico en extra-addons, y que ha estado en el limbo hasta hace poco, permite generar los informes financieros que de manera legal hay que presentar en el cierre del ejercicio. Estado de la migración: Sin realizar, pero no es tan urgente puesto que las cuentas se presentan a final de año, aunque hay gente que lo utiliza para ver su estado financiero en mitad del ejercicio. Refactorización: La idea es intentar aprovechar el motor de informes financieros que incorpora OpenERP. Este motor tiene una pega principal, y es que sólo permite trabajar con un ejercicio fiscal, pero en España se requiere que los informes presenten la información del ejercicio actual y del anterior. MalagaTIC va a encargarse de mirar posibilidades de adaptación del estándar.

Módulos contables I

• l10n_es_fiscal_year_closing: Este módulo incluye un proceso de cierre contable propio, debido a las peculiaridades que se dan en España en el cierre (movimiento de saldos a cuentas específicas, eliminación de saldos en otras, etc). El módulo es imprescindible,. pero sólo necesario al final del ejercicio, que para la mayoría de empresas es al final de año. Estado de la migración: Dada su prioridad más baja, aún no está realizada la migración. Refactorización: Se quiere ver si extendiendo el proceso de cierre contable estándar se pueden cubrir los requisitos españoles. Joaquín Gutierrez va a encargarse de este análisis.
• l10n_es_aeat_*: El módulo base sin sufijo incorpora una serie de utilidades para la exportación de archivos de longitud fija y un modelo base del que heredan el resto de módulos, y permite gestionar la presentación de obligaciones fiscales con la Hacienda española. Aunque muchas de estas obligaciones se pueden presentar rellenando los datos manualmente a partir de información dentro del propio OpenERP, su uso agiliza mucho este trabajo y para empresas con gran volumen contable se hace totalmente imprescindible. Estado de la migración: La adaptación está en un estado muy avanzado. Acysos se está encargando de ella. 

Módulos contables II

• l10n_es_payment_order: Utilizando como base el ya veterano módulo account_payment_extension, incorpora la posibilidad de exportar órdenes de pago/cobro que agrupan más de una factura a un formato estándar (más o menos, jeje) establecido por la AEB (Asociación Española de Banca) para los distintos usos bancarios (cobros, pagos, domiciliaciones, etc). Su uso es recomendable siempre e imprescindible para grandes volúmenes. Estado de la migración: Acysos tambien se está encargando de ella. Refactorización: Se ha realizado para la versión 6.1, lo que va a hacer que la adaptación para la 7 sea trivial, pero dependiendo igual de account_payment_extension. Existe una gran cantidad de código para el manejo de los archivos. Nuestro compañeros españoles de Tryton han hecho una librería denominada retrofix que tal vez podría facilitar ese manejo, pero el problema principal aquí es del marco legal, que está pendiente el cambio a la nueva norma SEPA, que fija unos estándares a nivel europeo, por lo que no merece la pena mucho ahondar en una optimización. Además, hay que aclarar a nivel de comunidad por qué camino se va en este sentido (si con account-payment_extension o con banking-addons) para intentar adherirnos a los estándares.
• l10n_es_bank_statement: Este módulo utiliza como base otro que se creó también con propósito genérico, nan_account_bank_statement, para poder importar de manera automatizada y casar pagos y cobros con el extracto bancario según el formato estándar de la AEB. Estado de la migración: Acysos tiene marcada dicha migración, pero desconozco su estado actual. Refactorización: Un buen camino a tomar para aligerar código y adherirse a estándares, aunque sean de la comunidad, es utilizar los banking-addons como base, pero ante la incertidumbre por todo el cambio a SEPA, no está claro cómo van a funcionar los extractos bancarios en un futuro más o menos cercano, por lo que puede no merecer la pena el trabajo.

Módulos de facturación

• l10n_es_account_invoice_sequence_fix: Pequeña utilidad que repara aquellas instalaciones que han instalado el módulo nan_account_invoice_sequence después de haber generado facturas. Estado de la migración: Sin migrar. Refactorización: Se mirará si sigue siendo necesario en la v7 y, si es así, se integrará en el propio módulo l10n_es_account_invoice_sequence para que se realice de manera transparente para el usuario.
• l10n_es_facturae: Este módulo está pensado para la generación de factura electrónica, pero desde hace tiempo no funciona (y no sé si en algún momento llegó a funcionar). La factura electrónica no es obligatoria, y es más una molestia (preparación de certificados, etc) que algo útil (no se le ha dado validez legal en litigios), pero se supone que en un plazo no demasiado largo sí que será obligatorio. Por ello, será imprescindible que tanto para la 6.1, 7.0 u 8.0 se desarrolle el módulo correspondiente. Estamos empezando a organizarnos con ello. Estado de la migración: Sin realizar.
• l10n_es_gestion_comercial: Incluye la posibilidad de una gestión de efectos comerciales más profunda que con OpenERP (impagables, incobrables, en cartera de efectos, etc). Esta cuestión, aunque no debe ser específica de España, por ningún lado se ha tratado, y de ahí que se incluyera en la localización. Es obligatoria según las normas contables españolas, aunque se puede solventar haciendo los apuntes contables manualmente. Estado de la migración: Pendiente de una refactorización para la 6.1 que está terminada y en proceso de revisión, realizada entre Soluntec, Avanzosc y yo, pero no debería ser muy complicada. Refactorización: El módulo aprovecha muy bien la función estándar del voucher para acometer su funcionalidad, por lo que no se plantea una mayor refactorización que la hecha para la 6.1.

Módulos de utilidad I

• l10n_es_igic: Permite establecer unas peculiaridades a nivel de impuestos que se dan en las Islas Canarias. Sólo necesario para aquellos canarios que utilicen OpenERP. Estado de la migración: Sin migrar.
• acy_partner_correos: Este módulo sí que se puede considerar una utilidad, y no es imprescindible para la localización. Permite exportar los contactos para la oficina virtual de correos. Estado de la migración: Sin migrar.
• base_vat_vies: También dentro de la categoría de utilidad, permite validar un NIF (VAT number) contra un webservice de VIES, que es un servicio para determinar quiénes pueden importar/exportar en la Unión Europea sin cargar impuestos. Estado de la migración: Sin migrar.

Módulos de idioma

• l10n_cat_account: Tal como se ha comentado previamente, este módulo traduce el plan de cuentas catalán de la mejor manera técnica posible. En principio, no debe ser imprescindible, a no ser que en Cataluña (una región española con idioma co-oficial con el español, el catalán) obliguen a presentar las cuentas en catalán (Albert, ¿podrías aclararlo?). Creo que el origen histórico de éste y otros módulos l10n_cat procede de que las primeras empresas que impulsaron la localización eran catalanas (ZikZak Media y NaN) y, sin ánimo de levantar polémicas nacionalistas, se intentaba “catalanizar” todo. Estado de la migración: Sin migrar.
• l10n_cat_toponyms: Incorpora subdivisiones territoriales que se usan sólo en Cataluña. Para el resto de españoles no es de utilidad, y no sé si las empresas catalanas lo están utilizando. Una posibilidad podría ser la de crear otro repositorio distinto a openerp-spain, por ejemplo openerp-cat u openerp-catalonia, para albergar este tipo de peculiaridades catalanas, ¿no os parece?. Estado de la migración: Sin migrar.
• l10n_cat_partner_data: Este módulo sólo aporta unos cuantos datos de categorías y canales en catalán y, al igual que el l10n_es_partner_data, para mí son totalmente prescindibles y los eliminaría del repositorio de la 7. No sé si alguien los estará usando. Si es así, que por favor se pronuncie. Estado de la migración: Sin migrar.
• l10n_es_partner_data: Ídem que para l10n_cat_partner_data.

Módulos de utilidad II

• l10n_es_account: Pequeñas utilidades para búsquedas o filtros que son opcionales. Bastante prescindible. Estado de la migración: Sin migrar.
• l10n_es_auto_fiscal_position: Pequeña utilidad para establecer automáticamente la posición fiscal. Opcional. Estado de la migración: Sin migrar.
• l10n_es_hr_nominas: Incluye algunos cambios para la gestión de nóminas en España. Realmente, ésta es una funcionalidad residual, ya que las nóminas en España son muy complejas de realizar por la multitud de convenios, desgravaciones, complementos, etc, y nadie o casi nadie utiliza OpenERP para este fin. No es, por tanto, muy necesario por el momento. Estado de la migración: Sin migrar.
• l10n_es_lopd: Permite manejar algunos conceptos de la LOPD (Ley Orgánica de Protección de Datos), como el registro de los ficheros privados, pero no conozco este módulo a fondo. Esta gestión se puede llevar en otro sistema o manualmente, por lo que podemos categorizarlo como opcional. Estado de la migración: Compuservice, que fue la creadora original del módulo, está puesta como responsable de la migración, pero desconozco su estado.
• l10n_es_partner_mercantil: Pequeño módulo que añade unos pocos campos a res.partner. Opcional. Estado de la migración: Sin probar, pero debería funcionar directamente.

Módulos de utilidad III

• l10n_es_partner_seq: Módulo para la creación automática de subcuentas para cada cliente. Esto provoca una duplicidad de datos, un rendimiento mucho menor al haber mayor número de cuentas (tantas como clientes, proveedores, acreedores, impagados, etc), y un posible problema de escalabilidad si se supera el nº de dígitos que se han dejado para las cuentas. Pero hay gente en España y contables difíciles de convencer que siguen queriendo ese uso. Estado de la migración: Sin migrar.
• l10n_es_prev_tesoreria: Este módulo también podría considerarse una utilidad para hacer una previsión de tesorería. Incluso podría tener un carácter más genérico que sólo para España. Opcional. Estado de la migración: Sin migrar.
• l10n_es_pyme_account: Meta-módulo que simplemente incluye dependencias a lo que se considera un paquete estándar para la contabilidad de una PYME. Estado de la migración: No necesaria.
• l10n_es_toponyms_region: En España existe dos subdivisiones del territorio: comunidades autónomas y provincias. Este módulo cubre la primera división, que no se considera en l10n_es_toponyms. No se suele utilizar en casi ninguna referencia, por lo que también se puede catalogar de opcional. Estado de la migración: Sin migrar. Refactorización: Una vía de trabajo muy buena es la que se ha hecho en Tryton y que Jordi Esteve me proponía en la lista de correo.

Agradecer a Pedro Manuel Baeza el trabajo de recopilación realizado y a Alejandro de Anubia por la traducción al inglés realizada. También destacar el papel de Nhomar de Vauxoo dando impulso y reactivando éste tema.

Para más información sobre OpenERP visita nuestra web haciendo un clic aquí.