Erori e-FacturaBR-DEC-28

Prea multe zecimale la baza de calcul a majorării de pe linie

Codul regulii este BR-DEC-28.

Mesajul exact din validatorul ANAF

textEroare=[BR-DEC-28]-The allowed maximum number of decimals for the Invoice line charge base amount (BT-142) is 2.
textEroare=[UBL-DT-01]-Amounts shall be decimal up to two fraction digits
textEroare= [BR-RO-Z2]-Numarul maxim permis de zecimale pentru Valoarea de baza a taxei suplimentare la linia facturii (BT-142) este 2. #The allowed maximum number of decimals for the Invoice line charge base amount (BT-142) is 2.

Ce inseamna

Regula limitează la două zecimale baza de calcul a unei majorări (taxe) de pe linia facturii - BT-142, adică elementul cbc:BaseAmount din cac:AllowanceCharge cu cbc:ChargeIndicator true, aflat în interiorul liniei. Nu este vorba despre preț, ci despre valoarea pe care se calculează majorarea respectivă. Dacă programul scrie acolo 1000.005, fișierul este respins, deși sumele facturii sunt corecte: majorările de linie sunt doar informative în EN 16931, iar totalurile rămân calculate din cantitate × preț (1000,00 + 19% = 1190,00).

Cum repari

Setează la două zecimale câmpul în care programul scrie baza de calcul a majorării de linie și verifică la export că acolo ajunge valoarea rotunjită (1000.00), nu cea brută rezultată din calcule (1000.005). Nu umbla la suma majorării (BT-141) și nici la totalurile facturii, fiindcă regula se referă strict la baza de calcul.

Exemplu

Asa pica

<ubl:Invoice>
  <cac:InvoiceLine>
    <cbc:ID>1</cbc:ID>
    <cbc:InvoicedQuantity unitCode="H87">10</cbc:InvoicedQuantity>
    <cbc:LineExtensionAmount currencyID="RON">1000.00</cbc:LineExtensionAmount>
    <cac:AllowanceCharge>
      <cbc:ChargeIndicator>true</cbc:ChargeIndicator>
      <cbc:AllowanceChargeReason>Transport</cbc:AllowanceChargeReason>
      <cbc:Amount currencyID="RON">100.00</cbc:Amount>
      <cbc:BaseAmount currencyID="RON">1000.005</cbc:BaseAmount>
    </cac:AllowanceCharge>
    <cac:Item>
      <cbc:Name>Serviciu de consultanta</cbc:Name>
      <cac:ClassifiedTaxCategory>
        <cbc:ID>S</cbc:ID>
        <cbc:Percent>19.00</cbc:Percent>
        <cac:TaxScheme>
          <cbc:ID>VAT</cbc:ID>
        </cac:TaxScheme>
      </cac:ClassifiedTaxCategory>
    </cac:Item>
  </cac:InvoiceLine>
</ubl:Invoice>

Asa trece

<ubl:Invoice>
  <cac:InvoiceLine>
    <cbc:ID>1</cbc:ID>
    <cbc:InvoicedQuantity unitCode="H87">10</cbc:InvoicedQuantity>
    <cbc:LineExtensionAmount currencyID="RON">1000.00</cbc:LineExtensionAmount>
    <cac:AllowanceCharge>
      <cbc:ChargeIndicator>true</cbc:ChargeIndicator>
      <cbc:AllowanceChargeReason>Transport</cbc:AllowanceChargeReason>
      <cbc:Amount currencyID="RON">100.00</cbc:Amount>
      <cbc:BaseAmount currencyID="RON">1000.00</cbc:BaseAmount>
    </cac:AllowanceCharge>
    <cac:Item>
      <cbc:Name>Serviciu de consultanta</cbc:Name>
      <cac:ClassifiedTaxCategory>
        <cbc:ID>S</cbc:ID>
        <cbc:Percent>19.00</cbc:Percent>
        <cac:TaxScheme>
          <cbc:ID>VAT</cbc:ID>
        </cac:TaxScheme>
      </cac:ClassifiedTaxCategory>
    </cac:Item>
  </cac:InvoiceLine>
</ubl:Invoice>

Greseala asta strica si alte verificari, deci in acelasi raspuns vei gasi si: BR-DEC-RO-28, UBL-DT-01. 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 allowed maximum number of decimals for the Invoice line charge base amount (BT-142) is 2.

Unde se aplica

$Invoice_line_charges

Conditia care trebuie sa fie adevarata

$BR-DEC-28
Ce nu rezulta din textul oficial al regulii

Factura de referință nu are nicio reducere/majorare pe linie, deci grupul cac:AllowanceCharge (plasat înaintea lui cac:Item, după cbc:LineExtensionAmount) și valorile 100,00 / 1000,005 sunt exemplificate de mine, nu preluate din EA. Nu am putut confirma dacă validatorul numără zecimalele ca text sau numeric; am ales o valoare cu a treia zecimală nenulă, care pică în ambele variante.