Выгрузка данных из 1С: OData, СКД, SQL и репликация

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

Способ подключения решает только часть задачи. Нужно определить, какие данные выгружать, как замечать изменения и по каким ключам связывать таблицы. Разберём пять подходов: СКД и файлы, OData, собственный HTTP-сервис, прямое чтение SQL и отдельную копию базы. Основная часть статьи относится к «1С:Предприятию 8»; для старых платформ и конкретных облачных размещений доступные механизмы проверяют отдельно.

Материал посвящён технической стороне работы аналитика и разработчика. Если сначала нужно определить отчёты для руководителя, выбрать платформу и спланировать проект, начните с выбора BI-системы для 1С и плана внедрения аналитики.

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

1. Сначала определите, что считать данными о продажах

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

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

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

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

2. Как выбрать способ выгрузки данных из 1С

Метод	Когда подходит	Что предусмотреть
СКД → CSV/Excel	Нужны согласованные таблицы и обновление по расписанию	Стабильную структуру файла, запуск выгрузки и доставку
OData	Есть веб-публикация 1С и нужны доступные через неё объекты	Права, постраничное чтение, нагрузку и учёт изменений
HTTP-сервис или внешняя обработка	Нужны специальные расчёты, формат или правила обмена	Разработку, контроль ошибок и поддержку после обновлений
Прямое чтение SQL	Есть доступ к СУБД и специалисты по структуре конкретной базы	Поддерживаемость подхода, расшифровку таблиц, права и нагрузку
Копия или реплика базы	Тяжёлую аналитику нужно вынести на отдельные ресурсы	Согласованность копии, задержку, изменения схемы и обслуживание

Готовые коннекторы могут сочетать эти методы: выполнять запросы через платформу, читать OData, принимать файлы или переносить изменения из СУБД. При выборе полезно выяснить, какой именно механизм работает внутри, где выполняются расчёты и что произойдёт после изменения конфигурации. Название продукта этого не объясняет.

3. СКД и файлы: выгрузить подготовленный набор

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

СКД сама по себе не является транспортом обмена. Сохранение CSV или Excel, запуск по расписанию, отправка и повторная доставка организуются отдельно — средствами конфигурации, обработкой или заданием. В файловом варианте базы особенно важно проверить, при каких условиях действительно запускается выбранный механизм расписания.

Рабочая схема выглядит так: 1С → подготовленная таблица → CSV → закрытое хранилище → загрузка в BI или аналитическую базу. Такой подход описан и на странице интеграции 1С с BI. Исходящая отправка по HTTPS или SFTP позволяет построить обмен без входящего подключения из интернета к серверу 1С; принимающая сторона при этом должна быть доступна отправителю.

Таблица для человека и таблица для загрузки

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

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

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

4. OData: читать объекты через интерфейс платформы

Стандартный REST-интерфейс 1С использует OData 3.0. После настройки веб-публикации внешняя система получает доступ к опубликованным объектам через HTTP. Доступны справочники, документы, регистры и предусмотренные платформой виртуальные таблицы; конкретный состав и права нужно проверять в своей базе. Официальное описание — REST-интерфейс 1С.

Начинают с документа $metadata: он описывает доступные сущности и типы. Затем выбирают нужные поля и ограничения. Опции $select, $filter, $orderby, $top и $skip помогают сократить ответ и читать данные порциями. Поддержку конкретных выражений сверяют с версией платформы; материал 1С о расширении OData показывает, как эти возможности развивались.

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

Где возникают сложности

Постраничное чтение не равно согласованному снимку. Если во время обхода данные меняются, смещения страниц могут привести к пропускам и повторам. Нужны устойчивый порядок, контроль ключей и стратегия повторной сверки. Там, где интерфейс и данные позволяют, используют отбор по последнему обработанному ключу; согласованность связанных наборов всё равно проверяют отдельно.

Фильтр по дате документа не ловит все изменения. Документ за прошлый месяц могут изменить сегодня. Наличие OData не означает, что готов журнал всех исправлений и удалений. Этот механизм нужно спроектировать отдельно.

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

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

У Power Query есть источник OData Feed. Но успешное подключение на компьютере ещё не подтверждает обновление в облачном сервисе: отдельно проверяют сетевую доступность, способ авторизации и необходимость шлюза. Наличие HTTPS-адреса само по себе не доказывает, что шлюз не нужен. Аналогично запросы в режиме прямого доступа к базе могут переносить нагрузку от каждого действия пользователя в источник.

5. HTTP-сервис и внешняя обработка: задать правила обмена

Собственный HTTP-сервис полезен, когда BI нужен подготовленный набор с определённым смыслом: например, отгрузки с возвратами и расшифровкой аналитик. Разработчик выполняет запросы и расчёты на стороне 1С и формирует ответ согласованной структуры. В отличие от автоматически сформированного интерфейса, состав ответа задаётся кодом; возможности платформы описаны в документации HTTP-сервисов.

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

Чтобы такую интеграцию можно было сопровождать, заранее определяют:

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

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

Если в действующей интеграции используется COM

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

Сохранение действующего COM-обмена или переход на HTTP решают по требованиям к размещению и сопровождению. Сам по себе файловый режим базы не означает, что COM — единственно возможный вариант.

6. Прямое подключение к SQL: доступ к таблицам ещё не готовая модель

Если 1С работает в клиент-серверном варианте и администратор предоставляет доступ к СУБД, технически можно читать физические таблицы, например в Microsoft SQL Server или PostgreSQL. Файловая база .1cd не превращается в обычный SQL-источник от наличия доступа к её файлу.

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

Дополнительно проверьте официальный FAQ 1С по лицензированию, вопрос X.6-65: он распространяет ограничения внесистемного доступа и на прямое чтение таблиц; применение средств СУБД связывается с явными рекомендациями документации для конкретной задачи. Наличие SQL-доступа и создание реплики сами по себе эти условия не отменяют. Отдельная аналитическая база, наполненная через предусмотренный платформой обмен, — другой сценарий.

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

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

Практические ограничения

• Только чтение. Для аналитической интеграции не выполняют прямые записи в таблицы 1С и не добавляют в рабочую базу свои индексы или триггеры без отдельного проектного решения.
• Права задаются заново. При обходе платформы ограничения пользователя 1С автоматически не действуют. Доступ к организациям, зарплате и другим чувствительным данным ограничивают в СУБД, витрине и BI.
• Нагрузка остаётся. Даже чтение потребляет процессор, память и диск; влияние блокировок зависит от СУБД и режима изоляции. «Без блокировок» не должно означать чтение несогласованных данных.
• Нужен ответственный за схему. После обновления 1С проверяют соответствие полей, типы, количество строк и контрольные показатели.

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

7. Копия, реплика и аналитическое хранилище — разные варианты

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

Восстановленная копия на определённый момент

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

Файл резервной копии или выгрузка .dt не являются таблицей для подключения BI: сначала требуется восстановление и способ чтения данных. Простое копирование файлов работающей СУБД или активной файловой базы без предусмотренной процедуры не гарантирует согласованность.

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

Реплика средствами СУБД

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

Физическая реплика и логическое копирование таблиц имеют разные свойства. При логической репликации PostgreSQL изменения схемы не переносятся автоматически; после обновлений нужно поддерживать совместимость схем. Это ограничение зафиксировано в документации PostgreSQL. Для других СУБД и редакций проверяют свои возможности и условия.

Аналитическое хранилище с загрузкой изменений

В хранилище данные переносят через API, файлы, согласованный SQL-доступ или механизм захвата изменений — CDC. Затем приводят к удобной структуре и связывают с CRM, рекламой и планами. Здесь можно хранить историю и создавать собственные индексы независимо от учётной базы.

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

Реплика не заменяет резервное копирование и историю. Ошибочные изменения и удаления могут попасть на неё следом за рабочей базой. Если нужно видеть состояние «как было на дату», проектируют снимки или версии отдельно.

8. Как обновлять данные и не терять исправления

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

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

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

1. Зафиксируйте партию. Сохраните идентификатор запуска, границы отбора и контрольную позицию. Чтение нескольких таблиц в разное время не даёт автоматически единый снимок.
2. Загружайте повторяемо. Повтор одной партии должен давать тот же результат. Используйте обновление по устойчивому ключу или замену согласованного среза.
3. Учитывайте удалённые строки. Если у документа было пять позиций, а стало четыре, добавление и обновление строк оставит лишнюю пятую. Нужна синхронизация полного состава документа или явные события удаления.
4. Публикуйте после проверки. Сначала загрузите промежуточные таблицы, проверьте полноту и связи, затем переключите отчёт на готовую партию. Контрольную позицию продвигайте только после успешного завершения.
5. Пересчитывайте прошлое. Скользящее окно повторной загрузки помогает ловить поздние исправления. Оно не гарантирует полноту, если корректировки возможны за его пределами; нужна дополнительная сверка или обработка таких событий.

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

9. Как связать выгрузки и не умножить суммы

Храните идентификаторы, а не только представления

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

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

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

Не соединяйте две детализации напрямую

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

Показатель	До соединения	После ошибочного JOIN
Стоимость товаров	1 000 + 2 000 + 3 000 = 6 000 ₽	12 000 ₽: каждая позиция повторилась дважды
Сумма платежей	2 500 + 3 500 = 6 000 ₽	18 000 ₽: каждый платёж повторился трижды

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

Сопоставляйте 1С с CRM по явным правилам

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

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

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

10. Как подготовить выгрузку к загрузке в BI

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

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

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

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

11. Как проверить полноту и корректность выгрузки

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

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

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

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

Читайте также руководство по выбору BI для 1С и запуску пилотного проекта и материал о том, как выгружать данные Битрикс24 для общей аналитической модели. Технические положения сверены с доступной официальной документацией на 3 октября 2026 года. Возможности вашей версии платформы, конфигурации и среды размещения нужно проверить перед внедрением.