Почему после загрузки через Конвертацию данных появляется «Объект не найден» и как это исправить?

← На главную

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

Причина проблемы: несовпадение УИД и логика поиска

Надпись <Объект не найден> появляется в платформе 1С только в одном случае: в ссылочный реквизит записана ссылка с конкретным уникальным идентификатором (UUID/GUID), но запись с таким идентификатором в таблице базы данных фактически отсутствует. Если бы объект не сопоставился по другим полям при выключенном поиске по УИД, поле осталось бы просто пустым.

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

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

Решение 1. Настройка полей поиска и флагов в ПКО

Рассмотрим правила конвертации объекта (ПКО) для проблемного справочника в конфигурации «Конвертация данных 2.x». Чтобы система корректно находила существующий в приемнике объект даже при несовпадающих идентификаторах, выполним следующие настройки:

Откроем нужное ПКО (например, для справочника Номенклатура).
На вкладке «Настройки поиска» убедимся, что включен флаг «Продолжить поиск по полям поиска, если по идентификатору объект приемник не найден».
В табличной части правил конвертации свойств (ПКС) отметим флажками колонку «Поиск» у ключевых реквизитов (например, Артикул, Код или Наименование + ЭтоГруппа).
Проверим настройки создания: снимем флаги «Не создавать новый объект в приемнике, если он НЕ найден» и «При переносе объекта по ссылке НЕ создавать новый объект, а только переносить ссылку», если требуется автоматическое создание недостающих позиций.

Решение 2. Проверка правил конвертации табличных частей

Выясним причину, почему в движениях ссылка может быть заполнена, а в строках документа — нет. Это происходит при раздельной выгрузке табличной части и наборов записей регистров. Для движений может быть назначено одно правило с поиском по реквизитам, а для табличной части — другое, либо ПКО вовсе не указано.

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

Решение 3. Обработка ненайденных ссылок в коде правил

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


Если Не ОбъектНайден Тогда
    // Заменяем битую ссылку на пустую, чтобы исключить появление битых записей
    Объект = Справочники.Номенклатура.ПустаяСсылка();
КонецЕсли;

Если же выгрузка выполняется через планы обмена, и подчиненный справочник просто не попал в состав изменений узла, перед формированием выгрузки можно принудительно зарегистрировать изменения справочника:


ПланыОбмена.ЗарегистрироватьИзменения(УзелОбмена, Метаданные.Справочники.Номенклатура);

Решение 4. Программное создание объекта с требуемым GUID

Если в базе-приемнике требуется восстановить связь именно с тем идентификатором, который пришел из источника, создадим элемент программно с явным назначением идентификатора с помощью метода УстановитьСсылкуНового():


Идентификатор = Новый УникальныйИдентификатор("00000000-0000-0000-0000-000000000000");
СсылкаНаОбъект = Справочники.Номенклатура.ПолучитьСсылку(Идентификатор);

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

После записи элемента ссылка в документе моментально станет валидной, так как в таблице базы данных появится соответствующая запись с данным УникальныйИдентификатор.