Codul regulii este BR-RO-DT001.
Datele din e-Factura se scriu exclusiv în format ISO, adică YYYY-MM-DD (exact 10 caractere), fără puncte, fără bare oblice și fără inversarea zilei cu luna. Validatorul verifică două lucruri: lungimea șirului să fie 10 și valoarea să poată fi convertită în data calendaristică. O dată scrisă în stil românesc, ca 05.06.2024, pică regula deși omului i se pare corectă.
În programul de facturare setează pentru data emiterii (cbc:IssueDate) formatul de ieșire yyyy-MM-dd, nu dd.MM.yyyy. Verifică și exporturile din Excel/ERP care lipesc data ca text, pentru că acolo se schimbă des în zi.lună.an.
<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:IssueDate>05.06.2024</cbc:IssueDate> </ubl:Invoice>
<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:IssueDate>2024-06-05</cbc:IssueDate> </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.
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.Un element de tip data (BT-2, BT-27) trebuie sa respecte formatul YYYY-MM-DD
A date (BT-2, BT-27) MUST be formatted YYYY-MM-DD. ({element} = '{valoare}')
cbc:IssueDate
string-length(text()) = 10 and (string(.) castable as xs:date)
Textul oficial al regulii și lista de câmpuri menționează BT-2 și BT-27, dar BT-27 este, în EN 16931, numele vânzătorului, nu o dată; contextul XPath primit se aplică doar pe cbc:IssueDate (BT-2). Nu pot confirma din datele primite care este al doilea element de tip dată vizat de regula, așa că am corectat exclusiv data emiterii.