Частые ошибки синхронизации статусов заказов и как их избежать

Ошибка №1. Неправильный маппинг статусов

В чём проблема. 1С отправляет статус заказа в XML-документе, но Битрикс не знает, какому внутреннему коду он соответствует. Например, 1С передаёт статус «Отгружен», а в Битриксе нет статуса с таким идентификатором — обновление не применяется.

Как это выглядит в логах. В файле обмена `orders.xml` есть тег `<Статус>` с идентификатором из 1С. При импорте Битрикс ищет заказ по идентификатору и пытается обновить статус согласно маппингу. Если сопоставление не задано — статус остаётся прежним.

Как избежать. В разделе Магазин → Настройки → Статусы заказов для каждого статуса заполните поле «Идентификатор 1С» — это код статуса из 1С.

Стандартный маппинг для УТ 11:

Статус в 1С	Код в Битрикс
Новый	N
В работе	P
Подготовлен	D
Выполнен	F
Отменён	C

После обновления 1С статусы могут переименовываться — маппинг слетает. Выход — автоматизировать проверку соответствия или вести журнал всех статусов.

Ошибка №2. Путаница с идентификаторами заказа

В чём проблема. Обмен работает только с `ACCOUNT_NUMBER` (номер заказа), а не с внутренним `ID`. Если в XML передан не тот идентификатор — Битрикс не найдёт заказ для обновления.

Как избежать. При диагностике ошибки «Status not updating» проверьте в логах, какой идентификатор передаётся в теге `<Ид>` заказа, и сравните его с `ACCOUNT_NUMBER` на сайте.

Шаг 2. Включение выгрузки контрагентов

В чём проблема. По логике синхронизации «1С» и «1С-Битрикс: Управление сайтом», статус заказа меняется только если из 1С передались дата оплаты либо дата отгрузки товара.

Как это работает:

• Чтобы дата оплаты попала в XML, в 1С нужно сформировать документы оплаты: «Платежное поручение входящее» или «Приходный кассовый ордер».
• Чтобы дата отгрузки попала в XML, нужно ввести документ «Реализация товаров и услуг».

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

• в регистре «Расчеты с контрагентами» остаток по заказу <= 0 (заказ считается оплаченным);
• в регистре «Заказы покупателей» остаток по заказу <= 0 (заказ считается отгруженным).

Ошибка №4. Забытый callback при онлайн-оплате

В чём проблема. Клиент оплатил заказ через эквайринг, деньги списались, а статус в Битриксе не обновился. Причина — неправильный URL в настройках шлюза или обработчик, возвращающий 500-ю ошибку.

Как избежать. При настройке приёма платежей проверьте корректность callback-URL и убедитесь, что обработчик возвращает успешный код. После успешной оплаты в Битриксе создаётся объект платежа с признаком `PAID = Y`, который затем передаётся в 1С.

Ошибка №5. Дублирование заказов при сбое обмена

В чём проблема. Если сеанс обмена прервался после передачи файла, при следующем запуске заказы передаются повторно.

Как избежать. Используйте уникальный идентификатор заказа (`ACCOUNT_NUMBER`) и проверку на существование документа в 1С. В сложных случаях настраивайте REST API, который атомарно подтверждает получение заказа.

Ошибка №6. Потеря свойств заказа (UTM-метки, промокоды)

В чём проблема. Стандартный CommerceML не передаёт UTM-метки, промокоды и тип клиента. Без них маркетинговая аналитика становится неполной.

Как избежать. Добавляйте недостающие реквизиты через обработчик `OnSaleOrderExport1C` и создавайте соответствующие реквизиты в 1С.

Ошибка №7. «Зависший» заказ в промежуточном статусе

В чём проблема. В коде интеграции нет обработки ошибок при взаимодействии с внешними сервисами — заказ застревает в промежуточном статусе.

Как избежать. Настраивайте очереди и механизмы повторных попыток (retry), чтобы ошибки синхронизации не блокировали заказ.

Ошибка №8. Конфликт событий при кастомной логике

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

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

Ошибка №9. Проблемы с производительностью и правами

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

Как избежать:

• Убедитесь, что у пользователя обмена есть права на изменение статусов заказов.
• Проверьте права на запись в папку обмена и наличие свободного места на диске.
• Используйте кеширование с тегами и агентов для ускорения обмена.
• Для критичных заказов используйте REST API вместо CommerceML — он работает в десятки раз быстрее.