Управление вариациями товара (размер, цвет, комплектация)

Одна футболка бывает в пяти размерах и трёх цветах — это пятнадцать реальных позиций на складе, но для покупателя это один товар, у которого он хочет выбрать «свой» вариант. Как показать это правильно? Плохое решение — завести пятнадцать отдельных карточек, которые дробят каталог и путают. Хорошее — вести вариации через торговые предложения, объединяя их в одну карточку с раздельным учётом.

В этой статье разберём управление вариациями товара в 1С-Битрикс предметно: как устроены торговые предложения (SKU), чем они лучше отдельных карточек, как вести цены и остатки по каждому варианту, показывать выбор в карточке и не создавать недоступные комбинации. И почему источник вариаций почти всегда — учётная система, а качество каталога держится на обмене и автоматизации продаж и склада на 1С.

Что такое вариации и зачем они нужны

Вариация — это конкретное исполнение товара, которое покупатель выбирает: размер одежды, цвет техники, комплектация набора, объём упаковки. С точки зрения покупателя это один товар с выбором, с точки зрения склада — набор разных позиций с собственными артикулами, ценами и остатками.

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

Торговые предложения (SKU) в 1С-Битрикс

Механизм вариаций в 1С-Битрикс называется торговыми предложениями. Устроен он так: есть инфоблок товаров (родителей) и связанный с ним инфоблок торговых предложений. Товар-родитель хранит общее — название, описание, категорию, — а каждое торговое предложение представляет конкретный вариант со своими свойствами и параметрами.

• Товар-родитель. Общая карточка: название, описание, изображения, принадлежность к разделу.
• Торговое предложение (SKU). Конкретный вариант: размер M, цвет синий, со своим артикулом.
• Свойства-варианты. Характеристики, различающие предложения: размер, цвет, комплектация.
• Параметры SKU. Цена, остаток, вес и другие данные ведутся по каждому предложению.

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

Вариации против отдельных карточек

Соблазн завести отдельную карточку на каждый вариант велик — кажется, что так проще. На деле это почти всегда ошибка. Сравним подходы.

Отдельные карточки оправданы редко — когда варианты по сути разные товары (например, принципиально разные модели). В остальных случаях торговые предложения лучше по всем осям: для покупателя, для SEO, для учёта и для поддержки.

Свойства-варианты: размер, цвет, комплектация

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

1. Выделите различающие свойства. Размер, цвет, объём, комплектация — то, что покупатель реально выбирает.
2. Отделите от общих характеристик. Материал или бренд, единые для всех вариантов, — свойства родителя, а не предложения.
3. Задайте типы отображения. Цвет удобно показывать плашкой-свотчем, размер — кнопками, комплектацию — списком.
4. Согласуйте с 1С. Свойства-варианты должны соответствовать характеристикам номенклатуры в учёте.

Цены и остатки по каждому SKU

Главное преимущество торговых предложений — раздельный учёт цен и остатков. Это не косметика, а основа корректной торговли вариативным товаром.

• Своя цена у каждого варианта. Размер XXL может стоить дороже, комплект «макси» — иметь свою цену.
• Типы цен для групп. У каждого SKU могут быть разные цены для розницы и оптовых групп клиентов.
• Остаток по складам. Синий заканчивается, красный в наличии — учёт ведётся по каждому предложению.
• Актуальность из обмена. Цены и остатки по SKU, как правило, приходят из 1С и обновляются автоматически.

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

Выбор варианта в карточке товара

Карточка — место, где вариации встречаются с покупателем. От того, как устроен выбор, зависит, купит он или уйдёт в замешательстве. Хорошая карточка вариативного товара делает выбор очевидным.

• Понятные переключатели. Размеры кнопками, цвета свотчами, комплектация списком — без догадок.
• Обновление цены и наличия. При выборе варианта сразу меняются цена, артикул, остаток и изображение.
• Изображения под вариант. Выбор синего показывает синий товар, а не общее фото.
• Кнопка в корзину — по SKU. В корзину уходит именно выбранное предложение, а не абстрактный товар.

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

Недоступные комбинации и наличие

Одна из самых частых и болезненных ошибок — позволять покупателю выбрать комбинацию, которой нет. Если синего в размере XL не бывает, эта комбинация не должна выглядеть доступной. Иначе покупатель выбирает несуществующий вариант и упирается в ошибку при оформлении — раздражение и потерянный заказ.

Правильная карточка опирается на остатки по SKU и подсказывает доступность: доступные сочетания активны, отсутствующие — заблокированы или помечены как «под заказ». Это делается на основе данных о наличии по каждому предложению. Корректность здесь снова упирается в обмен: если остатки по SKU приходят из 1С с ошибками, подсказки наличия будут врать. Про устойчивость такого обмена мы писали в статье про REST, вебхуки и безопасность интеграций.

Вариации, умный фильтр и поиск

Вариации влияют не только на карточку, но и на навигацию по каталогу. Свойства торговых предложений обычно участвуют в умном фильтре catalog.smart.filter, чтобы покупатель отбирал товары нужного размера или цвета.

• Фильтр по свойствам SKU. Отбор по размеру и цвету работает через свойства предложений.
• Логика показа товара. Товар попадает в выдачу, если хотя бы одно его предложение подходит под фильтр.
• Поиск по артикулу варианта. У каждого SKU свой код, и точный поиск должен учитывать их.
• Согласованность данных. Свойства для фильтра и для карточки должны быть заведены единообразно.

Поиск по коду конкретного варианта — отдельная важная тема для каталогов с большим числом SKU, особенно в B2B, где закупщик ищет по артикулу предложения напрямую.

Обмен с 1С: источник вариаций

В большинстве проектов вариации не заводятся вручную на сайте, а приходят из учётной системы. Номенклатура с характеристиками, цены и остатки по каждому варианту ведутся в 1С и передаются на сайт при обмене CommerceML, превращаясь в товары и торговые предложения.

Отсюда важное следствие: структура вариаций на сайте должна соответствовать тому, как характеристики устроены в 1С. Если в учёте размер и цвет — это характеристики номенклатуры, то на сайте они должны стать свойствами торговых предложений с корректным сопоставлением. Рассогласование ломает обмен: варианты дублируются, теряются или путаются. Поэтому проектирование вариаций начинают с того, как устроен товар в 1С, а не наоборот.

Комбинаторный взрыв и как его избежать

Технически 1С-Битрикс позволяет использовать несколько свойств-вариантов одновременно, но здесь подстерегает комбинаторный взрыв. Три свойства по пять значений дают 125 предложений на один товар — это тяжело вести и в учёте, и на сайте, и в интерфейсе выбора.

1. Используйте минимум свойств. Только те, что реально различают товар для покупателя и учёта.
2. Не создавайте несуществующие комбинации. Заводите только те SKU, что есть или бывают на складе.
3. Следите за производительностью. Тысячи предложений на товар бьют по скорости карточки и фильтра.
4. Пересматривайте структуру. Если вариантов слишком много, возможно, часть — это разные товары.

Частые ошибки с вариациями

• Отдельные карточки на каждый вариант. Дробят каталог, распыляют SEO, путают покупателя.
• Общие свойства как варианты. Материал или бренд заведены как SKU-свойство и плодят лишние предложения.
• Доступные несуществующие комбинации. Покупатель выбирает то, чего нет, и упирается в ошибку.
• Цена и наличие не обновляются. При выборе варианта данные не меняются, покупатель дезориентирован.
• Рассогласование с 1С. Структура вариаций не соответствует характеристикам в учёте, обмен ломается.
• Комбинаторный взрыв. Слишком много свойств-вариантов, тысячи SKU, тормоза и хаос.
• Нет свойств вариантов в фильтре. Покупатель не может отобрать товар по размеру или цвету.

Чек-лист внедрения

1. Модель выбрана верно. Вариации ведутся торговыми предложениями, а не отдельными карточками.
2. Свойства разделены. Различающие — у предложений, общие — у родителя.
3. Цены и остатки по SKU. Каждый вариант имеет свою цену и остаток по складам.
4. Карточка удобна. Переключатели понятны, цена, наличие и фото обновляются при выборе.
5. Недоступное помечено. Несуществующие комбинации заблокированы по остаткам.
6. Обмен согласован. Структура вариаций соответствует характеристикам в 1С.
7. Комбинаций не слишком много. Используется минимум свойств, нет лишних SKU.

Вывод

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

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