Два заказа вместо одного в 1С-Битрикс: как найти причину дублей

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

Ниже — порядок проверки дублей при оформлении в интернет-магазине на 1С-Битрикс. Он подходит для стандартного оформления с доработанным шаблоном, покупки в один клик и собственных обработчиков. Причины перечислены как гипотезы для проверки: сам по себе дубль не доказывает ошибку ядра. Примеры и номера заказов условные.

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

1. Убедитесь, что на сайте созданы два разных заказа

Откройте список заказов в административной части и сравните внутренние ID. Два письма с одним ID ещё не означают, что покупка создалась дважды. Внешний номер заказа, внутренний ID, идентификатор оплаты и номер документа в 1С — разные ориентиры; в диагностике их стоит записывать отдельно.

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

Если повторяются только платежи или документы обмена, полезны отдельные разборы онлайн-оплаты и передачи заказов в 1С. Дальше речь идёт о двух самостоятельных заказах на сайте.

2. Проследите, сколько запросов отправляет оформление

На тестовой копии откройте инструменты разработчика браузера, вкладку Network, включите сохранение журнала и оформите контрольную корзину. Важно найти запрос, который действительно создаёт заказ. Пересчёт доставки, применение купона и обновление блока оформления тоже могут обращаться к серверу; несколько AJAX-запросов сами по себе нормальны.

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

• Два запроса создания с одного действия. Проверьте, не работают ли одновременно обработчик клика и обработчик отправки формы, не подключён ли скрипт дважды.
• Проблема появляется после выбора доставки. Посмотрите, не навешивается ли новый обработчик на каждом обновлении блока, в том числе в доработанном шаблоне sale.order.ajax.
• Один запрос, но два новых ID. Продолжайте на сервере: две записи могли создать разные участки логики в рамках одного обращения.
• Дубли только из «Купить в один клик». Сравните его маршрут с основным оформлением: вспомогательная форма может иметь собственный обработчик создания.

Не публикуйте необработанный HAR-файл: в нём могут оказаться контакты покупателя, адрес, cookies и служебные значения. Для передачи разработчику достаточно очищенной трассировки с временем, адресом обработчика, статусом ответа и обезличенным идентификатором попытки.

3. Свяжите запрос с конкретной записью на сервере

Назначьте входящему запросу технический идентификатор и сопоставьте его с точками создания и сохранения заказа. Для каждой точки нужны время, источник вызова, результат операции и полученный ID. Журнал веб-сервера покажет обращения, но обычно не объяснит, какой участок PHP создал вторую запись: для этого нужна ограниченная диагностика приложения.

В D7 новый объект создают через Order::create(), затем сохраняют через save(). Проверку результата показывает официальный пример работы с заказами. При поиске дублей проследите, не создаётся ли второй новый объект в другом обработчике. Повторное сохранение уже существующего объекта само по себе не равнозначно созданию второго заказа.

Отдельно проверьте собственные обработчики событий, модули покупки в один клик и интеграции. По документации событий сохранения, OnSaleOrderSaved вызывается после сохранения, а параметр IS_NEW отличает создание от обновления. Проверка этого параметра помогает ограничить действие обработчика, но не объединяет два независимых запроса: каждый из них может создать свой новый заказ.

Условный пример: запрос A создал заказ 4101, ответ не дошёл до браузера, повторный запрос B создал 4102. Здесь нужно проверять повторное выполнение одной покупки. Если же A вызвал основное оформление, а затем собственный модуль создал 4102, причина в двух путях записи. Внешне пары выглядят одинаково, исправления будут разными.

4. Защитите одну покупку от повторного выполнения

Блокировка кнопки и понятное состояние «Оформляем заказ…» уменьшают случайные нажатия. Но защита должна учитывать и повторное обращение к серверу. Для собственной логики оформления полезен принцип идемпотентности: повтор одной операции возвращает её сохранённый результат. Сам метод POST такой гарантии не даёт — это поясняет справочник MDN.

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

Простой поиск «есть ли такой ключ» перед вставкой недостаточен: два параллельных запроса могут оба увидеть пустой результат. Нужны согласованная транзакционная схема и атомарное ограничение уникальности или блокировка в подходящем хранилище. Отдельно предусмотрите восстановление после сбоя между сохранением заказа и фиксацией результата, срок действия ключа и новую попытку после изменения корзины. Это схема проектирования, а не универсальный патч для любого компонента Битрикса.

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

5. Проверьте исправление в нескольких сценариях

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

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

6. Что передать разработчику для диагностики

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

В таких задачах я сначала связываю конкретную пару заказов с запросами и источниками записи, затем исправляю найденный путь и проверяю повторы и параллельные обращения. Работу можно начать с исправления ошибки оформления заказа, а для контроля после обновлений подойдёт поддержка сайта на 1С-Битрикс. Если дубль появляется при передаче между системами, нужна проверка интеграции.

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

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

Достаточно ли отключить кнопку после первого нажатия?

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

Можно ли автоматически удалять все заказы с одинаковыми товарами и телефоном?

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

Поможет ли обновление Битрикса?

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