Как собрать сводную информацию и построить отчеты из нескольких баз 1С

← На главную

Когда учет нескольких юридических лиц ведется в раздельных информационных базах одной конфигурации (например, в типовых базах УПП или УТ), руководство неизбежно сталкивается с необходимостью оперативно видеть сводную картину. Типичные примеры: получение общего остатка материалов по складам группы компаний, анализ консолидированной дебиторской задолженности или сопоставление взаиморасчетов. Разберем доступные варианты решения этой задачи, их архитектурные плюсы, скрытые технические подводные камни и вопросы синхронизации нормативно-справочной информации.

Вариант 1. Слияние в единую базу данных или распределенная информационная база (РИБ)

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

Проанализируем преимущества и сложности этого подхода:

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

Вариант 2. Консолидация данных через COM-соединение и веб-сервисы

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

Выясним технические особенности реализации через V83.COMConnector:

Расход клиентских лицензий: каждый метод подключения Connect() запускает полноценную внешнюю сессию в целевой информационной базе. Пока объект соединения удерживается в памяти, эта сессия занимает лицензию из пула. Если отчет формируют несколько пользователей одновременно, пул лицензий может быстро исчерпаться.
Платформенные ограничения: COM-технология работает исключительно в операционной системе Windows. Если кластер серверов «1С:Предприятия» развернут на базе Linux, запустить прямое COM-соединение невозможно. Кроме того, на 64-разрядных серверах нередко возникают проблемы со стабильностью 32-разрядных COM-компонентов.

Рассмотрим альтернативу в виде публикации SOAP Web-сервисов или HTTP-сервисов в каждой подчиненной базе. В целевых базах создается сервис, принимающий параметры отчета (период, склад, организация) и возвращающий готовый сжатый пакет данных (например, XML или JSON).

Преимущества веб-сервисов:

Экономия лицензий: веб-сервер поддерживает постоянный пул соединений, переиспользуя существующие сеансы платформы, благодаря чему не происходит лавинообразного захвата пользовательских лицензий при частых запросах.
Кроссплатформенность: веб-сервисы стабильно функционируют независимо от операционной системы серверов (Windows/Linux) и разрядности платформы.
Совместимость: для конфигураций с устаревшим режимом совместимости платформы (например, УПП 1.3 с режимом 8.2) классические SOAP-сервисы являются полностью штатным механизмом, не требующим снятия конфигурации с поддержки.

Вариант 3. Использование внешних наборов данных в Системе компоновки данных (СКД)

Для объединения разнородных данных в красивый пользовательский отчет оптимально использовать Систему компоновки данных с внешними наборами данных. Модуль отчета опрашивает внешние источники, объединяет строки в общую структуру и передает управление процессору компоновки.

Посмотрим на пример структуры модуля отчета, агрегирующего остатки из двух баз:


Процедура ПриКомпоновкеРезультата(ДокументРезультат, ДанныеРасшифровки, СтандартнаяОбработка)
    
    СтандартнаяОбработка = Ложь;
    
    // Получаем остатки из локальной базы
    ТаблицаЛокальная = ПолучитьОстаткиТекущейБазы();
    
    // Получаем остатки из удаленной базы через сервис
    ТаблицаВнешняя = ПолучитьОстаткиУдаленнойБазы();
    
    // Объединяем полученные данные в одну универсальную таблицу
    ТаблицаДанных = ТаблицаЛокальная.Скопировать();
    Для Каждого Стр Из ТаблицаВнешняя Цикл
        ЗаполнитьЗначенияСвойств(ТаблицаДанных.Добавить(), Стр);
    КонецЦикла;
    
    ВнешниеНаборы = Новый Структура("НаборДанныхОстатки", ТаблицаДанных);
    
    СхемаКомпоновки = ПолучитьМакет("ОсновнаяСхемаКомпоновкиДанных");
    Настройки = КомпоновщикНастроек.ПолучитьНастройки();
    
    КомпоновщикМакета = Новый КомпоновщикМакетаКомпоновкиДанных;
    МакетКомпоновки = КомпоновщикМакета.Выполнить(СхемаКомпоновки, Настройки, ДанныеРасшифровки);
    
    ПроцессорКомпоновки = Новый ПроцессорКомпоновкиДанных;
    ПроцессорКомпоновки.Инициализировать(МакетКомпоновки, ВнешниеНаборы, ДанныеРасшифровки);
    
    ПроцессорВывода = Новый ПроцессорВыводаРезультатаКомпоновкиДанныхВТабличныйДокумент;
    ПроцессорВывода.УстановитьДокумент(ДокументРезультат);
    ПроцессорВывода.Вывести(ПроцессорКомпоновки);

КонецПроцедуры

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

Проблема синхронизации нормативно-справочной информации (НСИ)

Главная практическая сложность сводных отчетов заключается не в технологии передачи байтов по сети, а в сопоставлении аналитики. Если один и тот же материал в одной базе заведен как «Кабель ВВГнг 3х1.5», а во второй — как «Кабель силовой 3х1,5 ВВГ-НГ», автоматический сводный отчет разделит остатки на две независимые строки.

Разберем способы решения проблемы НСИ:

Административная синхронизация и системы MDM: назначение одной базы эталонным источником («мастером») для справочников «Номенклатура», «Контрагенты», «Статьи затрат». В подчиненных базах блокируется ручное добавление элементов операторами, а синхронизация ведется строго по уникальным идентификаторам (GUID).
Таблицы соответствия кодов (мэппинг): если объединить справочники невозможно, в точке сбора данных создается служебный регистр сведений, где сопоставляются артикулы, штрихкоды или коды ТН ВЭД позиций из разных баз.
Специализированные конфигурации холдинга: внедрение типовых решений верхнего уровня, таких как «1С:Управление холдингом» или «1С:Консолидация». В них заложены механизмы сбора форм с удаленных баз, мэппинга произвольных планов счетов и аналитик, а также функции элиминации внутригрупповых оборотов.

Создание промежуточного хранилища данных (DWH)

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

Проанализируем схему с витриной данных:

В каждой рабочей базе настраивается РегламентноеЗадание, которое с заданной периодичностью (например, раз в час или ночью) выгружает дельту движений и остатков в единую промежуточную базу данных.
Сводный отчет пользователя строится мгновенно по предрассчитанным таблицам хранилища без обращения к «живым» производственным базам и без создания паразитной нагрузки на рабочие транзакции.