Проектирование каталога товаров с вариациями, комплексами и наборами

Подготовка: что нужно собрать перед проектированием

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

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

Наконец, определите требования поиска и фильтрации: какие атрибуты важны для клиента (цвет, материал, длина), нужно ли показывать доступность по складу или наличие комплектов, и какие варианты должны быть видны на карточке товара. Это позволить сэкономить время при проектировании интерфейса и API.

Структура товаров: базовые сущности и отношения

Рекомендуем разделить каталог на три базовые сущности: базовый товар (product), артикул/вариант (SKU) и комплект/набор (bundle). Product описывает концепт товара: название, основное описание, категория и бренд. SKU — конкретная комбинация атрибутов (цвет + размер), с собственной карточкой цены и остатками. Bundle — коллекция из SKU и/или products с правилами скидки и составления.

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

Важно также предусмотреть мета-связи: заменители для SKU (аналогичные позиции), правила суммирования цен в наборах (фиксированная цена или сумма со скидкой) и флаги сборки (на складе/в момент заказа). Это избавит от необходимости вносить изменения в архитектуру при добавлении новых типов комплектов.

Атрибуты и свойства: какие данные хранить в каталоге

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

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

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

Архитектура данных и учёт: как моделировать SKU, комплекты и остатки

Для учёта используйте отдельную таблицу/сущность SKU с уникальным идентификатором и ссылкой на Product. В SKU хранятся артикул, цена, остаток и уникальные атрибуты. Остатки и резервации учитывайте не в Product, а на уровне SKU, потому что именно артикулы списываются при комплектации и отгрузке.

Комплект реализуйте как сущность bundle, которая содержит набор ссылок на SKU и правила подсчёта (процент скидки, фиксированная цена, условная опция). При оформлении заказа система должна транслировать состав bundle в конкретные SKU с необходимыми проверками наличия и возможностью замены при отсутствии.

Планируя интеграцию с учётными системами (например, 1С), заранее оговорите форматы обмена: какие поля экспортируются, как помечать трансформации (bundle → несколько SKU), и как обрабатывать частичный возврат: возвращается ли весь набор или отдельный SKU. Чёткая модель данных защищает от рассинхрона остатков и ошибок при сборке.

Интерфейс поиска и фильтрации для товаров с вариациями

Продумайте, как пользователь увидит варианты: лучший UX — показывать Product как основной объект с контролом выбора варианта (выпадающие списки или визуальные переключатели), а не дублировать список всех SKU. При этом в результатах поиска можно показывать релевантный SKU-статус (в наличии/под заказ) и ключевые отличия.

Фильтры должны работать по атрибутам SKU и Product одновременно. Реализуйте логику «фильтр по цвету» так, чтобы отображались Product, у которых есть хотя бы один SKU с выбранным цветом, и на карточке автоматически предлагался этот SKU. Это уменьшит количество пустых страниц и ускорит путь к покупке.

Для наборов обеспечьте отдельный визуальный признак в списке и возможность фильтрации по типу товара «набор/комплект». На странице набора показывайте развернутый состав с индикаторами наличия каждого SKU и итоговой ценой с учетом правил комплектования.

Последовательные шаги внедрения: от модели до миграции

План внедрения разбейте на блоки и соблюдайте строгую нумерацию действий. 1) Моделирование: утвердите сущности Product, SKU и Bundle. 2) API и интеграции: определите контракт с 1С/складом и внешними сервисами. 3) Интерфейс: спроектируйте карточку товара и логику переключения вариантов. 4) Тестирование: разработайте сценарии проверки учёта и поиска.

Далее — миграция данных: 5) Подготовка выгрузок: сгруппируйте существующие позиции по новым SKU-правилам, определите правила разбиения артикулов. 6) Прогон на тестовой базе: загрузите данные, проверьте соответствие остатков и корректность формирования наборов. 7) Коррекция бизнес-правил и повторный прогон.

В технической реализации придерживайтесь итераций: закрывайте один блок функционально (например, SKU + поиск) до начала работ по комплексам. Это уменьшит риск простоя и позволит тестировать критичные участки отдельно — сначала учёт и списание, затем логика формирования bundle и расчёт цен.

Контрольные точки перед релизом (чек-лист)

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

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

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

• Уникальные артикулы для всех SKU
• Остатки ведутся на уровне SKU
• Практические сценарии сборки bundle
• Фильтрация по атрибутам SKU и Product
• Корректный экспорт/импорт в 1С или ERP
• Обработка частичных возвратов и замен

Тестирование сценариев: что прогонять и как фиксировать ошибки

Опишите тест-кейсы для трёх групп: функциональные (отображение и выбор варианта), учётные (списание, резерв, возврат) и пользовательские (поиск, фильтрация, оформление заказа). Каждый тест-кейс должен содержать предусловия (какие SKU есть в наличии), шаги и ожидаемый результат, а также критерий «принятия».

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

Для приоритезации багов используйте правило: критичные — приводят к ошибке списания/платежа; высокие — мешают продаже (показывают неверную доступность); средние и низкие — косметика и удобство. Исправления тестируйте в той же последовательности, чтобы исключить регрессии.

Запуск и пост-релизная проверка: что мониторить после публикации

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

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

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

Типичные ошибки и способы их предотвращения

Частая ошибка — дублирование атрибутов в Product и SKU, что приводит к рассинхрону при массовых изменениях. Решение: чётко разделять, какие поля являются общими, а какие — специфичными для SKU, и реализовать централизованные операции обновления.

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

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

Частые вопросы