Erori e-FacturaBR-RO-020_2

Codul tipului facturii trebuie să fie 380, 389, 384, 381 sau 751

Codul regulii este BR-RO-020_2. 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

ANAF afișează regula sub eticheta [BR-RO-020] (în schematron este varianta _2, cea care verifică codul din nota de creditare), nu sub id-ul BR-RO-020_2, așa că mesajul de respingere îl vei găsi doar după eticheta scurtă. Regula limitează codul tipului de document (BT-3) la cinci coduri din lista UNTDID 1001: 380 (Factura), 389 (Autofactura), 384 (Factura corectată), 381 (Nota de creditare) și 751 (Factură — informații în scopuri contabile). Orice alt cod din UNTDID 1001, de pildă 383 (notă de debit), este respins, chiar dacă restul facturii este perfect. Într-o factură XML codul stă în cbc:InvoiceTypeCode, iar valoarea 381 este valabilă doar în cbc:CreditNoteTypeCode, adică în nota de creditare.

Cum repari

Verifică în programul de facturare tipul de document selectat pentru factura respinsă și pune-l pe Factură (cod 380). Dacă documentul este într-adevăr o notă de creditare, codul corect este 381 și se emite ca document de tip credit note, nu ca factură. Nu edita manual fișierul XML: schimbă tipul în datele facturii și regenerează fișierul, ca să rămână sincron cu restul datelor.

Exemplu

Asa pica

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

Asa trece

<Invoice xmlns="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>
</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). ({element} = '{valoare}')

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

Conditia care trebuie sa fie adevarata

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

Contextul oficial al variantei _2 este cbc:CreditNoteTypeCode, element care nu există în factura de referință (document de tip Invoice, care folosește cbc:InvoiceTypeCode); am presupus că pentru factura respinsă elementul vizat este cbc:InvoiceTypeCode. Valoarea 383 folosită ca exemplu greșit este un cod real UNTDID 1001 (notă de debit), nu un cod inventat, dar nu am putut confirma din datele primite că exact această valoare a apărut în fișierul respins.