Как настроить обмен данными между УТ 10.3 и БП 3.0 при замене исходной базы и несовпадении GUID?

← На главную

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

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

Механизм поиска и синхронизации в типовом обмене

Прежде всего, проанализируем, как работает типовой механизм обмена, построенный на технологии Конвертация данных 2.0. Когда данные передаются из УТ 10.3 в БП 3.0, поиск объекта в приемнике проходит через несколько этапов:

Поиск по уникальному идентификатору (GUID): Система ищет в базе-приемнике объект с точно таким же UUID, как у объекта-источника. Поскольку в новой базе УТ объекты создавались заново, их GUID не совпадают с теми, что уже есть в БП. На этом этапе поиск всегда будет выдавать «промах».
Поиск по полям поиска (ПКС): Если по GUID объект не найден, система использует правила, прописанные в XML-файле обмена. Обычно для справочника Контрагенты это связка ИНН + КПП, для Номенклатуры — Артикул или Наименование.
Поиск в регистре соответствий: Система проверяет специальный регистр сведений, где хранятся уже установленные связи между объектами разных баз.

Рассмотрим подробнее три варианта решения задачи сопоставления объектов.

Вариант 1. Интерактивное сопоставление через Помощник

Это штатный путь, встроенный в современные конфигурации на базе БСП (включая БП 3.0). Рассмотрим этот процесс по шагам:

При настройке синхронизации данных в БП 3.0 со стороны бухгалтерии можно запустить Помощник интерактивной синхронизации. В момент первой загрузки данных система предложит проанализировать данные. Вы увидите таблицу сопоставления, где в левой колонке будут данные из новой УТ, а в правой — найденные «похожие» объекты в БП.

Основное преимущество этого метода заключается в том, что после того, как вы вручную свяжете объект «А» из УТ с объектом «Б» из БП, система запишет это соответствие в регистр сведений СоответствияОбъектовИнформационныхБаз. При последующих обменах поиск по полям и GUID уже не потребуется — система мгновенно найдет связь в регистре.

Однако, если объектов десятки тысяч, ручное сопоставление невозможно. Здесь нам помогут более продвинутые методы.

Вариант 2. Модификация правил в «Конвертации данных 2.0»

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

Рассмотрим алгоритм действий:

Выгружаем типовые правила обмена из макета узла обмена в УТ 10.3 или БП 3.0 в XML-файл.
Загружаем эти правила в конфигурацию Конвертация данных.
Находим нужное ПКО (Правило конвертации объекта), например, Контрагенты.
Переходим на закладку «Поля поиска». Здесь мы можем написать произвольный алгоритм на языке 1С.

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


// Пример в обработчике "Поля поиска"
Если НомерВариантаПоиска = 1 Тогда
    // Пытаемся найти объект в БП по коду, который хранится в реквизите СтарыйКод источника
    Запрос = Новый Запрос;
    Запрос.Текст = 
    "ВЫБРАТЬ Ссылка 
    |ИЗ Справочник.Контрагенты 
    |ГДЕ Код = &СтарыйКод";
    
    Запрос.УстановитьПараметр("СтарыйКод", СвойстваПоиска["СтарыйКод"]);
    Результат = Запрос.Выполнить();
    
    Если Не Результат.Пустой() Тогда
        Выборка = Результат.Выбрать();
        Выборка.Следующий();
        СсылкаНаОбъект = Выборка.Ссылка;
        ПрекратитьПоиск = Истина;
    КонецЕсли;
КонецЕсли;

После внесения таких изменений в правила для всех ключевых справочников (Номенклатура, Контрагенты, Договоры), мы загружаем обновленный XML-файл обратно в настройки обмена. Теперь система будет автоматически «склеивать» объекты по вашему алгоритму.

Вариант 3. Программное заполнение регистра соответствий

Если мы не хотим менять правила обмена, мы можем пойти путем прямого воздействия на базу данных. Разберем ситуацию: у нас есть две базы, и мы хотим заранее сообщить БП 3.0, какой объект из УТ какому объекту в БП соответствует.

Для этого используется регистр сведений СоответствияОбъектовИнформационныхБаз. Нам нужно написать обработку, которая через COM-соединение или текстовый файл сопоставит UUID объектов.

Посмотрим на структуру этого регистра. Основные измерения:

УзелИнформационнойБазы — ссылка на узел обмена с вашей УТ.
СобственныйОбъект — ссылка на объект в текущей базе (БП).
УникальныйИдентификаторИсточника — GUID объекта из внешней базы (УТ) в виде строки.
ТипИсточника и ТипПриемника — строковые имена типов объектов.

Рассмотрим пример кода для программной записи соответствия:


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

Выполнив такую обработку один раз перед запуском обмена, мы «обучим» систему. Когда БП 3.0 получит данные из УТ, она первым делом заглянет в этот регистр, увидит готовую связь и просто обновит существующий объект вместо создания дубля.

Тонкости работы с договорами и сериями

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

Важный совет: При использовании КД 2.0 для договоров обязательно включайте поиск по Владельцу. Если вы переносите данные через COM, старайтесь сохранять иерархию связей. Если в новой УТ договор получил новый код, единственным надежным способом сопоставления остается поиск по связке Владелец + Наименование + Организация или использование того самого «старого кода», проброшенного в правилах обмена.

Резюме

Мы рассмотрели три основных подхода к решению проблемы. Для разового исправления небольшого объема данных идеально подойдет интерактивное сопоставление в БП 3.0. Если же база большая и есть четкий критерий связи (например, «старый код»), лучше всего один раз доработать правила в Конвертации данных 2.0. Программное заполнение регистра соответствий — это «тяжелая артиллерия» для тех случаев, когда нужно связать базы максимально быстро без изменения типовых механизмов обмена.

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