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