Arhitectura modulelor open-source de fiscalizare SIA e-Factura și MEV pentru Odoo 19

În arhitectura modernă a sistemelor de planificare a resurselor întreprinderii (ERP) pentru companiile mijlocii, puține eșecuri structurale sunt la fel de costisitoare și răspândite ca „capcana dublei contabilități”. În companiile din jurisdicțiile în curs de digitalizare, conducerea executivă gestionează operațiunile cotidiene (comenzi de vânzare, tranzacții la punctele de vânzare POS, recepții și livrări din depozit) într-o platformă operațională agilă precum Odoo. În același timp, departamentul de contabilitate financiară rămâne captiv într-un siloz contabil moștenit (de cele mai multe ori platforme monolitice de sorginte sovietică, cum ar fi 1C:Contabilitate 8.3).

Consecința directă este o divergență operațională permanentă. Tranzacțiile comerciale sunt înregistrate în Odoo de către echipele de vânzări și logistică, exportate ulterior în tabele Excel sau reintroduse manual de către operatori contabili câteva săptămâni mai târziu, iar la final de lună se încearcă reconcilierea prin corecții disperate. Soldurile din balanță deviază, stocurile fizice din depozit nu mai coincid cu valorile contabile, iar directorii financiari (CFO) sunt forțați să piloteze fluxurile de numerar pe baza unor rapoarte financiare învechite cu treizeci de zile.

Între anii 2024 și 2026, cadrul statutar și fiscal a cunoscut o transformare profundă. Autoritățile din Europa de Est și Uniunea Europeană au impus mandate stricte de schimb electronic de date (EDI), eliminând în mod concomitent birocrația internă pe suport de hârtie. În Republica Moldova, de exemplu, Legea contabilității și raportării financiare nr. 287/2017 (în special art. 11 alin. (9) și art. 15 alin. (4)) a eliminat obligativitatea aplicării semnăturilor olografe pe documentele primare interne și pe registrele contabile întocmite în formă electronică prin sisteme securizate. Hotărârea Guvernului nr. 229/2024 a exclus foile de parcurs (foaia de parcurs) și avizele de însoțire din categoria formularelor tipizate de strictă evidență, iar Legea nr. 160/2024 a desființat formularele tipizate pe hârtie pentru actele de achiziție.

Din punct de vedere statutar, pentru întreprinderile comerciale au rămas exact două documente electronice de strictă evidență: factura fiscală electronică (Factura fiscală înregistrată în portalul guvernamental centralizat SIA e-Factura) și bonul fiscal de casă (Bon fiscal emis prin rețeaua de telemetrie SIA MEV). Toate celelalte operațiuni (consumul intern de materiale, deconturile de avans, consumul de combustibil și amortizarea mijloacelor fixe) pot funcționa exclusiv ca piste de audit criptografice și înregistrări relaționale într-un motor ERP tranzacțional ACID.

Cu toate acestea, 95% din întreprinderile mici și mijlocii rămân blocate în proceduri manuale de introducere a datelor. Bariera nu a fost niciodată una legislativă, ci absența unei arhitecturi ERP integrate, modulare și libere de parametri codificați static (zero-hardcode). Prezentul document tehnic descrie arhitectura noastră de referință implementată pe Odoo 19 Community Edition.

Capcana dublei contabilități și doctrina „Zero Duplicate Models”

Când inginerii software încearcă să construiască o punte între un sistem ERP internațional și cerințele contabile locale, cel mai frecvent anti-pattern constă în crearea unor „modele-insulă” redundante. În implementările Odoo, dezvoltatorii construiesc adesea tabele paralele precum l10n_md.advance.report, l10n_md.waybill și l10n_md.purchase.act.

Această abordare încalcă principiul fundamental al contabilității în partidă dublă: orice eveniment economic operațional trebuie să se reflecte instantaneu în registrul general (general ledger), fără intermediari artificiali. Modelele duplicate introduc riscuri sistemice grave:

1. Multiplicarea memoriei și balastul în baza de date apar atunci când numărul tabelelor și înregistrărilor relaționale este dublat, necesitând mecanisme de sincronizare care eșuează sub tranzacții concurente.
2. Discrepanțele între sub-registre survin când un consum de motorină introdus într-un model custom de foaie de parcurs scade cantitățile fizice din depozit fără a genera nota contabilă de cheltuială în contul 713/811, provocând dezechilibre în balanța de verificare.
3. Fragmentarea pistei de audit împiedică auditorii financiari și inspectorii fiscali să reconstituie firul tranzacțional de la comanda de achiziție până la nota de plată și reconcilierea bancară, deoarece continuitatea este ruptă între tabele nestandardizate.

Arhitectura noastră v4.0 impune cu strictețe Doctrina Zero Duplicate Models. Toate entitățile insulare sunt declarate perimate (@api.deprecated). Evenimentele economice se desfășoară 100% pe modelele native din Odoo 19 CE:

• Titularii de avans și deconturile de cheltuieli sunt gestionate exclusiv prin hr.expense și hr.expense.sheet, cu reconciliere automată a contului de decontări Contul 2261 (Titulari de avans).
• Monitorizarea parcului auto și consumul de carburant sunt înregistrate pe modelul nativ fleet.vehicle.odometer, generând bonuri automate de casare a stocului (stock.picking / stock.scrap din contul de stoc Contul 2114).
• Achizițiile de la persoane fizice (terenuri, produse agricole, chirii) sunt procesate prin facturi native de furnizor (account.move cu move_type='in_invoice'), unde reținerile la sursă (art. 90, 90.1, 90.3 din Codul Fiscal) se calculează ca linii native de taxe asociate contului de pasiv Contul 5343 (Rețineri la sursă).

Arhitectura punților decuplate și modulele auto-install

O a doua eroare arhitecturală întâlnită în pachetele monolitice de localizare este cuplarea rigidă a dependențelor. În versiunile precedente (19.0.3.0.0), modulul de bază l10n_md avea setate dependențe fixe în __manifest__.py către purchase, stock, fleet și hr_expense. Astfel, o companie de consultanță sau o firmă IT care dorea doar evidență financiară și generarea declarațiilor fiscale era forțată să instaleze modulele de stocuri, parcuri auto și puncte de vânzare cu amănuntul.

În arhitectura v4.0, nucleul l10n_md este complet decuplat. Dependențele sale sunt reduse strict la:

Toate integrările periferice sunt mutate în 6 module de legătură („glue modules”) echipate cu mecanismul nativ 'auto_install': True:

• l10n_md_expense: Se instalează automat numai dacă sunt prezente simultan l10n_md și hr_expense, adăugând logica de reconciliere a avansurilor și tipărirea decontului de avans.
• l10n_md_stock: Se activează automat la prezența modulului stock, configurând valorificarea stocurilor pentru obiecte de mică valoare și scurtă durată (OMVSD) conform standardului național SNC „Stocuri”.
• l10n_md_fleet: Leagă fleet de stock, transformând citirile de kilometraj în consumuri contabile de combustibil.
• l10n_md_pos: Extrage logica caselor de marcat din modulul fiscal MEV, permițând nucleului l10n_md_mev să funcționeze ca un serviciu backend autonom pentru facturi online și comerț electronic, fără interfața greoaie a casierului din POS.
• l10n_md_efactura_stock: Extrage legăturile dintre documentele de livrare din depozit (stock.picking) și facturile electronice din l10n_md_efactura.

Această structură garantează că nucleul contabil rămâne minimalist, securizat și compatibil cu orice scenariu de implementare.

Automatul criptografic cu stări finite pentru facturarea de stat (SIA e-Factura)

Sistemul național de facturare electronică funcționează după modelul de vămuire și validare prealabilă (clearance model). O factură emisă între două entități comerciale nu are valoare juridică fiscală până când nu este semnată digital, transmisă în hub-ul fiscal central (api.fisc.md) și recepționată prin semnătură de către cumpărător.

Ciclul de viață al facturii electronice

În cadrul modulului l10n_md_efactura, documentul tranzitează prin cinci stări finite deterministe:

1. draft: Factura este validată contabil în Odoo (posted), dar nu a fost încă înregistrată în gateway-ul fiscal guvernamental.
2. signed_issuer: XML-ul canonic al facturii a fost semnat criptografic cu cheia fiscală a furnizorului prin standardul W3C Enveloped XML Signature (XMLDSig).
3. sent: Pachetul semnat a fost expediat prin protocolul SOAP MTOM/XOP către serviciul de stat și a primit un identificator unic de tranzacție.
4. signed_recipient: Cumpărătorul a inspectat documentul în portalul fiscal, a aplicat propria semnătură electronică și a acceptat factura.
5. accepted: Starea finală imuabilă; factura este blocată la modificări și poate fi dedusă în declarația privind TVA (TVA12).

Capcanele canonicizării XML

Cea mai periculoasă capcană tehnică în integrarea sistemelor e-Factura constă în modificarea invizibilă a spațiilor albe și a spațiilor de nume (namespaces). Dacă documentul XML generat este serializat prin metode standard de concatenare de șiruri, parserele XML intermediare vor reordona atributele sau vor altera caracterele de sfârșit de linie, invalidând instantaneu valoarea de dispersie (digest value) RSA-SHA256. Motorul nostru impune utilizarea obligatorie a algoritmului W3C Exclusive XML Canonicalization (xml-exc-c14n#) înainte de calcularea amprentei criptografice.

Cozi fiscale idempotente SIA MEV și autonomie offline de 72 de ore

În domeniul comerțului cu amănuntul și al plăților directe, sistemul guvernamental SIA MEV (Monitorizarea Electronică a Vânzărilor) impune ca fiecare bon emis să fie transmis ca telemetrie fiscală către Serviciul Fiscal de Stat.

În exploatarea de producție, serverele cloud ERP se confruntă inevitabil cu latențe WAN, ferestre de mentenanță pe serverele guvernamentale sau pierderi de pachete. O arhitectură sincronă, care blochează interfața casierului până la primirea răspunsului HTTP de la fisc, este catastrofală: casierul este blocat, rândul de clienți se blochează, iar vânzările sunt paralizate.

Pentru a asigura continuitatea absolută a afacerii, modulul l10n_md_mev implementează o coadă asincronă cu tampon de autonomie offline de 72 de ore (în strictă conformitate cu Regulamentul aprobat prin HG nr. 141/2019):

1. Salvarea tranzacțională locală are loc la finalizarea bonului sau a plății, când operațiunea este înscrisă în registrul PostgreSQL și inserată în tabela l10n_md.mev.offline.buffer. Fiecare bon din coadă conține un cod hash SHA-256 înlănțuit, calculat pe baza semnăturii bonului precedent, împiedicând orice tentativă de reordonare sau ștergere retroactivă.
2. Eliberarea imediată a clientului permite terminalului POS să tipărească un bon marcat BON EMIS ÎN REGIM AUTONOM (OFFLINE), prevăzut cu un cod QR local și hash-ul criptografic de verificare.
3. Evacuarea asincronă în fundal folosește un proces planificat ir.cron care interoghează coada locală și trimite pachete de până la 50 de bonuri printr-un apel SOAP MTOM/XOP către endpoint-ul ACPS v3 (/api/v3/ACPS).
4. Confirmarea idempotentă se produce atunci când serverul fiscal confirmă primirea și returnează numerele unice de înregistrare în MEV. Înregistrările locale sunt actualizate, iar tamponul este degrevat. Dacă serverul central este indisponibil, algoritmul aplică reîncercări cu backoff exponențial, permițând continuarea nestingherită a vânzărilor pe o durată de până la 72 de ore.

Maparea liniilor de furnizor în 4 etape prin SequenceMatcher și detecția anomaliilor

La descărcarea facturilor fiscale electronice de la furnizori, denumirile articolelor din XML nu coincid aproape niciodată cu nomenclatorul intern al cumpărătorului. Un furnizor facturează "Flanșă oțel DN50 PN16", care în nomenclatorul intern trebuie asociată codului STEEL-FLG-050 și debitată pe materii prime (Contul 2111), nu pe cheltuieli generale.

Obligarea contabilului de a alege manual fiecare produs pentru zeci de linii recreează blocajul muncii manuale. Pentru a rezolva această problemă fără a introduce halucinațiile modelelor generative de inteligență artificială, am construit un Clasificator Hibrid Determinist în 4 Etape:

Când toate liniile unei facturi de intrare obțin un coeficient de încredere ≥0.90 și nu prezintă nicio anomalie, documentul este inclus automat în Coridorul Verde (Green Corridor Eligible), permițând contabilului-șef validarea în masă printr-un singur clic a sute de facturi de intrare.

Generarea automată a declarațiilor fiscale în format XML

Conformitatea financiară se definitivează prin depunerea declarațiilor fiscale periodice pe portalul Serviciului Fiscal de Stat (declaratii.fisc.md). Întocmirea manuală a rapoartelor generează erori umane și discordanțe față de registrul general.

Modulul l10n_md_sfs_reports interoghează direct tabelele native account.move.line din Odoo pentru a compila declarațiile oficiale în format XML validat:

• TVA12 (Declarația privind TVA) distribuie rulajele și TVA deductibilă/colectată în Boxa 1 (Cota standard 20%), Boxa 2 (Cota redusă 8%), Boxa 3 (Cota redusă 6%), Boxa 5 (Scutit cu drept de deducere, export servicii conf. art. 104) și Boxele 12/13 privind deducerile.
• IPC21 (Darea de seamă privind reținerea impozitului pe venit, a primelor de asigurare și a contribuțiilor) agregă BASS (24%), AOAM (9%) și impozitul pe venit (12%), cu evidență specială pentru inginerii IT rezidenți în Moldova IT Park (Categoria de asigurat 162 conform Legii nr. 77/2016).
• IU17 (Darea de seamă privind impozitul unic 7% pentru parcurile IT) calculează automat cota de 7% din venitul din vânzări și verifică respectarea plafonului minim legal per angajat:

Dacă 7% din cifra de afaceri este inferior acestui prag, motorul ajustează automat impozitul datorat la valoarea plafonului minim.

• rsf1_24 (Situațiile financiare anuale BNS) convertește balanța de verificare cu 6 coloane direct în structura XML a Bilanțului și a Raportului de Profit și Pierdere.

Foaia de parcurs R&D (sprinturile v4.1 – v4.5)

Când nu trebuie utilizată această arhitectură EDI fiscală

Nicio arhitectură software nu este universal valabilă. Implementarea unei suite complete de EDI fiscal într-un context nepotrivit generează costuri operaționale inutile:

1. Micro-întreprinderile cu volum redus de tranzacții nu au nevoie de cozi automate complexe. Dacă o organizație emite sub zece facturi pe lună și nu administrează stocuri fizice, implementarea cozilor EDI asincrone, a proceselor cron și a matricelor de mapare a nomenclatorului este nejustificată economic. Emiterea directă prin interfața web fisc.md și contabilizarea sumară rămân abordarea corectă.
2. Jurisdicțiile fără vămuire fiscală centralizată (CTC) nu folosesc portaluri de validare în timp real. Această arhitectură este concepută special pentru țările care aplică modelul de control continuu al tranzacțiilor (SIA e-Factura și MEV în Moldova, sistemul SDI în Italia sau RO e-Factura în România). Pentru companiile care activează exclusiv în regimuri fiscale post-audit descentralizate (SUA, Marea Britanie), aceste mașini cu stări și transformări canonice adaugă latență fără niciun beneficiu fiscal.
3. Punctele de vânzare cu echipamente mecanice neconectate necesită drivere locale dedicate. Arhitectura noastră presupune noduri de rețea moderne (case de marcat virtuale conectate la internet, POS web, plăți prin NFC TapXphone). Dacă un comerciant este obligat să folosească aparate de casă mecanice vechi, conectate prin cablu serial RS-232 și bandă de control pe hârtie, este necesar un driver middleware dedicat, nu o arhitectură ERP pură.