Când emiți câteva facturi pe lună, le poți încărca de mână în Spațiul Privat Virtual. Când emiți zeci pe zi, din ERP sau din magazinul online, încărcarea manuală devine un post de lucru în sine, iar greșelile apar exact când e mai aglomerat. O integrare e-Factura mută această muncă în program: factura se emite o singură dată, iar restul drumului îl face softul.
e-Factura este sistemul național de facturare electronică. Facturile ajung acolo ca fișiere XML structurate, printr-o interfață de programare pusă la dispoziție de ANAF, iar pentru fiecare factură sistemul întoarce o stare și un răspuns. Cine este obligat să transmită, ce documente și până când sunt întrebări pentru contabilul tău: noi construim unealta, nu interpretăm legea.
Drumul unei facturi, de la emitere până la răspunsul ANAF
Programul salvează factura și construiește din datele ei fișierul XML, în structura cerută de sistem. Fișierul pleacă prin interfața ANAF, care confirmă primirea. Mai târziu vine rezultatul: factura a trecut de validare sau a fost respinsă, cu erorile găsite.
Partea care se uită cel mai des este că rezultatul nu vine pe loc. Programul trebuie să întrebe din nou, la intervale rezonabile, și să nu considere factura „transmisă” doar pentru că fișierul a plecat. De aceea fiecare factură are o stare proprie: de trimis, în așteptare, acceptată, respinsă, de retrimis.
- Verificarea dinainte: câmpuri obligatorii lipsă, coduri fiscale scrise greșit, totaluri care nu se adună.
- Urmărirea stării: programul interoghează sistemul până primește un rezultat final.
- Păstrarea răspunsului: fișierul întors de sistem se arhivează lângă factură.
- Alerta: omul potrivit este anunțat când o factură e respinsă sau a rămas blocată.
O integrare e-Factura se judecă după felul în care tratează erorile
Erorile tehnice (sistem indisponibil, timp de răspuns depășit) se rezolvă prin reîncercări automate, la intervale tot mai mari. Erorile de conținut, adică facturile respinse la validare, nu se repară singure: ajung la cineva din echipa ta, cu mesajul primit, explicat pe cât se poate în limbaj omenesc, și cu legătură directă spre factură.
Rămâne cazul cel mai neplăcut: conexiunea cade exact după trimitere și nu știi dacă factura a ajuns. Programul trebuie să afle întâi ce s-a întâmplat și abia apoi să retrimită. Altfel trimite a doua oară un document deja primit, iar felul în care sistemul tratează dublurile s-a schimbat în timp și se verifică la momentul proiectului.
Întrebări de lămurit înainte de prima linie de cod
Lucrul începe cu o discuție la care e bine să participe și contabilul: ce tipuri de documente emiți (facturi, stornări, facturi în valută, avansuri), din câte programe pleacă și cine răspunde de ele. Tot acum se stabilește cine obține accesul la interfață: autorizarea o face, cu certificatul său digital, o persoană care are deja acces în Spațiul Privat Virtual în numele firmei, nu programatorul.
Urmează inventarul datelor. Formatul structurat cere informații pe care multe programe mai vechi nu le țin separat: județul și localitatea în câmpuri distincte, unitatea de măsură aleasă dintr-o listă de coduri, cota de TVA pe fiecare linie. Curățarea nomenclatoarelor face parte din proiect și durează adesea mai mult decât programarea.
- Probele: transmiteri pe mediul de test, acolo unde este disponibil, fără efect asupra facturilor reale.
- Rularea supravegheată: facturile reale pleacă automat, dar cineva le verifică zilnic o perioadă.
- Predarea: documentație, ecran de monitorizare și un om din echipa ta care știe ce înseamnă fiecare stare.
Cozi, jurnale și locul în care rulează totul
De obicei scriem legătura ca modul separat, în PHP cu Laravel sau în Python, care discută cu programul tău prin baza de date sau printr-un API (o poartă prin care două programe schimbă date fără intervenția omului). Programul de facturare rămâne neatins, iar transmiterea poate fi actualizată când se schimbă cerințele tehnice.
Transmiterile trec printr-o coadă de sarcini, adică o listă de lucrări executate pe rând, în fundal, fără să depindă de browserul cuiva. Fiecare pas se scrie într-un jurnal: ce s-a trimis, când, ce a răspuns sistemul. Datele de acces se țin criptat, iar când reînnoirea lor cere un om, programul anunță din timp.
Când nu ai nevoie de dezvoltare la comandă
Dacă folosești un program de facturare obișnuit, cumpărat de pe piață, foarte probabil are deja transmiterea inclusă. Nu are rost să plătești pentru ceva scris de la zero; cel mult merită legat de magazinul sau de ERP-ul tău.
Dezvoltarea la comandă își are locul când facturile se nasc într-un sistem propriu sau când ai mai multe surse de facturare. Un lucru rămâne valabil oricum: automatizarea transmite ce primește. O factură greșită în program ajunge greșită și în sistem, doar mai repede.
Întrebări frecvente
Cât durează legarea unui program de sistemul e-Factura?
Depinde de câte programe emit facturi, de cât de curate sunt datele despre cumpărători și produse și de câte tipuri de documente ai. Transmiterea e de obicei mai previzibilă decât pregătirea datelor.
Ce se întâmplă dacă ANAF schimbă cerințele tehnice?
Structura fișierului și regulile de validare se mai actualizează, așa că modulul trebuie întreținut, nu doar instalat. Îl construim cu regulile adunate într-un singur loc, ușor de modificat.
Poate programul să decidă singur ce facturi se transmit?
Poate aplica reguli stabilite de tine împreună cu contabilul, de exemplu după tipul cumpărătorului sau al documentului. Cazurile care nu se potrivesc niciunei reguli rămân în așteptare, la un om.
Aceasta este o descriere de proiect-tip: arată cum abordăm de obicei o astfel de lucrare și nu prezintă un proiect făcut pentru un client anume. Fiecare proiect real pornește de la situația firmei tale, iar etapele, termenele și prețul se stabilesc după discuția de început.