ACCES PREMIUM
De ce premium?
e-Factura: Nouă clarificări tehnice pentru „construirea” XML-ului care se trimite la Fisc, pentru a evita erorile
În contextul trecerii la facturarea electronică pentru toate operațiunile din relația B2B, specialiștii KPMG România au oferit câteva clarificări tehnice legate de „construirea” fișierelor XML care trebuie trimise la Fisc în e-Factura. Dacă specificațiile tehnice nu sunt respectate, facturile electronice nu pot fi transmise în sistemul din Spațiul Privat Virtual (SPV).
Articolul continuă mai jos
Discuția despre
întocmirea facturilor în format XML a avut loc la
o conferință recent organizată de avocatnet.ro. Iar răspunsurile vin de la Vladimir Zoican, Senior Tax Manager la KPMG.
1. De unde aflu ce limitări tehnice sunt la elementele facturii electronice?Vladimir Zoican: „Vreau să pornesc de la legislația tehnică - Ordinul Ministerului Finanțelor 1.366/2021, care menționează, în principiu, regulile de validare la nivelul structurii XML pentru majoritatea elementelor din facturile electronice, precum și faptul că, în cazul în care o validare nu este respectată, validatorul «DUK Integrator» va genera o eroare. Dacă avem erori, XML-ul respectiv nu va fi acceptat de către SPV. Aici majoritatea regulilor de validare sunt fie de tip limită la numărul de caractere, fie anumite restricții pentru ce putem pune la anumite elemente șamd.”2. Ce tipuri de facturi există în sistemul e-Factura și pentru ce sunt?Vladimir Zoican: „«Invoice type» specifică autorităților tipul de factură generată prin fișierul XML. Tipul de factură poate fi 380, care reprezintă o factură normală, poate fi 381, care reprezintă o factură de storno, sau poate fi 389, care este acea factură emisă de beneficiar în numele furnizorului. În funcție de acest tip de factură, SPV știe să trimită XML-ul de la CUI-ul furnizorului către CUI-ul beneficiarului. Pe de altă parte, în cazul unei facturi de tip 389, fluxul de transmitere este inversat - se transmite de la CUI-ul beneficiarului către CUI-ul furnizorului. (...) Mai este tipul de factură 384, care ar trebui să fie folosit în cazul în care emitem o factură inițială care conține erori - factură pe care o stornăm cu 381, iar apoi emitem o a treia factură, cea corectată, care ar putea folosi tipul 384. Pe de altă parte, din experiența pe care am avut-o cu alți clienți, 384 nu este folosită tot timpul, dar se poate folosi foarte ușor și 380 pentru factura corectată.”3. Numărul facturii trebuie să conțină neapărat cifre?Vladimir Zoican: „Elementul «Invoice ID» are și o restricție semantică - acest element nu poate să fie doar din litere. Fiind vorba despre un număr de factură, trebuie să existe cel puțin o cifră în elementul «Invoice ID».”4. Moneda facturii electronice trebuie să fie neapărat leul?Vladimir Zoican: „Ce este foarte important la nivelul facturii inițiale este moneda facturii, care este obligatoriu de folosit. Aici vreau să punctez că, în cazul în care factura este emisă în altă monedă decât leul, dacă «Document currency code», adică moneda facturii, este euro, se generează automat încă un element care devine obligatoriu - «Tax currency code». De ce? Pentru că acest lucru este în conformitate cu legislația românească, ce specifică faptul că o factură poate fi emisă în orice valută, dar TVA-ul trebuie neapărat exprimat în lei. (...) Altfel DUK Integrator va genera erori.”5. Pot trece în factură numărul de contract sau numărul de comandă?Vladimir Zoican: „Sunt două elemente pe care le considerăm utile, dar care nu sunt obligatorii - referința la un contract sau referința la o comandă. Foarte mulți clienți au pe factură o referință la numărul de comandă sau la numărul de contract. Aceste două elemente nu sunt obligatorii, dar sunt foarte utile. Ce vreau să punctez, atât pentru referința la contract, cât și pentru referința la comandă, este că ambele au o restricție de lungime - nu se pot folosi mai mult de 30 de caractere, altfel nu se trece de validarea DUK.”6. Ce e bine de știut despre completarea adresei furnizorului în factură?Vladimir Zoican: „Adresa furnizorului, din păcate, este cea care prezintă cele mai multe probleme. Adresa nu este făcută doar din număr și stradă, ci are patru elemente minime obligatorii - țara în care activează furnizorul (care trebuie să fie tot timpul în conformitate cu standardul european, adică prefixul de două litere al țării; în cazul României, RO), orașul și, foarte important, în cazul în care furnizorul este din România, județul («Country subentity»). Și, desigur, avem un nomenclator inclusiv pentru județe. La acest element, nu putem pune altceva decât codul din nomenclator. Cu alte cuvinte, dacă punem «București» în loc de «RO-B», DUK Integratorul va genera o eroare. (...) A doua problemă cu adresa, care, din punctul nostru de vedere, este puțin mai complicată, este în cazul Bucureștiului. În cazul în care «Country subentity» este RO-B, «City name» trebuie neapărat să fie unul dintre cele șase sectoare (scrise fără spațiu - de exemplu, SECTOR1, nu SECTOR 1).”7. Ce e bine de știut la completarea datelor aferente unui produs facturat?Vladimir Zoican: „Noi am încercat să exemplificăm o linie cu TVA 19% la un produs generic (e vorba de o factură-model prezentată în cadrul conferinței - n. red.) - unde, foarte important, trebuie să fie menționată cantitatea bunurilor sau a serviciilor facturate la nivelul acelei linii. Unitatea de măsură nu este «buc», cum ne-am aștepta, ci există un nomenclator pentru toate unitățile de măsură acceptate - cel mai des folosit pentru bucată este «XPP». Pe lângă elementul de unitate de măsură, trebuie neapărat raportată și cantitatea. Mai avem suma la nivel de linie, suma la nivel de bucată. La nivel de linie, mai avem descrierea - aici am folosit special două elemente, pentru că doar unul este obligatoriu (numele). Din păcate, elementul nume are o restricție de 100 de caractere. Pe de altă parte, elementul descriere, care nu este obligatoriu, poate primi 200 de caractere. Deci, dacă aveți o descriere mai lungă, recomandăm să împărțiți această descriere între cele două elemente (nume și descriere). Ultimul element la nivelul fiecărei linii este cota de TVA aplicabilă - fiecare linie la nivel de factură va trebui să menționeze categoria de TVA și procentul acestei categorii. De ce spun categoria de TVA? Pentru că, desigur, există un nomenclator. În conformitate cu standardul european, pot fi folosite mai multe categorii, dar în practica de la noi sunt doar trei - «S» pentru «Standard rate» (adică TVA aplicabil, nu cota standard de TVA), «AE» pentru măsurile de simplificare (taxarea inversă) și «E» (scutire de TVA).”8. Pot include în factură și alte elemente decât cele obligatorii?Vladimir Zoican: „În XML-ul nostru, deși este generic, am încercat să includem, în afară de acele elemente minime obligatorii, cât mai multe elemente pe care noi le-am văzut în practică, cu mențiunea că sunt mult mai multe. Aici noi avem un număr de vreo 50 de elemente. În total, structura XML primește aproximativ 200 de elemente diferite, care se referă nu doar la factură, beneficiar și furnizor, ci sunt inclusiv elemente pentru identificarea locului de livrare, a reducerilor acordate... Structura XML este foarte complexă, dar și ofertantă. Cu alte cuvinte, orice (sau aproape orice) aveți în momentul de față pe facturile în format PDF sau tipărit poate fi inclus într-o factură în format XML. Desigur, asta dacă se respectă restricțiile la nivelul fiecărui element din structura XML. Dacă aceste restricții nu sunt respectate, DUK Integrator va genera erori și XML-ul nu va putea fi încărcat în SPV.”9. Cum pot adăuga anexe la factura electronică?Vladimir Zoican: „Structura standard XML are două elemente pentru anexe, dar ambele sunt foarte dificil de folosit în practică. Unul este un element în care se pune un link URL la un server de unde pot fi descărcate anexele - ceea ce, în practică, pare ușor de folosit, dar este foarte greu de folosit din punctul de vedere al securității cibernetice. Sau mai există un al doilea element, care se cheamă «Binary object», unde orice anexă poate fi convertită, prin diverse soluții tehnice, într-un șir de caractere text. Acel element va putea primi foarte multe informații privind șirul de caractere. XML-ul se validează și în momentul în care se descarcă XML-ul se poate reconverti șirul de caractere în formatul de anexă, în PDF. Dar în practică este extraordinar de complicat, pentru că fișierul XML devine foarte mare. Deci, în practică, tot prin e-mail veți transmite anexele la facturile transmise prin SPV.”
Context: Raportarea facturilor în e-Factura este obligatorie, de la 1 ianuarie 2024, pentru operațiunile în relația B2B, însă în paralel se folosesc și regulile vechi de facturare până la 30 iunie 2024, conform Legii 296/2023. De la 1 iulie 2024, e-Factura devine unicul canal de transmitere a facturilor, în relația B2B, către destinatari.
--
Acest material este destinat exclusiv informării dumneavoastră personale, conform
termenilor și condițiilor de furnizare a serviciilor avocatnet.ro. Dacă reprezentaţi o instituţie media sau o companie şi doriţi un acord pentru republicarea articolelor noastre, va rugăm să ne trimiteţi o solicitare pe adresa
office@avocatnet.ro.