Каталог для разнотипных товаров: как организовать

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

В чём сложность разнотипного каталога

В 1С-Битрикс структура характеристик задаётся на уровне инфоблока: набор свойств (PROPERTY_*) общий для всех его элементов. Это удобно, пока товары однородны. Как только в одном инфоблоке оказываются, скажем, бытовая техника и одежда, свойства начинают конфликтовать.

• Часть свойств пустует у половины товаров — карточка выглядит незаполненной, а в детальном виде торчат лишние строки.
• Умный фильтр показывает нерелевантные параметры: фильтр «Размер обуви» в разделе телевизоров.
• Обмен с 1С через CommerceML валит все свойства в один список, и сопоставление полей усложняется.

Поэтому вопрос «один инфоблок или несколько» — не про удобство, а про то, где именно физически хранятся разные наборы характеристик.

Один инфоблок или несколько

Это ключевая архитектурная развилка. У обоих подходов есть цена, и выбирать нужно осознанно.

Практическое правило: если типов 2–4 и они кардинально разные (техника vs. услуги), берите отдельные инфоблоки. Если типов много, но они близки (разная электроника), удобнее один инфоблок с разбивкой по разделам и группировкой свойств.

Разделы и наборы свойств

Даже внутри одного инфоблока Битрикс позволяет управлять свойствами по-разному для разных разделов. В умном фильтре (bitrix:catalog.smart.filter) параметры настраиваются отдельно для каждого раздела: заходите в раздел «Ноутбуки» и включаете только релевантные свойства, а в «Краски» — свои.

Сами свойства создаются в Контент → Инфоблоки → Типы свойств карточки инфоблока. Полезные приёмы для разнотипного каталога:

• Свойства типа «Справочник» (Highload-блок) — вместо списка внутри инфоблока выносите значения (цвета, бренды) в отдельный HL-блок, чтобы переиспользовать их между типами товаров.
• Умные группы свойств — в детальной карточке (bitrix:catalog.element) через параметр вывода группируйте характеристики, чтобы у каждого товара показывались только заполненные.
• Обязательность по разделу задать штатно нельзя — если нужно, контролируйте заполнение на этапе выгрузки из 1С или обработчиком события OnBeforeIBlockElementUpdate.

Торговые предложения для разных типов

Отдельная тонкость — торговые предложения (SKU). Инфоблок предложений привязан к инфоблоку товаров один-к-одному, и его свойства тоже общие. Если у одежды есть «Размер» и «Цвет», а у книги предложений нет вовсе, в инфоблоке SKU появятся свойства, нужные лишь части товаров.

• Товары без вариаций (книга, услуга) просто не имеют торговых предложений — это нормально, каталог их отдаёт как простые товары.
• Свойства предложений, влияющие на выбор SKU, помечайте флагом участия в умном фильтре и в выборе предложения в карточке.
• Если наборы вариаций у разных типов конфликтуют слишком сильно, это ещё один аргумент за отдельные инфоблоки — у каждого будет свой инфоблок предложений.

Помните: цена, остаток, единица измерения и другие торговые поля живут в модуле catalog и одинаковы для любого типа товара — их дублировать не нужно.

Разнотипность и обмен с 1С

В 1С разные товары обычно относятся к разным видам номенклатуры, и у каждого свой набор характеристик. При выгрузке в Битрикс по CommerceML 2 характеристики превращаются в свойства инфоблока.

• При схеме «один инфоблок» все характеристики из 1С сливаются в общий список свойств — следите, чтобы одноимённые характеристики разных видов не пересекались по смыслу.
• При схеме «несколько инфоблоков» настраивается несколько правил обмена или фильтрация по группам/видам номенклатуры, чтобы каждый вид попадал в свой инфоблок.
• Внешние коды (XML_ID) должны быть стабильны: именно по ним обмен находит и обновляет товары, разделы и свойства.

Единый вывод и навигация

Пользователю каталог должен казаться цельным независимо от того, сколько инфоблоков под ним. Инструменты Битрикс это позволяют.

• Общий раздел меню и хлебные крошки — навигацию стройте по разделам, а не по инфоблокам; посетитель не должен догадываться о внутренней структуре.
• Поиск модуля search индексирует все инфоблоки сразу, поэтому единая строка поиска работает поверх разнотипного каталога без доработок.
• Для сводных витрин («Хиты», «Новинки») используйте компоненты с выборкой по нескольким инфоблокам или собственный CIBlockElement::GetList с массивом IBLOCK_ID.

Шаблон карточки товара делайте адаптивным к набору свойств: выводите блок характеристик циклом по фактически заполненным полям, а не жёстко перечисляйте свойства — тогда один шаблон обслужит и ноутбук, и услугу.

Итог

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

Если каталог разрастается и структура начинает мешать фильтру, обмену или скорости, мы помогаем спроектировать инфоблоки под реальный ассортимент — в рамках разработки на 1С-Битрикс и настройки интеграции с 1С, чтобы разнотипный каталог оставался управляемым и быстрым.