При интеграции 1С с интернет-магазином на платформе 1С-Битрикс часто возникает задача передачи дополнительных характеристик товара, таких как цвет, размер, бренд или материал. Однако после добавления новых реквизитов в справочник Номенклатура на стороне 1С они либо не выгружаются на сайт, либо попадают в системный список «Реквизиты» (CML2_TRAITS), вместо того чтобы стать полноценными свойствами инфоблока для фильтрации и фасетного поиска.
Разберем архитектурные причины такого поведения стандарта CommerceML и рассмотрим практические способы решения задачи.
Проанализируем структуру обмена данными в формате CommerceML (файлы import.xml):
<ЗначенияРеквизитов>): сюда попадают системные и стандартные поля объекта (например, вес, артикул, код, базовая единица измерения). На стороне Битрикса эти данные записываются в единое множественное свойство с кодом CML2_TRAITS. Такие значения сложно использовать в умном фильтре каталога без дополнительной обработки.<ЗначенияСвойств>): сюда попадают пользовательские характеристики. Чтобы значение появилось в этом блоке, в секции <Классификатор> пакета выгрузки обязательно должно присутствовать описание свойства с уникальным идентификатором (GUID), наименованием и типом данных.Если добавить новый реквизит напрямую в дерево метаданных конфигурации 1С (в справочник Номенклатура), типовой модуль обмена не знает о его существовании и либо игнорирует его, либо помещает в общий массив реквизитов.
Наиболее простое и универсальное решение, не требующее доработки кода конфигурации, — использование типового функционала подсистемы «Свойства» (План видов характеристик ДополнительныеРеквизитыИСведения).
Выполним следующие шаги:
Типовой модуль интеграции 1С-Битрикс автоматически считывает план видов характеристик, формирует их описание в классификаторе XML и передает значения товаров в блоке <ЗначенияСвойств>. На сайте автоматически создаются одноименные свойства инфоблока, готовые к использованию в фильтрах.
Если реквизиты уже созданы в структуре метаданных справочника и переносить их в состав дополнительных реквизитов нецелесообразно, проверим возможности используемого модуля интеграции.
Разберем порядок действий:
В этом случае модуль обмена самостоятельно сгенерирует для реквизита идентификатор GUID в секции классификатора и поместит его данные в блок значений свойств каждого товара.
Если используется полностью самописная подсистема обмена или нетиповой алгоритм выгрузки, доработаем процедуры формирования XML-пакета.
Для корректной передачи свойства необходимо реализовать две процедуры:
<Свойство>, в котором указать уникальный идентификатор (GUID), наименование и тип («Строка» или «Число»).<ЗначенияСвойств>, связав его по ранее определенному GUID со значением реквизита текущей номенклатуры.Выясним, как связать свойство на сайте с данными из 1С:
XML_ID).XML_ID на сайте должно в точности совпадать с тегом <Ид> этого свойства в файле import.xml.GUID свойства из 1С (или из выгруженного XML-файла) и укажем его в поле Внешний код в параметрах свойства инфоблока.После создания новых свойств или заполнения реквизитов существующие позиции номенклатуры не регистрируются как измененные автоматически. Чтобы данные ушли на сайт, инициируем отправку:
УзелОбмена = ПланыОбмена.ОбменССайтом.НайтиПоНаименованию("Выгрузка на сайт");
Если ЗначениеЗаполнено(УзелОбмена) Тогда
ПланыОбмена.ЗарегистрироватьИзменения(УзелОбмена, Метаданные.Справочники.Номенклатура);
КонецЕсли;
После регистрации изменений следующий сеанс обмена передаст все обновленные значения реквизитов на сайт.