Статусы заказа ATI.SU расходятся с 1С или TMS
Содержание 9 разделов
В 1С или TMS заказ может считаться завершённым, пока в ATI.SU он остаётся активным. Бывает и обратная ситуация: в ATI.SU перевозка получила новое состояние, а внутренний диспетчер его не видит. Это не всегда ошибка площадки. У заказа есть несколько связанных сущностей и несколько участников, а одно слово «статус» в интеграции часто скрывает разные процессы.
Надёжная синхронизация начинается не с написания ещё одного фонового задания, а с разборки модели. Нужно определить, какое событие изменяет груз, какое — заказ, а какое описывает ход перевозки. Затем каждому состоянию назначают место в 1С или TMS, владельца изменения и правило конфликта. Простая таблица «один статус ATI.SU — один статус 1С» редко покрывает весь жизненный цикл.
Груз, заказ и перевозка — разные части процесса
По документации ATI.SU, при создании заказа связанный груз переносится в архив, а для дальнейшей работы создаётся копия. Это важно для идентификаторов: исходная публикация, её копия и заказ нельзя считать одной записью только потому, что они описывают одну перевозку. Если интеграция продолжает обновлять старый груз, диспетчер может видеть изменения не там, где ожидает.
Сам заказ содержит сведения о транспортном средстве, водителе и реквизитах участников, а также состояние заказа и состояние перевозки. Эти два статуса имеют разный смысл. Статус заказа описывает договорный процесс между сторонами. Статус перевозки нужен для фактического хода доставки. Внутренняя система тоже может иметь отдельные состояния заявки, рейса, документа и оплаты. Сводить их в одно поле означает потерять часть информации.
Почему стороны могут завершить заказ в разное время
ATI.SU позволяет грузовладельцу и перевозчику независимо завершить заказ. Поэтому состояние у сторон способно различаться. Например, перевозчик отметил свою часть выполненной, а грузовладелец ещё проверяет документы. Интеграция, которая принимает первое завершение за окончательное закрытие всего процесса, раньше времени блокирует изменения в учётной системе.
В таблице соответствий полезно хранить не только итоговый ярлык, но и контекст: чья сторона изменила состояние, подтверждено ли завершение второй стороной, каков статус перевозки и требуется ли действие сотрудника. В интерфейсе 1С или TMS это можно показать отдельными полями или вычисляемым пояснением. Тогда диспетчер понимает, почему заказ не перешёл на следующий этап автоматически.
Как составить таблицу соответствий
Сначала выгружают реальные состояния по тестовым и завершённым заказам, сверяют их с официальной документацией и описывают бизнес-значение. Названия внутренних статусов могут совпадать с ATI.SU, но иметь другой смысл, поэтому сравнивают не текст, а условия входа и выхода.
| Слой | Что фиксируем | Что нельзя терять |
|---|---|---|
| Публикация груза | Связь исходной записи и созданной копии | Какой объект можно обновлять после появления заказа |
| Заказ | Идентификатор сделки и состояние сторон | Кто инициировал переход и подтверждён ли он |
| Перевозка | Фактический этап доставки | Время получения и источник состояния |
| 1С или TMS | Заявка, рейс, документы, расчёты | Внутренний процесс не должен исчезать из-за одного внешнего статуса |
Для каждого перехода задают направление: только из ATI.SU, только из внутренней системы или двустороннее. Затем определяют приоритет. Например, фактический статус перевозки может поступать из ATI.SU, а закрытие финансового документа выполняться только в 1С. Если обе системы могут менять одно состояние, нужны версия, время события и понятное правило разрешения конфликта.
Вебхуки ускоряют обмен, но не заменяют сверку
ATI.SU предоставляет темы вебхуков по заказам. Событие позволяет быстрее узнать об изменении, чем частый опрос. Получатель должен проверить подлинность уведомления по официальной схеме подписи и разобрать только заявленные подписанные заголовки. Документация отдельно предупреждает, что текущий идентификатор ключа может совпадать с идентификатором вебхука, однако строить на этом проверку владельца нельзя.
После проверки событие записывают в очередь и быстро подтверждают получение. Бизнес-обработку выполняют отдельно: медленный ответ увеличивает вероятность повторной доставки и нагрузки. Повторное событие не должно заново переводить заказ, создавать документ или отправлять уведомление сотруднику. Для этого сохраняют безопасный отпечаток события либо сравнивают уже применённое состояние и версию локального объекта.
Одних вебхуков недостаточно. Сетевой сбой, остановка получателя или ошибка обработчика могут оставить разрыв. Периодическая сверка запрашивает актуальные состояния набора заказов и сравнивает их с локальной таблицей. В официальном сценарии ATI.SU для получения состояний заказов показан метод /v1.2/orders/get_orders_statuses; в примере ответа используются идентификатор сделки deal_id и её status. Интеграция должна опираться на актуальную документацию доступной версии, а не копировать поля из случайного примера без проверки.
Как избежать циклических изменений
Цикл возникает, когда изменение ATI.SU записывается в 1С, а обработчик 1С считает его локальным и отправляет обратно. Затем вебхук снова запускает тот же процесс. Даже если значения одинаковы, системы тратят лимиты и заполняют журнал.
На каждой операции сохраняют источник: пользователь 1С, регламентное задание, вебхук ATI.SU или контрольная сверка. Перед исходящей отправкой сравнивают новое значение с последним подтверждённым удалённым состоянием. Если внешняя система уже содержит это значение, запрос не нужен. Дополнительно задают короткое окно подавления эха для только что применённого внешнего события, но оно не заменяет сравнение фактических данных.
Что делать, если статус «застрял»
- Найдите все связанные идентификаторы. Проверьте исходный груз, копию, заказ и локальные документы, не ориентируясь только на номер в интерфейсе.
- Получите актуальное состояние ATI.SU. Сверьте статус заказа и статус перевозки отдельно.
- Поднимите журнал событий. Нужны время получения, источник, результат проверки подписи, решение таблицы соответствий и ответ исходящего запроса.
- Проверьте очередь ошибок. Событие могло быть принято, но отложено из-за недоступности 1С, лимита API или отсутствия допустимого перехода.
- Сравните версии данных. Более старое событие не должно отменять свежее состояние.
- Исправьте причину и повторите одну операцию. Массовая повторная синхронизация до проверки одного заказа может распространить неверное правило.
Проверки перед рабочим запуском
Тестовый набор должен включать создание заказа, появление копии груза, изменение состояния перевозки, независимое завершение каждой стороной, отмену, повтор вебхука, временную недоступность 1С и восстановление после паузы. Отдельно проверяют событие, пришедшее позже более нового: локальное состояние должно остаться корректным, а журнал — объяснить решение.
Полезна сверочная страница для диспетчера. Она показывает заказ ATI.SU, связанный объект 1С или TMS, оба внешних статуса, внутреннее состояние, время последнего успешного обмена и понятную причину расхождения. Ручная команда должна запускать безопасную сверку выбранной записи, а не безусловно отправлять её заново.
Какие показатели наблюдать после запуска
- количество заказов без связанного локального объекта;
- расхождения статуса заказа и рассчитанного внутреннего состояния;
- возраст последнего подтверждённого обмена;
- непроверенные или отклонённые вебхуки;
- повторные события и циклические исходящие изменения;
- переходы, для которых в таблице нет правила.
Небольшое число расхождений может быть нормальным, если оно объясняется независимыми действиями сторон. Проблемой становится состояние без владельца и следующего шага. Поэтому отчёт должен делить ожидающие подтверждения, технические ошибки и действительно неизвестные переходы.
Такой подход делает статусы проверяемыми. Сотрудник видит не абстрактное «не синхронизировано», а конкретную связь объектов, источник последнего изменения и действие, которое вернёт процесс в норму.