Jak fungují podnikové informační systémy (ERP): moduly, tok dat a podkladová hlavní kniha
Jedna transakce proslulá všemi moduly ERP systému, včetně konkrétních účetních zápisů, a vysvětlení, proč je hlavní kniha záznamem, ze kterého čte vše ostatní.
Podnikový informační systém (ERP) funguje tak, že každou obchodní událost uloží pouze jednou, a to do jediné databáze, přičemž jednotlivým modulům umožňuje z tohoto sdíleného záznamu číst i do něj zapisovat. Vyřízená objednávka představuje naprosto totožný záznam bez ohledu na to, zda se na ni dívá pracovník skladu, obchodní tým nebo účetní. Modulem, který drží celý systém pohromadě a zajišťuje jeho správnost, je hlavní kniha (general ledger): každá událost vyjádřená v peněžním vyjádření v ní skončí jako vyrovnaný účetní zápis a veškeré výkazy se odvíjejí právě od těchto zápisů.
Tento článek sleduje jeden prodejní případ napříč všemi moduly, ukazuje účetní zápisy, které generuje, a vysvětluje, proč integrace s ERP systémem stojí na událostech a hlavní knize spíše než na uživatelských obrazovkách.
Sdílená databáze
Před příchodem systémů ERP provozovalo každé oddělení vlastní program. Zásoby se nacházely ve skladovém systému, faktury v fakturačním programu a účetnictví v samostatném účetním softwaru. Konec měsíce pak pravidelně plynul ve znamení zdlouhavého vzájemného odsouhlasování těchto tří světů. Článek Co je to software ERP představuje tuto kategorii systémů; mechanismem, který zajišťuje jejich fungování v praxi, je jednotný datový model, v němž platí, že:
- záznam obchodního partnera (partner) využívá prodej, nákup i účetní kniha společně,
- záznam položky (item) v sobě nese skladové množství, ocenění metodou FIFO (FIFO cost layers), prodejní cenu a příslušný výnosový účet,
- dokument (objednávka, faktura, dobropis, nákup, výrobní příkaz) odkazuje na partnery i položky a generuje přesně jednu sadu účetních zápisů,
- účetní zápis (journal entry) odkazuje na dokument, který jej vytvořil, takže jakoukoli hodnotu ve výkazu lze zpětně vystopovat až k původnímu zdroji.
Jakmile jsou záznamy sdílené, odpadá nutnost cokoliv zdlouhavě párovat a odsouhlasovat mezi moduly. To, co zbývá k odsouhlasení, představuje okolní svět: bankovní výpisy a daňová přiznání.
Přehled modulů
| Modul | Zapisuje | Čte |
|---|---|---|
| Prodej | Objednávky, faktury, dobropisy | Partnery, položky, ceny, pravidla DPH |
| Nákup | Nákupní objednávky, dodavatelské faktury | Partnery, položky, nákladové účty |
| Sklady | Skladové pohyby, ocenění metodou FIFO, inventury | Položky, sklady |
| Výroba | Výrobní příkazy, spotřebu materiálu, hotové výrobky | Kusovníky, zásoby |
| Banka | Importované transakce, spárované platby | Otevřené faktury, bankovní účty |
| Mzdy | Zpracování mezd, odvody, hlášení | Zaměstnance, smlouvy, daňové tabulky |
| Majetek | Kniha majetku, odpisy | Skupiny majetku, dobu životnosti |
| Daně | Přiznání k DPH, souhrnná hlášení, Intrastat, e-faktury | Vydané a zaevidované doklady |
| Hlavní kniha | Účetní zápisy, uzávěrky období | Vše výše uvedené |
| Výkaznictví | Nic | Hlavní knihu a analytické evidence |
Každý řádek kromě posledních dvou končí zápisem do hlavní knihy. Právě toto pravidlo architektury odlišuje plnohodnotný ERP systém od sady volně propojených nástrojů.
Názorný tok dat
Následující příklad využívá koncové body (endpoints) systému Nordlet a výchozí účtovou osud litevské lokalizace, kterou dodává v základu. Libovolný jiný ERP systém provádí naprosto totožné kroky; lišit se mohou pouze kódy účtů a názvy koncových bodů.
1. Objednávka
E-shop vytvoří objednávku prostřednictvím požadavku POST /v1/ecommerce/orders/create: předá partnera, položky s množstvím na řádcích a zemi určení pro doručení. Do hlavní knihy se v této fázi nezapisuje ještě nic. Objednávka představuje závazek, nikoliv účetní transakci.
2. Rezervace zásob
Volání orders/reserve vyčlení příslušné množství, aby stejné kusy nemohla prodat jiná objednávka. Stále nevzniká žádný účetní zápis: rezervované zásoby jsou stále ve vlastnictví firmy.
3. Vyřízení (fulfilment)
Požadavek orders/fulfill zaeviduje vyskladnění zboží ze skladu. V rámci jedné databázové transakce dojde ke dvěma krokům:
- Zásoby se vyskladní v ocenění FIFO: použijí se nejstarší nákupní ceny pro každou položku, což odpovídá metodě popsané v glosáři ocenění zásob metodou FIFO.
- Náklady na tyto kusy se zaúčtují jako účetní zápis: na vrub nákladů vynaložených na prodané zboží a ve prospěch skladu.
| Účet | Má dáti | Dal |
|---|---|---|
| 6000 Náklady na prodané zboží | 600,00 | |
| 2040 Zásoby | 600,00 |
Vyřízení objednávky rovněž vytvoří koncept faktury (draft invoice) a na základě země určení určí daňový režim DPH s využitím nástroje EU VAT engine.
4. Vystavení faktury
Vystavení faktury představuje okamžik, kdy dochází k uznání výnosu u prodeje realizovaného v jednom časovém bodě. Dokladu je přiděleno číslo v řadě bez mezer a zaúčtuje se jeden vyrovnaný zápis: celková částka jde na pohledávky, DPH na účet výstupu DPH a čistá částka (základ) do výnosů.
Pro prodej v čisté hodnotě 1 000 EUR při 21% litevské DPH:
| Účet | Má dáti | Dal |
|---|---|---|
| 2410 Pohledávky z obchodního styku | 1 210,00 | |
| 5000 Výnosy z prodeje zboží | 1 000,00 | |
| 4492 DPH k úhradě (výstup) | 210,00 |
Pokud řádek faktury vyžaduje jinou metodu uznání výnosu než k okamžiku plnění, základy putují na účet výnosů příštích období (rozlišené výnosy) a modul pro rozpoznávání výnosů je uvolňuje do výnosů podle harmonogramu. Zaúčtování pohledávek a DPH se tímto nemění.
Fakturu lze nyní odeslat ve formátu PDF, jako e-fakturu dle standardu Peppol BIS 3.0 nebo v národním formátu pro elektronickou fakturaci, který vyžadují předpisy v zemi působení společnosti.
5. Párování s bankou
O dva týdny později dorazí platba ve výši 1 210 EUR. Pohyb dorazí prostřednictvím bankovního datového kanálu PSD2 nebo importem výpisu ve formátu camt.053. Bankovní modul ohodnotí kandidátské faktury podle částky, variabilního symbolu, názvu protistrany a čísla účtu IBAN a požadavek bank/transactions/match zaúčtuje úhradu:
| Účet | Má dáti | Dal |
|---|---|---|
| 2710 Bankovní účty | 1 210,00 | |
| 2410 Pohledávky z obchodního styku | 1 210,00 |
Stav faktury se změnil na „zaplaceno“ a systém odešle webhookovou událost sale_invoice.paid. Článek párování plateb popisuje logiku párování podrobněji. Platba v jiné měně v témže kroku zaúčtuje realized kursový rozdíl na účet kurzových zisků nebo ztrát.
6. Přiznání k DPH
Na konci měsíce není nutné nic přepisovat ani ručně přenášet. Přiznání k DPH se vypočte přímo z vydaných a zaevidovaných dokladů: příkaz declarations/eu/vat-return/compute spočítá národní přiznání (v Litvě formulář FR0600) a declarations/eu/oss/compute zpracuje přeshraniční prodeje koncovým zákazníkům v rámci unijního režimu OSS. Výše uvedený prodej se promítne do řádku pro tuzemská zdanitelná plnění se základní sazbou, jelikož jeho daňový režim je nastaven jako domestic (tuzemský).
7. Uzamčení období
Jakmile je přiznání podáno, příkaz ledger/periods/lock uzavře daný měsíc. Od tohoto okamžiku je jakýkoliv účetní zápis s datem spadajícím do tohoto období (včetně pozdního párování plateb nebo opakovaného volání API) odmítnut s chybovým kódem HTTP 409. Uzamčení zároveň spustí rozpoznání výnosů příštích období, které měly být uplatněny k datu konce měsíce, takže se nemůže stát, že by se měsíc uzavřel a výnosy patřící do něj by zůstaly na účtu cizích zdrojů (závazků).
Proč je hlavní kniha systémem záznamů
Každý výše uvedený modul spravuje vlastní analytickou evidenci (subledger): pohledávky po zákaznících, závazky po dodavatelích, zásoby po položkách, majetek po inventárních číslech. Hlavní kniha drží celkové součty, se kterými musí tyto analytické evidence souhlasit. Vztah popisuje článek Analytická evidence vs. hlavní kniha; z praktického hlediska to znamená, že výkaz sestavený z hlavní knihy a výkaz sestavený z analytické evidence musí dávat naprosto totožné číslo. Systém ERP to zaručuje tak, že obojí generuje ze stejných účetních zápisů.
Důvěryhodnost hlavní knihy jako primárního zdroje záznamů zajišťují tři vlastnosti:
- Vynucená rovnováha. V systému Nordlet databáze odmítne jakýkoliv zápis, u kterého se strany Má dáti a Dal nerovnají. Chyba v modulu nedokáže vytvořit nesystémové, jednostranné zaúčtování.
- Historie pouze pro zápis (append-only). Zaúčtovaný doklad se nikdy dodatečně neupravuje. Chyba se opravuje stornem a novým zápisem, přičemž oba doklady jsou vzácně propojené. Článek o neměnné hlavní knize vysvětluje, proč na tomto principu auditoři trvají.
- Uzamykání období. Uzavřený měsíc již nelze měnit, takže čísla, která jste odevzdali úřadům, zůstávají v systému pevně zafixovaná.
Integrace: události a idempotence namísto nočních dávek
Starší integrace ERP systémů spoléhaly na soubory vyměňované v noci: exportovat objednávky, importovat je, ráno zkontrolovat chybový protokol. Moderní ERP systémy poskytují API a integrace se tak stává záležitostí dvou klíčových přístupů.
Události směrem ven. Jakmile se cokoliv změní, ERP systém vás o tom sám informuje. Nordlet zapisuje každou událost webhooku do výstupní fronty (outbox) v rámci stejné databázové transakce, v jaké došlo ke změně. Díky tomu platí, že doklad, který byl vrácen zpět (rollbacked), nikdy nevygeneruje událost a žádná událost se neztratí. Doručované zprávy jsou podepsané pomocí HMAC-SHA256 a v případě selhání se opakovaně odesílají s exponenciálně rostoucím intervalem. Váš systém reaguje na událost sale_invoice.paid namísto toho, aby každých pět minut se ptal, zda už je něco zaplaceno.
Bezpečné opakování požadavků (idempotence) směrem dovnitř. Sítě občas selhávají a opakovaný požadavek nesmí vytvořit druhou, duplicitní fakturu. Nordlet akceptuje hlavičku Idempotency-Key u každého mutujícího volání: stejný klíč se stejným obsahem vrátí již uloženou odpověď, stejný klíč s odlišným obsahem je odmítnut a platnost klíčů vyprší po 24 hodinách. Přesné chování popisuje článek v glosáři idempotence a konvence API rozhraní.
Jelikož každá operace probíhá jako volání POST /v1/{module}/{resource}/{action} a samotná aplikace využívá stejná koncová bodová rozhraní, dokáže integrační skript spustit celý výše popsaný proces, aniž by kdokoliv otevíral uživatelské rozhraní. Postup takového vývoje popisuje článek Jak integrovat cloudové účetní API do platformy SaaS.
Co čte výkaznictví?
Výkazy neukládají žádná čísla předem. Jsou to dynamické dotazy nad hlavní knihou a analytickými evidencemi k určitému časovému okamžiku:
- Obratová předvaha, rozvaha, výkaz zisku a ztráty a přehled o peněžních tocích (cash flow) čtou účetní zápisy seskupené podle účtů a období.
- Stáří pohledávek (debt aging) čte otevřené pohledávky a závazky podle data splatnosti.
- Zůstatky a pohyby zásob čtou skladovou evidenci a její FIFO vrstvy.
- Souhrn DPH čte řádky DPH na vydaných a zaevidovaných dokladech.
- Reporty středisek (cost-center reports) čtou dimenzi nákladového střediska na každém účetním řádku.
V systému Nordlet se výkaz generuje na pozadí ve formátu XLSX, PDF nebo JSON a po dokončení souboru se odešle webhook. Konsolidované údaje pocházejí z konsolidace, která slučuje hlavní knihy několika společností s ohledem na podíly vlastnictví a přepočet cizích měn.
Kde se to v praxi drhne
Většina potíží s ERP systémy pramení z porušování principu sdíleného záznamu, nikoliv z chyb samotného softwaru. Mezi typické scénáře patří:
- Paralelní tabulka v Excelu pro agendu, kterou prý ERP „neumí“,čehož výsledkem je trvalý nesoulad s oficiálním účetnictvím.
- Ruční účetní zápisy používané k opravě výstupů z modulů namísto opravy samotného zdrojového dokladu, což porušuje dohledatelnost od výkazu ke zdroji.
- Integrace zapisující zůstatky namísto jednotlivých dokumentů, takže hlavní kniha obsahuje součty, které nikdo nedokáže vysvětlit.
- Otevřená období ponechaná neuzamčená po celé měsíce, což vede k tomu, že již odevzdaná čísla za minulé čtvrtletí se neustále mění.
Článek Proč selhávají implementace ERP popisuje, jak tyto návyky během zavádění systému vznikají, a realistický harmonogram implementace ERP ukazuje, v jakých fázích projektu se obvykle objevují.
FAQ
Co tvoří jádro ERP systému?
Hlavní kniha a sdílený datový model kolem ní. Každý modul zapisuje dokumenty, které generují vyrovnané účetní zápisy, a veškeré výkazy se odvíjejí právě od těchto zápisů.
Jakým způsobem data protékají systémem ERP?
Událost se zaznamená pouze jednou jako dokument (objednávka, faktura, pohyb, mzdová uzávěrka). Tento dokument generuje účetní zápisy v hlavní knize a pohyby v příslušné analytické evidenci. Výkazy a daňová přiznána se vypočítávají z těchto záznamů. Mezi moduly se nic duplicitně nekopíruje.
Jaký je rozdíl mezi modulem a integrací?
Modul zapisuje do stejné databáze a stejné hlavní knihy jako zbytek systému. Integrace je externí program, který volá API rozhraní ERP systému. U ERP systémů s architekturou API-first je tento rozdíl minimální, protože integrace využívá naprosto stejné koncové body jako samotné moduly.
Účtuje ERP systém automaticky?
Ano. Vystavení faktury, vyřízení objednávky, spárování platby, zpracování mezd nebo výpočet odpisů majetku – to vše generuje příslušné účetní zápisy, aniž by kdokoliv musel ručně skládat strany Má dáti a Dal. Použité účty vycházejí z předkontací (posting rules), které lze nastavit pro každou společnost zvlášť.
Proč ERP systémy uzamykají účetní období?
Protože zajišťují, že čísla vykázaná nebo odevzdaná za určité období se již nemohou zpětně změnit. Uzamčené období odmítá nové zápisy, což chrání auditní stopu a nutí provádět případné korekce v aktuálním období, kde jsou řádně vidět.