Вариации товаров (цвет, размер) в каталоге 1С-Битрикс

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

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

Что такое вариации и торговые предложения

Вариация товара — это конкретный продаваемый вариант одной и той же модели, отличающийся значениями одной или нескольких характеристик: цветом, размером, объёмом, комплектацией. Модель «Футболка Classic» существует в вариантах «синяя M», «синяя L», «чёрная M» и так далее. Каждый такой вариант — отдельная единица склада с собственным артикулом, ценой и остатком, но с точки зрения покупателя это всё та же футболка.

В 1С-Битрикс вариации реализуются через торговые предложения — их же в обиходе называют SKU (Stock Keeping Unit, складская учётная единица) или офферами. Технически это отдельный информационный блок, жёстко связанный с инфоблоком товаров: каждое торговое предложение «привязано» к своему родительскому товару. Товар выступает витринной сущностью — у него общее описание, фотографии модели, категория и SEO; предложение выступает торговой сущностью — у него артикул, цена, остаток и значения осей вариаций.

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

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

Архитектура: товар + инфоблок предложений

Чтобы настраивать вариации осознанно, держите в голове двухуровневую модель каталога. В 1С-Битрикс это два связанных информационных блока внутри одного торгового каталога.

• Инфоблок товаров. Родительский уровень. Хранит витринную информацию: название модели, описание, картинки, раздел каталога, общие свойства (бренд, материал, сезон), SEO-метатеги.
• Инфоблок торговых предложений (SKU). Дочерний уровень. Каждый элемент — это конкретная вариация, привязанная к товару через служившее свойство-связку. Хранит оси вариаций (цвет, размер), артикул, штрихкод.
• Модуль «Торговый каталог». Навешивает на предложения цены (в том числе несколько типов цен), остатки по складам, единицы измерения и НДС.
• Компонент карточки catalog.element. Собирает витрину: показывает данные товара и селекторы вариаций, подтягивая цену и остаток выбранного SKU.
• Компонент списка catalog.section. Выводит каталог, умеет показывать «есть в других цветах» и агрегировать доступность предложений к товару.
• Умный фильтр catalog.smart.filter. Фильтрует товары по свойствам их предложений через фасетный индекс.

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

Свойства SKU: цвет, размер и другие оси

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

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

Цвет — особый случай. Голого текста «синий» покупателю мало, ему нужен визуальный образец. В Битрикс для этого у свойства-списка есть дополнительные поля: можно привязать к каждому значению файл-картинку (сваток ткани) или задать HEX-код фона. Тогда компонент карточки рисует не подпись, а кружок нужного цвета — это и красивее, и понятнее, особенно когда оттенков много.

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

Единая карточка и выбор вариации

Единая карточка — это то, ради чего вообще затевают торговые предложения. Вместо россыпи страниц-клонов покупатель видит одну карточку модели, а цвет и размер выбирает переключателями. При смене вариации карточка мгновенно обновляет цену, остаток, артикул и, если настроено, главную фотографию — без перезагрузки страницы.

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

Хорошая карточка вариаций подчиняется нескольким принципам:

• Всегда выбран валидный вариант. При открытии карточки по умолчанию должна быть выбрана существующая и, желательно, доступная вариация — чтобы кнопка «В корзину» работала сразу.
• Недоступное — видно, но выключено. Размеры, которых нет для выбранного цвета, лучше не прятать, а гасить: покупатель понимает, что модель бывает в L, просто сейчас его нет.
• Цвет меняет фото. Если у SKU разных цветов свои картинки, переключение цвета должно менять галерею — это резко повышает доверие.
• Корзина знает точный SKU. В корзину кладётся конкретное торговое предложение, а не «товар вообще», иначе склад и 1С не поймут, что именно продано.

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

Остатки и цены по каждой вариации

Самое частое заблуждение новичка — считать, что остаток и цена принадлежат товару. В модели с торговыми предложениями это не так: и остаток, и цена принадлежат предложению. У «синей M» восемь штук на складе за 1 490 ₽, у «чёрной L» три штуки за 1 590 ₽, а «синей XL» может не быть вовсе. Родительский товар сам по себе не продаётся — он лишь агрегирует доступность своих SKU.

Из этого вытекают практические следствия:

• Доступность товара — это ИЛИ по предложениям. Товар считается «в наличии», если есть хотя бы одно доступное предложение. Если распроданы все SKU — товар показывается как отсутствующий.
• Цена «от». В списке каталога у модели с разными ценами SKU обычно показывают минимальную цену с приставкой «от». В карточке цена уточняется после выбора вариации.
• Складской учёт ведётся по SKU. Списание при заказе, резервирование и обмен остатков с 1С работают на уровне торговых предложений по артикулу или внешнему коду.
• Несколько типов цен и складов. Модуль торгового каталога позволяет держать у одного SKU розничную и оптовую цену и остатки по разным складам одновременно.

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

Матрица цвет × размер и «висящие» комбинации

Как только осей становится две, ассортимент удобно представлять матрицей: цвета по строкам, размеры по столбцам. На пересечении — либо реальный SKU с остатком, либо пустая ячейка (такой комбинации нет). Эта матрица — самый наглядный способ увидеть, что происходит с моделью.

Ключевая проблема любой матрицы — «висящие» комбинации. У модели есть синий и чёрный цвета, есть размеры M, L, XL. Но синий XL никогда не завозили, а чёрный M закончился. Если карточка показывает все размеры активными для любого цвета, покупатель выберет несуществующий синий XL, нажмёт «В корзину» и получит ошибку. Это классический путь к брошенной корзине.

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

Из матрицы видно и то, как выстраивать логику интерфейса: «нет SKU» — вариант, которого не существует, его комбинацию нужно блокировать жёстко; «нет в наличии» — вариант существует, но временно распродан, его показываем неактивным с возможностью подписки на поступление. Разделять эти два состояния важно и для покупателя, и для аналитики закупок.

Вариации через SKU или отдельные товары

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

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

Настройка торговых предложений пошагово

1. Включите торговые предложения у инфоблока. В настройках инфоблока каталога («Торговый каталог» → вкладка «Торговый каталог») включите использование торговых предложений. Битрикс создаст связанный инфоблок SKU.
2. Создайте оси вариаций. В инфоблоке предложений добавьте свойства «Цвет» и «Размер» типом «Список». Для цвета включите доп. поля — файл-образец или HEX-фон.
3. Задайте порядок значений. Отсортируйте размеры логически (S, M, L, XL), а не по алфавиту; цветам задайте образцы.
4. Наполните предложения. Для каждой модели заведите SKU по существующим комбинациям цвет × размер, проставьте артикулы, цены и остатки. Несуществующие комбинации не создавайте.
5. Настройте карточку. В компоненте catalog.element включите вывод торговых предложений, укажите свойства-селекторы (цвет, размер) и вид их отображения.
6. Включите умную фильтрацию по SKU. На свойствах предложений «Цвет» и «Размер» поставьте флаг «Участвует в умной фильтрации» и постройте фасетный индекс.
7. Проверьте на боевых данных. Прокликайте вариации: цена и остаток переключаются, недоступные комбинации гаснут, в корзину уходит правильный SKU, фильтр по цвету находит модели.

Как это выглядит в админке 1С-Битрикс

Торговые предложения редактируются на карточке товара в админке: под основными полами модели появляется таблица её SKU с осями вариаций, ценой и остатком. Схематично интерфейс выглядит так:

Практический порядок работы в админке такой. Сначала на инфоблоке каталога включается режим торговых предложений — это разовое действие. Затем в инфоблоке предложений создаются свойства-оси. После этого на каждой карточке товара становится доступна таблица SKU, где менеджер добавляет реально существующие комбинации. Цена и остаток проставляются на вкладке «Торговый каталог» каждого предложения, а при подключённом обмене — приходят из 1С автоматически, и руками их трогать уже не нужно.

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

Почти все каталоги с вариациями наполняются не руками, а обменом с «1С:Управление торговлей» или другой учётной системой. Здесь важно понимать, как соотносятся сущности. В 1С «характеристики номенклатуры» (цвет, размер) при выгрузке в Битрикс превращаются в торговые предложения. Каждая характеристика становится отдельным SKU со своим артикулом, ценой и остатком.

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

• Стабильный XML_ID. Внешние коды товара и предложений должны быть постоянными между выгрузками. Обычно это GUID номенклатуры и характеристики из 1С.
• Оси приходят из характеристик. Значения свойств «Цвет» и «Размер» на предложениях формируются из характеристик номенклатуры — следите, чтобы справочники значений совпадали.
• Остатки — отдельным пакетом. В коммерческой информации остатки часто идут отдельным файлом и чаще, чем каталог; настройте их регулярную выгрузку.
• Цены по типам. Розничная и оптовая цены выгружаются как разные типы цен и ложатся на те же SKU.

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

Вариации в умном фильтре и поиске

Вариации нужны не только в карточке — покупатель хочет отфильтровать весь каталог «покажи всё синее в размере L». Это работает через умный фильтр, но с важной оговоркой: фильтруемые свойства цвета и размера живут на уровне торговых предложений, а не товаров. Значит, умную фильтрацию нужно включать именно на инфоблоке предложений, а фасетный индекс — строить с учётом SKU.

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

Несколько практических моментов:

• Не дублируйте оси на двух уровнях. Если цвет — свойство предложения, не заводите такое же свойство на товаре. Дубль путает счётчики фильтра.
• Стройте фасет после наполнения SKU. Массовая заливка предложений обменом требует полного перестроения фасетного индекса, иначе фильтр не увидит новые вариации.
• Показывайте «есть в других цветах». В списке каталога полезно выводить мини-свотчи доступных цветов прямо на плитке товара — это повышает кликабельность.

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

UX выбора цвета и размера в карточке

Технически исправная карточка вариаций может всё равно плохо продавать, если выбор неудобен. UX выбора цвета и размера — отдельная дисциплина, и мелочи здесь решают конверсию.

1. Цвет — образцом, не текстом. Кружки-свотчи с реальным цветом или фактурой ткани понятнее, чем список «Синий, Индиго, Бирюзовый». Для сложных оттенков добавляйте подпись при наведении.
2. Размер — крупными кнопками. Выпадающий список размеров хуже, чем ряд кнопок: покупатель видит сразу весь размерный ряд и что доступно.
3. Недоступное гасите, а не прячьте. Перечёркнутый или приглушённый размер сообщает «бывает, но сейчас нет» и удерживает интерес.
4. Таблица размеров рядом. Ссылка «Таблица размеров» у селектора размеров снимает главный страх онлайн-покупки одежды и обуви и снижает возвраты.
5. Смена цвета меняет фото. Переключил на чёрный — галерея показала чёрную модель. Это резко повышает доверие к карточке.
6. Уведомление о поступлении. Для распроданных вариаций дайте кнопку «Сообщить, когда появится» — вы удержите спрос и соберёте данные для закупок.

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

SEO, дубли и микроразметка вариаций

Главный SEO-выигрыш вариаций мы уже назвали: единая карточка вместо десятка дублей под каждый цвет. Но чтобы этот выигрыш не превратился в проблему, нужно правильно обойтись с индексацией и разметкой.

• Одна каноническая карточка на модель. Смена вариации в карточке не должна порождать отдельный индексируемый URL под каждый цвет с GET-параметрами. Если параметры цвета попадают в адрес, канонизируйте их на основную карточку.
• Посадочные под цвет — осознанно. Иногда под «платье синее» есть реальный поисковый спрос, и тогда отдельная страница оправдана. Но делают её точечно и с уникальными метатегами, а не автоматически под каждую вариацию.
• Микроразметка товара. В schema.org/Product вариации удобно описывать через offers: у товара несколько предложений с ценой и доступностью. Так поисковик видит и диапазон цен, и наличие размеров.
• Наличие в разметке. Прокидывайте в разметку реальную доступность SKU (InStock/OutOfStock), чтобы сниппет не обещал того, чего нет на складе.

Отдельно проследите за пагинацией и сортировкой каталога с вариациями — они, как и на любом каталоге, способны плодить дубли. Осмысленные комбинации фильтра по цвету/размеру можно отдавать как ЧПУ-посадочные под спрос, а всё остальное держать на GET-параметрах и канонизировать. Тонкости индексации фильтруемых страниц — это уже тема рубрики SEO и продвижение.

Производительность на больших матрицах

Пока у модели три-четыре SKU, о производительности можно не думать. Но на каталоге, где у каждой из тысяч моделей матрица 8 цветов × 6 размеров, число торговых предложений исчисляется сотнями тысяч, и это уже нагрузка. Вот на что смотреть.

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

Частые ошибки при настройке

• Делают каждый цвет отдельным товаром вместо торговых предложений — получают дубли, каннибализацию SEO и ручную синхронизацию описаний.
• Заводят цвет и размер строкой, а не списком — «Синий», «синий» и «СИНИЙ» становятся тремя разными вариациями и ломают фильтр.
• Показывают все размеры активными для любого цвета — покупатель выбирает несуществующую комбинацию и упирается в ошибку корзины.
• Прячут распроданные размеры полностью — теряют SEO-сигнал и не понимают, каких вариаций не хватает клиентам.
• Хранят остаток и цену на товаре, а не на предложении — теряют точный складской учёт и корректный обмен с 1С.
• Дублируют ось «цвет» на уровне и товара, и предложения — счётчики умного фильтра начинают противоречить друг другу.
• Правят руками цены и остатки, которые приходят обменом с 1С — следующая выгрузка перезаписывает правки.
• Не перестраивают фасетный индекс после массовой заливки SKU — фильтр по цвету и размеру не находит новые вариации.

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

Сведём всё в практический список, по которому удобно принимать готовность вариаций перед запуском:

1. Торговые предложения включены. На инфоблоке каталога активирован режим SKU, создан связанный инфоблок предложений.
2. Оси типизированы. Цвет и размер — свойства-списки на уровне предложений; у цвета заданы образцы, у размеров — логичный порядок.
3. SKU заведены по факту. Созданы только реально существующие комбинации, у каждой — артикул, цена и остаток.
4. Карточка переключает вариации. Выбор цвета и размера меняет цену, остаток, фото; недоступные комбинации гаснут; в корзину уходит конкретный SKU.
5. Остатки и цены — на предложениях. Складской учёт и типы цен настроены на уровне SKU, распроданное показывается неактивным.
6. Умная фильтрация по SKU. На свойствах предложений включён фасет, индекс построен, фильтр по цвету/размеру находит модели.
7. Обмен с 1С согласован. Стабильные внешние коды, совпадающие справочники осей, остатки и цены приходят автоматически.
8. SEO под контролем. Одна каноническая карточка на модель, микроразметка offers с наличием, дубли по параметрам канонизированы.

Вывод

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