В B2B сайт без учётной системы — витрина без товара. Оптовый клиент должен видеть свою цену по договору, реальный остаток на складе, откуда ему отгрузят, и получить заказ, который тут же попадёт в 1С для обработки. Всё это уже живёт в учётной системе, и задача интеграции — аккуратно перенести эту сложность на сайт, не потеряв и не упростив её.
В этой статье разберём, как выстроить интеграцию B2B-магазина на 1С-Битрикс с 1С и учётными системами: как работает штатный обмен CommerceML, почему в опте его часто мало, как передавать цены по группам, остатки по складам и заказы контрагентов. Настроить и отладить этот обмен помогает автоматизация на 1С.
Коротко
- Источник истины в B2B — 1С: цены, остатки, договоры ведутся там, сайт их отображает и принимает заказы.
- Штатный обмен CommerceML 2.x закрывает каталог, цены и остатки, но для опта его часто дополняют.
- B2B-специфика — цены по группам и договорам, остатки по складам, привязка заказов к контрагентам.
- Тяжёлый каталог выгружают по расписанию, а остатки и заказы — оперативнее, нередко через REST.
Зачем B2B-магазину интеграция с 1С
Оптовый бизнес почти всегда ведёт учёт в 1С: номенклатуру, цены, договоры с контрагентами, остатки по складам, отгрузки. Сайт в этой картине — не отдельная система, а канал продаж, который должен показывать те же данные и возвращать заказы туда, где их обрабатывают. Ручное перенесение данных между сайтом и 1С в опте невозможно: объёмы и частота изменений слишком велики.
Поэтому интеграция для B2B — не «приятная опция», а фундамент. Без неё клиент видит устаревшие цены и остатки, менеджеры дублируют заказы руками, а ошибки множатся. С хорошей интеграцией сайт становится продолжением учётной системы: клиент видит своё, заказ уходит в работу автоматически, менеджер занимается продажей, а не перепечатыванием.
Штатный обмен CommerceML
1С-Битрикс и 1С исторически «дружат»: между ними есть штатный обмен на стандартном формате CommerceML 2.x. Работает он по понятной схеме: 1С выгружает данные в XML, сайт их загружает, а заказы уходят обратно тем же каналом.
- Каталог. Номенклатура, свойства, изображения, разделы выгружаются на сайт в инфоблоки торгового каталога.
- Цены. Типы цен переносятся и сопоставляются с ценами на сайте.
- Остатки. Складские остатки выгружаются для отображения наличия.
- Заказы. Оформленные на сайте заказы возвращаются в 1С для обработки.
Для типового розничного магазина этого механизма часто достаточно без единой строчки кода. Именно поэтому связка Битрикс и 1С удобна по умолчанию. Базовую механику обмена мы подробно разбираем и в других материалах; здесь важно понять, что для B2B этот фундамент есть, но его, как правило, приходится достраивать.
Чем B2B-обмен сложнее
Опт добавляет к обмену слой сложности, которого нет в рознице. Недостаточно выгрузить «каталог и остаток» — нужно перенести всю логику работы с контрагентами.
| Аспект | Розница | B2B |
|---|---|---|
| Цены | Одна витринная | По группам, договорам, индивидуальные |
| Остатки | Общий остаток | В разрезе складов клиента |
| Клиент | Физлицо | Контрагент с договором и лимитом |
| Заказ | Простая покупка | Привязка к договору, условия отгрузки |
| Видимость | Всё открыто | Цены и товары зависят от клиента |
Вся эта сложность уже описана в 1С — задача интеграции не упростить её, а корректно перенести на сайт. Поэтому B2B-обмен почти всегда выходит за рамки коробочного сценария и требует настройки соответствий и, нередко, доработки.
Цены по группам и договорам
Цена в B2B — не публичное число, а функция от того, кто смотрит. У дилера одна цена, у крупного опта — другая, у нового клиента — третья, а у отдельных контрагентов действуют индивидуальные соглашения. Всё это ведётся в 1С через типы цен и договорённости с контрагентами.
На сайте этому соответствуют типы цен и группы пользователей. При обмене цены выгружаются по типам, а авторизованный клиент видит цену своей группы или своё индивидуальное соглашение. Критично, чтобы соответствие групп на сайте и типов цен в 1С было настроено однозначно — иначе клиент увидит чужую или неверную цену. А для закрытых оптовых цен гостю их не показывают вовсе: неавторизованный посетитель видит либо розницу, либо приглашение войти.
Остатки в разрезе складов
В рознице обычно хватает общего остатка «есть/нет». В распределённом опте этого мало: один и тот же товар может быть на московском складе и отсутствовать на региональном, а клиенту важно видеть наличие именно там, откуда ему отгрузят.
Поэтому остатки выгружают в разрезе складов, а на сайте привязывают к региону и складу клиента. Тогда закупщик видит не «вообще на остатках», а реальную доступность для своей отгрузки. Это влияет и на поиск, и на карточку, и на корзину. Актуальность остатков особенно чувствительна: устаревший остаток в опте — это сорванная отгрузка. Держать остатки и продажи в синхроне помогает автоматизация продаж и склада на 1С.
Контрагенты, договоры, лимиты
Оптовый клиент на сайте — не безымянное физлицо, а контрагент с историей, договором и условиями. Эта связка должна отражаться в интеграции, иначе личный кабинет опта превращается в обычную розничную корзину.
- Контрагент. Клиент на сайте связан с контрагентом в 1С — со своими реквизитами и историей.
- Договор. Условия, цены и лимиты действуют в рамках договора, а не «вообще».
- Кредитный лимит. Доступная сумма отгрузки и задолженность приходят из 1С и влияют на оформление.
- Взаиморасчёты. Баланс, акты сверки, история отгрузок — то, что опт хочет видеть в кабинете.
Полноценный оптовый кабинет с контрагентами, договорами и лимитами — отдельная задача поверх обмена. Данные для неё приходят из 1С, а логика отображения и оформления живёт на сайте.
Заказы обратно в 1С
Обмен — это дорога в обе стороны. Заказ, оформленный на сайте, должен уйти в 1С со всей B2B-спецификой: привязкой к контрагенту и договору, ценами по соглашению, нужным складом отгрузки, кратностью и условиями. Просто «список товаров и сумма» в опте не годятся.
Хорошо настроенная передача заказов избавляет менеджеров от ручного переноса и ошибок: заказ сразу попадает в работу с правильным контрагентом и условиями. Здесь же важно корректно обрабатывать статусы — подтверждение, резерв, отгрузку — и возвращать их на сайт, чтобы клиент видел актуальное состояние заказа в кабинете. Логику сохранения и обработки этих данных на стороне сайта удобно строить на современном ORM — подход разобран в статье про D7 и ORM в Битрикс.
Расписание против реального времени
Частый вопрос — как часто обмениваться данными. Универсального ответа нет: разные данные требуют разной оперативности, и правильная схема почти всегда комбинированная.
- Каталог и свойства. Меняются редко — выгрузка по расписанию, например ночью, вполне достаточна.
- Цены. Обновляются по расписанию несколько раз в день или по событию изменения.
- Остатки. В опте хотят видеть оперативно — чаще, чем каталог, вплоть до близкого к реальному времени.
- Заказы и статусы. Желательно оперативно в обе стороны, чтобы клиент и менеджер видели актуальное.
Тяжёлый каталог гонять в реальном времени бессмысленно и вредно для нагрузки. Разумный подход — комбинировать: каталог и цены по расписанию, а остатки и заказы — чаще или через отдельный оперативный канал.
Когда нужен REST поверх обмена
Штатный CommerceML хорош для каталога, но для оперативных сценариев его нередко дополняют обменом через REST API и вебхуки. Это оправдано, когда возможностей стандартного обмена не хватает.
- Оперативные остатки. Нужна близкая к реальному времени актуальность склада, а не выгрузка раз в несколько часов.
- Нестандартная логика. Сложные правила цен, договоров и лимитов, не укладывающиеся в стандартный формат.
- Несколько систем. Обмен не только с 1С, но и с другими учётными или складскими системами.
- События. Мгновенная реакция на изменение статуса заказа или остатка через вебхуки.
Часто оптимальна гибридная схема: штатный CommerceML для тяжёлого каталога плюс REST для оперативных данных. При этом обменные каналы нужно защищать — открытый API с доступом к ценам, остаткам и заказам это лакомая цель. О том, как это делать правильно, — в материале про REST, вебхуки и безопасность в Битрикс.
Большие объёмы и стабильность
Оптовые каталоги нередко насчитывают десятки и сотни тысяч позиций, и наивный «выгрузить всё разом» на таких объёмах падает по памяти или таймауту. Стабильный обмен на объёме требует нескольких приёмов.
- Пошаговый обмен. Выгрузка и загрузка частями, чтобы не упираться в лимиты за один проход.
- Только изменения. Обмен изменёнными позициями вместо полной выгрузки каждый раз.
- Окно низкой нагрузки. Тяжёлые операции выносятся на время наименьшего трафика.
- Настройка сервера. Лимиты памяти и времени, индексы, ресурсы под обмен.
Стабильность обмена на объёме напрямую зависит от инфраструктуры, поэтому её планируют вместе с интеграцией, а не после. Вопросы сервера и производительности разобраны в статье про инфраструктуру на BitrixVM. А чтобы изменения интеграции безопасно доезжали на боевой сайт, полезен налаженный процесс деплоя.
Частые ошибки
- Неоднозначное соответствие цен. Группы на сайте и типы цен в 1С сопоставлены криво — клиент видит чужую цену.
- Общий остаток вместо складского. В опте важно наличие по складу клиента, а показывают «вообще».
- Закрытые цены видны гостю. Оптовые цены показаны неавторизованному посетителю.
- Заказы без B2B-специфики. В 1С уходит «список и сумма» без договора, склада и условий.
- Всё в реальном времени. Тяжёлый каталог гоняют постоянно, перегружая сервер.
- Полная выгрузка на объёме. Нет пошагового обмена и обмена изменениями — падения по таймауту.
- Незащищённый REST. Открытый обменный API без авторизации и ограничений — риск утечки цен и данных.
- Правят сайт вместо 1С. Проблемы данных чинят на витрине, а источник истины остаётся кривым.
Чек-лист внедрения
- Роли определены. 1С — источник данных, сайт — витрина и приём заказов; ответственность разделена.
- Каталог обменивается. Номенклатура, свойства, изображения корректно приходят через CommerceML.
- Цены по группам. Типы цен 1С однозначно сопоставлены группам клиентов; закрытые цены скрыты от гостя.
- Остатки по складам. Наличие выгружается в разрезе складов и привязано к региону клиента.
- Контрагенты и договоры. Клиент связан с контрагентом, действуют договор и лимиты.
- Заказы в 1С. Уходят с договором, складом и условиями; статусы возвращаются на сайт.
- Расписание настроено. Каталог по расписанию, остатки и заказы — оперативно, REST где нужен.
- Объём выдержан. Пошаговый обмен, обмен изменениями, инфраструктура под нагрузку, защита каналов.
Вывод
Интеграция с 1С — фундамент B2B-магазина, а не дополнение к нему. Штатный обмен CommerceML даёт хорошую базу для каталога, цен и остатков, но опт добавляет слой сложности: цены по группам и договорам, остатки по складам, привязку заказов к контрагентам и лимитам. Задача интеграции — корректно перенести эту сложность из учётной системы на сайт.
Держитесь принципа «1С — источник истины, сайт — витрина и приём заказов», комбинируйте расписание с оперативным обменом, дополняйте CommerceML через REST там, где нужна скорость, и планируйте инфраструктуру под объём. Тогда сайт станет продолжением учётной системы: клиент видит своё, заказы уходят в работу автоматически, а менеджеры занимаются продажами, а не ручным переносом данных.
