Dicționar IT
Ce este XML?
Formatul veteran al datelor structurate: etichete care descriu conținutul — limba oficială a facturii electronice românești și a schimburilor enterprise.
XML-ul (eXtensible Markup Language) e formatul veteran al datelor structurate: informația împachetată în etichete care o descriu — <factura><client>Popescu SRL</client><total>1250</total></factura> — citibilă și de mașini, și de oameni, cu o virtute care i-a definit cariera: rigoarea. Schemele XML (XSD) definesc exact ce câmpuri există, în ce ordine, cu ce tipuri — iar documentele se validează automat contra lor: exact ce trebuie când o factură sau o declarație trebuie să respecte un standard la virgulă. De aici locul lui în viața firmelor românești, mai relevant azi ca oricând: e-Factura vorbește XML (fișierul cu valoare fiscală transmis prin SPV e un XML în standardul UBL — PDF-ul e doar umbra lui de curtoazie; când softul tău „generează XML-ul” și ANAF îl „validează”, exact schema aceasta se verifică — motiv pentru care erorile de validare din e-Factura sunt, tehnic, abateri de la schemă: câmpuri lipsă, coduri greșite, structuri stricate), SAF-T (D406) la fel — raportarea contabilă standardizată e un XML masiv — plus declarații, extrase bancare în formate de schimb, cataloage de produse între parteneri, fluxuri enterprise mai vechi (SOAP) și fișiere de configurare. Relația cu JSON-ul, ruda mai tânără care domină web-ul: JSON a câștigat API-urile moderne prin simplitate (mai puțin zgomot, nativ în JavaScript), XML-ul rămâne rege unde validarea strictă contra unui standard oficial e cerința — adică exact în fiscal, bancar și schimburile instituționale; nu e o competiție cu învingător, ci două unelte pe două nevoi, iar sistemele firmei tale le vorbesc, prin integrări, pe amândouă fără ca cineva să trebuiască să aleagă. Ce îi folosește concret unui administrator de firmă din toate acestea: înțelegerea că „XML-ul respins de ANAF” e o problemă de validare contra schemei — cu mesaj de eroare precis, reparabilă punctual în softul care l-a generat (nu un mister birocratic), că cerința „ne trebuie facturile/catalogul în XML” de la un partener mare e o cerință de integrare standard cu soluții gata făcute, și că datele primite în XML sunt date reale, structurate — importabile, transformabile, arhivabile — spre deosebire de PDF-uri, care sunt poze; plus detaliul de arhivă cu bătaie lungă: XML-ul e text simplu, citibil peste 20 de ani cu orice unealtă — exact ce vrei de la formatul în care trăiește istoria fiscală a firmei.
Hai să vorbim despre proiectul tău
Scrie-ne pe WhatsApp sau trimite un email — vorbești direct cu un programator.
office@northdan.com · +40 752 070 247
Termenul te interesează pentru un proiect concret? Integrări cu e-Factura și schimb de date — vezi serviciul de integrare API
De ce contează pentru afacerea ta
Limba oficială a fiscalității digitale
e-Factura, SAF-T și declarațiile trăiesc în XML validat contra schemelor oficiale — sistemele care îl vorbesc corect trec; restul colecționează respingeri.
Validare strictă, erori precise
Documentul verificat automat contra schemei pică cu mesaj exact — „câmpul X lipsește” se repară punctual, nu se ghicește prin suport telefonic.
Arhivă citibilă peste decenii
Textul simplu structurat rămâne accesibil cu orice unealtă, oricând — formatul corect pentru datele care trebuie să supraviețuiască sistemelor care le-au creat.
Întrebări frecvente
De ce e-Factura folosește XML și nu PDF-ul „normal”?
Pentru că scopurile diferă: PDF-ul e făcut pentru ochi (arată la fel peste tot — dar extragerea datelor din el e ghicit automatizat), XML-ul e făcut pentru sisteme: fiecare informație în câmpul ei definit de standard (UBL), validabilă automat, importabilă fără erori în contabilitatea destinatarului. Factura-date în loc de factura-poză e exact ce permite automatizarea întregului lanț — de la validarea ANAF la înregistrarea automată la primitor; PDF-ul rămâne legitim ca reprezentare vizuală de curtoazie, generată din XML.
ANAF ne respinge XML-urile la e-Factura — ce înseamnă și cine repară?
Respingerea e un verdict de validare: documentul generat nu respectă schema — cazurile tipice: coduri lipsă sau greșite (unități de măsură, cote TVA, coduri de țară), câmpuri obligatorii goale, structuri incorecte, date de identificare eronate. Mesajul de eroare indică precis problema (chiar dacă în limbaj tehnic), iar reparația aparține softului care generează: furnizorul aplicației de facturare/ERP corectează maparea — tu doar raportezi eroarea completă. Respingerile repetate pe aceleași tipuri de erori sunt semnalul unui soft neactualizat la versiunea curentă a schemei — întrebare directă pentru furnizor.
Un partener mare ne cere datele „în XML după schema lor” — e un proiect mare?
De regulă nu — e o integrare de transformare standard: datele tale (din ERP, gestiune) se mapează pe structura cerută de schema lor și se exportă automat, la program sau la eveniment; uneltele și practica există de decenii, iar efortul tipic e de zile, nu de luni — cu condiția clarificării de la început: schema exactă și exemple valide de la partener, regulile de transport (unde și cum se trimit fișierele) și tratarea erorilor de validare. E genul de cerință care sperie prin acronime și se rezolvă prin rutină — orice echipă de integrări a făcut-o de multe ori.
Hai să vorbim despre proiectul tău
Scrie-ne pe WhatsApp sau trimite un email — vorbești direct cu un programator.
office@northdan.com · +40 752 070 247