Erori e-Factura

coduri

Tipul facturii trebuie să fie un cod din lista UNTDID 1001

Codul regulii este BR-CL-01.

Mesajul exact din validatorul ANAF

textEroare=[BR-CL-01]-The document type code MUST be coded by the invoice and credit note related code lists of UNTDID 1001.
textEroare=[BR-RO-020]-Codul tipului facturii (BT-3) trebuie sa fie unul dintre urmatoarele coduri din lista de coduri UNTDID 1001: 380 (Factura), 389 (Autofactura), 384 (Factura corectata), 381 (Nota de creditare), 751 (Factura — informatii în scopuri contabile). #The invoice type code (BT-3) must be one of the following codes in the UNTDID 1001 code list: 380 (Invoice), 389 (Self-invoice), 384 (Corrected invoice), 381 (Credit note), 751 (Invoice - information for accounting purposes).

Ce înseamnă

cbc:InvoiceTypeCode nu acceptă text liber, ci doar codurile de tip document din lista UNTDID 1001 pentru facturi (380 = factură comercială, 384 = factură de corecție, 389 = autofactură, 751 = factură de achiziție etc.). Lista pentru facturi este diferită de lista pentru notele de creditare (381, 396, 532...). Un cod din afară listei, sau un cod care conține un spațiu în interior, face factura să pice exact pe această regulă.

Cum repari

În programul de facturare, câmpul de tip document nu trebuie să fie editabil liber: pune o listă fixă de valori, mapată pe tipurile tale de document (factură, corecție, autofactură). Verifică și ieșirea reală: unele softuri scriu codul cu zecimale (380.0) sau cu spații, iar validatorul îl respinge.

Exemplu

Așa pică

<ubl:Invoice xmlns:ubl="urn:oasis:names:specification:ubl:schema:xsd:Invoice-2" xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2">
  <cbc:InvoiceTypeCode>381</cbc:InvoiceTypeCode>
</ubl:Invoice>

Așa trece

<ubl:Invoice xmlns:ubl="urn:oasis:names:specification:ubl:schema:xsd:Invoice-2" xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2">
  <cbc:InvoiceTypeCode>380</cbc:InvoiceTypeCode>
</ubl:Invoice>

Greșeala asta strică și alte verificări, deci în același răspuns vei găsi și: BR-RO-020_2. Le repari pe toate odată cu asta.

Verificat. Am pus fiecare din cele două fragmente într-o factură completă și le-am trecut prin validatorul oficial ANAF, versiunea ro16931-ubl-1.0.9. Factura cu fragmentul din stânga a fost respinsă cu exact mesajul de mai sus; cea cu fragmentul din dreapta a trecut fără nicio eroare. Verificarea s-a făcut pe 14.09.2026.
Regula așa cum e scrisă în schematronul oficial

Textul oficial, în engleză

The document type code MUST be coded by the invoice and credit note related code lists of UNTDID 1001.

Unde se aplică

cbc:InvoiceTypeCode | cbc:CreditNoteTypeCode

Condiția care trebuie să fie adevărată

(self::cbc:InvoiceTypeCode and ((not(contains(normalize-space(.), ' ')) and contains(' 71 80 81 82 84 102 130 202 203 204 211 218 219 295 325 326 331 380 382 383 384 385 386 387 388 389 390 393 394 395 456 457 527 553 575 623 633 751 780 817 870 875 876 877 935 ', concat(' ', normalize-space(.), ' '))))) or (self::cbc:CreditNoteTypeCode and ((not(contains(normalize-space(.), ' ')) and contains(' 81 83 261 262 296 308 381 396 420 458 532 ', concat(' ', normalize-space(.), ' ')))))
Ce nu rezultă din textul oficial al regulii

Nu pot confirma din datele primite cum se transmite corect o factură de stornare în RO e-Factura: ca document de tip CreditNote (cbc:CreditNoteTypeCode 381) sau ca factură cu codul 384. Verifică ghidul ANAF înainte de a schimba maparea în soft.