Комплекты и наборы товаров в Битрикс: состав, цена и остатки

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

Комплекты товаров Битрикс и наборы: где проходит граница моделей покупки

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

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

Почему модели покупки нельзя смешивать в одной карточке

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

Где в этой картине торговые предложения

Если у товара есть варианты (размер, цвет, объём), комплект и набор могут опираться на них. Заранее решите, продаётся ли конкретное предложение, любой доступный вариант или набор с выбором вариантов по каждому компоненту. Устройство вариантов описано в материале про торговые предложения Битрикс.

Как выбор модели влияет на всю цепочку

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

Какие исходные данные и правила согласовать до настройки

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

• Перечень компонентов. Для каждого комплекта и набора — точный список товаров или торговых предложений, которые в него входят.
• Количество каждого компонента. Один комплект может включать не по одной единице, а по несколько; это влияет на списание.
• Правило цены. Фиксированная цена комплекта, сумма цен компонентов или сумма со скидкой. Отдельно решите, что происходит, когда цена компонента меняется.
• Правило остатков. Считаем остаток по самому дефицитному компоненту, по сумме или не считаем вовсе и продаём «под заказ».
• Правило замены. Можно ли заменить компонент на аналог, кто это решает и видит ли покупатель замену.
• Правило возврата. Что возвращается — комплект целиком или отдельные компоненты, и как это отражается на складе.
• Правило доставки. Считается ли комплект одной посылкой или компоненты могут ехать отдельно.
• Ответственный. Кто владеет правилами: менеджер каталога, руководитель склада или заказчик.

Что фиксировать письменно

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

Кто владелец правила

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

Как выбрать сценарий: критерии и сравнение вариантов

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

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

Как читать таблицу

Строки таблицы — точки выбора, а не готовые рецепты. Смотрите на столбец «Основной риск»: он указывает, что нужно проверить внимательнее всего. Если риск касается цены — готовьте проверки цены, если остатков — проверки склада. Таблица становится планом проверок, а не справочником.

Когда сценарий стоит упростить

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

Состав: как задать компоненты и правила замены

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

Что происходит при изменении состава

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

Совместимость компонентов

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

Количество единиц в комплекте

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

Цена: три источника и проверка сочетаний

У цены три источника: фиксированное значение, сумма компонентов и сумма со скидкой. Фиксированная цена проще для покупателя, но требует ручного пересмотра при изменении закупки. Сумма компонентов обновляется автоматически, но не стимулирует покупку набора. Скидка за набор — компромисс, требующий проверки на сочетание с другими акциями.

Что проверить при изменении цены компонента

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

Как не потерять маржу на скидке

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

Округление и типы цен

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

Остатки и резервирование: как не продать отсутствующее

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

Момент резервирования

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

Частичная доступность набора

Если часть компонентов набора закончилась, нужно решить, что видит покупатель: набор целиком недоступен или доступен в частичном составе. Оба варианта допустимы, но правило должно быть единым. Смешанное поведение — когда иногда набор скрывается, а иногда собирается частично — сбивает и покупателя, и менеджера.

Несколько складов

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

Порядок настройки и зоны ответственности

Работы идут по шагам, и каждый шаг имеет владельца.

1. Согласование правил. Заказчик и менеджер каталога фиксируют состав, цену, остатки и возвраты. 2. Подготовка тестовой копии. Настройка ведётся не на рабочем магазине, а на копии с резервной копией данных и планом возврата. 3. Настройка каталога. Разработчик настраивает торговый каталог, типы товаров и, если нужно, торговые предложения. 4. Наполнение. Контент-менеджер заводит компоненты и собирает комплекты и наборы. 5. Проверка. Тестировщик или менеджер проходит сценарии покупки и сверяет цену и остатки. 6. Приёмка и публикация. Заказчик подтверждает результат по чек-листу, и только после этого изменения переносятся на рабочий магазин.

Как разделить ответственность

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

Что подготовить перед стартом

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

Как переносить изменения на рабочий магазин

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

Учебный пример: комплект и набор в одном каталоге

Учебный пример. Данные условные и не описывают реальный проект.

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

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

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

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

Что показал пример

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

Как перенести пример на свой магазин

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

Как проверить результат на тестовом магазине

Проверку удобно вести по списку. Пройдите его на копии, а не на рабочем магазине.

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

Как фиксировать результат проверки

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

Когда проверку можно считать законченной

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

Типичные ошибки и ограничения

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

Ограничения, которые стоит признать заранее

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

Что делать дальше

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

Совместимость редакции и что уточнять официально

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

Как проверить, не полагаясь на обещания

Способ проверки простой: возьмите официальную документацию по своей редакции и сверьте, какие разделы торгового каталога и складского учёта в ней описаны. Дополнительно проверьте фактическую конфигурацию проекта — какие модули подключены и как настроен инфоблок каталога. Так вы получите ответ по своему случаю, а не общее предположение.

Что делать, если возможности не хватает

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

FAQ