Далее описаны общие инженерные рекомендации, а не внутренняя архитектура проекта dag-sport.
Почему дубли заказов создают проблемы
Один заказ сайта превращается в два документа в 1С, а вслед за этим появляются лишние резервы, повторные звонки, уведомления и неверная аналитика.
Надёжный обмен допускает повтор одного события без повторного бизнес-действия. Сеть может оборваться после записи документа, но до ответа сайту. Сайт повторит запрос, и система должна вернуть существующий результат.
7 причин, почему заказы дублируются в 1С
- Повтор после тайм-аута. Документ записан, ответ потерян, повтор создаёт новый.
- Нет стабильного внешнего ключа. Поиск ведётся по телефону, номеру или времени.
- Два параллельных обработчика. Оба одновременно видят, что документа ещё нет.
- Ручной и автоматический импорт. Заказ приходит двумя независимыми маршрутами.
- Оплата считается новым заказом. Событие статуса создаёт документ вместо обновления.
- Ключ меняется при редактировании. Изменённый заказ перестаёт узнаваться.
- Очередь повторяет частично выполненное сообщение. Действие выполнено, но результат не зафиксирован.
Два похожих заказа клиента могут быть реальными. Сначала проверьте, не создан ли один заказ в 1С дважды. Сопоставляйте идентификатор заказа вместе с системой или магазином, откуда он пришёл. Payment ID, message ID и correlation ID помогают проследить обработку, но не заменяют эту проверку.
Как найти место, где заказ создаётся повторно
- Зафиксируйте пример
Запишите ID заказа, время и IDs документов 1С.
- Соберите попытки
Найдите запросы, сообщения, файлы и ручные действия с этим ID.
- Постройте временную линию
Расположите приём, запись, ответ и повторы по времени.
- Проверьте ключ
Убедитесь, что поиск идёт по неизменяемому ID и источнику.
- Проверьте параллельность
Выясните, могли ли два процесса создать документы одновременно.
- Воспроизведите безопасно
На тестовой копии повторите запрос, потерю ответа и параллельную отправку.
Полезный журнал связывает внешний заказ со всеми попытками: когда событие принято, какой обработчик работал, найден или создан документ, какой ответ отправлен.
| Поле | Зачем |
|---|---|
| external_order_id | Связать документ с источником |
| request/message ID | Различить попытки доставки |
| correlation ID | Собрать цепочку систем |
| время и обработчик | Увидеть параллельность |
| ID документа 1С | Вернуть прежний результат при повторе |
Дубли в связке 1С-Битрикс и 1С
Для сайтов на 1С-Битрикс «1С» и «1С-Битрикс» описали открытый протокол обмена. Данные идут в формате CommerceML, а начинает обмен всегда 1С. За заказами она обращается к сайту в таком порядке: авторизация, параметры, получение заказов (mode=query) и подтверждение (mode=success). Подтверждение 1С отправляет после того, как получила и записала заказы. Затем она может передать сайту файл с изменениями по заказам.
Отсюда два случая, когда заказ может прийти в 1С повторно. Если подтверждение не дошло до сайта, следующий сеанс может передать те же заказы ещё раз. Сайт может передать заказ и тогда, когда тот изменился после выгрузки: например, поменялся статус оплаты. Если подтверждение не дошло, повторная передача не должна создавать новый документ. Если заказ изменился после выгрузки, обработка должна найти существующий документ и обновить согласованные данные.
Поэтому первым делом проверьте, по какому полю 1С узнаёт заказ из пакета. В XML заказа есть и идентификатор (элемент Ид), и номер. Номер удобен людям, но он может поменяться. В настройках «Интеграция с 1С» в Битриксе, например, есть префикс номера заказа при выгрузке. Если 1С ищет документ по номеру, то после смены префикса она не узнает заказ, который придёт повторно, и создаст новый документ.
| Что видно | Что проверить | Что подтверждает версию |
|---|---|---|
| Второй документ появился после сбоя обмена | Дошёл ли до сайта запрос mode=success после сеанса, в котором записан первый документ | Сеанс без подтверждения, а следующий сеанс передал заказ с тем же Ид |
| Дубль появился после оплаты или смены статуса | Обновляет ли 1С найденный документ, когда изменённый заказ приходит снова | У обоих документов один и тот же идентификатор заказа сайта |
| Дубли пошли после изменения настроек обмена | Не меняли ли префикс номера заказа при выгрузке | Номера дублей различаются префиксом, идентификатор совпадает |
| Лишний заказ появился на сайте | Включена ли настройка «Создавать новые заказы и контрагенты из 1С» и не заводят ли тот же заказ в 1С вручную | Второй заказ на сайте создан обменом из документа, введённого в 1С |
Префикс номера, фильтры выгрузки и создание заказов из 1С влияют на все следующие сеансы. Меняйте их на копии сайта и базы, а после изменения повторите приёмочные сценарии ниже.
Как предотвратить повторное создание заказов
Неизменяемый ID источника хранится в 1С и проверяется до создания.
Два процесса не могут одновременно пройти «проверить и создать».
Повтор получает ID уже созданного документа.
Создание, оплата, изменение и отмена имеют отдельные правила.
Один клиент может оформить несколько заказов. Идентификатор должен приходить из системы-источника и не зависеть от редактируемых полей.
Какими тестами проверить исправление
Приёмочные сценарии
- Один запрос создаёт один документ.
- Повтор того же запроса не создаёт новый.
- Два одинаковых запроса приходят одновременно — документ один.
- Ответ теряется после записи — повтор возвращает существующий ID.
- Оплата обновляет заказ.
- Неизвестный товар не создаёт половину документа.
- Если в схеме есть очередь и ограничение числа повторов, после исчерпания попыток ошибка остаётся в журнале с идентификатором, по которому можно восстановить цепочку.
Что делать с существующими дублями
Сначала остановите источник повторов, затем найдите кандидатов по внешнему ID и проверьте резервы, оплаты, отгрузки и уведомления. Простое удаление второго документа может нарушить учёт, если по нему уже были движения.
Для каждого дубля определяют основной экземпляр, корректно отменяют или переносят связанные операции и фиксируют результат разбора. После очистки полезен автоматический отчёт по повторяющимся ключам.
Сначала исправляется причина, потом данные. Иначе ручная очистка освобождает место для новых дублей.
Частые вопросы
Можно ли искать дубли по телефону и сумме?
Так можно искать кандидатов, но не защищать обмен. Надёжнее неизменяемый внешний ID заказа.
Что такое идемпотентность?
Идемпотентность означает, что повторная обработка одного и того же заказа не создаёт второй документ: система находит уже созданный результат вместо повторного создания.
Почему дубль появляется не всегда?
Это часто зависит от тайм-аута, гонки процессов или редкого повтора, поэтому без журнала ошибку трудно воспроизвести.
Что если заказ приходит из разных сайтов?
Используют составной ключ: источник плюс ID заказа в источнике.
Поможет ли очередь?
Она управляет доставкой, но сообщение всё равно может прийти повторно. Обработчик обязан быть идемпотентным.
Что означает mode=success в обмене Битрикса с 1С?
Это запрос, которым 1С подтверждает сайту, что получила и записала заказы. Если подтверждение не дошло, следующий сеанс может передать те же заказы, поэтому 1С должна находить уже созданный документ по идентификатору заказа.
Почему дубли появились после смены префикса номера заказа?
Если 1С ищет заказ по номеру, новый префикс меняет номер. Заказ, который придёт повторно, 1С уже не узнает и создаст второй документ. Надёжнее сопоставлять заказы по идентификатору из XML.
Нужно разобраться, почему заказы дублируются?
Пришлите схему обмена, пример внешнего ID и обезличенный фрагмент журнала. Я помогу локализовать точку повтора.
Разобрать проблему →