При обмене данными между двумя базами 1С (например, через универсальный обмен XML или Конвертацию данных) часто возникает ситуация, когда в базе-приемнике вместо ожидаемых значений справочников отображается «Объект не найден» (битая ссылка). Особенно остро эта проблема стоит для предопределенных элементов: несмотря на то что они называются одинаково в конфигураторе обеих баз, их внутренние уникальные идентификаторы (GUID) могут различаться. В данной статье мы подробно разберем причины этой проблемы и изучим несколько эффективных способов ее решения.
Разберем ситуацию: в базе-источнике есть предопределенный элемент справочника СтатьиДвиженияДенежныхСредств с именем «ОплатаПоставщику». При выгрузке в XML система записывает его GUID (Уникальный Идентификатор). Если в базе-приемнике этот же предопределенный элемент был создан вручную или иным способом с другим GUID, то стандартный механизм загрузки не сможет найти соответствие по идентификатору. В результате в регистре или документе появится ссылка на несуществующий в текущей базе GUID.
Если обмен планируется выполнять на постоянной основе, наиболее правильным методом будет использование конфигурации «Конвертация данных». Рассмотрим, как настроить сопоставление предопределенных элементов по их именам, а не по GUID.
Начиная с версии платформы 8.3, механизм работы с предопределенными данными был существенно переработан. Мы можем программно управлять тем, как система сопоставляет данные метаданных с записями в таблицах базы данных.
Если мы столкнулись с тем, что ссылки «битые», попробуем заставить платформу выполнить переинициализацию связей. Для этого можно использовать метод УстановитьОбновлениеПредопределенныхДанных. Выполним следующий код в базе-приемнике:
// Устанавливаем режим автоматического обновления для справочника
Справочники.ВашСправочник.УстановитьОбновлениеПредопределенныхДанных(ОбновлениеПредопределенныхДанных.Авто);
// Принудительно запускаем процесс заполнения
Справочники.ВашСправочник.ЗаполнитьПредопределенныеДанные();
Этот метод заставляет систему заново сопоставить внутренние идентификаторы с именами, указанными в конфигураторе. Это часто помогает, если объекты в базе фактически есть, но ссылки на них не отрабатывают корректно.
В современных конфигурациях у объектов появилось строковое поле ИмяПредопределенныхДанных. Если при загрузке через XML в узле справочника указано корректное имя, платформа может автоматически связать его с существующим. Рассмотрим ситуацию, когда у нас уже появились дубли (один элемент «настоящий» предопределенный, а второй — загруженный как обычный, но с тем же именем).
Проанализируем шаги по исправлению:
ИмяПредопределенныхДанных, чтобы он перестал считаться предопределенным с точки зрения системы.Если нам необходимо, чтобы обмен шел строго по GUID (например, в самописных механизмах обмена), мы можем «подтянуть» GUID в приемнике под источник. Это радикальный, но эффективный метод. Важно помнить: напрямую изменить GUID у существующей записи нельзя.
Разберем алгоритм действий:
УстановитьСсылкуНового().
НоваяСсылка = Справочники.Номенклатура.ПолучитьСсылку(Новый УникальныйИдентификатор("нужный-гуид-из-источника"));
НовыйОбъект = Справочники.Номенклатура.СоздатьЭлемент();
НовыйОбъект.УстановитьСсылкуНового(НоваяСсылка);
НовыйОбъект.Наименование = "Наименование из источника";
НовыйОбъект.ИмяПредопределенныхДанных = "ИмяИзМетаданных";
НовыйОбъект.Записать();
Важно: После этой операции все старые документы в базе-приемнике, ссылавшиеся на старый GUID, «обернутся» битыми ссылками. Поэтому обязательно используйте типовую обработку «Поиск и замена значений», чтобы перебросить ссылки со старого (удаляемого) элемента на новый.
Если ваши конфигурации построены на базе БСП (Библиотека стандартных подсистем), мы можем воспользоваться регистром сведений СоответствияОбъектовИнформационныхБаз. Это позволяет не менять GUID самих объектов, а просто «объяснить» системе обмена, что объект А в базе 1 соответствует объекту Б в базе 2.
Выясним, как это работает: при обмене система сначала заглядывает в этот регистр. Если там найдена запись соответствия для конкретного узла обмена, то загрузка произойдет успешно, даже если GUID различаются. Это наиболее безопасный метод для баз, находящихся в промышленной эксплуатации, так как он не требует удаления данных или изменения метаданных.
Чтобы избежать подобных сложностей в будущем, придерживайтесь следующих правил при разработке и сопровождении обменов:
message.xml перед его загрузкой в приемник.