← На главную

При интеграции интернет-магазина на платформе 1С-Битрикс с конфигурацией 1С:Управление торговлей 10.3 часто возникает задача: в учетной системе товар ведется как одна позиция номенклатуры с характеристиками по двум свойствам (например, Цвет и Размер), а на сайте необходимо отображать отдельные карточки для каждого цвета (например, «Носки синие» и «Носки черные»), внутри которых покупатель может выбрать только размер.

Разберем причины возникновения этой сложности и проанализируем доступные способы решения.

Архитектурные ограничения типового обмена CommerceML

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

1. Двухуровневая модель каталога: Стандартный протокол обмена CommerceML и архитектура инфоблоков Битрикса поддерживают только связь вида Товар → Торговое предложение (SKU). Промежуточный уровень иерархии (Товар → Цвет → Размер) в стандартной структуре отсутствует.
2. Привязка по уникальным идентификаторам (GUID): Каждая номенклатура 1С становится ровно одним элементом основного инфоблока каталога. Все комбинации характеристик выгружаются в подчиненный инфоблок торговых предложений со ссылкой на исходный GUID товара (поле CML2_LINK).
3. Схлопывание карточек: Если выгружать все характеристики как SKU, в каталоге будет отображаться только одна общая карточка («Носки»), внутри которой придется выбирать и цвет, и размер. Если же попытаться средствами сайта разбить характеристики на отдельные товары, стандартная пошаговая синхронизация перезапишет структуру при следующем обмене.

Рассмотрим основные способы реализации требуемой логики каталога.

Способ 1. Модификация модуля выгрузки и загрузки заказов в 1С (виртуальное разделение)

Это классический путь, позволяющий не менять принципы ведения складского учета в 1С и сохранить типовую логику работы интернет-магазина.

Разберем по шагам логику доработки модуля обмена в 1С:

1. Формирование виртуальных товаров: При формировании выгрузки в XML-файл номенклатура группируется по уникальным значениям свойства «Цвет». Для каждого цвета формируется отдельный узел товара каталога. К наименованию номенклатуры динамически добавляется название цвета.
2. Генерация составного идентификатора: Чтобы сайт воспринимал каждую цветовую вариацию как самостоятельный товар, формируется составной внешний код, например: GUIDТовара_GUIDЦвета.
3. Формирование предложений: Торговые предложения (размеры) привязываются к соответствующему составному коду родительского цвета.
4. Обработка входящих заказов: При получении заказов с сайта в модуле загрузки реализуется обратное сопоставление: составной код парсится, и в документ ЗаказПокупателя подставляются исходная номенклатура и соответствующая характеристика.

Способ 2. Изменение методологии учета номенклатуры в 1С

Если доработка программного кода выгрузки нежелательна, задачу можно решить методологически на уровне ведения справочников в 1С:

1. Разделение позиций номенклатуры: В справочнике Номенклатура позиции заводятся отдельно под каждый цвет («Носки синие», «Носки черные»).
2. Упрощение характеристик: В характеристиках номенклатуры оставляется только одно свойство — Размер.
3. Группировка на сайте: Чтобы объединить разные цвета одной модели на витрине сайта, для номенклатуры в 1С заполняется общее дополнительное свойство (например, «Артикул модели» или «Коллекция»). На стороне сайта в карточке товара настраивается переключатель цветов, который ведет ссылками на соседние товары каталога с тем же значением общего свойства.

Способ 3. Визуальное разделение торговых предложений на стороне сайта (Frontend)

При этом подходе обмен данными и структура в 1С остаются полностью типовыми, а логика отображения переопределяется в компонентах Битрикса:

1. Кастомизация выборки списка: Компонент каталога (bitrix:catalog.section) модифицируется таким образом, чтобы в списке товаров выводились не сами родительские элементы, а торговые предложения, сгруппированные по уникальному значению свойства Цвет.
2. Отображение в каталоге: Покупатель видит в общем списке товаров отдельные плитки для каждого цвета.
3. Карточка товара: При переходе в карточку конкретного цвета в блоке выбора SKU выводятся только те размеры, которые соответствуют выбранному цвету.

Способ 4. Постобработка каталога на стороне Битрикса (обработчики событий импорта)

Выгрузка из 1С передается в стандартном виде, а трансформация данных выполняется на сайте после завершения импорта XML:

1. Перехват события: В local/php_interface/init.php настраивается перехват события окончания импорта каталога (OnSuccessCatalogImport1C).
2. Перераспределение элементов: Пользовательский скрипт обходит торговые предложения, создает в основном инфоблоке недостающие карточки товаров под каждый цвет и перепривязывает к ним предложения по значению свойства CML2_LINK.
3. Важный нюанс: При таком подходе необходимо контролировать обновление цен и остатков, так как штатный обмен может перезаписывать измененные привязки при последующих сеансах синхронизации.

Резюме: Наиболее надежным и масштабируемым решением для высоконагруженных проектов является доработка модуля выгрузки в 1С с формированием составных идентификаторов (Способ 1), либо вывод торговых предложений на уровне шаблонов сайта (Способ 3).