Вы запускаете интернет-магазин на 1С-Битрикс с сотнями вариаций товаров: диваны в 20 цветах, кроссовки 10 размеров, ноутбуки с разным объёмом памяти. Стандартная схема инфоблоков часто не учитывает особенности многовариантного каталога, что приводит к проблемам при масштабировании. Фильтр по параметрам должен показывать только то, что есть в наличии, а обмен с 1С — не плодить дубликатов.
Если на этом этапе допустить ошибку в проектировании SKU, последствия аукнутся на производительности и точности остатков. Каждый лишний запрос к базе снижает скорость отклика, а неверная связка предложений порождает дубли. Мы проектируем торговые предложения (SKU) так, чтобы фильтрация работала мгновенно, а остатки не дублировались.
Наш опыт — десятки проектов с тысячами вариантов товаров. Мы знаем, как правильно разграничить свойства товара и предложения, настроить фасетный индекс и организовать стабильный обмен с 1С. Оценим ваш проект под ключ за 3–8 дней — просто свяжитесь с нами. Получите консультацию, и мы разберём вашу структуру каталога.
Техническая схема SKU в Битрикс
Торговое предложение — элемент инфоблока офферов, привязанный к родительскому товару. В БД:
-
b_iblock_element— товар (типTYPE_PRODUCT) -
b_iblock_element— предложение (типTYPE_OFFER) -
b_catalog_product.OWNER_ID— связь -
b_catalog_price— цена на уровне предложения -
b_catalog_store_amount— остатки
Термин SKU (Stock Keeping Unit) используется для однозначной идентификации варианта. Настройка связи: Контент → Каталог → [инфоблок] → Торговые предложения. Компонент catalog.element отображает карточку товара; он должен корректно выбирать активное предложение.
Как правильно разграничить свойства товара и предложения?
Главное правило: свойство относится к предложению, если его значение меняет цену или остаток. Например:
- Свойства товара: название, описание, бренд, категория, базовые изображения.
- Свойства предложения: цвет, размер, объём, артикул, штрихкод, изображение варианта.
Ошибка — поместить цвет в товар: тогда невозможно отфильтровать «синие платья 42 размера», так как остатки привязаны к предложению.
| Тип свойства | Примеры | Влияет на цену/остаток |
|---|---|---|
| Товара | Бренд, категория, описание | Нет |
| Предложения | Цвет, размер, артикул | Да |
Почему фильтрация по свойствам предложений тормозит?
Стандартный компонент bitrix:catalog.smart.filter умеет фильтровать по свойствам офферов, но фасетный индекс строится отдельно. Если у товара 50+ предложений, запросы могут быть тяжёлыми. Кастомная фильтрация с правильным фасетом работает в 2–3 раза быстрее. Сложный случай — одновременная фильтрация по свойствам товара и предложения: стандартный фасет не поддерживает cross-iblock. Нужна доработка компонента, например, кастомный фильтр с предварительным агрегированием.
Для больших каталогов (сотни тысяч SKU) мы используем фасетный индекс с предварительным агрегированием. Это даёт прирост скорости на 40% по сравнению со стандартным решением. Наш опыт подтверждает: грамотное проектирование фильтра окупается на этапе нагрузки. Экономия бюджета на доработках может достигать 30%.
Как избежать дублирования SKU при обмене с 1С?
В CommerceML предложения передаются в ЗначенияРеквизитов. Критично: XML-ID должен быть уникален и стабилен. По документации 1С-Битрикс, даже однократное изменение идентификатора ведёт к дублированию. Согласуйте формат с командой 1С до старта.
| Проблема | Решение |
|---|---|
| Дубли товаров при повторной выгрузке | Стабильный XML-ID, уникальный для каждой характеристики |
| Неверный маппинг свойств | Согласовать схему с 1С заранее |
| Потеря связи товар-предложение | Правильная настройка свойства-связки (CML2_LINK) |
Кейс из нашей практики: мебельный магазин с 14 000 SKU
Мы настраивали каталог для магазина мягкой мебели: 1 200 моделей, каждая в 8–20 вариантах ткани — итого 14 000 предложений. После первичной настройки фильтр по цвету показывал товары, у которых цвет был в свойстве родительского товара, а не предложения. Диван «Марко» с цветом «бежевый» отображался, даже если все бежевые варианты распроданы. Решение:
- Перенесли цвет и материал в инфоблок офферов.
- Настроили фасетный индекс на инфоблоке предложений.
- В компонент раздела добавили проверку: товар показывается, только если есть предложение с остатком > 0 и нужным цветом.
- Изображения вариантов — в свойстве предложения, модели — в товаре.
После доработки фильтрация заработала корректно, а «нет в наличии» отображается по конкретным вариантам без скрытия товара. Экономия времени на обработку запросов — 40%. Гарантируем, что ваш каталог будет работать без сбоев. Стоимость владения каталогом снижается на 20% за счёт правильной архитектуры.
Что входит в работу по проектированию SKU
Полный список этапов
- Анализ вариативности товаров и выделение свойств предложений.
- Проектирование разграничения: какие атрибуты — товарные, какие — офферные.
- Настройка связи инфоблоков и свойства-связки.
- Планирование фасетного индекса для корректной фильтрации.
- Маппинг полей CommerceML для стабильного обмена с 1С.
- Схема отображения SKU на карточке товара.
- Тестирование всех сценариев фильтрации и отображения.
Наша команда имеет опыт в разработке на 1С-Битрикс, реализовали более 30 проектов с торговыми предложениями. Получите консультацию — свяжитесь с нами для анализа вашего проекта.