Заказ в Битрикс24 без остатка: резерв МойСклад 2026

Менеджер перевёл сделку в Битрикс24 на стадию «Счёт выставлен», клиент оплатил, и только на сборке выясняется: товара нет. Часть ушла по другому заказу час назад, часть — на маркетплейс, а в CRM всё это время висела зелёная стадия и ощущение, что всё под контролем. Дальше — либо извинения и перенос срока, либо отмена заказа, либо (хуже) отправка не того, что клиент купил, лишь бы не признавать провал.

Причина почти всегда не в менеджере. Причина в том, что Б24 не знает, сколько товара реально доступно, а решение «взять в работу» принимается по памяти, звонку кладовщику или вчерашней выгрузке в Excel. Здесь разбираем не то, нужна ли вам связка МойСклад и Битрикс24 как таковая — об этом отдельный материал, — а конкретную механику: как резервировать остаток из МойСклад прямо в сделке и как блокировать переход дальше по воронке, если остатка не хватает.

Почему менеджер продаёт то, чего нет на складе

Дело не в невнимательности. У менеджера физически нет данных, чтобы поступить иначе.

Остаток в другой системе. Карточка сделки в Б24 не знает, что происходит на складе — если её никто туда не подключил.
Остаток устарел. Даже если цифра есть, она могла обновиться час назад, а с тех пор товар ушёл по другому заказу.
«Доступно» и «на складе» — разные числа. На складе может быть 20 штук, но 15 уже зарезервированы под другие сделки — доступно физически 5, а не 20.
Нет обратной связи от склада. Кладовщик видит расхождение на сборке, но узнаёт об этом последним — когда сделка уже «выиграна» и клиент оплатил.
Скорость важнее проверки. У менеджера есть KPI на закрытие сделки, и звонок кладовщику ради каждого заказа не масштабируется на десятки сделок в день.

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

Резерв и блокировка: что выбрать

Есть два разных механизма, и путать их — частая ошибка при настройке связки.

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

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

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

Что настроить в связке МойСклад и Битрикс24

Если у вас в принципе ещё нет рабочей связки между МойСклад и Битрикс24 — начните не с этой статьи, а с вопроса, нужна ли она вам и в каком порядке её строить: там разбор, когда связка оправдана, а когда рано. Здесь мы предполагаем, что базовая интеграция уже есть или строится, и говорим только про её самую важную часть для торговли — механику остатка, резерва и блокировки.

Для того, что описано ниже, нужны три элемента:

Поле в карточке сделки Б24, которое показывает доступный остаток по позициям заказа — не текстом «спросить у склада», а живым числом из МойСклад.
Правило (робот или бизнес-процесс) в Б24, которое при переходе стадии создаёт заказ покупателя в МойСклад и одновременно проверяет условие по остатку.
Обратный канал — статус из МойСклад (резерв поставлен, отгружено, недостаточно остатка) должен возвращаться в сделку автоматически, а не через сообщение в чат кладовщику.

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

Шаг 1. Показывать доступный остаток в карточке сделки

Первое, что должен увидеть менеджер, открыв сделку, — не остаток «на складе» вообще, а доступный остаток: физическое количество минус то, что уже зарезервировано под другие заказы.

В карточке сделки Б24 создайте пользовательское поле (или блок в смарт-процессе) «Доступно на складе» для каждой позиции заказа.
Значение подтягивается запросом к МойСклад по артикулу в момент открытия карточки или по расписанию — раз в несколько минут, если нагрузка не позволяет делать это в реальном времени.
Показывайте именно доступный остаток (available), а не общий физический остаток — это разница, которая обычно и приводит к перепродаже.
Если позиций в заказе много, добавьте сводный индикатор по сделке целиком: «всё доступно» / «есть дефицит» — чтобы менеджер не листал каждую строку.

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

Шаг 2. Автоматический резерв при переходе стадии

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

Определите одну стадию-триггер: обычно это «Счёт выставлен» или «Договор подписан» — момент, когда сделка перестаёт быть предположением и становится обязательством перед клиентом.
При переходе на эту стадию правило Б24 создаёт в МойСклад документ заказа покупателя с позициями из сделки.
МойСклад при создании заказа покупателя резервирует указанное количество автоматически — эта настройка есть в самом документе, отдельно продумывать резерв «сбоку» не нужно.
Свяжите ID сделки Б24 и ID заказа в МойСклад — без этой связки при любой правке позже придётся сверять вручную, что к чему относится.
Изменение количества или состава позиций в сделке после резерва должно инициировать пересоздание или корректировку резерва, а не тихо расходиться с фактическим заказом в МойСклад.

Важный нюанс: резерв должен ставиться до момента, когда клиент получает подтверждение, а не после отгрузки. Иначе смысл теряется — вы просто задокументировали то, что уже случилось, вместо того чтобы предотвратить перепродажу.

Шаг 3. Блокировка сделки, если остатка не хватает

Это ядро всей механики и то, ради чего собственники в принципе идут на эту настройку.

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

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

Шаг 4. Снятие резерва при проигрыше или таймауте

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

При переводе сделки в статус «Проиграна» или «Отменена» правило Б24 должно автоматически инициировать снятие резерва в МойСклад — отдельным действием, не «когда-нибудь руками».
Задайте таймаут на резерв без движения: если сделка не переходит на следующую стадию (оплата, отгрузка) дольше установленного срока — резерв снимается автоматически, а менеджер получает уведомление.
Срок таймаута зависит от цикла сделки: для розницы и быстрых B2B-заказов это может быть 24–48 часов, для проектных продаж с длинным циклом согласования — неделя и больше.
Отдельно продумайте частичную отгрузку: если клиент забрал часть заказа, а часть отложена, — резерв должен корректироваться на остаток, а не сниматься или сохраняться полностью.

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

Шаг 5. Статус отгрузки обратно в CRM

Последнее звено — то, без которого вся связка превращается в одностороннюю передачу данных: Б24 отправляет в МойСклад, но никогда не узнаёт, что там произошло дальше.

Статусы заказа в МойСклад («в резерве», «собран», «отгружен», «отгружен частично») должны транслироваться обратно в поле или стадию сделки Б24.
Не обязательно вести отдельную стадию воронки под каждый статус склада — достаточно поля-индикатора рядом с текущей стадией продаж, чтобы менеджер и руководитель видели факт, а не только этап переговоров.
Закрытие сделки как «выиграна» логично привязывать именно к статусу «отгружено» из МойСклад, а не к моменту, когда менеджер посчитал сделку закрытой на своей стороне.
Если отгрузка задерживается — это тоже сигнал, который должен быть виден в CRM, а не только в разговорах склада между собой.

Когда этот шаг настроен, руководитель перестаёт спрашивать «а что там на складе» на планёрке: ответ уже в сделке.

Типовая ситуация: два менеджера, один остаток

Представим типичную для опта картину: на складе 10 единиц товара. Утром менеджер А обсуждает с клиентом заказ на 6 штук, к обеду — созванивается и получает согласие, но не спешит переводить сделку дальше, потому что клиент «на подумать до вечера». Параллельно менеджер Б получает заявку на 8 штук от своего клиента и в 15:00 выставляет счёт. Без резерва система в этот момент честно показывает «10 в наличии» обоим — и оба менеджера считают, что могут продать нужное количество.

Если резерв ставится автоматически при выставлении счёта, то к моменту, когда менеджер А наконец переводит свою сделку на ту же стадию, доступный остаток уже не 10, а 2 (10 минус 8, зарезервированных менеджером Б) — и блокировка на шаге 3 не даст пройти дальше с запросом на 6 штук. Менеджер А узнаёт о проблеме сразу, до звонка клиенту с подтверждением, а не после.

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

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

Когда нужен склад, а не только CRM

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

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

Признаки, что проблема на уровне склада, а не CRM:

Остаток по одному и тому же артикулу в разных источниках (Excel, память кладовщика, старая выгрузка) не совпадает.
Понятия «доступно» и «на складе» никто не разделяет — есть только одна цифра.
Резервы под заказы никто не ведёт системно — «зарезервировано» существует только в переписке или в голове.
Несколько складов, точек или каналов продаж (в том числе маркетплейсы) ведутся в одной общей таблице без разделения.

В этом случае связка с Б24 и её резервы — вторая задача, а первая — навести порядок в складском учёте: развести склады и остатки под разные каналы, если у вас несколько точек или несколько схем продаж, и настроить перемещения между ними. Похожая логика — на стыке разных каналов отгрузки, когда один и тот же остаток продаётся сразу по нескольким схемам: FBS и FBO на одном складе дают ту же перепродажу, что и два менеджера без резерва, только на уровне канала, а не человека. Ссылки на обе темы — в конце статьи.

Типичные ошибки

Резервируют по общему остатку, а не по доступному. Показывают в Б24 физическое количество без вычета уже занятого — блокировка формально есть, но перепродажа всё равно случается.
Резерв ставится вручную, «когда вспомнят». Любое ручное действие в цепочке продаж — это действие, которое иногда не выполняется. Резерв должен быть побочным эффектом смены стадии, а не отдельной задачей менеджера.
Нет таймаута на резерв. Товар зависает под забытыми или мёртвыми сделками, доступный остаток искусственно занижен для новых клиентов.
Блокировку можно обойти самому менеджеру. Если снять запрет может тот же человек, который его получил, при первом же давлении клиента блокировка перестаёт работать.
Статус отгрузки не возвращается в CRM. Связка работает только в одну сторону — руководитель и менеджер продолжают узнавать факт отгрузки по телефону, а не из системы.
Настраивают резерв и блокировку до наведения порядка в номенклатуре и остатках склада. Автоматизация над неточными данными автоматизирует саму неточность — быстрее и с виду убедительнее.
Пытаются закрыть маркетплейсы той же логикой, что и B2B-сделки. Отгрузки по FBS и резервы под B2B-заказы должны идти по разным правилам и часто — с разных складов, иначе один канал будет «съедать» остаток другого.

FAQ

Можно ли блокировать сделку без интеграции?

Частично — да, но это будет ручная проверка: поле в сделке, которое менеджер сверяет глазами с отдельным отчётом МойСклад, и правило «нельзя двигать дальше без пометки, что остаток проверен». Это лучше, чем ничего, но зависит от дисциплины, а не от системы, и при росте числа сделок в день перестаёт масштабироваться.

Резерв в МойСклад виден на маркетплейсах?

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

Кто настраивает связку — CRM или склад?

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

Что если товар в пути, но ещё не на складе?

Это отдельный статус, не «доступно». Если вы продаёте под ожидаемую поставку, заведите это как осознанную пометку в сделке («под заказ», с датой) — не как обход блокировки, а как отдельный, прозрачный для клиента и менеджера сценарий продажи с другим сроком.

Сколько держать резерв по умолчанию?

Ориентир: 24–48 часов для розничных и быстрых B2B-заказов, до 5–7 дней для сделок с длинным циклом согласования или предоплатой по счёту. Точный срок зависит от вашего цикла продажи — начните с одного значения и скорректируйте через месяц по факту, сколько резервов снималось по таймауту, а сколько — вручную раньше срока.

AmoCRM — та же логика?

Да, механика резерва и блокировки не зависит от конкретной CRM — важны стадии воронки, поля и правила автоматизации, которые есть в AmoCRM не хуже, чем в Б24. Разница между системами — в глубине настройки автоматизации и в типовых интеграционных модулях с МойСклад, которые могут отличаться по готовым сценариям.

Нужен ли отдельный склад под резервы B2B?

Не отдельный склад, а отдельная логика резервирования на общем складе — если у вас также идут отгрузки по FBS или другим каналам. Смешивать резервы B2B и автоматические выгрузки остатков маркетплейсов на одном необособленном остатке — частая причина той же перепродажи, только на уровне канала, а не менеджера.

Хотите резерв и блокировку в вашей связке МойСклад и Битрикс24? Диагностика 15 минут — разберём вашу воронку и скажем, что настраивать первым.

Читайте также:

Автор: Кирилл Титов, CRMHUB — партнёр МойСклад и Битрикс24. 17 лет в складе и операционных процессах.