Аналитика данных из 1С в Power BI: варианты интеграции через OData, SQL и выгрузки

Учётная система накапливает огромный массив информации о продажах, складе, взаиморасчётах и финансах, но показывает её через типовые отчёты, рассчитанные на бухгалтерский и оперативный учёт. Как только руководителю нужен сводный взгляд на бизнес, начинается ручная работа с таблицами. Power BI решает эту задачу, но сначала данные нужно из системы получить. Есть три принципиально разных пути — OData, прямые запросы к базе и файловые выгрузки, — и у каждого своя цена, скорость и набор ограничений.

Главная причина — разделение учётной и аналитической нагрузки. Учётная система рассчитана на ввод документов и проведение движений, а не на построение сложных срезов по десяткам показателей. Когда пользователи одновременно формируют тяжёлые отчёты, страдает скорость работы всей системы.

Второй аргумент — гибкость. Типовые отчёты дают фиксированный набор форм, изменение которых требует доработки конфигурации. BI-инструмент позволяет собрать модель под управленческие задачи: динамику продаж по менеджерам и каналам, оборачиваемость товаров, структуру затрат — и менять представление без вмешательства программиста.

Третий фактор — объединение источников. Реальная картина бизнеса редко умещается в одну базу: рядом существуют CRM, сайт, таблицы планов, отдельные базы филиалов. Power BI связывает эти данные в единую модель, где показатели из разных систем сопоставимы.

Прежде чем настраивать подключение, нужно понимать, из чего состоит база. Информация хранится не в готовых таблицах отчётов, а в объектах метаданных: справочниках (контрагенты, номенклатура, склады), документах (реализация, поступление, оплата) и регистрах — накопления и сведений. Именно регистры содержат итоговые движения, на которых строится вся отчётность по остаткам и оборотам.

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

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

OData — это встроенный в платформу REST-интерфейс, через который внешние приложения получают доступ к объектам конфигурации по протоколу HTTP. Это официально поддерживаемый механизм, не требующий вмешательства в структуру базы, поэтому для большинства организаций он становится отправной точкой.

Настройка выполняется в несколько шагов:

• публикация базы на веб-сервере с включённым стандартным интерфейсом OData;
• явное указание объектов, которые разрешено отдавать наружу — по умолчанию не публикуется ничего;
• создание отдельной учётной записи с правами только на чтение нужных данных;
• подключение в Power Query как к веб-источнику с указанием адреса сервиса;
• настройка фильтров по периоду и полям на стороне запроса, а не после загрузки.

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

Второй вариант — обращаться к хранилищу напрямую, на уровне SQL Server или PostgreSQL, минуя платформу. Главное преимущество — скорость: чтение таблиц работает на порядок быстрее, а произвольный запрос позволяет сразу получить агрегированный результат нужной формы.

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

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

Третий путь самый очевидный: выгрузить данные в файл и загрузить его в отчёт. Форматы стандартные — CSV, Excel, реже JSON. Ручная выгрузка не требует настройки инфраструктуры и позволяет проверить гипотезу за час.

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

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

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

Схема выглядит так: ETL-процесс регулярно забирает информацию из учётной системы любым доступным способом, приводит её к единому формату, очищает и агрегирует, после чего записывает в аналитическую базу. Power BI подключается уже к хранилищу, а не к рабочей системе, поэтому отчёты открываются мгновенно.

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

Любая интеграция ценна только тогда, когда данные обновляются без участия человека. В Power BI есть два режима работы с источником. Импорт загружает данные в модель и хранит их внутри — отчёты работают быстро, но показывают состояние на момент последнего обновления. Прямые запросы обращаются к источнику в момент открытия отчёта, обеспечивая актуальность ценой скорости и постоянной нагрузки на систему.

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

Универсального ответа нет — выбор определяется четырьмя параметрами: объёмом данных, требуемой актуальностью, числом пользователей отчётности и наличием ИТ-ресурса для поддержки.

Ориентировочные критерии выбора:

• Файловая выгрузка — разовые задачи, пилотные отчёты, небольшие объёмы;
• OData — регулярная отчётность на средних объёмах, приоритет безопасности и поддерживаемости;
• Прямой SQL — большие массивы данных, сложные срезы, наличие копии базы и компетенций;
• Хранилище и ETL — несколько источников, глубокая история, требования к скорости отчётов.

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

Zerobit Kazakhstan помогает выстроить и поддерживать интеграцию учётных систем с аналитическими платформами: подобрать подходящий способ подключения под ваши объёмы, настроить безопасный доступ и автоматическое обновление, обеспечить круглосуточное сопровождение ИТ-инфраструктуры по всему Казахстану.