Как правильно настроить выгрузку торговых предложений (SKU) из 1С на сайт Bitrix через XML?

← На главную

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

Разбор архитектуры связки «Товар — Торговое предложение»

Для того чтобы система Bitrix поняла, что перед ней не просто список товаров, а товар с набором характеристик, необходимо строго соблюдать иерархию в двух основных файлах обмена. Проанализируем назначение каждого файла в контексте SKU:

import.xml — в этом файле мы описываем «товар-контейнер» (основной товар). У него есть свой уникальный идентификатор, название, описание и общие свойства. Важно понимать: для товаров с торговыми предложениями в этом файле не указываются цены и остатки.
offers.xml — здесь перечисляются конкретные торговые предложения (варианты). Именно здесь указываются цены, склады и специфические характеристики (цвет, размер, материал), которые отличают один вариант от другого.

Правильное формирование идентификатора предложения

Ключевым моментом в связке является узел Ид. Рассмотрим стандарт, который использует Bitrix для идентификации сложного предложения. Идентификатор торгового предложения должен иметь формат:

ИД_ОСНОВНОГО_ТОВАРА#ИД_ХАРАКТЕРИСТИКИ

Разберем по шагам, как это должно выглядеть в коде XML:


<!-- Фрагмент файла import.xml -->
<Товар>
    <Ид>77a123-b456-11e1-80c1</Ид>
    <Наименование>Футболка мужская</Наименование>
    ...
</Товар>

<!-- Фрагмент файла offers.xml -->
<Предложение>
    <Ид>77a123-b456-11e1-80c1#88b234-c567-22f2-90d2</Ид>
    <Наименование>Футболка мужская (Синяя, XL)</Наименование>
    ...
</Предложение>

Важно: Часть идентификатора до знака решетки (#) должна символ в символ совпадать с идентификатором товара в файле import.xml. Если вы используете старые конфигурации (например, Бухгалтерия 1.6 на обычных формах), где нет штатных характеристик, вам необходимо генерировать вторую часть GUID программно и сохранять ее для последующих обменов, чтобы избежать дублей на сайте.

Работа с узлом ХарактеристикиТовара

Часто разработчики совершают ошибку, передавая характеристики варианта через обычные ЗначенияСвойств. Однако для корректной работы модуля торгового каталога Bitrix необходимо использовать специализированный узел ХарактеристикиТовара. Проанализируем структуру этого узла:


<ХарактеристикиТовара>
    <ХарактеристикаТовара>
        <Наименование>Цвет</Наименование>
        <Значение>Синий</Значение>
    </ХарактеристикаТовара>
    <ХарактеристикаТовара>
        <Наименование>Размер</Наименование>
        <Значение>XL</Значение>
    </ХарактеристикаТовара>
</ХарактеристикиТовара>

Если этот узел оставить пустым (<ХарактеристикиТовара/>), сайт может создать предложение, но не сможет отобразить его в блоке выбора параметров у покупателя. Именно на основе этих данных Bitrix связывает предложения с соответствующими свойствами инфоблока SKU.

Типичные ошибки при ручном написании обмена

Выясним причины, по которым варианты могут отображаться как отдельные товары, даже если формат ID кажется верным:

Наличие цены у основного товара: Если в файле import.xml или offers.xml вы передали цену для идентификатора без решетки (основного товара), Bitrix может классифицировать его как «простой товар». В этом случае все последующие предложения с решеткой могут быть проигнорированы или созданы отдельно.
Отсутствие связи инфоблоков на стороне сайта: В административной панели Bitrix необходимо убедиться, что основной каталог товаров связан с инфоблоком торговых предложений. Если обмен создается «с нуля», Bitrix должен автоматически создать эту связь при первом получении корректного файла с SKU.
Разные типы свойств: Убедитесь, что наименования характеристик (например, «Размер») в 1С и на сайте совпадают, либо настройте соответствие в параметрах модуля обмена.

Использование эталонных примеров

Для понимания того, как должна выглядеть структура в идеале, рекомендуется проанализировать код типовых модулей обмена, которые предоставляет компания Битрикс для современных конфигураций (УТ 11, ERP, УНФ). Даже если ваша база работает на обычных формах (как БП 1.6), логика формирования XML в коде модулей остается идентичной.

Посмотрим на пример логики формирования узла предложения в коде 1С:


// Пример формирования строки идентификатора
ИдентификаторТовара = Строка(ТоварСсылка.УникальныйИдентификатор());
ИдентификаторХарактеристики = Строка(ХарактеристикаСсылка.УникальныйИдентификатор());

ПолныйИдентификатор = ИдентификаторТовара + "#" + ИдентификаторХарактеристики;

ЗаписьXML.ЗаписатьНачалоЭлемента("Предложение");
    ЗаписьXML.ЗаписатьЭлемент("Ид", ПолныйИдентификатор);
    ЗаписьXML.ЗаписатьЭлемент("Наименование", СформироватьНаименованиеПредложения(ТоварСсылка, ХарактеристикаСсылка));
    ...
    // Обязательно заполняем характеристики
    ЗаписатьБлокХарактеристик(ЗаписьXML, ХарактеристикаСсылка);
ЗаписьXML.ЗаписатьКонецЭлемента();

Заключение

Подводя итог, для успешного создания вариантов товара на сайте необходимо обеспечить три условия: правильный формат ID с разделителем #, заполнение узла характеристик внутри каждого предложения и отсутствие цен/остатков у основного товара-контейнера. Тщательная проверка структуры XML на соответствие стандарту CommerceML 2.0 позволит избежать дублирования товаров и обеспечит корректную работу фильтров и выбора характеристик на стороне интернет-магазина.