Cum funcționează sistemele ERP: module, flux de date și registrul contabil din spate
O tranzacție urmărită prin fiecare modul al unui ERP, cu notele contabile aferente și explicația motivului pentru care registrul-jurnal este sursa unică de adevăr pentru tot restul sistemului.
Un sistem ERP funcționează prin stocarea fiecărui eveniment de afaceri o singură dată, într-o singură bază de date, permițând fiecărui modul să citească și să scrie în acea înregistrare partajată. O comandă livrată este exact aceeași înregistrare, indiferent dacă este consultată de departamentul logistic, de echipa de vânzări sau de contabil. Modulul care menține corectitudinea întregului sistem este registrul-jurnal (general ledger): fiecare eveniment cu valoare monetară se încheie acolo sub forma unei note contabile echilibrate, iar fiecare raport este derivat din aceste înregistrări.
Acest articol urmărește o vânzare prin intermediul modulelor, prezintă notele contabile pe care le generează și explică de ce integrarea cu un ERP se referă la evenimente și la registrul contabil, nu la interfețele grafice.
Baza de date partajată
Înainte de apariția sistemelor ERP, fiecare departament rula propria aplicație. Stocurile se aflau într-un sistem de gestiune a depozitului, facturile într-un sistem de facturare, iar contabilitatea într-un program separat. Sfârșitul de lună era dedicat reconcilierii dintre cele trei. Articolul Ce este un software ERP? explică această categorie de produse; mecanismul care le face să funcționeze este un singur model de date în care:
- o înregistrare de tip partener (partner) este utilizată în mod egal de vânzări, achiziții și contabilitate,
- o înregistrare de tip articol (item) conține cantitatea din stoc, straturile de cost FIFO, prețul de vânzare și contul de venituri,
- un document (comandă, factură, notă de credit, achiziție, ordin de producție) face referire la parteneri și articole și generează exact un set de note contabile,
- o notă contabilă (journal entry) face trimitere la documentul care a generat-o, astfel încât fiecare cifră dintr-un raport poate fi urmărită până la sursă.
Atunci când înregistrările sunt partajate, nu mai există elemente de reconciliat între module. Ceea ce rămâne de reconciliat este lumea exterioară: extrasele bancare și declarațiile fiscale.
Harta modulelor
| Modul | Scrie | Citește |
|---|---|---|
| Vânzări | Comenzi, facturi, note de credit | Parteneri, articole, prețuri, reguli de TVA |
| Achiziții | Comenzi de achiziție, facturi de furnizor | Parteneri, articole, conturi de cheltuieli |
| Gestiune stocuri | Mișcări de stoc, straturi de cost FIFO, inventare | Articole, depozite |
| Producție | Ordine de producție, consum de componente, produse finite | Liste de materiale (BOM), stocuri |
| Bancă | Tranzacții importate, reconcilieri de plăți | Facturi deschise, conturi bancare |
| Salarizare | State de plată, contribuții, declarații | Angajați, contracte, grile de impozitare |
| Imobilizări | Registrul imobilizărilor, rulaje de amortizare | Grupe de imobilizări, durate de viață |
| Taxe | Deconturi de TVA, declarații intracomunitare, Intrastat, e-facturi | Documente emise și înregistrate |
| Registru-jurnal | Note contabile, închideri de perioadă | Tot ce este mai sus |
| Raportare | Nimic | Registrul-jurnal și jurnalele auxiliare |
Fiecare rând, cu excepția ultimelor două, se încheie cu o scriere în registrul-jurnal. Aceasta este regula de design care distinge un ERP de un set de unelte conectate între ele.
Un flux de date practic
Exemplul de mai jos utilizează endpointurile Nordlet și conturile implicite din planul de conturi lituanian inclus în platformă. Orice ERP parcurge aceiași pași; codurile de cont și numele endpointurilor pot diferi.
1. Comanda
Un magazin online plasează o comandă prin POST /v1/ecommerce/orders/create: un partener, linii cu articole și cantități, o țară de destinație pentru livrare. Deocamdată nu se înregistrează nimic în contabilitate. O comandă reprezintă un angajament, nu o tranzacție.
2. Rezervarea stocului
Funcția orders/reserve blochează cantitățile respective, astfel încât o a doua comandă să nu poată vinde aceleași unități. În continuare, nu există nicio notă contabilă: stocul rezervat se află încă în proprietatea companiei.
3. Livrarea (fulfilment)
Funcția orders/fulfill înregistrează ieșirea bunurilor din depozit. Două lucruri se întâmplă simultan în aceeași tranzacție de bază de date:
- Stocul este descărcat la costul FIFO: sunt utilizate mai întâi cele mai vechi straturi de cost pentru fiecare articol, aceasta fiind metoda descrisă în secțiunea de glosar Evaluarea stocurilor FIFO (FIFO inventory valuation).
- Costul acestor unități se înregistrează ca o notă contabilă: debit costul bunurilor vândute, credit stocuri.
| Cont | Debit | Credit |
|---|---|---|
| 6000 Costul bunurilor vândute | 600,00 | |
| 2040 Stocuri | 600,00 |
Livrarea creează, de asemenea, o factură în ciornă (draft invoice) pentru comandă și stabilește tratamentul fiscal privind TVA-ul pe baza țării de destinație, utilizând motorul de TVA UE (EU VAT engine).
4. Emiterea facturii
Emiterea facturii este momentul în care se recunoaște venitul pentru o vânzare punctuală (point-in-time). Documentul primește numărul său secvențial, fără întreruperi, și se generează o înregistrare contabilă echilibrată: valoarea brută în clienți, TVA-ul în contul de TVA colectat, iar valoarea netă în contul de venituri.
Pentru o vânzare netă de 1.000 EUR cu o cotă de TVA de 21% în Lituania:
| Cont | Debit | Credit |
|---|---|---|
| 2410 Clienți | 1.210,00 | |
| 5000 Venituri din vânzarea mărfurilor | 1.000,00 | |
| 4492 TVA colectat | 210,00 |
Dacă o linie conține o altă metodă de recunoaștere decât cea punctuală, valoarea netă merge în contul de venituri în avans (deferred income), iar motorul de recunoaștere a veniturilor (revenue recognition engine) o deblochează conform scadențarului. Înregistrarea clienților și a TVA-ului rămâne neschimbată.
Factura poate fi acum expediată ca fișier PDF, ca e-factură în format Peppol BIS 3.0 sau în formatul național de e-facturare cerut de legislația din țara companiei.
5. Reconcilierea bancară
Două săptămâni mai târziu, suma de 1.210 EUR intră în cont. Această mișcare este preluată printr-un flux bancar PSD2 sau prin importul unui extras în format camt.053. Modulul bancar evaluează potențialele facturi pe baza sumei, a referinței de plată, a numelui contrapartidei și a IBAN-ului, iar funcția bank/transactions/match înregistrează decontarea:
| Cont | Debit | Credit |
|---|---|---|
| 2710 Conturi la bănci | 1.210,00 | |
| 2410 Clienți | 1.210,00 |
Starea facturii se actualizează la „plătită” și este emis un webhook de tip sale_invoice.paid. Articolul de glosar Reconcilierea plăților (payment reconciliation) explică logica de potrivire în detaliu. O plată efectuată în altă monedă înregistrează diferența de curs valutar realizată în contul de profituri sau pierderi în același pas.
6. Decontul de TVA
La sfârșitul lunii, nu este nevoie de nicio reintroducere manuală a datelor. Decontul de TVA este calculat pe baza documentelor emise și înregistrate: declarations/eu/vat-return/compute pentru decontul național (FR0600 în Lituania) și declarations/eu/oss/compute pentru vânzările transfrontracțiere către consumatori în cadrul regimului comunitar (OSS). Vânzarea de mai sus este inclusă în secțiunea pentru cota standard a decontului intern, deoarece regimul său de TVA este domestic.
7. Închiderea perioadei
Odată ce declarația a fost depusă, funcția ledger/periods/lock închide luna. Din acel moment, orice înregistrare contabilă datată în perioada respectivă, inclusiv o reconciliere bancară întârziată sau un apel API reîncercat, este respinsă cu eroarea HTTP 409. Blocarea declanșează, de asemenea, recunoașterea veniturilor în avans scadente până la sfârșitul perioadei, astfel încât o lună nu se poate încheia cu venituri câștigate rămase în contul de datorii.
De ce registrul-jurnal este sistemul de înregistrare de bază
Fiecare modul menționat anterior gestionează un jurnal auxiliar (subledger): clienții pe solduri individuale, furnizorii la fel, stocurile pe articole, imobilizările pe bunuri. Registrul-jurnal (general ledger) conține totalurile cu care aceste jurnale auxiliare trebuie să fie în perfectă concordanță. Articolul Jurnal auxiliar vs. registru-jurnal (Subledger vs general ledger) detaliază această relație; aspectul practic este că un raport generat din registrul-jurnal și un raport generat dintr-un jurnal auxiliar trebuie să indice exact aceeași valoare, iar un ERP garantează acest lucru generându-le pe ambele din aceleași note contabile (journal entry).
Trei proprietăți fac ca registrul-jurnal să fie demn de încredere ca sistem de evidență:
- Echilibrul este obligatoriu. În Nordlet, baza de date refuză orice înregistrare în care debitele nu sunt egale cu creditele. O eroare de programare într-un modul nu poate genera o înregistrare contabilă dezechilibrată.
- Istoricul este doar pentru adăugare (append-only). O înregistrare contabilă validată nu este niciodată modificată. O greșeală este corectată printr-o stornare și o nouă înregistrare, ambele legate de documentul original. Articolul de glosar Registru-jurnal imutabil (immutable ledger) explică motivul pentru care auditorii insistă asupra acestui aspect.
- Perioadele se închid. O lună blocată nu poate fi modificată, astfel încât cifrele pe care le-ați declarat sunt cele care rămân în sistem.
Integrare: evenimente și idempotență, nu loturi nocturne (batch jobs)
Integrările ERP mai vechi funcționau pe baza unor fișiere schimbate pe timpul nopții: se exportau comenzi, se importau, se verifica jurnalul de erori dimineața. ERP-urile moderne expun un API, iar integrarea devine o chestiune bazată pe două principii fundamentale.
Evenimente de ieșire (Events out). Atunci când se produce o modificare, ERP-ul vă notifică. Nordlet scrie fiecare eveniment de tip webhook într-o coadă de ieșire (outbox) în cadrul aceleiași tranzacții de bază de date cu modificarea în sine, astfel încât un document care a fost anulat nu va emite niciodată un eveniment și niciun eveniment nu se pierde. Livrările sunt semnate criptografic folosind HMAC-SHA256 și sunt reîncercate cu un interval de timp crescător în progresie geometrică (exponential backoff). Sistemul dumneavoastră reacționează la evenimentul sale_invoice.paid în loc să interogheze sistemul la fiecare cinci minute pentru a afla dacă o factură a fost achitată.
Reîncercări sigure (Safe retries in). Rețelele pot cădea, iar o cerere reîncercată nu trebuie să creeze o a doua factură. Nordlet acceptă un antet HTTP Idempotency-Key pentru fiecare apel de modificare: aceeași cheie trimisă cu același conținut returnează răspunsul stocat anterior, aceeași cheie trimisă cu un conținut diferit este respinsă, iar cheile expiră după 24 de ore. Articolul de glosar Idempotență (idempotency) și documentul Convenții API (API conventions) descriu comportamentul exact.
Deoarece fiecare operațiune reprezintă un apel de tip POST /v1/{module}/{resource}/{action} iar aplicația folosește aceleași endpointuri, o integrare poate rula întregul flux de mai sus fără ca nimeni să deschidă o interfață vizuală. Ghidul Cum se integrează un API de contabilitate în cloud într-o platformă SaaS parcurge etapele unei astfel de implementări.
Ce citește raportarea
Rapoartele nu stochează cifre. Ele reprezintă interogări efectuate asupra registrului-jurnal și a jurnalelor auxiliare la un moment dat în timp:
- Balanța de verificare, bilanțul, contul de profit și pierdere, fluxul de numerar citesc notele contabile grupate pe conturi și perioade.
- Vechimea soldurilor (debt aging) citește clienții și furnizorii deschiși pe date de scadență.
- Soldul și mișcările de stoc citesc jurnalul auxiliar de inventar și straturile sale FIFO.
- Sumarul de TVA citește liniile de TVA din documentele emise și înregistrate.
- Rapoartele pe centre de cost citesc dimensiunea centrului de cost de pe fiecare linie contabilă.
În Nordlet, un raport este generat în fundal ca fișier XLSX, PDF sau JSON, iar un webhook se declanșează când fișierul este gata. Cifrele consolidate provin din secțiunea de consolidare (consolidation), care combină registrele contabile ale mai multor companii aplicând ponderi de deținere și conversie valutară.
Unde se blochează acest mecanism în practică
Cele mai multe probleme legate de ERP-uri reprezintă eșecuri ale principiului de înregistrare partajată, nu probleme de software. Situații frecvente:
- Un tabel paralel în Excel pentru ceva ce ERP-ul „nu poate face”, care ajunge ulterior să intre în contradicție cu registrele contabile.
- Note contabile manuale utilizate pentru a corecta rezultatul unui modul în loc să se corecteze documentul sursă, ceea ce rupe firul trasabilității de la raport la originea sa.
- Integrări care scriu solduri în loc de documente, lăsând registrul-jurnal cu totaluri pe care nimeni nu le poate explica.
- Perioade deschise lăsate neblocate timp de luni de zile, astfel încât cifrele declarate pentru trimestrul trecut ajung să sufere modificări ulterioare.
Articolul De ce eșuează implementările ERP? analizează modul în care se formează aceste obiceiuri în timpul unui proiect, iar Termene realiste de implementare ERP arată în ce etapă a proiectului își fac de obicei apariția.
FAQ
Care este nucleul unui sistem ERP?
Registrul-jurnal (general ledger) și modelul de date partajat din jurul acestuia. Fiecare modul generează documente care produc note contabile echilibrate, iar fiecare raport este derivat din aceste înregistrări.
Cum circulă datele printr-un ERP?
Un eveniment este înregistrat o singură dată sub formă de document (comandă, factură, mișcare de stoc, stat de plată). Documentul generează note contabile în registrul-jurnal și mișcări în jurnalul auxiliar corespunzător. Rapoartele și declarațiile fiscale sunt calculate pe baza acelor înregistrări. Nimic nu este copiat manual între module.
Care este diferența dintre un modul și o integrare?
Un modul scrie în aceeași bază de date și în același registru-jurnal ca restul sistemului. O integrare este un program extern care apelează API-ul ERP-ului. În cazul unui ERP centrat pe API (API-first), distincția este minimă, deoarece integrarea utilizează aceleași endpointuri pe care le folosesc și modulele native.
Un ERP înregistrează automat notele contabile?
Da. Emiterea unei facturi, livrarea unei comenzi, reconcilierea unei plăți, generarea statului de plată sau amortizarea unei imobilizări generează fiecare nota contabilă aferentă fără ca o persoană să fie nevoită să creeze manual debite și credite. Conturile utilizate provin din reguli de înregistrare contabilă care pot fi configurate pentru fiecare companie în parte.
De ce blochează ERP-urile perioadele contabile?
Pentru ca cifrele raportate sau declarate pentru o perioadă să nu mai poată fi modificate ulterior. O perioadă blocată respinge noile înregistrări contabile, protejând astfel pista de audit (audit trail) și forțând efectuarea oricăror corecturi în perioada curentă, unde acestea devin vizibile.