Обмен с 1С по нескольким сайтам (многосайтовость)

Многосайтовость в 1С-Битрикс — это несколько витрин на одном ядре, но одна учётная система в 1С. Задача обмена — развести один поток CommerceML на разные каталоги, цены и склады так, чтобы каждый сайт получал только своё, а заказы возвращались в 1С с признаком источника. Ниже разбираем архитектуру, настройку профилей и типовые грабли.

Как устроена многосайтовость и обмен

В 1С-Битрикс несколько сайтов живут на одном ядре и одной базе, но имеют разные LID (идентификатор сайта), разные публичные папки (/ и, например, /opt/ или отдельный домен через DOCUMENT_ROOT) и, как правило, разные валюты, языки и наборы свойств. При этом инфоблоки каталога привязываются к сайтам в настройках инфоблока (вкладка «Привязка к сайтам» или поле SITE_ID).

Обмен с 1С идёт по протоколу CommerceML 2 через типовой файл-приёмник /bitrix/admin/1c_exchange.php. Ключевой момент: каждый профиль обмена в 1С-Битрикс жёстко привязан к одному инфоблоку каталога. Значит, при N витринах с разными каталогами вам нужно N профилей выгрузки — и, соответственно, N узлов обмена в самой 1С.

Три сценария разделения

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

Чаще всего встречается второй вариант — например, розничный и оптовый сайт, или два бренда одной компании. Именно он требует аккуратной настройки, о которой ниже.

Настройка профилей обмена

Профили создаются в Магазин → Настройки → Торговый каталог → Настройки обмена с 1С (или через модуль sale/catalog на странице /bitrix/admin/1c_exchange_settings.php). Для каждой витрины:

• создайте отдельный профиль с уникальным логином/паролем обмена — это разграничит доступ и упростит разбор логов;
• укажите целевой инфоблок каталога конкретного сайта;
• задайте свой каталог для загрузки картинок и файлов, чтобы витрины не перетирали изображения друг друга;
• настройте нужный размер шага (PACKAGE_SIZE) и порог по времени под ресурсы сервера.

В самой 1С (Управление торговлей / КА / ERP) под каждый профиль заводится отдельный узел обмена с сайтом в разделе «Обмен с сайтом (CommerceML)». В настройках узла указывается свой адрес http://site.ru/bitrix/admin/1c_exchange.php, свои логин/пароль и, главное, свой отбор номенклатуры — по группе, виду, свойству или произвольному запросу. Так одна база 1С кормит разные сайты разными срезами каталога.

Цены и склады по сайтам

Даже при общем каталоге витрины обычно отличаются ценами и наличием. В CommerceML цены передаются как типы цен, а остатки — по складам. Разведение делается так:

• в 1С в каждом узле выгружайте только нужные типы цен — например, «Розница» на b2c-сайт и «Оптовая» на b2b-сайт;
• на сайте в настройках каталога сопоставьте пришедшие типы цен с ценами Битрикса и назначьте базовую цену для витрины;
• для наличия используйте складской учёт (catalog_store): выгружайте по конкретным складам и покажите на витрине остаток только своих складов;
• права на цены и склады разграничиваются группами пользователей — это защищает опт от показа розничным клиентам.

Заказы: возврат в 1С с источником

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

1. каждый узел обмена в 1С забирает заказы по своему адресу 1c_exchange.php с логином профиля — уже это физически разделяет потоки;
2. в заказ дополнительно можно выгружать реквизит «Сайт заказа» — через свойство заказа, которое передаётся в <ЗначенияРеквизитов> документа;
3. в 1С по этому реквизиту заказы раскладываются по нужной организации, складу отгрузки и типу цен.

Обратный поток (статусы оплаты и отгрузки) идёт тем же узлом: 1С отдаёт обновлённый документ, Битрикс сопоставляет заказ по ID/XML_ID и меняет статус. Так как узлы разные, статусы не «протекают» между сайтами.

Расписание и нагрузка

Несколько профилей — это несколько параллельных обменов, и они конкурируют за ресурсы. Практические рекомендации:

• разнесите старты выгрузок по времени в планировщике 1С, чтобы тяжёлые каталоги не грузились одновременно;
• используйте пошаговую выгрузку (PACKAGE_SIZE) и разумный интервал — обмен CommerceML идёт частями и держит соединение;
• тяжёлую полную выгрузку каталога делайте ночью, а днём гоняйте только изменения цен и остатков отдельными узлами — они лёгкие;
• следите за таблицей b_xml_tree и временными файлами в /upload/1c_catalog/: при параллельных обменах они растут быстрее.

Логи каждого профиля пишутся отдельно (__1c_exchange.log в каталоге обмена), что удобно — по имени видно, какая витрина сбоит.

Типовые ошибки при многосайтовости

Основные проблемы возникают не в самом протоколе, а в том, что настройки одного сайта незаметно влияют на другой:

• Товары гаснут после чужого обмена — общий инфоблок и включённая деактивация отсутствующих элементов. Лечится отбором в 1С и снятием флага удаления.
• Перепутаны картинки — профили указывают на один каталог загрузки. Задайте разные пути.
• Заказы уходят не в ту организацию — не выгружается реквизит сайта. Добавьте свойство «Сайт заказа».
• Дубли разделов — разные узлы 1С создают одинаковые группы в общем инфоблоке из-за несовпадения XML_ID. Держите единый источник структуры.
• Обмен «висит» — два тяжёлых профиля стартуют одновременно и упираются в лимиты PHP/памяти.

Итог

Многосайтовый обмен с 1С — это дисциплина разделения: свой профиль и узел на каждую витрину, свои типы цен, склады и каталог загрузки, а также реквизит источника в заказах. Технически всё делается штатными средствами CommerceML, но цена ошибки высока — один неаккуратный отбор гасит товары соседнего сайта. Поэтому важны продуманная структура каталога в 1С и аккуратное сопоставление данных на стороне Битрикса.

Мы в B2Bsite настраиваем такие связки под ключ: разводим каталоги, цены и заказы между сайтами, дорабатываем обработки 1С под отборы и сопровождаем обмен на проде. Если у вас несколько витрин на одной 1С — поможем собрать это без потерь данных.