Erori e-Factura

CIUS-RO

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 înseamnă

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

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

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

Î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-72) trebuie sa respecte formatul YYYY-MM-DD

Textul oficial, în engleză

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

Unde se aplică

cbc:ActualDeliveryDate

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

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.