Резервы без потери контекста между кабинетами и складами
Резерв нужен, чтобы один и тот же товар не был обещан двум заказам. Но зависший резерв так же вреден: он искусственно уменьшает доступный остаток.
Почему отдельный сценарий важнее ещё одной таблицы
При отменах, смене статусов и сбоях интеграции резерв может остаться активным после завершения жизненного цикла заказа.
- 1. ШагСвязывайте резерв с заказом, SKU и локальным складом.
- 2. ШагСверяйте статус заказа перед удержанием количества.
- 3. ШагВыявляйте зависшие резервы и причины расхождений.
- 4. ШагВозвращайте количество в доступный остаток только после подтверждённого события.
Рабочие элементы сценария
Связь с заказом
Используется вместе с каталогом, магазином и компанией, чтобы действие не теряло источник данных.
Контекст склада
Используется вместе с каталогом, магазином и компанией, чтобы действие не теряло источник данных.
Контроль зависших резервов
Используется вместе с каталогом, магазином и компанией, чтобы действие не теряло источник данных.
История операций
Используется вместе с каталогом, магазином и компанией, чтобы действие не теряло источник данных.
Коротко о резервы
Когда создаётся резерв?
Резерв используется в операционном процессе после появления заказа, когда количество требуется закрепить за конкретным заказом и складом.
Что такое зависший резерв?
Это количество, которое продолжает считаться занятым после отмены или завершения заказа либо после некорректного перехода статуса.
Можно ли просто уменьшать физический остаток при заказе?
Это смешивает разные сущности. Физический товар и обещанное заказу количество лучше учитывать отдельно, чтобы сохранять корректную складскую картину.
Посмотреть соседние задачи
Сценарии связаны между собой, но каждая страница отвечает только на одну операционную проблему.