Erori e-FacturaBR-CL-01

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 inseamna

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

Asa pica

<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>

Asa 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>

Greseala asta strica si alte verificari, deci in acelasi raspuns vei gasi si: BR-RO-020_2. Le repari pe toate odata cu asta.

Verificat. Am pus fiecare din cele doua fragmente intr-o factura completa si le-am trecut prin validatorul oficial ANAF, versiunea ro16931-ubl-1.0.9. Factura cu fragmentul din stanga a fost respinsa cu exact mesajul de mai sus; cea cu fragmentul din dreapta a trecut fara nicio eroare. Verificarea s-a facut pe 14.09.2026.
Regula asa cum e scrisa in schematronul oficial

Textul oficial, in engleza

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

Unde se aplica

cbc:InvoiceTypeCode | cbc:CreditNoteTypeCode

Conditia care trebuie sa fie adevarata

(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 rezulta 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.