Обмен данными между системами: как не терять заявки при сбоях

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

Определите, где сохраняется исходное обращение

До настройки нужно решить, какая система отвечает за первичную запись. Для формы это может быть её собственное хранилище, CRM или другая согласованная точка. Важно, чтобы при неудачной передаче существовал способ восстановить запрос.

Нужен номер обращения или другой идентификатор, который проходит через этапы. По нему сотрудник сможет связать сообщение формы и запись в конечной системе.

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

Отличайте попытку от результата

Владельцу процесса полезны состояния «Ожидает передачи», «Передано», «Требует проверки». Успех наступает, когда приёмник подтвердил запись. Начатая отправка ещё не успех.

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

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

Как показывать ошибки интеграции

Список проблемных отправок должен отвечать на простые вопросы:

• какое обращение не обработано;
• когда произошла последняя попытка;
• что известно о причине;
• кто должен вмешаться;
• можно ли повторить действие;
• как убедиться, что дубля не возникло.

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

Повторная отправка заявки: что согласовать

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

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

ИИ объясняет проблему, правила управляют повтором

Помощнику можно передать разрешённые записи журнала и инструкцию: он подготовит сводку «с утра отклоняются заявки без нового обязательного поля» со ссылками на события. Ответственный проверяет причину и выбирает действие. Коммерческие данные и секреты подключения в такую сводку не включают.

Сам повтор выполняется по заранее заданным правилам. Модель не должна по догадке менять реквизиты, удалять записи или увеличивать права доступа. Ошибка «нет обязательного поля» требует исправления данных; потерянное подтверждение требует поиска уже созданной записи. Это разные действия, даже если для пользователя оба случая выглядят как «не отправилось».

Платформа 1С поддерживает REST‑интерфейс для обмена данными. Но наличие механизма не означает, что в конкретной базе опубликованы нужные объекты и настроены права. Это проверяют до оценки подключения.

Как руководителю проверить надёжность без чтения кода

Попросите показать одну заявку на каждом этапе и найти её по исходному номеру. Затем отправьте её повторно: количество бизнес‑записей не должно увеличиться. После временной недоступности приёмника покажите, где хранится обращение и кто видит очередь. После восстановления найдите подтверждённую запись в конечной системе.

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

Приёмка заканчивается сверкой исходного обращения с результатом. Зелёной галочки в журнале для этого мало. Для пилота достаточно одного направления обмена; расширение на другие сущности делают после проверки этой цепочки.

Какие ситуации проверить до запуска

Отправьте корректное обращение, затем неполное и повторное. Проверьте недоступность принимающей системы, отклонение данных и сценарий, при котором запись создана, но подтверждение потеряно.

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

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

TRIKE может связать ваши системы и определить порядок обработки ошибок. В демо интеграции показан пример сценария, а реальные способы обмена зависят от ваших систем. Базовый набор полей разобран в статье о передаче заявок в CRM.

Смежные разборы: Подготовка данных к автоматизации: справочники без путаницы; Сопровождение автоматизации: что нужно после запуска.