Kuidas ERP-süsteemid töötavad: moodulid, andmevoog ja alusdokumentideta raamatupidamine
Üks tehing läbi kõigi ERP moodulite koos tegelike raamatupidamiskannetega ning selgitus, miks pearaamat on keskne dokument, millest kõike muud loetakse.
ERP-süsteem ehk majandustarkvara toimib nii, et iga ärisündmus salvestatakse ühe korraga ühte andmebaasi ning iga moodul loeb ja kirjutab seda ühist kirjet. Väljasaadetud tellimus on täpselt sama kirje sõltumata sellest, kas seda vaatab lao töötaja, müügimeeskond või raamatupidaja. Moodul, mis hoiab kogu süsteemi korras, on pearaamat: iga rahalise väärtusega sündmus lõpeb seal tasakaalus kande kujul ja kõik aruanded tuletatakse nendest kannetest.
See artikkel jälgib ühte müügitehingut läbi erinevate moodulite, näitab sellega kaasnevaid raamatupidamiskandeid ja selgitab, miks ERP-ga liidestumisel on keskne roll sündmustel ja pearaamatul, mitte ekraanivaadetel.
Ühine andmebaas
Enne ERP-süsteemide kasutuselevõttu kasutas iga osakond oma programmi. Laoseis asus laoprogrammis, arved arveldamissüsteemis ja finantsandmed raamatupidamistarkvaras. Kuu lõpp kulus nende kolme sobitamisele ehk vastavusse viimisele. Artikkel Mis on ERP-tarkvara? selgitab seda tarkvarakategooriat; mehhanism, mis paneb selle toimima, on ühtne andmemudel, milles:
- partneri kirjet kasutavad nii müük, ostuosakond kui ka pearaamat ühiselt,
- artikli kirje sisaldab laokogust, FIFO-meetodil arvutatud soetusmaksumuse kihte (FIFO cost layers), müügihinda ja tulu kontot,
- dokument (tellimus, arve, kreeditarve, ost, tootmistellimus) viitab partneritele ja artiklitele ning genereerib täpselt ühe komplekti raamatupidamiskandeid,
- raamatupidamiskanne viitab dokumendile, mis selle tekitas, nii et iga aruande numbrit saab algallikani välja jälitada.
Kui kirjed on ühised, pole moodulite vahel vaja midagi eraldi klapitada. Välismaailm on aga endiselt see, mida tuleb sobitada: pangaväljavõtted ja maksuaruanded.
Moodulite kaart
| Moodul | Kirjutab | Loeb |
|---|---|---|
| Müük | Tellimused, arved, kreeditarved | Partnerid, artiklid, hinnad, käibemaksureeglid |
| Ost | Ostutellimused, tarnijate arved | Partnerid, artiklid, kulukontod |
| Ladu | Laoliikumised, FIFO soetusmaksumuse kihid, inventuurid | Artiklid, laod |
| Tootmine | Tootmistellimused, komponentide kulu, valmistoodang | Bill of materials, ladu |
| Pank | Imporditud tehingud, maksete vastavusse viimised | Avatud arved, pangakontod |
| Palgaarvestus | Palgaarvestused, maksud, deklaratsioonid | Töötajad, lepingud, maksumäärad |
| Põhivara | Põhivara register, kulumiarvestused | Põhivara grupid, kasulikud eluead |
| Maksustamine | Käibedeklaratsioonid, EL-i müügiaruanded, Intrastat, e-arved | Välja antud ja registreeritud dokumendid |
| Pearaamat | Raamatupidamiskanded, perioodide lukustused | Kõik eelnev |
| Aruandlus | Ei kirjuta midagi | Pearaamat ja analüütilised registrid (subledgers) |
Iga rida, välja arvatud kaks viimast, lõpeb kirjutamisega pearaamatusse. See on disainireegel, mis eristab ERP-d omavahel ühendatud tööriistade kogumist.
Konkreetne andmevoog
Järgnevas näites on kasutatud Nordleti otspunktide (endpoints) liideseid ja Leedu vaikimisi kontoplaani. Iga ERP teeb samad sammud, kuid kontokoodid ja liidese nimed võivad erineda.
1. Tellimus
Veebipood loob tellimuse päringuga POST /v1/ecommerce/orders/create: edastatakse partner, artiklite ja kogustega read ning sihtriik. Pearaamatusse ei postitata veel midagi. Tellimus on kohustus, mitte tehing.
2. Laoseisu reserveerimine
orders/reserve eraldab kogused, et teine tellimus ei saaks samu ühikuid ära müüa. Ikka veel ei teki ühtegi raamatupidamiskannet: reserveeritud kaup kuulub endiselt ettevõttele.
3. Täitmine (fulfilment)
orders/fulfill registreerib kauba laost väljumise. Ühes andmebaasi tehingus juhtub kaks asja:
- Kaup võetakse arvele FIFO soetusmaksumusega: esmalt kasutatakse iga artikli vanimaid soetusmaksumuse kihte, nagu on kirjeldatud FIFO laovarude hindamise sõnastikus.
- Nende ühikute kulu postitatakse raamatupidamiskandena, deebetisse müüdud kaupade soetusmaksumus ja kreeditarvesse ladu.
| Konto | Deebet | Kreedit |
|---|---|---|
| 6000 Müüdud kaupade soetusmaksumus | 600.00 | |
| 2040 Ladu | 600.00 |
Kauba täitmisel luuakse tellimusele ka arve mustand ning määratakse sihtriigi alusel käibemaksurežiim, kasutades EL-i käibemaksumootorit.
4. Arve väljastamine
Arve väljastamine on hetk, mil müügitehingult kajastatakse tulu. Dokument saab lüngata numbri ja luuakse üks tasakaalus kanne: brutosumma nõuetesse, käibemaks väljamineva käibemaksu kontole ja netosumma tuludesse.
1000-eurose netomüügi korral 21% Leedu käibemaksuga:
| Konto | Deebet | Kreedit |
|---|---|---|
| 2410 Nõuded ostjate vastu | 1,210.00 | |
| 5000 Kaupade müügitulu | 1,000.00 | |
| 4492 Makstav käibemaks | 210.00 |
Kui müügireal on kasutusel mõni muu tulude kajastamise meetod kui tehinguhetkel kajastamine, liigub netosumma selle asemel tulevaste perioodide tulu kontole ja tulude kajastamise mootor vabastab selle graafiku alusel. Nõuete ja käibemaksu kajastamine ei muutu.
Arve võib nüüd teele minna PDF-ina, Peppol BIS 3.0 e-arvena või ettevõtte asukohariigi nõutavas e-arve formaadis.
5. Panga vastavusse viimine
Kaks nädalat hiljem laekub 1,210 eurot. Liikumine saabub PSD2 pangavooprogrammi või camt.053 väljavõtte impordi kaudu. Pangamoodul hindab võimalikke arveid summa, makseviite, vastaspoole nime ja IBAN-i alusel ning bank/transactions/match postitab laekumise:
| Konto | Deebet | Kreedit |
|---|---|---|
| 2710 Pank | 1,210.00 | |
| 2410 Nõuded ostjate vastu | 1,210.00 |
Arve staatus muutub tasutuks ja saadetakse välja veebikonks (webhook) sale_invoice.paid. Maksete sobitamise artikkel selgitab sobitamise loogikat täpsemalt. Teises valuutas tehtud makse korral kantakse realiseeritud kursivahe samas sammus kasumi- või kahjumikontole.
6. Käibedeklaratsioon
Kuu lõpus pole vaja andmeid käsitsi ümber tõsta. Käibedeklaratsioon arvutatakse välja väljastatud ja registreeritud dokumentide põhjal: riikliku deklaratsiooni (Leedus FR0600) jaoks declarations/eu/vat-return/compute ja liiduülese skeemi kohase piiriülese B2C-müügi jaoks declarations/eu/oss/compute. Ülaltoodud müük paigutatakse kodumaise deklaratsiooni standardmäära lahtrisse, kuna selle käibemaksurežiim on domestic.
7. Perioodi lukustamine
Kui deklaratsioon on esitatud, suleb ledger/periods/lock kuu. Pärast seda lükatakse kõik kanded, mille kuupäev langeb sellesse perioodi (sealhulgas hiline pangasobitus või uuesti saadetud API päring), tagasi HTTP veaga 409. Lukustamine käivitab ka kõigi perioodi lõpuks aeguvate tulevaste perioodide tulude kajastamise, nii et kuu ei saa sulguda nii, et teenitud tulu on jäänud kohustuste kontole.
Miks pearaamat on tõeallikas (system of record)
Iga ülaltoodud moodul hoiab analüütilist registrit (subledger): ostjate nõuded kliendi lõikes, võlad tarnija lõikes, laoseis artikli lõikes, põhivara esemete lõikes. Pearaamatus asuvad kogusummad, millega need registrid peavad klappima. Analüütiline register vs pearaamatus käsitleb seda suhet; praktiline aspekt seisneb selles, et pearaamatu põhjal koostatud aruanne ja analüütilise registri põhjal koostatud aruanne peavad andma sama numbri ning ERP tagab selle, luues mõlemad samadest raamatupidamiskannetest.
Pearaamatu kui arvestuse aluse usaldusväärsust tagavad kolm omadust:
- Tagatud tasakaal. Nordletis keeldub andmebaas kande vastuvõtmisest, mille deebetid ei võrdu kreeditarvetega. Moodulis esinev viga ei saa tekitada tasakaalust väljas olevat kannet.
- Ajalugu on ainult lisatav (append-only). Postitatud kannet ei muudeta kunagi. Viga parandatakse ümberpööramise (reversal) ja uue kandega, mis mõlemad on algdokumendiga lingitud. Muutumatu pearaamatu artikkel selgitab, miks audiitorid seda nõuavad.
- Perioodid lukustatakse. Lukustatud kuud ei saa muuta, seega on esitatud numbrid samad numbrid, mis jäävad süsteemi alles.
Liidestamine: sündmused ja identsus (idempotency), mitte öised partiid
Vanemad ERP liidestused põhinesid öösiti vahetatavatel failidel: ekspordi tellimused, impordi need, kontrolli hommikul vealogi. Kaasaegsed ERP-d pakuvad API-liidest ja liidestamisest saab kahe põhimõtte järgimine.
Sündmused välja (Events out). Kui midagi muutub, annab ERP sellest teada. Nordlet kirjutab iga veebikonksi sündmuse muutusega samasandmebaasi tehingus väljaminevate teadete sabasse (outbox), nii et tagasi pööratud dokument ei käivita kunagi sündmust ja ühtegi sündmust ei kadunud. Edastused on allkirjastatud HMAC-SHA256 algoritmiga ja korduskatseid tehakse eksponentsiaalse viivitusega. Teie süsteem reageerib sündmusele sale_invoice.paid, selle asemel et iga viie minuti järel küsida, kas midagi on makstud.
Turvalised korduskatsed sisse (Safe retries in). Võrgud tõrjuvad ja korduv päring ei tohi luua teist arvet. Nordlet aktsepteerib igal muutval päringul päist Idempotency-Key: sama võti sama sisuga tagastab salvestatud vastuse, sama võti erineva sisuga lükatakse tagasi ja võtmed aeguvad 24 tunni pärast. Identalsuse ehk idempotentsuse sõnastik ja API konventsioonid kirjeldavad täpset käitumist.
Kuna iga toiming on POST /v1/{module}/{resource}/{action} päring ja rakendus kasutab samu liideseid, saab integratsioon käivitada kogu ülaltoodud voo ilma, et keegi peaks ekraani avama. Artikkel Kuidas integreerida pilveraamatupidamise API SaaS-platvormi juhendab sellise lahenduse ehitamist.
Mida aruandlus loeb
Aruanded ei salvesta arveid. Need on päringud pearaamatu ja analüütiliste registrite vastu teatud ajahetkel:
- Saldoleht, bilanss, kasumiaruanne ja rahavoogude aruanne loevad kandeid kontode ja perioodide kaupa.
- Nõuete vananemine (debt aging) loeb avatud nõudeid ja kohustusi maksetähtpäeva järgi.
- Laosaldo ja liikumine loevad lao analüütilist registrit ja selle FIFO kihte.
- Käibemaksu koond loeb välja antud ja registreeritud dokumentide käibemaksuridu.
- Kulukohtade aruanded loevad iga kanderea kulukoha mõõdet.
Nordletis genereeritakse aruanne taustal XLSX-, PDF- või JSON-vormingus ning faili valmimisel käivitutakse veebikonks (webhook). Kontserni numbrid tulevad konsolideerimisest, mis ühendab mitme ettevõtte pearaamatu omandikaalu ja valuuta konverteerimisega.
Kus see praktikas tõrgub
Enamik ERP probleeme tuleneb ühise kirje põhimõtte eiramisest, mitte tarkvara vigadest. Tavalised juhud:
- Paralleelselt toimiv arvutustabel millegi jaoks, mida ERP "ei oska", mis läheb hiljem raamatupidamisega vastuollu.
- Manuaalsed raamatupidamiskanded, mida kasutatakse mooduli väljundi parandamiseks dokumendi parandamise asemel, mis rikub jälitatavuse aruandest algallikani.
- Integratsioonid, mis kirjutavad saldosid dokumentide asemel, mistõttu pearaamatus on kogusummad, mida keegi ei oska selgitada.
- Avatud perioodid, mis on kuude kaupa lukustamata, mistõttu eelmise kvartali esitatud andmed trihvivad (drift).
Artikkel Miks ERP-dejuurutused ebaõnnestuvad käsitleb seda, kuidas need harjumused juurutamise käigus tekivad, ning Realistlikud ERP juurutamise ajakavad näitab, millises projekti faasis need tavaliselt ilmnevad.
FAQ
Mis on ERP-süsteemi tuum?
Pearaamat ja selle ümber oleev ühine andmemudel. Iga moodul kirjutab dokumente, mis toodavad tasakaalus raamatupidamiskandeid, ja iga aruanne tuletatakse nendest kannetest.
Kuidasandmed läbi ERP liiguvad?
Ärisündmus salvestatakse ühe korraga dokumendina (tellimus, arve, liikumine, palgaarvestus). Dokument tekitab pearaamatusse kanded ja vastavasse analüütilisse registrisse liikumised. Aruanded ja käibedeklaratsioonid arvutatakse nende kirjete põhjal. Moodulite vahel ei kopeerita midagi.
Mis vahe on moodulil ja integratsioonil?
Moodul kirjutab samasse andmebaasi ja samasse pearaamatusse ülejäänud süsteemiga. Integratsioon on väline programm, mis kutsub ERP API-t. API-keskses ERP-s on see vahe väike, kuna integratsioon kasutab samu liideseid, mida moodulidki.
Kas ERP postitab raamatupidamiskanded automaatselt?
Jah. Arve väljastamine, tellimuse täitmine, makse sobitamine, palgaarvestus või põhivara kulumiarvestus loovad igaüks oma raamatupidamiskande ilma, et keegi peaks deebeteid ja kreedeteid käsitsi koostama. Kasutatavad kontod tulevad postitamisreeglitest, mida saab ettevõttekohaselt muuta.
Miks ERP-d lukustavad raamatupidamisperioode?
Selleks, et teatud perioodi kohta esitatud või deklareeritud andmed ei saaks hiljem muutuda. Lukustatud periood lükkab uued kanded tagasi, mis kaitseb auditeeritavust ja sunnib parandused tegema jooksvasse perioodi, kus need on nähtavad.