Erori e-Factura

CIUS-RO

Data TVA (BT-7) trebuie scrisă în format YYYY-MM-DD

Codul regulii este BR-RO-DT002.

Mesajul exact din validatorul ANAF

org.xml.sax.SAXParseException; lineNumber: 17; columnNumber: 50; cvc-datatype-valid.1.2.1: '05.06.2024' is not a valid value for 'date'.

Ce înseamnă

BT-7 (cbc:TaxPointDate) este data faptului generator de TVA și trebuie scrisă în format ISO 8601, adică YYYY-LL-ZZ. Validatorul nu se uită la conținutul calendaristic, ci verifică două lucruri: textul să aibă exact 10 caractere și să poată fi convertit într-o dată (xs:date). De aceea "05.06.2024" sau "5.6.2024" sunt respinse, deși unui contabil i se par corecte. Elementul se așează între cbc:InvoiceTypeCode și cbc:DocumentCurrencyCode; în factura de referință el nu există deloc, deci îl adaugi doar dacă emiți cu data faptului generator.

Cum repari

În programul de facturare, setează formatul pentru câmpul "Data TVA / data faptului generator" pe șablon ISO (yyyy-MM-dd), separat de formatul afișat pe print (zz.ll.aaaa). Nu adăuga oră și nu adăuga sufix de fus orar, pentru că lungimea trebuie să rămână fix 10 caractere.

Exemplu

Așa pică

<ubl:Invoice xmlns:ubl="urn:oasis:names:specification:ubl:schema:xsd:Invoice-2"
             xmlns:cac="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2"
             xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2">
  <cbc:InvoiceTypeCode>380</cbc:InvoiceTypeCode>
  <cbc:TaxPointDate>05.06.2024</cbc:TaxPointDate>
  <cbc:DocumentCurrencyCode>RON</cbc:DocumentCurrencyCode>
</ubl:Invoice>

Așa trece

<ubl:Invoice xmlns:ubl="urn:oasis:names:specification:ubl:schema:xsd:Invoice-2"
             xmlns:cac="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2"
             xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2">
  <cbc:InvoiceTypeCode>380</cbc:InvoiceTypeCode>
  <cbc:TaxPointDate>2024-06-05</cbc:TaxPointDate>
  <cbc:DocumentCurrencyCode>RON</cbc:DocumentCurrencyCode>
</ubl:Invoice>

În practică nu ajungi să vezi codul regulii: valoarea e respinsă mai devreme, de schema XML, iar mesajul arată cum scrie mai sus. Regula există și ea, dar prinde doar cazurile pe care schema le lasă să treacă.

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 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 română

Un element de tip data (BT-7) trebuie sa respecte formatul YYYY-MM-DD

Textul oficial, în engleză

A date (BT-7) MUST be formatted YYYY-MM-DD. ({element} = '{valoare}')

Unde se aplică

cbc:TaxPointDate

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

string-length(text()) = 10 and (string(.) castable as xs:date)
Ce nu rezultă din textul oficial al regulii

Factura de referință nu conține deloc cbc:TaxPointDate, așa că elementul apare doar în fragmentele de mai sus; nu am putut confirma din datele primite dacă CIUS-RO îl cere obligatoriu în anumite situații sau dacă validatorul îl acceptă și lipsa. Nu am confirmat nici dacă ANAF acceptă variante de dată cu fus orar (ar avea peste 10 caractere, deci ar pica pe regula de lungime).