Почему системы расходятся после успешной передачи
Аудит интеграций и обменов данными
Проверяем цепочку обмена от исходного события до фактического результата, включая повторы, задержки и ручное восстановление.
В журнале стоит «успешно», но заказа нет в учёте. Или заказ появился дважды после повторной отправки. Такие ситуации редко объясняются одной настройкой API. Нужно восстановить путь конкретной операции и установить, что каждая сторона считает подтверждением результата.
Начинаем с нескольких реальных расхождений. Для каждого собираем время, известные идентификаторы и доступные журналы. Затем прослеживаем исходное событие, приём, очередь, преобразование справочников и применение в целевой системе. Там, где нет наблюдаемости, отдельно фиксируем пробел: отсутствие записи в журнале не доказывает отсутствия операции.
На стыке систем меняется смысл
«Клиент», «контрагент» и «плательщик» могут быть разными объектами. Статус CRM может обозначать коммерческую договорённость, а похожий статус ERP — факт проведения документа. Составляем карту соответствий и определяем владельца каждого важного поля. Двусторонняя передача не должна превращаться в соревнование последних изменений.
Отдельно проверяем идентификаторы и начальную загрузку. Если существующие объекты сопоставлялись по названию, дальнейшая надёжность обмена зависит от случайных совпадений. Для цен, количеств и дат уточняем округление, единицы и часовые пояса; небольшое внешне расхождение может менять итоговую бизнес-операцию.
Четыре ситуации, которые стоит воспроизвести
- Источник повторяет уже принятое событие после потери ответа.
- Целевая система некоторое время недоступна, затем возвращается в работу.
- Пакет содержит корректные объекты и одну позицию с неизвестным справочником.
- Результат операции неизвестен: запрос отправлен, подтверждение не получено.
Условия эксперимента выбираем по критичности контура. Для платежей, действующих заказов и складских операций используем разрешённые тестовые сущности или отдельную среду. Аудит не предполагает неконтролируемого воспроизведения сбоев на рабочих документах.
Как оператор восстановит работу без разработчика
Проверяем, можно ли найти проблемный объект по известному номеру, увидеть причину и повторить допустимую обработку. Важны ограничение попыток, очередь исключений и сверка итогового состояния. Кнопка «повторить всё» без защиты от дублирования сама может быть источником инцидента.
Итоговый документ содержит схему фактического обмена, подтверждённые дефекты, недоступные для проверки участки и план изменений. Разделяем исправление контракта, улучшение диагностики и организационные правила: иногда техническая передача работает, а согласованный владелец ошибки отсутствует.
До начала нужны перечень связанных систем, контакт сопровождающего каждой стороны и несколько примеров расхождений. Если обмен поддерживают разные подрядчики, заключение помогает согласовать границу ответственности по конкретным свидетельствам. Разработка исправлений, изменения в 1С и установка готовых модулей оцениваются после проверки, а не назначаются обязательным условием аудита.