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

← На главную

При работе с крупными холдингами или государственными структурами часто возникает задача формирования единого аналитического отчета, который должен собирать данные из сотен разрозненных информационных баз (ИБ). В нашем случае рассматривается ситуация с 800 организациями, работающими в различных конфигурациях, таких как Зарплата и Управление Персоналом (ЗУП) и Бухгалтерия предприятия (БП). Основной вопрос заключается в том, как собрать фактические начисления, планы и командировочные расходы, не обрушив при этом серверы и не заставив пользователя ждать формирования отчета часами.

Проанализируем ситуацию: попытка «дергать» данные через API (HTTP или веб-сервисы) напрямую из 800 баз в момент нажатия кнопки «Сформировать» — это путь к техническому коллапсу. Время ожидания ответа от каждой базы, сетевые задержки и ограничения веб-серверов сделают такой процесс невозможным. Рассмотрим более надежные и производительные варианты решения этой задачи.

Вариант 1. Использование промежуточной информационной базы (Хранилище данных)

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

Создание легкой конфигурации: Разработаем собственную конфигурацию на базе Библиотеки стандартных подсистем (БСП). В ней не должно быть лишнего функционала — только необходимые регистры сведений или накопления для хранения плоских таблиц данных.
Организация обмена (Push-модель): Настроим регламентные задания в каждой из 800 периферийных баз. По расписанию (например, ночью или раз в час) каждая база будет сама отправлять измененные данные в центральное хранилище. Это снимает нагрузку с центральной базы по опросу узлов.
Использование планов обмена: Для оптимизации передачи данных крайне важно использовать ПланыОбмена. Это позволит передавать не всю базу целиком, а только измененные или новые записи.

Рассмотрим пример упрощенного кода для передачи данных из периферийной базы в центральную через HTTP-сервис:


Процедура ОтправитьДанныеВЦентр()
    ДанныеДляОтправки = СформироватьПакетДанных(); // Собираем ТЗ или Структуру
    ЗаписьJSON = Новый ЗаписьJSON;
    ЗаписьJSON.УстановитьСтроку();
    ЗаписатьJSON(ЗаписьJSON, ДанныеДляОтправки);
    СтрокаJSON = ЗаписьJSON.Закрыть();

    НТТПСоединение = Новый HTTPСоединение("server.central.db", , "user", "pass");
    Запрос = Новый HTTPЗапрос("/v1/data/receiver");
    Запрос.УстановитьТелоИзСтроки(СтрокаJSON);
    
    Попытка
        Ответ = НТТПСоединение.ОтправитьДляОбработки(Запрос);
    Исключение
        ЗаписатьЛогОшибки(ОписаниеОшибки());
    КонецПопытки;
КонецПроцедуры

Вариант 2. Публикация данных через OData и REST JSON

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

Однако, как мы выяснили, последовательный опрос 800 баз займет слишком много времени. Для решения этой проблемы проанализируем возможность параллельной обработки. Разберем алгоритм:

Центральная база хранит список URL-адресов всех 800 баз.
При запуске процесса сбора данных система инициирует ФоновыеЗадания.
Каждое фоновое задание берет на себя «пачку» из 20-30 баз и опрашивает их параллельно.
Результаты собираются во временную таблицу или промежуточный регистр центральной базы.

Важный нюанс: Использование REST JSON считается более производительным по сравнению со стандартным OData, так как позволяет передавать только необходимые поля и использовать более компактный формат данных.

Вариант 3. Использование 1С:Шина для гарантированной доставки

В системах с 800 узлами неизбежны ситуации, когда часть баз будет недоступна (проблемы со связью, технические работы). Чтобы данные не терялись, рассмотрим внедрение 1С:Шина. Это современное решение для асинхронного обмена данными.

Принцип работы в этой ситуации будет следующим:

Базы-источники «публикуют» сообщения с данными о начислениях в шину.
Шина хранит эти сообщения в очередях.
База-приемник (отчетная база) «подписывается» на эти сообщения и постепенно их обрабатывает.

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

Вариант 4. 1С:Аналитика и внешние СУБД (ClickHouse)

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

Проблема нормализации данных (MDM)

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

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

Безопасность и персональные данные (152-ФЗ)

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

Анонимизация: Если для сводного отчета контролирующему органу не нужны конкретные ФИО, а важны только суммы по категориям персонала, передавайте данные в обезличенном виде. Вместо ФИО используйте уникальный хеш-код. Это позволит избежать создания «супер-базы» с персональными данными тысяч сотрудников, что накладывает очень жесткие требования к защите серверной инфраструктуры по требованиям ФСТЭК.

Резюме и рекомендации

Подводя итог нашему анализу, рекомендуем следующую стратегию:

Отказаться от формирования отчета «на лету» путем прямого обращения к 800 базам.
Создать промежуточную базу на 1С (хранилище), куда данные будут попадать регламентно по модели Push.
Использовать HTTP-сервисы для приема данных в центральной базе.
Применить механизм Планов обмена для минимизации трафика.
Если требуется высокая скорость визуализации для руководства — подключить 1С:Аналитику.

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