Торговые предложения Битрикс: настройка SKU, свойств и вывода в каталоге

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

Как устроены торговые предложения в Битрикс

Механизм построен на двух информационных блоках. Первый - «Товары», в нём лежат карточки в привычном виде: название, описание, характеристики, фото. Второй - инфоблок торговых предложений, в нём для каждого товара создаётся одна или несколько записей с конкретным набором характеристик: скажем, «Кроссовки Х, размер 42, чёрные». Именно запись из второго инфоблока и есть SKU - тот объект, который реально попадает в корзину, списывается со склада и продаётся по конкретной цене.

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

Настройка SKU: привязка инфоблоков и мастер торговых предложений

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

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

Свойства для торговых предложений: цвет, размер и привязка к элементам

Характеристики, по которым отличаются варианты - цвет, размер, объём, комплектация - заводятся как свойства инфоблока предложений, а не товара. Это принципиально: если цвет повесить на товар, у карточки будет один цвет на все размеры сразу, и витрина не сможет показать переключение между вариантами.

Списки и справочники

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

Артикул, штрихкод и остаток на уровне SKU

Артикул, штрихкод, вес и остаток на складе логично держать на предложении, а не на товаре: у чёрной пары 42 размера и белой пары 38 размера разные штрихкоды и разные остатки, даже если это один и тот же товар в карточке. Цена точно так же считается для каждого SKU отдельно, с учётом типов цен и скидок, поэтому один товар продаётся по разным ценам в зависимости от комплектации, без отдельной карточки на каждый вариант.

Вывод торговых предложений в каталоге и на карточке товара

На карточке товара за отображение вариантов отвечает шаблон компонента каталога: можно вывести список торговых предложений выпадающим списком, кнопками-прямоугольниками с превью цвета, или обычным списком с ценой и остатком у каждой строки. Выбор шаблона зависит от количества свойств-вариаций: если у товара всего один параметр выбора (например, только размер), удобнее плоский список; если варианты комбинируются по двум осям (цвет и размер), лучше работает связка «сначала цвет прямоугольниками, потом доступные размеры для выбранного цвета».

Цена «от» и умный фильтр

В разделе каталога, где выводится список товаров, а не карточка одного товара, обычно показывается минимальная цена среди всех предложений товара с пометкой «от». Это поведение настраивается в компоненте раздела каталога и не требует доработки шаблона, если сразу выбрать нужный режим отображения цены.

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

Синхронизация и импорт торговых предложений

Если каталог ведётся в 1С, торговые предложения приходят в Битрикс через стандартный обмен CommerceML: 1С экспортирует товары и предложения отдельными сущностями, и при настроенном обмене Битрикс сам раскладывает их по двум инфоблокам, сохраняя привязку. На моей практике основная работа тут не в самом обмене, а в сопоставлении справочников характеристик: если в 1С цвет и размер хранятся как текстовые значения, а в Битриксе как элементы highload-блока, при первой синхронизации нужно явно сопоставить значения, иначе после обмена появятся дубли вроде «Черный» и «чёрный» как разные варианты цвета.

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

Типичные проблемы при работе с торговыми предложениями

Из того, что регулярно всплывает на аудитах и доработках чужих каталогов:

• Дублирующиеся предложения после повторного импорта - если импорт запускается без проверки на существующий код предложения, вместо обновления цены создаётся вторая запись с тем же товаром и теми же характеристиками.
• Медленная карточка товара при большом числе вариаций - если у товара под сотню предложений с несколькими свойствами каждое, компонент карточки перебирает и рендерит их все разом. Помогает включённое кеширование результатов компонента и ограничение набора свойств, которые реально показываются в шаблоне выбора.
• Показ вариантов, которых нет в наличии - без явной настройки компонент показывает все предложения товара, включая закончившиеся, из-за чего покупатель выбирает недоступный размер и видит ошибку только в корзине. Настраивается это на уровне параметров компонента и логики скрытия предложений с нулевым остатком.

Когда каталог разрастается за пределы пары тысяч товаров с предложениями, а витрину и админку под него никто изначально не проектировал, дешевле не латать компонент за компонентом, а один раз пересобрать структуру каталога и импорт с нуля. Этим у меня в основном и заканчивается интернет-магазин под ключ для клиентов, которые приходят с самодельным Excel-каталогом на десятки тысяч строк.

1С-Битрикс регулярно обновляется, поэтому перед внедрением я сверяюсь с актуальной документацией.

Частые вопросы

Можно ли обойтись без торговых предложений, если у товара один вариант

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

Почему у товара пропала цена после добавления торговых предложений

Обычно потому что цена осталась только на старой карточке товара, а модуль каталога после перевода на SKU берёт цену уже с предложений. Нужно проверить, что у каждого предложения товара заполнен хотя бы один тип цены - без этого карточка в каталоге будет показывать пустую цену, даже если у товара она физически заполнена.

Что делать, если умный фильтр не показывает цвет и размер

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

Как перенести существующий каталог на торговые предложения без потери остатков и цен

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