Все методы выгрузки данных из 1С для BI в 2026

OData REST-интерфейс

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

После публикации веб-сервера (IIS или Apache) доступ идёт по URL вида:

# Получить справочник Номенклатура
GET http://1c-server/base/odata/standard.odata/Catalog_Номенклатура?$format=json

# Отфильтровать + выбрать поля
GET http://1c-server/base/odata/standard.odata/Catalog_Номенклатура
    ?$filter=IsFolder eq false and DeletionMark eq false
    &$select=Ref_Key,Description,Code,Артикул
    &$format=json

# Пагинация + сортировка
GET http://1c-server/base/odata/standard.odata/Document_РеализацияТоваровУслуг
    ?$filter=Date ge datetime'2026-01-01T00:00:00'
    &$top=1000
    &$skip=0
    &$orderby=Date
    &$format=json

Поддерживается Basic/NTLM/Windows-авторизация. Протокол OData v3 и v4 (зависит от версии платформы). Также доступны связанные сущности через $expand: ?$expand=Товары,Склад.

Инкрементальная выгрузка. Каждый объект имеет служебное поле DataVersion — бинарную метку, которая меняется при любом изменении записи. Схема: храните максимальный DataVersion из последней выгрузки, делаете $filter=DataVersion gt 'xxx' — получаете только изменения. Работает, но DataVersion непредсказуемо меняется при массовых операциях 1С.

Когда применять: справочники (номенклатура, контрагенты, подразделения) до 100 тыс. строк, где полная перезаливка раз в сутки устраивает. Документы до 500 тыс. строк с инкрементом по Date + DataVersion. На регистрах накоплений с миллионами строк OData упирается в потолок.

HTTP-сервисы (собственные endpoints)

В Конфигураторе создаётся объект «HTTP-Сервис» с методами (GET/POST), внутри которых вы пишете 1С-код: делаете запрос через Запрос.Выполнить(), собираете результат, возвращаете JSON или XML. Полная свобода в том, что и как возвращать.

// 1С-код: метод GET в HTTP-сервисе
Процедура ВыполнитьПолучениеПродажПериод(Запрос, Ответ)
    ДатаС = Запрос.ПараметрыURL["ДатаС"];
    ДатаПо = Запрос.ПараметрыURL["ДатаПо"];

    ЗапросДанных = Новый Запрос;
    ЗапросДанных.Текст =
        "ВЫБРАТЬ
        |   Продажи.Период КАК Дата,
        |   Продажи.Номенклатура.Код КАК НоменклатураКод,
        |   Продажи.Количество,
        |   Продажи.Стоимость
        |ИЗ
        |   РегистрНакопления.Продажи.Обороты(&ДатаС, &ДатаПо, Период) КАК Продажи";
    ЗапросДанных.УстановитьПараметр("ДатаС", ДатаС);
    ЗапросДанных.УстановитьПараметр("ДатаПо", ДатаПо);

    Результат = ЗапросДанных.Выполнить().Выбрать();

    МассивДанных = Новый Массив;
    Пока Результат.Следующий() Цикл
        Элемент = Новый Структура(
            "Дата,НоменклатураКод,Количество,Стоимость",
            Результат.Дата, Результат.НоменклатураКод,
            Результат.Количество, Результат.Стоимость
        );
        МассивДанных.Добавить(Элемент);
    КонецЦикла;

    Ответ.УстановитьТелоИзСтроки(
        ЗначениеВJSON(МассивДанных),
        "UTF-8"
    );
КонецПроцедуры

Когда применять: нужны агрегаты (обороты регистров, итоги по группам), сложные выборки с join-ами, быстрая выгрузка больших объёмов с преагрегацией. Когда ETL-команда хочет получать готовые витрины, а не сырые строки.

Совет: держите endpoints в отдельной подсистеме «Интеграция_DWH» — это упрощает поддержку и отделяет их от основной бизнес-логики. И сразу версионируйте: /api/v1/sales, а не просто /api/sales.

Прямой SQL к базе MS SQL Server

1С:Предприятие 8 хранит данные в MS SQL Server (или PostgreSQL) в собственных таблицах с закодированными именами. Если подключиться к базе напрямую через SQL Server Management Studio или ADO.NET, можно читать данные без участия сервера 1С. Скорость — максимально возможная для SQL-базы.

Структура имён таблиц 1С:

_Reference123         — справочник (ID 123 в метаданных)
_Reference123_VT456   — табличная часть справочника
_Document84           — документ
_Document84_VT789     — табличная часть документа
_DocumentJournal12    — журнал документов
_AccumRg45            — регистр накопления (движения)
_AccumRgT45           — таблица итогов регистра
_AccRg30              — регистр бухгалтерии
_InfoRg67             — регистр сведений
_Enum10               — перечисление
_Const                — константы
Config                — метаданные (XML)
DBSchema              — структура базы
Params                — параметры базы

Главная сложность: цифры в именах таблиц не соответствуют никакому очевидному порядку. Mapping «_Reference123 = справочник Номенклатура» хранится в таблице Config и в XML-файлах конфигурации. Без reverse-инжиниринга метаданных прямой SQL бесполезен.

Типичные grаbli:

• GUID хранятся как BINARY(16). Чтобы увидеть как строку: CAST(_IDRRef AS UNIQUEIDENTIFIER).
• Ссылочные поля — это пара колонок. Одна хранит тип объекта (_Fld123_TYPE), другая — ID (_Fld123_RRRef). Для составного типа нужна CASE-конструкция.
• Даты хранятся со смещением на 2000 лет вперёд. DATEADD(year, -2000, _Date_Time) возвращает реальную дату.
• Строки в NVARCHAR фиксированной длины — с паддингом пробелами. RTRIM() обязателен.
• Булевы значения — как BINARY(1). CAST(_Fld456 AS TINYINT).
• NULL в ссылках представлен как 0x00000000000000000000000000000000, не SQL NULL.

Минимальный пример:

-- Справочник Номенклатура (после reverse: _Reference123)
SELECT
    CAST(_IDRRef AS UNIQUEIDENTIFIER) AS ref_guid,
    RTRIM(_Code) AS nom_code,
    RTRIM(_Description) AS nom_name,
    _Folder AS is_folder,
    _Marked AS is_deleted
FROM _Reference123 WITH (NOLOCK)
WHERE _Marked = 0x00;

Рекомендация: используйте read-only replica (AlwaysOn) или snapshot isolation — так вы не блокируете продуктивную базу. Для автоматизации reverse-инжиниринга есть Tool_1CD (читает XML-конфигурацию, генерирует mapping), ATK Extract и другие — см. следующие методы.

ATK BI View

Коммерческий инструмент от Analytical Technology Group (ATG). Снимает главную боль прямого SQL: автоматически генерирует набор SQL VIEW поверх базы 1С с человекочитаемыми именами колонок, правильной распаковкой GUID и дат, разворачиванием ссылок.

Вместо SELECT _IDRRef, _Description FROM _Reference123 вы пишете:

SELECT
    nom_guid,
    nom_code,
    nom_name,
    nom_parent_code,
    nom_unit_name,
    is_deleted
FROM ATK.v_Catalog_Nomenclature
WHERE is_deleted = 0;

VIEW хранятся в отдельной схеме (например, ATK), исходная 1С-база не изменяется. Генератор ATK периодически (по расписанию) пересчитывает VIEW при изменении структуры 1С.

Когда применять: быстрый старт BI в средней компании без своей 1С-команды; когда DWH-команда знает SQL, но не хочет разбираться с внутренней структурой 1С. Типовой срок от установки до первой витрины — 1-2 недели.

Denvic Extractor

Ещё один коммерческий инструмент, уровнем выше: уже не просто VIEW, а полноценный managed-ETL. Закрывает весь жизненный цикл: извлечение → CDC → SCD Type 2 → загрузка в целевую БД → оркестрация и мониторинг.

Архитектурно Denvic работает как отдельный сервис, который:

1. Подключается к источнику 1С (прямой SQL или реплика)
2. По расписанию/триггеру делает CDC: сравнивает текущий snapshot с предыдущим
3. Генерирует delta (inserted/updated/deleted) и применяет к целевой БД
4. Ведёт журнал изменений для audit и SCD Type 2 (исторические версии)
5. Алертит при аномалиях (скачок объёма, расхождение контрольных сумм)

Когда применять: несколько 1С-баз в холдинге (3-10+ юрлиц), нужен исторический срез данных и единый audit-trail, нет ресурсов на собственный ETL. Хорошо заходит там, где качество данных критично — в финансах и консолидации отчётности.

ПланОбмена + узлы регистрации

Встроенный в 1С механизм распределённых информационных баз (РИБ) и обменов данными. Идея: в конфигурации 1С создаётся объект метаданных «ПланОбмена» с узлами-получателями. Когда объекты изменяются, 1С автоматически регистрирует факт изменения для подписанных узлов.

Внешняя система (ваша BI-платформа, DWH) выступает как узел-получатель. Забирает через HTTP/COM/файл-обмен только изменения с момента последней квитанции, применяет к себе и подтверждает получение. 1С очищает регистрацию изменений для этого узла.

// В 1С создаём узел "DWH" в ПланеОбмена "ОбменСBI"
// Регистрируем изменения для объекта "Продажи"

// Чтение изменений через HTTP-сервис
ВыборкаИзменений = ПланыОбмена.ОбменСBI.ВыбратьИзменения(
    Узел, НомерСообщения
);
Пока ВыборкаИзменений.Следующий() Цикл
    // Сериализуем в JSON/XML, возвращаем внешней системе
КонецЦикла;

// После подтверждения получения внешней системой
ПланыОбмена.ОбменСBI.УдалитьРегистрациюИзменений(
    Узел, НомерСообщения
);

Когда применять: near-real-time BI (каждые 5-15 минут), когда нельзя пропустить ни одного изменения (финансы, остатки). Часто комбинируется с HTTP-сервисом: endpoint читает регистрацию изменений для узла DWH и отдаёт delta в JSON. ETL на стороне BI применяет изменения и подтверждает квитанцией.

КД 3.0 (Конвертация данных)

Универсальный механизм обмена между конфигурациями 1С. Правила обмена описываются в отдельной подсистеме КД («Конвертация данных»), данные выгружаются в XML-файлы по схеме Enterprise Data.

Для BI применяется редко: формат XML-сообщений тяжёлый, обмен идёт пакетами, полной автоматизации нет. Обычно используется для миграций между 1С-базами (например, при смене конфигурации) или для интеграции с внешними учётными системами.

Когда применять для BI: редко, если вообще. Если в компании уже настроен обмен через КД, можно подцепить BI как получателя XML. Но парсинг больших XML, обработка ошибок и скорость делают этот путь хуже остальных. Упоминаем для полноты картины.