Настройка обмена заказами между 1С и 1С-Битрикс
Обмен заказами — двусторонний процесс: сайт передаёт новые заказы в 1С, 1С возвращает обновлённые статусы. Ключевой вопрос при настройке — маппинг статусов заказов между системами, который в каждом проекте уникален. Ошибочный маппинг ведёт к тому, что покупатель видит устаревший статус или, хуже, получает уведомление «Заказ выполнен», пока товар ещё на складе.
Передача заказов с сайта в 1С
Заказы передаются в формате CommerceML в XML-файле orders.xml. 1С забирает файл при очередном сеансе обмена. Настройки на стороне Битрикс:
Настройки → Настройки продуктов → Интернет-магазин → Обмен заказами:
- Выгружать заказы: включить
-
Статусы для выгрузки: выбрать статусы, которые должны попадать в 1С. Обычно «Новый» (
N) и «Оплачен» (P). Отменённые и завершённые заказы без нужды передавать не стоит — они создают лишнюю нагрузку - Период: с даты последнего обмена — самый безопасный вариант, не передаёт повторно уже обработанные заказы
В XML заказа передаются: реквизиты покупателя, позиции с количеством и ценами, выбранная доставка, свойства заказа (адрес, телефон, комментарий).
Маппинг статусов
Статусы в 1С и на сайте называются по-разному и не всегда соответствуют один к одному. Стандартный маппинг настраивается в:
Магазин → Настройки → Статусы заказов → [статус] → Идентификатор в 1С
Пример типичного маппинга для УТ 11:
| Статус в 1С | Код статуса Битрикс | Описание |
|---|---|---|
| В работе | P |
Принят, передан в обработку |
| Подготовлен к отгрузке | D |
Комплектуется / Готов |
| Передан курьеру | F |
Доставляется |
| Выполнен | FF |
Доставлен, закрыт |
| Отменён клиентом | C |
Отменён |
Без правильного маппинга 1С при обновлении статуса создаст в журнале ошибку «Неизвестный статус», и обновление не применится.
Типичные проблемы
Дублирование заказов. Если сеанс обмена прервался после передачи файла, но до получения подтверждения от 1С — при следующем сеансе заказы передадутся повторно. Защита: уникальный идентификатор заказа в XML совпадает с ACCOUNT_NUMBER сайта, 1С проверяет существование документа перед созданием.
Потеря свойств заказа. Нестандартные свойства (UTM-метки, промокод, тип клиента) не передаются через стандартный XML. Добавляются через обработчик события OnSaleOrderExport1C. После добавления свойства убедиться, что в 1С реквизиты для их хранения созданы.
Расхождение сумм. 1С пересчитывает скидки по своим правилам и получает другую итоговую сумму. Решение: передавать итоговые цены позиций уже с учётом скидки, а скидку — как отдельную строку в позициях заказа.
Обмен заказами в реальном времени через события
Если нужно, чтобы заказ попадал в 1С сразу при оформлении (без ожидания следующего сеанса обмена) — использовать REST API 1С или HTTP-запрос в обработчике события OnSaleOrderSaved:
\Bitrix\Main\EventManager::getInstance()->addEventHandler(
'sale',
'OnSaleOrderSaved',
function(\Bitrix\Main\Event $event) {
$order = $event->getParameter('ENTITY');
if ($order->isNew()) {
\MyProject\Exchange\OrderPusher::push($order->getId());
}
}
);
Сроки настройки
Настройка обмена заказами с маппингом статусов — 4–8 часов. С нестандартными свойствами и обработчиками — 1–2 дня. С push-отправкой заказов в реальном времени — +1 день.