Почему дубль — это не просто лишний документ

Один заказ сайта превращается в два документа в 1С, а вслед за этим появляются лишние резервы, повторные звонки, уведомления и неверная аналитика.

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

Семь причин дублей

  1. Повтор после тайм-аута. Документ записан, ответ потерян, повтор создаёт новый.
  2. Нет стабильного внешнего ключа. Поиск ведётся по телефону, номеру или времени.
  3. Два параллельных обработчика. Оба одновременно видят, что документа ещё нет.
  4. Ручной и автоматический импорт. Заказ приходит двумя независимыми маршрутами.
  5. Оплата считается новым заказом. Событие статуса создаёт документ вместо обновления.
  6. Ключ меняется при редактировании. Изменённый заказ перестаёт узнаваться.
  7. Очередь повторяет частично выполненное сообщение. Действие выполнено, но результат не зафиксирован.
Важно

Два похожих заказа клиента могут быть реальными. Дубль подтверждается одним внешним ID, payment ID, message ID или correlation ID.

Как найти точку повторного создания

  1. Зафиксируйте пример

    Запишите ID заказа, время и IDs документов 1С.

  2. Соберите попытки

    Найдите запросы, сообщения, файлы и ручные действия с этим ID.

  3. Постройте временную линию

    Расположите приём, запись, ответ и повторы по времени.

  4. Проверьте ключ

    Убедитесь, что поиск идёт по неизменяемому ID и источнику.

  5. Проверьте параллельность

    Выясните, могли ли два процесса создать документы одновременно.

  6. Воспроизведите безопасно

    На тестовой копии повторите запрос, потерю ответа и параллельную отправку.

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

Минимум для расследования
ПолеЗачем
external_order_idСвязать документ с источником
request/message IDРазличить попытки доставки
correlation IDСобрать цепочку систем
время и обработчикУвидеть параллельность
ID документа 1СВернуть прежний результат при повторе

Как защитить обмен

01 · IDВнешний ключ

Неизменяемый ID источника хранится в 1С и проверяется до создания.

02 · LOCKАтомарность

Два процесса не могут одновременно пройти «проверить и создать».

03 · RESULTСохранённый ответ

Повтор получает ID уже созданного документа.

04 · EVENTSРазные события

Создание, оплата, изменение и отмена имеют отдельные правила.

Телефон — не ключ заказа.

Один клиент может оформить несколько заказов. Идентификатор должен приходить из системы-источника и не зависеть от редактируемых полей.

Какими тестами проверить исправление

Приёмочные сценарии

  • Один запрос создаёт один документ.
  • Повтор того же запроса не создаёт новый.
  • Два одинаковых запроса приходят одновременно — документ один.
  • Ответ теряется после записи — повтор возвращает существующий ID.
  • Оплата обновляет заказ.
  • Неизвестный товар не создаёт половину документа.
  • После исчерпания повторов приходит уведомление с correlation ID.

Что делать с существующими дублями

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

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

Сначала исправляется причина, потом данные. Иначе ручная очистка освобождает место для новых дублей.

Частые вопросы

Можно ли искать дубли по телефону и сумме?

Так можно искать кандидатов, но не защищать обмен. Надёжнее неизменяемый внешний ID заказа.

Что такое идемпотентность?

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

Почему дубль появляется не всегда?

Это часто зависит от тайм-аута, гонки процессов или редкого повтора, поэтому без журнала ошибку трудно воспроизвести.

Что если заказ приходит из разных сайтов?

Используют составной ключ: источник плюс ID заказа в источнике.

Поможет ли очередь?

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

Заказы уже дублируются?

Пришлите схему обмена, пример внешнего ID и обезличенный фрагмент журнала. Я помогу локализовать точку повтора.

Разобрать проблему →