Как устранить битые ссылки предопределенных данных при загрузке XML в 1С

Программист 1С v8.3 (Управляемые формы) IT и автоматизация бизнеса
← На главную

При обмене данными между двумя базами 1С (например, через универсальный обмен XML или Конвертацию данных) часто возникает ситуация, когда в базе-приемнике вместо ожидаемых значений справочников отображается «Объект не найден» (битая ссылка). Особенно остро эта проблема стоит для предопределенных элементов: несмотря на то что они называются одинаково в конфигураторе обеих баз, их внутренние уникальные идентификаторы (GUID) могут различаться. В данной статье мы подробно разберем причины этой проблемы и изучим несколько эффективных способов ее решения.

Почему возникают битые ссылки на предопределенные данные

Разберем ситуацию: в базе-источнике есть предопределенный элемент справочника СтатьиДвиженияДенежныхСредств с именем «ОплатаПоставщику». При выгрузке в XML система записывает его GUID (Уникальный Идентификатор). Если в базе-приемнике этот же предопределенный элемент был создан вручную или иным способом с другим GUID, то стандартный механизм загрузки не сможет найти соответствие по идентификатору. В результате в регистре или документе появится ссылка на несуществующий в текущей базе GUID.

Решение 1: Использование «Конвертации данных» (КД 2.1)

Если обмен планируется выполнять на постоянной основе, наиболее правильным методом будет использование конфигурации «Конвертация данных». Рассмотрим, как настроить сопоставление предопределенных элементов по их именам, а не по GUID.

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

Решение 2: Настройка платформенного обновления предопределенных данных

Начиная с версии платформы 8.3, механизм работы с предопределенными данными был существенно переработан. Мы можем программно управлять тем, как система сопоставляет данные метаданных с записями в таблицах базы данных.

Если мы столкнулись с тем, что ссылки «битые», попробуем заставить платформу выполнить переинициализацию связей. Для этого можно использовать метод УстановитьОбновлениеПредопределенныхДанных. Выполним следующий код в базе-приемнике:


// Устанавливаем режим автоматического обновления для справочника
Справочники.ВашСправочник.УстановитьОбновлениеПредопределенныхДанных(ОбновлениеПредопределенныхДанных.Авто);

// Принудительно запускаем процесс заполнения
Справочники.ВашСправочник.ЗаполнитьПредопределенныеДанные();

Этот метод заставляет систему заново сопоставить внутренние идентификаторы с именами, указанными в конфигураторе. Это часто помогает, если объекты в базе фактически есть, но ссылки на них не отрабатывают корректно.

Решение 3: Использование свойства «ИмяПредопределенныхДанных»

В современных конфигурациях у объектов появилось строковое поле ИмяПредопределенныхДанных. Если при загрузке через XML в узле справочника указано корректное имя, платформа может автоматически связать его с существующим. Рассмотрим ситуацию, когда у нас уже появились дубли (один элемент «настоящий» предопределенный, а второй — загруженный как обычный, но с тем же именем).

Проанализируем шаги по исправлению:

  1. Определим «неправильный» элемент, который мешает системе.
  2. У этого элемента необходимо очистить поле ИмяПредопределенныхДанных, чтобы он перестал считаться предопределенным с точки зрения системы.
  3. После этого «правильный» элемент из метаданных сможет занять свое место.

Решение 4: Синхронизация GUID (выравнивание идентификаторов)

Если нам необходимо, чтобы обмен шел строго по GUID (например, в самописных механизмах обмена), мы можем «подтянуть» GUID в приемнике под источник. Это радикальный, но эффективный метод. Важно помнить: напрямую изменить GUID у существующей записи нельзя.

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

  1. Получаем нужный GUID из базы-источника (через XML или программно).
  2. В базе-приемнике удаляем текущий элемент (предварительно сохранив данные).
  3. Создаем новый элемент с нужным GUID, используя метод УстановитьСсылкуНового().

НоваяСсылка = Справочники.Номенклатура.ПолучитьСсылку(Новый УникальныйИдентификатор("нужный-гуид-из-источника"));
НовыйОбъект = Справочники.Номенклатура.СоздатьЭлемент();
НовыйОбъект.УстановитьСсылкуНового(НоваяСсылка);
НовыйОбъект.Наименование = "Наименование из источника";
НовыйОбъект.ИмяПредопределенныхДанных = "ИмяИзМетаданных";
НовыйОбъект.Записать();

Важно: После этой операции все старые документы в базе-приемнике, ссылавшиеся на старый GUID, «обернутся» битыми ссылками. Поэтому обязательно используйте типовую обработку «Поиск и замена значений», чтобы перебросить ссылки со старого (удаляемого) элемента на новый.

Решение 5: Механизмы БСП (Синхронизация данных)

Если ваши конфигурации построены на базе БСП (Библиотека стандартных подсистем), мы можем воспользоваться регистром сведений СоответствияОбъектовИнформационныхБаз. Это позволяет не менять GUID самих объектов, а просто «объяснить» системе обмена, что объект А в базе 1 соответствует объекту Б в базе 2.

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

Рекомендации для предотвращения проблемы

Чтобы избежать подобных сложностей в будущем, придерживайтесь следующих правил при разработке и сопровождении обменов:

← На главную