Анализ остатков в 1С: как находить дефицит и аномалии

Как поставить задачу ИИ-сотруднику VibeLab

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

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

Результат удобно делить на три очереди:

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

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

Как выглядит один сигнал

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

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

Не превращайте предупреждения в шум

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

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

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

Есть важная граница: Analytics Bridge только читает и агрегирует данные. Он не исправляет остатки и не проводит документы. Если сотрудник нашёл расхождение, действие в 1С выполняет ответственный человек или отдельный согласованный процесс. Это сохраняет понятную ответственность за учёт.

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

Как проверить, что сигнал действительно полезен

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

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

Когда правила устоялись, ИИ-сотрудник может выдавать ежедневную короткую сводку: пять критичных позиций, новые необычные движения и список вопросов владельцам данных. Формат должен быть достаточно компактным, чтобы его читали до начала закупочного дня. Детали среза остаются доступными для проверки каждой строки.

Первый рабочий сценарий

Возьмите список двадцати позиций, которые часто заканчиваются или долго лежат. Сверьте их остатки, резервы и движения с отчётом 1С за несколько дат. Затем задайте два-три правила исключений и попросите сотрудников неделю отмечать полезные и ложные сигналы. Так появится регламент, который действительно помогает закупке.

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