Erori e-FacturaBR-RO-020_1

Cod factură invalid: ANAF acceptă doar 380, 384, 389 sau 751

Codul regulii este BR-RO-020_1. In raspunsul de la ANAF vezi insa BR-RO-020: eticheta din mesaj nu coincide cu identificatorul regulii. Nu cauta dupa codul regulii, ci dupa textul mesajului.

Mesajul exact din validatorul ANAF

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

În răspunsul ANAF eroarea apare sub etichetă [BR-RO-020], nu sub id-ul intern al regulii, pentru că acolo e afișată în lista de erori. Regula spune că elementul cbc:InvoiceTypeCode (BT-3) poate conține doar unul dintre codurile 380 (factură), 384 (factură corectată), 389 (autofactură) sau 751 (factură cu informații în scopuri contabile). Orice alt cod — inclusiv unul valid în alte liste de coduri sau un text de tipul "FACTURA" — face factura să fie respinsă la validare, chiar dacă restul documentului este corect.

Cum repari

În programul de facturare, caută câmpul "tip document" / "tip factură" din antetul facturii și setează-l pe 380 pentru o factură obișnuită. Verifică tabelul de mapare dintre tipurile interne de documente și codurile UNTDID 1001: dacă acolo există valori proprii (de exemplu "factură fiscală", "tax invoice" sau coduri numerice de 3 cifre care nu sunt în lista de mai sus), înlocuiește-le cu 380 sau 384.

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>388</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>
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.

ANAF raporteaza sub aceeasi eticheta BR-RO-020 si

Regula asa cum e scrisa in schematronul oficial

Textul oficial, in romana

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)

Textul oficial, in engleza

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

Unde se aplica

cbc:InvoiceTypeCode

Conditia care trebuie sa fie adevarata

(. and ((not(contains(normalize-space(.), ' ')) and contains(' 380 384 389 751 ', concat(' ', normalize-space(.), ' ')))))
Ce nu rezulta din textul oficial al regulii

Textul oficial în română și cel în engleză enumeră și codul 381 (Notă de creditare), dar lista din testul XPath al regulii BR-RO-020_1 conține doar 380, 384, 389 și 751. Nu pot confirma din datele primite dacă 381 trece sau nu de validatorul ANAF; pentru notele de creditare verifică separat în validator. De asemenea, nu am confirmat ce semnificație are codul 388 în UNTDID 1001, l-am folosit doar ca exemplu de cod care nu apare în lista acceptată.