← На главную

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

Ограничения типовой конфигурации

В типовой «1С:Управление торговлей 11.5» отсутствует механизм мгновенных интерактивных оповещений. Вы не увидите всплывающих окон, push-уведомлений или системных сообщений для сотрудников прямо в момент проведения документа реализации, если остаток упал ниже заданного порога. Типовая подсистема оповещений предназначена в первую очередь для взаимодействия с клиентами (уведомления об оплате, изменении статусов заказов) и не рассчитана на реакцию по внутренним товарным триггерам.

Нюансы учета: физический и свободный остаток

Прежде чем приступать к настройке уведомлений, проанализируем ситуацию с остатками. Крайне важно понимать разницу между физическим и свободным остатком, так как уведомление о наличии 1 штуки может ввести в заблуждение.

• Физический остаток — это фактическое наличие товара на полке. Эти данные хранятся в регистре накопления ТоварыНаСкладах.
• Свободный остаток — это товар, который реально доступен для продажи. Он рассчитывается через регистр РаспределениеЗапасов. Этот показатель учитывает зарезервированные товары под заказы клиентов, ожидаемые поступления и графики отгрузок.

На практике товар может лежать на складе в количестве 10 штук (физический остаток), но свободный остаток уже будет равен 0 из-за активных резервов. Поэтому контролировать и рассылать уведомления правильнее именно по свободному остатку.

Способ 1. Тонкая настройка рассылки отчетов

Это самый простой и штатный метод без привлечения программистов. Разберем по шагам, как его настроить:

1. Откроем вариант отчета «Остатки и доступность товаров».
2. Перейдем в настройки структуры отчета и зададим отбор по показателю В наличии (если нужен физический остаток) или Доступно (для свободного остатка). Установим условие: «Меньше или равно 1».
3. Сохраним этот вариант отчета.
4. Создадим новую Рассылку отчетов, выберем сохраненный вариант и укажем расписание (например, каждые 2 часа или раз в день).
5. Чтобы сотрудники не получали пустые письма, когда дефицита нет, в настройках рассылки обязательно установим признак отправки только при наличии данных в отчете.

Способ 2. Подсистема поддержания запасов и обеспечение потребностей

Вместо реактивных уведомлений типовая УТ 11.5 предлагает проактивную модель управления запасами. Настроим методы обеспечения потребностей:

1. Для нужной номенклатуры зададим метод обеспечения, например, «Минимум – максимум».
2. Укажем минимальный остаток — 1 шт.
3. Когда расчетный остаток опускается до этого значения или ниже, позиция автоматически появится в рабочем месте «Формирование заказов по потребностям» со статусом потребности к заказу.

Ответственный сотрудник (закупщик) видит все дефицитные позиции в едином окне и может сразу формировать заказы поставщикам, без необходимости читать множество разрозненных писем.

Способ 3. Внешняя обработка по расписанию (без изменения конфигурации)

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

1. Подключим её в качестве регламентного задания через подсистему дополнительных отчетов и обработок.
2. Обработка с заданной периодичностью будет выполнять запрос к регистру РаспределениеЗапасов, выявляя позиции с остатком меньше или равным единице.
3. Далее обработка может отправлять оповещения по электронной почте, через API бота в мессенджер (например, Telegram) или создавать «Задачу» во встроенной подсистемы бизнес-процессов.

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

Способ 4. Расширение конфигурации с подпиской на события

Если бизнес-процесс жестко требует мгновенной реакции на снижение остатка именно при проведении документа, придется использовать расширение конфигурации.

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

Не следует отправлять внешние уведомления (например, через HTTP-запросы в мессенджеры или отправку писем) синхронно внутри транзакции проведения документа. Это неизбежно замедлит работу пользователей и может привести к транзакционным блокировкам в системе. Оптимальный архитектурный подход — при проведении документа помещать событие дефицита в отдельную очередь (специально созданный регистр сведений). Затем отдельное фоновое задание, работающее по расписанию (например, каждую минуту), будет читать эту очередь и выполнять саму отправку уведомлений.