user10757672

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

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

Тогда рядом с 1С постепенно появляются Excel-файлы, дополнительные обработки, SQL-запросы, интеграции и отдельные базы данных.

Где проходит эта граница и когда компании действительно нужен отдельный аналитический контур, мы поговорили со Степаном Пыстиным, техническим директором «Денвик Аналитика».

Где заканчиваются возможности отчетов

- Обычно все начинается с решения внедрить BI?

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

- То есть стандартные отчеты сами по себе не плохой вариант?

Конечно. Если они закрывают задачи бизнеса, менять что-то ради самого изменения смысла нет.
Вопрос обычно появляется тогда, когда новые управленческие запросы все чаще требуют доработок.
Сегодня руководитель просит один дополнительный показатель. Через месяц - еще несколько. Потом нужно сравнить данные трех подразделений. Затем добавить CRM.
В какой-то момент каждый новый вопрос начинает требовать отдельной технической работы.

Почему появляется Excel

- Что обычно делает сотрудник, если одного отчета уже не хватает?

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

- А в какой момент Excel начинает мешать?

Когда вокруг отчета появляется целый процесс.
Нужно сначала выгрузить один файл, потом второй. Из третьего вычленить справочник. После этого обновить формулы, проверить несколько строк вручную и только потом отправить результат руководителю.
Если такую последовательность приходится повторять каждую неделю или каждый месяц, это уже хороший кандидат на автоматизацию.
Особенно если процесс знает только один сотрудник.
Он уходит в отпуск - и внезапно выясняется, что никто точно не помнит, какой файл нужно открыть первым и почему одна формула отличается от соседней.

- Получается, проблема Excel в ошибках?

Ошибки - только одна часть.
Основной вопрос - воспроизводимость.
Можно ли через полгода повторить расчет по тем же правилам? Понимает ли другой сотрудник, откуда взялась цифра? Можно ли изменить формулу и быть уверенным, что соседний отчет после этого не сломается?
Если ответы понятны, Excel может спокойно оставаться частью процесса.
Если все держится на ручных действиях и памяти одного человека, стоит посмотреть на процесс внимательнее.

Когда нужна отдельная автоматизация

- Логичный следующий шаг - позвать разработчика 1С?

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

- А когда этого становится мало?

Когда количество источников и требований начинает расти.
Представим обычную картину.
Продажи находятся в 1С. Информация о лидах - в CRM. План - в Excel. Маркетинговые расходы приходят из внешнего сервиса.
А руководитель хочет увидеть цепочку:
рекламный канал → клиент → продажа → себестоимость → финансовый результат
Теперь нужно договориться, как связать эти данные.
В одной системе компания может называться ООО Ромашка, в другой - Ромашка. Где-то используется внутренний ID, где-то ИНН. Подразделение в одной базе называется Москва, а в другой - Филиал МСК.
Здесь задача уже выходит за пределы отдельного отчета.

- И количество систем здесь главное?

Не обязательно. Иногда даже два источника создают много вопросов.
Важнее понять, насколько стабильно данные можно объединять.
Если каждый месяц сотрудник вручную решает, какие строки друг другу соответствуют, результат сложно воспроизводить.
Тогда имеет смысл выстраивать постоянный процесс получения и подготовки данных.

Что происходит с данными дальше

- Что значит «постоянный процесс» с технической точки зрения?

Раньше пользователь говорил: «Мне нужен отчет».
Теперь появляются дополнительные требования.
Данные нужно получать регулярно. Нужно понимать, когда они обновились. Нужно контролировать ошибки. Если объем данных большой - желательно повторно не читать весь массив каждый раз.
Для данных 1С эту задачу может закрывать Экстрактор 1С.
Он получает данные из информационной базы 1С и передает их во внешний контур - например, в СУБД, где дальше с ними уже работают аналитические системы.
Для больших наборов можно использовать инкрементальную выгрузку: передавать изменения вместо полной повторной выгрузки всего объема.

- Можно сказать, что тогда нагрузки на 1С вообще нет?

Так говорить было бы неправильно.
Любое получение данных использует ресурсы системы.
Задача состоит в другом - сделать процесс управляемым. Например, не перечитывать без необходимости весь набор данных, выполнять выгрузки по расписанию и контролировать объем обработки.

- Получили данные из 1С. Можно сразу подключать BI?

Иногда да.
Если данные уже находятся в удобной структуре и нужно построить относительно простой отчет, дополнительная обработка может вообще не понадобиться.
Но если нужно объединить несколько систем, обычно появляется следующий этап - подготовка данных.
Нужно привести форматы к общему виду, сопоставить справочники, рассчитать показатели, проверить значения, иногда сохранить историю изменений.
Вот здесь появляется ETL.

- Все это обязательно писать на SQL или Python?

Нет. Подход зависит от команды.
Кому-то удобнее код. Особенно если уже есть свои процессы разработки, Git, тестирование и CI/CD.
Есть и визуальные инструменты.
В нашей архитектуре для таких задач используется Denvic Visual Transformer - DVT. В нем процесс можно собрать как последовательность операций: прочитать данные, отфильтровать, объединить, преобразовать, посчитать нужные поля и записать результат.
Проекты можно запускать по расписанию и смотреть историю выполнения.
При этом сам визуальный интерфейс не решает вопросы модели данных.
Все равно нужно определить, по каким ключам объединять таблицы, где считать показатели, что делать с ошибками и какую историю хранить.

- Тогда в чем смысл low-code?

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

Нужен ли отдельный контур всем

- Если BI умеет получать данные из 1С напрямую, зачем вообще строить отдельные слои?

Иногда незачем.
Допустим, есть одна база, один отчет, небольшой объем данных и несколько пользователей. Запросы не мешают работе системы, а сложных преобразований нет.
Создавать большое хранилище ради такого сценария избыточно.
Ситуация меняется, когда появляется несколько источников, тяжелые расчеты, много потребителей или одна модель данных используется сразу в нескольких отчетах.
Тогда обработку и хранение данных часто выносят во внешний контур.
Он тоже может быть очень разным: от одной аналитической таблицы до полноценного DWH.
Размер решения должен соответствовать задаче.

- Как тогда выглядит типовая схема?

Если сильно упростить:
1С → Экстрактор 1С → аналитическая БД / DWH → DVT → BI / CRM / API / Excel
Экстрактор здесь отвечает за получение данных из 1С.
DVT нужен в тех проектах, где данные требуется объединять или преобразовывать.
А BI работает уже с подготовленным набором.
При простой задаче часть элементов из этой схемы вообще может отсутствовать.

Как понять, что процесс пора менять

- Есть какой-то простой способ понять, что компания уже выросла из текущего подхода?

Я бы взял один важный регулярный отчет и прошел весь путь его подготовки.
Откуда берутся исходные данные?
Сколько файлов нужно выгрузить?
Что сотрудник делает вручную?
Какие таблицы объединяет?
Где считает показатели?
Как проверяет результат?
Сколько людей понимают весь процесс?
После этого обычно становится видно, что именно создает сложности.

- Если ручных действий много, нужно сразу внедрять ETL-платформу?

Нет. Иногда достаточно одной автоматической выгрузки или доработки отчета.
В другом проекте понадобится отдельная аналитическая таблица.
Где-то потребуется полноценный ETL-процесс.
Архитектуру лучше наращивать по мере появления требований.

- А как относиться к Open Source?

Как к обычному варианту выбора технологии.
Цена лицензии - только одна часть затрат.
Еще есть инфраструктура, разработка, сопровождение, мониторинг, обновления, обучение команды.
Если внутри компании уже есть сильная инженерная команда и выстроенные процессы, Open Source может быть вполне удобным вариантом.
Если значительную часть инфраструктуры и инструментов еще предстоит создавать и поддерживать самостоятельно, стоит учитывать стоимость этой работы.
Поэтому я бы сравнивал решения по полной стоимости владения.

Например:

- И какой главный признак того, что аналитика компании становится более зрелой?

Наверное, предсказуемость.
Когда появляется новый вопрос руководителя, команда понимает, где взять данные, как они обновляются, где выполняются расчеты и кто отвечает за логику показателя.
Тогда новый отчет уже не требует каждый раз заново собирать всю цепочку.
Можно представить это так:
источник → получение → хранение → подготовка → показатель → отчет
Причем далеко не каждой компании сразу нужна вся эта цепочка.
Стандартных отчетов 1С может быть вполне достаточно. Excel тоже может оставаться удобным рабочим инструментом. Для части задач хватит доработки внутри 1С.
Отдельный контур данных появляется тогда, когда ручные операции, количество источников и частота изменений начинают заметно усложнять работу.

И уже после этого имеет смысл выбирать конкретную архитектуру и инструменты.

18 сентября команда «Денвик Аналитика» провела день на Жёлтой конфе 2026 – конференции для специалистов 1С, аналитиков, разработчиков и IT-руководителей.

И это был тот случай, когда программа мероприятия довольно точно совпала с вопросами, которые мы регулярно видим в проектах: интеграции, API, производительность, архитектура, ИИ, управление разработкой и место 1С во всё более сложном корпоративном IT-контуре. В программе конференции было 30 докладов сразу в трёх направлениях – аналитика, разработка и управление.

От «Денвик Аналитики» выступил Денис Смирнов с докладом с говорящим названием: «Интеграции с 1С без БДСМ».
Название получилось провокационным, а разговор – вполне прикладным.

С какой задачей мы приехали

Проблема знакома многим компаниям, где вокруг 1С постепенно появляется всё больше потребителей данных.

Сначала нужен один отчёт – появляется отдельная выгрузка. Потом BI – ещё одна обработка.

Потом DWH, внешний сервис, новая база, API, очередная аналитическая система.

Через какое-то время вместо понятной архитектуры компания получает набор отдельных механизмов, каждый из которых нужно поддерживать, дорабатывать и учитывать при очередном изменении.

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

По сути, главный вопрос звучал шире самой технологии выгрузки: где заканчивается ответственность рабочей 1С и начинается корпоративный контур данных?

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

Поэтому разговор постепенно смещается от «как написать ещё одну выгрузку» к архитектуре потока данных: один раз организовать получение данных из 1С и дальше использовать этот поток для разных корпоративных сценариев.

Доклад закончился – разговор продолжился

Участие «Денвик Аналитики» докладом не ограничивалось – весь день работал наш стенд.
И здесь формат конференции оказался особенно уместным.

В одном пространстве собрались люди, которые смотрят на одну и ту же систему с разных сторон: разработчики думают о механике обмена и коде, аналитики – о доступности данных, архитекторы – о связях между системами, руководители – о поддержке всего этого контура.

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

Для нас стенд стал логичным продолжением темы Дениса: можно было перейти от общей архитектуры к конкретным схемам – BI, DWH, ETL/ELT, обмену между базами 1С, внешним сервисам и другим задачам вокруг корпоративных данных. Именно такой формат мы и закладывали перед конференцией.

Что осталось после конференции

Пожалуй, главное впечатление от Жёлтой конфы – здесь довольно быстро исчезает граница между «докладом» и обычным профессиональным разговором.

Одна тема начинается на слайде, продолжается вопросом после выступления, а потом переходит в обсуждение конкретной архитектуры уже в кулуарах или у стенда.

И сама проблематика интеграций с 1С сегодня тоже становится шире.

Речь уже далеко не всегда идёт о том, можно ли получить данные из 1С. Получить можно разными способами.

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

Именно с этим вопросом мы выходили на Жёлтую конфу.

Доклад позволил разобрать его на уровне подхода, а работа стенда – продолжить уже на уровне конкретных сценариев и архитектур.

Спасибо CORS Academy, организаторам, спикерам и всем участникам за Жёлтую конфу 2026.

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

До встречи на следующих мероприятиях.

1. От задачи к способу: как выбрать метод выгрузки

Каждая компания, работающая в 1С, ежедневно накапливает данные: контрагенты, номенклатура, остатки на складах, движения по регистрам, сотрудники, договоры. Эти данные — основа учета, но их польза не ограничивается самой 1С. Руководителю нужен дашборд с ключевыми показателями, аналитику — выгрузка в BI-систему для гибких срезов, интеграции с CRM или складом требуют регулярной синхронизации справочников между системами.

Проблема в том, что данные внутри 1С «заперты»: доступ к ним есть только у пользователей учетной системы, а получить их в удобном для анализа виде — отдельная задача, которая требует либо ручного труда, либо участия программиста.

На практике для решения этой задачи используют разные способы — от простого экспорта списка в Excel до автоматизированных low-code инструментов. У каждого способа своя область применения, свои плюсы и свои скрытые риски, которые проявляются только при росте объема данных или усложнении задачи:

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

Нужно получать данные по запросу, например настроить обновляемую таблицу в Excel через Power Query — используется OData. Удобно для интеграций, но при росте базы (от сотен тысяч строк) появляются таймауты, а попытка сэкономить ресурсы через выгрузку только «изменений за период» создает риск расхождения данных в 1С и в аналитической системе.

Нужна гибкая выгрузка с отбором, в том числе по регистрам накопления или сведений — поможет универсальный отчет. Встроенный и гибкий инструмент, но каждая новая настройка выполняется вручную.

Есть более технические способы — прямой доступ к базе данных SQL — они дают скорость, но ценой нарушения официальной поддержки 1С, рисков безопасности и сложности сопровождения. Это инструмент для инженеров, а не для самостоятельной настройки бизнес-пользователем.

Нужна регулярная автоматическая выгрузка по расписанию без ручных действий и без зависимости от программиста на каждое изменение — для этого существуют специализированные low-code инструменты, например «Экстрактор 1С».

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

2. Экспорт из списка в 1С (Excel/CSV)

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

2.1. Справочники

Как это сделать

Откройте нужный справочник (например, Контрагенты или Номенклатура).

(Опционально) Если нужно выгрузить не весь список, а по определенному условию — нажмите «Еще» → «Настроить список...». На вкладке «Отбор» выберите нужное поле из списка слева (например, «Вид контрагента»), нажмите «Добавить новый элемент» и задайте условие. Также доступны вкладки «Сортировка», «Условное оформление» и «Группировка», если нужно упорядочить или сгруппировать данные. Нажмите «Завершить редактирование».

В верхнем меню нажмите «Еще» → «Вывести список...».

В открывшемся окне в поле «Выводить в» выберите «Табличный документ» (для выгрузки в Excel). Ниже отметьте галочками нужные колонки для выгрузки.

При необходимости включите «Только выделенные», если нужно выгрузить не весь список, а отдельные выделенные строки.

Нажмите «ОК» — откроется табличный документ прямо в 1С.

В верхнем меню выберите «Файл» → «Сохранить как...».

В диалоге сохранения укажите имя файла и выберите тип — «Лист Excel2007-... (*.xlsx)». Нажмите «Сохранить» — готово.

2.2. Регистры накопления

Экспорт через «Вывести список» работает не только для справочников, но и для регистров — например, регистра накопления «Выручка и себестоимость продаж». Разница лишь в том, что перед выгрузкой обычно нужно задать период и другие отборы, чтобы не выгружать весь регистр целиком.

Как это сделать

Откройте нужный регистр (например, через раздел отчетов или монитор регистров — зависит от конфигурации).

Задайте отбор по нужным полям — например, по регистратору и периоду.

В верхнем меню нажмите «Еще» → «Вывести список...».

В открывшемся окне в поле «Выводить в» выберите «Табличный документ», отметьте нужные колонки — для регистра их обычно значительно больше, чем для справочника (Организация, Подразделение, Склад, Клиент, Номенклатура, Партия, Ставка НДС и т.д.).

Нажмите «ОК» — таблица откроется в 1С.

В верхнем меню выберите «Файл» → «Сохранить как...», укажите формат Excel (.xlsx) и сохраните.

Важный нюанс: у регистров, в отличие от справочников, обычно гораздо больше полей и строк (каждая проводка может разворачиваться на несколько строк), поэтому перед выгрузкой стоит заранее решить, какие колонки действительно нужны — иначе таблица получится избыточной и неудобной для дальнейшего анализа.

Как это выглядит на практике в реальном бизнесе

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

Это создает две конкретные проблемы:

Потеря времени. Вместо аналитики человек часами занимается механическим копированием и сведением таблиц.

Человеческий фактор. Любая случайная ошибка при копировании искажает итоговую аналитику — а решения потом принимаются на основе неверных цифр.

С регистрами эта проблема усиливается еще сильнее, чем со справочниками:

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

Объем и сложность сведения выше. У регистра значительно больше колонок и строк (одна проводка может разворачиваться на несколько строк), поэтому свести вручную несколько регистров между собой — например, сверить выручку с движениями по складу — занимает в разы больше времени, чем сведение справочников.

Выше цена ошибки в отборе. Если при выгрузке регистра неверно задать период или отбор по регистратору, часть данных просто не попадет в выгрузку — и это не всегда заметно сразу, в отличие от справочника, где пропущенную позицию легче обнаружить визуально.

Что бывает при попытке автоматизировать

Чтобы избавиться от рутины, компании часто зовут программиста 1С — он настраивает регламентные задания, которые сами по расписанию генерируют отчеты и складывают их в папку. Проблема в том, что это создает полную зависимость от разработчика: как только меняется бизнес-логика или нужно добавить новую колонку, выгрузка ломается, и приходится снова вставать в очередь к программисту и ждать, пока он внесет правки — иногда неделями.

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

Вывод

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

3. Через OData

По сути, OData — это встроенный нативный интерфейс, который дает прямой доступ к объектной модели данных 1С. Для многих аналитиков это кажется отличной отправной точкой: зачем изобретать велосипед, если инструмент уже есть в самой платформе. Хорошо подходит, когда нужно получать данные по запросу — например, настроить обновляемую таблицу в Excel через Power Query, без необходимости каждый раз заходить в 1С и вручную выгружать список.

Что нужно заранее

OData должен быть опубликован администратором 1С — обычно это делается через веб-сервер (IIS/Apache) или в облачных версиях 1С уже включено по умолчанию. Вам понадобится:

Адрес OData-сервиса — обычно выглядит так: http://ваш-сервер/имя_базы/odata/standard.odata

Логин и пароль пользователя 1С с правами на чтение нужных данных

Если этого адреса у вас нет — обратитесь к вашему ИТ-специалисту или администратору базы.

Как это сделать (на примере Excel Power Query)

Откройте Excel, перейдите на вкладку «Данные» → «Получить данные» → «Из других источников» → «Из канала OData».

Вставьте адрес OData-сервиса в поле «URL-адрес», нажмите «ОК».

Выберите способ авторизации — обычно «Базовый» — и введите логин и пароль от 1С. Нажмите «Сохранить».

В открывшемся окне навигатора появится список доступных объектов — найдите нужный справочник или регистр (названия будут на латинице/транслите, например Catalog_Nomenklatura или AccumulationRegister_ВыручкаИСебестоимостьПродаж), поставьте галочку.

Нажмите «Загрузить» — данные появятся в Excel обычной таблицей, либо «Преобразовать данные», чтобы предварительно отредактировать запрос в редакторе Power Query.

При необходимости регулярного обновления — на вкладке «Данные» используйте кнопку «Обновить все», либо настройте автообновление в свойствах запроса.

Частые проблемы при подключении

На практике даже при правильном адресе и корректных правах доступа подключение часто проходит не с первого раза. Вот две типичные ошибки.

Ошибка метаданных канала. При попытке подключения Excel может выдать: «OData: Документ метаданных канала недопустим... The root element should be Edmx». Это значит, что вместо XML-схемы с описанием структуры данных (документ Edmx) сервер вернул общий список коллекций (Service Document). Причины бывают разные: неверно указан адрес, кэш старого подключения в Power Query, либо временный сбой публикации OData на сервере. Проверить просто — открыть в браузере тот же адрес с /$metadata на конце: если там тоже не открывается нормальная XML-схема, проблема на стороне публикации OData в 1С, и нужно звать администратора; если схема открывается корректно — достаточно пересоздать подключение в Excel.

Ошибка предпросмотра данных. Другая типичная ошибка — «Текущее предварительное значение слишком сложно для отображения». Она возникает уже после успешного подключения и означает, что Power Query не может построить предпросмотр для объекта со сложной структурой — например, из-за большого числа полей или вложенных табличных частей. В большинстве случаев помогает просто нажать «Загрузить» напрямую, минуя предпросмотр — сама загрузка данных при этом проходит нормально.

Как это выглядит на практике в реальном бизнесе

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

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

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

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

Вывод

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

4. Через настраиваемый (универсальный) отчет

В отличие от простого экспорта списка, отчеты в 1С с гибкими настройками позволяют не просто вывести данные «как есть», а сразу собрать нужный срез: с отборами, группировками и оформлением. Это может быть как встроенный «Универсальный отчет», так и любой другой настраиваемый отчет конфигурации — например, «Валовая прибыль предприятия», «Продажи», «Взаиморасчеты с контрагентами» и т.д. Логика работы с ними одинаковая.

Как это сделать

Откройте нужный отчет (в примере — «Валовая прибыль предприятия»), задайте период в верхней части окна.

Нажмите «Настройки...», чтобы открыть детальные параметры отчета.

На вкладке «Фильтры» задайте нужные параметры и отборы — например, по подразделению, менеджеру, сегменту номенклатуры. Значения можно закрепить (звездочка слева), чтобы они были видны сразу на форме отчета.

На вкладке «Поля и сортировки» выберите, какие поля должны попасть в отчет, и в каком порядке их выводить.

На вкладках «Оформление» и «Структура» при необходимости настройте группировки, промежуточные итоги и визуальное оформление таблицы.

Нажмите «Закрыть и сформировать» — отчет построится с учетом всех заданных настроек.

В верхнем меню выберите «Файл» → «Сохранить как...».

Укажите имя файла и формат — Excel (.xlsx) — и сохраните.

Чем это лучше простого экспорта списка

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

Недостатки способа

Каждая новая настройка — вручную. В отличие от автоматизированных инструментов, здесь нет расписания «из коробки» — если нужна регулярная выгрузка, отчет все равно приходится открывать и формировать заново каждый раз (либо настраивать регламентное задание через программиста, с теми же рисками зависимости, что и в способе 1).

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

Сложность освоения для не-технического пользователя. Настройки фильтров, полей и структуры отчета — это не всегда интуитивно понятно с первого раза, особенно на вкладке «Расширенный» вид, где логика построения сложнее, чем в «Простом» режиме.

Не решает проблему интеграции с внешними системами. Результат — это файл Excel, который нужно куда-то вручную загружать дальше (в BI, в другую базу), то есть автоматической синхронизации с внешними системами такой способ не дает.

5. Способ для продвинутых: прямой доступ к SQL

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

Почему это выглядит сложнее, чем кажется

Взгляните на структуру таблиц реальной базы 1С:

Все названия таблиц — технические идентификаторы, а не понятные бизнес-термины. Понять, что в таблице _AccumRg87428 хранятся, например, движения по регистру «Выручка и себестоимость продаж», можно только сопоставив ее с внутренним справочником метаданных конфигурации.

Ситуация усложняется на уровне самих данных:

Ссылки на другие объекты (_Fld87429RRef, _RecorderTRef) хранятся в виде бинарных идентификаторов, а не читаемых значений — чтобы понять, что означает конкретная ссылка, нужно отдельно расшифровывать ее через таблицу _Reference и знать внутреннюю структуру типов 1С. Без этого знания собрать из таких таблиц осмысленный отчет просто невозможно.

Риски такого подхода

Нарушение стандартов поддержки. Это официально не поддерживаемый компанией 1С способ интеграции. Обновили конфигурацию — структура таблиц в SQL изменилась, ваши запросы упали, аналитика сломалась.

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

Сложность сборки. Чтобы вытащить из SQL один привычный документ, нужно связать между собой десятки технических таблиц — без опытного разработчика 1С здесь легко запутаться.

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

Вывод

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

6. Через «Экстрактор 1С»

Все способы из предыдущих разделов объединяет одна проблема: рано или поздно они упираются либо в ручной труд, либо в необходимость привлекать программиста 1С. «Экстрактор 1С» — low-code ETL-инструмент, который позволяет настроить регулярную автоматическую выгрузку данных из 1С в базу данных или хранилище без участия программиста. Разберем на реальном примере, как настраивается выгрузка справочника «Номенклатура».

Как это сделать

Откройте раздел «Проекты» и нажмите «Создать». Укажите подключение — базу 1С, откуда берем данные, и подключение к приемнику (например, ClickHouse или другая БД для аналитики).

В открывшемся мастере «Конструктор проекта» выберите тип источника данных. Для выгрузки справочника «как есть» подойдет вариант «Объект».

В списке объектов конфигурации найдите и выберите нужный справочник — в примере это «Номенклатура».

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

В режиме «Расширения параметров» можно разделить параметры на «Инициализацию» (используется при первом формировании очереди) и «Регулярный» (используется при каждой последующей выгрузке) — это помогает эффективно обрабатывать большие объемы данных.

На шаге «Поля» выберите нужные колонки для выгрузки, перенеся их из списка доступных полей в выбранные.

Выберите приемник данных — «Создать новую» таблицу или «Выбрать существующую».

Если создается новая таблица — укажите базу и имя таблицы (при необходимости можно транслитерировать название автоматически).

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

Нажмите «Записать и закрыть», затем на карточке проекта — «Выполнить проект». Чтобы выгрузка происходила автоматически, настройте «Расписание выгрузки» в нижней части карточки проекта.

Чем это принципиально отличается от предыдущих способов

Настройка один раз, а не при каждой выгрузке. В отличие от экспорта списка, OData или настраиваемого отчета, проект в Экстракторе создается один раз, а дальше выполняется по расписанию без участия человека.

Работа с большими объемами. Механизм параметров и сегментирования (инициализация/регулярный параметр) решает именно ту проблему, с которой упирается OData — таймауты и обрывы соединения при больших объемах данных.

Не требует программиста. Весь процесс настройки — от выбора источника до маппинга полей — выполняется через визуальный мастер, без написания кода, в отличие от веб-сервисов, COM-соединений или прямого доступа к SQL.

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

Вывод

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

7. Сравнение способов и рекомендации

Каждый способ решает свою задачу — универсального варианта на все случаи нет. Вот краткое сравнение всех пяти способов из статьи:

Как выбрать способ под свою задачу

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

Нужны обновляемые данные в Excel для точечной интеграции — подойдет OData, но заложите время на настройку и учитывайте ограничение по объему.

Нужна гибкая аналитика с отборами и группировками, без интеграции с внешними системами — используйте настраиваемый (универсальный) отчет.

Нужна максимальная скорость и в компании есть опытный разработчик 1С, готовый нести риски — рассмотрите прямой доступ к SQL, но только как осознанный компромисс.

Нужна регулярная автоматическая выгрузка больших объемов без участия программиста — это задача для специализированного low-code инструмента, например «Экстрактора 1С».

Главный вывод

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

Денвик Аналитика — российская ИТ-компания, разработчик ETL-инструментов для интеграции, обработки и подготовки корпоративных данных. Линейка ETL-продуктов Денвик Аналитика позволяет работать с корпоративными данными в режиме self-service, без постоянного привлечения программиста:

• выгружать любые данные из 1С для анализа во внешних BI-системах;

• строить корпоративные хранилища данных, источником которых выступает 1С;

• выполнять очистку, подготовку и консолидацию данных в корпоративном хранилище;

• загружать данные в 1С из внешних систем.

В ClickHouse вы можете обновлять разные данные с разной частотой. Продажи — раз в час, остатки — чаще, историю — вообще загрузить один раз. Исправленный документ тоже должен попасть в ClickHouse, а прерванная загрузка — продолжиться с нужного места. От того, как вы построите обмен, зависят объем передаваемых данных, нагрузка на 1С и то, как выгрузка будет работать при изменениях и сбоях.

Чтобы передавать данные из 1С в ClickHouse, вы можете заказать разработку у интегратора, собрать обмен с помощью ИИ или использовать Экстрактор 1С. Разберем, сколько времени займет каждый способ, что происходит при изменениях и сбоях и кто будет поддерживать передачу данных после запуска.

Зачем выгружать данные из 1С в ClickHouse

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

ClickHouse — аналитическая колоночная СУБД для работы с большими объемами информации. В нее загружают сведения из учетной системы (продажи, закупки, остатки и историю операций) для расчетов, отчетности и BI. Аналитические запросы к этим данным выполняются отдельно от рабочей базы 1С.

1С и ClickHouse работают с разными типами нагрузки: 1С поддерживает текущий учет, а ClickHouse обрабатывает накопленные данные для аналитики.

Важно: ClickHouse нужен не каждой компании.

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

Как организовать выгрузку данных из 1С в ClickHouse

Предположим, производственная компания каждый день смотрит в BI себестоимость выпуска, объем производства и отклонения по цехам.

Но — в течение дня в 1С появляются новые документы, меняются остатки и корректируются операции. Если один раз выгрузить базу в ClickHouse и больше ее не обновлять, следующий отчет покажет показатели по состоянию на момент последней выгрузки.

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

Для регулярной выгрузки из 1С в ClickHouse компания может:

1. Заказать разработку у интегратора.

2. Собрать обмен с помощью ИИ.

3. Использовать специализированный Экстрактор данных.

Разберем ниже особенности каждого способа: настройку, работу с изменениями, сбоями и поддержку после запуска.

Если заказывать разработку у интегратора

Интегратор разрабатывает обмен между 1С и ClickHouse. Вы описываете, какие данные хотите передавать и как часто их обновлять, а интегратор проектирует выгрузку: выбирает, какие записи забирать из 1С, как передавать изменения, обрабатывать сбои и повторные загрузки.

Допустим, у вас сеть магазинов, и вы хотите обновлять продажи в ClickHouse каждый час. Вам нужны данные о выручке и продажах по каждому магазину в течение дня. Интегратор проектирует обмен так, чтобы каждый час передавать новые и измененные записи, не загружая заново уже переданную историю.

Для такого обмена разработчик прописывает правила:

● что выгружать — продажи, товары, магазины, цены, остатки и связанные данные;

● как находить изменения — отбирать новые и измененные записи при каждом запуске;

● как продолжать загрузку после сбоя — определить, с какого места возобновлять передачу;

● как исключать дубли — повторная отправка не должна создавать вторую запись о продаже;

● как проверять полноту — контролировать, что данные из 1С полностью дошли до ClickHouse;

● как учитывать изменения в 1С — проверять обмен после изменений в документах, регистрах и справочниках.

Разработчик реализует эти правила в коде и тестирует основные ситуации: обычную загрузку, повторную отправку, обрыв передачи и неполную выгрузку. Ошибка в правилах обмена может привести к пропускам или дублям: часть продаж не попадет в ClickHouse, а одна продажа загрузится дважды.

Что происходит с обменом после запуска

После запуска интегратор продолжает сопровождать разработанный обмен: исправлять ошибки, проверять изменения в 1С и дорабатывать обмен при новых требованиях.

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

Если разработчик меняется, новому специалисту сначала нужно изучить код, правила загрузки и логику обработки данных. Пока он изучает обмен, новая доработка занимает больше времени.

Разработка обмена с помощью ИИ

Вайбкодинг — разработка, при которой специалист описывает задачу ИИ обычным языком, получая готовый фрагмент кода и уточняя его следующими запросами. Это действительно ускоряет написание обмена.

К примеру, у оптовой компании три базы 1С и руководителю нужен единый отчет по заказам, отгрузкам и остаткам. Чтобы отчет отражал изменения в течение дня, компания хочет передавать новые и измененные записи в ClickHouse каждые 30 минут.

Программист 1С может собрать обмен с помощью ИИ: он передает ИИ структуру документов, нужные поля и правила загрузки — ИИ собирает код обмена.

Дальше программист проверяет, что происходит с загрузкой в реальных ситуациях:

● Новые записи — все ли новые заказы и отгрузки попадают в ClickHouse.

● Изменения — видит ли обмен исправления в уже созданных документах.

● Сбой — что произойдет, если передача оборвется после загрузки части записей.

● Дубли— не загрузятся ли эти записи повторно после перезапуска.

● Пропуски — совпадает ли состав загруженных записей с 1С.

● Изменения в 1С — продолжит ли обмен работать после обновления документов, регистров или справочников.

Если программист 1С собрал обмен с ИИ, он же и проверяет его на реальных данных. Иначе нельзя понять, как код поведет себя после сбоя, повторного запуска или изменения документов в 1С. ИИ сгенерирует код по заданным условиям, но не проверит, совпадает ли результат с данными 1С. Программист должен сам проверить пропуски, дубли, повторный запуск после сбоя и изменения в документах.

ИИ сокращает время на написание кода, но не отвечает за то, что произойдет с выгрузкой после запуска. Если в компании нет специалиста, который может проверить такой обмен и поддерживать его дальше, после первой версии кода придется искать разработчика для этой работы.

Экстрактор 1С: готовый способ выгружать данные в ClickHouse

Отдельный инструмент выгрузки извлекает данные из 1С по расписанию и передает их в ClickHouse. Он отслеживает изменения в источнике и забирает только новые или измененные записи. Поэтому 1С не выполняет полную выгрузку при каждом обновлении, а СУБД получает только актуальные изменения.

Например, Экстрактор 1С от Денвик Аналитика автоматизирует регулярную передачу данных без разработки собственного обмена в 1С.

1С не формирует повторно весь массив данных при каждом запуске. Это снижает нагрузку на учетную систему и ускоряет регулярную передачу изменений в ClickHouse.

Экстрактор 1С можно подключить к одной или нескольким базам 1С. Если в 1С меняются документы или справочники, вам не нужно править код обмена в каждой базе — правила выгрузки остаются в Экстракторе.

Важно: совсем скоро в Экстракторе 1С появится собственный ИИ для быстрой сборки выгрузок. Вы сможете описать, что нужно передать из 1С в ClickHouse, а ИИ поможет собрать выгрузку. Например, при подключении новой базы или нового раздела 1С он сократит время на создание правил выгрузки.

Как продукты Денвик Аналитика помогают организовать интеграцию 1С и ClickHouse

Для интеграции 1С с ClickHouse компания использует не только Экстрактор 1С, но и DVT (Denvic Visual Transformer) — low-code ETL-сервис для визуальной трансформации данных перед загрузкой в BI-системы.

Если в ClickHouse нужно загрузить сведения не только из 1С, но и из других источников, DVT подготавливает их до загрузки. Он объединяет информацию из 1С, Bitrix24, баз, файлов и API, очищает значения и приводит поля к общей структуре. После обработки в ClickHouse поступают готовые аналитические таблицы для BI.

После загрузки в ClickHouse компания получает единое хранилище для аналитических данных из 1С и других источников. BI берет показатели из этого хранилища, поэтому отчеты не нагружают рабочую базу 1С аналитическими запросами. Продукт помогает связать ClickHouse с Yandex DataLens, PIX BI и Visiology, чтобы отчеты и дашборды использовали подготовленные показатели.

Сравнение способов выгрузки данных из 1С в ClickHouse

Кратко сравним варианты выгрузки по объему ручной работы, сопровождению и затратам на эксплуатацию.

Пример автоматической выгрузки из 1С в ClickHouse

Рассмотрим кейс компании «Хеппивеар Юг», где данные из 1С и Bitrix перенесли в ClickHouse для подготовки BI-отчетов.

Проблема

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

Решение

Наши эксперты настроили Экстрактор 1С для автоматической передачи изменений из 1С в ClickHouse. Он забирает новые и измененные записи по расписанию, поэтому при каждом обновлении не приходится повторно выгружать всю историю.

Данные из Bitrix также загрузили в ClickHouse и объединили их с данными 1С для BI-отчетов в DataLens. Для каждого набора данных настроили расписание обновления и контроль задержки. Если данные не поступали вовремя, команда получала уведомление в Telegram и проверяла, на каком этапе возник сбой: при чтении данных из 1С, передаче или загрузке в ClickHouse.

Результат

● данные из 1С и Bitrix регулярно обновляются в ClickHouse;

● BI-отчеты получают показатели из единого аналитического источника;

● специалисты отказались от ручной подготовки отчетов в Excel;

● отчеты показывают показатели с детализацией от общих KPI до товаров и товарных категорий;

● показатели можно анализировать по дням, месяцам и годам;

● в аналитику вошли продажи, финансовые показатели, данные о подразделениях и сотрудниках, а также обращения в техническую поддержку.

Подробнее о проекте — вполном кейсе компании.

Типичные ошибки при выгрузке данных из 1С в ClickHouse

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

Каждый раз загружать всю историю

Если при каждом обновлении вы передаете всю историю, 1С снова обрабатывает уже выгруженные записи, а ClickHouse получает их повторно. На больших таблицах это увеличивает время загрузки и нагрузку на учетную систему.

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

Не отслеживать изменения в 1С

Документы, заказы и остатки могут измениться после первой загрузки. Если обмен не фиксирует эти изменения, СУБД хранит прежние значения, а BI показывает устаревшие показатели.

Например, вы исправили количество товара в заказе, но обмен не передал изменение. В отчете останется старое значение, хотя в 1С документ уже исправлен.

Не предусмотреть продолжение после сбоя

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

Для регулярной выгрузки заранее задайте правила повторной передачи и восстановления после сбоя.

Считать загрузку успешной без проверки

Завершение обмена не подтверждает, что ClickHouse получил полный набор записей. Проверяйте количество и состав загруженных данных, а для критичных показателей — сверяйте итоговые значения с 1С. Таким образом вы обнаружите пропуски и дубли до того, как они попадут в управленческий отчет.

Привязать обмен к коду 1С

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

Денвик Аналитика — российская ИТ-компания, разработчик ETL-инструментов для интеграции, обработки и подготовки корпоративных данных. Линейка ETL-продуктов Денвик Аналитика позволяет работать с корпоративными данными в режиме self-service, без постоянного привлечения программиста.

Ответы на часто задаваемые вопросы:

Как передавать данные из 1С в ClickHouse?

Можно заказать разработку обмена, собрать его с помощью ИИ или подключить Экстрактор 1С. Для регулярной выгрузки решение должно отслеживать изменения и передавать только новые и измененные данные.

Как автоматизировать выгрузку данных из 1С в ClickHouse?

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

Как загружать только новые и измененные данные из 1С?

Настройте инкрементальную выгрузку данных из 1С в ClickHouse: при каждом запуске система ищет изменения после предыдущей загрузки. Это уменьшает объем передаваемых данных и нагрузку на 1С.

Можно ли разработать интеграцию 1С и ClickHouse с помощью ИИ?

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

Нужна ли заказная разработка для выгрузки данных из 1С в ClickHouse?

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

Какой инструмент использовать для автоматической выгрузки из 1С в ClickHouse?

Для автоматической выгрузки используйте Экстрактор 1С. Он отслеживает изменения в одной или нескольких базах и передает их в ClickHouse по заданному расписанию.

Компания «Денвик Аналитика» опубликовала исходный код Denvic Visual Transformer (DVT) - визуальной low-code платформы для построения ETL/ELT-процессов. DVT ядро теперь доступно в публичном репозитории GitHub и распространяется по лицензии GNU Affero General Public License v3.0 (AGPL-3.0-only).

Репозиторий DVT: GitHub - Denvic-Tech/dvt

До выхода в Open Source DVT развивался командой «Денвик Аналитика» в собственных проектах как инструмент для построения и управления потоками данных. Теперь исходный код платформы открыт: разработчики и data-команды могут изучать архитектуру DVT, развертывать решение в собственной инфраструктуре, создавать расширения и участвовать в развитии проекта через публичный GitHub-репозиторий. Репозиторий содержит исходный код, конфигурацию Docker, установщик, тесты, документацию для разработчиков и API расширений.

Зачем DVT открыли

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

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

Публикация DVT в Open Source делает этот технологический слой доступным за пределами проектов «Денвик Аналитики». Теперь любая компания может развернуть DVT у себя, изучить устройство платформы и при необходимости доработать ее под собственный стек данных с учетом требований лицензии AGPL-3.0. Повышается доверие к инструменту, а команда “Денвик” делает вклад в opensource-сообщество.

Полные условия лицензирования DVT Core опубликованы вместе с исходным кодом в файлах LICENSE и COPYING репозитория. Архитектура также предусматривает механизм расширений через документированные интерфейсы DVT Extension Interfaces.

Что умеет открытый DVT

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

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

Для более сложных сценариев предусмотрены SQL-запросы, Python-блоки, HTTP-запросы, REST API, собственные расширения и повторно используемые компоненты. DVT можно использовать для подготовки данных для BI, построения аналитических витрин и DWH, консолидации корпоративных источников и других ETL/ELT-процессов.

DVT можно развернуть у себя

DVT ориентирован на self-hosted-развертывание. В GitHub опубликован установщик для Linux-среды с Docker и Docker Compose, а исходный код проекта можно получить непосредственно из публичного репозитория.

Для разных инфраструктурных сценариев подготовлена отдельная документация по установке DVT. Помимо установки с помощью командного скрипта предусмотрены офлайн-развертывание и автономная установка в закрытый контур .

Командный сценарий подходит для Linux-среды с Docker: установщик последовательно подготавливает параметры окружения, формирует конфигурацию и запускает сервисы DVT.

Офлайн-установка рассчитана на инфраструктуру, где дистрибутив удобнее заранее подготовить и перенести на целевой сервер в виде архива.

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

Документация DVT: Denvic Visual Transformer - документация

Открытое ядро можно расширять

DVT Core распространяется как Open Source по AGPL-3.0. При этом архитектура платформы предусматривает подключение дополнительных расширений через документированные интерфейсы.

Для задач, связанных с корпоративными источниками данных, «Денвик Аналитика» также развивает коммерческие дополнения к DVT. В частности, к платформе можно подключить “Экстрактор 1С” для получения данных из 1С и “Коннектор к Битрикс24”.

Такой подход позволяет использовать открытый DVT как самостоятельную платформу обработки данных и при необходимости дополнять его специализированными компонентами для конкретной инфраструктуры.

Проект открыт на GitHub

Исходный код DVT, инструкции по запуску, описание архитектуры и материалы для разработчиков опубликованы в открытом репозитории:

github.com/Denvic-Tech/dvt - Denvic Visual Transformer

В репозитории также описаны правила разработки и тестирования. Команда проекта принимает внешние contributions и предлагает использовать публичный GitHub как основной источник для работы с изменениями DVT.

Подробнее о DVT и возможностях платформы:

DVT - визуальная low-code платформа для трансформации данных

Оставить заявку и обсудить проекты, вы сможете на нашем сайте: https://denvic.tech

В большинстве компаний различные конфигурации 1С выступают центральными источниками финансового и операционного учета. 1С точно, последовательно и в соответствии с законодательством отражает данные по ключевым процессам бизнеса.

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

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

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

Какую аналитику предлагает 1С

Прикладные решения 1С охватывают функции продуктов классов ERP, CRM, HRM, SCM.
В системе хранятся данные бухгалтерского и налогового учета, данные о производственных процессах, продажах и маркетинге, логистике и закупках, которые ценны для аналитики.
Как правило, сотрудники решают задачу аналитики просто — делают выгрузки из 1С в Excel с помощью функции «Рассылка отчетов» или используют встроенную 1С:Аналитику.

1. Рассылка отчетов

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

Несмотря на простоту, у способа есть существенные минусы:

• Потеря актуальности

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

• Ручные корректировки

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

• Сложность для восприятия и анализа

Выгрузки из 1С – это таблицы, и если найти и сравнить вручную 2-3 значения из них еще возможно, то десятки и сотни – нет.

• Отсутствие единого контекста

1С — не единственный источник данных в компании. Чтобы получить полное представление, нужно объединить данные из различных информационных систем, например, CRM, маркетинговых платформ, ERP и других.

• «Плоская» картина бизнеса

Формат таблиц не подходит для детализированной, глубокой аналитики, не показывает динамику показателей в разрезах (по клиентам, регионам, каналам), связь между операционными и финансовыми показателями, план-фактное отклонение в реальном времени и т.д.
Любой нестандартный отчет потребует доработок и привлечения 1С-программиста.
1С — система для учета, а не для анализа, и по итогу выгрузок компания получает не управленческую аналитику, а набор статичных таблиц, собранных «на глаз».

2. 1С:Аналитика

Для бизнес-аналитики 1C предлагает и собственный BI-продукт – 1С: Аналитика, который является конфигурацией платформы 1С: Предприятие.
1С: Аналитика работает как часть интерфейса и позволяет создавать отчеты, графики и диаграммы на основе данных из 1С.

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

• Анализ ограниченного среза данных

Все данные для 1С: Аналитика должны быть строго в базе 1С, причем источником может выступать только одна база, которая должна быть опубликована на веб-сервере

• Ограничение в преобразовании данных

1С: Аналитика не хранит данные и способна визуализировать их только без предобработки. Все расчеты и преобразования в системе нужно делать средствами платформы 1С, в базе 1С

• Схема и модель данных

В 1С: Аналитика нет понятия модели данных, для связи нескольких таблиц создается новый запрос и формируется новый источник в базе 1С

• Ограниченный набор визуализаций

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

1C: Аналитика может быть хорошим вариантом для формирования ежедневной отчетности из решений 1С, но не сможет в полной мере закрыть потребности управленческой отчетности.
_____

В результате при выгрузке Excel или использовании 1С:Аналитики управленческие решения принимаются по неполным данным.
Стандартные отчеты 1C оказывается тяжело адаптировать, сложные выборки замедляют систему, а любое изменение стандартной выгрузки требует вмешательства программиста.

Управленческие дашборды в BI: переход от учета к управляемости

• Выручку, себестоимость, прибыль по направлениям, подразделениям компании, периодам

• Маржинальность по продуктам, каналам, регионам, проектам

• План-факт и динамику расходов

• Дебиторскую и кредиторскую задолженности

• Денежные потоки (Cash Flow) — план / факт / прогноз

• Рентабельность инвестиций (ROI, ROE, ROS)

• Показатели простоев и загрузки подразделений

• …и другие метрики

Для создания такой отчетности требуется объединить данные из 1С и других систем и визуализировать их в едином пространстве – BI-дашбордах.

С помощью BI-системы можно построить управленческие дашборды для разных направлений:

• Дашборд CEO / собственника

Отражает ключевые KPI по компании (EBITDA, выручка, рентабельность, маржа, cash flow)

• Дашборд коммерческого директора

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

• Дашборд финансового директора / CFO

Включает в себя отчеты P&L, баланс, структуру затрат, план-фактный анализ

• Дашборд операционного директора / директора по производству

Отражает ключевые операционные процессы, SLA, производительность, запасы и т.д.

Главной сложностью реализации комплексной управленческой аналитики в BI становится выгрузка данных из 1С.

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

Прямое подключение к SQL-базе 1С трудоемко и нарушает лицензионную политику решения. Такой способ может привести к изменениям в нормальной работе платформы, разрушению БД и отказу 1С в техподдержке. К тому же при внесении изменений в систему придется каждый раз повторять запрос к БД и выгружать все целиком.

Кроме прямого подключения возможны способы:

• Построить свою аналитическую SQL-базу

• Вручную выгрузить файлы XLS/CSV/XML

• Загрузить данные по протоколу OData

• Использовать COM-соединение

• Внедрить 1C:Шину

Каждый из этих способов имеет свои плюсы и минусы, но все они дают нестабильный и трудозатратный результат.

Задачу выгрузки больших объемов данных из 1С в BI решает готовое решение - Экстрактор от Денвик.

Как извлечь данные из 1С в BI с помощью Экстрактора от Денвик

• Без изменения конфигурации 1С

• В любом объеме

• С учетом прав доступа

• В нужной детализации и структуре

• С регулярным обновлением по расписанию

Как работает Экстрактор 1С?

• Подключается к базе 1С как Расширение к приложению 1С

• Извлекает нужные документы, справочники, регистры по заранее заданным настройкам для выгрузки

• Позволяет очищать данные от ошибок и дублей, проводить дополнительные вычисления, шифровать данные

• Выгружает данные в СУБД ClickHouse, PostgreSQL, Microsoft SQL

• Передает данные в DWH или BI (PIX BI, Analytic Workspace, Qlik Sense и другие)

Экстрактор создает надежный мост между 1С и BI, автоматически извлекая нужные данные, обеспечивая их прозрачность и подготавливая их для аналитики.

Что нового в Экстракторе 1С: интеграция с PIX BI и другие доработки

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

Расскажем кратко о свежих ключевых обновлениях в Релизе 3.8.3.88.

• В релизе реализована интеграция с PIX BI в формате нового подключения, что позволяет автоматически создать «Источник» и «Набор данных» в PIX BI.

Новая функция значительно упрощает интеграцию решения с платформой PIX BI.
О том, как создать новое подключение в Экстракторе читайте в статье.

Прочие доработки

• Добавлен раздел «Дополнительные настройки» для строки проекта, в который перенесены настройки «Параметры источника инициализируются из очереди» и «Значение партиции инициализируется из очереди», а также добавлен флаг «Выгружать строку при отсутствии данных»

В форме проекта в колонке «Источник» теперь указывается и тип источника (набор данных, используемый для создания данной строки проекта: объект, запрос и т.д.).

FIX-176141. Для удобства в форму элемента справочника «Проекты» добавлены подписи кнопок «История» и «Очередь»

FIX-165879. Добавлено информирование о блокировке работы с внешними ресурсами, а также уточнено описание

• Введена проверка заполнения обязательных полей для предопределенных обработчиков

• Актуализированы типы полей MS SQL

• Реализована запись статуса «Пропущено» при блокировке внешних ресурсов

• Добавлены следующие функции для вычисляемых полей:

1. Метаданные.Проект.Время запуска

2. Метаданные.СтрокаПроекта.Время запуска

3. Метаданные.Очередь.Количество записей

• В сообщение об ошибке проверки лицензии добавили информацию о том, с какого сервера 1С к какому ресурсу и по какому порту осуществляется подключение

• Актуализированы все процедуры «Алгоритм» из Модуля менеджера справочника Экс_Обработчики

• Для лицензии «Коннектор 1С к Yandex DataLens» в информацию об ошибке добавлены сервер, порт и сервер 1С при HTTP запросе

• FIX-132685. В меню Экстрактора 1С добавлен раздел «Информация о программе»

Обновления Denvic Control Center (DCC)

• Добавлена кнопка «Очистить» в «Регистр сообщений».

• Поддержали PUT-запрос для платформ 1С конфигураций ниже 8.3.6.

Исправлены следующие ошибки

• FIX-131603. Ошибка сегментации данных по полям «Счет» (Хозрасчетный).

• FIX-175965. Ссылка SQL (_IDRRef) возвращает ссылку на sql, для перечислений в том числе.

• FIX-176733. При изменении таблицы остаётся индекс от старой таблицы.

• FIX-176617. При полной выгрузке не заполняются поля «Метаданные.Очередь.Пользователь» и «Метаданные.Очередь.Операция».

• FIX-177789. Ошибки прохода по помощнику при работе с подключением Apache Kafka.

• FIX-176153. Ошибка при выгрузке статуса задачи DCC

Компания Qlever Solutions, специализирующаяся на внедрении корпоративных аналитических решений, является лидером среди партнеров ГК Денвик, заняв первое место в Q1 2025 по объему продаж Экстрактора 1С.

Авторы статьи и партнеры: Qlever Solutions (https://www.qlever.ru/)