Заказы и остатки: состояния, резерв и склад

TL;DR: заказ — это машина состояний с разрешёнными переходами, а остаток — не одно число, а три: физический stock, резервы и доступность к продаже. Ошибки «продали того, чего нет» и «заказ завис» почти всегда возникают из-за неописанной state machine и неявной формулы доступности, поэтому обе вещи фиксируются до интеграции.

Назначение и границы

Страница описывает состояния заказа, модель резервирования и складскую логику. Она не описывает движение денег (проверка, авторизация, возврат средств — в жизненном цикле платежа) и физическую доставку, вручение и невыкуп (в интеграции доставки).

Жизненный цикл заказа

Состояния и разрешённые переходы:

Состояние	Что означает	Разрешённые переходы
Создан (new)	Корзина оформлена, оплата ещё не подтверждена	Оплачен, Отменён
Оплачен	Деньги подтверждены, резерв на товар поставлен	В сборке, Отменён (возврат средств)
В сборке	Резерв закреплён, склад набирает товар	Отгружен (частично или полностью), Отменён
Отгружен	Товар передан перевозчику, частично или полностью	Доставлен, Отменён (по логистике)
Доставлен	Вручён получателю	Возврат, Завершён
Возврат	Оформлен возврат товара, ожидает оприходования	Завершён
Отменён	Закрыт без продажи	— терминальное

Правила, которые стоит выписать явно, а не дописывать потом:

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

Резерв и доступность к продаже

Три разных числа, которые часто путают под именем «остаток»:

Физический остаток — сколько единиц реально лежит на складе (данные WMS/учёта).
Резерв — сумма, которую удержали оформленные и оплаченные заказы, но ещё не отгруженные.
Доступность к продаже — то, что видит покупатель: доступно = остаток − резервы − страховой буфер.

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

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

Мультисклад

При нескольких складах заказ должен распределяться по складам, а не «висеть» на одном:

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

Backorder, разбиение и частичная отгрузка

Backorder — заказ на товар с нулевым физическим остатком: доступен покупателю только при разрешённом отрицательном резерве и подтверждённой поставке; иначе выключен.
Разбиение заказа — заказ распадается на несколько поставок (разные склады, разные сроки, часть под заказ). Каждая поставка — отдельная строка с логистикой, статусом и документами; основной заказ при этом не отменяется, а продолжает собирать статусы поставок.
Частичная отгрузка — отгужено меньше, чем оплачено: статус заказа остаётся «В сборке» с признаком частичной отгрузки; недостача либо допоставляется, либо переводится в частичный возврат по правилам логистики.

Отмена и её последствия

Отмена — не удаление, а ветка с последствиями, которые разъезжаются по учёту и платформе:

резерв снимается, доступность возвращается (немедленно);
удержанное/оплаченное — разбирается платёжным контуром: авторизация откатывается или происходит возврат средств (детали — в жизненном цикле платежа);
Акционные и накопительные бонусы пересчитываются; промокод возвращается, если правила это допускают;
отменённые позиции не попадают в отчёты продаж и не разрушают формулу выручки.

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

Связка OMS ↔ WMS

Разграничение: OMS решает что и на каком складе исполнить, WMS — как физически сложить и отпустить. Поток выглядит так: заказ → OMS выбирает склад и способ исполнения → на выбранный склад уходит задание на сборку → WMS отбирает по ячейкам, собирает и передаёт товар перевозчику → факты (собрано, отгружено, вес, количество) возвращаются в OMS и учёт. Расхождения набирают веса там, где OMS и WMS — разные системы без общей номенклатуры: единица «счёт» на уровне платформы превращается в «шт» на складе, а ошибочная ассоциация SKU между системами ломает сборку.

Контроль расхождений

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

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

Сверка фиксирует, не исправляет: исправление — операция корректировки в учёте с журналированием причины, а не ручная правка числа на витрине (правила владения данными — в обзоре контура).

Различия B2C и B2B

B2C-заказ короткий: оформлен → оплачен → собран → отгружен → доставлен; разрешение появляется с момента оплаты. B2B-заказ со счётом другой по конструкции, и не сводится к «оптовой скидке»:

Аспект	B2C-заказ	B2B-заказ со счётом
Форма	Корзина + checkout	Корзина → счёт на оплату → подтверждение оплаты
Момент разрешения исполнения	Дата оплаты	Момент получения денег или разрешения по договору
Резервирование	Немедленно	После согласования счёта, до оплаты или отгрузки с отсрочкой
Кредитный лимит	Не применяется	Лимит дебиторки в учётной системе; превышение блокирует заказ
Согласование	Нет	Внутреннее согласование покупателя и/или продавца
Документы	Чек, накладная	Счёт, УПД, накладные через ЭДО
Изменение состава	Редко	Норма: правка счёта до оплаты меняет заказ

Порядок: счёт → согласование → лимит дебиторки → оплата (или отгрузка с отсрочкой) → резерв → сборка → отгрузка. Лимит дебиторки проверяется на стороне учётной системы: витрина не владеет взаиморасчётами и не может сама решать, можно ли отгружать контрагенту в долг. Общая B2B-модель — в B2B-портале и опте.

Критерии проверки

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

Связанные страницы

Обзор контура «Данные и интеграции» — владение заказом и остатком в матрице source of truth.
Системы и потоки данных: обмен с 1С, ERP и CRM — как статусы и резервы доезжают между системами.
Жизненный цикл платежа — платёжные события, управляющие переходами заказа.
Интеграция доставки — что происходит после состояния «Отгружен»: вручение и невыкуп.
Остатки в WooCommerce: варианты учёта — конкретные реализации модели на WooCommerce: учёт на сайте, МойСклад, 1С, CRM.

Материалы и источники

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