Как объединить хранилища конфигураций 1С и не потерять данные при несовпадении GUID метаданных?

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

Почему происходит потеря данных при подключении к хранилищу

Проанализируем механизм работы платформы 1С с метаданными. Физические таблицы в базе данных СУБД жестко привязаны не к строковым именам объектов конфигурации, а к их внутренним уникальным идентификаторам (GUID). Когда база подключается к хранилищу, конфигурация хранилища целиком заменяет конфигурацию информационной базы.

Если в базе и в хранилище есть документ с именем РеализацияТоваровУслуг, но с разными GUID метаданных, платформа фиксирует два действия: удаление старого объекта метаданных и создание совершенно нового. При обновлении конфигурации базы данных таблица старого документа физически удаляется из СУБД вместе со всеми табличными частями и записями, а для нового объекта создается пустая структура.

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

Способ 1. Двухэтапная миграция данных внутри информационной базы

Рассмотрим наиболее надежный и проверенный практикой подход. Он основан на стандартном механизме обновлений типовых конфигураций 1С: временном сохранении старых таблиц с префиксом Удалить и последующем программном переносе данных в новые структуры.

1. Переименование конфликтующих объектов. В информационной базе, которую требуется подключить к хранилищу, откройте конфигуратор и переименуйте все конфликтующие объекты метаданных, добавив префикс (например, Удалить_РеализацияТоваровУслуг).
2. Фиксация изменений структуры в БД. Выполните команду Обновить конфигурацию базы данных (F7). Так как объект был просто переименован внутри базы, платформа лишь изменит метаописание физической таблицы в СУБД, сохранив все данные и ссылки без потерь.
3. Подключение базы к хранилищу. Подключите базу данных к целевому хранилищу конфигурации (или выполните загрузку конфигурации из файла, выгруженного из хранилища). При обновлении конфигурации базы данных платформа создаст новые пустые объекты с правильными GUID из хранилища, при этом объекты с префиксом Удалить_ останутся нетронутыми.
4. Программный перенос данных и движений. Напишите и выполните внешнюю обработку, которая перенесет элементы, документы и движения регистров из старых объектов в новые.
5. Удаление временных объектов. После полной проверки корректности перенесенных данных и сверки отчетов удалите объекты с префиксом Удалить_ из конфигурации и зафиксируйте изменения в хранилище.

Посмотрим на пример программного кода для переноса документов с сохранением их уникальных идентификаторов ссылок и оригинальных движений по регистрам:

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

Обратите внимание на использование свойства ОбменДанными.Загрузка = Истина. Этот режим отключает запуск платформенных событий проведения и модулей объектов, что гарантирует точное сохранение исторических проводок и остатков за все предыдущие периоды без искажений.

Способ 2. Выгрузка и загрузка данных через внешние файлы обмена

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

1. Перед выполнением любых действий с хранилищем создайте полную резервную копию базы данных.
2. С помощью обработки УниверсальныйОбменДаннымиXML или специализированных правил конвертации данных выгрузите конфликтующие объекты, связанные с ними подчиненные справочники и записи регистров во внешний XML-файл.
3. Подключите базу данных к хранилищу конфигурации и обновите конфигурацию базы данных. При этом старые таблицы с несовпадающими GUID будут очищены и пересозданы платформой.
4. Загрузите ранее выгруженные данные обратно в базу в режиме обмена данными. При сопоставлении по GUID ссылок документы и справочники займут свои места, а движения регистров будут привязаны к новым регистраторам.

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