Как создать сводный отчет из нескольких баз 1С:ЗУП 2.5 и 3.1

Разберем непростую, но часто встречающуюся задачу: получение консолидированных данных по заработной плате из нескольких разрозненных информационных баз. В нашем случае мы имеем дело с «зоопарком» конфигураций: одной современной ЗУП 3.1 Корп и двумя устаревшими ЗУП 2.5. Ситуация осложняется тем, что все базы серверные, а данные по сотрудникам и подразделениям могут не совпадать в разных источниках.

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

Вариант 1. Использование COM-соединения (Классический метод)

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

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

Пример инициализации соединения может выглядеть следующим образом:

Попытка
    COMСоединение = Новый COMОбъект("V83.COMConnector");
    БазаИсточник = COMСоединение.Connect("Srvr='ServerName';Ref='BaseName';Usr='Login';Pwd='Password';");
Исключение
    Сообщить("Не удалось подключиться к базе: " + ОписаниеОшибки());
КонецПопытки;

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

Вариант 2. HTTP-сервисы и Web-сервисы (Современный подход)

Более надежным и быстрым вариантом является использование HTTP-сервисов. Вместо того чтобы «врываться» в чужую базу через COM, мы просим базу-источник подготовить и отдать данные в легком формате (JSON или XML).

Почему это лучше? Во-первых, HTTP-соединения работают быстрее и стабильнее в распределенных сетях. Во-вторых, они не блокируют сеансы для обновления конфигурации так агрессивно, как COM. Для баз ЗУП 2.5, если они работают на платформе 8.3, также можно настроить веб-сервер (Apache или IIS) и опубликовать сервисы.

Выясним причину популярности этого метода: он позволяет абстрагироваться от структуры данных базы-источника. База-приемник просто вызывает определенный URL, а база-источник возвращает готовую таблицу значений в формате JSON.

Вариант 3. Использование встроенного интерфейса OData (REST API)

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

Рассмотрим алгоритм действий:

1. Опубликовать информационную базу на веб-сервере.
2. Включить стандартный интерфейс OData для нужных объектов (например, для регистров расчета или накопления, где хранятся данные о начислениях).
3. Выполнять запросы из главной базы, получая данные в формате JSON.

Важный нюанс: для ЗУП 2.5 этот механизм доступен только в том случае, если она запущена на платформе версии 8.3.5 и выше.

Вариант 4. Прямое чтение из SQL (Внешние источники данных)

Для продвинутых разработчиков существует вариант прямого обращения к таблицам СУБД (MS SQL или PostgreSQL). Это самый быстрый способ получения данных, однако он требует глубокого понимания структуры хранения данных 1С.

Проанализируем ситуацию: имена таблиц в SQL (например, _InfoRg123) не соответствуют именам объектов в конфигураторе. Чтобы составить правильный запрос, необходимо использовать функцию ПолучитьСтруктуруХраненияБазыДанных() в базе-источнике.

Пример использования ADO для получения данных из внешней базы:

Connection = Новый COMОбъект("ADODB.Connection");
ConnectionString = "Driver={SQL Server};Server=MyServer;Database=MyBase;Uid=user;Pwd=password;";
Connection.Open(ConnectionString);

Recordset = Новый COMОбъект("ADODB.Recordset");
ТекстЗапроса = "SELECT * FROM _InfoRg123 WHERE _Period >= '2023-01-01'";
Recordset.Open(ТекстЗапроса, Connection);

Внимание: прямое чтение таблиц SQL не нарушает лицензию 1С, но изменение данных (INSERT/UPDATE) через SQL категорически запрещено и может привести к разрушению логической целостности базы.

Вариант 5. Архитектура с «Буферной базой»

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

Посмотрим на шаги реализации этого метода:

1. В базах ЗУП 2.5 и ЗУП 3.1 создаем регламентное задание, которое раз в сутки (например, ночью) выгружает итоги за месяц в буферную таблицу.
2. Буферная таблица может находиться в основной базе или в отдельной «микро-базе».
3. Когда руководителю нужен отчет, система просто считывает уже подготовленные и «причесанные» данные из этой таблицы.

Главная проблема: Маппинг (Сопоставление) данных

Самое сложное в создании сводного отчета — это не технический канал связи, а идентификация сотрудников. В трех базах один и тот же человек может быть заведен трижды с разными внутренними идентификаторами (GUID).

Рассмотрим, как решить проблему идентификации:

• СНИЛС или ИНН: это лучшие ключи для сопоставления физических лиц. ФИО использовать опасно из-за возможных ошибок в написании или смены фамилий.
• Создание таблицы соответствий: в главной базе необходимо вести справочник, где указано, какой идентификатор из Базы А соответствует идентификатору в Базе Б.
• Единообразие начислений: в разных базах виды расчетов могут называться по-разному («Оклад» и «Оклад по дням»). Рекомендуется создать в отчете маппинг по группам начислений.

Подведение итогов

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