Cuando envía una factura a eConnect, el documento pasa por una serie de pasos de procesamiento. El desarrollo exacto de este procesamiento depende del tipo de archivo (XML o PDF) y de la calidad del archivo suministrado. Este artículo explica lo que sucede entre bastidores.

eConnect dispone de dos rutas de procesamiento fundamentalmente diferentes:

Procesamiento XML (ruta directa): si envía una factura UBL válida (SI-UBL 2.0, Peppol BIS Billing 3.0 u otro formato XML compatible), se procesa directamente. La plataforma lee los datos estructurados del XML, los valida y enruta el documento al destinatario. Esta es la ruta más rápida y fiable.

Procesamiento PDF (conversión vía IDR): si envía una factura PDF, se procesa mediante el Intelligent Document Recogniser (IDR). El IDR extrae los datos de facturación mediante OCR y reconocimiento de patrones, y produce una factura UBL basada en los datos reconocidos. Este proceso es intrínsecamente menos fiable que el procesamiento XML directo, ya que depende de la calidad del PDF.

Consejo : el suministro UBL siempre es preferible al PDF. Es más rápido, más económico y más fiable. Pregunte a su proveedor o software si la exportación UBL está disponible.

Al enviar un archivo XML, eConnect realiza los siguientes pasos:

La plataforma reconoce automáticamente qué formato sigue el archivo basándose en el CustomizationID y el esquema XML. Los formatos compatibles incluyen entre otros NLCIUS, BIS Billing V3, XRechnung, CII y Factur-X.

La factura se valida según las reglas del perfil reconocido. Esto incluye:

• Validación del esquema: ¿el XML cumple con la estructura del esquema UBL 2.1 o CII?
• Reglas de negocio: ¿son correctos los cálculos? ¿Están rellenos los campos obligatorios? ¿Coinciden los valores de las listas de códigos?
• Reglas nacionales: ¿se respetan las reglas NL-R-, DK-R- u otras reglas nacionales?

Consejo: ¿Recibe el mensaje de que no se encontraron "reglas de validación"? Esto generalmente significa que el CustomizationID en su XML falta o no se reconoce. Sin un perfil reconocible, el validador no puede aplicar reglas de negocio. Verifique que su factura contiene un CustomizationID válido, como el de NLCIUS o BIS Billing V3.

Una característica notable del procesamiento de eConnect es la reparación automática de archivos XML. Mediante transformaciones XSL, se corrigen errores conocidos. La plataforma acepta en principio cualquier UBL; los campos no esenciales faltantes se rellenan con valores por defecto. Esta función de reparación se mejora continuamente sobre la base del feedback de los clientes y está lista para producción.

Ejemplos de reparaciones automáticas:

• Los campos opcionales faltantes se completan con valores por defecto correctos
• Los errores de formato conocidos en los campos de identificación se corrigen
• Los datos de contacto incompletos se completan (si el campo ElectronicMail del proveedor está vacío, eConnect rellena automáticamente support@econnect.eu, para que las facturas rechazadas lleguen al remitente)

Si el destinatario admite un formato diferente al formato fuente, el PSB transforma automáticamente el documento. Una factura NLCIUS puede, por ejemplo, transformarse a XRechnung si el destinatario es una administración pública alemana. Esto es posible porque todos los formatos compatibles se basan en el mismo modelo semántico (EN 16931).

Técnico : al descargar una factura a través de la API, puede especificar el formato de recepción deseado mediante el parámetro targetDocumentTypeId. El PSB transforma entonces el documento a ese formato.

ZUGFeRD y Factur-X son formatos de factura híbridos: un archivo PDF/A-3 que contiene una factura CII XML integrada. Para estos documentos, la plataforma intenta primero extraer el XML integrado del PDF. Si el XML es válido, se procesa directamente, como una factura XML regular. Solo si el XML integrado resulta no válido, el sistema recurre al procesamiento OCR mediante el IDR.

Una factura ZUGFeRD que pasa los validadores externos pero se procesa mediante OCR indica un problema con el XML integrado en el proceso de validación de eConnect. En ese caso, puede contactar con soporte.

Técnico : la plataforma legacy solo puede almacenar facturas UBL válidas. Cuando una factura ZUGFeRD se procesa mediante el IDR como PDF, la salida del IDR debe primero transformarse a UBL válido (BIS Billing V3 o NLCIUS). Si esa transformación falla porque los datos fuente no contienen suficientes campos para una factura UBL válida, la plataforma no puede almacenar la factura. En el PSB/Control, este problema es menor, ya que las facturas se almacenan en su formato original y solo se transforman en el momento de la entrega.

Si envía un archivo XML no válido, el sistema recurre automáticamente al PDF adjunto. Funciona de la siguiente manera:

1. La plataforma intenta primero procesar el componente XML.
2. Si el UBL no es válido, se utiliza el PDF adjunto como fallback.
3. El PDF se procesa a través de la ruta IDR (OCR y reconocimiento de patrones).

Este mecanismo garantiza que la factura siempre se procese, incluso si el XML contiene errores. Sin embargo, es una ruta más costosa y más lenta que el procesamiento XML directo.

SI-UBL 1.2 (Simplerinvoicing 1.2) fue definitivamente retirado el 1 de enero de 2024. Las facturas en este formato son rechazadas en la red Peppol. eConnect puede a veces transformar los archivos SI antiguos recibidos por correo electrónico a NLCIUS válido, siempre que los datos esenciales estén presentes. Si faltan datos, la validación puede fallar.

Atención : ¿Recibe mensajes de error al enviar facturas? Compruebe si su software todavía genera SI-UBL 1.2. Si es así, solicite a su proveedor una actualización a NLCIUS/SI-UBL 2.0 o BIS Billing V3.

El procesamiento difiere ligeramente entre la plataforma legacy y el PSB/Control:

• Plataforma legacy: una factura siempre se transforma primero a UBL válido (BIS Billing V3 o NLCIUS) antes de ser almacenada. Si esa transformación falla, la factura no puede ser almacenada.
• PSB/Control: una factura se valida y almacena en la recepción. La transformación solo tiene lugar más tarde cuando es necesario, por ejemplo durante la entrega a un sistema ERP. Esto significa que una factura puede ser almacenada en el PSB, pero que un error de transformación puede ocurrir posteriormente si el formato objetivo no puede ser generado.

Una dirección en la visualización de la factura que muestra una mezcla de datos de domicilio y apartado postal no es una mezcla creada por eConnect en la recepción. eConnect transmite los campos de dirección UBL (cac:PostalAddress) 1:1 y no reescribe ni normaliza direcciones. Si el UBL fuente mezcla los componentes de domicilio y apartado postal en un solo bloque PostalAddress, la visualización sigue esa fuente.

Un patrón de mezcla típico en el UBL fuente:

• cbc:StreetName = calle y número (domicilio)
• cbc:AdditionalStreetName = código postal del domicilio, en el campo incorrecto
• cbc:BuildingName = Apartado postal N (el campo canónico de apartado postal en UBL es cbc:Postbox)
• cbc:PostalZone = código postal del apartado postal

La visualización de la factura muestra entonces a menudo la línea de calle junto con PostalZone/CityName, produciendo visualmente una "dirección mezclada" sin que eConnect combine o corrija ningún campo. Ambos componentes de dirección pueden ser correctos por separado, pero combinarlos en un bloque de dirección compartido con códigos postales cruzados es un error de mapeo en el UBL fuente.

Acción: abra el UBL fuente y revise los elementos hijos de PostalAddress de la parte correspondiente. El proveedor corrige el mapeo: o bien un domicilio consistente (StreetName con el PostalZone correspondiente), o un apartado postal en el campo correcto (Postbox) con el código postal correspondiente -- no ambos mezclados con códigos postales cruzados. Una vez corregido el UBL fuente, la visualización se resuelve por sí sola.

Ejemplo -- factura de crédito "Payee/receptor = propia organización": con crédito versus débito, AccountingSupplierParty y AccountingCustomerParty no se invierten. La dirección (a pagar o a recibir) está en el tipo de documento y el signo de PayableAmount, no en partes invertidas. eConnect no ajusta los roles de las partes y no vuelve a aplicar automáticamente una corrección Payee anterior si el UBL de origen ya es correcto -- el mismo principio de passthrough que el anterior. Desarrollado con ejemplo: Variantes de nota de crédito.

Variantes de búsqueda: "factura de crédito Payee", "factura de crédito Payee propia organización", "Supplier Customer intercambiar crédito".

¿Desea comprobar si su archivo XML se procesa correctamente? Utilice el validador eConnect gratuito para probar su factura de antemano.

• La estructura de una factura UBL
• ¿Cuál es la diferencia entre XML, UBL, BIS Billing V3 y NLCIUS?
• Campos de envío importantes en UBL
• SEEF: la Standaard Energie eFactuur
• Descargar archivos XML de ejemplo
• De la semántica a la sintaxis