How ERP Systems Work: Modules, Data Flow, and the Ledger Underneath
One transaction followed through every module of an ERP, with the actual journal entries, and why the general ledger is the record everything else reads.
System ERP działa dzięki zapisywaniu każdego zdarzenia gospodarczego tylko raz w jednej bazie danych, co pozwala poszczególnym modułom odczytywać ten wspólny zapis i do niego pisać. Zrealizowane zamówienie jest dokładnie tym samym rekordem niezależnie od tego, czy patrzy na nie magazyn, dział sprzedaży, czy księgowy. Modułem, który dba o spójność całego systemu, jest księga główna (general ledger): każde zdarzenie mające wartość pieniężną kończy się tam w postaci zbilansowanego zapisu księgowego, a wszelkie raporty powstają bezpośrednio na bazie tych wpisów.
W niniejszym artykule prześledzimy jedną transakcję przez wszystkie moduły systemu ERP, pokażemy generowane przez nią zapisy księgowe i wyjaśnimy, dlaczego integracja z systemem ERP dotyczy zdarzeń oraz księgi głównej, a nie ekranów użytkownika.
Wspólna baza danych
Przed nadejściem systemów ERP każdy dział korzystał z własnego programu. Stany magazynowe znajdowały się w systemie magazynowym, faktury w systemie fakturowania, a księgi w pakiecie księgowym. Koniec miesiąca upływał na uzgadnianiu danych między tymi trzema światami. Artykuł Czym jest oprogramowanie ERP wyjaśnia tę kategorię systemów; mechanizmem, który zapewnia ich działanie, jest jednolity model danych, w którym:
- rekord kontrahenta (partner) jest używany wspólnie przez sprzedaż, zakupy i księgowość,
- rekord towaru (item) przechowuje stan magazynowy, warstwy kosztowe FIFO, cenę sprzedaży oraz konto przychodowe,
- dokument (zamówienie, faktura, nota korygowa, zakup, zlecenie produkcyjne) odwołuje się do kontrahentów i towarów, generując dokładnie jeden zestaw zapisów księgowych,
- zapis księgowy (journal entry) wskazuje dokument, który go wygenerował, dzięki czemu każdą kwotę w raporcie można prześledzić wstród do źródła.
Gdy dane są współdzielone, nie trzeba niczego uzgadniać między modułami. Do uzgodnienia pozostaje jedynie świat zewnętrzny: wyciągi bankowe oraz deklaracje podatkowe.
Mapa modułów
| Moduł | Zapisuje | Odczytuje |
|---|---|---|
| Sprzedaż | Zamówienia, faktury, noty korygowe | Kontrahentów, towary, ceny, reguły VAT |
| Zakupy | Zamówienia zakupu, faktury od dostawców | Kontrahentów, towary, konta kosztowe |
| Magazyn | Ruchy magazynowe, warstwy kosztowe FIFO, remanenty | Towary, magazyny |
| Produkcja | Zlecenie produkcyjne, rozchód komponentów, produkty gotowe | Normy zużycia (BOM), stany magazynowe |
| Bank | Zaimportowane transakcje, dopasowane płatności | Otwarte faktury, rachunki bankowe |
| Płace | Listy płac, składki, deklaracje | Pracowników, umowy, tabele podatkowe |
| Środki trwałe | Rejestr środków trwałych, amortyzacja | Grupy środków trwałych, okresy użyteczności |
| Podatki | Deklaracje VAT, podsumowania VIES, Intrastat, e-faktury | Dokumenty wystawione i zarejestrowane |
| Księga główna | Zapisy księgowe, zamknięcia okresów | Wszystkie powyższe |
| Raportowanie | Nic | Księgę główną i księgi pomocnicze |
Każdy wiersz z wyjątkiem dwóch ostatnich kończy się zapisem w księdze głównej. To właśnie ta reguła projektowa odróżnia system ERP od zestawu połączonych ze sobą narzędzi.
Przepływ danych w praktyce
Poniższy przykład wykorzystuje endpointy platformy Nordlet oraz domyślne konta z litewskiego planu kont dostarczanego wraz z systemem. Każdy ERP wykonuje te same kroki, choć numery kont i nazwy endpointów mogą się różnić.
1. Zamówienie
Sklep internetowy składa zamówienie za pomocą POST /v1/ecommerce/orders/create: przekazuje kontrahenta, pozycje zawierające towary i ilości oraz kraj dostawy. Na tym etapie w księdze głównej nie pojawiają się żadne wpisy. Zamówienie to zobowiązanie, a nie transakcja.
2. Rezerwacja zapasów
Metoda orders/reserve blokuje odpowiednie ilości, uniemożliwiając sprzedaż tych samych jednostek w ramach innego zamówienia. Wciąż brak wpisów w księdze: zarezerwowany towar nadal stanowi własność firmy.
3. Wydanie z magazynu
Metoda orders/fulfill rejestruje opuszczenie magazynu przez towary. W ramach jednej transakcji bazy danych zachodzą dwa procesy:
- Zapasy są rozchodowane według kosztu FIFO (FIFO cost): w pierwszej kolejności wykorzystywane są najstarsze warstwy kosztowe dla każdego towaru, co opisuje wpis w słowniku wycena zapasów metodą FIFO.
- Koszt tych jednostek trafia do księgi jako zapis: debet konto kosztu własnego sprzedaży, kredyt konto zapasów.
| Konto | Debet | Kredyt |
|---|---|---|
| 6000 Koszt własny sprzedaży | 600,00 | |
| 2040 Zapasy | 600,00 |
Wydanie tworzy również projekt faktury (draft invoice) dla zamówienia oraz ustala prawidłowe traktowanie podatkowe VAT na podstawie kraju dostawy, korzystając z silnika VAT dla UE.
4. Wystawienie faktury
Wystawienie faktury to moment ujęciu przychodu dla transakcji rozliczanej w czasie jej dokonania (point-in-time sale). Dokument otrzymuje swój numer z ciągłej serii, a w księdze pojawia się jeden zbilansowany zapis: kwota brutto na należności, kwota VAT na konto należnego VAT, a kwota netto na przychody.
Dla sprzedaży netto na kwotę 1 000,00 EUR przy litewskiej stawce VAT 21%:
| Konto | Debet | Kredyt |
|---|---|---|
| 2410 Należności od odbiorców | 1 210,00 | |
| 5000 Przychody ze sprzedaży towarów | 1 000,00 | |
| 4492 VAT należny do zapłaty | 210,00 |
Jeśli pozycja posiada metodę rozpoznawania przychodu inną niż bieżąca, kwota netto trafia na rozliczenia międzyokresowe przychodów, a silnik rozpoznawania przychodów uwalnia ją zgodnie z harmonogramem. Zaksięgowanie należności oraz podatku VAT pozostaje bez zmian.
Faktura może teraz zostać wygenerowana jako plik PDF, e-faktura w standardzie Peppol BIS 3.0 lub w krajowym formacie e-faktur wymaganym w jurysdykcji firmy.
5. Dopasowanie wpłaty bankowej
Dwa tygodnie później na rachunek wpływa kwota 1 210,00 EUR. Płatność dociera za pośrednictwem strumienia danych bankowych PSD2 lub importu wyciągu w formacie camt.053. Moduł bankowy ocenia pasujące faktury na podstawie kwoty, tytułu płatności, nazwy kontrahenta oraz numeru IBAN, a endpoint bank/transactions/match księguje rozliczenie:
| Konto | Debet | Kredyt |
|---|---|---|
| 2710 Rachunek bieżący | 1 210,00 | |
| 2410 Należności od odbiorców | 1 210,00 |
Status faktury zmienia się na opłaconą, a system emituje zdarzenie webhook sale_invoice.paid. Szczegóły logiki dopasowywania opisano w sekcji uzgadnianie płatności. Płatność w innej walucie automatycznie księguje powstałe różnice kursowe na odpowiednie konta zysków lub strat w tym samym kroku.
6. Deklaracja VAT
Na koniec miesiąca żadne dane nie są wprowadzane ręcznie. Deklaracja VAT jest wyliczana na podstawie wystawionych i zarejestrowanych dokumentów: declarations/eu/vat-return/compute dla deklaracji krajowej (FR0600 na Litwie) oraz declarations/eu/oss/compute dla unijnej sprzedaży konsumenckiej w procedurze unijnej OSS. Powyższa sprzedaż trafia do pola stawki podstawowej w deklaracji krajowej, ponieważ jej schemat podatkowy to domestic.
7. Zamknięcie okresu
Po złożeniu deklaracji polecenie ledger/periods/lock zamyka miesiąc. Od tego momentu jakikolwiek zapis z datą przypadającą w tym okresie, w tym spóźniona wpłata bankowa lub ponowione wywołanie API, zostanie odrzucony z kodem HTTP 409. Zamknięcie wyzwala również rozpoznanie przychodów odroczonych przypadających na koniec okresu, co zapobiega sytuacji, w której miesiąc zostaje zamknięty z zarobionym przychodem nadal widniejącym na koncie zobowiązań.
Dlaczego księga główna jest źródłem prawdy
Wszystkie wyżej wymienione moduły prowadzą tzw. księgi pomocnicze (subledger): rozrachunki z odbiorcami, rozrachunki z dostawcami, stany magazynowe według towarów czy rejestry środków trwałych. Księga główna gromadzi sumy kontrolne, z którymi te księgi pomocnicze muszą się zgadzać. Relację tę opisuje artykuł Księgi pomocnicze a księga główna; z praktycznego punktu widzenia raport zbudowany na podstawie księgi głównej oraz raport wygenerowany z księgi pomocniczej muszą wskazywać dokładnie tę samą kwotę, a system ERP gwarantuje to poprzez tworzenie obu zestawień na bazie tych samych zapisów księgowych.
Wiarygodność księgi jako systemu ewidencji opiera się na trzech filarach:
- Wymóg bilansowania. W systemie Nordlet baza danych odrzuca każdy zapis, w którym strona debetowa nie równa się stronie kredytowej. Błąd w module nie doprowadzi do powstania niezbilansowanego wpisu.
- Historia tylko do dopisywania (append-only). Raz zatwierdzony zapis nigdy nie jest edytowany. Pomyłkę koryguje się poprzez wpis odwracający oraz nowy zapis, przy czym oba pozostają powiązane z oryginałem. Wyjaśnienie, dlaczego audytorzy bezwzględnie tego wymagają, zawiera artykuł o niezmienialnej księdze rachunkowej.
- Zamknięcie okresów. Zamkniętego miesiąca nie można modyfikować, dzięki czemu figuruące w nim i wysłane do urzędów dane pozostają nienaruszone w systemie.
Integracja: zdarzenia i idempotencja zamiast nocnych wsadowych plików
Starsze integracje ERP opierały się na plikach wymienianych w nocy: eksport zamówień, import, a rano sprawdzanie dziennika błędów. Nowoczesne systemy ERP udostępniają interfejs API, a integracja sprowadza się do przestrzegania dwóch zasad.
Wychodzące zdarzenia (Events out). Gdy coś się zmienia, ERP informuje o tym zewnętrzny system. Nordlet zapisuje każde zdarzenie webhooka do tabeli kolejkowej (outbox) w ramach tej samej transakcji bazy danych, co sam proces biznesowy, dzięki czemu wycofany dokument nigdy nie wyemituje zdarzenia, a żadna informacja nie ulegnie zagubieniu. Dostarczane pakiety są podpisane kluczem HMAC-SHA256, a w razie awarii ponawiane przy użyciu wykładniczego cofania (exponential backoff). Twój system reaguje na zdarzenie sale_invoice.paid zamiast pytać co pięć minut, czy faktura została opłacona.
Bezpieczne ponawianie żądań (Safe retries in). Sieci ulegają awariom, a ponowione żądanie nie może doprowadzić do utworzenia drugiej faktury. Nordlet obsługuje nagłówek Idempotency-Key przy każdym zapytaniu modyfikującym dane: ten sam klucz z tym samym ładunkiem zwraca zapisaną wcześniej odpowiedź, ten sam klucz z innym ładunkiem zostaje odrzucony, a klucze wygasają po 24 godzinach. Dokładne działanie opisują wpis słownikowy idempotencja oraz konwencje API.
Ponieważ każda operacja to wywołanie typu POST /v1/{module}/{resource}/{action}, a aplikacja korzysta z tych samych endpointów, proces integracji pozwala na odtworzenie całego powyższego przepływu bez konieczności otwierania jakiegokolwiek ekranu. Przewodnik Jak zintegrować API księgowości w chmurze z platformą SaaS krok po kroku pokazuje, jak zbudować taką architekturę.
Co odczytują raporty
Raporty nie przechowują gotowych kwot. Są dynamicznymi zapytaniami skierowanymi do księgi głównej i ksiąg pomocniczych na określony moment w czasie:
- Bilans próbny, bilans, rachunek zysków i strat oraz przepływy pieniężne odczytują zapisy księgowe według kont i okresów.
- Wiek należności (aging) odczytuje otwarte rozrachunki z podziałem na terminy płatności.
- Stany i ruchy magazynowe odczytują księgę pomocniczą zapasów oraz jej warstwy FIFO.
- Podsumowanie VAT odczytuje pozycje podatkowe z wystawionych i zarejestrowanych dokumentów.
- Raporty miejsc powstawania kosztów (centrów kosztów) odczytują wymiar centrum kosztów przypisany do każdego wiersza zapisu.
W systemie Nordlet raport generowany jest w tle do formatu XLSX, PDF lub JSON, a po zakończeniu pliku wysyłany jest webhook powiadamiający. Dane skonsolidowane pochodzą z modułu konsolidacji, który łączy księgi kilku spółek z uwzględnieniem udziałów własnościowych oraz przeliczeń walutowych.
Gdzie to zawodzi w praktyce
Większość problemów z systemami ERP wynika z naruszenia zasady wspólnego rekordu, a nie z wad samego oprogramowania. Najczęstsze przypadki to:
- Równoległe arkusze kalkulacyjne prowadzone do zadań, których ERP "nie potrafi zrobić", co nieuchronnie prowadzi do rozbieżności z oficjalnymi księgami.
- Ręczne zapisy księgowe używane do korygowania wyników modułów zamiast poprawiania dokumentu źródłowego, co niszczy powiązanie raportu z oryginałem.
- Integracje przesyłające same salda zamiast konkretnych dokumentów, przez co księga główna zawiera sumy, których nikt nie potrafi wyjaśnić.
- Niezamknięte okresy pozostawione otwarte przez wiele miesięcy, co powoduje dryfowanie danych z rozliczonych już kwartałów.
Artykuł Dlaczego wdrożenia ERP kończą się niepowodzeniem omawia, jak te nawyki rodzą się podczas wdrożenia, a tekst Realistyczne harmonogramy wdrożenia ERP pokazuje, na którym etapie projektów najczęściej się pojawiają.
FAQ
Czym jest rdzeń systemu ERP?
Księga główna oraz otaczający ją jednolity model danych. Każdy moduł zapisuje dokumenty generujące zbilansowane wpisy księgowe, a wszelkie raporty powstają bezpośrednio na bazie tych zapisów.
Jak dane przepływają przez system ERP?
Zdarzenie jest rejestrowane tylko raz jako dokument (zamówienie, faktura, ruch magazynowy, lista płac). Dokument ten generuje zapisy księgowe w księdze głównej oraz ruchy w odpowiedniej księdze pomocniczej. Raporty i deklaracje podatkowe są wyliczane na podstawie tych danych. Żadne informacje nie są kopiowane między modułami.
Jaka jest różnica między modułem a integracją?
Moduł zapisuje dane w tej samej bazie i tej samej księdze co reszta systemu. Integracja to program zewnętrzny wywołujący interfejs API systemu ERP. W przypadku systemu ERP opartego na architekturze API-first różnica ta zaciera się, ponieważ integracja korzysta z dokładnie tych samych endpointów, z których korzystają moduły wbudowane.
Czy system ERP automatycznie księguje dokumenty?
Tak. Wystawienie faktury, wydanie towaru, rozliczenie płatności, naliczenie listy płac czy amortyzacja środków trwałych generują wpisy księgowe bez konieczności ręcznego dekretowania przez człowieka. Konta używane do księgowań wynikają z reguł dekretacji, które można konfigurować dla każdej spółki.
Dlaczego systemy ERP blokują okresy księgowe?
Po to, aby dane wykazane w raportach lub złożone w deklaracjach za dany okres nie mogły ulec późniejszej zmianie. Zamknięty okres odrzuca nowe zapisy, co chroni ścieżkę audytu (audit trail) i wymusza dokonywanie korekt w bieżącym okresie, gdzie są one w pełni widoczne.