Premise: pentru facturare, folosesc o aplicație dezvoltată de mine care se integrează cu sistemul ERP (programul de contabilitate, dar toate se descriu acum ca ERP 🙂 ) pe care îl avem, deci a trebuit să gestionez partea de integrare și implementare. eFactura fusese implementată deja pentru anumite categorii de firme, deci nu putem spune că este ceva nou și se știa că devine obligatoriu de la 1 ianuarie 2024. Sistemul este unul implementat la nivel european, există mai multe țări care îl folosesc și la un moment dat va deveni obligatoriu în toată UE, deși nu sunt stabilite termene fixe. Inclusiv verișorii moldoveni au ceva similar de ceva vreme.
După trei săptămâni în decembrie care au însemnat efectiv cam 3 zile complete de muncă am reușit să am o aplicație eFactura complet funcțională cu toate caracteristicile.
Principalul obstacol, desigur, a fost documentația săracă spre inexistentă, în modul tipic de răspuns al autorităților „conform legea X, paragraful Y”. Se vede că e o aplicație „străină”, deoarece sunt date inutile în România (cum este codul poștal, care are o mare importanță dincolo, dar la noi nu e folosit aproape deloc), nomenclatoare stranii, coduri după care trebuie să sapi prin ordine de ministru sau standarde internaționale. Altele sunt date de „lenea” tipică, de exemplu, inexistența orașului București își are originea fix în baza de date cu codurile poștale care circulă pe net (nu știu dacă e furnizată de data.gov – un proiect altfel bun care merită dezvoltat) unde apare fix cum cere eFactura, SECTORX. Din fericire, ei validează doar existența câmpului, nu și valoarea, că pentru firmele care au mai mulți clienți e aproape imposibil să stea să completeze câmpurile așa că eu am băgat unul generic acolo unde nu am avu date și merge.
„Dezvoltarea” practic a însemnat mult trial and error, „hai să vedem ce face asta”, „hai să vedem ce obținem dacă facem așa”. Altfel, însă, nu e foarte complicat. Sunt 3 pagini php mari și late, una care generează xml, una care îl încarcă și-l descarcă semnat, și una prin care preiei și descarci facturile primite în sistem. Partea tehnică nu e grea deloc, indiferent de limbajul utilizat. Ceea ce nu se înțelege însă este că este un program de facturare, nu chiar orice aplicație și dacă nu sunt generate corect poți băga la modul serios o firmă în belele. Or, aici nu e nici un fel de documentație cu ce vrea ANAF de la fiecare tag în parte, ce se poate folosi și în ce condiții – de exemplu, deși există posibilitatea în standard, ANAF nu a implementat încă tagul pentru firmele cu TVA la încasare, ordinul de ministru explicând ce face tagul. Nu este foarte clar cum se fac corect corecțiile la o factură (au fost avansate 3 variante oficiale). Alte erori și frustrări sunt generate de validatoarele și aplicațiile de generare xml de pe site-ul oficial sau de transformare a facturii în pdf. Eu personal nu m-am mai chinuit cu acestea, am folosit integrarea prin API, care a mers ok. În ceea ce privește marea problemă cu facturile dublate, acum cunoscând tehnic sistemul, mai degrabă zic că e vorba de un script greșit la utilizator, decât de o problemă de sistem. Că ANAF trebuia să implementeze de la bun început un sistem de control, e altceva. Sistemul nu e gândit cap-coadă, nu are obiective foarte clare și nici nu are documentație. Faptul că găsești pe net standarde și ai ordinul MF cu câmpurile „CIUS” nu e propriu-zis documentație. Nici nu sunt oferite modele complete de facturi, doar ce găsești prin alte țări.
În practică, va simplifica mult munca contabililor, fiindcă xml-urile respective se pot importa direct, deci nu le mai introduc de mână. Se va termina cu „nu am primit factura, o mai trimiteți odată” (deși probabil va veni ceva nou „n-a descărcat contabila facturile”, că românul e inventiv). Se va termina cu haiducia, în sensul că ar trebui să fie țepe mai puține, nu prea mai poți veni după X zile că nu ești de acord cu factura, că una-alta. Se va introduce și o oarecare disciplină și standardizare în procesul de facturare, apar pe factură câmpuri „noi” care permit o mai bună gestionare financiară (în măsura în care le implementează ANAF). Practic, vorbim de un standard cu circa 1000 de taguri pentru xml generat.
Tehnic vorbind, nu cred că se pune problema să nu reziste „sistemul”, pentru că încărcarea acestei activități este una redusă și oricum se realizează asincron (tu încarci acum, este procesat un pic mai târziu). La modul practic, eu nu am întâmpinat nici o problemă luna aceasta. Fiind înscris pe o grămadă de grupuri, am observat că 95% din probleme sunt generate de contul SPV, care este o altă mâncare de pește și acolo sunt probleme foarte mari (este adevărat că o parte din ele sunt cauzate și de faptul că unii au amânat până după 1 ianuarie să facă un cont în SPV, iar cei care fac acum deja sunt persoane mai atehnice). 4% sunt legate de validatoarele sau generatoarele de pe site și abia 1% sunt legate strict de sistemul efactura. De altfel, la seminarul „tehnic” la care am participat împreună cu alți vreo 60 de „dezvoltatori” discuțiile au deviat mai mult spre aspecte procedurale și situați tehnice foarte punctuale și specifice, nemaifiind raportate probleme de „sistem”.
La modul practic, încă nu cred că este foarte clar pentru ANAF ce vrea de la acest sistem. Este un simplu sistem de monitorizare? Este un sistem de raportare?
Cât ajută eFactura la limitarea evaziunii? Aici este un pic dificil de estimat, deoarece noi avem vehiculat un procent uriaș de TVA neîncasat și personal nu sunt convins că procentul respectiv este calculat corect, deoarece structura economiei nu permite chiar atât de mult, zona nefiscalizată fiind în realitate foarte mică, prin simplul fapt că 80% din cifra de afaceri în economie e generată de vreo 100.000 de firme deci este fiscalizată. Revenind:
- Prin eFactura se elimină facturile false prin care se deduce fraudulos TVA. Cu facturile pe hârtie puteai să bagi în contabilitate practic orice, făceai o factură în Word cu orice CUI voiai. Da, exista 394, dar până se făceau corelațiile… Ai undeva peste un milion patru sute de mii de firme „active”, dar doar vreo 800.000 depun bilanțuri. Cât TVA se pierde la acești „zombi”? Acum se poate identifica o factură de la un „zombi” dacă apare în sistem.
- Se poate identifica mai ușor frauda de tip „carusel”, adică TVA plimbat prin 4-5 firme „legate”. Aici e posibil să fie nevoie de ceva mai multă putere de calcul decât are efectiv ANAF.
Văicăreala asta generală legată de eFactura are ceva din celebrul „ce-ai cu noi, bă? pentru ce să dăm cu var?”. Faptul că eu am fost capabil să produc o „soluție și că toate programele de facturare și de contabilitate de pe piață au integrat rapid arată că în ciuda obstacolelor „naturale” nu a fost chiar așa de greu. Ce face ANAF cu ele? Aici este o altă discuție. Sunt și nu sunt de acord cu domnul Biriș. Sunt de acord că ANAF nu dispune de capacitate de prelucrare de „big data”. Doar că un „steguleț” la un CUI inactiv în sistem, un sistem de „tracking” pe firmele cu datorii sau istoric negativ nu necesită mari capacități de prelucrare date. Un query simplu pe un milion de înregistrări sau câte facturi se încarcă zilnic în sistem poate duce un laptop mediu 😉 Nici nu avem o economie atât de sofisticată să utilizeze scheme complicate care să necesite analize foarte detaliate. Pe de altă parte, genul acesta de sisteme mai au și rol descurajare prin simplul fapt că duce la creșterea costului total pentru a face afaceri. În România ai nevoie de 128 de lei + costul unei semnături electronice (vreo 500 de lei pe 3 ani) ca să deschizi o firmă. Că nici măcar capitalul social ăla de 200 de lei nu mai trebuie să-l depui. Doar taxa la Registrul Comerțului și semnătura electronică.
