Как на самом деле интегрируются модули ERP

За словом «интегрированная» скрываются три разные вещи

Почти в каждой брошюре об ERP встречается слово «интегрированная». За ним стоят как минимум три схемы, которые ведут себя совершенно по-разному, когда в конце месяца что-то идёт не так. Первая — файловый или плановый пакетный обмен: одна система выгружает данные, другая загружает, обычно ночью. Вторая — синхронизация через API или промежуточное ПО, при которой две отдельные базы данных поддерживаются в согласованном состоянии за счёт обмена сообщениями. Третья — по-настоящему общие данные, когда модули вовсе не являются отдельными системами, а представляют собой разные представления над одним набором таблиц, одной главной книгой и одним набором основных записей.

Ни одна из них не является универсально правильной. Пакетный обмен дёшев, прост для понимания и переживает сбой любой из сторон, потому что файл просто ждёт. Но он по определению всегда устаревший, а сбойное задание может оставаться незамеченным, пока кто-то не усомнится в отчёте. Синхронизация через API даёт поведение, близкое к режиму реального времени, и позволяет сохранить системы, которые у Вас есть веские причины сохранять, но теперь Вы владеете распределённой системой: повторные попытки, порядок сообщений, частичные сбои и две копии истины, которые могут расходиться. Общие данные устраняют целый класс проблем, когда две базы данных расходятся, потому что база одна, но это значит, что модули должны договориться об одном плане счетов, одном определении номенклатуры и одном цикле выпуска версий, — и это ограничение, а не бесплатное преимущество.

Практический вопрос не в том, какой уровень лучший, а в том, какого уровня заслуживает каждый поток. Ночная передача банковской выписки — нормально. Ночная передача складских остатков для работающего кассового терминала — нет. Skyline Nexus находится на третьем уровне для собственных модулей: бухгалтерия, кассовые продажи и склад, CRM, техобслуживание, кадры, автопарк и активы записывают данные в одну главную книгу и один набор справочников, а с внешними системами интегрируются через API там, где у клиента уже есть система, которую стоит сохранить.

Расхождение начинается с основных данных

В сбоях интеграции обычно винят интерфейсы, но первая трещина, как правило, — это основная запись, существующая дважды с немного разным содержимым. Как только у каждой из двух систем появляется свой список клиентов, списки расходятся в течение нескольких недель, и каждая последующая цифра наследует это расхождение.

• Клиент: одна идентичность для продаж, выставления счетов, поступлений и кредитного контроля, иначе анализ дебиторской задолженности по срокам не сойдётся с отчётом о продажах.
• Поставщик: общий для закупок, кредиторской задолженности и платежей, включая банковские реквизиты, которые при дублировании становятся целью мошенников.
• Номенклатура: один код, одна единица измерения, один метод оценки себестоимости. Два справочника номенклатуры — две оценки запасов.
• План счетов: единая структура. Если модуль ведёт собственный список счетов и сопоставляет его с Вашим, это сопоставление — ещё одна вещь, которую нужно поддерживать и в которой можно ошибиться.
• Налоговые коды: одно определение ставки, режима и дат действия, используемое и в операции, и в декларации.
• Филиал и местонахождение: общие, потому что и запасы, и учёт ведутся в этом разрезе.
• Сотрудник: одна запись для расчёта зарплаты, учёта рабочего времени, нарядов на техобслуживание и закрепления транспортных средств.
• Актив: один реестр для амортизации, истории обслуживания и выбытия.

Вспомогательные книги и контрольный счёт

Главная книга хранит сводные остатки. Детализация находится во вспомогательных книгах, и каждая вспомогательная книга привязана к контрольному счёту в главной книге. Дебиторская задолженность содержит строку по каждому счёту клиенту и каждому поступлению, и их сумма равна контрольному счёту дебиторской задолженности. Кредиторская задолженность делает то же самое для счетов поставщиков. Движения запасов проводятся на контрольный счёт запасов, а себестоимость проданных товаров признаётся при их выбытии. Расчёт зарплаты проводит начисленную зарплату, взносы работодателя, удержания и чистые обязательства. Основные средства проводят поступления, амортизацию и выбытие по первоначальной стоимости и накопленной амортизации. Кассовые продажи проводят выручку, собранный налог, виды оплаты и — при непрерывном учёте запасов — себестоимость каждой продажи.

Правило, которое делает это надёжным, простое: вспомогательная книга всегда должна сходиться со своим контрольным счётом — до последней денежной единицы. Если анализ дебиторской задолженности по срокам показывает одну цифру, а контрольный счёт — другую, одна из них неверна, и без расследования не узнать какая. Поэтому прямые проводки на контрольные счета обычно запрещены. Ручная проводка на дебиторскую задолженность создаёт остаток, который не должен ни один клиент, и он не появится ни в одном акте сверки, который Вы отправите.

Сверка должна быть отчётом, который можно запустить в любой момент, а не электронной таблицей, которую кто-то ведёт. Когда модули разделяют одну главную книгу, сверка почти тавтологична. Когда нет, это самая важная проверка, которую можно автоматизировать.

Правила проведения и журнал аудита

Каждая строка главной книги должна прослеживаться до первичного документа: номера счёта, поступления товаров, расчёта зарплаты, графика амортизации, кассовой операции. Если строка существует без источника, кто-то обошёл процесс. Идентификатор документа должен идти вместе со строкой главной книги, а не храниться в отдельной таблице сопоставления.

Проведённые записи не должны незаметно редактироваться. Исправления оформляются сторнирующими записями или кредит-нотами, при которых видны и исходная запись, и исправление — со своими датами и своими пользователями. Закрытие периода должно блокировать период, а не полагаться на то, что люди не забудут не проводить задним числом. Проверка проста: можно ли взять любой остаток, открыть его и дойти до породивших его документов, не выходя из системы.

Где на самом деле ломаются интеграции

Типы сбоев хорошо известны и почти всегда одни и те же.

• Время и отсечение периода: продажа, проведённая незадолго до полуночи в последний день периода, попадает в другую систему уже после отсечения, и два периода никогда не совпадут.
• Сбойные задания, за которыми никто не следит: плановая передача перестаёт работать, и отсутствие данных выглядит как спокойная неделя.
• Частичная запись: заголовок счёта создан, строки не записались, и одна сторона теперь хранит документ, который другая не распознаёт.
• Дублирующиеся ключи: повторно отправленное сообщение создаёт вторую копию того же счёта, или схема нумерации конфликтует между филиалами.
• Расхождения в валюте и округлении: две системы округляют на разных этапах или используют разные курсы за один и тот же день, и мелкие разницы накапливаются.
• Налог, рассчитанный дважды: и учётная система операций, и бухгалтерская система рассчитывают налог, применяя немного разные правила к скидкам, ценам с налогом или округлению по строке и по документу. В результате счёт, выданный клиенту, и цифра в декларации расходятся.

Идемпотентность и доказательство согласованности сторон

Всё, что может быть отправлено повторно, будет отправлено повторно, поэтому каждой операции проведения нужен устойчивый ключ, получаемый из первичного документа. Двукратная отправка одного и того же счёта должна давать одну проводку, а не две. Принимающая сторона должна фиксировать, какие ключи она уже обработала, и возвращать прежний результат, а не создавать новый. Без этого обычное поведение сети превращается в задвоенную выручку.

Наряду с этим нужна сверка как полноценная функция: количество и суммы за период по каждому типу документов, сравниваемые на обеих сторонах, с перечнем расхождений, а не их итогом. Зелёная галочка, сообщающая лишь, что последнее задание выполнено успешно, не доказывает согласованности. Полезен тот отчёт, который называет семь документов, существующих на одной стороне и отсутствующих на другой.

Филиалы и валюты

Работа с несколькими филиалами означает, что каждая операция несёт своё местонахождение как аналитический разрез с момента создания, а не получает его позже через логику отчёта. Запасы, выручка, затраты и персонал — всё относится к филиалу, и при перемещениях между филиалами должны быть проведены обе стороны, иначе складские остатки двух филиалов не сложатся в показатель компании. Нумерация документов должна быть уникальной по всем филиалам и при этом осмысленной внутри одного.

Мультивалютный учёт требует хранить в строке валюту операции, применённый курс и сумму в базовой валюте. Хранение только пересчитанной суммы уничтожает доказательства. Тогда у переоценки открытых остатков и реализованных курсовых разниц при расчётах есть куда проводиться, и курсовая разница перестаёт быть загадкой округления.

Региональное примечание: клиринговая модель меняет сроки

Там, где действует режим электронных счетов-фактур, сроки интеграции перестают быть вопросом проектного предпочтения. Ряд налоговых органов теперь требует, чтобы счета проходили подтверждение (клиринг) или передавались в налоговый орган до того, как они попадут к покупателю, или одновременно с этим. Режим ZATCA в Саудовской Аравии — действующий пример: счета формируются с заданной структурой, криптографическими элементами и идентификаторами, и налоговый орган участвует в жизненном цикле документа, а не получает сводку постфактум. Это превращает создание счёта в задачу интеграции в реальном времени. Ночной пакет не может выдать документ, которого клиент ждёт у кассы.

В других странах картина иная, и здесь стоит быть точным. В США нет федерального требования об электронных счетах-фактурах, а налог с продаж администрируется на уровне штатов, причём правила и ставки различаются по штатам и нередко по местным юрисдикциям. Канада применяет GST и HST на федеральном уровне с провинциальными различиями, включая провинциальные налоги с продаж в некоторых провинциях. Другие рынки MENA находятся на разных стадиях. Урок для проектирования: держать определение налога и выпуск документа в одном месте, чтобы при переходе рынка от передачи сведений к клиринговой модели менялась конфигурация, а не архитектура. Skyline Nexus обрабатывает клиринг ZATCA в той же операции, которая формирует запись в главной книге, поэтому счёт, который получает клиент, и цифра в декларации происходят из одного расчёта.