Карточка товара интернет-магазина: состав, состояния и приёмка

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

Что решает карточка товара интернет-магазина и где её границы

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

Полезно сразу развести три уровня, которые часто смешивают в одном обсуждении:

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

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

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

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

Отдельно стоит договориться, что считается улучшением. Формулировки вроде «сделать карточку удобнее» не проверяемы. Рабочие формулировки звучат иначе: покупатель видит актуальную цену и наличие; при отсутствии варианта он понимает, что делать дальше; менеджер может заполнить карточку по инструкции, не задавая вопросов разработчику. Такие формулировки проверяются на тестовых данных, не дожидаясь запуска.

Что входит в задачу, а что нет

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

Из чего состоит карточка: товар и торговые предложения

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

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

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

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

Отдельно стоит тема «Новая карточка товара»: в курсе есть разделы «Старая и новая карточки», «Как включить режим работы с новой карточкой» и «Как создавать товары». Это значит, что внешний вид и логика карточки зависят от режима, в котором работает магазин, и этот режим — предмет отдельного решения, а не побочная настройка. Перед переключением режима нужны копия, тест и план возврата.

Как проверить, что уровень выбран верно

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

Что уточнить до начала работ

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

Характеристики, варианты и документы: что подготовить

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

Базовый перечень:

• Наименование и артикул в том виде, в каком они приняты в учёте.
• Список свойств с типами: строка, число, список значений, справочник.
• Единицы измерения и ставка НДС для товара и для услуг доставки — в материалах это отдельные темы «Единицы измерения» и «Ставки НДС для товаров».
• Типы цен и правила округления.
• Изображения и, при необходимости, документы.
• Признак, требует ли товар маркировки.

Про маркировку нужно сказать аккуратно. В материалах есть раздел «Маркировка товаров 487-ФЗ» и связанные с ним настройки магазина (ссылка на соответствующий раздел документации). Это область, где требования меняются и зависят от категории товара, поэтому в проекте её выделяют в отдельный блок с ответственным и обязательной сверкой с профильным специалистом. Карточка лишь показывает то, что требуется по правилам, и не заменяет юридическую консультацию.

Документы и сертификаты — частая причина споров. Заранее решите, что именно публикуется: скан, ссылка, декларация в текстовом виде. Если решение не принято, в карточке появляется пустой блок «Документы», который снижает доверие.

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

Как понять, что данных достаточно

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

Состояния цены, наличия и заказа

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

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

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

Наличие. Здесь опираются на разделы «Количественный и Складской учёты» и «Резервирование товаров» (ссылки на соответствующие разделы документации). Практически важно различать: товар в наличии, товар под заказ, товара нет, товар в резерве под другой заказ. Для каждого состояния нужен свой текст и своё действие — кнопка «Купить», «Уточнить срок», «Сообщить о поступлении».

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

Прототип состояний карточки

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

Минимальный набор осей:

• Наличие: есть, под заказ, нет.
• Цена: обычная, со скидкой, не задана.
• Варианты: один, несколько, выбран конкретный.
• Действие: покупка доступна, доступна заявка, недоступно.

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

Как описать состояние словами

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

Учебный пример на тестовых данных

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

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

Шаг 1. Размечаем уровни. Футболка, куртка, шапка — товары. Размеры и цвета — торговые предложения. Бренд и материал — свойства товара. Размер и цвет — свойства предложения.

Шаг 2. Описываем состояния. Для футболки: размер M в наличии, размер L под заказ, размер XL отсутствует. Для куртки: чёрная в наличии, синяя под заказ. Для шапки: в наличии.

Шаг 3. Сводим в прототип. Получается таблица, где по строкам — предложения, по столбцам — цена, наличие, действие и текст кнопки.

Шаг 4. Проверяем на тестовых данных. Меняем остаток у одного предложения, смотрим, изменилось ли состояние и текст. Задаём скидку на товар, проверяем, показывается ли старая цена и не «съезжает» ли она при переключении размера. Ставим одно предложение в резерв и убеждаемся, что это отражено в показе.

Шаг 5. Фиксируем результат. Прототип и правила передаются в разработку как часть задания.

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

Таблица принятия решения

Как проверить результат и принять работу

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

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

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

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

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

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

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

Чтобы получить оценку, а не диапазон «от и до», подготовьте:

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

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

Коротко о главном

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