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