Антон Дегтярёвнастройка обмена «сайт ↔ 1С» с помощью commerceml
CommerceML — не то же самое, что обмен Битрикс24 и 1С через CRM-коннектор, хотя название путают постоянно. Это отдельный протокол для сайта на 1С-Битрикс: выгрузка каталога и остатков из 1С на сайт, и обратная загрузка заказов. Ниже — как это настроить и что обычно идёт не так в первый раз.
чем это отличается от обмена битрикс24 и 1с
Важно сразу развести два разных обмена, которые называют одинаково «1С и сайт». Обмен Битрикс24 (CRM) с 1С работает с сущностями CRM — контрагентами, сделками, счетами, номенклатурой для выставления счёта. Разбор этих вариантов — в отдельной статье.
CommerceML — протокол для сайта на движке «1С-Битрикс: Управление сайтом» (интернет-магазин), а не для CRM-портала Битрикс24. Он выгружает из 1С каталог товаров, цены, остатки — на витрину сайта, и загружает с сайта в 1С оформленные заказы. Если у вас интернет-магазин на 1С-Битрикс и учёт в 1С — это тот протокол, который нужен именно для наполнения каталога, а не для CRM.
что выгружается и в каком формате
Стандартный обмен CommerceML2 состоит из XML-файлов. import.xml — структура каталога: разделы, товары, свойства, характеристики (размер, цвет и так далее), картинки. offers.xml — торговые предложения: цены и остатки по конкретным SKU, привязанные к товарам из import.xml по идентификатору.
Разделение на два файла не случайное: структура каталога (import.xml) меняется редко, а цены и остатки (offers.xml) — часто, иногда несколько раз в день. Обмен можно настроить так, чтобы полная выгрузка каталога шла раз в сутки, а offers.xml (только цены и остатки) — каждые 15–30 минут, без перегрузки сервера полной выгрузкой.
настройка на стороне 1с
В 1С (Управление торговлей, Бухгалтерия, УНФ — обмен встроен в типовые конфигурации через план обмена CommerceML) нужно создать узел обмена с сайтом: указать адрес сайта, логин и пароль для авторизации на обработчике обмена, выбрать номенклатуру и склад, с которого берутся остатки.
Частая ошибка на этом шаге — выгружать в обмен весь справочник номенклатуры, включая позиции, которых нет в наличии или которые не предназначены для розничной продажи (сырьё, комплектующие для внутреннего производства). Правильно — фильтр по группе номенклатуры или отдельному реквизиту «публикуется на сайте», иначе на витрине появляются товары, которые продавать не планировали.
настройка на стороне сайта
На стороне 1С-Битрикс обмен принимает обработчик /bitrix/admin/1c_exchange.php. В административной панели сайта нужно создать пользователя с правами на обмен (отдельная учётная запись, не основной админ — так проще отследить, что именно делает обмен, и ограничить права только каталогом), и указать те же логин-пароль в настройках 1С.
В модуле «Торговый каталог» указывается, в какой раздел сайта попадают товары из import.xml — обычно это уже существующая структура каталога, и первая синхронизация просто раскладывает номенклатуру 1С по существующим разделам по совпадению названия или отдельному полю сопоставления.
http против webdav — как передаются файлы
Файлы обмена передаются одним из двух способов. Через прямой HTTP-запрос к 1c_exchange.php — 1С отправляет данные напрямую на сайт, без промежуточных папок. Этот способ проще в настройке и подходит для каталогов среднего размера.
Через WebDAV — 1С сначала кладёт XML-файлы в папку на сервере сайта по протоколу WebDAV, обмен идёт через файловую систему. Это надёжнее для больших каталогов (десятки тысяч позиций), где прямой HTTP-запрос может не уложиться в таймаут сервера. Выбор способа — на старте настройки в 1С, при создании узла обмена.
как загружаются заказы обратно в 1с
Обратное направление — заказы, оформленные на сайте, поступают в 1С при следующем сеансе обмена. Каждый заказ получает статус, который синхронизируется в обе стороны: 1С может менять статус («в сборке», «отгружен»), и это отражается на сайте в личном кабинете покупателя, если такая синхронизация настроена дополнительно.
Важный момент, который часто упускают на старте: если у заказа на сайте есть кастомные поля (например, комментарий к заказу, способ доставки не из стандартного списка), их нужно явно сопоставить с реквизитами документа в 1С — иначе информация просто не долетает, и менеджер по заказам не видит комментарий покупателя.
типичные ошибки именно в обмене каталога
В отличие от ошибок CRM-обмена (разобраны отдельно — дубли контрагентов, зависший обмен, кракозябры), у обмена каталога свои специфичные проблемы. Первая — превышение времени выполнения PHP-скрипта при большом каталоге: если import.xml выгружает 20+ тысяч товаров одним запросом, обмен может обрываться на середине. Решение — либо увеличить лимиты на сервере, либо перейти на WebDAV с разбивкой на части.
Вторая — несовпадение идентификаторов между import.xml и offers.xml: если 1С меняет внутренний ID товара (например, после реструктуризации справочника), офера перестают находить свой товар, и остатки/цены на сайте не обновляются, хотя обмен формально проходит без ошибок. Третья — картинки: при большом каталоге выгрузка изображений занимает больше всего времени и трафика, поэтому картинки часто настраивают на менее частую синхронизацию, чем цены и остатки.
как проверить, что обмен прошёл успешно
После первой настройки проверяю по чек-листу: количество товаров на сайте совпадает с количеством в выгрузке 1С (не больше и не меньше — расхождение говорит о фильтрах или ошибке маппинга разделов); цены и остатки на карточке товара совпадают с 1С на момент последней синхронизации; тестовый заказ, оформленный на сайте, появился в 1С со всеми полями, включая доставку и комментарий.
В 1С в узле обмена есть протокол выполнения — там видно время последнего успешного сеанса и текст ошибки, если обмен оборвался. Если сеансы идут по расписанию, но данные на сайте не обновляются — почти всегда это либо ошибка авторизации (истёк или сменился пароль на одной из сторон), либо блокировка со стороны хостинга сайта на частые запросы.
когда типовой commerceml не подходит
Типовой обмен рассчитан на стандартную структуру каталога и штатные конфигурации 1С. Он перестаёт быть удобным, если: каталог обновляется почти в реальном времени (десятки изменений цен в час на маркетплейс-подобном ассортименте), структура каталога сильно нестандартная и требует сложной логики маппинга, или нужна синхронизация не только каталога и заказов, но и статусов оплаты, резервов, персональных цен по клиентам.
В этих случаях смотрят в сторону кастомной интеграции через REST API вместо типового CommerceML, либо стороннего сервиса синхронизации. Обзор всех вариантов обмена, включая нетиповые, — в статье про варианты обмена; там же ориентир по стоимости каждого способа.
почему это вообще есть только у 1с-битрикс
Встроенный CommerceML-обмен — одна из причин, почему для магазина с учётом в 1С я обычно рекомендую именно движок 1С-Битрикс, а не конструктор или коробочное решение без такой интеграции: обмен работает «из коробки», без покупки дополнительного модуля или разработки коннектора с нуля. Сравнение движков интернет-магазинов именно по этому критерию — в отдельной статье, там разбор по количеству SKU и источнику остатков.
Если сайта на 1С-Битрикс у вас ещё нет, а обмен с 1С нужен — это стоит учитывать на этапе выбора платформы, а не после того, как магазин уже сделан на другом движке и типовой протокол оказывается недоступен. Подробнее о разработке сайтов и интернет-магазинов на 1С-Битрикс — здесь.