Kā darbojas ERP sistēmas: moduļi, datu plūsma un virsgrāmata to pamatā
Viena darījuma ceļš caur visiem ERP moduļiem ar reāliem grāmatojumiem un skaidrojumu, kāpēc virsgrāmata ir vienīgais avots, kurā balstās viss pārējais.
ERP sistēma darbojas, saglabājot katru uzņēmuma notikumu vienu reizi vienā datu bāzē un ļaujot katram modulim lasīt un ierakstīt šo kopīgo ierakstu. Izpildīts pasūtījums ir viens un tas pats ieraksts neatkarīgi no tā, vai uz to skatās noliktava, pārdošanas komanda vai grāmatvedis. Modulis, kas gādā par visas sistēmas precizitāti, ir virsgrāmata (general ledger): katrs notikums, kam ir naudas izteiksme, tur nonāk kā sabalansēts grāmatojums, un katrs pārskats tiek ģenerēts, balstoties uz šiem ierakstiem.
Šajā rakstā mēs izsekosim vienam pārdošanas darījumam cauri visiem moduļiem, parādīsim tā radītos grāmatojumus un paskaidrosim, kāpēc integrācija ar ERP balstās uz notikumiem un virsgrāmatu, nevis ekrāna formām.
Kopīgā datu bāze
Pirms ERP parādīšanās katra nodaļa izmantoja savu programmu. Krājumi tika uzskaitīti noliktavas sistēmā, rēķini izrakstīti norēķinu sistēmā, bet grāmatvedība kārtota grāmatvedības programmā. Mēneša beigās tika patērēts daudz laika, lai šīs trīs sistēmas saskaņotu. Rakstā Kas ir ERP programmatūra ir apskatīta šī sistēmu kategorija, savukārt mehānisms, kas nodrošina tās darbību, ir vienots datu modelis, kurā:
- partnera (partner) ierakstu vienādi izmanto gan pārdošana, gan iepirkumi, gan virsgrāmata,
- preces vai pakalpojuma (item) ieraksts ietver krājumu daudzumu, FIFO izmaksu slāņus, pārdošanas cenu un ieņēmumu kontu,
- dokuments (pasūtījums, rēķins, kredītrēķins, pirkums, ražošanas pasūtījums) atsaucas uz partneriem un precēm, izveidojot tieši vienu grāmatojumu kopumu,
- grāmatojums (journal entry) atsaucas uz dokumentu, kas to izraisījis, tāpēc katru rādītāju pārskatā iespējams izsekot līdz tā pirmsākumam.
Kad dati tiek koplietoti, starp moduļiem vairs nekas nav jāsaskaņo. Tas, kas jāsaskaņo, ir ārējā pasaule: bankas konta izraksti un nodokļu deklarācijas.
Moduļu karte
| Modulis | Raksta | Nolasa |
|---|---|---|
| Pārdošana | Pasūtījumus, rēķinus, kredītrēķinus | Partnerus, preces, cenas, PVN noteikumus |
| Iepirkumi | Pirkuma pasūtījumus, piegādātāju rēķinus | Partnerus, preces, izdevumu kontus |
| Krājumi | Krājumu kustību, FIFO izmaksu slāņus, inventarizācijas datus | Preces, noliktavas |
| Ražošana | Ražošanas pasūtījumus, materiālu patēriņu, saražoto produkciju | Materiālu specifikācijas, krājumus |
| Banka | Importētos darījumus, maksājumu saskaņojumus | Atvērtos rēķinus, bankas kontus |
| Darba algas | Algu aprēķinus, sociālās iemaksas, atskaites | Darbiniekus, līgumus, nodokļu likmes |
| Pamatlīdzekļi | Pamatlīdzekļu reģistru, nolietojuma aprēķinus | Pamatlīdzekļu grupas, lietderīgās lietošanas laikus |
| Nodokļi | PVN deklarācijas, ES preču piegāžu sarakstus, Intrastat, e-rēķinus | Izrakstītos un reģistrētos dokumentus |
| Virsgrāmata | Grāmatojumus, periodu slēgumus | Visu iepriekš minēto |
| Atbilstība un pārskati | Neko | Virsgrāmatu un pakārtotos reģistrus (subledgers) |
Katra rinda, izņemot pēdējās divas, noslēdzas ar ieraksta veikšanu virsgrāmatā. Šis ir dizaina princips, kas atšķir ERP no savstarpēji savienotu rīku kopuma.
Reālas datu plūsmas piemērs
Turpmākajā piemērā ir izmantoti Nordlet API galapunkti un Lietuvas kontu plāna noklusējuma konti, kas ir iebūvēti sistēmā. Jebkura ERP veic tās pašas darbības, lai gan kontu kodu un galapunktu nosaukumi var atšķirties.
1. Pasūtījums
Interneta veikals izveido pasūtījumu, izmantojot POST /v1/ecommerce/orders/create: tiek norādīts partneris, rindas ar precēm un daudzumu, kā arī galamērķa valsts. Virsgrāmatā pagaidām nekas netiek grāmatojums. Pasūtījums ir apņemšanās, nevis darījums.
2. Krājumu rezervēšana
Galapunkts orders/reserve rezervē attiecīgo daudzumu, lai otru pasūtījumu nevarētu izpildīt ar tām pašām vienībām. Grāmatojuma joprojām nav: rezervētie krājumi joprojām pieder uzņēmumam.
3. Izpilde
Galapunkts orders/fulfill reģistrē preču izvešanu no noliktavas. Vienā datu bāzes tranizakcijā notiek divas lietas:
- Krājumi tiek norakstīti pēc FIFO izmaksu metodes: vispirms tiek izmantoti vecākie katras preces izmaksu slāņi, kas atbilst metodei, kura aprakstīta glosārija ierakstā par FIFO krājumu novērtēšanu.
- Šo vienību pašizmaksa tiek grāmatota kā grāmatojums: debetā pārdotās produkcijas pašizmaksa, kredītā krājumi.
| Konts | Debets | Kredīts |
|---|---|---|
| 6000 Pārdotās produkcijas pašizmaksa | 600.00 | |
| 2040 Krājumi | 600.00 |
Izpildes brīdī tiek izveidots arī rēķina melnraksts (draft invoice) un atbilstoši galamērķa valstij tiek noteikts PVN piemērošanas veids, izmantojot ES PVN dzinuli.
4. Rēķina izrakstīšana
Rēķina izrakstīšana ir brīdis, kurā tiek atzīti ieņēmumi vienreizējam darījumam. Dokuments saņem savu secīgo numuru, un tiek izveidots viens sabalansēts grāmatojums: kopsumma debetē debitoru parādus, PVN tiek grāmatots uz izejošā PVN kontu, bet neto summa – uz ieņēmumu kontu.
Pārdodot preci par 1,000 EUR neto ar 21% Lietuvas PVN:
| Konts | Debets | Kredīts |
|---|---|---|
| 2410 Pircēju parādi | 1,210.00 | |
| 5000 Ieņēmumi no preču pārdošanas | 1,000.00 | |
| 4492 Maksājamais PVN | 210.00 |
Ja rēķina rindai ir norādīta cita ieņēmumu atzīšanas metode, nevis uzreiz brīdī, neto summa nonāk nākamo periodu ieņēmumos (deferred income), un ieņēmumu atzīšanas dzinulis tos atzīst grafika noteiktajos termiņos. Debitoru parādu un PVN grāmatojums nemainās.
Tagad rēķinu var nosūtīt PDF formātā, kā Peppol BIS 3.0 e-rēķinu vai uzņēmuma valsts prasībām atbilstošā nacionālā e-rēķinu formātā.
5. Bankas saskaņošana
Pēc divām nedēļām ienāk 1,210 EUR. Maksājums tiek saņemts, izmantojot PSD2 bankas datu plūsmu vai camt.053 konta izraksta importu. Bankas modulis novērtē iespējamos rēķinus pēc summas, maksājuma mērķa, sadarbības partnera nosaukuma un IBAN, un galapunkts bank/transactions/match iegrāmato samaksu:
| Konts | Debets | Kredīts |
|---|---|---|
| 2710 Banka | 1,210.00 | |
| 2410 Pircēju parādi | 1,210.00 |
Rēķina statuss nomainās uz apmaksātu, un tiek izsaukts sale_invoice.paid tīmekļa āķis (webhook). Maksājumu saskaņošanas ieraksts skaidro saskaņošanas loģiku sīkāk. Ja maksājums saņemts citā valūtā, tajā pašā solī tiek iegrāmatojama realizētā valūtas kursa svārstību starpība uz ieņēmumu vai zaudējumu kontu.
6. PVN deklarācija
Mēneša beigās dati nav jāpārvada manuāli. PVN deklarācija tiek aprēķināta, balstoties uz izrakstītajiem un reģistrētajiem dokumentiem: declarations/eu/vat-return/compute nacionālajai deklarācijai (Lietuvā – FR0600), savukārt declarations/eu/oss/compute ES OSS (One Stop Shop) shēmas pārdošanai galapatērētājiem citās ES dalībvalstīs. Iepriekš minētais darījums nonāk vietējās deklarācijas standartlikmes ailē, jo tā PVN režīms ir domestic.
7. Perioda slēgšana
Kad deklarācija ir iesniegta, galapunkts ledger/periods/lock aizver mēnesi. Pēc tam jebkurš grāmatojums ar šī mēneša datumu, tostarp novēlota bankas saskaņošana vai atkārtoti nosūtīts API pieprasījums, tiek noraidīts ar HTTP 409 kļūdas kodu. Perioda slēgšana arī aktivizē nākamo periodu ieņēmumu atzīšanu par attiecīgo mēnesi, nepieļaujot situāciju, ka mēnesis tiek noslēgts ar nopelnītajiem ieņēmumiem saistību kontos.
Kāpēc virsgrāmata ir galvenais patiesības avots
Katrs iepriekš minētais modulis uztur pakārtoto reģistru (subledger): debitoru parādus pa klientiem, kreditoru parādus pa piegādātājiem, krājumus pa precēm, pamatlīdzekļus pa vienībām. Virsgrāmata glabā kopsummas, ar kurām šiem pakārtotajiem reģistriem jāsakrīt. Rakstā Pakārtotais reģistrs pret virsgrāmatu ir apskatīta šo divu jēdzienu saistība; praktiskā nozīme ir tāda, ka pārskatam, kas veidots no virsgrāmatas, un pārskatam, kas veidots no pakārtotā reģistra, ir jāsakrīt, un ERP to garantē, ģenerējot abus no tiem pašiem grāmatojumiem.
Trīs īpašības padara virsgrāmatu par uzticamu datu avotu:
- Tiek nodrošināta bilance. Nordlet datu bāze noraida jebkuru grāmatojumu, kura debeti nesakrīt ar kredītiem. Moduļa kļūda nevar radīt nesabalansētu ierakstu.
- Vēsture ir tikai papildināma (append-only).. Grāmatojums nekad netiek labots tieši. Kļūda tiek labota ar storno grāmatojumu un jaunu pareizu ierakstu, un abi ir savstarpēji saistīti ar sākotnējo dokumentu. Nezūdošas virsgrāmatas (immutable ledger) ieraksts paskaidro, kāpēc revidenti uz to uzstāj.
- Periodi tiek slēgti. Aizvērtu mēnesi nevar mainīt, tāpēc iesniegtie un reģistrētie rādītāji paliek nemainīgi sistēmā.
Integrācija: notikumi un idempotence, nevis nakts pakešu apstrāde
Vecākas ERP integrācijas balstījās uz naktī apmainītiem failiem: eksportēt pasūtījumus, importēt tos, no rīta pārbaudīt kļūdu žurnālu. Mūsdienu ERP nodrošina API, un integrācija kļūst par divu disciplīnu jautājumu.
Notikumi virzienā no ERP uz āru. Kad kaut kas mainās, ERP par tai ziņo. Nordlet ieraksta katru tīmekļa āķa notikumu izziņošanas rindā (outbox) tajā pašā datu bāzes transakcijā, kurā notika izmaiņas, tāpēc atcelsmes gadījumā notikums netiek nosūtīts un neviens notikums nepazūd. Paziņojumi tiek parakstīti ar HMAC-SHA256 un atkārtoti nosūtīti ar eksponenciālu aizturi. Jūsu sistēma reaģē uz sale_invoice.paid, nevis ik pēc piecām minūtēm vaicā, vai rēķins ir apmaksāts.
Droši atkārtoti pieprasījumi virzienā uz ERP. Tīklā var rasties kļūdas, un atkārtots pieprasījums nedrīkst izveidot otro rēķinu. Nordlet katram datu modificēšanas pieprasījumam pieņem Idempotency-Key galveni: identiska atslēga ar tādu pašu datu saturu atgriež saglabāto atbildi, identiska atslēga ar citu datu saturu tiek noraidīta, un atslēgas derīguma termiņš beidzas pēc 24 stundām. Glosārija ieraksts par idempotenci un API vadlīnijas apraksta precīzu šo mehānismu.
Tā kā katra operācija ir POST /v1/{module}/{resource}/{action} izsaukums un lietotne izmanto tos pašus galapunktus, integrācija var izpildīt visu iepriekš aprakstīto plūsmu, nevienam neatverot nevienu lietotnes ekrānu. Raksts Kā integrēt mākoņgrāmatvedības API SaaS platformā soli pa solim apraksta šādas sistēmas izveidi.
Ko nolasa pārskati
Pārskati nesaglabā datus. Tie ir vaicājumi virsgrāmatā un pakārtotajos reģistros konkrētā laika momentā:
- Apgrozījuma pārskats, bilance, peļņas vai zaudējumu aprēķins un naudas plūsmas pārskats nolasa grāmatojumus pēc kontiem un periodiem.
- Debitoru parādu vecumstruktūra nolasa atvērtos pircēju un piegādātāju parādus pēc apmaksas termiņiem.
- Krājumu atlikumi un kustība nolasa krājumu pakārtoto reģistru un tā FIFO slāņus.
- PVN kopsavilkums nolasa izrakstīto un reģistrēto dokumentu PVN rindas.
- Izmaksu centru pārskati nolasa izmaksu centru dimensiju katrā grāmatojuma rindā.
Nordlet platformā pārskats tiek ģenerēts fonā XLSX, PDF vai JSON formātā, un, kad fails ir gatavs, tiek izsaukts tīmekļa āķis. Konsolidētie rādītāji tiek iegūti, izmantojot konsolidāciju, kas apvieno vairāku uzņēmumu virsgrāmatas, ņemot vērā kapitāda daļas un valūtu pārrēķinus.
Kur tas praksē var noiet greizi
Lielākā daļa problēmu ar ERP ir kopīgā datu avota principa neievērošana, nevis pašas programmatūras kļūdas. Biežākie piemēri:
- Paralēli uzturēta izklājlapa (Excel) lietām, ko ERP it kā „neprot”, un rezultātā tās dati nesakrīt ar grāmatvedību.
- Manuāli grāmatojumi, ar kuriem labo moduļu rezultātus, tā vietā, lai labotu sākotnējo dokumentu, kas izposta iespēju izsekot ceļu no pārskata līdz pamatojošajam dokumentam.
- Integrācijas, kas grāmato atlikumus, nevis dokumentus, tāpēc virsgrāmatā nonāk summas, kuras neviens nespēj pamatot.
- Neaizvērti periodi, kuri mēnešiem ilgi paliek atvērti, ļaujot iepriekšējā ceturkšņa iesniegtajiem datiem mainīties.
Rakstā Kāpēc izgāžas ERP ieviešana ir aprakstīts, kā šie ieradumi veidojas ieviešanas laikā, bet rakstā Reālistiski ERP ieviešanas termiņi parādīts, kurā projekta posmā tie visbiežāk parādās.
FAQ
Kas ir ERP sistēmas kodols?
Virsgrāmata un tai apkārt izveidotais kopīgais datu modelis. Katrs modulis ieraksta dokumentus, kas ģenerē sabalansētus grāmatojumus, un katrs pārskats tiek veidots, balstoties uz šiem ierakstiem.
Kā dati plūst caur ERP?
Notikums tiek reģistrēts vienu reizi kā dokuments (pasūtījums, rēķins, kustība, algu aprēķins). Šis dokuments izveido grāmatojumus virsgrāmatā un kustību attiecīgajā pakārtotajā reģistrā. Pārskati un nodokļu deklarācijas tiek aprēķināti no šiem datiem. Starp moduļiem nekas netiek kopēts.
Kāda ir atšķirība starp moduli un integrāciju?
Modulis raksta datiem tajā pašā datu bāzē un tajā pašā virsgrāmatā, kur pārējā sistēma. Integrācija ir ārēja programma, kas izsauc ERP API. Izmantojot ERP, kas balstīta uz API (API-first), šī atšķirība ir neliela, jo integrācija izmanto tieši tos pašus galapunktus, ko moduļi.
Vai ERP grāmatojumus izveido automātiski?
Jā. Rēķina izrakstīšana, pasūtījuma izpilde, maksājuma saskaņošana, algu aprēķins vai nolietojuma rēķināšana – katra no šīm darbībām izveido savu grāmatojumu, bez nepieciešamības cilvēkam manuāli veidot debetus un kredītus. Izmantotie konti tiek ņemti no grāmatošanas likumiem, kurus var pielāgot katram uzņēmumam.
Kāpēc ERP slēdz grāmatvedības periodus?
Lai periodā uzrādītie vai iesniegtie dati vēlāk vairs nevarētu mainīties. Aizvērts periods noraida jaunus grāmatojumus, kas aizsargā revīzijas izsekojamību un spiež labojumus veikt tekošajā periodā, kur tie ir skaidri redzami.