Як працюють ERP-системи: модулі, рух даних та головна книга
Одна транзакція, простежена крізь усі модулі ERP, із реальними бухгалтерськими проводками, а також пояснення того, чому головна книга є першоджерелом, на якому базується все інше.
ERP-система працює завдяки збереженню кожної бізнес-події один раз в одній базі даних, дозволяючи кожному модулю читати цей спільний запис і записувати дані в нього. Відвантажене замовлення є тим самим записом незалежно від того, хто на нього дивиться: склад, відділ продажу чи бухгалтер. Модулем, який забезпечує узгодженість усієї системи, є головна книга (general ledger): кожна подія, що має грошовий вираз, зрештою перетворюється там на збалансовану проводку, а будь-який звіт формується на основі цих проводок.
У цій статті ми простежимо шлях одного продажу через усі модулі, покажемо створені ним проводки та пояснимо, чому інтеграція з ERP стосується подій і головної книги, а не інтерфейсних екранних форм.
Спільна база даних
До появи ERP кожний відділ використовував власну програму. Товари обліковувалися в складській системі, рахунки виставлялися в білінговій, а бухоблік вівся в обліковому софті. Кінець місяця витрачався на звірку даних між усіма трьома системами. У статті Що таке ERP-програмне забезпечення пояснюється ця категорія систем, а механізмом, який змушує їх працювати, є єдина модель даних, у якій:
- запис контрагента (partner) спільно використовується продажами, закупівлями та головною книгою;
- запис номенклатури (item) містить кількість запасів, шари собівартості за методом FIFO, ціну продажу та рахунок доходів;
- документ (замовлення, рахунок, кредит-нота, закупівля, виробниче замовлення) посилається на контрагентів та номенклатуру й генерує рівно один набір проводок;
- бухгалтерська проводка (journal entry) містить посилання на документ, який її створив, тож кожен показник у звіті можна простежити до першоджерела.
Коли дані є спільними, між модулями немає чого звіряти. Звіряти залишається лише зовнішній світ: банківські виписки та податкові декларації.
Карта модулів
| Модуль | Записує | Читає |
|---|---|---|
| Продажі | Замовлення, рахунки, кредит-ноти | Контрагенти, номенклатура, ціни, правила ПДВ |
| Закупівлі | Замовлення на закупівлю, рахунки постачальників | Контрагенти, номенклатура, рахунки витрат |
| Склад | Рух товарів, шари собівартості FIFO, інвентаризації | Номенклатура, склади |
| Виробництво | Виробничі замовлення, списання компонентів, готову продукцію | Специфікації (BOM), запаси |
| Банк | Імпортовані транзакції, зіставлені платежі | Відкриті рахунки, банківські рахунки |
| Заробітна плата | Нарахування зарплати, внески, звіти | Співробітники, договори, податкові таблиці |
| ОЗ (активи) | Реєстр активів, нарахування амортизації | Групи активів, терміни корисного використання |
| Податки | Декларації з ПДВ, звіти про внутрішньокомунітарні операції, Intrastat, е-рахунки | Випущені та зареєстровані документи |
| Головна книга | Проводки, закриття періодів | Усе зазначене вище |
| Звітність | Нічого | Головна книга та аналітичні рахунки (subledgers) |
Кожен рядок, окрім двох останніх, завершується записом до головної книги. Це концептуальне правило, яке відрізняє ERP від набору з'єднаних між собою інструментів.
Практичний приклад руху даних
У наведеному нижче прикладі використовуються ендпоінти Nordlet та стандартний план рахунків литовського стандарту, що постачається за замовчуванням. Будь-яка ERP виконує такі самі кроки, хоча коди рахунків та назви ендпоінтів можуть відрізнятися.
1. Замовлення
Інтернет-магазин створює замовлення через POST /v1/ecommerce/orders/create: контрагент, позиції з товарами та кількістю, країна доставки. У головній книзі ще нічого не проводяться. Замовлення є зобов'язанням, а не транзакцією.
2. Резервування запасів
Запит orders/reserve резервує кількість на складі, щоб друге замовлення не могло продати ті самі одиниці товару. Проводки в обліку досі відсутні: зарезервовані запаси все ще перебувають у власності компанії.
3. Виконання (відвантаження)
Запит orders/fulfill фіксує вибуття товарів зі складу. В рамках однієї транзакції бази даних відбуваються дві речі:
- Запаси списуються за собівартістю FIFO: спершу використовуються найстаріші шари собівартості для кожної одиниці товару, як це описано у глосарії оцінки запасів методом FIFO.
- Собівартість цих одиниць відображається проводкою: дебет собівартості реалізованої продукції, кредит запасів.
| Рахунок | Дебет | Кредит |
|---|---|---|
| 6000 Собівартість реалізованої продукції | 600.00 | |
| 2040 Запаси | 600.00 |
Відвантаження також створює проєкт рахунка (draft invoice) для замовлення та визначає режим оподаткування ПДВ на основі країни призначення за допомогою механізму розрахунку ПДВ в ЄС.
4. Виставлення рахунка
Виставлення рахунка є моментом визнання доходу для продажу за фактом здійснення (point-in-time). Документ отримує свій унікальний порядковий номер без пропусків, і формується одна збалансована проводка: брутто-сума — на дебиторську заборгованість, ПДВ — на рахунок вихідного ПДВ, а нето-сума — на доходи.
Для чистого продажу на суму 1 000,00 € за ставкою литовського ПДВ 21%:
| Рахунок | Дебет | Кредит |
|---|---|---|
| 2410 Дебіторська заборгованість покупців | 1,210.00 | |
| 5000 Дохід від реалізації товарів | 1,000.00 | |
| 4492 Зобов'язання з вихідного ПДВ | 210.00 |
Якщо для позиції передбачено метод визнання доходу, що відрізняється від визнання в момент часу, чистий дохід спрямовується на рахунок доходів майбутніх періодів (deferred income), а механізм визнання доходу визнає його за графіком. Проводки для дебіторської заборгованості та ПДВ при цьому не змінюються.
Тепер рахунок можна надіслати у форматі PDF, як електронний рахунок Peppol BIS 3.0 або у форматі національного стандарту електронного документообігу, якого вимагає законодавство країни компанії.
5. Звірка з банком
Через два тижні надходить сума 1 210,00 €. Рух коштів надходить через банківську виписку PSD2 або імпорт файлу стандарту camt.053. Банківський модуль оцінює потенційні рахунки за сумою, платіжним призначенням, назвою контрагента та IBAN, а запис bank/transactions/match проводить погашення:
| Рахунок | Дебет | Кредит |
|---|---|---|
| 2710 Рахунки в банках | 1,210.00 | |
| 2410 Дебіторська заборгованість покупців | 1,210.00 |
Статус рахунка змінюється на «оплачено», і надсилається вебхук sale_invoice.paid. У статті глосарія звірка платежів логіку зіставлення описано більш детально. Платіж в іншій валюті на тому ж кроці відображає реалізовану курсову різницю на рахунок прибутків чи збитків.
6. Податкова декларація з ПДВ
Наприкінці місяця нічого не потрібно переносити вручну. Декларація з ПДВ розраховується на основі виставлених та зареєстрованих документів: declarations/eu/vat-return/compute для національної декларації (FR0600 у Литві), declarations/eu/oss/compute для транскордонних продажів споживачам за європейською схемою OSS (One Stop Shop). Згаданий вище продаж потрапляє до стандартної ставки внутрішньої декларації, оскільки його податковою схемою є domestic.
7. Закриття періоду
Після подання декларації запис ledger/periods/lock закриває місяць. З цього моменту будь-яке проведення датоване цим періодом, включно із запізнілою банківською звіркою чи повторним викликом API, відхиляється з кодом помилки HTTP 409. Закриття також ініціює визнання будь-яких відкладених доходів, термін яких настає до кінця періоду, тому місяць не може закритися з не визнаним доходом на рахунку зобов'язань.
Чому головна книга є першоджерелом даних
Кожен із зазначених вище модулів веде аналітичний облік (subledger): дебіторську заборгованість — за клієнтами, кредиторську — за постачальниками, запаси — за номенклатурою, активи — за інвентарними номерами. Головна книга містить підсумкові суми, з якими ці аналітичні рахунки мають збігатися. У статті Аналітичний облік проти головної книги розглядається їхній взаємозв'язок; на практиці це означає, що звіт, побудований на основі головної книги, і звіт, побудований на основі аналітичних рахунків, мусять давати однакові цифри. ERP-система гарантує це, створюючи обидва звіти з одних і тих самих бухгалтерських проводок.
Надійність головної книги як єдиного джерела правди забезпечують три властивості:
- Контроль збалансованості. У Nordlet база даних відхиляє проводку, якщо сума дебетів не дорівнює сумі кредитів. Помилка в коді будь-якого модуля не може створити незбалансований запис.
- Історія доступна лише для додавання (append-only). Опубліковану проводку ніколи не редагують заднім числом. Помилка виправляється сторнуванням (сторніруванням) та новою проводкою, причому обидві посилаються на оригінальний документ. Стаття глосарія незмінна головна книга (immutable ledger) пояснює, чому на цьому наполягають аудитори.
- Закриття періодів. Закритий місяць не можна змінити, тому цифри, які ви подали в звітності, залишаються в системі незмінними.
Інтеграція: події та ідемпотентність замість нічних пакетних обмінів
Старі інтеграції з ERP працювали на основі файлів, якими обмінювалися вночі: експортували замовлення, імпортували їх, а вранці перевіряли журнал помилок. Сучасні ERP надають API, і підхід до інтеграції будується на двох засадах.
Події назовні (Events out). Коли щось змінюється, ERP повідомляє вас про це. Nordlet записує кожну подію вебхука до таблиці вихідних повідомлень (outbox) у межах тієї самої транзакції бази даних, що й сама зміна. Тому документ, який було відкочено, ніколи не згенерує подію, а жодна подія не буде втрачена. Доставки підписуються за допомогою HMAC-SHA256, а в разі збоїв повторюються за експоненційним алгоритмом. Ваша система реагує на подію sale_invoice.paid, замість того щоб кожні п'ять хвилин опитувати систему щодо статусу оплати.
Безпечні повторні запити всередину (Safe retries in). Мережі бувають ненадійними, і повторний запит не повинен призводити до створення другого рахунка. Nordlet приймає заголовок Idempotency-Key для кожного запиту, що змінює дані: той самий ключ із тим самим корисним навантаженням повертає збережену відповідь; той самий ключ із іншим навантаженням відхиляється, а термін дії ключів закінчується через 24 години. Точну поведінку описано в статті глосарія ідемпотентність та в розділі API-конвенції.
Оскільки кожна операція є викликом виду POST /v1/{module}/{resource}/{action}, а застосунок використовує ті самі ендпоінти, інтеграція може виконати весь описаний вище сценарій без необхідності відкривати будь-які екранні форми. У статті Як інтегрувати API хмарного обліку в SaaS-платформу докладно розібрано побудову такого рішення.
Що читає звітність
Звітні форми не зберігають цифри. Вони є запитами до головної книги та аналітичних рахунків станом на певний момент часу:
- Оборотльно-сальдова відомость, баланс, звіт про прибутки й збитки, звіт про рух грошових коштів читають проводки в розрізі рахунків і періодів.
- Аналіз вікової структури заборгованості (debt aging) читає відкриті дебіторські та кредиторські заборгованості за термінами погашення.
- Залишки та рух запасів читають складський аналітичний облік і його шари FIFO.
- Зведена інформація щодо ПДВ читає рядки ПДВ із виставлених і зареєстрованих документів.
- Звіти за центрами витрат (cost centers) читають виміри центрів витрат для кожного рядка проводки.
У Nordlet звіт генерується у фоновому режимі у форматі XLSX, PDF або JSON, а коли файл готовий, надсилається сповіщення у вигляді вебхука. Консолідовані показники формуються завдяки консолідації, яка об'єднує головні книги кількох компаній з урахуванням часток власності та перерахунку валют.
Де це дає збій на практиці
Більшість проблем з ERP є наслідком порушення принципу єдиного запису, а не збоїв програмного забезпечення. Типові випадки:
- Паралельна таблиця в Excel для обліку чогось, чого «не може зробити ERP», після чого цифри там розходяться з офіційними книгами.
- Ручні проводки, що використовуються для виправлення результатів роботи модуля замість виправлення самого первинного документа, що руйнує трасування від звіту до джерела.
- Інтеграції, які записують підсумкові сальдо замість первинних документів, у результаті чого головна книга містить загальні суми, які ніхто не може пояснити.
- Відкриті періоди, які залишаються незакритими місяцями, через що остаточно подані цифри за минулий квартал починають «плисти».
У статті Чому впровадження ERP зазнають невдачі описано, як формуються такі звички під час запуску системи, а матеріал Реалістичні терміни впровадження ERP показує, на яких етапах проєкту вони зазвичай виникають.
FAQ
Що є ядром ERP-системи?
Головна книга та єдина модель даних навколо неї. Кожен модуль створює документи, які формують збалансовані бухгалтерські проводки, а будь-який звіт будується на основі цих проводок.
Як дані рухаються через ERP?
Подія фіксується один раз як документ (замовлення, рахунок, переміщення, нарахування зарплати). Документ створює бухгалтерські проводки в головній книзі та рух за відповідними аналітичними рахунками. Звіти та податкові декларації обчислюються на основі цих записів. Між модулями нічого не копіюється вручну.
У чому різниця між модулем та інтеграцією?
Модуль записує дані в ту саму базу даних і ту саму головну книгу, що й решта системи. Інтеграція є зовнішньою програмою, яка звертається до API ERP-системи. У випадку ERP, що створена за принципом API-first, ця різниця мінімальна, оскільки інтеграція використовує ті самі ендпоінти, що й внутрішні модулі.
Чи створює ERP бухгалтерські проводки автоматично?
Так. Виставлення рахунка, виконання замовлення, звірка платежу, нарахування зарплати або амортизації основних засобів створюють відповідні бухгалтерські проводки без необхідності вручну формувати дебет і кредит. Рахунки беруться з правил проводок, які можна налаштовувати для кожної компанії окремо.
Чому ERP блокують бухгалтерські періоди?
Для того щоб показники, які були звітними або поданими за певний період, не могли бути змінені заднім числом. Закритий період відхиляє нові проводки, що захищає аудиторський слід (audit trail) і змушує проводити коригування в поточному періоді, де вони будуть видимими.