Visit www.invinet.org

¿Hacía falta Facturae 3.2.1?

El pasado viernes 28 de marzo de 2014 se publicó en el BOE la resolución sobre la nueva versión del formato de factura “Facturae”,  la versión 3.2.1.

Se trata concretamente de incorporar 4 cambios respecto al formato 3.2 que es el que se está utilizando de forma general (aunque muy poco, sea dicho de paso) en España:

  1. Se crea un nuevo tipo de datos, el DoubleUpToEightDecimalType, y se asigna a una serie de  importes: Todos los importes que en Facturae 3.2 eran DoubleSixDecimalType (una restricción que exigía que el número tuviera 6 decimales), ahora se han cambiado al tipo DoubleUpToEightDecimalType, que permite poner desde 1 hasta 8 decimales.
  2. Se modifica el tipo de datos DoubleTwoDecimalTypede modo que se obliga a especificar dos decimales“, creando una nueva expresión regular.
  3. Se amplia la lista de códigos asociados a TaxTypeCode, con los siguientes códigos:
    • Impuesto sobre las Primas de Seguros.
    • Recargo destinado a financiar las funciones de liquidación de entidades aseguradoras.
    • Impuesto sobre el valor de la producción de la energía eléctrica.
    • Impuesto sobre la producción de combustible nuclear gastado y residuos radioactivos resultantes de la generación de energía nucleoeléctrica.
    • Impuesto sobre el almacenamiento de combustible nuclear gastado y residuos radioactivos e instalaciones centralizadas.
    • Impuesto sobre los Depósitos en las Entidades de Crédito.
  4. Se añaden los siguientes ejemplos de referencias legales en el comentario que explica el campo destinado a incorporar referencias legales en la factura (LegalLiteralsType)

Es decir, se ha creado una nueva versión de Facturae para :

  • Permitir números de hasta 8 decimales en lugar de un fijo de 6 decimales en algunos importes. Este cambio está bien porque evita tener que poner siempre 6 decimales en la mayoría de importes de Facturae. Sin embargo, quién dispone de un sistema de gestión capaz de recibir y procesar importes con 8 decimales? Porqué se incorporan al estándar longitudes y/o restricciones sobre el número de decimales?
  • Cambiar la restricción en un tipo de datos para obligar a especificar dos decimales en algunos importes. En primer lugar, la restricción descrita en el BOE es errónea, le faltan unos paréntesis, pero más allá de este detalle, este cambio era innecesario ya que este mismo tipo de datos en Facturae 3.2 ya obligaba a especificar 2 decimales. Porqué se ha hecho este cambio?
  • Ampliar una lista de códigos con cinco nuevos elementos. Definir las listas de códigos dentro de los propios esquemas obliga a cambiar la versión del esquema cada vez que cambia (o se añade) alguno de los datos de la lista. Este problema se ha identificado hace tiempo, y las principales iniciativas de estandarización internacional ya utilizan listas de códigos externas para evitar este problema. De hecho, esto ya lo avisábamos hace algunos años en este post.
  • Añadir un comentario al esquema. Sin comentarios.

La estabilidad en los estándares es buena y necesaria si lo que se pretende es que sean adoptados. No recomendaría que se fueran cambiando los formato de los enchufes, o los conectores de los cargadores de los móviles muy a menudo, porque esto iría totalmente en contra de su adopción en el mercado.

Por pequeños que sean los cambios, y por más que la propia resolución indique que “Esta versión tiene la característica de ser compatible hacia atrás con la versión 3.2, es decir, una factura conformada según la versión 3.2 será interpretada correctamente por un programa que se ajuste a la versión 3.2.1. Lo contrario, en cambio, no es cierto en todos los casos.“, lo cierto es que estos pequeños cambios implican ajustes e inversiones en los sistemas que generan y reciben documentos en formato Facturae. Deberán diferenciar entre Facturae 3.2 y Facturae 3.2.1, deberán permitir la recepción de importes con hasta 8 decimales donde antes sólo tenían que contemplar 6 o deberán incorporar a sus validaciones seis nuevos códigos de impuestos.

Y es que a Facturae 3.2 si que le hace falta un cambio, pero un cambio en profundidad, para adecuarlo realmente a los estándares internacionales y corregir algunos de los errores que tiene. Y estos cambios se habían realizado ya en el año 2010, con Facturae 4.0, un modelo basado en el modelo descrito en el CEN BII y que podría haber ayudado a convergir el formato Facturae al que se está imponiendo en muchos países europeos de la mano de la red pan-europea PEPPOL.

No comprendo porqué se ha impulsado esta nueva versión de Facturae, con estos cuatro cambios insignificantes y que no ayudan, sino que más bien ponen palos en las ruedas a su difusión y adopción.

Creo que no hacía falta Facturae 3.2.1, y que su publicación es otro error más en la estrategia sobre Factura Electrónica en España.

4 Comments

  1. Posted 16/04/2014 at 2:56 PM | Permalink

    Parece que han procedido a corregir los errores detectados en este post. Ver CORRECCIÓN DE ERRORES en http://www.facturae.es/es-ES/Documentacion/EsquemaFormato/Paginas/Index.aspx

  2. Lluis Martinez
    Posted 25/11/2014 at 2:57 PM | Permalink

    Si les llibreries Java per la versió 3.2.1 són com les 3.x ja podem plegar. Quin horror.

  3. Lluis Martinez
    Posted 21/01/2015 at 1:09 PM | Permalink

    No existeixen llibreries Java del Ministeri per la versió 3.2.1 de fet ja no existeix ni la pàgina. Suposo que es van adonar del merder que estaven provocant.

  4. Oriol Bausà
    Posted 21/01/2015 at 2:42 PM | Permalink

    Gràcies per la noticia Lluís. Tanmateix, no sé si és bona o dolenta…

Post a Comment

Your email is never shared. Required fields are marked *

*
*