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