Click & Collect: данные магазинов, остатки и самовывоз

06.11.2026 Click & Collect - это заказ на сайте с получением в магазине.

Путь покупателя связывает сайт, ERP, OMS, складской учёт, кассы, геоданные и справочник торговых точек.

Если магазин закрыт, но отображается на сайте, покупатель оформит невыполнимый заказ.

Если магазин и пункт выдачи смешаны в одном списке, интерфейс покажет неверные условия.

Если остатки обновляются с задержкой, товар будет обещан там, где его уже нет.

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

Поэтому Click & Collect проектируют как сквозной процесс управления заказом и данными торговой сети.

Организационный риск возникает, когда у мастер-данных нет владельца.

Адрес хранится в одной системе, график - в другой, статус закрытия - в третьей, а признак самовывоза вручную задаётся на сайте.

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

Витрина получает согласованный статус из определённого источника; косвенные поля не дают надёжного результата.

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

Или временное закрытие и окончательное прекращение работы представлены одним признаком.

Практичная модель различает: - работает; - временно недоступен; - готовится к открытию; - закрыт окончательно; - работает, но не участвует в Click & Collect.

Для временных изменений полезны интервалы действия.

Система должна заранее знать, что точка закроется на ремонт или будет работать по сокращённому графику, и перестать обещать недоступные интервалы выдачи.

Физический остаток, доступность на витрине и количество, которое можно подтвердить покупателю, - разные показатели.

Для выдачи нужен расчёт с учётом резервов, уже начатых продаж, перемещений, брака и страхового запаса. В документации Dynamics 365 Commerce Inventory Visibility описана как основа актуального представления остатков и сценариев резервирования.

Требуемая задержка обмена определяется процессом конкретного ритейлера.

Эти материалы показывают возможности продукта Microsoft, а предлагаемая модель данных применима и к другим платформам.

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

1. Описать путь заказа От выбора магазина до выдачи и возврата: кто резервирует товар, кто подтверждает, где меняется статус и что видит клиент. 2. Провести аудит данных магазинов

Найти дубли, закрытые точки, неполные адреса, несовпадающие идентификаторы и неявные правила активности. 3. Назначить владельцев данных

За каждой группой полей должен стоять процесс обновления и ответственная функция. 4.

Согласовать контракт между системами

Зафиксировать типы точек, обязательные поля, версии, правила ошибок и обратную совместимость. 5.

Проверить исключения В тесты включают временно закрытый магазин, отсутствие остатка после оформления, повтор события, смену графика, смешанный заказ и отказ покупателя. 6. Запустить ограниченный пилот

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