Kako funkcioniraju ERP sustavi: Moduli, tok podataka i temeljna glavna knjiga
Jedna transakcija praćena kroz svaki modul ERP-a, sa stvarnim temeljnicama i objašnjenjem zašto je glavna knjiga evidencija iz koje sve ostalo čita podatke.
ERP sustav funkcionira tako što svaki poslovni događaj sprema jednom, u jednoj bazi podataka, te omogućuje svakom modulu da čita i zapisuje u taj zajednički zapis. Otpremljena narudžba predstavlja isti zapis bez obzira na to gleda li je skladište, prodajni tim ili računovođa. Modul koji cijelom sustavu osigurava ispravnost jest glavna knjiga (general ledger): svaki događaj koji ima novčanu vrijednost ondje završava kao uravnotežena temeljnica (journal entry), a svaki se izvještaj izvodi upravo iz tih stavaka.
Ovaj članak prati jednu prodaju kroz module, prikazuje temeljnice koje ona proizvodi i objašnjava zašto se integracija s ERP-om temelji na događajima i glavnoj knjizi, a ne na sučeljima.
Dijeljena baza podataka
Prije pojave ERP-a, svaki je odjel koristio vlastiti program. Zalihe su se vodile u skladišnom sustavu, fakture u sustavu naplate, a poslovne knjige u računovodstvenom paketu. Kraj mjeseca provodio se u usklađivanju ta tri sustava. Članak Što je ERP softver? objašnjava ovu kategoriju, a mehanizam koji osigurava njezino funkcioniranje jest jedinstveni model podataka u kojem:
- zapis poslovnog partnera (partner) koriste i prodaja, i nabava, i glavna knjiga,
- zapis artikla (item) sadrži količinu zaliha, FIFO slojeve troškova, prodajnu cijenu i konto prihoda,
- dokument (narudžba, faktura, odobrenje, nabava, radni nalog) upućuje na partnere i artikle te proizvodi točno jedan skup temeljnica,
- temeljnica upućuje na dokument koji ju je stvorio, tako da se svaka brojka u izvještaju može pratiti do izvora.
Kada su zapisi dijeljeni, nema potrebe za usklađivanjem između modula. Ono što preostaje za usklađivanje jest vanjski svijet: bankovni izvodi i porezne prijave.
Mapa modula
| Modul | Zapisuje | Čita |
|---|---|---|
| Prodaja | Narudžbe, fakture, odobrenja | Partnere, artikle, cijene, pravila PDV-a |
| Nabava | Narudžbe dobavljača, ulazne račune | Partnere, artikle, konte troškova |
| Skladište | Skladišna kretanja, FIFO slojeve troškova, inventure | Artikle, skladišta |
| Proizvodnja | Radne naloge, utrošak sirovina, gotove proizvode | Sastavnice (BOM), zalihe |
| Banka | Uvezene transakcije, usklađenja plaćanja | Otvorene fakture, bankovne račune |
| Plaće | Obračune plaća, doprinose, izvještaje | Zaposlenike, ugovore, porezne tablice |
| Imovina | Registar dugotrajne imovine, obračune amortizacije | Skupine imovine, korisni vijek trajanja |
| Porezi | PDV obrasce, ZP obrasce, Intrastat, e-račune | Izdane i evidentirane dokumente |
| Glavna knjiga | Temeljnice, zaključke razdoblja | Sve navedeno iznad |
| Izvještavanje | Ništa | Glavnu knjigu i analitička knjigovodstva (subledgers) |
Svaki redak osim posljednja dva završava upisom u glavnu knjigu. To je projektno pravilo koje razlikuje ERP od skupa povezanih alata.
Praktičan tok podataka
Primjer u nastavku koristi Nordletove krajnje točke (endpoints) i zadane kontore litavskog kontnog plana s kojim dolazi. Svaki ERP obavlja iste korake, s time da se kontni planovi i nazivi krajnjih točaka mogu razlikovati.
1. Narudžba
Web-trgovina kreira narudžbu putem poziva POST /v1/ecommerce/orders/create: partner, stavke s artiklima i količinama, država isporuke. U glavnu se knjigu još uvijek ništa ne knjiži. Narudžba je preuzeta obveza, a ne transakcija.
2. Rezervacija zaliha
Poziv orders/reserve izdvaja količine kako druga narudžba ne bi mogla prodati iste jedinice. Temeljnica se još uvijek ne stvara: rezervirana je zaliha i dalje u vlasništvu.
3. Isporuka (fulfilment)
Poziv orders/fulfill bilježi izlazak robe iz skladišta. Dvije se stvari događaju unutar jedne transakcije baze podataka:
- Zaliha se troši po FIFO metodi troška: koriste se najstariji slojevi troškova za svaki artikl, što je metoda opisana u glosaru pod FIFO vrednovanje zaliha.
- Trošak tih jedinica knjiži se kao temeljnica: terećenje (debit) troška prodane robe, odobrenje (credit) zaliha.
| Konto | Duguje (Debit) | Potražuje (Credit) |
|---|---|---|
| 6000 Trošak prodane robe | 600.00 | |
| 2040 Zalihe | 600.00 |
Isporuka također stvara nacrt fakture (draft invoice) za narudžbu i određuje porezni tretman (PDV) na temelju države isporuke koristeći mehanizam za EU PDV.
4. Izdavanje fakture
Izdavanje fakture trenutak je u kojem se priznaje prihod za prodaju izvršenu u određenom trenutku. Dokument dobiva svoj serijski broj bez preskoka i knjiži se jedna uravnotežena temeljnica: bruto iznos na potraživanja od kupaca, PDV na konto obveza za PDV, a neto iznos na prihode.
Za neto prodaju od 1.000,00 € uz litavski PDV od 21%:
| Konto | Duguje (Debit) | Potražuje (Credit) |
|---|---|---|
| 2410 Potraživanja od kupaca | 1.210.00 | |
| 5000 Prihodi od prodaje robe | 1.000.000,00 (1.000,00) | |
| 4492 Obveze za PDV | 210.00 |
Ako stavka ima drugačiju metodu priznavanja prihoda umjesto trenutka isporuke, neto iznos ide na odgođene prihode, a mehanizam za priznavanje prihoda ih otpušta prema rasporedu. Knjiženje potraživanja i PDV-a se ne mijenja.
Faktura sada može biti poslana kao PDF, kao e-račun u formatu Peppol BIS 3.0 ili u nacionalnom formatu e-računa koji zahtijeva država u kojoj tvrtka posluje.
5. Bankovno usklađivanje
Dva tjedna kasnije stiže iznos od 1.210,00 €. Uplata stiže putem PSD2 bankovnog izvoda ili uvoza camt.053 datoteke. Bankovni modul ocjenjuje kandidate za fakture prema iznosu, pozivu na broj, nazivu druge ugovorne strane i IBAN-u, a poziv bank/transactions/match knjiži zatvaranje:
| Konto | Duguje (Debit) | Potražuje (Credit) |
|---|---|---|
| 2710 Žiro račun / Banka | 1.210.00 | |
| 2410 Potraživanja od kupaca | 1.210.00 |
Status fakture mijenja se u plaćeno i šalje se webhook sale_invoice.paid. Unos u glosaru Usklađivanje plaćanja detaljnije objašnjava logiku usklađivanja. Plaćanje u drugoj valuti istodobno knjiži realiziranu tečajnu razliku na konto dobitaka ili gubitaka.
6. Prijava PDV-a
Na kraju mjeseca nema potrebe za ponovnim ručnim unosom. Prijava PDV-a računa se iz izdanih i evidentiranih dokumenata: poziv declarations/eu/vat-return/compute za nacionalnu prijavu (FR0600 u Litvi), odnosno declarations/eu/oss/compute za prekograničnu prodaju krajnjim kupcima u sklopu Unijskog postupka (OSS). Gore navedena prodaja svrstava se u polje s redovnom stopom PDV-a u domaćoj prijavi jer joj je porezni sustav domestic.
7. Zaključak razdoblja
Nakon što je prijava predana, poziv ledger/periods/lock zaključuje mjesec. Od tog trenutka svako knjiženje s datumom unutar tog razdoblja, uključujući zakašnjelo bankovno usklađivanje ili ponovljeni API poziv, biva odbijeno uz HTTP statusni kod 409. Zaključivanje također pokreće priznavanje svih odgođenih prihoda koji dospijevaju s krajem razdoblja, čime se sprječava da se mjesec zaključi s ostvarenim prihodima koji su još uvijek na kontu obveza.
Zašto je glavna knjiga temeljni sustav evidencije
Svaki gore navedeni modul vodi analitičko knjigovodstvo (subledger): kupce po kupcima, dobavljače po dobavljačima, zalihe po artiklima, imovinu po sredstvima. Glavna knjiga sadrži zbrojeve s kojima se ta analitička knjigovodstva moraju slagati. Članak Analitičko knjigovodstvo vs. glavna knjiga objašnjava taj odnos, pri čemu je praktična poanta u tome da izvještaj izrađen iz glavne knjige i izvještaj izrađen iz analitike moraju dati isti iznos, a ERP to jamči tako što oba izvještava iz istih temeljnica.
Glavnu knjigu pouzdanom čine tri svojstva:
- Osigurana je ravnoteža. U sustavu Nordlet baza podataka odbija unose čiji debiti nisu jednaki kreditima. Pogreška u modulu ne može stvoriti neuravnoteženo knjiženje.
- Povijest je nepromjenjiva (append-only). Proknjižena se stavka nikada ne uređuje. Pogreška se ispravlja stornom i novim unosom, pri čemu su oba povezana s izvornikom. Unos u glosaru Nepromjenjiva glavna knjiga objašnjava zašto revizori inzistiraju na tome.
- Razdoblja se zaključuju. Zaključeni mjesec ne može se mijenjati, stoga brojke koje ste predali ostaju zabilježene u sustavu.
Integracija: događaji i idempotencija, a ne noćne sinkronizacije
Starije ERP integracije oslanjale su se na datoteke razmjenjivane noću: izvezi narudžbe, uvezi ih, provjeri zapisnik pogrešaka ujutro. Suvremeni ERP-ovi izlažu API, pa integracija postaje stvar dviju disciplina.
Događaji prema van (Events out). Kada se nešto promijeni, ERP vas o tome obavještava. Nordlet zapisuje svaki webhook događaj u odlazni sandučić (outbox) unutar iste transakcije baze podataka kao i samu promjenu, tako da dokument koji je poništen nikada ne emitira događaj i nijedan događaj nije izgubljen. Isporuke se potpisuju HMAC-SHA256 algoritmom i ponavljaju uz eksponencijalno kašnjenje (exponential backoff). Vaš sustav reagira na sale_invoice.paid umjesto da svakih pet minuta pita je li nešto plaćeno.
Sigurni ponovljeni pozivi prema unutra (Safe retries in). Mreže pucaju, a ponovljeni zahtjev ne smije stvoriti drugu fakturu. Nordlet prihvaća zaglavlje Idempotency-Key na svakom pozivu koji mijenja podatke: isti ključ s istim podatcima vraća spremljeni odgovor, isti ključ s drukčijim podatcima se odbija, a ključevi istječu nakon 24 sata. Unos u glosaru Idempotencija i API konvencije opisuju točno ponašanje sustava.
Budući da je svaka operacija poziv POST /v1/{module}/{resource}/{action} i aplikacija koristi iste krajnje točke, integracija može provesti cijeli gore opisani tijek bez da ijedna osoba otvori korisničko sučelje. Članak Kako integrirati API računovodstva u oblaku u SaaS platformu detaljno prolazi kroz takav razvoj.
Što izvještaji čitaju
Izvještaji ne pohranjuju brojke. Oni su upiti nad glavnom knjigom i analitičkim evidencijama u određenom trenutku:
- Bruto bilanca (trial balance), bilanca stanja, račun dobiti i gubitka, novčani tijek čitaju temeljnice prema kontima i razdobljima.
- Starosna struktura potraživanja i obveza (debt aging) čita otvorene stavke kupaca i dobavljača prema datumu dospijeća.
- Stanje i kretanje zaliha čitaju skladišno analitičko knjigovodstvo i njegove FIFO slojeve.
- Pregled PDV-a čita retke PDV-a iz izdanih i evidentiranih dokumenata.
- Izvještaji po troškovnim mjestima čitaju dimenziju troškovnog mjesta na svakom retku temeljnice.
U Nordletu se izvještaj generira u pozadini u XLSX, PDF ili JSON formatu, a kada je datoteka spremna, aktivira se webhook. Grupne brojke dolaze iz konsolidacije, koja kombinira glavne knjige nekoliko tvrtki uz ponderiranje vlasničkog udjela i preračunavanje valuta.
Gdje ovo zapinje u praksi
Većina problema s ERP-om posljedica je kršenja načela dijeljenog zapisa, a ne pogrešaka u softveru. Uobičajeni slučajevi su:
- Paralelna tablica u Excelu za nešto što ERP "ne može učiniti", a koja se potom ne slaže s poslovnim knjigama.
- Ručne temeljnice koje se koriste za ispravljanje izlaza iz modula umjesto ispravljanja samog dokumenta, što narušava trag revizije od izvještaja do izvora.
- Integracije koje upisuju stanja umjesto dokumenata, pa glavna knjiga sadrži zbrojeve koje nitko ne može objasniti.
- Otvorena razdoblja koja mjesecima ostaju zaključana, zbog čega se brojke koje ste predali za prošli kvartal s vremenom razilaze.
Članak Zašto implementacije ERP-a propadaju opisuje kako ove navike nastaju tijekom uvođenja, dok Realni rokovi implementacije ERP-a pokazuje u kojim se fazama projekta obično pojavljuju.
FAQ
Što je jezgra ERP sustava?
Glavna knjiga i zajednički model podataka koji se oko nje nalazi. Svaki modul upisuje dokumente koji stvaraju uravnotežene temeljnice, a svaki se izvještaj izvodi iz tih unosa.
Kako podaci teku kroz ERP?
Događaj se bilježi jednom kao dokument (narudžba, faktura, kretanje, obračun plaća). Dokument proizvodi temeljnice u glavnoj knjizi i kretanja u relevantnom analitičkom knjigovodstvu. Izvještaji i porezne prijave izračunavaju se iz tih zapisa. Ništa se ne kopira između modula.
Koja je razlika između modula i integracije?
Modul zapisuje podatke u istu bazu podataka i istu glavnu knjigu kao i ostatak sustava. Integracija je vanjski program koji poziva API ERP-a. Kod ERP-a s naglaskom na API (API-first), ta je razlika mala jer integracija koristi iste krajnje točke koje koriste i moduli.
Knjiži li ERP računovodstvene stavke automatski?
Da. Izdavanje fakture, isporuka narudžbe, usklađivanje plaćanja, obračun plaća ili amortizacija imovine stvaraju svoju temeljnicu bez potrebe da neka osoba ručno slaže dugovanja i potraživanja. Korišteni konti dolaze iz pravila knjiženja koja se mogu mijenjati po tvrtkama.
Zašto ERP sustavi zaključuju računovodstvena razdoblja?
Kako se brojke prijavljene ili predane za neko razdoblje ne bi mogle naknadno mijenjati. Zaključeno razdoblje odbija nova knjiženja, čime štiti trag revizije i prisiljava na ispravke u tekućem razdoblju gdje su vidljivi.