Kako delujejo sistemi ERP: Moduli, pretok podatkov in temeljna glavna knjiga
Ena transakcija, ki gre skozi vsak modul sistema ERP, z dejanskimi knjižbami in razlago, zakaj je glavna knjiga evidenca, iz katere vse ostalo črpa podatke.
Sistem ERP deluje tako, da vsak poslovni dogodek shrani enkrat, v eno podatkovno bazo, in omogoča vsakemu modulu, da bere in piše v ta skupni zapis. Odpremljeno naročilo je enak zapis, ne glede na to, ali si ga ogleduje skladišče, prodajna ekipa ali računovodja. Modul, ki skrbi za doslednost celotnega sistema, je glavna knjiga (general ledger): vsak dogodek z denarno vrednostjo se tam konča kot uravnavotena temeljnica, vsa poročila pa izvirajo iz teh knjižb.
Ta članek sledi eni prodaji skozi module, prikazuje knjižbe, ki jih ta ustvarja, in pojasnjuje, zakaj integracija z ERP-jem temelji na dogodkih in glavni knjigi ter ne na uporabniških vmesnikih.
Skupna podatkovna baza
Pred sistemi ERP je vsak oddelek poganjal svoj program. Zaloga je bila v skladiščnem sistemu, računi v fakturirnem programu, knjigovodstvo pa v računovodski rešitvi. Konec meseca se je porabilo za usklajevanje vseh treh. Članek Kaj je programska oprema ERP pojasnjuje to kategorijo; mehanizem, ki omogoča njeno delovanje, pa je enoten podatkovni model, v katerem:
- zapis poslovnega partnerja (partner) hkrati uporabljajo prodaja, nabava in glavna knjiga,
- zapis artikla (item) vsebuje količino zaloge, FIFO stroškovne sloje, prodajno ceno in konto prihodkov,
- dokument (naročilo, račun, dobropis, naročilo za nabavo, delovni nalog) se sklicuje na partnerje in artikle ter ustvari natanko en niz knjižb,
- temeljnica (journal entry) se sklicuje na dokument, ki jo je ustvaril, zato je mogoče vsak podatek v poročilu slediti nazaj do vira.
Ko so zapisi skupni, med moduli ni ničesar več za usklajevanje. Kar ostane za usklajevanje, je zunanji svet: bančni izpiski in davčni obračuni.
Pregled modulov
| Modul | Piše | Bere |
|---|---|---|
| Prodaja | Naročila, računi, dobropisi | Partnerji, artikli, cene, pravila za DDV |
| Nabava | Naročilnice, prejeti računi | Partnerji, artikli, konti stroškov |
| Zaloge | Premiki zalog, FIFO stroškovni sloji, popisi | Artikli, skladišča |
| Proizvodnja | Delovni nalogi, poraba sestavin, gotovi izdelki | Normativi, zaloga |
| Banka | Uvožene transakcije, ujemanja plačil | Odprti računi, bančni računi |
| Plače | Obračuni plač, prispevki, oddaje | Zaposleni, pogodbe, davčne lestvice |
| Osnovna sredstva | Registri osnovnih sredstev, obračuni amortizacije | Skupine sredstev, dobe uporabnosti |
| Davki | Obračuni DDV, rekapitulacijska poročila, Intrastat, e-računi | Izdani in knjiženi dokumenti |
| Glavna knjiga | Temeljnice, zaklepanje obdobij | Vse zgoraj navedeno |
| Poročanje | Ničesar | Glavna knjiga in pomožne knjige |
Vsaka vrstica razen zadnjih dveh se zaključuje s pisanjem v glavno knjigo. To je načrtovalsko pravilo, ki loči sistem ERP od niza povezanih orodij.
Delujoč pretok podatkov
Spodnji primer uporablja končne točke (endpoints) rešitve Nordlet in privzete konte litvanskega kontnega načrta, ki je priložen sistemu. Vsak ERP izvaja iste korake, le kontne šifre in imena končnih točk se razlikujejo.
1. Naročilo
Spletna trgovina odda naročilo prek zahteve POST /v1/ecommerce/orders/create: partner, postavke z artikli in količinami, država prejemnika. V glavno knjigo se za zdaj še ne knjiži ničesar. Naročilo je zaveza, ne transakcija.
2. Rezervacija zaloge
Ukaz orders/reserve odloži količine na stran, tako da drugo naročilo ne more prodati istih enot. Še vedno ni knjižbe: rezervirana zaloga je še vedno v lasti podjetja.
3. Izpolnitev naročila (fulfilment)
Ukaz orders/fulfill zabeleži odhod blaga iz skladišča. V eni transakciji podatkovne baze se zgodita dve stvari:
- Zaloga se porabi po FIFO stroškovni metodi: uporabijo se najstarejši stroškovni sloji za posamezen artikel, kar je metoda, opisana v glosarju vrednotenje zaloge po FIFO metodi.
- Strošek teh enot se knjiži kot temeljnica v v breme konta stroškov prodanega blaga in v dobro konta zalog.
| Konto | V breme (Debit) | V dobro (Credit) |
|---|---|---|
| 6000 Stroški prodanega blaga | 600.00 | |
| 2040 Zaloge | 600.00 |
Izpolnitev naročila ustvari tudi osnutek računa za naročilo in določi obravnavo DDV glede na državo prejemnika z uporabo motorja za EU DDV.
4. Izdaja računa
Izdaja računa je trenutek, ko se prihodki pripoznajo pri prodaji ob določenem času. Dokument dobi svojo neprekinjeno številko in knjiži se ena uravnavotena temeljnica: bruto znesek na terjatve, DDV na konto izdanega DDV in neto znesek na prihodke.
Za neto prodajo v višini 1.000,00 EUR z 21-odstotnim litvanskim DDV:
| Konto | V breme (Debit) | V dobro (Credit) |
|---|---|---|
| 2410 Terjatve do kupcev | 1.210.00 | |
| 5000 Prihodki od prodaje blaga | 1.000.00 | |
| 4492 Obveznosti za izstopajoči DDV | 210.00 |
Če postavka vsebuje drugačno metodo pripoznavanja kot ob določenem času, gre neto znesek namesto tega na pasivne časovne razmejitve (deferred income), motor za pripoznavanje prihodkov pa ga sprosti po načrtu. Knjiženje terjatev in DDV se ne spremeni.
Račun lahko zdaj zapusti sistem v obliki PDF, kot e-račun v standardu Peppol BIS 3.0 ali v nacionalnem formatu e-invoziranja, ki ga zahteva država podjetja.
5. Bančna uskladitev
Dva tedna kasneje prispe znesek 1.210,00 EUR. Priliv pride prek bančnega prenosa PSD2 ali uvoza izpiska camt.053. Bančni modul oceni kandidate med računi glede na znesek, sklic, ime nasprotne stranke in IBAN, ukaz bank/transactions/match pa knjiži poravnavo:
| Konto | V breme (Debit) | V dobro (Credit) |
|---|---|---|
| 2710 Transakcijski račun | 1.210.00 | |
| 2410 Terjatve do kupcev | 1.210.00 |
Status računa se spremeni v plačano in sproži se spletni dogodek (webhook) sale_invoice.paid. Vnos v glosarju o usklajevanju plačil podrobneje pojasnjuje logiko ujemanja. Plačilo v drugi valuti v enakem koraku knjiži realizirano tečajno razliko na konto dobičkov ali izguba.
6. Obračun DDV
Konec meseca ni treba ponovno tipkati podatkov. Obračun DDV se izračuna iz izdanih in knjiženih dokumentov: declarations/eu/vat-return/compute za nacionalni obračun (FR0600 v Litvi), declarations/eu/oss/compute za čezmejno prodajo končnim kupcem v okviru sheme VEMV (OSS). Zgornja prodaja pristane v polju za standardno stopnjo domačega obračuna, ker je njen DDV sistem domestic (domači).
7. Zaklepanje obdobja
Ko je obračun oddan, ukaz ledger/periods/lock zapre mesec. Od takrat naprej se vsaka knjižba z datumom v tem obdobju, vključno z zapoznelo bančno uskladitvijo ali ponovnim klicem API, zavrne s kodo HTTP 409. Zaklepanje sproži tudi pripoznavanje vseh odloženih prihodkov, ki zapadejo do konca obdobja, zato se mesec ne more zaključiti tako, da bi ustvarjeni prihodki ostali na kontu obveznosti.
Zakaj je glavna knjiga evidenca resnice
Vsak zgornji modul vodi pomožno knjigo (subledger): terjatve po kupcih, obveznosti po dobaviteljih, zaloge po artiklih, osnovna sredstva po sredstvih. Glavna knjiga hrani vsotne zneske, s katerimi se morajo te pomožne knjige ujemati. Članek Pomožna knjiga proti glavni knjigi obravnava to razmerje; praktično bistvo je, da morata poročilo, zgrajeno iz glavne knjige, in poročilo, zgrajeno iz pomožne knjige, dati enak znesek, ERP pa to zagotavlja tako, da obe ustvari iz istih temeljnica.
Glavno knjigo delajo zaupanja vredno evidenco tri lastnosti:
- Uravnoteženost je obvezna. V sistemu Nordlet podatkovna baza zavrne vnos, katerega bremenitve niso enake dobroimetjem. Hrošč v modulu ne more ustvariti neuravnavnanega knjiženja.
- Zgodovina je nespremenljiva (append-only). Knjižena temeljnica se nikoli ne popravlja. Napaka se popravi s storno knjižbo in novim vnosom, pri čemer sta oba povezana z izvirnikom. Vnos v glosarju o nespremenljivi glavni knjigi pojasnjuje, zakaj revizorji vztrajajo pri tem.
- Obdobja se zapirajo. Zaklenjenega meseca ni mogoče spreminjati, zato so številke, ki ste jih oddali, tiste, ki ostanejo v sistemu.
Integracija: dogodki in idempotenca namesto nočnih paketnih obdelav
Starejše integracije ERP so delovale na podlagi datotek, izmenjanih ponoči: izvoz naročil, uvoz, preverjanje dnevnika napak zjutraj. Sodobni sistemi ERP ponujajo vmesnik API, zato integracija postane vprašanje dveh strogi disciplin.
Dogodki navzven (events out). Ko se nekaj spremeni, vas ERP o tem obvesti. Nordlet zapisuje vsak dogodek spletnega klavlika (webhook) v izhodno čakalno vrsto (outbox) v isti transakciji podatkovne baze kot spremembo, zato dokument, ki je bil razveljavljen, nikoli ne sproži dogodka in noben dogodek se ne izgubi. Dostave so podpisane s ključem HMAC-SHA256 in se ponavljajo z eksponentnim pojemanjem (exponential backoff). Vaš sistem se odzove na dogodek sale_invoice.paid, namesto da vsakih pet minut sprašuje, ali je kaj plačano.
Varna ponavljanja navznoter (safe retries in). Omrežja odpovedo, ponovljena zahteva pa ne sme ustvariti drugega računa. Nordlet sprejema glavo Idempotency-Key pri vsakem klicu, ki spreminja podatke: isti ključ z istim bremenitvom (payload) vrne shranjen odziv, isti ključ z drugačnim bremenitvom se zavrne, ključi pa potečejo po 24 urah. Vnos v glosarju o idempotenci in konvencije API opisujejo točno obnašanje.
Ker je vsaka operacija klic POST /v1/{module}/{resource}/{action} in aplikacija uporablja iste končne točke, lahko integracija izvede celoten zgornji pretok, ne da bi kdor koli odprl uporabniški vmesnik. Članek Kako integrirati API za v oblaku podprto računovodstvo v platformo SaaS vodi skozi takšno gradnjo.
Kaj berejo poročila
Poročila ne shranjujejo številk. So poizvedbe nad glavno in pomožnimi knjigami ob določenem času:
- Bruto bilanca, bilanca stanja, izkaz poslovnega izida in izkaz denarnih tokov berejo temeljnice po kontih in obdobjih.
- Staranje terjatev (debt aging) bere odprte terjatve in obveznosti po datumu zapadlosti.
- Stanje in gibanje zalog bereta pomožno knjigo zalog in njene FIFO sloje.
- Pregled DDV bere postavke DDV izdanih in knjiženih dokumentov.
- Poročila po stroškovnih mestih berejo dimenzijo stroškovnega mesta na vsaki vrstici temeljnice.
V sistemu Nordlet se poročilo ustvari v ozadju kot datoteka XLSX, PDF ali JSON, ko pa je datoteka pripravljena, se sproži spletni klic (webhook). Skupni zneski izvirajo iz konsolidacije, ki združuje glavne knjige več podjetij z upoštevanjem lastniških deležev in preračunom valut.
Kje se to v praksi zatakne
Večina težav s sistemi ERP izhaja iz kršitve načela skupnega zapisa in ne iz programske opreme. Pogosti primeri:
- Vzporedna preglednica (spreadsheet) za nekaj, česar ERP "ne zna narediti", kar se nato ne ujema s knjigami.
- Ročne temeljnice, ki se uporabljajo za popravljanje izhoda modula namesto popravljanja dokumenta, kar prekinja sled od poročila do vira.
- Integracije, ki pišejo stanja namesto dokumentov, zaradi česar glavna knjiga vsebuje vsote, ki jih nihče ne zna pojasniti.
- Odprta obdobja, ki ostanejo odklenjena mesece, zaradi česar se oddane številke preteklega četrtletja razidejo.
Članek Zakaj implementacije ERP propadajo obravnava, kako te navade nastanejo med uvajanjem, članek Realistični roki za implementacijo ERP pa prikazuje, kje v projektu se običajno pojavijo.
FAQ
Kaj je jedro sistema ERP?
Glavna knjiga in skupni podatkovni model okoli nje. Vsak modul piše dokumente, ki ustvarjajo uravnavotene temeljnice, vsako poročilo pa izhaja iz teh knjižb.
Kako podatki tečejo skozi ERP?
Dogodek se enkrat zabeleži kot dokument (naročilo, račun, premik, obračun plač). Dokument ustvari temeljnice v glavni knjigi in premike v ustrezni pomožni knjigi. Poročila in davčni obračuni se izračunajo iz teh zapisov. Med moduli se ničesar ne kopira.
Kakšna je razlika med modulom in integracijo?
Modul piše v isto podatkovno bazo in isto glavno knjigo kot preostali sistem. Integracija je zunanji program, ki kliče vmesnik API sistema ERP. Pri ERP-ju, ki daje prednost vmesnikom API (API-first), je ta razlika majhna, ker integracija uporablja iste končne točke, ki jih uporabljajo moduli.
Ali ERP knjiži računovodske dogodke samodejno?
Da. Izdaja računa, izpolnitev naročila, uskladitev plačila, obračun plač ali amortizacija osnovnih sredstev – vsak od teh postopkov ustvari svojo temeljnico, ne da bi moral kdor koli ročno določati bremene in dobre. Uporabljeni konti izhajajo iz pravil knjiženja, ki jih je mogoče nastaviti za posamezno podjetje.
Zakaj sistemi ERP zaklepajo računovodska obdobja?
Zato da se številke, ki so bile poročane ali oddane za obdobje, pozneje ne morejo več spremeniti. Zaklenjeno obdobje zavrača nova knjiženja, kar ščiti revizijsko sled in prisili popravke v tekoče obdobje, kjer so vidni.