Erori e-FacturaBR-RO-DT002

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 inseamna

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

Asa pica

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

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

In practica nu ajungi sa vezi codul regulii: valoarea e respinsa mai devreme, de schema XML, iar mesajul arata cum scrie mai sus. Regula exista si ea, dar prinde doar cazurile pe care schema le lasa sa treaca.

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

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

Textul oficial, in engleza

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

Unde se aplica

cbc:TaxPointDate

Conditia care trebuie sa fie adevarata

string-length(text()) = 10 and (string(.) castable as xs:date)
Ce nu rezulta 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).