Конфигуратор товара для интернет-магазина: правила, цена и состав заказа
Покупатель выбрал ширину шкафа, фасад и внутреннее наполнение. Картинка выглядит правильно, цена посчитана, но менеджер снова собирает заказ вручную: уточняет крепёж, проверяет размеры и переносит детали в 1С. В таком виде конфигуратор добавляет ещё один экран между покупателем и сотрудником.
Рабочий конфигуратор помогает получить допустимую комплектацию, объясняет её стоимость и передаёт в заказ точный состав. Визуализация может быть важна, но сложность проекта чаще скрывается в правилах: какие детали совместимы, что есть в наличии, как применяется скидка и что делать при изменении цены.
Сначала определите, какой выбор вы автоматизируете
Под одним названием продают несколько разных инструментов. У них разная модель товара, стоимость наполнения и требования к разработке. Начните с результата, который должен получить покупатель и менеджер.
| Тип выбора | Пример | Что получает система |
|---|---|---|
| Готовый вариант | Кроссовки нужного размера и цвета | Конкретный артикул со своей ценой и остатком |
| Комплект из позиций | Компьютер из выбранных комплектующих | Состав с артикулами, количеством и правилами совместимости |
| Изделие по параметрам | Столешница с длиной, вырезом и обработкой края | Параметры изделия, расчёт, материалы и производственные ограничения |
| Предварительный подбор | Оборудование, для которого нужен расчёт инженера | Сохранённые исходные данные и запрос на проверку |
Если цена зависит от инженерного обследования, не превращайте ориентировочный расчёт в готовую к оплате покупку. Покажите, что уже определено, что проверит специалист и какие данные сохранятся. Иначе клиент и менеджер будут обсуждать разные ожидания.
Для простой комбинации цвета и размера отдельный конструктор может оказаться лишним. Сначала проверьте, решает ли задачу обычный выбор вариантов товара. Конфигуратор оправдан, когда выборы зависят друг от друга, меняют состав или требуют расчёта.
Пример HYPERPC: покупатель видит выбор и его цену
В конфигураторе HYPERPC слева перечислены разделы комплектующих, в центре выбирается позиция, справа видны текущая цена и состав сборки. У альтернатив показана разница в стоимости. Это помогает понять последствия выбора без перехода между несколькими карточками.
HYPERPC заявляет проверку совместимости компонентов. По одному экрану нельзя установить полноту этой проверки: это требует отдельного набора сценариев. Для собственного проекта важно заранее описать, какие сочетания система запрещает, какие разрешает с предупреждением и в каких случаях предлагает замену.
Переносимая идея здесь простая: покупатель сохраняет контекст. Он видит, на каком шаге находится, что уже выбрано и как изменение влияет на итог. В вашем магазине вместо процессора может быть ткань, тип двигателя или основание стола; структура решения останется похожей.
Соберите правила до рисования интерфейса
Возьмите один товар, который менеджеры регулярно рассчитывают вручную. Попросите опытного сотрудника собрать три обычных заказа и два неудобных. Записывайте не только действия, но и причины: «этот блок нельзя поставить», «здесь нужен переходник», «такой размер согласует производство».
Ниже учебные правила для модульного шкафа. Они не описывают ассортимент IKEA или готовое решение CAPS.
| Правило | Что происходит в интерфейсе | Как проверить |
|---|---|---|
| Полка подходит только к секции своей ширины | Показаны подходящие полки; остальные недоступны с объяснением | В каждой секции нельзя сохранить полку другого размера |
| Для выдвижного ящика нужен согласованный зазор у двери | При конфликте указано, что именно мешает и что заменить | Смена двери повторно проверяет уже выбранный ящик |
| Подсветке нужен блок питания | Обязательная деталь добавляется с понятным количеством и ценой | Она не пропадает при редактировании и не добавляется дважды |
| После изменения ширины часть наполнения не подходит | Пользователь видит список изменений и подтверждает замену | Недопустимые детали не остаются в сохранённом заказе |
| Нестандартный размер требует проверки производства | Показан переход к запросу расчёта с сохранением параметров | Такой вариант нельзя случайно оплатить как типовой |
У каждого правила должен быть владелец со стороны бизнеса. Разработчик может реализовать ограничение, но не должен угадывать допустимые размеры или подбирать инженерный запас. Отдельно назначьте того, кто будет обновлять правила после запуска.
Правила удобно хранить в форме, которую может проверить специалист предметной области: таблица зависимостей, перечень ограничений, примеры допустимых заказов. Если весь смысл существует только внутри программного кода, смена ассортимента снова потребует расшифровки у разработчика.
Мебельный планировщик: картинка и спецификация должны совпадать
В публичном планировщике IKEA PAX можно увидеть размеры шкафа, группы деталей и итоговую цену. На выбранном примере визуализация показывает целое изделие, а разделы справа позволяют работать с рамами, дверями и наполнением.
При раскрытии состава доступны артикулы, количество и стоимость деталей. Для магазина это принципиальный переход: визуальный выбор становится набором позиций, с которым могут работать заказ, склад и сотрудник.
На своих данных проверьте этот переход в обе стороны. Если покупатель добавил две одинаковые полки, в спецификации должно быть количество два. Если менеджер открыл сохранённую конфигурацию, он должен увидеть тот же состав, а не только похожую картинку.
Для производственного изделия может понадобиться ещё и ведомость материалов: какие листы, профиль или фурнитура требуются для изготовления. Покупательская комплектация и производственная ведомость могут различаться. Это нужно согласовать отдельно, чтобы не пытаться передать на производство один текстовый комментарий.
Разберите цену на проверяемые составляющие
Надпись «цена от» не объясняет, сколько будет стоить выбранный вариант. Пользователь должен видеть актуальный итог и понимать значимые доплаты. Команда, в свою очередь, должна уметь повторить расчёт по тем же исходным данным.
Учебный пример, все суммы условные. Товары стоят 38 600 ₽: корпус 22 000 ₽, двери 12 000 ₽ и наполнение 4 600 ₽. Монтаж стоит ещё 3 500 ₽. На товары действует скидка 10%, на монтаж она не распространяется.
| Часть расчёта | Сумма | Правило |
|---|---|---|
| Корпус, двери и наполнение | 38 600 ₽ | Сумма выбранных товарных позиций |
| Скидка на товары | −3 860 ₽ | 10% от 38 600 ₽ |
| Товары после скидки | 34 740 ₽ | 38 600 − 3 860 |
| Монтаж | 3 500 ₽ | Отдельная услуга без этой скидки |
| Итого без доставки | 38 240 ₽ | 34 740 + 3 500 |
Теперь договоритесь об изменениях. Что будет, если пользователь уберёт монтаж, применит второй промокод или откроет сохранённый расчёт после обновления прайса? Должна ли старая цена сохраняться и до какого момента? Ответ зависит от вашей модели продаж; интерфейс не должен решать это молча.
Округление, единицы измерения, порядок скидок и цены для разных покупателей входят в правила расчёта. В смете разработки они должны быть названы явно. «Калькулятор цены» без этих условий слишком широко трактуется.
Не смешивайте доплату с полной стоимостью замены. Если базовая дверь уже включена в цену, при выборе дорогой двери нужно заменить одну позицию другой по согласованной модели. Иначе одна и та же часть изделия незаметно будет оплачена дважды.
Сервер должен заново проверить выбранную конфигурацию
Проверка в браузере помогает пользователю быстро исправить выбор. Она не защищает заказ от подмены запроса или устаревших данных. OWASP рекомендует выполнять проверку входных данных на сервере; клиентскую проверку можно обойти.
Для конфигуратора это означает: сервер получает идентификаторы выбранных позиций и параметры, проверяет допустимые значения, зависимости, доступность и заново рассчитывает цену. Сумма, которую прислал браузер, не должна становиться окончательной только потому, что она есть в запросе.
Показательный сценарий: покупатель оставил вкладку открытой, а сотрудник за это время изменил прайс или отключил деталь. При продолжении покупки сайт должен обнаружить изменение, объяснить его и получить подтверждение нового результата. Молчаливая замена на «похожее» изделие создаёт спор о составе заказа.
Нужна и защита от повторов. После обрыва связи покупатель может нажать кнопку ещё раз. Система должна определить результат первой попытки и не создавать второй одинаковый заказ. Это проверяют отдельно от красивого сценария с быстрым интернетом.
Что передавать в заказ, CRM и 1С
Запись «шкаф белый, 150 см, как на картинке» не позволяет надёжно сверить заказ. Нужна структура, в которой разделены выбранная конфигурация, её товарный состав, услуги и финансовый результат.
| Данные | Зачем они нужны |
|---|---|
| Идентификатор и версия конфигурации | Открыть нужный вариант и отличить его от последующих изменений |
| Параметры изделия и выбранные опции | Восстановить выбор покупателя в интерфейсе |
| Артикулы, количество и единицы | Сверить состав со складом или учётной системой |
| Версия правил и прайса, время расчёта | Объяснить полученную цену и изменения при повторном открытии |
| Скидки, услуги, доставка и итог | Сопоставить расчёт, платёж и документы заказа |
| Статус проверки и ограничения | Отличить готовую покупку от запроса, который должен проверить специалист |
В учёте нужно заранее выбрать модель: продаётся один составной товар, отдельные позиции или изделие по производственному заказу. У этих вариантов разные правила изменения, резервирования и возврата. Согласуйте их со специалистом по вашей конфигурации 1С до разработки обмена.
Отправьте в тестовую учётную базу несколько согласованных примеров и сравните документы. На этом этапе важны не только успешная загрузка и итоговая сумма: количество, единицы, артикулы и услуги тоже должны совпасть. Детали подготовки обмена есть в статье об интеграции магазина с 1С.
Где хватит Битрикса и готового модуля
В Битриксе различаются торговые предложения, комплекты и наборы рекомендаций. Выбор готового артикула, обязательный состав изделия и блок «купить вместе» нельзя считать одной функцией. На официальном экране ниже показан именно набор рекомендуемых товаров: чехол, карта памяти и плёнка.
Штатный компонент конструктора наборов предназначен для работы с наборами. В его документации отдельно описаны ограничения работы с товаром с предложениями и групповыми скидками. Поэтому название «конструктор» в списке компонентов ещё не подтверждает, что он реализует вашу размерную сетку и правила производства.
Готовый модуль стоит проверять на ваших примерах. Попросите показать зависимые опции, исключения, расчёт цены, сохранение состава и передачу заказа. Проверьте также, кто меняет правила, как модуль обновляется и можно ли сохранить данные при его замене.
Собственная логика оправдана, когда правила и модель изделия существенно выходят за возможности проверенного решения. Она может работать внутри существующего магазина или отдельным сервисом. Laravel или Node.js помогают реализовать такую систему, но сами по себе не определяют совместимость деталей и корректность цены. Выбор платформы имеет смысл обсуждать после описания процесса; для общей оценки есть разбор выбора платформы магазина.
Когда нужна 3D-модель
Визуализация полезна, если человеку трудно представить форму, сочетание материалов или размеры. Для мебели важны расположение секций и открывание дверей; для компьютера покупателю может быть важнее состав и цена. Начните с вопроса, какую ошибку выбора должна предотвращать картинка.
Для одного товара может хватить качественных фотографий вариантов или слоёв изображения. Свободное размещение предметов в комнате уже требует другой работы: геометрии, поведения камеры, материалов, света и проверки на разных устройствах. Наполнение 3D-каталога и поддержка моделей становятся отдельной частью проекта.
В спецификации полезно разделить изображение и правила допустимости. Красивое наложение деталей не доказывает, что изделие можно собрать. А отсутствие 3D не мешает сделать надёжный конфигуратор с точным расчётом и понятной спецификацией.
Для телефона предусмотрите режим работы, в котором человек видит текущий шаг, выбранные параметры и итог без постоянных прыжков по длинной странице. Объяснение конфликта должно находиться рядом с выбором. При уходе назад уже заполненные параметры сохраняются.
Приёмка: проверьте конфликты, изменения и повторные действия
| Сценарий | Ожидаемый результат |
|---|---|
| Несовместимые детали | Нельзя сохранить недопустимый состав; причина и способ исправления понятны |
| Замена базового параметра | Повторно проверены зависимые позиции; изменения явно показаны |
| Две одинаковые детали | Правильное количество в спецификации, заказе и учёте |
| Обязательная дополнительная деталь | Добавлена один раз; её стоимость учтена и объяснена |
| Товар закончился после расчёта | Перед покупкой показано актуальное ограничение без молчаливой подмены |
| Прайс обновлён в другой вкладке | Применено согласованное правило цены; пользователь видит изменение |
| Скидка и платная услуга | Пересчитаны нужные позиции; скидка не затронула исключённую услугу |
| Повтор после потери ответа | Нет второго заказа; результат первой попытки можно получить |
| Открытие сохранённого проекта | Восстановлен состав; устаревшие позиции и правила обработаны явно |
| Передача в учёт | Совпали артикулы, количества, единицы, услуги и итог |
| Телефон, клавиатура, слабое соединение | Выбор, объяснения и подтверждение доступны; состояние не пропадает |
| Изменение правила сотрудником | Понятны автор, новая версия и влияние на сохранённые расчёты |
Скачать таблицу приёмки конфигуратора. Добавьте реальные примеры вашего ассортимента и отметьте результат каждого сценария. Один успешно собранный товар не проверяет всю систему правил.
Первая версия и экономика проекта
Практичная первая версия охватывает одну товарную семью, для которой можно формально описать правила. В неё входят выбор, проверка, расчёт, сохранение результата и передача заказа или запроса менеджеру. Добавление остальных категорий становится отдельным решением после проверки первой.
До запуска измерьте текущую работу: сколько расчётов делает менеджер, сколько времени они занимают, какие уточнения повторяются и сколько запросов доходит до согласованного заказа. После запуска считайте не только открытия конфигуратора, но и завершённые допустимые расчёты, обращения с сохранённым составом, принятые заказы и возвраты к ручной доработке.
Для решения о следующем этапе полезны две величины: сколько работы удалось убрать у сотрудников и изменился ли путь к заказу. Рост числа начатых конфигураций без готовых составов может означать, что интерфейс заинтересовал посетителей, но не помог им закончить выбор. Оплаченный заказ учитывается отдельно от расчёта и заявки.
В стоимость проекта входят не только экраны: описание и реализация правил, подготовка каталога, расчёт, интеграции, изображения или 3D, проверка и инструменты изменения ассортимента. Отдельно оцените, кто поддерживает прайс и правила после запуска. Без этого новый товар быстро вернёт расчёты в переписку.
Для обсуждения конфигуратора с CAPS пришлите один типичный заказ, один сложный случай и действующую таблицу расчёта без данных покупателей. По ним можно определить, хватит ли вариантов товара или модуля, где нужна собственная логика и что войдёт в первый работающий объём. Примеры HYPERPC и IKEA в этой статье иллюстрируют подходы; их разработку мы себе не приписываем.
Источники и примеры интерфейсов
Проверено 22 октября 2026 года. Учебные правила шкафа, суммы и таблица приёмки созданы для объяснения; это не расчёт конкретного продавца и не опубликованный результат клиента CAPS.
- HYPERPC: описание конфигуратора и рабочий интерфейс выбора комплектующих. Проверены видимые разделы, цена и состав; полная матрица совместимости не тестировалась.
- IKEA PAX, испанская версия на английском: выбран готовый пример, открыты размеры и список деталей. Цены на снимках относятся к этому экрану и дате.
- 1С-Битрикс: типы товаров и наборы, комплекты и наборы рекомендаций, возможности и ограничения конструктора наборов.
- OWASP: проверка входных данных на сервере.
Экраны HYPERPC и IKEA сняты в публичных интерфейсах. Экран настройки набора получен из официальной документации Битрикс. Заказы, регистрации и отправка контактов при исследовании не выполнялись.
