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

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

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

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

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

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

Почему нельзя обойтись плоскими товарами? Технически можно, но каждая вариация станет отдельной карточкой, и тогда: во-первых, каталог раздувается в разы и засоряется дублями; во-вторых, поисковые системы получают десятки почти идентичных страниц, которые конкурируют между собой; в-третьих, покупатель вынужден листать «Футболка синяя S», «Футболка синяя M» вместо одного удобного выбора. Торговые предложения решают все три проблемы разом: одна карточка для человека и поисковика, но точный складской учёт по каждой вариации внутри.

Когда нужны вариации, а когда нет

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

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

Два инфоблока: товары и предложения

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

• Инфоблок товаров (родительский). Хранит витринные карточки: название, детальное описание, анонс, общие свойства (бренд, коллекция, состав), картинки модели. Здесь же лежат SEO-поля товара.
• Инфоблок торговых предложений (дочерний). Хранит элементы-вариации. У каждого элемента есть служебное свойство-привязка к родительскому товару и «различающие» свойства — размер, цвет, объём. Цена, остаток, вес, артикул и штрихкод тоже живут здесь, на уровне SKU.

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

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

Как связаны товар и его SKU

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

Из этой архитектуры вытекает несколько практических вещей, которые важно держать в голове:

• SKU без родителя «не существует» для витрины. Если у предложения потеряна привязка (например, товар удалили, а оффер остался), оно повиснет в инфоблоке офферов и не покажется ни в одной карточке. Такие «сироты» стоит регулярно чистить.
• Удаление товара удаляет и его предложения. В типовой логике при удалении родителя дочерние офферы тоже убираются, чтобы не плодить осиротевшие SKU.
• Товар знает своих детей через выборку. Компоненты каталога, получая товар, отдельным запросом подтягивают связанные предложения по CML2_LINK и формируют массив офферов для карточки.
• Внешние коды важнее внутренних ID. При обмене с 1С связь восстанавливается не по внутренним ID Битрикса (они у разных сайтов разные), а по внешним кодам XML_ID, которые приходят из 1С и остаются стабильными.

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

Свойства предложений: размер, цвет, артикул

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

Свойства-«различители» (размер, цвет, объём)

Свойства, по которым покупатель выбирает вариацию, почти всегда должны быть типа «Список» или «Привязка к highload-справочнику». Строку тут использовать нельзя: она плохо группируется, порождает дубли значений («Синий» / «синий» / «СИНИЙ») и не даёт удобно рисовать переключатели. Для цвета часто заводят highload-справочник с дополнительным полем «HEX-код» или картинкой-образцом, чтобы в карточке показывать не текст, а цветные плашки.

Служебные складские свойства

На уровне SKU также живут артикул, штрихкод и вес. Артикул в типовом каталоге — это отдельное строковое поле товара (CATALOG_QUANTITY и артикул относятся к карточке товара торгового каталога), которое у офферов заполняется для каждой вариации. Штрихкод хранится в отдельной сущности штрихкодов, привязанной к элементу каталога. Вес и габариты нужны для расчёта доставки и тоже задаются на уровне предложения, потому что «M» и «XXL» вполне могут весить по-разному.

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

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

1. Включите торговый каталог для инфоблока. В настройках торгового каталога отметьте инфоблок товаров как «Торговый каталог», чтобы у элементов появились цена, остаток и складские поля.
2. Активируйте торговые предложения. В том же окне включите опцию «Торговые предложения» и укажите инфоблок офферов — существующий или создаваемый. Битрикс автоматически заведёт свойство-привязку CML2_LINK.
3. Заведите различающие свойства. В инфоблоке предложений создайте свойства «Размер» и «Цвет» типа «Список» (или привязку к highload-справочнику). Наполните списки значений заранее и без дублей.
4. Отметьте свойства для карточки. Укажите, какие свойства офферов участвуют в выборе вариации, чтобы шаблон карточки строил из них переключатели.
5. Включите умную фильтрацию. У свойств, по которым будут фильтровать (размер, цвет), поставьте флаг «Участвует в умной фильтрации» и постройте фасетный индекс.
6. Заполните вариации. Создайте предложения вручную или загрузите их обменом с 1С. Проверьте, что у каждого SKU заданы значения различающих свойств, цена и остаток.
7. Настройте карточку и список. В компоненте catalog.element включите вывод предложений и укажите свойства для выбора; при необходимости покажите SKU-переключатели и в списке (catalog.section).
8. Проверьте покупку. Убедитесь, что без выбора вариации кнопка «В корзину» неактивна, а после выбора в корзину падает конкретный SKU с верной ценой и остатком.

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

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

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

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

За вывод карточки товара отвечает компонент bitrix:catalog.element. Когда у товара есть предложения, компонент получает не только сам товар, но и массив его офферов с их свойствами, ценами и остатками, а также «дерево предложений» — структуру, по которой фронтенд понимает, какие комбинации свойств существуют и какому SKU соответствуют.

Дальше работает шаблон карточки. Он рисует переключатели по различающим свойствам — кнопки размеров, образцы цветов — и вешает на них JavaScript. При выборе значения скрипт вычисляет подходящий SKU и обновляет на странице цену, старую цену и скидку, остаток и статус наличия, артикул, а часто и фотогалерею. Кнопка «В корзину» до выбора вариации либо неактивна, либо при клике подсвечивает незаполненные свойства — иначе система не знает, какой именно SKU продавать.

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

Матрица «размер × цвет» и JS-логика

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

Технически фронтенд оперирует «деревом предложений» — картой всех реальных комбинаций. По ней скрипт умеет:

• Гасить недоступные значения. Если для выбранного цвета нет размера L, кнопка «L» становится неактивной или помечается «нет в наличии».
• Автоматически доуточнять выбор. Если после выбора цвета остаётся единственный размер, его можно выбрать автоматически.
• Подставлять данные SKU. Как только комбинация однозначно определяет предложение, обновляются цена, остаток, артикул и картинки.
• Отражать выбор в URL. Часто выбранную вариацию прокидывают в адрес (через хеш или параметр), чтобы ссылкой можно было поделиться и попасть сразу на нужный SKU.

Картинки и галерея у предложений

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

На практике удобно придерживаться такой логики отображения:

1. Основной источник — картинки предложения. Если у выбранного SKU есть свои фотографии, галерея показывает их.
2. Запасной источник — картинки товара. Если у оффера фото не заданы, подставляются изображения родительской модели, чтобы галерея не пустовала.
3. Превью в списке — по «главному» SKU. В плитке каталога у товара с вариациями показывают либо картинку модели, либо изображение первого доступного предложения.

Отдельная тонкость — вес страницы. У товара с десятью цветами может быть под сотню фотографий, и грузить их все сразу не нужно. Изображения неактивных вариаций подгружают лениво (lazy-load) или по факту переключения цвета. Это заметно влияет на скорость карточки и метрики Core Web Vitals, особенно на мобильных.

Цены и остатки по SKU

Одно из главных следствий торговых предложений: цена и остаток живут на уровне SKU, а не товара. Это правильно и удобно, но требует аккуратности в настройке и выводе.

Цены

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

Частый вопрос — как показать цену в списке каталога, где вариация ещё не выбрана. Обычно выводят диапазон («от 1 490 ₽») или цену «главного»/минимального предложения. Диапазон честнее для покупателя, но требует, чтобы шаблон умел собирать минимум и максимум по офферам товара.

Остатки

Остаток тоже привязан к SKU. Товар считается доступным, пока в наличии есть хотя бы одна вариация. Это порождает три состояния, которые карточка должна корректно отражать: вариация в наличии, вариация закончилась (но товар в целом ещё доступен в других вариантах), товар недоступен целиком. При включённом учёте остатков и запрете продажи «в минус» Битрикс не даст добавить в корзину SKU с нулевым остатком.

Если магазин работает с несколькими складами, остаток по SKU может складываться из остатков на разных складах, и тогда в карточке уместно показывать доступность по точкам выдачи. Это уже логика складского учёта Битрикса, но начинается она всё равно с того, что базовая единица остатка — торговое предложение.

Артикулы и штрихкоды вариаций

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

Артикул. Каждая вариация должна иметь собственный артикул. В идеале он осмысленный и читаемый: BS-M-BL сразу говорит «Basic, размер M, цвет blue». Артикул используется в трёх местах: складской учёт и обмен с 1С, поиск по каталогу (менеджеры и B2B-клиенты ищут именно по артикулам) и оформление документов. Как настроить быстрый и точный поиск по артикулам для оптовых клиентов, мы подробно разбираем в статье про поиск по артикулу в B2B.

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

Торговые предложения в умном фильтре

Фильтровать одежду «по размеру» покупатель хочет так, чтобы в выдаче остались модели, у которых есть нужный размер в наличии. А размер лежит в предложениях. Значит, умный фильтр должен уметь фильтровать по свойствам офферов и показывать при этом родительские товары. Битрикс это поддерживает, и настраивается такая связка через фасетный индекс.

Порядок действий тот же, что и для обычных свойств, но с оглядкой на уровень:

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

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

Обмен с 1С: как приходят вариации

В большинстве проектов торговые предложения не заводят руками — они приезжают из 1С по обмену. Понимать этот механизм полезно, потому что 80% проблем с SKU в боевых магазинах родом именно из обмена.

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

1. Приходит каталог (import). Товары и их характеристики выгружаются с уникальными кодами XML_ID. Битрикс создаёт элементы в двух инфоблоках и проставляет привязку офферов к товарам по этим кодам.
2. Приходят цены и остатки (offers). Отдельным пакетом 1С передаёт цены и количество по каждой характеристике. Битрикс раскладывает их по соответствующим SKU, находя их снова по XML_ID.
3. Синхронизируются свойства. Значения характеристик (размер, цвет) сопоставляются со значениями свойств-списков на сайте. Если значения ещё нет, оно создаётся.
4. Обновляется фасет. После крупного обмена фасетный индекс перестраивают, иначе фильтр по размерам и цветам покажет устаревшую картину.

Главный источник боли — нестабильные или пустые коды характеристик в 1С. Если у характеристики нет уникального кода или он меняется между выгрузками, Битрикс при каждом обмене будет создавать новые SKU вместо обновления старых. Результат — размножившиеся дубли предложений, съехавшие остатки и «потерянные» привязки. Поэтому первое, что проверяют при разборе проблем с вариациями, — стабильность и уникальность кодов номенклатуры и характеристик на стороне 1С.

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

SEO вариаций товара

Торговые предложения влияют на SEO двояко, и оба эффекта важно держать под контролем.

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

Риск: выбор вариации не должен плодить дубли. Если переключение размера или цвета меняет URL (через параметр или хеш), важно, чтобы поисковик не индексировал каждую комбинацию как отдельную страницу. Обычно основной URL карточки остаётся каноническим, а вариации переключаются на клиенте без создания новых индексируемых адресов, либо параметры вариаций закрываются от индексации.

Отдельная возможность — посадочные страницы под вариации, у которых есть спрос. Если по запросу «купить синюю футболку basic» есть трафик, из фильтра «цвет = синий» можно сделать отдельную SEO-страницу с ЧПУ и своими метатегами — так же, как это делается для фасетной навигации. Но плодить такие страницы стоит только под реальный спрос, иначе получите тысячи тонких страниц-дублей. Баланс между «открыть под спрос» и «закрыть мусор» — ключевая SEO-задача каталога с вариациями.

Несколько свойств и сложные наборы

Пока свойство одно (только размер), всё просто. Как только их становится два и больше, появляются нюансы, которые стоит спроектировать заранее.

• Полнота матрицы. Далеко не все комбинации существуют. Из 4 размеров и 3 цветов теоретически 12 SKU, но реально может быть 8 — остальных просто нет. Карточка должна корректно гасить несуществующие пересечения, а не показывать «пустые» вариации.
• Порядок выбора. Решите, какое свойство выбирается первым. Обычно сначала цвет (он часто определяет фотографии), потом размер. От порядка зависит, как гасятся недоступные значения.
• Разные наборы у товаров группы. Если у части моделей вариации по «размеру», а у части — по «размеру и росту», шаблон карточки и фильтр усложняются. Старайтесь держать единый набор свойств внутри категории.
• Число вариаций. Товар с 50–100 SKU (например, обувь с полноразмерной сеткой в нескольких цветах) — это уже нагрузка и на карточку, и на обмен. Такие случаи проектируют отдельно, с ленивой подгрузкой и аккуратным деревом предложений.

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

Производительность при большом числе SKU

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

Общий принцип тот же, что и для любого большого каталога на Битриксе: опираться на кэш и заранее просчитанные структуры, а тяжёлые операции (обмен, построение фасета, переиндексацию поиска) уводить на часы низкой нагрузки. Дополнительно помогает композитный режим сайта: статическая часть карточки и списка отдаётся мгновенно, а данные вариаций и остатки догружаются. Для магазина с большим числом SKU это ощутимо улучшает и воспринимаемую скорость, и метрики Core Web Vitals.

Фиды и выгрузки: Маркет и агрегаторы

Торговые предложения напрямую влияют на выгрузки в маркетплейсы, прайс-агрегаторы и рекламные системы. Почти все фиды (YML для Яндекса, форматы маркетплейсов) оперируют именно покупаемыми единицами — то есть SKU, а не моделями. Это значит, что в фид должна попадать каждая вариация со своим артикулом, ценой, остатком, набором параметров (размер, цвет) и, желательно, своей картинкой.

Практические требования к каталогу с SKU для корректных фидов:

• Уникальные идентификаторы. У каждого SKU — стабильный уникальный ID и артикул, иначе агрегатор будет «терять» и дублировать предложения.
• Заполненные параметры. Размер и цвет должны быть машиночитаемыми (значения списка), чтобы попасть в структурированные параметры фида, а не в текст.
• Актуальные остатки. Фид должен отдавать наличие по вариациям, иначе площадка покажет то, чего нет на складе.
• Группировка вариаций. Многие площадки умеют объединять SKU в карточку модели — для этого в фиде должна быть корректная привязка вариаций к родителю.

Если в каталоге вариации заведены аккуратно — с уникальными артикулами, нормализованными свойствами и корректной привязкой к товарам, — фиды собираются почти автоматически. И наоборот: беспорядок в SKU (дубли, пустые свойства, потерянные привязки) первым делом «всплывает» именно в выгрузках, потому что площадки к ним требовательны.

Частые ошибки

• Свойства-различители заведены строкой. «Размер» и «цвет» типа «Строка» дают дубли значений и не строят нормальные переключатели. Нужен «Список» или highload-справочник.
• Одно свойство на двух уровнях. «Цвет» и у товара, и у предложения — счётчики фильтра начинают противоречить друг другу. Держите характеристику на одном уровне.
• Кнопка «Купить» без выбора вариации. У товара с SKU покупка без выбранного предложения приводит к ошибочным заказам. Блокируйте кнопку до выбора.
• Нестабильные коды характеристик в 1С. Меняющиеся или пустые XML_ID плодят дубли офферов при каждом обмене. Коды должны быть уникальными и стабильными.
• Фасет не перестроен после загрузки вариаций. Фильтр по размерам и цветам показывает устаревшую картину. После массовых изменений SKU перестраивайте фасетный индекс.
• Осиротевшие предложения. Офферы с потерянной привязкой висят в инфоблоке и не показываются нигде. Периодически чистите SKU без родителя.
• Все картинки вариаций грузятся сразу. Сотня фото на карточке убивает скорость. Используйте ленивую подгрузку изображений неактивных вариаций.
• Единственный «фиктивный» SKU у простых товаров. Насильно заведённое одно предложение у товара без вариантов усложняет обмен и отчёты. Простой товар пусть остаётся простым.
• Диапазон цен в списке не собирается. Для товара с разными ценами вариаций в плитке показывают одну случайную цену вместо «от N ₽». Научите шаблон собирать минимум по офферам.
• Артикулы правят руками при живом обмене. Если источник артикулов — 1С, ручные правки затираются при следующей выгрузке. Меняйте в источнике.

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

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

1. SKU включены осознанно. Торговые предложения заведены там, где вариации — самостоятельные складские единицы; простые товары остались простыми.
2. Свойства на правильном уровне. Различающие характеристики (размер, цвет) — в инфоблоке предложений; общие (бренд, состав) — в товарах; дублей между уровнями нет.
3. Типы свойств корректны. Различители — «Список» или highload-справочник; значения нормализованы, без синонимов и разного регистра.
4. Привязка работает. Свойство CML2_LINK заполнено у всех офферов, «сирот» без родителя нет.
5. Карточка выбирает SKU. Переключатели вариаций рисуются, недоступные комбинации гасятся, цена/остаток/артикул/галерея обновляются при выборе.
6. Покупка защищена. Без выбора вариации кнопка «В корзину» неактивна; в корзину падает конкретное предложение.
7. Цены и остатки по SKU. В карточке — цена выбранной вариации, в списке — диапазон «от»; учёт остатков настроен.
8. Фильтр видит вариации. У свойств офферов включена умная фильтрация, фасетный индекс построен и перестраивается после обмена.
9. Обмен с 1С стабилен. Коды характеристик уникальны и постоянны; после крупного обмена фасет и поиск переиндексируются.
10. Фиды корректны. В выгрузки попадает каждая вариация с уникальным артикулом, параметрами и наличием.

Словарь терминов

Вывод

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

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