Erori e-Factura

CIUS-RO

Localitatea vânzătorului (BT-37) lipsește din factură

Codul regulii este BR-RO-091. În răspunsul de la ANAF vezi însă BR-RO-090: eticheta din mesaj nu coincide cu identificatorul regulii. Nu căuta după codul regulii, ci după textul mesajului.

Mesajul exact din validatorul ANAF

textEroare=[BR-RO-090]-Localitatea Vanzatorului (BT-37) trebuie furnizata. #Seller city(BT-37) must be provided.
textEroare=[BR-RO-100]-Daca Codul tarii Vanzatorului (BT-40) este RO si Subdiviziunea tarii Vanzatorului (BT-39) este RO-B (corespunzator Municipiului Bucuresti), atunci Localitatea Vanzatorului (BT-37) trebuie sa fie codificata folosind lista de coduri SECTOR-RO. #If the Seller's country Code (BT-40) is RO and the Seller's country subdivision (BT-39) is RO-B (corresponding to Bucharest Municipality), then the Seller city (BT-37) must be coded using the code list SECTOR-RO(SECTOR1, SECTOR2, SECTOR3, SECTOR4, SECTOR5, SECTOR6).

Ce înseamnă

Regula cere că adresa vânzătorului să conțină localitatea, adică elementul cbc:CityName din cac:PostalAddress al vânzătorului să existe și să aibă text. În răspunsul ANAF apare sub eticheta [BR-RO-090], nu sub id-ul BR-RO-091, deci după eticheta asta trebuie să cauți. Validatorul verifică normalize-space, deci atât elementul lipsă, cât și cel gol sunt respinse. Nu e o regulă de sume sau de TVA, doar de adresă.

Cum repari

Completează localitatea din adresa vânzătorului în datele firmei tale (Setări / Date firmă), că programul să o scrie în cbc:CityName la fiecare factură emisă. Nu lăsa câmpul gol și nu pune doar spații. Dacă ai deja localitatea în bază, verifică de ce nu ajunge în XML la facturarea pe care a picat.

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:AccountingSupplierParty>
    <cac:Party>
      <cac:PostalAddress>
        <cbc:StreetName>Str. Exemplu nr. 1</cbc:StreetName>
        <cbc:PostalZone>010101</cbc:PostalZone>
        <cbc:CountrySubentity>RO-B</cbc:CountrySubentity>
        <cac:Country>
          <cbc:IdentificationCode>RO</cbc:IdentificationCode>
        </cac:Country>
      </cac:PostalAddress>
    </cac:Party>
  </cac:AccountingSupplierParty>
</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:AccountingSupplierParty>
    <cac:Party>
      <cac:PostalAddress>
        <cbc:StreetName>Str. Exemplu nr. 1</cbc:StreetName>
        <cbc:CityName>SECTOR1</cbc:CityName>
        <cbc:PostalZone>010101</cbc:PostalZone>
        <cbc:CountrySubentity>RO-B</cbc:CountrySubentity>
        <cac:Country>
          <cbc:IdentificationCode>RO</cbc:IdentificationCode>
        </cac:Country>
      </cac:PostalAddress>
    </cac:Party>
  </cac:AccountingSupplierParty>
</ubl:Invoice>

Greșeala asta strică și alte verificări, deci în același răspuns vei găsi și: BR-RO-100. Le repari pe toate odată cu asta.

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 exact mesajul de mai sus; cea cu fragmentul din dreapta a trecut fără nicio eroare. Verificarea s-a făcut pe 14.09.2026.

Alte reguli pe care ANAF le raportează tot ca BR-RO-090

Regula așa cum e scrisă în schematronul oficial

Textul oficial, în română

Localitatea Vanzatorului (BT-37) trebuie furnizata

Textul oficial, în engleză

Seller city(BT-37) must be provided.

Unde se aplică

/ubl:Invoice | /cn:CreditNote

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

cac:AccountingSupplierParty/cac:Party/cac:PostalAddress/cbc:CityName[boolean(normalize-space(.))]
Ce nu rezultă din textul oficial al regulii

Nu am putut confirma din datele primite dacă validatorul diferențiază între elementul absent și cel prezent dar gol (cbc:CityName cu text gol) la afișarea etichetei [BR-RO-090] — testul normalize-space le respinge pe amândouă. De asemenea, nu am verificat dacă pentru localitățile din București există o regulă separată de forma SECTOR1-SECTOR6, care nu face obiectul acestei reguli.