Задача объединения нескольких информационных баз в одну — это сложный проект, требующий не только технических навыков, но и глубокого понимания структуры данных 1С. Часто возникают ситуации, когда компании ведут учет в разных базах, а затем принимают решение о консолидации. Рассмотрим подробнее, почему стандартные механизмы вроде РИБ могут не подойти, и разберем по шагам наиболее надежный алгоритм слияния.
Первоначальная идея многих разработчиков заключается в том, чтобы «подружить» базы через механизм Распределенных Информационных Баз (РИБ). По задумке, если назначить одну базу главной, а остальные — подчиненными с тем же префиксом, данные должны «слиться». Проанализируем ситуацию: этот метод крайне рискован по нескольким причинам.
Как показала практика участников обсуждения, попытка использовать РИБ для слияния разнородных данных часто заканчивается техническим сбоем и появлением огромного количества дублей, которые потом приходится вычищать вручную месяцами.
Наиболее правильным и контролируемым методом является использование конфигурации «Конвертация данных 2.0» (или 3.0). Этот способ позволяет настроить четкие правила сопоставления объектов. Разберем по шагам правильную последовательность действий.
Контрагенты и Организации — это ИНН + КПП.Номенклатура — Артикул или Наименование.Валюты и Банки — Код (ОКВ) и БИК.ОбменДанными.Загрузка = Истина позволит избежать лишних проверок, но потребует внимательности при переносе движений документов.При написании правил в КД 2.0 важно уделить внимание предопределенным элементам. Часто в разных базах GUID предопределенных элементов (например, статьи затрат или группы финансового учета) могут различаться. Выясним причину: это происходит, если базы обновлялись в разное время или создавались из разных шаблонов.
В обработчике ПоляПоиска для таких объектов можно использовать следующий код для программного уточнения сопоставления:
Если ИмяТипаОбъекта = "СправочникСсылка.СтатьиДвиженияДенежныхСредств" Тогда
Если СвойстваПоиска.Найти("Наименование") <> Неопределено Тогда
СсылкаНаОбъект = Справочники.СтатьиДвиженияДенежныхСредств.НайтиПоНаименованию(СвойстваПоиска["Наименование"]);
КонецЕсли;
КонецЕсли;
Рассмотрим подробнее работу с движениями. Чтобы не возникло ситуации, когда документы перенеслись, а отчеты пустые, необходимо переносить не только сами документы, но и их движения по регистрам бухгалтерии и регистрам накопления. Однако помните, что в БП 3.0 многие итоги строятся по «Ключам аналитики». После завершения загрузки в целевой базе обязательно нужно выполнить процедуру обновления вспомогательных данных:
// Внешняя обработка или консоль кода
Справочники.КлючиАналитикиУчетаНоменклатуры.ОбновитьДанные();
// И другие аналогичные методы для БП 3.0
Если целью объединения является исключительно получение «красивых отчетов» (баланс, доходы и убытки) для руководства, то проанализируем ситуацию: стоит ли тратить сотни часов на слияние? Посмотрим на примеры альтернативных решений.
1. Использование механизма внешних источников данных.
Вы можете создать шестую базу, в которой настроены подключения к SQL-таблицам исходных пяти баз. Отчет будет собирать данные «на лету» с помощью запроса ОБЪЕДИНИТЬ ВСЕ.
2. Сбор данных через OData (REST API). В каждой базе включается стандартный интерфейс OData. В отчетной базе пишется алгоритм, который опрашивает 5 баз через HTTP-запросы и сводит данные в одну таблицу. Это позволяет избежать проблем с дублями в справочниках, так как данные сопоставляются только в памяти в момент формирования отчета.
3. Использование специализированных продуктов.
Если бизнес-процессы сложные, рассмотрим возможность перехода на 1С:Управление холдингом или использование модуля 1С:Консолидация. Эти системы специально спроектированы для импорта данных из разных учетных систем и исключения внутригрупповых оборотов (элиминации).
Б1-00001, Б2-00001).Подводя итог, объединение через РИБ — это путь мазохиста. Правильный путь — это методичная работа с Конвертацией данных или использование инструментов BI-аналитики для сборки отчетов без физического перемещения миллионов строк документов.