Проектирование торговых предложений (SKU) 1С-Битрикс

Проектирование торговых предложений (SKU) 1С-Битрикс

Торговые предложения в Битрикс — это механизм, позволяющий одному товару иметь несколько вариантов с разными ценами, остатками и характеристиками. Звучит просто, но реализация этого механизма вызывает больше вопросов на практике, чем любая другая часть каталога. Как разграничить свойства товара и свойства предложения? Как корректно настроить фильтрацию по атрибутам SKU? Почему после настройки обмена с 1С предложения дублируются? Ответы на эти вопросы — в архитектурных решениях, принятых при проектировании.

Техническая схема SKU в Битрикс

Торговое предложение в Битрикс — это элемент отдельного инфоблока, привязанный к родительскому товару из основного инфоблока каталога. В базе данных:

• b_iblock_element — товар в основном инфоблоке (родитель, тип TYPE_PRODUCT)
• b_iblock_element — предложение в инфоблоке офферов (тип TYPE_OFFER)
• b_catalog_product.OWNER_ID — связь предложения с родительским товаром
• b_catalog_price — цена на уровне предложения
• b_catalog_store_amount — остатки на складах на уровне предложения

Настройка связи: Контент → Каталог → [инфоблок] → Настройки → Торговые предложения. Здесь указывается инфоблок офферов и свойство-связка (CML2_LINK или кастомное свойство типа «Привязка к элементам инфоблока»).

Разграничение свойств: товар vs. предложение

Самая критичная проектная задача. Правило: свойство принадлежит предложению, если его значение влияет на цену или остаток, или если оно уникально для конкретного варианта.

Примеры:

• Свойства товара: название, описание, бренд, категория, изображения, технические характеристики (не варьируемые)
• Свойства предложения: цвет, размер, объём, комплектация, артикул (SKU-код), штрихкод, изображение варианта

Ошибка — поместить цвет и размер в свойства родительского товара: тогда невозможно отфильтровать «синие платья размера M», потому что эти атрибуты не связаны с остатками и ценой конкретного варианта.

Компонент bitrix:catalog.element и отображение SKU

Стандартный компонент карточки товара bitrix:catalog.element поддерживает отображение торговых предложений: переключение вариантов, динамическое обновление цены и изображения через AJAX-запрос к методу CatalogElementComponent.getProductData. При проектировании важно понимать, что этот компонент делает отдельный запрос за данными предложений — значит, они должны быть правильно структурированы и кешированы.

Если предложений у товара много (50+), стандартный компонент может генерировать тяжёлые запросы. Решение: ленивая загрузка вариантов через REST или принудительное ограничение количества отображаемых предложений с «показать больше».

Фильтрация по свойствам предложений

Стандартный компонент bitrix:catalog.smart.filter умеет фильтровать по свойствам инфоблока офферов — для этого в настройках компонента нужно указать OFFER_IBLOCK_ID. Но фасетный индекс строится отдельно для инфоблока офферов и для основного инфоблока. Чтобы фильтр по цвету показывал только товары, у которых есть вариант нужного цвета — фасет должен быть включён именно на инфоблоке офферов.

Сложный случай: фильтр по свойству товара И по свойству предложения одновременно. Стандартный фасет не поддерживает cross-iblock фильтрацию «из коробки» — нужна кастомная доработка компонента фильтра.

Обмен с 1С и торговые предложения

В CommerceML 2 торговые предложения передаются в секции ЗначенияРеквизитов с атрибутом характеристики. Стандартный обмен Битрикс умеет создавать и обновлять предложения из выгрузки 1С. Критичные точки:

• XML-ID предложения должен быть уникальным и стабильным между обменами
• Если 1С меняет идентификаторы характеристик — предложения дублируются вместо обновления
• Изображения предложений передаются отдельно от изображений товара

При проектировании нужно согласовать с командой 1С формат XML-ID предложений до начала разработки.

Кейс: мебельный магазин с 14 000 SKU

Магазин мягкой мебели. 1 200 моделей, каждая в 8–20 вариантах ткани/цвета. Суммарно 14 000 торговых предложений.

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

Корректное решение:

1. Цвет и материал перенесены в свойства инфоблока офферов
2. Фасетный индекс настроен на инфоблоке офферов
3. В компоненте раздела добавлена проверка: товар показывается в результатах фильтра только если у него есть предложение с остатком > 0 И с нужным цветом
4. Изображения вариантов — в свойстве предложения, изображение модели — в родительском товаре

После переноса: корректная фильтрация, «нет в наличии» по конкретным вариантам без скрытия товара целиком.

Состав работы по проектированию SKU

• Анализ вариативности товаров: какие атрибуты варьируются
• Проектирование разграничения свойств товар/предложение
• Настройка связи инфоблоков (основной + офферы)
• Планирование фасетного индекса для инфоблока офферов
• Маппинг полей CommerceML для корректного обмена с 1С
• Схема отображения SKU на карточке товара
• Тестирование сценариев фильтрации после настройки

Срок: 3–8 рабочих дней в зависимости от сложности вариативности и требований к фильтрации.