Цвет и размер товара: когда нужны торговые предложения, а когда отдельные карточки

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

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

Возьмём условную толстовку «Линия». У поставщика есть песочная размера M, песочная размера L и синяя размера M. Синей размера L в ассортименте вообще нет. У каждой из трёх существующих позиций свой складской идентификатор и остаток. Покупатель выбирает цвет и размер в общей карточке, но в заказ должна попасть одна точная позиция.

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

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

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

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

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

Полезный вопрос к каждому признаку: если покупатель его изменит, что именно изменится в обязательстве магазина? Другой предмет со склада, другая работа, другая комплектация или только способ показа? Ответ связывает каталог с операциями. Красивая переключалка цвета не решает, должен ли склад резервировать отдельную позицию.

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

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

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

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

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

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

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

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

Корзина и подтверждение заказа должны сохранять выбранные признаки. Названия одной модели недостаточно, чтобы человек проверил покупку. Менеджеру и складу также нужна точная продаваемая позиция. Если после выбора двух разных размеров в корзине остаётся одна строка без различий, проблема находится на границе каталога и заказа, даже если сама карточка выглядит правильно.

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

Для пробной группы достаточно письменно зафиксировать четыре вещи: какую сущность считают общей моделью; какие записи являются продаваемыми вариантами; где находятся их постоянные идентификаторы; какая система меняет свойства и состав вариантов. Название и артикул не следует без проверки объявлять универсальным ключом: они могут меняться или повторяться.

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

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

In a clothing catalog, you might see ten identical hoodies that differ only by size. Alternatively, you can open a single card and select the required variant. Both representations can sell the product, but they rely on different data models. An error in the model will not only affect the product list: stock levels, photos, filters, and order lines will start to get mixed up.

For a store built on 1C-Bitrix: Site Management, it is useful to first separate two questions: what the shopper perceives as a single model and which specific unit the warehouse must ship. Product variants allow you to link these levels. The main card describes the model, while the variant specifies the sellable option with a particular combination of attributes. The decision to adopt this structure should be made before the mass upload of the catalog.

Let's take a hypothetical hoodie called "Line". The supplier has a beige size M, a beige size L, and a blue size M. There is no blue size L in the assortment at all. Each of the three existing items has its own warehouse identifier and stock level. The buyer selects the color and size in a single product card, but only one exact item must be added to the order.

The three offers in this example do not represent three physical items. The offer "beige, M" might have a stock of seven units. Conversely, zero stock does not necessarily cancel the offer itself: the item can remain in the assortment while awaiting delivery. The existence of a variant, its quantity, and the ability to order it are separate attributes.

In the official 1C-Bitrix model, a product variant corresponds to an assortment item (SKU). A variant may differ in size, color, capacity, and other properties. The convenience for the buyer lies in selecting the desired combination within a single model. For accounting purposes, the key point is that the selected variant can be unambiguously linked to a price, quantity, and shipment.

Generating all combinations of two colors and two sizes would have created a fourth record in our example. The system does not know that the supplier does not produce it. Therefore, the variant matrix is taken from the actual assortment, not obtained by simply multiplying property lists. An unavailable variant today and a combination that never existed must behave differently.

A property itself does not require a separate product variant. Care instructions and country of origin can describe the model as a whole. If the buyer does not select them during purchase and the warehouse does not distinguish items by them, there is no need to multiply variants. A supplier's service flag also does not become a choice in the card just because it is present in the export.

The answer regarding color depends on the business. For ready-made hoodies, color separates warehouse positions. For an item that is dyed after the order, color can be a manufacturing parameter: there is no finished stock of each combination yet. In the second case, the clothing warehouse scheme cannot be automatically transferred. Rules for ordering, price calculation, and production time suitable specifically for this process will be required.

A useful question for every attribute: if a buyer changes it, what exactly changes in the store's obligation? A different item from stock, a different service, a different configuration, or only the display method? The answer links the catalog to operations. A pretty color switcher does not determine whether the warehouse must reserve a separate item.

Different prices do not always mean different product variants. Retail and dealer prices for the same item depend on sales conditions and do not turn it into two separate items. There is no need to create a "wholesale hoodie" as a copy of the regular product just for a different price tag. First, separate the product variant from the pricing rules.

Merging is appropriate if the buyer is truly choosing a variant of a single model. But a similar name does not prove commonality. Two drills with different chucks, purposes, and compatible accessories may require independent descriptions and comparison. If important differences are hidden in a small switcher, a combined card makes selection difficult.

A boundary case is a device with varying memory capacity. For one store, these are variants of a single model: a shared chassis and purpose, with an obvious choice of capacity. For another, differences extend to the configuration and delivery terms to such an extent that independent product cards are more convenient. The decision must be justified by the assortment and shopper scenarios, not by a rule that 'all electronics must be structured identically'.

There is also a hybrid representation: variants appear as separate tiles in the list but are linked internally by a common model. This is an interface question, not a requirement to create independent products in the accounting system. The developer must verify the capabilities of the chosen solution and agree on where each tile leads and which variant will be selected. The catalog view and storage structure are related but not identical.

Independent search demand for color or size should be investigated separately. It cannot be considered proven simply because the system can generate many pages. If separate landing pages are needed, their content and relationship to variants must be defined in advance. Mass replication of nearly identical cards for the sake of address count does not replace this work.

Distribute data by meaning. Fabric composition and cut description belong to the model if they are identical across all variants. Color, size, individual SKU, stock, and differing price belong to a specific product variant. An image may be shared among sizes of a single color, but selecting a blue variant must not leave the user with a sand-colored item on the screen without explanation.

Maintaining the same attribute independently in multiple places is dangerous. If color is stored in the parent description, in the variant, and in a separate manual field, the values will eventually diverge. Every piece of information needs a single source and a rule for inheritance. If a variant overrides a shared photo or attribute, the team must understand the priority.

Independently consider the availability of combinations. After selecting size L, the buyer must understand that the blue color in our example is not produced. After selecting sand-colored size M with zero stock, the buyer must understand that this variant exists but is currently unavailable or available only via a coordinated pre-order. Substituting an out-of-stock size with the nearest available size when adding to the cart is not allowed.

The cart and order confirmation must preserve the selected attributes. A model name alone is insufficient for a user to verify a purchase. The manager and warehouse also need the exact sellable position. If, after selecting two different sizes, only one line remains in the cart without distinctions, the issue lies at the boundary between the catalog and the order, even if the product card itself looks correct.

If 1C manages the assortment, determine how the specific configuration represents the nomenclature, attributes, and packaging. Not all databases are structured the same way. An example with a warehouse attribute is useful as a model, but it does not prove that any exchange will automatically generate the required website structure.

For a pilot group, it is sufficient to document four items in writing: which entity is considered the common model; which records are sellable variants; where their permanent identifiers are located; and which system modifies the properties and composition of variants. Do not declare the name and article number as a universal key without verification: they may change or repeat.

Select not the simplest product for approval, but several edge cases: an incomplete size matrix, a variant with zero stock, a different photo and model that truly should remain separate. On a test copy, the developer will verify whether the selected logic persists after re-export. This is a proposal for verification, not a claim that a specific store has already been tested here.

If the catalog is already operational, changing the data model requires a separate migration plan. You cannot simply delete product cards and regenerate offers: orders, page addresses, images, and external identifiers are linked to them. The design outcome for our hoodie should be more modest and precise: one clear model, three actual sellable positions, and no invented fourth combination.