Erori e-FacturaBR-RO-DT004

Data livrării (BT-72) trebuie scrisă în format YYYY-MM-DD

Codul regulii este BR-RO-DT004.

Mesajul exact din validatorul ANAF

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

Ce inseamna

Dacă factura conține data livrării (cac:Delivery/cbc:ActualDeliveryDate, BT-72), ANAF o acceptă doar în format ISO: exact 10 caractere, adică patru cifre pentru an, liniuță, două cifre pentru lună, liniuță, două cifre pentru zi (2024-06-05). Formatele românești uzuale (05.06.2024, 5/6/2024) și variantele cu oră (2024-06-05T00:00:00) pică testul string-length(text()) = 10 și validarea xs:date. Elementul este opțional, dar odată trimis, formatul lui devine obligatoriu.

Cum repari

În programul de facturare, setează câmpul de dată a livrării pe tip de dată ISO (yyyy-MM-dd), fără oră și fără separatorii punct sau slash. Dacă exportul scrie data în format local, convertește-o înainte de generarea XML-ului; dacă nu ai o dată a livrării, omite complet elementul.

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">
  <cac:AccountingCustomerParty>
    <cac:Party>
      <cac:PostalAddress>
        <cbc:StreetName>Bd. Revolutiei nr. 10</cbc:StreetName>
        <cbc:CityName>ARAD</cbc:CityName>
        <cbc:PostalZone>310130</cbc:PostalZone>
        <cbc:CountrySubentity>RO-AR</cbc:CountrySubentity>
        <cac:Country>
          <cbc:IdentificationCode>RO</cbc:IdentificationCode>
        </cac:Country>
      </cac:PostalAddress>
      <cac:PartyTaxScheme>
        <cbc:CompanyID>RO14399840</cbc:CompanyID>
        <cac:TaxScheme>
          <cbc:ID>VAT</cbc:ID>
        </cac:TaxScheme>
      </cac:PartyTaxScheme>
      <cac:PartyLegalEntity>
        <cbc:RegistrationName>Cumparator SRL</cbc:RegistrationName>
        <cbc:CompanyID>J02/4321/2012</cbc:CompanyID>
      </cac:PartyLegalEntity>
    </cac:Party>
  </cac:AccountingCustomerParty>
  <cac:Delivery>
    <cbc:ActualDeliveryDate>05.06.2024</cbc:ActualDeliveryDate>
  </cac:Delivery>
  <cac:PaymentMeans>
    <cbc:PaymentMeansCode>31</cbc:PaymentMeansCode>
    <cac:PayeeFinancialAccount>
      <cbc:ID>RO49AAAA1B31007593840000</cbc:ID>
    </cac:PayeeFinancialAccount>
  </cac:PaymentMeans>
</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">
  <cac:AccountingCustomerParty>
    <cac:Party>
      <cac:PostalAddress>
        <cbc:StreetName>Bd. Revolutiei nr. 10</cbc:StreetName>
        <cbc:CityName>ARAD</cbc:CityName>
        <cbc:PostalZone>310130</cbc:PostalZone>
        <cbc:CountrySubentity>RO-AR</cbc:CountrySubentity>
        <cac:Country>
          <cbc:IdentificationCode>RO</cbc:IdentificationCode>
        </cac:Country>
      </cac:PostalAddress>
      <cac:PartyTaxScheme>
        <cbc:CompanyID>RO14399840</cbc:CompanyID>
        <cac:TaxScheme>
          <cbc:ID>VAT</cbc:ID>
        </cac:TaxScheme>
      </cac:PartyTaxScheme>
      <cac:PartyLegalEntity>
        <cbc:RegistrationName>Cumparator SRL</cbc:RegistrationName>
        <cbc:CompanyID>J02/4321/2012</cbc:CompanyID>
      </cac:PartyLegalEntity>
    </cac:Party>
  </cac:AccountingCustomerParty>
  <cac:Delivery>
    <cbc:ActualDeliveryDate>2024-06-05</cbc:ActualDeliveryDate>
  </cac:Delivery>
  <cac:PaymentMeans>
    <cbc:PaymentMeansCode>31</cbc:PaymentMeansCode>
    <cac:PayeeFinancialAccount>
      <cbc:ID>RO49AAAA1B31007593840000</cbc:ID>
    </cac:PayeeFinancialAccount>
  </cac:PaymentMeans>
</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-72) trebuie sa respecte formatul YYYY-MM-DD

Textul oficial, in engleza

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

Unde se aplica

cbc:ActualDeliveryDate

Conditia care trebuie sa fie adevarata

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

Textul oficial în engleză al regulii enumeră BT-73 și BT-134, dar contextul XPath este cbc:ActualDeliveryDate, care corespunde lui BT-72; nu pot confirma din datele primite dacă aceeași regulă acoperă și celelalte elemente de dată sau doar acesta. În plus, factura de referință nu conține deloc grupul cac:Delivery, așa că l-am inserat pe poziția lui din secvența UBL (după cac:AccountingCustomerParty, înainte de cac:PaymentMeans) fără să pot verifica dacă alte reguli CIUS-RO se aplică acestui grup. Prefixul rădăcinii (ubl:Invoice) l-am scris așa cum cere formatul fragmentelor; factura de referință folosește namespace-ul implicit pe elementul Invoice.