Задача и границы решения

Двусторонний обмен опасен, когда обе системы считают себя главными для одного поля. Изменение статуса возвращается обратно и запускает повторную обработку.

Как подойти к задаче

Для каждого поля назначьте владельца: оплата, отгрузка, состав, отмена. Опишите разрешённые переходы и отличайте изменение от повторной доставки того же события. Внешний номер заказа должен сохраняться стабильно.

Что проверить на практике

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

Какой ошибки избежать

Ошибка — сопоставить статусы только по названиям. В разных системах одинаковое слово может означать разный этап. Согласование выполняется с теми, кто обрабатывает заказы, и проверяется на реальной последовательности действий.

Если к обмену позже подключается ИИ-помощник, права на изменение заказа требуют отдельной границы. В AI2Business разобрана архитектура подключения LLM к 1С через контролируемые инструменты. Агентный слой не должен обходить уже согласованные правила статусов и владельцев данных.

Пример для проверки на вашем проекте

Сайт отправил заказ, а 1С присвоила ему внутренний номер. Повтор исходного сообщения не должен создавать новый документ. Затем из учёта приходит подтверждение оплаты. Если позже доставлено старое событие «ожидает оплаты», статус не должен откатиться автоматически. Для этого нужны связь идентификаторов, порядок обработки и согласованные правила устаревших событий, а не только таблица названий статусов.

Сначала договорённость о данных

Для обмена фиксируем системы-источники, идентификаторы сущностей и владельца каждого поля. Нужны конфигурация 1С, версия сайта, расписание и обезличенные примеры расхождений. Согласуем, какие ручные изменения допустимы и что происходит при временной недоступности одной стороны. Без этого технически успешная передача может давать неверный бизнес-результат.

Проверка устойчивости обмена

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

Документация и полезные ссылки