Archivo de la categoría: CII – Cross Industry Invoice

Informe final del Grupo de Expertos en Factura Electrónica


El Final Report of the Expert Group on e-Invoicing es el resultado de más de un año de trabajo de más de 30 expertos de toda Europa.

Junto con conclusiones que verdaderamente pueden ser de consenso se incluyen otras que parecen sesgadas por determinados intereses políticos, y en defensa de algunas posiciones particulares.

El informe tiene partidarios y detractores como puede verse en estos blogs:

Las dos posiciones son relevantes porque de la tesis «triunfadora» depende el consenso para la modificación de la Directiva 2006/112/EC, cuyo borrador actual está disponible.

La posición mayoritaria en España es que no es conveniente cambiar las reglas del juego a mitad del partido, y que tampoco es aceptable, ni siquiera dar a entender que se pueden cambiar. El efecto que tendría es que todos los jugadores se pararan hasta que queden claras las reglas de nuevo, ralentizando la expansión de la factura electrónica. Otra posición mayoritaria en España es que tampoco se deben cambiar las reglas de forma que favorezcan a los más lentos (o a los más torpes) del mercado pero con gran potencia de lobby como algunas entidades financieras europeas (afortunadamente, no las españolas).

Entre todos los conceptos que se manejan, el más peligroso es el de «equal treatment» refiriéndose a un tratamiento igual de las facturas electrónicas respecto a las de papel. Y sin definir qué significa eso.

Para ser correcto, debería llevar la coletilla latina «mutatis mutandi», que significa que se aplica la semejanza cambiando lo que haya que cambiar, como consecuencia de la diferencia de soporte que conlleva formas diferentes de gestionar. Por ejemplo, en una factura en papel se le puede poner el sello «pagado» sobre el documento original. Eso no es tan fácil de representar en un documento electrónico, salvo que se tengan en cuenta parámetros de autenticidad electrónica que algunos de los expertos pretenden eliminar de la factura electrónica.

En todo caso, mi posición personal es que no se puede imponer un modelo que cada vez es menos seguro (el del papel) sobre otro que nace con cierto nivel de seguridad. Por el contrario, dado que las facturas en papel son fácilmente falsificables se debería imponer una exigencia de seguridad adicional (se me ocurren varias: usar papel con marcas de agua, usar papel timbrado, usar papel con marcas de trepado, por ejemplo indicando el CIF del emisor, usar papel con tintas ultravioletas,…)

Por todos estos argumentos y algunos más estoy preparando un documento que recoja la posición española a favor del mantenimento de la firma electrónica de las facturas electrónicas en la Directiva 2006/112/CE, y de la adopción internacional a corto de plazo del estándar UBL, sin perjuicio de una migración futura a CII, cuando la norma esté más madura. La idea es enviarlo a la UE en el marco de la consulta  «Consultation on the Final Report of the Expert Group on e-Invoicing».

Estoy abierto a que me envieis comentarios y sugerencias para su inclusión en el documento, pero recordad que el período de la consulta se extiende desde el 30.11.2009 hasta el  26.2.2010, por lo que tengo que enviar el documento en inglés antes del cierre del plazo. Si alguien quiere contactar conmigo para este tema, que llame al 902 365 612.

Ejemplo de factura en UBL, CII, facturae


En nuestro Roadmap de productos relacionados con la factura electrónica se incluye soporte para los formatos facturae (ahora en la versión 3.2), UBL (Universal Business Language) y CII (Cross Industry Invoice).

De todos los formatos, por nuestra experiencia, el UBL es el más completo y el mejor documentado, y el que debería utilizarse en las transacciones internacionales. Entre sus ventajas está la de que desde hace tiempo existen traducciones de todas sus etiquetas a la mayor parte de los idiomas (entre ellos el español), por lo que se evitan ambigüedades y errores de adopción en cuanto al significado de los campos.

Además es el que se está adoptando a nivel internacional, y, posiblemente en España, en el marco del eProcurement (Contratación Pública Electrónica). El Grupo de Trabajo de CEN BII (Business Interoperability Interfaces on public procurement in Europe), ha partido del modelo de contratación pública CODICE desarrollado por la Dirección General de Patrimonio del Estado (que ha demostrado ser una decisiva contribución española a la interoperabilidad europea) para crear el marco de referencia de los nuevos mensajes de licitaciones y contratación pública a partir de los bloques constructivos de UBL desarrollados por OASIS.

Por otro lado, se han desarrollado muchas expectativas respecto al formato CII (Cross Industry Invoice) que representa la concreción por parte de los grupos de trabajo de Naciones Unidas (United Nations Centre for Trade Facilitation and Electronic Business) de la iniciativa de unificar diferentes esfuerzos de estandarización. En este marco, los avances han sido decepcionantemente lentos. El documento de Business Requirement Specifications (BRS) for the Cross Industry Invoice V.2.0 se aprobó en noviembre de 2008 y la última modificación es de mayo de 2009. El esquema de CII se finalizó en el Foro UN/CEFACT que tuvo lugar el 30 de septiembre de 2009 en Sapporo (Japan), en el que estuvieron presentes 200 expertos de 30 países.

Sorprendentemente, el esquema de la «versión 2.0» de CII viene identificado como versión 1.0 del esquema, lo que sirve para despistar aún más, ya que eso implica que la versión 1.0 de CII nunca pasó de la fase de borrador, y la versión 2.0 (borrador) fue la que dió lugar a la versión 1.0 definitiva a la que todo el mundo se refiere como versión 2.0

La escasa y contradictoria documentación disponible sobre CII y el hecho de que se basa en Core Components, al igual que UBL, especificación mucho más madura, definitivamente hace más recomendable empezar por implementar UBL sabiendo que en cualquier momento en el futuro (cuando el estándar madure) será posible transformar una factura UBL en una UN/CEFACT. En todo caso, los Core Components están perfectamente mantenidos por UN/CEFACT, son comunes a ambas implementaciones.

En nuestro caso, hemos intentado implementar todas las versiones en nuestros desarrollos interinos, pensando en extender las funcionalidades de FactOffice y aquí presentamos una factura de ejemplo, codificada en cada formato de los mencionados: