Поиск складских аномалий в 1С с ИИ: какие движения отправлять на проверку
Необычное списание может быть ошибкой, законной операцией или следствием неполных данных. Разбираем, как связать историю движений 1С с моделью аномалий и получить полезную очередь проверки.
На складе заметили крупное списание. Для одного товара оно действительно необычно, для другого соответствует обычной месячной операции. Правило «показывать всё больше ста единиц» засыпает контролёра сообщениями и пропускает небольшие, но странные комбинации. Машинное обучение может помочь выделить такие события, если сначала определить, что именно анализируется.
Ниже — проектная схема контроля движений по данным 1С. Она не предсказывает продажи и не устанавливает виновность сотрудника. Её результат — список операций с основаниями для проверки. Изменять документы по одному баллу модели нельзя.
Отделите нарушения правил от необычного поведения #
Обязательный реквизит, запрещённый тип операции или нарушенная связь документов проверяются явным правилом. Модель не нужна, чтобы каждый раз заново угадывать известное ограничение. При этом отрицательный остаток сам по себе ещё требует контекста: правила его контроля и момент появления данных зависят от настройки учёта.
В описании складских возможностей 1С:ERP отдельно представлены пересчёт, регистрация расхождений и отражение фактических изменений запасов. Это разные операции. Отчёт об аномалиях не должен смешивать ошибку проведения с законной инвентаризационной корректировкой.
Начните с перечня проверок: какие ошибки точно известны, какие отклонения можно оценить статистически и какие сочетания требуют более сложной модели. Результаты разных проверок полезно сохранять раздельно. Тогда сотрудник понимает, что перед ним: нарушение формального условия или необычное событие без доказанной ошибки.
Одна строка обучающих данных может соответствовать строке движения, целому документу или суточному итогу по товару и складу. Эти варианты отвечают на разные вопросы. Суточный итог способен скрыть ошибочную операцию, компенсированную обратным движением. Анализ каждой строки без контекста документа, напротив, может сделать нормальное перемещение похожим на расход.
Для первого сценария удобно определить событие и его связи: документ-основание, вид движения, товар, склад, количество в базовой единице и время. Для перемещения нужно учитывать обе стороны по правилам конфигурации. Нельзя объявлять исходящую часть потерей, не проверив связанную приёмку и допустимую задержку её отражения.
У количества должен быть понятный масштаб. Десять коробок и десять штук нельзя подавать модели как одинаковое значение. Номенклатуру с разной размерностью не сравнивают одним сырым числом. Признак может описывать отклонение от обычного объёма данного товара или группы, а не только абсолютное количество.
Для проверки могут быть полезны величина движения, частота аналогичных операций, отношение к предыдущему запасу, время и тип основания. Но информация должна быть доступна в момент, когда система предполагает выдать сигнал.
Если обучить модель на итоговом статусе «ошибка подтверждена», а в рабочем процессе этого статуса ещё нет, результат проверки окажется недостижимым. То же относится к исправлению, которое бухгалтер внёс через неделю. Исторический набор собирают с учётом времени появления сведений, а не только по текущему состоянию документов.
Разные режимы работы требуют контекста. Переезд склада, ежегодная инвентаризация, запуск новой линии и массовая возвратная операция могут резко изменить распределение движений. Такие периоды не нужно безусловно удалять: их отмечают и решают, где нужны отдельные правила или контрольная группа.
Для стабильного потока начните с понятного базового варианта: лимит по утверждённому правилу, отклонение от медианы сравнимой группы или редкое сочетание типа операции и склада. Если эти проверки уже дают полезную очередь, усложнение должно иметь измеримое преимущество.
Подход
Для какой задачи подходит
Что нужно объяснить пользователю
Явное правило
Известное недопустимое состояние
Какое условие нарушено
Статистическое отклонение
Необычная величина в сравнимой группе
С чем сравнивали и за какой период
Модель аномалий
Необычные комбинации нескольких признаков
Какие наблюдаемые признаки требуют проверки
Один из доступных методов — Isolation Forest в scikit-learn . Он оценивает необычность наблюдений через их изоляцию в случайных деревьях. Его оценка не является вероятностью мошенничества. Порог и состав признаков проверяют на своей задаче; настройка доли выбросов не доказывает, что такая доля операций ошибочна.
Языковой модели можно передать подтверждённые признаки события и предложить короткое объяснение для контролёра. Сам расчёт необычности и данные движения остаются результатом программы. Текст не должен выдумывать причину: «объём выше обычного для этой группы» допустимо при наличии расчёта, «сотрудник пытался скрыть недостачу» из него не следует.
В карточке сигнала нужны ссылка на операцию, причина отбора, сравнимые события и время расчёта. Сотрудник выбирает итог: ошибка данных, допустимая операция, требует уточнения либо проблема настройки контроля. Только подтверждённое решение запускает предусмотренный процесс исправления.
Учебный пример: из двадцати проверенных сигналов семь привели к подтверждённым ошибкам. Доля полезных срабатываний составила 35%. Эта величина ничего не говорит о том, сколько ошибок осталось среди остальных операций. Для оценки пропусков нужна независимая проверочная выборка, включающая события без сигнала.
Помимо качества считают нагрузку: сколько карточек сотрудник может рассмотреть и какие ошибки важнее найти. Высокая доля правильных сигналов при огромной очереди тоже может быть непригодна. Порог выбирают с учётом серьёзности события и доступной проверки, а не по красивому числу в демонстрации.
Обучение и приёмку разделяют по времени. На новом периоде сохраняют исходные сигналы и сравнивают их с последующим разбором, не подправляя оценку задним числом. Отдельно проверяют новые товары, склады с короткой историей и смену режима работы.
Интеграция с 1С должна позволять восстановить, по какой версии данных и модели появился сигнал. После исправления документа сигнал может потерять актуальность; его закрывают или пересчитывают с сохранением истории. Старое объяснение нельзя показывать как оценку уже изменённой операции.
Да, с явных правил и предметной проверки событий. Для модели нужно достаточно сравнимой истории; универсального минимального числа строк нет. Если почти все операции уникальны, более сложный алгоритм не создаст отсутствующую норму сравнения.
Сигнал относится к операции, а не к намерению человека. Ошибка загрузки, регламентный пересчёт и реальное нарушение могут выглядеть похоже. Решения о действиях сотрудника требуют отдельной проверенной процедуры и не должны следовать из оценки модели автоматически.
NetLabCS поможет выбрать события 1С, подготовить признаки и настроить очередь контроля с понятными основаниями при разработке решений на базе ИИ . Для обсуждения проекта выберите одну операцию и несколько примеров подтверждённых ошибок: сравним правила и модель до расширения на весь склад.
