Синхронизация заказов Битрикс ↔ 1С

Обмен каталогом идёт из 1С на сайт, а заказы движутся в обратную сторону и возвращаются обновлёнными. Это встречный, двусторонний обмен: сайт отдаёт новые и изменённые заказы, а 1С возвращает их со статусами оплаты, отгрузки и связкой с контрагентом. Разберём, как это работает и где чаще всего рвётся.

Что именно синхронизируется и в какую сторону

Обмен с 1С в Битрикс — это два независимых потока по протоколу CommerceML. Каталог (товары, цены, остатки, свойства) идёт из 1С на сайт, а заказы — с сайта в 1С и обратно. Оба потока используют один HTTP-скрипт входа /bitrix/admin/1c_exchange.php, но работают с разными схемами данных: каталог — тип catalog, заказы — тип sale.

По заказам синхронизируются: сам заказ и его состав (корзина), плательщик и покупатель (контрагент), способ оплаты и доставки, факт и сумма оплаты, факт отгрузки, комментарии и статус. Инициатором обмена всегда выступает 1С: она по расписанию обращается к сайту, забирает новые заказы и присылает обновления.

Как устроен обмен заказами: этапы

Один сеанс обмена заказами — это последовательность HTTP-запросов от 1С к сайту с параметром type=sale. Понимание этапов сильно упрощает отладку.

1. Авторизация — mode=checkauth: 1С проходит Basic-аутентификацию и получает cookie сессии обмена.
2. Инициализация — mode=init: согласуются zip-сжатие и предельный размер порции файла.
3. Выгрузка заказов сайтом — mode=query: Битрикс формирует XML с новыми и изменёнными заказами и отдаёт его 1С.
4. Загрузка обновлений в сайт — mode=import: 1С присылает те же заказы обратно с проставленными статусами, оплатой и отгрузкой.

То есть заказ уходит в 1С, там обрабатывается (проводится оплата, резервируется и отгружается товар), а затем возвращается на сайт уже с актуальным состоянием. Обмен инициируется регламентным заданием в 1С, поэтому периодичность задаётся именно там, а не на сайте.

Настройка на стороне сайта

Базовые параметры обмена заказами лежат в Магазин → Настройки → Настройки обмена с «1С» (для старой торговой платформы) либо в узле обмена, если магазин переведён на новый функционал заказов. Ключевые вещи, которые нужно проверить:

• Логин и пароль обмена. Отдельный служебный пользователь с правами на обмен — именно под ним 1С проходит checkauth. Не используйте для этого администратора.
• Экспортируемые статусы. Указывается, с какого статуса заказ считается готовым к выгрузке и какие изменения инициируют повторную отдачу.
• Соответствие свойств заказа. Свойства с типами «ФИО», «Телефон», «E-Mail», «Местоположение», «Адрес» должны быть привязаны к соответствующим системным типам — иначе 1С не соберёт контрагента.
• Способы оплаты и доставки. Каждой платёжной системе и службе доставки на сайте нужно сопоставление с 1С.

Настройка на стороне 1С

В типовых конфигурациях (УТ, Комплексная автоматизация, УНФ, а для 1С-Битрикс: Управление сайтом — модуль «1С-Битрикс: Сайт») обмен настраивается через узел обмена с сайтом. Здесь задаются адрес скрипта, учётные данные и расписание.

Что важно указать в 1С:

• Адрес узла — полный URL до /bitrix/admin/1c_exchange.php вашего сайта.
• Логин и пароль — те же, что заведены на сайте под обмен.
• Правила выгрузки заказов — какие статусы 1С возвращает на сайт и как этапы документов (заказ клиента, реализация, оплата) отображаются в статусы сайта.
• Расписание — регламентное задание, которое запускает сеанс обмена. Обычно это интервал в несколько минут.

Инициатива обмена в 1С означает, что если задание не выполняется (остановлен планировщик, нет сеанса под нужным пользователем в серверной 1С), заказы просто перестают приходить, хотя на сайте всё исправно.

Соответствие статусов, оплаты и доставки

Самая частая точка расхождений — маппинг состояний. У сайта свой список статусов заказа (Магазин → Настройки → Статусы заказа), у 1С — свои этапы документов. Их нужно свести в явную таблицу соответствий.

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

Идентификаторы и связывание объектов

Обмен держится на идентификаторах. Если связка теряется, вместо обновления возникают дубли.

• Товары в корзине связываются по XML_ID — тому же идентификатору, под которым товар пришёл из 1С при выгрузке каталога. Позиция без корректного XML_ID в 1С не сопоставится, и заказ загрузится с ошибкой по строке.
• Сам заказ идентифицируется по номеру (ACCOUNT_NUMBER) и внутреннему ID; 1С хранит своё соответствие, чтобы при повторных сеансах обновлять тот же документ.
• Покупатель на сайте — это пользователь, а в 1С — контрагент. Связывание идёт по свойствам заказа (ФИО, телефон, e-mail). Именно здесь рождаются дубли контрагентов, если данные приходят в разном формате.

Типовые проблемы и отладка

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

• Обмен «молчит». Проверьте регламентное задание в 1С и ответ checkauth — чаще всего дело в пароле служебного пользователя или в блокировке 1c_exchange.php фаерволом.
• Заказ не выгружается. Скорее всего он не попал под фильтр экспортируемых статусов или менеджер не менял его после последнего сеанса.
• Дубли заказов или контрагентов. Потеряна связка по идентификатору или расходятся данные покупателя — сверьте свойства заказа и правила поиска контрагента в 1С.
• Ошибка по строке товара. У позиции нет XML_ID или товар отсутствует в базе 1С.
• Таймаут / большой файл. Уменьшите размер порции (шаг обмена) в настройках, чтобы сеанс укладывался в лимиты по времени и памяти PHP.

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

Итог

Синхронизация заказов в 1С-Битрикс — это встречный обмен по CommerceML: сайт отдаёт заказы через 1c_exchange.php, а 1С возвращает их с оплатой, отгрузкой и статусами. Надёжность держится на трёх вещах: корректной привязке свойств заказа к контрагенту, точном соответствии статусов и способов оплаты/доставки, и целостности идентификаторов (XML_ID товаров, номер заказа). Инициатором всегда остаётся 1С, поэтому расписание и большая часть логики возврата живут на её стороне.

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