Как работают ERP-системы: модули, потоки данных и лежащая в основе главная книга
Одна хозяйственная операция, прослеженная через все модули ERP, с реальными бухгалтерскими проводками, а также объяснение того, почему главная книга — это источник истины для всех остальных данных.
ERP-система работает за счет того, что любое бизнес-событие записывается ровно один раз в единую базу данных, после чего каждый модуль может читать эту общую запись и работать с ней. Отгруженный заказ выглядит абсолютно одинаково независимо от того, кто на него смотрит — кладовщик, менеджер по продажам или бухгалтер. Модуль, который поддерживает целостность всей системы — это главная книга (general ledger): любое событие, имеющее денежную оценку, превращается там в сбалансированную бухгалтерскую проводку, а вся отчетность строится на основе этих проводок.
В этой статье мы проследим путь одной продажи по всем модулям, покажем формируемые ею проводки и объясним, почему интеграция с ERP строится вокруг событий и главной книги, а не интерфейсных экранов.
Единая база данных
До появления ERP каждый отдел использовал собственную программу. Данные по запасам хранились в складской системе, счета выставлялись в биллинговой, а учет велся в бухгалтерской программе. Конец месяца уходил на сверку этих трех систем. В статье Что такое программное обеспечение ERP подробно описана эта категория ПО, а механизм ее работы основан на единой модели данных, в которой:
- запись о контрагенте (partner) используется одновременно продажами, закупками и бухгалтерией;
- запись об элементе номенклатуры (item) содержит количество на складе, слои себестоимости по методу ФИФО (FIFO), цену продажи и счет доходов;
- документ (заказ, счет, кредитовое авизо, закупка, производственный заказ) ссылается на контрагентов и номенклатуру и формирует ровно один набор бухгалтерских проводок;
- бухгалтерская проводка ссылается на породивший ее документ, благодаря чему любую цифру в отчете можно проследить до исходного источника.
Когда данные общие, между модулями больше нечего сверять. Единственное, что остается сверять — внешний мир: банковские выписки и налоговые декларации.
Карта модулей
| Модуль | Создает записи (Writes) | Использует данные (Reads) |
|---|---|---|
| Продажи | Заказы, счета, кредитовые авизо | Контрагенты, номенклатура, цены, правила НДС |
| Закупки | Заказы на закупку, счета от поставщиков | Контрагенты, номенклатура, счета затрат |
| Склад | Движения товаров, слои себестоимости FIFO, инвентаризации | Номенклатура, склады |
| Производство | Производственные заказы, списание компонентов, выпуск готовой продукции | Спецификации (BOM), складские остатки |
| Банк | Импортированные транзакции, сопоставление платежей | Открытые счета, банковские счета |
| Расчет зарплаты | Расчетные ведомости, отчисления, отчетность | Сотрудники, договоры, налоговые шкалы |
| Основные средства | Регистр ОС, расчеты амортизации | Группы ОС, сроки полезного использования |
| Налоги | Декларации по НДС, отчеты об intra-EU операциях (EU sales lists), 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) и определяет режим налогообложения НДС на основе страны назначения с помощью модуля расчета НДС в ЕС (EU VAT engine).
4. Выставление счета
Выставление счета — это момент признания выручки для продажи, совершаемой в момент времени (point-in-time sale). Документ получает свой уникальный сквозной номер, после чего формируется сбалансированная проводка: полная сумма — на дебет дебиторской задолженности, НДС — на кредит счета исходящего НДС, а чистая выручка — на кредит счета доходов.
Для облагаемой продажи на сумму 1 000,00 € при литовском НДС по ставке 21%:
| Счет | Дебет | Кредит |
|---|---|---|
| 2410 Дебиторская задолженность покупателей | 1 210.00 | |
| 5000 Выручка от реализации товаров | 1 000.00 | |
| 4492 Исходящий НДС к уплате | 210.00 |
Если для позиции применяется метод признания выручки, отличный от момента совершения операции, чистая сумма отправляется на счет доходов будущих периодов, а модуль признания выручки (revenue recognition engine) списывает ее по графику. Проводки по дебиторской задолженности и НДС при этом не меняются.
Теперь счет может быть отправлен в формате PDF, в виде электронного счета Peppol BIS 3.0 или в национальном формате электронного выставления счетов, требуемом в стране компании.
5. Банковская сверка
Две недели спустя поступает оплата на сумму 1 210,00 €. Платеж поступает через банковский поток PSD2 (bank feed) или при импорте выписки в стандарте camt.053. Банковский модуль оценивает потенциальные счета-кандидаты по сумме, платежному назначению, имени контрагента и IBAN, после чего вызов bank/transactions/match отражает погашение задолженности:
| Счет | Дебет | Кредит |
|---|---|---|
| 2710 Расчетный счет в банке | 1 210.00 | |
| 2410 Дебиторская задолженность покупателей | 1 210.00 |
Статус счета меняется на «оплачен», и генерируется вебхук sale_invoice.paid. В статье Сверка платежей (payment reconciliation) логика сопоставления описана более подробно. Если платеж поступил в другой валюте, в том же шаге на счет доходов или расходов записывается реализованная курсовая разница.
6. Налоговая декларация по НДС
В конце месяца ничего не нужно переносить вручную. Декларация по НДС рассчитывается на основе выставленных и зарегистрированных документов: declarations/eu/vat-return/compute для национальной декларации (FR0600 в Литве), declarations/eu/oss/compute для трансграничных продаж потребителям в рамках схемы OSS (One Stop Shop). Рассмотренная выше продажа попадает в стандартную налоговую строку внутренней декларации, так как ее режим НДС — domestic.
7. Закрытие периода
После подачи декларации вызов ledger/periods/lock закрывает месяц. С этого момента любые проводки с датой внутри этого периода, включая запоздалую банковскую сверку или повторный вызов API, отклоняются с кодом HTTP 409. Закрытие также запускает признание любых отложенных доходов, приходящихся на конец периода, поэтому месяц не может закрыться с нераспределенной выручкой, зависшей на пассивном счете.
Почему главная книга — это источник истины
Каждый из рассмотренных модулей ведет свой аналитический регистр (subledger): дебиторскую задолженность — в разрезе клиентов, кредиторскую — в разрезе поставщиков, склад — в разрезе номенклатуры, основные средства — в разрезе инвентарных объектов. Главная книга (general ledger) содержит итоговые суммы, с которыми должны сходиться эти аналитические регистры. В статье Аналитический регистр против главной книги (subledger vs general ledger) рассматривается их взаимосвязь; на практике это означает, что отчет, построенный по главной книге, и отчет, построенный по аналитическому регистру, должны давать абсолютно одинаковые цифры. ERP-система гарантирует это за счет формирования обоих отчетов из одних и тех же бухгалтерских проводок (journal entries).
Надежность главной книги как учетного регистра обеспечивают три свойства:
- Контроль баланса. В Nordlet база данных отклоняет проводку, если дебет не равен кредиту. Сбой в каком-либо модуле не может создать перекошенную запись.
- Неизменность истории (append-only). Проведенная запись никогда не редактируется. Ошибка исправляется сторнированием (reversal) и созданием новой проводки, причем обе они связаны с исходной. В статье Неизменяемая главная книга (immutable ledger) объясняется, почему на этом настаивают аудиторы.
- Закрытие периодов. Закрытый месяц изменить нельзя, поэтому цифры, которые вы сдали в налоговую, навсегда остаются в системе в неизменном виде.
Интеграция: события и идемпотентность вместо ночных пакетных выгрузок
Интеграции со старыми ERP строились на файлах, которыми обменивались по ночам: выгрузить заказы, импортировать их, утром изучить файл ошибок. Современные ERP предоставляют API, и интеграция сводится к двум принципиальным подходам.
Исходящие события (Events out). Когда что-то меняется, ERP сообщает вам об этом. Nordlet записывает каждое событие вебхука во внутреннюю очередь (outbox) в рамках той же транзакции базы данных, что и само изменение, поэтому отмененный документ никогда не сгенерирует событие, а ни одно реальное событие не потеряется. Доставки подписываются с помощью HMAC-SHA256 и повторяются при сбоях с экспоненциальной задержкой. Ваша система реагирует на событие sale_invoice.paid, а не опрашивает ERP каждые пять минут в поисках оплаты.
Безопасные повторные запросы (Safe retries in). Сети несовершенны, и повторный запрос не должен приводить к созданию второго счета. Nordlet принимает заголовок Idempotency-Key для каждого мутирующего вызова: тот же ключ с тем же телом запроса возвращает сохраненный ранее ответ, тот же ключ с другим телом запроса отклоняется, а ключи истекают через 24 часа. Точное поведение описано в статье глоссария Идемпотентность (idempotency) и в руководстве Соглашения API (API conventions).
Поскольку любая операция представляет собой вызов вида POST /v1/{module}/{resource}/{action}, а само приложение использует те же эндпоинты, интеграция может воспроизвести весь описанный выше сценарий без единого открытия пользовательского экрана. В статье Как интегрировать API облачной бухгалтерии в SaaS-платформу этот процесс разобран по шагам.
Что читает отчетность
Отчеты не хранят в себе цифры. Они представляют собой запросы к главной книге и аналитическим регистрам по состоянию на определенный момент времени:
- Оборотно-сальдовая ведомость, баланс, отчета о прибылях и убытках, отчет о движении денежных средств читают бухгалтерские проводки в разрезе счетов и периодов.
- Анализ дебиторской задолженности по срокам погашения (Debt aging) читает открытую дебиторскую и кредиторскую задолженность по срокам оплаты.
- Остатки и движение товаров читают складской регистр и его слои FIFO.
- Сводка по НДС читает строки НДС из выставленных и зарегистрированных документов.
- Отчеты по центрам затрат читают аналитику центров затрат по каждой строке проводки.
В Nordlet отчет формируется в фоновом режиме в формате XLSX, PDF или JSON, а когда файл готов, отправляется вебхук. Сводные показатели группы компаний рассчитываются с помощью консолидации (consolidation), которая объединяет главные книги нескольких компаний с учетом долей владения и пересчета валют.
Где это ломается на практике
Большинство проблем с ERP возникают из-за нарушения принципа единой базы данных, а не из-за ошибок в коде. Типичные сценарии:
- Параллельные таблицы Excel для задач, которые ERP «не умеет делать», из-за чего данные перестают сходиться с бухгалтерией.
- Ручные проводки для исправления результатов работы модулей вместо исправления самого документа, что разрушает цепочку прослеживаемости от отчета к источнику.
- Интеграции, записывающие сальдо вместо документов, из-за чего в главной книге висят итоговые суммы, которые никто не может объяснить.
- Открытые периоды, которые месяцами не закрываются, из-за чего отчетность за прошлый квартал начинает «плыть».
В статье Почему внедрения ERP терпят неудачу рассказывается, как возникают такие привычки в ходе развертывания, а в материале Реалистичные сроки внедрения ERP показано, на каких этапах проекта они обычно проявляются.
FAQ
Что является ядром ERP-системы?
Главная книга и окружающая ее единая модель данных. Каждый модуль создает документы, которые формируют сбалансированные бухгалтерские проводки, а вся отчетность строится на основе этих проводок.
Как данные перемещаются внутри ERP?
Событие регистрируется единожды в виде документа (заказ, счет, складское перемещение, расчет зарплаты). Документ порождает бухгалтерские проводки в главной книге и движения в соответствующем аналитическом регистре. Отчеты и налоговые декларации вычисляются на основе этих записей. Никакое дублирование данных между модулями не производится.
В чем разница между модулем и интеграцией?
Модуль осуществляет запись в ту же базу данных и ту же главную книгу, что и вся остальная система. Интеграция — это внешняя программа, которая обращается к API ERP. В ERP с архитектурой API-first эта разница стирается, поскольку интеграция использует те же эндпоинты, что и внутренние модули.
Создает ли ERP бухгалтерские проводки автоматически?
Да. Выставление счета, отгрузка заказа, сопоставление платежа, расчет зарплаты или начисление амортизации основных средств — каждое из этих действий автоматически формирует бухгалтерскую проводку без необходимости вручную собирать дебет с кредитом. Используемые счета определяются правилами разноски (posting rules), которые можно настраивать для каждой компании.
Зачем ERP-системы блокируют учетные периоды?
Чтобы показатели, по которым сдана отчетность или поданы декларации за период, не могли быть изменены задним числом. Закрытый период отклоняет новые проводки, что защищает аудиторский след и заставляет проводить все исправления в текущем периоде, где они остаются на виду.