Stati
Eventi di stato e stati nella coda.
- Nella sandboxstruttura degli eventi
- Non ancora nella sandboxstati delle infrastrutture
In parole semplici
Ogni fattura ha uno stato, come «in coda» o «scartata», e una cronologia di eventi che dice cosa le è successo. È così che un cliente o un partner scopre se una fattura è andata a buon fine. La sandbox ospitata non contiene ancora alcuna credenziale per le infrastrutture, quindi gli eventi che provengono da un collegamento con un paese compaiono solo quando un canale è collegato.
Una fattura ha due tipi di stato. Gli eventi di stato dicono cosa le è successo. Lo stato nella coda dice dove si trova ora.
Stato nella coda
GET /invoices/{id} restituisce lo stato.
| Stato | Significato |
|---|---|
received | La fattura è stata accettata alla presa in carico. |
validated | La fattura ha superato tutti i controlli. |
validation_failed | Le regole ufficiali hanno rifiutato il documento. Va nell’elenco degli scarti. |
source_error | Non è stato possibile leggere i dati dell’ERP. |
queued | Accettata e in attesa. |
submitting | Un invio è stato tentato e la sua risposta è andata persa, quindi il canale potrebbe avere la fattura. Il worker la porta a submitted o dead_letter. |
submitted | Il canale ha la fattura. |
ready | Lo stato finale della Germania. L’XRechnung o lo ZUGFeRD è validato e archiviato perché il partner lo consegni. Non è stato inviato nulla. |
accepted | Il canale l’ha accettata. |
delivered | La fattura ha raggiunto la parte dell’acquirente. |
rejected | Il canale l’ha scartata in via definitiva. Va nell’elenco degli scarti. |
dead_letter | Gli errori temporanei hanno esaurito i tentativi. Va nell’elenco degli scarti. |
cancelled | Fermata prima della trasmissione (vedere annullare). |
queued e submitting sono passaggi interni tra validated e submitted, e nessun evento di stato li riporta.
Eventi di stato
Tutti i canali usano la stessa struttura di evento. GET /invoices/{id}/events restituisce gli eventi, e un webhook consegna lo stesso corpo (vedere webhook).
| Stato | Significato |
|---|---|
received | La fattura è stata accettata alla presa in carico. |
validated | La fattura ha superato tutti i controlli. |
source_error | Non è stato possibile leggere i dati dell’ERP. Riporta errors. |
validation_failed | Un controllo non è stato superato. Riporta errors. |
submitted | Il canale ha la fattura. |
accepted | Il canale l’ha accettata. Riporta legal_id, il riferimento proprio del canale. |
rejected | Il canale l’ha scartata. Riporta errors. |
delivered | La fattura ha raggiunto la parte dell’acquirente. |
buyer_status | L’acquirente ha risposto. buyer_status è uno tra acknowledged, in_process, under_query, conditionally_accepted, rejected, approved, disputed e paid. |
Campi presenti in ogni evento: event_id, sequence, occurred_at, invoice_ref, invoice_number, country_route, environment, status e document_sha256. Alcuni eventi aggiungono legal_id, buyer_status, errors (le stesse voci di una segnalazione di simulazione) e route, che contiene il submission_id del canale e il suo stato nativo in raw.
Suggerimento
Ordinare gli eventi per sequence, non per orario.
Lo schema impone tre regole: accepted riporta legal_id, i tre stati di errore riportano errors, e buyer_status riporta un buyer_status.
Quali eventi si verificano
Nella sandboxsandboxLa presa in carico scrive received, con sequence 1. Poi il servizio esegue i validatori del canale e scrive validated, oppure validation_failed quando un controllo non viene superato. Dopo, ogni passaggio della fattura scrive un evento: submitted, accepted, delivered o rejected. Per la Germania non segue nulla dopo validated, perché la fattura termina a ready. Per un esempio, vedere gli eventi registrati.
Nella sandbox ospitata non è ancora archiviata alcuna credenziale per le infrastrutture. Un canale che ne ha bisogno arriva a submitted senza che venga inviato nulla, e la Germania termina a ready. In produzione un canale senza credenziale ritenta e poi manda la fattura in dead letter.
Gli eventi che provengono da un’infrastruttura (accepted, delivered e buyer_status) richiedono un canale collegato. La mappatura dagli stati propri di ciascuna infrastruttura è realizzata e testata, ed è stata eseguita sui sistemi di test di KSeF, di un access point Peppol e di una piattaforma francese. Nella sandbox ospitata non è ancora collegata.
Stato finale per canale
Non ancora nella sandboxinfrastrutture| Canale | Stato finale | Cosa riporta | Errore |
|---|---|---|---|
PL-KSEF | accepted | Il numero KSeF come legal_id. | rejected con il codice KSeF, per esempio KSEF-440 per un duplicato. |
RO-EFACTURA | accepted quando lo stato di ANAF è ok | L’indice di caricamento di ANAF. | rejected quando lo stato è nok, con il codice di errore di ANAF. Il caricamento segue la documentazione di ANAF e non è stato provato; sono stati eseguiti solo i suoi validatori. |
PEPPOL | delivered | L’id del documento presso l’access point. | rejected quando l’access point la rifiuta o segnala un errore. |
FR-PA | delivered, poi eventi buyer_status | L’id della fattura sulla piattaforma. Il codice francese, la sua etichetta ed eventuali note viaggiano in route.raw. | rejected quando la piattaforma la rifiuta, per esempio fr:213. |
DE-XRECHNUNG | Nessuna autorità risponde. Il risultato è il file generato e controllato. | La consegna dipende dal canale di consegna, Peppol o e-mail. | Il 422 alla presa in carico. Non segue alcuna risposta dell’infrastruttura. |
- Gli errori temporanei dell’infrastruttura non diventano mai eventi. L’invio viene ritentato (vedere limiti).
- Un codice di stato francese che il servizio non mappa non produce alcun evento e genera un avviso, così non va perso.
- Un acquirente che un’infrastruttura non riesce a raggiungere. Per Peppol, il servizio controlla il codice dello schema dell’id dell’acquirente, non se l’acquirente è registrato. Un access point può segnalare un acquirente che non è su Peppol come non raggiungibile, e la mappatura lo trasforma in
rejectedconEI-PEPPOL-NO-ROUTE. Questo segue la documentazione dell’access point e non è stato confermato su un access point reale. Un acquirente francese senza indirizzo su una piattaforma dovrebbe dare un errore, non una consegna; neppure questo è stato confermato.