Резерв товаров в Битрикс24: как связать остаток, сделку и отгрузку
Два менеджера обещали клиентам последнюю единицу товара. Разбираем, что подтверждает резерв, как выбрать систему учёта и что проверить при частичной отгрузке.
На складе остался один комплект оборудования. Два менеджера открыли карточку почти одновременно и подтвердили поставку разным клиентам. Оба видели остаток, но между просмотром и обещанием не было общего подтверждения. Добавление ещё одной колонки «В наличии» не устранит эту гонку.
Нужен понятный переход от намерения продать к подтверждённому резерву, а затем к фактической отгрузке. При работе Битрикс24 вместе с учётной системой важно решить, где принимается каждое решение. Разберём учебный процесс и ограничения штатного резервирования, которые нужно учитывать до запуска.
Остаток, доступность и резерв — разные показатели #
Физический остаток показывает учтённое количество на складе. Доступность зависит ещё от действующих резервов, ограничений продажи и состояния товара. Плановая поставка не становится остатком только потому, что её дату записали в сделку.
Резерв фиксирует связь количества со сделкой или заказом по правилам конкретного контура. Он может иметь срок и собственные условия изменения. Отгрузка подтверждается соответствующей операцией учёта. Если эти состояния смешать, система будет одновременно считать товар свободным, обещанным и уже проданным.
В документации Битрикс24 о резервировании есть важная деталь: количество резерва не должно превышать продаваемое в сделке, но может превышать доступный остаток. Там же указано ограничение по режиму работы складского учёта. Поэтому фраза «включим резерв, и двойная продажа невозможна» без проверки конфигурации неверна.
До запуска определите бизнес-правило: допускается ли обещание под будущую поставку, какие товары продаются только из наличия и кто согласует превышение. Если нужен строгий контроль доступности, он должен проверяться в согласованной системе при подтверждении операции, а не только при открытии карточки.
Для уникального оборудования дополнительно требуется учёт конкретной единицы: серийного или инвентарного номера. Количественный резерв артикула не обязательно закрепляет именно тот экземпляр, который согласован с покупателем. Поддержку такого сценария проверяют по используемой учётной модели и доработкам.
Выберите одну систему, которая подтверждает резерв #
Если товарный учёт ведётся в 1С, менеджеру в CRM нужен результат её решения: подтверждённое количество, склад, срок и идентификатор операции. Сам факт отправки запроса не равен подтверждению. При ошибке связи сделка должна остаться в состоянии ожидания или ручной проверки.
Если учёт полностью находится в Битрикс24, проверяют его режимы и права, не создавая параллельный независимый остаток в таблице. У каждого изменяемого поля должен быть владелец. Иначе две системы начнут одновременно исправлять один резерв, возвращая значения друг другу.
Стандартный модуль обмена может передавать товары, остатки, резервы и отгрузки , но состав и поведение интеграции нужно сверять с установленными конфигурациями и настройками. Название модуля не доказывает, что ваш сценарий подтверждения уже покрыт.
В настройках складского учёта предусмотрены разные режимы резервирования. Конкретный выбор зависит от процесса продажи. Ранний резерв помогает удержать дефицитный товар, но неподтверждённые сделки могут надолго заблокировать доступность. Поздний резерв уменьшает блокировки, зато требует аккуратной формулировки обещаний клиенту.
Срок резерва должен быть виден менеджеру. До его истечения можно запросить продление по согласованному правилу; после истечения нужно заново подтвердить доступность. Нельзя считать, что товар по-прежнему закреплён, только потому что сделка не закрыта.
Отдельно проверьте, кто может менять режимы и срок, а кто — только работать с резервом своей сделки. Полномочия администратора учёта и менеджера различаются; массовое изменение настроек не должно становиться обходным способом подтвердить один спорный заказ.
Частичная отгрузка должна изменять только исполненную часть #
В учебном примере клиент заказал пять единиц, из них две отгрузили. В системе остаются сведения о двух переданных единицах и обязательстве по трём оставшимся. Переход всей сделки в стадию «отгружено» не должен скрывать недопоставку.
При отмене оставшейся части освобождают соответствующее количество по правилам учёта. При возврате товар сначала проходит предусмотренную проверку и отражение в учётной системе. Возвращённая единица не всегда сразу доступна для новой продажи: может потребоваться осмотр или другая классификация состояния.
Документ отгрузки и событие обмена связывают устойчивым идентификатором. Повторная доставка события не должна ещё раз уменьшать резерв. Исправление проведённого документа обрабатывают как изменение известной операции, а не как неизвестную новую продажу.
Используйте выделенные тестовые позиции и согласованный порядок очистки результатов. Проверка на реальном дефицитном товаре способна вмешаться в рабочие обещания клиентам.
— Два менеджера одновременно запрашивают последнюю доступную единицу.
— Запрашивается больше текущего наличия: результат соответствует принятой политике.
— Ответ из 1С задержался: CRM не показывает неподтверждённый резерв как успешный.
— Отгружена только часть заказа: остаток обязательства виден отдельно.
— Срок резерва истёк до оплаты: доступность проверяется заново.
— Событие отгрузки пришло повторно: количество не изменилось второй раз.
— Заказ отменён после частичной отгрузки: освобождается только неисполненная часть.
Сверяйте конкретные позиции и документы между системами. Совпадение общей суммы резервов не доказывает, что они относятся к правильным клиентам и складам. В отчёте о расхождении должны быть идентификаторы, по которым сотрудник найдёт причину.
Достаточно ли показывать менеджеру текущий остаток? #
Нет, если между просмотром и подтверждением товар может забрать другой заказ. Показатель помогает ориентироваться, но обязательство подтверждают отдельной операцией. Интерфейс должен различать справочное наличие и уже закреплённое количество.
Можно ли запретить продажу сверх остатка только роботом? #
Это зависит от всех путей изменения товара и используемого режима. Если другое приложение, импорт или учётная система обходят робота, правило будет неполным. Нужна проверка в точке принятия решения и испытание параллельных запросов.
NetLabCS поможет проверить интеграцию Битрикс24 с 1С и системами учёта : владельца резерва, подтверждения, частичные отгрузки и повторные события. Опишите вашу схему : где ведутся остатки, когда обещается товар и в каких ситуациях возникают расхождения.
