← На главную

При переводе конфигураций на новые редакции (например, при переходе с «1С:Бухгалтерия предприятия 2.0» на ред. 3.0) нередко возникает задача объединить две исторически раздельные информационные базы в распределенную информационную базу (РИБ). Типичный пример — наличие управленческой и регламентированной баз, между которыми ранее работал периодический перенос документов. Попробуем разобраться, возможно ли связать такие базы в РИБ без создания нового начального узла с нуля, с какими подводными камнями придется столкнуться и какие альтернативные решения стоит рассмотреть.

Ограничения и подводные камни механизма РИБ при связывании существующих баз

Прежде чем приступать к объединению существующих баз, важно понимать фундаментальные принципы работы механизма РИБ платформы «1С:Предприятие»:

1. Идентификация только по УИД (UUID): В РИБ синхронизация всех ссылочных объектов (справочников, документов, перечислений) выполняется исключительно по их уникальному внутреннему идентификатору (УникальныйИдентификатор). Платформа не выполняет сопоставление по коду, наименованию, ИНН или номеру документа. Если в двух базах одни и те же контрагенты или номенклатура создавались независимо или переносились сторонней обработкой без сохранения исходных УИД, при первом же обмене в обеих базах неизбежно возникнут полные дубли записей.
2. Абсолютная идентичность метаданных: Для успешной работы механизма РИБ структуры конфигураций узлов должны полностью совпадать. Если в одной из баз добавлены реквизиты, которых нет в другой, обмен будет блокироваться с ошибкой несоответствия конфигураций.
3. Блокировка изменения конфигурации в подчиненном узле: После установления признака подчиненности в подчиненной базе блокируется возможность редактирования метаданных. Все обновления структуры данных выполняются исключительно в главном узле и передаются в подчиненные через файлы обмена.
4. Риск нарушения ссылочной целостности при фильтрации: Если в обмене настраивается фильтрация (например, выгрузка только части документов или выборочных организаций), перенос документов, ссылающихся на отфильтрованные элементы справочников, приведет к появлению «битых ссылок» (Объект не найден) в базе-приемнике.
5. Синхронизация движений регистров: По умолчанию при выгрузке проведенного документа РИБ отправляет и наборы записей его движений. Если правила проведения и проводки в управленческой и регламентированной базах отличаются, стандартный обмен затрет локальные движения подчиненного узла.

Пошаговый технический порядок связывания двух баз в РИБ

Если решение объединить базы через РИБ принято осознанно, а риски появления дубликатов устранены предварительной синхронизацией идентификаторов, разберем порядок действий по созданию связки «Главный узел — Подчиненный узел»:

1. Выравнивание конфигураций: Убедимся, что обе базы обновлены до строго одинакового релиза конфигурации. Сохраняем файл конфигурации (.cf) из будущей центральной базы и загружаем его в будущую подчиненную базу.
2. Предварительная нормализация данных: До включения обмена выполняем поиск и объединение дублей, а также синхронизацию УИД для ключевых справочников (организации, контрагенты, договоры, номенклатура, статьи затрат).
3. Настройка узлов в базах:

   В Центральной базе (ЦБ): создаем предопределенный узел «ЭтотУзел» с кодом, например, «ЦБ», и создаем второй узел для подчиненной базы с кодом «ПБ».

   В Подчиненной базе (ПБ): создаем предопределенный узел «ЭтотУзел» с кодом «ПБ» и узел главного узла с кодом «ЦБ».

4. Программное назначение главного узла в подчиненной базе:

   Для того чтобы подчиненная база перешла в режим РИБ и признала центральную базу главной, выполним следующий код во внешней обработке в подчиненной базе:

   Скопировать код

   
   УзелЦБ = ПланыОбмена.Полный.НайтиПоКоду("ЦБ");
   Если ЗначениеЗаполнено(УзелЦБ) Тогда
       ПланыОбмена.УстановитьГлавныйУзел(УзелЦБ);
       Сообщить("Главный узел успешно установлен.");
   Иначе
       ВызватьИсключение "Узел ЦБ не найден в плане обмена!";
   КонецЕсли;
   

5. Сброс номеров сообщений:

   Чтобы исключить ошибку «Номер сообщения меньше или равен ранее принятому», программно выравниваем номера отправленных и принятых сообщений в обоих узлах перед первым запуском:

   Скопировать код

   
   УзелОбменаОбъект = УзелОбмена.ПолучитьОбъект();
   УзелОбменаОбъект.НомерОтправленного = 0;
   УзелОбменаОбъект.НомерПринятого = 0;
   УзелОбменаОбъект.Записать();
   

6. Очистка регистрации изменений:

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

   ПланыОбмена.УдалитьРегистрациюИзменений(УзелОбмена);

Альтернативные и более надежные варианты реализации

Учитывая жесткие ограничения РИБ, в большинстве случаев для баз с разным составом учета (управленческий и бухгалтерский) предпочтительнее использовать другие механизмы:

1. Обмен через универсальный формат (EnterpriseData):

   Использование типового механизма синхронизации через универсальный формат позволяет производить сопоставление по бизнес-полям (ИНН, КПП, наименование, дата и номер документа). Базы остаются полностью автономными, сохраняется возможность раздельного обновления и исключается риск появления дублей при различии внутренних идентификаторов.

2. Использование собственного Плана Обмена (без признака РИБ):

   Создаем отдельный план обмена, у которого отключен признак «Распределенная информационная база». Это сохраняет механизм регистрации изменений через ПланыОбмена.ЗарегистрироватьИзменения, но снимает платформенный запрет на изменение метаданных в подчиненной базе и позволяет гибко управлять правилами выгрузки данных и движений регистров без жесткой привязки к структуре УИД.