Visit www.invinet.org

Extensiones en los modelos de factura electrónica

Ya desde los tiempos del EDI se ha podido comprobar que crear modelos exhaustivos de datos para definir documentos electrónicos no es una gran idea. Uno acaba con conjuntos gigantescos de posibles elementos de datos en un documento que luego, a la hora de la verdad, cuando lo estudia un programador para realizar una integración en su sistema de información, le parece impracticable. No tiene mi aplicación ni una cuarta parte de los elementos que hay en un modelo de factura EDI! A partir de este momento, el programador debe decidir qué elementos va a utilizar, y es ahí donde aparecen los problemas de interoperabilidad. Lo que decida yo, ya sea yo una persona, un consultor EDI o un colectivo, no tiene porqué coincidir con lo que ha decidido mi interlocutor o un miembro de otro colectivo.

Pero es cierto también que hay sectores en la industria que tienen peculiaridades importantes, y que estas peculiaridades se deben tener en cuenta cuando se transaccionan documentos como facturas o pedidos entre clientes y proveedores, de manera que se pueda procesar automáticamente esta información en el sistema del receptor. El objetivo siempre debería ser el procesado automático de la información, modelar en un documento información que no va a ser procesada por el receptor eleva la complejidad del modelo y no añade valor.

Para superar el antiguo método de “modelo de datos donde todo cabe” y “personalizaciones” (o interpretaciones), desde el CEN BII se ha definido una nueva arquitectura para los modelos de documentos, basada en “modelo mínimo de información que todos debemos compartir y entender” y “extensiones“. Esto implica que aunque los documentos electrónicos sean intercambiados entre sectores distintos, siempre hay un core de información  que podrá entender cualquier sistema , y se podrá ignorar la información de las extensiones, es decir, no procesarla automáticamente,  guardándola únicamente para su revisión manual.

Con el CORE tenemos un común denominador en la información que estamos transmitiendo, y las extensiones son toda aquella información adicional que puede ser que no entienda nuestro interlocutor porque no es de nuestro mismo sector o de nuestro mismo país.

Este modelo es el que se está impulsando desde el BII. La figura a continuación creada por Georg Birgisson ilustra el uso de las extensiones dentro del ámbito del CEN BII.

Dentro de un mismo país o dentro de un mismo sector, las empresas pueden intercambiar documentos con el core más las extensiones específicas de dicho sector o país. En cambio, cuando se trata de mandar documentos entre distintos sectores o entre distintos países, sólo aplicarían aquellas reglas conocidas por ambos colectivos, es decir el core en el caso transfronterizo o el core más las extensiones nacionales en el caso de intercambio de documentos dentro de un mismo país pero sectores distintos.

Uno de los trabajos que Invinet está realizando para el consorcio PEPPOL consiste en la creación de un entorno de pruebas donde se puedan validar instancias de factura electrónica de distintos países mediante la arquitectura de validación de instancias definida en el BII. Esta arquitectura permite la generación de artefactos de validación para cada estrato o nivel de validación: Un artefacto para las reglas definidas en el entorno del CEN BII, otro para las reglas adicionales consensuadas dentro de PEPPOL y otros conjuntos de reglas definidos a nivel nacional.

En http://www.invinet.org/recursos/conformance/invoice-validation.html se encuentra el sistema de validación de instancias de factura electrónica que actualmente funciona para facturas en formato UBL ya que es el estándar en uso dentro de PEPPOL. El objetivo de BII de todos modos es la definición del CORE de forma neutral respecto a la sintaxis, de forma que es posible que en breve se añadan nuevos modelos de datos en este sistema de validación de factura electrónica, tales como el UN/CEFACT Cross Industry Invoice o incluso el propio Facturae.

Y dentro del colectivo Facturae parece que se está siguiendo el mismo camino en lo que a extensiones se refiere, y es bueno ver que ya hay definidas algunas extensiones para el sector turístico. Es una muy buena iniciativa, aunque como ya se ha comentado antes, al modelar extensiones deberíamos ser capaces de ver si existe una necesidad real de intercambiar determinada información. Disponer de unos elementos de datos semánticamente unívocos que nos  den cierta información es necesario siempre que el receptor los requiera para realizar un proceso a continuación. Si no se va a realizar nada con ellos, y se trata únicamente de información que se tratará de forma textual (para su visualización o impresión), realmente no es recomendable modelarlo.

La simplicidad  y facilitar la adopción deberían guiar a las organizaciones de definición de estándares de documentos electrónicos.

One Trackback

  1. […] This post was mentioned on Twitter by facturae, Oriol Bausa. Oriol Bausa said: Extensiones vs personalizaciones, factura electrónica para todos. http://bit.ly/9veawZ […]

Post a Comment

Your email is never shared. Required fields are marked *

*
*