Statut XML nesemnat sau semnat: ce înseamnă codurile e-Factura
Documentat în ghidul de integrare SFS.
Când transmiteți o factură prin integrare, indicați dacă XML-ul este semnat sau nu. Separat de asta, fiecare factură are un cod de stare în ciclul ei de viață. Sunt două lucruri diferite și se confundă des.
InvoicesXmlStatus: 0 sau 1
Câmpul InvoicesXmlStatus din cererea de transmitere acceptă două valori:
| Valoare | Înseamnă |
|---|---|
0 |
XML nesemnat |
1 |
XML semnat în prealabil |
Aceasta este distincția care decide cum arată restul procesului. Integrarea semi-automatizată descrisă în ghid transmite facturi fără certificat digital: se trimite XML nesemnat (0), iar semnarea se face ulterior, manual, de către persoana autorizată, în interfața web a platformei.
Valoarea 1 presupune că documentul a fost deja semnat înainte de transmitere.
Două câmpuri diferite, amândouă numite „statut”
Aceasta este confuzia care costă cel mai mult timp, așa că o separăm înainte de tabel.
| Câmp | Ce descrie | Valori |
|---|---|---|
Status |
cum a decurs cererea dumneavoastră | 1 acceptat pentru executare · 2 executat cu succes · 3 eroare la executare |
InvoiceStatus |
în ce stare se află factura | codurile 0–10 din tabelul de mai jos |
O cerere poate fi „executată cu succes” (Status = 2) și să vă returneze o factură aflată într-o stare care nu vă convine deloc. Cele două nu se substituie.
Codurile din ciclul de viață (InvoiceStatus)
Sunt coduri de stare, nu erori. Apar la verificarea stării unei facturi și sunt căutate mai ales atunci când o factură pare blocată.
Denumirile de mai jos sunt cele din ghid, inclusiv indicarea celui care acționează — pentru că „respins” și „refuzat de cumpărător” nu răspund la aceeași întrebare:
| Cod | Stare, conform ghidului |
|---|---|
| 0 | Draft |
| 1 | Semnat de Furnizor |
| 2 | Refuzat de Cumpărător |
| 3 | Acceptat de Cumpărător |
| 5 | Anulat de Furnizor |
| 6 | Arhivat |
| 7 | Trimis la Cumpărător |
| 8 | Semnat de Cumpărător |
| 10 | Transportat (confirmare de primire a bunurilor/serviciilor) |
Ce nu vă putem spune încă
Ghidul documentează numărul și denumirea fiecărei stări. Nu documentează condițiile în care o factură trece dintr-o stare în alta, iar noi nu le deducem din denumiri — o denumire nu este o regulă.
Două observații pe care le facem ca atare, fără explicație:
- Codurile 4 și 9 lipsesc din enumerarea documentată. Am căutat în textul integral al ghidului: nu apar. Nu știm de ce.
- Enumerarea nu este ordonată ca o secvență. Nu presupuneți că o factură parcurge codurile în ordine crescătoare.
- Codul 6 (Arhivat) apare într-o singură enumerare din ghid. Ghidul enumeră acest set de coduri în patru locuri, iar codul 6 figurează doar în unul dintre ele. Nu știm dacă în celelalte contexte starea nu poate apărea, sau dacă a fost pur și simplu omisă din tabele.
- Descrierea codului 10 diferă între secțiuni — într-un loc este glosat ca o confirmare de primire a bunurilor/serviciilor, în altul ca semnătură că acestea au fost primite. Am preluat mai sus prima formulare; nu tratăm diferența ca lipsită de importanță, pentru că nu știm care este cea aplicată.
Pentru condițiile efective de trecere între stări, verificați la SFS.
Ce înseamnă o stare din punct de vedere juridic
Nimic din ce scrie pe această pagină. Aici sunt explicate coduri tehnice raportate de platformă. Valabilitatea juridică a unei facturi și efectul semnăturii sunt un subiect separat, tratat pe o pagină separată, și nu îl atingem aici.
Vezi și
- Cum creați un utilizator API în e-Factura
- Cum se anulează o factură electronică în e-Factura
- Catalogul de erori e-Factura (cross-cluster D3)
depus este în dezvoltare. Nu există încă niciun API prin care să trimiteți o factură.
Verificat la: 2026-08-17
Acest material are caracter informativ și nu constituie consultanță juridică sau fiscală. Pentru situația concretă a companiei dumneavoastră, adresați-vă unui consultant autorizat sau instituției competente.
Stadiu: în recenzie