Как снять все резервы в МоемСкладе и почему они зависают

Что такое резерв в МоемСкладе

Резерв — это количество товара, которое закреплено за конкретным заказом покупателя. Он уменьшает доступное количество, но сам по себе не уменьшает фактический остаток товара на складе.

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

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

Чтобы оценить весь запас, а не только занятые количества, прочитайте как проверить остатки и найти залежавшиеся товары в МойСклад.

Как снять резерв вручную — и когда этого уже недостаточно

С одним заказом всё довольно просто. Откройте Продажи → Заказы покупателей, найдите нужный документ, снимите флажок Резерв и сохраните изменения. Если компания резервирует не заказ целиком, а отдельные позиции, нужно открыть товарные строки и проверить количество в резерве у каждой из них.

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

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

Открыть в полном размере ↗

Почему резервы «зависают»

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

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

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

Отгрузка не связана с заказом покупателя

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

Фактический резерв уже снят, но флажок остался

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

Как найти заказ, который держит товар

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

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

Чтобы разделить эти 17 единиц по документам, просмотрите заказы с данным товаром. В первую очередь подозрение вызывают отменённые, закрытые, неоплаченные и просроченные документы, а также заказы, которые месяцами остаются новыми или выполнены лишь частично. Названия статусов могут отличаться, но смысл проверки остаётся тем же: понять, есть ли у заказа реальная причина продолжать удерживать товар.

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

Как автоматизация создаёт проблему — и как её исправить

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

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

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

Резерв остался или появился снова: что проверить

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

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

Массовая очистка через API: почему здесь важна осторожность

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

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

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

Как сделать, чтобы резервы больше не зависали

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

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