Данные в 1С и BI не совпадают не только из-за технической ошибки. Причина может быть в разных правилах расчета, неполной выгрузке, сбое трансформации или настройках самого отчета.
В статье разберем, как локализовать расхождение, проследить путь показателя от 1С до BI и выстроить регулярный контроль качества данных.
На дашборде выручка одна, а в отчете 1С — другая. Руководителю нужно решить, какой цифре доверять при планировании закупок, бюджета или премий. Пока причина расхождения не найдена, решение на основе одного из отчетов может оказаться неверным.
Особенно опасны ошибки, которые не выглядят как сбой. Например, показатель рассчитывается по пяти таблицам. Четыре из них обновились, а в пятую не поступили сведения о логистических расходах. Дашборд все равно покажет результат, но итог окажется завышенным. Внешне цифра выглядит правдоподобно, поэтому проблему обнаруживают не сразу.
Однако прежде чем искать техническую ошибку, нужно убедиться, что отчеты действительно показывают одну и ту же метрику.
Разные значения не всегда означают ошибку.
Отчеты могут отражать разные метрики или использовать разные условия расчета:
Перед сверкой для показателя фиксируют:

Ограничения доступа проверяют не только в BI, но и в 1С, DWH и промежуточных слоях. Пользователи с разными ролями могут видеть разные наборы записей, даже если открывают один дашборд. Поэтому сравнивать только отчет 1С и итоговую цифру в BI недостаточно. Сначала нужно определить, в каком периоде, подразделении или документе показатели перестают совпадать, а затем последовательно проверить путь этих данных от BI до источника.
После локализации расхождения нужно проследить путь показателя от BI до исходных записей в 1С.
Такой подход называют Data Lineage — прослеживаемостью данных от итогового показателя в BI до исходной записи в 1С.
Проверку ведут в обратном порядке и на каждом этапе используют один локализованный фрагмент: день, сотрудника или документ.
После проверки общей цепочки нужно последовательно исключить причины расхождения. Сначала убеждаются, что из 1С поступили все необходимые данные. Если выгрузка полная, проверяют, как информация загрузилась в хранилище и изменилась при формировании витрины.
Сначала устанавливают, вся ли информация поступила из системы-источника.
Для этого проверяют:
При некорректной догрузке новые строки добавляются без обновления прежних записей, из-за чего появляются дубли.
Иногда сбой затрагивает только одну из связанных таблиц. Итоговый показатель продолжает рассчитываться, но не учитывает часть информации. Поэтому наличие цифры на дашборде еще не подтверждает полноту загрузки.
Если выгрузка из 1С прошла полностью, полученные данные сравнивают с таблицами DWH до преобразований. Совпадение строк, сумм и периода подтверждает, что ошибка возникла на следующем этапе — при обработке или подготовке витрины.
В витрине проверяют:
Одной итоговой суммы недостаточно. Пропущенная запись и дубль с таким же значением способны компенсировать друг друга. Общий результат совпадет, хотя детализация останется неверной.
После этого сравнивают результаты до и после каждого преобразования. Если этапы обработки наглядны, а промежуточные значения сохраняются, проще определить операцию, после которой появилось расхождение. Найденный участок исправляют, а затем меняют правила, чтобы ошибка не повторилась.
Расчетную логику по возможности сосредотачивают в одном слое: DWH, ETL-процессе или BI. Если одна формула распределена между несколькими системами, сложнее понять, на каком этапе изменился результат.
Изменения в источниках, правилах выгрузки, ETL-преобразованиях и формулах проверяют до обновления отчетности. При отклонении публикацию данных в BI останавливают до устранения причины.
Надежная сверка строится на трех принципах: единых правилах расчета, локализации расхождения и контроле каждого этапа от 1С до BI.
Такой подход помогает обнаружить сбой до того, как неверный показатель попадет в управленческую отчетность.
В статье разберем, как локализовать расхождение, проследить путь показателя от 1С до BI и выстроить регулярный контроль качества данных.
Чем опасны расхождения между 1С и BI
На дашборде выручка одна, а в отчете 1С — другая. Руководителю нужно решить, какой цифре доверять при планировании закупок, бюджета или премий. Пока причина расхождения не найдена, решение на основе одного из отчетов может оказаться неверным.
Особенно опасны ошибки, которые не выглядят как сбой. Например, показатель рассчитывается по пяти таблицам. Четыре из них обновились, а в пятую не поступили сведения о логистических расходах. Дашборд все равно покажет результат, но итог окажется завышенным. Внешне цифра выглядит правдоподобно, поэтому проблему обнаруживают не сразу.
Однако прежде чем искать техническую ошибку, нужно убедиться, что отчеты действительно показывают одну и ту же метрику.
Когда расхождение допустимо
Разные значения не всегда означают ошибку.
Отчеты могут отражать разные метрики или использовать разные условия расчета:
- период,
- дату учета,
- фильтры,
- статусы документов,
- группировку и формат представления.
Перед сверкой для показателя фиксируют:
- источник,
- формулу,
- дату и период расчета,
- фильтры,
- статусы.
Где искать причину расхождения между 1С и BI
Между исходными данными в 1С и показателем на дашборде чередуются процессы и слои данных:

Выгрузка и ETL — это процессы. DWH и витрина — слои, в которых хранятся данные до и после обработки.
Такое разделение важно для проверки: в слоях сравнивают строки, суммы и детализацию, а в процессах — статусы, логи и результаты отдельных операций.
Расследование начинают с BI, где обнаружено расхождение, и постепенно двигаются к источнику.
Такое разделение важно для проверки: в слоях сравнивают строки, суммы и детализацию, а в процессах — статусы, логи и результаты отдельных операций.
Расследование начинают с BI, где обнаружено расхождение, и постепенно двигаются к источнику.
| Этап проверки | Что проверяют | Как трактовать результат |
|---|---|---|
| BI-отчет | Период, фильтры, формулу, группировки и права доступа | Если BI не совпадает с витриной при одинаковых условиях, ошибка находится в настройках или расчетах отчета |
| Витрина данных | Итоговые значения и детализацию по тем же фильтрам | Если витрина совпадает с BI, проблему ищут на предыдущих этапах |
| ETL-процесс | Каждую промежуточную таблицу и правила ее формирования | Этап, после которого изменились значения, указывает на ошибочное преобразование |
| Сырые таблицы DWH | Строки, суммы, даты и статусы в сравнении с 1С | Расхождение между 1С и сырым слоем указывает на проблему при выгрузке |
| Выгрузка из 1С | Статус выполнения, время обновления, период и ошибки в логах | Проверка показывает, все ли изменения из источника поступили в DWH |
| 1С | Исходные документы, реквизиты, статусы и суммы | Здесь уточняют, какие данные должны были пройти по всей цепочке |
Ограничения доступа проверяют не только в BI, но и в 1С, DWH и промежуточных слоях. Пользователи с разными ролями могут видеть разные наборы записей, даже если открывают один дашборд. Поэтому сравнивать только отчет 1С и итоговую цифру в BI недостаточно. Сначала нужно определить, в каком периоде, подразделении или документе показатели перестают совпадать, а затем последовательно проверить путь этих данных от BI до источника.
С чего начать сверку данных между 1С и BI
Проверка всего дашборда или массива за несколько лет усложняет поиск причины. Сначала расхождение локализуют — находят небольшой участок, на котором показатели перестают совпадать.
Сверку проводят поэтапно:
Сверку проводят поэтапно:
- Выбирают конкретный показатель. Например, выручку, количество продаж или остатки.
- Фиксируют условия расчета. Период, дату, фильтры, статусы документов и права пользователя.
- Определяют контрольный источник. Это может быть отчет 1С, набор документов или исходная таблица, которую принимают за основу сверки.
- Сужают выборку. Сначала проверяют месяц, затем день, подразделение, сотрудника или отдельный документ.
- Сравнивают итог и детализацию. Совпадения общей суммы недостаточно: пропуски и дубли иногда компенсируют друг друга.
- Фиксируют проблемный участок. После этого проверяют, как выбранные записи прошли через выгрузку, DWH, витрину и BI.
Как найти ошибку по всей цепочке данных
После локализации расхождения нужно проследить путь показателя от BI до исходных записей в 1С.
Такой подход называют Data Lineage — прослеживаемостью данных от итогового показателя в BI до исходной записи в 1С.
Проверку ведут в обратном порядке и на каждом этапе используют один локализованный фрагмент: день, сотрудника или документ.
| Этап | Что сравнить | На что указывает расхождение |
|---|---|---|
| BI | Формулу, фильтры, используемые поля и права | Ошибка в настройках отчета |
| Витрина | Итоговые значения и детализацию | Ошибка отбора, группировки или расчета |
| ETL | Результаты до и после преобразования | Ошибка в формуле или объединении данных |
| DWH | Исходные и обработанные таблицы | Ошибка загрузки или обработки |
| Выгрузка | Количество строк, суммы и загруженный период | Неполная или повторная передача данных |
| 1С | Документ, реквизиты, статус и сумму | Ошибка в исходных данных или условиях отчета |
После проверки общей цепочки нужно последовательно исключить причины расхождения. Сначала убеждаются, что из 1С поступили все необходимые данные. Если выгрузка полная, проверяют, как информация загрузилась в хранилище и изменилась при формировании витрины.
Проверить полноту выгрузки из 1С
Сначала устанавливают, вся ли информация поступила из системы-источника.
Для этого проверяют:
- дату и время последнего обновления; статус выполнения задачи;
- ошибки и предупреждения в логах; количество документов или строк;
-
суммы и другие контрольные показатели; обновление всех таблиц, участвующих в расчете.
При некорректной догрузке новые строки добавляются без обновления прежних записей, из-за чего появляются дубли.
Иногда сбой затрагивает только одну из связанных таблиц. Итоговый показатель продолжает рассчитываться, но не учитывает часть информации. Поэтому наличие цифры на дашборде еще не подтверждает полноту загрузки.
Сверить DWH и витрину с 1С
Если выгрузка из 1С прошла полностью, полученные данные сравнивают с таблицами DWH до преобразований. Совпадение строк, сумм и периода подтверждает, что ошибка возникла на следующем этапе — при обработке или подготовке витрины.
В витрине проверяют:
- количество строк;
- суммы и количественные показатели; даты и статусы;
- ключи документов;
- справочники;
- детализацию по клиентам, товарам или подразделениям.
Одной итоговой суммы недостаточно. Пропущенная запись и дубль с таким же значением способны компенсировать друг друга. Общий результат совпадет, хотя детализация останется неверной.
После этого сравнивают результаты до и после каждого преобразования. Если этапы обработки наглядны, а промежуточные значения сохраняются, проще определить операцию, после которой появилось расхождение. Найденный участок исправляют, а затем меняют правила, чтобы ошибка не повторилась.
Как устранить причины повторных расхождений
После локализации расхождения недостаточно исправить отдельную запись или пересчитать отчет. Нужно устранить причину: скорректировать правила выгрузки, ETL-преобразования, формулы, связи между справочниками или настройки BI. Затем проверки встраивают в процесс обновления отчетности, чтобы некорректные данные не доходили до дашборда.
Для каждой метрики фиксируют источник, формулу, дату, фильтры и статусы. На технических этапах сохраняют логи, время обновления, результаты выполнения задач и промежуточные расчеты.
Пример регламента контроля
Для каждой метрики фиксируют источник, формулу, дату, фильтры и статусы. На технических этапах сохраняют логи, время обновления, результаты выполнения задач и промежуточные расчеты.
Пример регламента контроля
| Что контролировать | Когда | Ответственный | Что фиксировать |
|---|---|---|---|
| Выгрузку из 1С | После каждого обновления | IT-специалист или инженер данных | Статус, ошибки, время обновления, количество строк |
| Ключевые показатели | После обновления отчетности или по установленному графику | Ответственное подразделение и аналитик | Период, формулу и результат сверки |
| Справочники | После изменений и периодически | Data-stewart (специалист, отвечающий за качество справочных данных) | Дубли, ключи и несопоставленные записи |
| BI-дашборд | После обновления или изменения отчета | BI-аналитик | Актуальность данных, фильтры, формулы и права |
Расчетную логику по возможности сосредотачивают в одном слое: DWH, ETL-процессе или BI. Если одна формула распределена между несколькими системами, сложнее понять, на каком этапе изменился результат.
Изменения в источниках, правилах выгрузки, ETL-преобразованиях и формулах проверяют до обновления отчетности. При отклонении публикацию данных в BI останавливают до устранения причины.
Какие инструменты используют на разных этапах работы с данными
Когда каждый этап обработки данных прозрачен, расхождение проще локализовать. Видно, где остановилась загрузка, какие таблицы обновились, после какого преобразования изменился результат и какие сведения поступили в витрину. Поэтому при регулярной сверке важно контролировать не только итоговые показатели, но и весь путь данных от источника до BI.
Регулярный контроль проще выстроить с помощью специализированных инструментов. Они выполняют отдельные этапы работы с данными: автоматизируют выгрузку и преобразования, фиксируют выполнение процессов и поддерживают обратную загрузку в 1С.
Например, для такой архитектуры используют Экстрактор данных 1С в BI и DVT.
Каждый инструмент закрывает отдельный участок и не заменяет DWH, BI-систему или всю интеграционную архитектуру. Такое разделение помогает быстрее определить, где искать причину расхождения: при выгрузке, преобразовании, подготовке витрины.
Регулярный контроль проще выстроить с помощью специализированных инструментов. Они выполняют отдельные этапы работы с данными: автоматизируют выгрузку и преобразования, фиксируют выполнение процессов и поддерживают обратную загрузку в 1С.
Например, для такой архитектуры используют Экстрактор данных 1С в BI и DVT.
- Экстрактор 1С передает информацию из 1С во внешнюю базу, DWH или BI-систему. В нем настраивают состав и расписание выгрузки, в том числе инкрементальную передачу изменений.
- DVT используют для объединения источников, преобразования данных и формирования витрин. Визуальный ETL-сценарий показывает последовательность операций и промежуточные результаты.
Каждый инструмент закрывает отдельный участок и не заменяет DWH, BI-систему или всю интеграционную архитектуру. Такое разделение помогает быстрее определить, где искать причину расхождения: при выгрузке, преобразовании, подготовке витрины.
Как выстроить надежную сверку данных
Надежная сверка строится на трех принципах: единых правилах расчета, локализации расхождения и контроле каждого этапа от 1С до BI.
Такой подход помогает обнаружить сбой до того, как неверный показатель попадет в управленческую отчетность.