Мастер-данные, учёт, документы и финансовый факт
Источник истиныПерейти к содержанию
System of recordERP Execution layerSmartup SKU Точка Заказ Поставка Деньги Симптом Что проверить Вероятная причина Управленческое решение Симптом Что проверить Вероятная причина Управленческое решение Симптом Что проверить Вероятная причина Управленческое решение Симптом Что проверить Вероятная причина Управленческое решение
Практический гид
ERP и слой исполнения дистрибуции: как разделить ответственность
ERP обычно остаётся владельцем учёта и мастер-данных, а слой исполнения дистрибуции управляет визитами, заказами, дистрибьюторами, полкой и операционными решениями. Интеграция связывает процессы, но не требует переносить все функции одной системы в другую.
- ИТ-директору
- Интеграции с существующей ERP и внешними системами
- Green Line Trading: маркированный товар, карточка клиента и база на карте
Архитектура без дублирования
Один факт - один владелец. Остальные системы получают подтверждённое событие
Выберите бизнес-объект. Схема покажет, где возникает исходный факт, куда он передаётся, чем подтверждается и кто разбирает отклонение.
Интеграционный контрактERP → Smartup
Версия каталога
ID · версия · время · статусВизит, заказ, полка, дистрибьютор и операционное действие
Исполнение в полеВладелец факта
ERP или согласованная master-data система
- Исходный факт
- Номенклатура, единицы измерения, действующая цена, налоговые признаки и статус доступности.
- Триггер
- Публикация новой версии справочника или изменение значения.
- Подтверждение
- Smartup подтверждает применение версии и показывает записи, которые не прошли проверку.
- Если не принято
- Не заменять значение вручную в поле: исправить источник или согласованное правило преобразования.
Владелец факта
ERP или согласованная клиентская мастер-система
- Исходный факт
- Контрагент, торговая точка, договор, ценовой тип, лимит и разрешённые условия заказа.
- Триггер
- Создание клиента либо изменение коммерческих или финансовых условий.
- Подтверждение
- Условие связано с тем же внешним идентификатором и доступно нужной полевой роли.
- Если не принято
- Поместить запись в очередь разбора, не создавая второй профиль клиента с похожим названием.
Владелец факта
Smartup до приёма; ERP - после регистрации документа
- Исходный факт
- Маршрут, визит, полевое доказательство, заказ клиента и исходный идентификатор операции.
- Триггер
- Завершение согласованного шага визита или отправка заказа.
- Подтверждение
- ERP возвращает идентификатор принятого документа либо понятный отказ с причиной.
- Если не принято
- Повторить то же сообщение с тем же ключом идемпотентности, не создавая новый заказ.
Владелец факта
ERP или складская учётная система
- Исходный факт
- Подтверждённый документ отгрузки, учётный остаток, резерв и статус исполнения заказа.
- Триггер
- Проведение документа либо изменение статуса поставки.
- Подтверждение
- Статус связан с исходным заказом и становится видимым коммерческой и полевой команде.
- Если не принято
- Проверить связь идентификаторов и последовательность событий до ручной корректировки статуса.
Владелец факта
ERP и финансовый учёт
- Исходный факт
- Зарегистрированная оплата, открытая дебиторская задолженность, срок и доступный кредитный лимит.
- Триггер
- Регистрация платежа, закрытие документа или пересчёт финансового состояния.
- Подтверждение
- Полевое решение использует актуальную метку времени и согласованную версию финансового факта.
- Если не принято
- Остановить рискованное решение по правилу и передать расхождение финансовому владельцу.
Наблюдаемый интеграционный контракт
Передача данных заканчивается не отправкой, а подтверждённым применением
Пять состояний превращают технический обмен в управляемый бизнес-процесс. Световой импульс проходит цикл автоматически; при сниженной анимации схема остаётся статичной и полностью читаемой.
- 01Изменение
Зафиксировать исходный факт
Владелец создаёт версию или событие с устойчивым идентификатором и временем.
- 02Доставка
Передать один раз логически
Повторная техническая отправка использует тот же ключ и не меняет смысл операции.
- 03Проверка
Проверить контракт
Получатель валидирует схему, ссылки, версию и допустимость перехода состояния.
- 04Применение
Изменить бизнес-состояние
Событие применяется к нужному объекту без скрытого ручного сопоставления.
- 05Подтверждение
Вернуть результат
Источник получает идентификатор, статус или структурированную причину отказа.
Исходный факт → устойчивое событие → проверка → применение → подтверждение или очередь разбора
Проблема начинается, когда обе системы объявляются владельцами одного факта. Тогда клиент, цена, остаток или статус документа редактируются в двух местах, а интеграция превращается в постоянную сверку расхождений.
Устойчивая архитектура назначает владельца по типу данных. ERP может вести номенклатуру, финансовый учёт и итоговые документы; слой исполнения - план визита, факт работы в точке, заказ, полевое доказательство и оперативное исключение.
Обмен строится вокруг бизнес-событий: что изменилось, кому это нужно и как следующая система подтверждает приём. Ошибка обмена должна попадать в очередь разбора с ответственным, а не исчезать внутри технического журнала.
Ошибки, понятные бизнесу
Технический сбой должен показывать влияние, владельца и следующее действие
Выберите симптом. Разбор отделяет первопричину от внешнего проявления и не предлагает исправлять данные сразу в двух системах.
Повторная отправка создала второй документ
Один полевой заказ отображается в ERP как две операции.
Сравнить исходный идентификатор, ключ идемпотентности, время повторов и ответ ERP.
Повтор трактуется как новая бизнес-операция либо подтверждение первой отправки потеряно.
Закрыть дубль по согласованному регламенту и исправить правило повторной обработки.
Поле использует неактуальную цену
Заказ сформирован по версии цены, которая уже не действует в ERP.
Проверить владельца цены, дату действия, версию, задержку доставки и результат применения.
Изменение не опубликовано, не прошло проверку или применилось не к тому ценовому типу.
Исправить источник или маршрут версии; не вводить параллельную ручную цену в Smartup.
Остаток расходится между экраном и учётом
Полевой пользователь видит доступность, не совпадающую с учётным фактом.
Сверить тип остатка, склад, резерв, единицу измерения, время среза и порядок документов.
Сравниваются разные определения остатка или события применились не по порядку.
Зафиксировать единый бизнес-смысл показателя и восстановить последовательность обмена.
Сообщение не применилось, но команда этого не видит
Бизнес ждёт статус или документ, а технический журнал не превращён в действие.
Найти последнюю подтверждённую точку, код отказа, затронутый объект и число повторов.
Ошибка записана без бизнес-контекста, ответственного или порога эскалации.
Создать наблюдаемую очередь с влиянием, владельцем, сроком и безопасным повтором.
До первой синхронизации
Четыре проверки архитектуры до запуска сквозного сценария
Готовность подтверждается не количеством API-методов, а тем, что команда одинаково понимает владельцев, события, повторы и разбор ошибок.
- 01
Владелец
Для каждой сущности указан один владелец данных.
Матрица объектов и полей с системой-источником. - 02
Направление
Направление и частота обмена определены по бизнес-потребности.
Карта событий, триггеров, получателей и допустимой задержки. - 03
Без дублей
Повторное сообщение не создаёт дубликат операции.
Ключ идемпотентности и проверенный сценарий безопасного повтора. - 04
Наблюдаемость
Команда видит ошибку, её влияние и ответственного за исправление.
Очередь ошибок, классификация, срок и правило эскалации.
Пять шагов сквозной проверки
- 01
Составьте перечень сущностей и назначьте для каждой единственную систему-владельца.
- 02
Опишите события, которые запускают передачу данных, и минимальный состав сообщения.
- 03
Свяжите внешние и внутренние идентификаторы без ручного сопоставления в каждой операции.
- 04
Добавьте идемпотентность, повторную отправку и наблюдаемый журнал ошибок.
- 05
Проверьте сквозной сценарий от изменения мастер-данных до подтверждённого бизнес-документа.