Quando si invia una fattura a eConnect, il documento attraversa una serie di fasi di elaborazione. Il modo esatto in cui avviene l'elaborazione dipende dal tipo di file (XML o PDF) e dalla qualità del file fornito. Questo articolo spiega cosa accade dietro le quinte.

eConnect prevede due percorsi di elaborazione fondamentalmente diversi:

Elaborazione XML (percorso diretto): se si invia una fattura UBL valida (SI-UBL 2.0, Peppol BIS Billing 3.0 o un altro formato XML supportato), questa viene elaborata direttamente. La piattaforma legge i dati strutturati dall'XML, li valida e instrada il documento verso il destinatario. Questo è il percorso più veloce e affidabile.

Elaborazione PDF (conversione tramite IDR): se si invia una fattura in formato PDF, questa viene elaborata dall'Intelligent Document Recogniser (IDR). L'IDR estrae i dati della fattura tramite OCR e riconoscimento di pattern, e produce una fattura UBL sulla base dei dati riconosciuti. Questo processo è intrinsecamente meno affidabile rispetto all'elaborazione XML diretta, poiché dipende dalla qualità del PDF.

Suggerimento: l'invio in formato UBL è sempre preferibile rispetto al PDF. È più veloce, più economico e più affidabile. Verifichi presso il Suo fornitore o nel Suo pacchetto software se l'esportazione UBL è disponibile.

Quando si invia un file XML, eConnect esegue i seguenti passaggi:

La piattaforma riconosce automaticamente il formato del file in base al CustomizationID e allo schema XML. I formati supportati includono NLCIUS, BIS Billing V3, XRechnung, CII e Factur-X.

La fattura viene validata rispetto alle regole del profilo riconosciuto. Questo comprende:

• Validazione dello schema: il file XML è conforme alla struttura dello schema UBL 2.1 o CII?
• Business rules: i calcoli sono corretti? I campi obbligatori sono compilati? I valori delle code list corrispondono?
• Regole specifiche per Paese: vengono rispettate le regole NL-R-, DK-R- o altre regole nazionali?

Suggerimento: Riceve il messaggio che non sono state trovate "regole di validazione"? Generalmente significa che il CustomizationID nel Suo XML manca o non viene riconosciuto. Senza un profilo identificabile, il validatore non può applicare le regole di business. Verifichi che la Sua fattura contenga un CustomizationID valido, come quello di NLCIUS o BIS Billing V3.

Una caratteristica distintiva dell'elaborazione eConnect è la riparazione automatica dei file XML. Tramite trasformazioni XSL vengono corretti gli errori noti. La piattaforma accetta in linea di principio qualsiasi UBL; i campi non essenziali mancanti vengono compilati con valori predefiniti. Questa funzione di riparazione viene continuamente sviluppata sulla base del feedback dei clienti ed è pronta per la produzione.

Esempi di riparazioni automatiche:

• I campi opzionali mancanti vengono completati con valori predefiniti corretti
• Gli errori di formato noti nei campi identificativi vengono corretti
• I dati di contatto incompleti vengono integrati (se il campo ElectronicMail del fornitore è vuoto, eConnect inserisce automaticamente support@econnect.eu, in modo che le fatture rifiutate raggiungano comunque il mittente)

Se il destinatario supporta un formato diverso da quello di origine, la PSB trasforma automaticamente il documento. Ad esempio, una fattura NLCIUS può essere trasformata in XRechnung se il destinatario è un ente pubblico tedesco. Ciò è possibile perché tutti i formati supportati si basano sullo stesso modello semantico (EN 16931).

Tecnico: quando si scarica una fattura tramite l'API, è possibile specificare il formato di ricezione desiderato tramite il parametro targetDocumentTypeId. La PSB trasforma quindi il documento nel formato indicato.

ZUGFeRD e Factur-X sono formati di fatturazione ibridi: un file PDF/A-3 con una fattura XML CII incorporata. Per questi documenti la piattaforma tenta prima di estrarre l'XML incorporato dal PDF. Se l'XML è valido, viene elaborato direttamente, come una normale fattura XML. Solo se l'XML incorporato non risulta valido, il sistema ricorre all'elaborazione OCR tramite l'IDR.

Una fattura ZUGFeRD che supera la validazione in validatori esterni ma viene comunque elaborata tramite OCR indica un problema con l'XML incorporato nel processo di validazione eConnect. In tal caso è possibile contattare il supporto.

Tecnico: la piattaforma legacy può memorizzare esclusivamente fatture UBL valide. Quando una fattura ZUGFeRD viene elaborata tramite l'IDR come PDF, l'output dell'IDR deve prima essere trasformato in UBL valido (BIS Billing V3 o NLCIUS). Se tale trasformazione non riesce perché i dati di origine non contengono campi sufficienti per una fattura UBL valida, la piattaforma non può memorizzare la fattura. Nella PSB/Control questo problema è meno rilevante, poiché le fatture vengono memorizzate nel formato originale e trasformate solo al momento della consegna.

Se si invia un file XML non valido, il sistema ricorre automaticamente al PDF allegato. Il funzionamento è il seguente:

1. La piattaforma tenta prima di elaborare la componente XML.
2. Se l'UBL non è valido, viene utilizzato il PDF allegato come fallback.
3. Il PDF viene elaborato tramite il percorso IDR (OCR e riconoscimento di pattern).

Questo meccanismo garantisce che la fattura venga sempre elaborata, anche se l'XML contiene errori. Si tratta tuttavia di un percorso più costoso e più lento rispetto all'elaborazione XML diretta.

SI-UBL 1.2 (Simplerinvoicing 1.2) è stato definitivamente dismesso dal 1° gennaio 2024. Le fatture in questo formato vengono rifiutate sulla rete Peppol. eConnect può talvolta ancora trasformare file SI obsoleti ricevuti via e-mail in NLCIUS valido, a condizione che i dati essenziali siano presenti. In caso di dati mancanti la validazione può fallire.

Attenzione: riceve messaggi di errore durante l'invio di fatture? Verifichi se il Suo pacchetto software genera ancora SI-UBL 1.2. In tal caso, chieda al Suo fornitore un aggiornamento a NLCIUS/SI-UBL 2.0 o BIS Billing V3.

L'elaborazione differisce leggermente tra la piattaforma legacy e la PSB/Control:

• Piattaforma legacy: una fattura viene sempre prima trasformata in UBL valido (BIS Billing V3 o NLCIUS) prima di essere memorizzata. Se tale trasformazione non riesce, la fattura non può essere memorizzata.
• PSB/Control: una fattura viene validata e memorizzata al momento della ricezione. La trasformazione avviene solo successivamente quando necessario, ad esempio al momento della consegna a un sistema ERP. Ciò significa che una fattura può essere memorizzata nella PSB, ma che successivamente può verificarsi un errore di trasformazione se il formato di destinazione non può essere generato.

Un indirizzo nella visualizzazione della fattura che mostra una mescolanza di dati di indirizzo di residenza e casella postale non è una mescolanza creata da eConnect in fase di ricezione. eConnect trasmette i campi indirizzo UBL (cac:PostalAddress) 1:1 e non riscrive né normalizza gli indirizzi. Se l'UBL di origine mescola i componenti di indirizzo di residenza e casella postale in un unico blocco PostalAddress, la visualizzazione segue tale origine.

Uno schema tipico di mescolanza nell'UBL di origine:

• cbc:StreetName = via e numero civico (indirizzo di residenza)
• cbc:AdditionalStreetName = CAP dell'indirizzo di residenza, nel campo errato
• cbc:BuildingName = Casella postale N (il campo canonico per la casella postale in UBL è cbc:Postbox)
• cbc:PostalZone = CAP della casella postale

La visualizzazione della fattura mostra quindi spesso la riga della via insieme a PostalZone/CityName, producendo visivamente un "indirizzo misto" senza che eConnect combini o corregga alcun campo. Entrambi i componenti dell'indirizzo possono essere corretti singolarmente, ma la loro combinazione in un blocco indirizzo condiviso con CAP incrociati è un errore di mapping nell'UBL di origine.

Azione: apra l'UBL di origine e verifichi gli elementi figli di PostalAddress della parte interessata. Il fornitore corregge il mapping: o un indirizzo di residenza coerente (StreetName con il PostalZone corrispondente), oppure una casella postale nel campo corretto (Postbox) con il CAP corrispondente -- non entrambi mescolati con CAP incrociati. Una volta corretto l'UBL di origine, la visualizzazione si risolve automaticamente.

Esempio -- fattura di credito "Payee/destinatario = propria organizzazione": con credito versus debito, AccountingSupplierParty e AccountingCustomerParty non si invertono. La direzione (da pagare o da ricevere) è nel tipo di documento e nel segno di PayableAmount, non in parti invertite. eConnect non modifica i ruoli delle parti e non riapplica automaticamente una precedente correzione Payee se l'UBL di origine è già corretto -- stesso principio di passthrough come sopra. Dettagliato con esempio: Varianti nota di credito.

Varianti di ricerca: "fattura di credito Payee", "fattura di credito Payee propria organizzazione", "Supplier Customer invertire credito".

Desidera verificare se il Suo file XML viene elaborato correttamente? Utilizzi il Validatore eConnect gratuito per testare la Sua fattura in anticipo.

• La struttura di una fattura UBL
• Qual è la differenza tra XML, UBL, BIS Billing V3 e NLCIUS?
• Campi di invio importanti in UBL
• SEEF: il formato standard per le e-fatture nel settore energetico
• Scarica file XML di esempio
• Dalla semantica alla sintassi