Как корректно показывать доступность товара на витрине при нескольких складах и предзаказах — пошаговое руководство

Что подготовить перед изменениями в витрине

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

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

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

• Карта складов и приоритеты
• API/файл остатков и полная схема полей
• Правила резерва и возвратов
• Список бизнес‑сценариев продажи

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

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

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

Третий принцип — предсказуемость и однообразие формулировок. Статусы и тексты на карточке, в списке и в корзине должны использовать одинаковые определения и — при возможности — одинаковые правила расшифровки (например, что значат «ограниченно» и «в наличии»). Это уменьшает количество отмен и обращений в поддержку.

Шаг 1 — согласование бизнес‑правил и сценариев показов

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

Рекомендуем формализовать правила в виде краткой таблицы или набора если‑то правил. Например: 1) если доступный остаток > 0 — статус «В наличии», 2) если суммарный остаток = 0 и ожидаемая дата поставки есть — «Предзаказ: доставка с DD.MM», 3) если остаток зарезервирован частично — «Осталось N штук». Чёткие правила упрощают реализацию и тестирование.

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

Шаг 2 — модель данных и логика агрегации остатков

Проектирование модели данных начинается с определения полей, необходимых для отображения: warehouse_id, physical_qty, reserved_qty, available_qty, incoming_date, status. available_qty обычно считается как physical_qty − reserved_qty, но в реальности могут быть дополнительные корректировки (порча, минимальный остаток для магазина и т.д.).

Выберите стратегию агрегации: 1) простое суммирование по всем складам, 2) суммирование с исключением складов с низким приоритетом, 3) агрегация по приоритезированным площадкам (например, ближайший регион). Каждая стратегия имеет свои ограничения и последствия для отображения и логистики.

Не забудьте про временные статусы incoming/expected. Если поставка ожидается, в модели нужен атрибут expected_date и expected_qty. Это позволит показывать покупателю прогноз доставки и корректно оформлять предзаказы, не вводя в заблуждение по наличию товара.

• Обязательные поля: warehouse_id, physical_qty, reserved_qty, expected_date
• Вычисляемое поле: available_qty = physical_qty − reserved_qty
• Атрибуты для витрины: label_status, estimated_delivery

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

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

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

Шаг 3 — правила статусов и тексты для витрины

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

Уточните правила формирования текста: когда показывать точное количество (например, «Осталось 3 шт.»), а когда округлять (например, «Мало на складе» при остатке ≤ 5). Продумайте вариативность сообщений для мобильного и десктопа, чтобы текст помещался и не создавал ложное ожидание по доставке.

Наличие предзаказа оформляйте отдельно: 1) статус «Предзаказ», 2) дата ожидаемой отгрузки, 3) условие предварительной оплаты или удержания средств. Ясность в тексте позволяет уменьшить обращения в поддержку и снижает риск отмен после оформления.

• Статусы: В наличии; Ограничено; Предзаказ; Ожидается; Нет в наличии
• Правило показа количества: точное число при ≤ 20, иначе 'Много'
• Политика предзаказа: дата + условие оплаты

Шаг 4 — реализация front‑end: отображение и микровзаимодействия

На фронтенде обеспечьте единый компонент статуса, который принимает минимальный набор данных (label_status, available_qty, estimated_delivery) и рендерит соответствующий текст и микроинтеракции. Компонент должен быть устойчивым к отсутствию части данных: если expected_date отсутствует — не показывать дату, а предложить подписаться на уведомление.

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

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

• Единый компонент статуса для карточки, списка и корзины
• Микровзаимодействия: всплывающие подсказки, подтверждение для предзаказа
• Доступность и локализация

Шаг 5 — тестирование: сценарии и автоматизация

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

Автоматизируйте проверки ключевых статусов с помощью интеграционных тестов: подмените ответы от API склада и проверяйте рендер компонента статуса. В API‑тестах используйте граничные значения (0, 1, мало, много) и сочетания incoming_date с available_qty, чтобы выявить рассинхрон.

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

• Интеграционные тесты компонента статуса
• API‑муляция сценариев склада
• Ручной прогон через служебных пользователей

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

Перед релизом пройдите по контрольному списку: 1) бизнес‑правила утверждены, 2) модель данных и API готовы, 3) компонент статуса реализован и покрыт тестами, 4) тексты и локализации согласованы, 5) логирование событий и метрики настроены. Каждая контрольная точка должна иметь ответственного и критерий «готов/не готов».

Включите в контрольные точки проверку на отказоустойчивость: что приложение покажет клиенту при недоступности склада или ошибке API. Должны быть понятные fallback‑статусы и возможность мониторинга ошибок. Не запускайте изменения без механизма отката или флага feature flag.

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

• Утверждённые бизнес‑правила с ответственными
• Настроенные метрики и логирование
• План отката и feature flag

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

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

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

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

• Мониторинг отмен и обращений в поддержку
• Алерты на несинхронность остатков
• План итераций и корректировок

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