Материал статьи

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

Иллюстрация: остатки одного товара различаются между магазинами

Иллюстрация: остатки одного товара различаются между магазинами.

Оглавление

Один зелёный значок скрывает несколько разных обещаний

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

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

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

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

Проверяйте конкретный вариант, а не название модели

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

В учебном примере куртка есть в трёх размерах: два экземпляра M в одной точке, один L в другой, S отсутствует. Надпись «В наличии в двух магазинах» допустима как общее ориентирование, но после выбора S она должна смениться. Не оставляйте прежний список точек до следующей перезагрузки страницы. Человек может успеть нажать самовывоз между сменой размера и завершением запроса.

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

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

Что считать доступным количеством

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

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

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

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

Резерв для самовывоза отделён от доступного остатка

Резерв для самовывоза отделён от доступного остатка.

Давность данных важнее лишнего знака точности

Надпись «осталось 7 штук» выглядит точной. Но если она получена из вчерашней выгрузки, точность только визуальная. Нужны время последнего успешного обмена и допустимая давность для конкретного сценария. Для редкой промышленной позиции и быстро продаваемого аксессуара требования могут различаться. Сам интервал обновления выбирают по скорости изменения запасов и возможностям учётной системы.

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

При превышении допустимой давности заранее определите поведение. Можно скрывать точные числа, переводить покупку в запрос подтверждения или временно отключать самовывоз для затронутых точек. Выбор зависит от риска и процесса. Главное — не продолжать обещать обычную доступность молча. Подпись «Информация обновляется, подтвердим наличие перед поездкой» имеет смысл, только если кто-то действительно выполняет подтверждение.

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

Резерв — отдельное действие с понятным сроком

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

Когда резерв появился, клиенту нужны место, срок и способ получения. Формулировка «Отложили для вас до завтра» двусмысленна: до открытия магазина, до конца рабочего дня или до определённого часа? Лучше указывать конкретную дату и время в контексте точки. Если срок меняется после подтверждения, уведомление должно объяснить новые условия, а не просто повторить старый номер заказа.

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

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

Как показать несколько магазинов без перегруженной таблицы

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

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

Сортировка «ближайшие» тоже требует аккуратности. Географически близкая точка с выдачей через три дня может быть менее удобной, чем дальняя, готовая собрать заказ сегодня. Дайте возможность сравнить расстояние и срок, не выдавая одно за другое. Если точное расстояние неизвестно, не рисуйте приблизительное число как результат навигационного расчёта.

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

Перемещение со склада не равно наличию в магазине

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

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

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

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

Наличие конкретного варианта проверяют отдельно от поступившей партии

Наличие конкретного варианта проверяют отдельно от поступившей партии.

Не объединяйте разные виды отсутствия

Товар может закончиться только в выбранной точке, временно отсутствовать во всей сети или больше не поставляться. Это разные ситуации. В первом случае полезен другой магазин, во втором — уведомление о поступлении или подходящая замена, в третьем — объяснение и новый вариант. Одна кнопка «Нет в наличии» скрывает эти возможности.

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

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

SEO-решение о судьбе страницы не следует принимать по остатку одной точки. Временное отсутствие в магазине не означает, что карточку нужно удалять или перенаправлять. Вопрос индексации и вопрос доступности к выдаче разделяются; для первого есть отдельный разбор страниц отсутствующих товаров. Блок наличия должен описывать покупательскую ситуацию, а не управлять URL случайными колебаниями склада.

Что передать разработчику и учётной команде

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

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

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

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

Приёмка: проверьте путь последней единицы

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

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

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

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

Как понять, что блок наличия действительно помогает

Считайте не только клики по магазинам. Важнее доля подтверждённых самовывозов, отмен из-за фактического отсутствия, обращений «можно ли уже приехать» и случаев неверно выбранной точки. Разделяйте причины отмен: отсутствие товара, неудобный срок, изменение планов покупателя и ошибка данных требуют разных действий. Одна общая конверсия не объясняет, что исправлять.

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

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

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