Введение
Один из самых востребованных у наших клиентов решений сегодня — это чат-бот в Telegram, который принимает вопрос в привычной разговорной форме, переводит его в SQL, выполняет эти SQL-запросы, и на основе данных из хранилища формирует ответ.
Например:
- «Покажи топ-5 товарных позиций с ростом продаж более 10% за последний квартал и отклонениями от прогноза».
- «Проверь, хватает ли у нас средств для выплаты премии в марте».
- «Сколько клиентов из Белорецка сделали заказы дороже 1000 рублей за последнюю неделю?».
- «В каком подразделении больше всего просроченных задач по проекту с энергетиками и почему? Что сделать, чтобы ускорить?».
Ответ чат-бот может представить в виде текста, таблицы, PDF-отчёта, презентации или графика.
Несмотря на то что такие решения пока воспринимаются скорее, как интересный ИИ-эксперимент, уже на этапе пилота они приносят измеримые бизнес-результаты:
- Аналитика «на лету». Бизнес-пользователь получает ответ за секунды, а не ждёт несколько дней, пока ИТ-подразделение подготовит выгрузку, отчёт или найдёт подходящий дашборд в BI-системе.
- Self-service аналитика без знаний SQL и Python и без участия аналитиков и разработчиков: время реакции на запросы сокращается до нескольких минут.
- Снижение нагрузки на ИТ- и BI-подразделения. Бот автоматически генерирует SQL-запросы и визуализацию, пользователи не обращаются в ИТ, Data Science и BI-команды.
Если сильно упростить и схематизировать, то проекты организованы примерно так:
- Построение хранилища данных, которые и будут использоваться для формирования ответов пользователю. В хранилище будут аккумулироваться все необходимые данные из источников (например, ERP, CRM, логов, pdf-документов и т. д.).
- Настройка ETL-процессов для выгрузки из источников, очистки и трансформации данных и загрузки их в это хранилище.
- Векторное хранилище, в котором сохраняются векторы пар «вопрос пользователя — SQL-запрос». Это хранилище будет использоваться для того, чтобы быстро находить SQL-запросы, релевантные вопросу пользователя.
- Основанный на LLM SQL-агент, который «берёт» текст вопроса пользователя, преобразует его в SQL-запросы, выполняет эти SQL-запросы в хранилище данных, и затем формирует и выводит ответ пользователю в нужном формате.
Для реализации такого решения нужно применить много разных технологий (это и RAG, и txt2sql, ИИ-агенты, и много ещё чего интересного). Называется это Generative BI, и у нас есть интересная статья об этом.
В этой статье мы рассмотрим первый этап этой работы — это извлечение данных из источников и обработку их для того, чтобы они стали AI-ready. Особенность этого кейса в том, что источники данных — это разные конфигурации 1С.
Хороший ИИ = хорошие данные
Начинается всё с того, что нужно дать системе данные, на основании которых она будет формировать ответы. Без данных ничего работать не будет.
Поэтому если бы у нас спросили про жизненное кредо, то мы бы дополнили ёмкую формулировку Кисы Воробьянинова «Всегда» словами «Для хорошего ИИ нужны хорошие данные». Есть, конечно, и другие принципы, но они напрямую к работе не относятся.
У нас много статей и кейсов посвящены именно извлечению и подготовке данных для ИИ, и работа с данными — это большая, если не сказать, бОльшая часть всех наших проектов по внедрению ИИ.
В подготовке данных мы хорошо разобрались, умеем работать и с привычными базами и хранилищами, и со сложными — аудио, видео, изображения, сложные многостраничные документы и чертежи, ищем и скрейпим в интернете. В общем, чему только не научила нас жизнь в разных проектах.
Как Ахматова писала про то, откуда «растут стихи, не ведая стыда», так и наши датасеты — извлекаем, из чего только можем, интегрируем и анализируем, делаем обратный ETL и прочие интересные упражнения.
Потом на основании готовых данных настраиваем разные приложения с использованием искусственного интеллекта.
Поэтому на вопрос от потенциального заказчика, можно ли внедрить искусственный интеллект в аналитику, уверенно ответили «Да», даже не уточнили, что за источники данных.
Потенциальный наш заказчик всё же уточнил, что у него только несколько разных 1С, и больше ничего нет. Нет и обычного BI. Но мы не придали этому факту большого значения.
В ответ мы описали наши успехи в работе с данными, я вдохновенно про себя процитировал Ахматову, и на этом, довольные друг другом, мы разошлись. Мы — изучать структуру конфигураций 1С, а потенциальный заказчик — ждать генеративный BI.
Далее было много интересных открытий, нам пришлось подучиться и разобраться в особенностях 1С и узнать много нового.
В этой публикации рассмотрим, как из 1С создать AI-ready витрину и запустить Generative BI даже без привычной BI-платформы (сложно, но можно).
Как мы были наивны или первое столкновение с реальностью
На следующий день коллеги выгрузили дампы, и мы взялись за изучение.
Эксперт из операционного подразделения компании-заказчика описал AS-IS: «У нас нет BI-системы. Есть четыре конфигурации 1С и несколько Excel-таблиц. Чтобы ответить на вопрос типа «Почему у нас просела прибыль в таком-то филиале?», нужно выгрузить данные из определённой конфигурации 1С, очистить вручную в Excel, отправить нашему аналитику, подождать 2 дня. А потом пересчитать, потому что данные были из старой выгрузки».
До этого разговора мы наивно предполагали, что в компании уже были механизмы для регулярной выгрузки определённых объектов из разных 1С в хранилище. С ним и планировали работать. Но только в этот момент поняли, что ни выгрузок, ни самого хранилища нет.
Нам самим нужно превратить данные из 1С в слой данных, к которому наши AI-агенты смогут обращаться с SQL-запросами.
Пока мы осознавали этот нехитрый вывод, ИТ-директор уверенно подытожил результаты нашего звонка: «Готовы дать время, но предупреждаю сразу: если данные в 1С окажутся непригодными для вашего искусственного интеллекта без доработок, пилот рискует затянуться — у нас нет аппетита на доработку 1С ни силами своего разработчика, ни с привлечением подрядчиков».
Что мы имеем
В организации используются несколько независимых баз 1С с разными конфигурациями: 1C Управленческий учет, Управление торговлей, ЗУП, кастомное решение на 1С. Каждая конфигурация имеет собственную структуру данных и назначение и все развиваются независимо друг от друга и используются разными бизнес-линиями.
В дополнение к этому есть несколько внешних источников: складские и логистические сервисы, а также несколько XLSX-файлов, которые сотрудники регулярно заполняют вручную.
Одно и то же значение (например, остаток на складе), может храниться в трёх-четырёх базах данных и файлах одновременно. Любое изменение в одной из конфигураций «1С» оборачивается несколькими днями кропотливой правки формул, сводных таблиц и проверок связей в Excel.
Ну что ж — не так уж и плохо.
Может быть, обойдёмся без консолидации данных из разных 1С?
Сначала мы предложили такой подход: при формулировке запроса пользователь указывает, из какой именно конфигурации 1С нужно «добыть» данные. Наша система могла бы использовать эту подсказку, чтобы направить запрос в указанную базу.
Но эксперт возразил: «Наши конечные пользователи — собственник и руководство компании. Они не будут помнить, в какой базе хранится тот или иной показатель, не станут разделять свои вопросы по «бухгалтерии» или «продажам» или что-то уточнять. Нужен максимально простой интерфейс, который сразу понимает бизнес-контекст».
То есть нам придётся каким-то образом выгрузить данные из 1С, консолидировать их в одну витрину, и сделать так, чтобы пользователь не думал о том, сколько систем используется для подготовки ответа.
Почему 1С — это не просто ещё одна БД
Если совсем схематично, то в обычной СУБД имена таблиц и полей обычно отражают бизнес-понятия: «product», «order», «customer». В 1С же всё выглядит не так:
- Catalog_Номенклатура вместо «товары»
- Document_РеализацияТоваров вместо «чек»
- AccumulationRegister_ОстаткиТоваров вместо «остатки»
Поля тоже называются по-своему: «СвойствоНоменклатурыРегл», «БлокПхДвижений» и так далее. Как разобраться, к чему относится «БлокПхДвижений» (и что это вообще такое)?
Наш SQL-аналитик не смог найти многие значения без дополнительной «расшифровки» и изучение SQL-дампов оказалось бесполезным: названия таблиц и полей «придумывает» 1С, а бизнес-смысл лежит в метаданных. Из чего мы сделали неутешительный вывод, что без погружения в 1С ничего не получится.
Разобрались, что хранение данных в 1С строится вокруг объектов метаданных: справочников, документов и регистров, которые описаны в конфигураторе как классы с атрибутами и табличными частями.
Справочники
Справочники отвечают за мастер-данные: товары, контрагенты, сотрудников, склады и т.д.
Каждому справочнику соответствует таблица Catalog_<Имя>, где <Имя> — это имя справочника, заданное разработчиком (например, Catalog_Контрагенты, Catalog_Номенклатура и т.д.).
Если в конфигураторе к справочнику добавляются новые реквизиты или табличные части, то схема справоничка не меняется, а автоматически создаются дополнительные таблицы, например:
- Catalog_<Имя>_Extension
- Catalog_<Имя>_Attributes
В этих таблицах хранятся дополнительные поля, которые не включены в основную таблицу.
Эти дополнительные таблицы сразу начали сбивать нас с толку. Чтобы получить все реквизиты справочника в одном представлении, приходится явно объединять основную таблицу и её extension-части:
Catalog_<Имя>
JOIN Catalog_<Имя>_Extension
JOIN Catalog_<Имя>_Attributes
Без этого данные из дополнительных таблиц останутся недоступными для аналитики.
Документы
Документы в 1С хранят всю историю бизнес-транзакций: продажи, закупки, перемещения, бухгалтерские проводки. Платформа генерирует для каждого документа две таблицы:
- Шапка документа (Document_<ИмяДокумента>). Например, для документа «Реализация товаров» название шапки могло бы быть Document_РеализацияТоваров. Содержит ключевые реквизиты: Номер, Дата, Контрагент, Статус. Ссылка (GUID) в качестве первичного ключа связывает шапку с табличной частью документа.
- Строки документа хранится в отдельной таблице с именем по шаблону Document_<ИмяДокумента>_<ИмяЧасти>, например, Document_РеализацияТоваров_Товары.
Табличная часть хранит значения в полях, например, код товара, количество, цену, единицу измерения и другие. C шапкой документа табличная часть связана через то же поле Ссылка. В табличной части часто встречаются ссылки и на другие объекты. Любые дополнительные реквизиты документа тоже переносятся в Extension-таблицы, так же как и в Справочниках.
Регистры
Регистры представляют собой механизм хранения и агрегации фактов.
- Накопительные регистры фиксируют обороты и остатки по любым измерениям — товары, склады, контрагенты и т. п.
- Бухгалтерские регистры — частный случай накопительных, настроенный под план счетов и субконто: формирует проводки и служит основой финансовой отчётности.
- Расчётные регистры накапливают результаты пред- и пост-расчётов (средние цены, коэффициенты, формулы) и сразу выдают готовые к использованию значения.
- Регистры сведений хранят справочную информацию — характеристики, базовые цены, связи — фиксируя изменения во времени без аккумулирования.
К регистрам 1С обращаются через виртуальные представления, например:
- РегистрНакопления.Остатки(НаДата) — мгновенный срез остатков
- РегистрСведений.<Имя>.СрезПоследних — последние значения реквизита
Все объекты описываются в Конфигураторе 1С. При публикации конфигурации платформа автоматически создаёт или изменяет физические таблицы, колонки, индексы и связи в СУБД. Все сложные соединения и встроенные процедуры подсчёта «спрятаны» внутри 1С.
Что это значит для нас
Скрытая физическая схема и метаданные
Нам стало ясно, что схема данных проектировалась для оптимальной работы 1С, а не для аналитиков. Поэтому одной из самых трудоёмких задач при работе с данными 1С является разбор её структуры.
В 1С – платформенно-зависимая система: разработчик определяет объекты конфигурации (справочники, документы, регистры и т. д.), а платформа сама создаёт физические таблицы в базе данных на основании метаданных. Все внешние связи (ссылки на справочники, табличные расширения, регистры) тоже создаются автоматом. Что для нас это значит:
- Один документ может ссылаться на десяток справочников, каждый из которых имеет свои дочерние справочники, табличные части и перечисления. Большинство колонок — это GUID-ссылки на другие объекты, а их имена – «непереводимая игра слов». Без выгрузки и обработки метаданных мы видим служебные таблицы и GUID, но не понимаем, как они связаны.
- В некоторых таблицах 1С (особенно регистров) ключ может быть сложным. Например, в регистрах накопления ключ составляет комбинацию измерений (измерения — тоже часто GUID’ы на справочники) плюс период (дата/время). А документы часто имеют два идентификатора: постоянный GUID и номер версии (для обеспечения целостности при изменениях).
- Сами бизнес-поля могут храниться под техническими именами. Например, основное свойство справочника обычно называется Description (наименование), код – Code, а вот пользовательские реквизиты могут быть вынесены в отдельные таблицы расширений (особенно, если в конфигурации они созданы как дополнительные). Документы хранят дату и номер: эти поля могут называться Date, Number, но другие реквизиты документа чаще будут просто Fld1, Fld2 и т.п.
- Так как у разработчика не было шанса написать аннотации к таблицам и полям, то и нам посмотреть описания негде.
Поэтому без обработки метаданных доступ к базам данных 1С оказался для нас бесполезным.
Язык запросов 1С
Все ключевые слова — ВЫБРАТЬ, ИЗ, ГДЕ, ОБЪЕДИНИТЬ, ГРУППИРОВАТЬ и пр. — на русском языке и расширены специализированными конструкциями для работы с табличными значениями. Это не просто «диалект» SQL, а собственный язык с уникальным синтаксисом.
Вместо явных JOIN-ов используются обращения вида
- Документ.РеализацияТоваров.Товары.Количество
- Справочник.Номенклатура.Свойства.Цвет
1С сама определяет связи между шапкой документа и его табличными частями.
Виртуальные представления регистров
Накопительные и информационные регистры сразу доступны как функции, например,
- РегистрНакопления.Остатки(НаДата) — остатки на дату
- РегистрСведений.Цены.СрезПоследних — последние значения
Все сложные JOIN-цепочки и встроенные процедуры подсчёта скрыты.
Операторы «КОГДА—ТОГДА»
Для внедрения логики прямо в выборку применяются условные операторы «КОГДА—ТОГДА»
КОГДА Документ.Сумма > 100000 ТОГДА ‘Крупная’
ИНАЧЕ ‘Мелкая’
КОНЕЦ AS ТипСделки
Это аналог CASE WHEN… THEN… ELSE… END в классическом SQL.
Скрытые перечисления
Строковые представления перечислений (специальных справочных списков) не дублируются в таблицах, а хранятся в метаданных конфигуратора. Прямым SQL-запросом получить названия значений нельзя — сначала нужно выгрузить метаданные.
Нет штатных инструментов для инкрементальных выгрузок
1С не предлагает встроенного механизма Change Data Capture: справочники, документы и регистры не «умеют» инкрементально выдавать только изменения. Приходится либо регулярно делать полные дампы, либо разворачивать собственные регистры истории для отслеживания «дельт».
Разнородные названия бизнес-реквизитов
Даже схожие по тематике конфигурации 1С имеют разные структуры хранения и используют разную терминологию.
Например, в типовой Управление торговлей (УТ) товарно-складские операции описываются документами «Реализация товаров и услуг», а в Бухгалтерии (БП) им может соответствовать бухгалтерский документ «Отгрузка» или набор проводок.
Одни и те же параметры могут называться по-разному: «РозничнаяЦена», «ЦенаПродажи» или «ЦенаПоДокументу». Для консолидации данных требуются единые словари терминов, основанные на метаданных конфигуратора. Один и тот же контрагент или товар может существовать в каждой базе данных со своим уникальным идентификатором и набором свойств. В семантическом слое нужно либо сопоставить эти записи (например, по ИНН для контрагентов), либо как минимум разделять их по источнику в отчетах. В «самописной» конфигурации 1С тем более могут использоваться специфические названия документов или дополнительные регистры.
Термины, привычные пользователям разных баз 1С, должны быть учтены в системе, и нам нужно придумать, как хранить и обрабатывать синонимы и пояснения для генеративного ИИ.
Учет «скрытой» бизнес-логики в 1С
Многие показатели и данные, которые видят пользователи в интерфейсе 1С, не хранятся явно в таблицах, а рассчитываются с помощью бизнес-логики платформы. При прямом доступе к таблицам эти алгоритмы не воспроизводятся и результаты вычислений будут утеряны.
При интеграции 1С с BI необходимо либо вызывать все соответствующие методы и регламентные процедуры платформы, либо воспроизводить их логику на стороне ETL. Иначе ответы и отчёты получатся неполными или искаженными из-за неучтённых курсовых разниц, скидок, переоценок и особенностей учета партий и так далее. Ниже приведены примеры скрытой бизнес-логики.
Пример 1. Регламентные обработки и пакетные расчёты
Закрытие месяца в конфигурациях «Бухгалтерия» и «Управление предприятием» автоматически рассчитывает себестоимость, амортизацию, курсовые разницы и сохраняет результаты в регистрах накопления и бухгалтерских проводках. Если брать только первичные документы, итоговые показатели не совпадут с отчётами в 1С.
В «ЗУП» по расписанию выполняется обработка расчёта зарплаты: суммируются часы, налоги и другие начисления, и всё это сохраняется в Регистре РегистрРасчетаНачислений. Прямая выгрузка табличных частей документов даст лишь «черновые» данные.
Пример 2. Динамические вычисления «на лету»
Отчёты в некоторых конфигурациях строятся запросами на встроенном языке 1С в момент открытия формы. Результат не сохраняется в отдельных таблицах, и его нельзя воспроизвести простым SQL-запросом.
Пример 3. Логика отбора и классификации документов
Часто «Продажи за день» в 1С означают не все отгрузки, а документы определённых типов или статусов. Правила фильтрации описаны в модулях или макетах отчётов и неочевидны.
Пример 4. Курсовые и ценовые пересчёты
Процедура ConvertCurrency() автоматически пересчитывает суммы в нужную валюту при проведении документов. В таблице транзакций хранится результат уже после пересчёта, но при простой выгрузке исторических данных без запуска этой процедуры вы получите «сырые» значения, без учёта актуального курса.
Аналогично ApplyDiscounts() рассчитывает скидки и наценки в момент выполнения документа. Без вызова этой логики неясно, откуда узнать реальную цену продажи.
Пример 5. Закрытие партий и остатки на складе
Таблица регистра накопления AccumulationRegister_ОстаткиТоваров содержит движения по партиям, но не всегда отражает итоговые остатки. Чтобы получить окончательные значения, нужно запустить регламентную процедуру «ЗакрытиеПартий» — она сверяет и аккумулирует данные по сериям, партиям и характеристикам.
Без этого шага выгрузка покажет «промежуточные» остатки, а не фактическое наличие товаров.
Пример 6. Регистры расчёта и бухгалтерские проводки
Многие суммы (например, средняя себестоимость, начисления зарплаты) формируются в регистрах расчёта и бухгалтерии при выполнении регламентных заданий («НачислениеЗарплаты», «ЗакрытиеПериода» и т. д.). При простом SQL-выборе из таблиц регистров вы получите только грубые данные об операциях, без итоговых значений и коррекций.
В результате мы поняли, что работа с данными 1С требует не просто выполнения SQL-запросов, а изучения метаданных, использования конфигуратора и встроенного языка запросов 1С.
Обзор вариантов извлечения данных из 1С
Использование штатных отчётов и выгрузок из 1С
В 1С есть стандартный механизм «Рассылка отчётов»: после создания Универсального отчёта (выбор объекта, полей, фильтров и периода) и сохранения его варианта в меню «Рассылки отчётов» задаются формат (Excel/CSV/XML), путь (локальная папка, FTP/WebDAV) и расписание (по времени или событию).
У этого способа есть ограничения: при каждом запуске выгружается полный срез, инкрементальные обновления недоступны. Если нужного набора полей нет в стандартных отчётах, придётся привлекать 1С-разработчика для создания своего варианта отчёта.
Этот вариант мы оставили «на подумать»: есть идея, что можно разработать AI-агента, который будет регулярно запускать этот отчёт, обрабатывать и использовать данные из отчётов как источник данных. Если идея окажется удачной, опишем этот кейс отдельно.
Публикация базы 1С в интернете и подключение к ней по протоколу OData
Сейчас один из самых простых и популярных способов получить доступ к данным 1С из BI-систем — это опубликовать базу 1С на веб-сервере и включить стандартный OData-интерфейс.
После публикации базы на веб-сервере можно отправлять HTTP-запросы к URL вида …/odata/standard.odata/Каталог_Номенклатура, и получать данные в формате JSON или XML.
Это официальный способ интеграции, не нарушающий лицензии, так как работает через предусмотренный API 1С.
Можно фильтровать данные на стороне запроса (например, сразу запрашивать изменения за период или отдельные объекты) и использовать некоторые специальные параметры 1С (например, ?$expand для получения связанных данных, или преобразование ссылок GUID в значения).
У этого простого решения есть и ограничения:
- Падение производительности при увеличении числа записей время отклика резко растёт или выдаётся ошибка таймаута.
- Ограничения длины URL. Сам протокол OData не имеет ограничений, но веб-серверы и клиенты часто ограничивают длину GET-URL до ~2 000 символов, а это усложняет составление сложных фильтров и сортировок.
- Не все компании готовы публиковать 1С в интернете или корпоративной сети из-за угроз утечки. OData-доступ требует настроить HTTPS, аутентификацию (Basic Auth, OAuth) и организовать ролевой доступ, чтобы не открывать «лишние» объекты.
Мы пришли к выводу, что OData подходит для небольших и простых интеграций, для выгрузки справочников или небольших таблиц, либо при отсутствии прямого доступа к СУБД (например, если база файловая). Для промышленных BI-проектов с большими объёмами и SLA лучше посмотреть другие варианты.
Построение собственной аналитической базы SQL и наполнение её данными из выгрузок из 1С
Во многих крупных проектах аналитики приходят к необходимости собственного SQL-хранилища данных. Это классическая схема, когда сначала вы настраиваете выгрузку «сырых» данных из разных источников 1С в промежуточную базу. Там же создаёте представления – «превращаете» справочники, регистры и документы 1С в подходящие для анализа таблицы с понятными полями.
Для того, чтобы загружать данные в это хранилище, нужно разработать процедуры, которые формируют запросы к базе 1С и выгружают результаты выполнения запросов в соответствующие таблицы.
Для эксперта 1С разработать такие запросы не сложно, тем более что многие уже используют для ускорения работы большие языковые модели и основанные на них инструменты — помощники. Интересную статью на эту тему можно посмотреть на Хабре «Вайб кодинг в 1С. Лучшие нейросети для генерации 1С кода».
Проектирование такого хранилища – тоже стандартная задача для аналитика, и главное здесь – это аккуратно изучить все источники данных и правильно их объединить, и подготовить для анализа.
Этот вариант был бы идеальным для нас, если бы не то, что он – самый дорогой из всех вариантов, что мы рассмотрели.
Как только платформа или конфигурация 1С обновляется, меняются имена таблиц, полей и регистрационных процедур, наши view, жёстко прописанные под старую схему, тут же перестают работать. Каждое обновление требует переписывания ETL-скриптов и тестированию витрин.
Для нас этот метод не подошёл, так как он предполагает это высокую стоимость разработки, «наполнения» и поддержки хранилища. А у нашего заказчика желания задействовать 1С-разработчика и аналитика для этого проекта не было.
COM-соединение (COMConnector)
1С предоставляет COM-интерфейс для внешних программ, позволяющий запустить экземпляр 1С «внутри» другого приложения. Через COMConnector можно открыть нужную информационную базу и вызывать методы 1С, читать данные и выполнять 1С-запросы.
Этот метод даёт полный доступ к данным и логике 1С. Можно обращаться к объектам, использовать встроенный язык запросов 1С для выборки сложных данных, вызывать процедуры конфигурации (например, расчётные обработки). Это особенно полезно, если нужно применить часть бизнес-логики 1С при выгрузке (см. раздел о скрытой логике).
Минусы у этого способа такие: COM-соединение работает только под Windows (где установлен тонкий или толстый клиент 1С) и на каждое одновременное соединение расходуется лицензия 1С, что критично при ограниченном числе пользовательских лицензий. Также есть технические нюансы: версия клиентского приложения 1С должна совпадать с версией платформы базы, а при обновлении конфигурации может потребоваться обновлять и перерегистрировать COM-объект.
Кроме того, COM-соединение не самое быстрое: при подключении 1С инициализирует сессию, прогружает часть данных, поэтому время подключения пропорционально объёму базы. В многопоточных сценариях это узкое место, т.к. сессии в 1С открываются долго.
Также для нас узким местом стало то, что для использования COM-коннектора нужно писать код на стороне внешнего приложения с пониманием синтаксиса 1С, что опять-таки требует квалификации 1С-программиста, которых у нас нет.
Экстрактор внутри 1С
Ещё один подход – установить в базу 1С специальное расширение, которое само выгружает данные во внешнее хранилище. Этот способ использует возможности самой 1С для чтения данных, но автоматизирует и оптимизирует процесс выгрузки.
Плюсы экстрактора
Работает внутри платформы 1С, а значит, не нарушает её ограничения. Расширение знает структуру метаданных и может автоматически формировать необходимые запросы ко всем объектам. Современные инструменты позволяют настроить такую выгрузку без программирования: настраивается в пользовательском режиме 1С и формирует наборы данных (справочники, документы, регистры) для выгрузки. Преимущество – совместимость с любыми конфигурациями 1С и наличие встроенных возможностей: многопоточная выгрузка, инкрементальный режим, автоматическое создание таблиц в целевой БД.
Минусы экстрактора
Это дополнительное ПО, обычно коммерческое. Его нужно установить и сопровождать. Хотя программировать не нужно, всё же требуется знание структуры данных 1С при настройке наборов данных. Кроме того, выгрузка всё равно потребляет ресурсы самой 1С: при больших объёмах интенсивный отбор данных может нагружать сервер 1С. Нужно планировать выполнение таких выгрузок в регламентное время, чтобы «не мешать» пользователям.
Нельзя использовать прямой SQL-доступ к физическим таблицам
1C есть лицензионные ограничения, которое сильно меняет стандартный подход к организации хранилища. На первый взгляд кажется простым: берём ODBC/JDBC-драйвер, подключаемся к MS SQL или PostgreSQL и читаем таблицы.
Но с 1С это невозможно: здесь мы упираемся в лицензионные ограничения (1С запрещает прямые запросы к боевой базе) и в «чёрный ящик» зашифрованных имён таблиц и полей, о которых поговорили ранее. Любая попытка обратиться к БД 1С SQL-скриптами ведёт к отказу в поддержке платформы и рискам нарушить целостность данных.
Мы не поверили сразу
И проверили: действительно, ни одна из популярных BI-платформ не умеет «читать» внутреннюю модель 1С напрямую.
Ну ладно Power BI, Tableau, QuickSight и прочие западные, с ними все ясно, но и наши Yandex Datalens, Visiology, Loginom — работают с 1С только с использованием внешних экстракторов данных.
Ага, это уже что-то. Значит, экстракторы уже зарекомендовали себя в промышленных внедрениях.
Выбранное решение: коммерческий Data-Extractor из 1С
Мы с командой Заказчика пришли к выводу, что нам нужен готовый data-extractor, способный «понимать» сложную внутреннюю структуру 1С и автоматически загружать данные в удобную витрину для наших AI-агентов, при этом не нарушая лицензионных условий 1С.
Сначала мы составили список ключевых требований: экстрактор должен распознавать все объекты 1С без ручного описания, позволять применять кастомные правила преобразования и при этом умеет выгружать не весь объём, а только «дельты» изменений, чтобы укладываться в ночное окно обработки.
Изучили пять решений и остановились на Denvic Extractor. Это расширение устанавливается непосредственно в 1С и по расписанию выгружает только изменённые данные, автоматически собирает все справочники и регистры, разбирает метаданные и разворачивает схему с готовыми представлениями.
Кроме того, классные видео и описания Denvic позволили нам относительно быстро погрузиться в проблему – спасибо маркетологам и техническим писателям Denvic за наше образование в 1C.
Заключение
Теперь, мы можем приступить к построению самого DWH-слоя и сосредоточиться на разработке представлений. Об этом — в следующей статье. Всего статей c описанием этого проекта будет ещё 2:
- Статья 2: Построение DWH: Схемы хранения, настройка CI/CD для DDL-скриптов и мониторинг качества данных.
- Статья 3: Настройка AI-агента: RAG-слой, txt2sql, метрики качества, построение графиков и отладка в продакшене. Здесь же рассмотрим интересные особенности, с которыми мы столкнулись (например, как «объяснили» системе, что значит «этот месяц» или «текущий квартал» и как решили вопросы, откуда взяли столько пар «вопрос-sql» и как мерили качество ответов).
Запишитесь к нам на демонстрацию, и мы расскажем, как быстро внедрить AI-агентов и сделать ваши 1C ещё более удобными и полезными.
