30 450 позиций в 1С: что делать после того, как отчет нашел ошибки склада

На базе производственной компании проверили 30 450 позиций номенклатуры. В результате нашли 7 597 позиций без артикула, 7 030 без штрихкода, дубли кодов и штрихкодов, отрицательные остатки на двух складах и расхождения между номенклатурой 1С и каталогом сайта.

Ни одна из этих проверок не требует нейросети, чтобы определить сам факт нарушения. Рынок давно решает похожие задачи обычными запросами и СКД-отчетами. На Инфостарт такие разработки стоят от 6 100 до 11 691 рублей, а у одного отчета о расхождениях - 1 297 скачиваний. Спрос на задачу есть, но сам факт «мы тоже нашли расхождение» не является новым подходом.

Более интересный вопрос начинается после выполнения запроса: как превратить таблицу из сотен или тысяч строк в понятную, проверяемую очередь работы, без попытки автоматически исправить учёт вместо человека?

Что именно проверяли

В кейсе был не абстрактный «анализ качества данных», а набор отдельных правил. Каждое правило отвечало на конкретный вопрос к базе:

Важно не складывать числа по строкам в «общее количество ошибок». Одна позиция может одновременно быть без артикула и без штрихкода, поэтому 7 597 и 7 030, это размеры двух выборок, а не обязательно разные карточки.

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

Почему отдельного отчета иногда достаточно

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

Это подтверждает и рынок Инфостарта:

• отчет о расхождениях фактического и бухгалтерского учёта стоит 10 990 рублей, отдельно предлагаются поддержка и обновления;
• контроль остатков для БП продаётся за 6 100 рублей в год;
• разработка для контроля операций прихода и перемещения ТМЦ стоит 11 691 рубль;
• у первого решения указано 1 297 скачиваний и 22 отзыва.

То есть задача «найти расхождение» уже имеет понятный rule-based класс решений. Добавлять к нему ИИ только ради более современного ярлыка нет смысла.

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

1. помнить, какие отчёты и с какой периодичностью запускать;
2. понимать технические названия полей и регистров;
3. отделять допустимые исключения от реальной проблемы;
4. находить исходный объект в 1С;
5. определять, что проверять сначала.

Именно здесь таблица перестаёт быть конечным результатом и становится сырьём для аудита.

Единица результата - не строка отчета, а проверяемая находка

Для разбора удобнее привести разные проверки к одному контракту. Минимальная находка может содержать:

• правило, которое сработало;
• объект или строку из базы как основание;
• понятное описание без терминов внутренней реализации;
• серьезность;
• следующий шаг проверки;
• ссылку, по которой пользователь открывает исходный объект в 1С.

Например, вместо строки с техническими полями пользователь получает смысловой блок:

Отрицательный остаток на складе
По позиции N на складе S расчетный остаток ниже нуля. Основание - движение и строка из текущей базы. Проверьте последние документы поступления, перемещения и реализации. Решение об исправлении остаётся за ответственным сотрудником.

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

Ссылка на объект решает вторую практическую проблему. Пользователь не должен копировать номер из отчета, искать раздел и восстанавливать контекст вручную. Находка ведёт к документу или карточке, на которой основан вывод. Проверка занимает один переход, но окончательное решение всё равно принимает человек.

Несколько правил за один запуск

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

Такой оркестратор не делает правила умнее. Он решает организационную задачу:

• не забыть отдельный отчет;
• собрать находки разных типов в одну очередь;
• отсортировать их по серьезности;
• сохранить основание и переход к объекту;
• отделить расчет факта в 1С от текстового объяснения.

Это не «аудит всего склада». Состав правил должен быть ограничен заранее и проверен на конкретной конфигурации. УТ, КА, ERP и УНФ по-разному хранят операционные данные; одинаковое название бизнес-проверки не означает одинаковый запрос.

Как не утонуть в ложных срабатываниях

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

1. Подтверждённый дефект. Синтетически или вручную внесенный случай обязан попасть в результат.
2. Допустимое исключение. Услуга без штрихкода, свежий черновик или карточка, помеченная на удаление, не должны автоматически становиться проблемой.
3. Пограничный случай. Его система показывает для проверки, но не называет ошибкой без решения пользователя.

Практическая метрика здесь, не количество найденных строк, а доля находок, которые ответственный сотрудник подтвердил как реальные проблемы. В описываемом кейсе такой замер продуктового эффекта не проводился, поэтому делать выводы об экономии времени или точности автоматической системы по этим цифрам нельзя.

Где в этой схеме нужен ИИ

Не для поиска пустого артикула и не для вычисления отрицательного остатка. Эти факты надежнее считает 1С по детерминированным правилам.

Языковой слой полезен после расчёта:

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

При этом учёт должен оставаться read-only: никаких автоматических Записать или Провести. Находка показывает основание, сотрудник открывает объект и сам принимает решение.

Что подтвердил кейс - и чего он не подтвердил

Подтверждено:

• в базе из 30 450 позиций есть крупные выборки незаполненных атрибутов;
• обнаружены дубли кодов и штрихкодов;
• отрицательные остатки присутствуют на двух складах;
• есть расхождения между номенклатурой 1С и каталогом сайта;
• набор отдельных правил дает конкретный перечень для последующего разбора.

Не подтверждено:

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

Компания в статье не названа: письменного согласия на раскрытие имени нет. Это производственная компания с товарным и складским учётом в 1С; большего для разбора методики не требуется.

Вывод

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

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

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

Ссылки

• Отчёт о расхождениях факт/учёт
• Контроль остатков в УНФ/БП
• Контроль прихода и перемещения ТМЦ