Почему не заполняется реквизит ссылочного типа в табличной части при обмене через КД 2.1?

← На главную

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

Шаг 1: Проверка типизации коллекции объектов

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

Для корректной типизации воспользуемся следующим кодом:


КоллекцияОбъектов.Колонки.Добавить("Номенклатура", 
    Новый ОписаниеТипов("СправочникСсылка.Номенклатура"));

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

Шаг 2: Анализ правил конвертации свойств (ПКС)

Проверьте настройки вашего ПКО (Правила Конвертации Объектов) и ПКС (Правила Конвертации Свойств). Убедитесь, что для реквизита установлены следующие параметры:

Указано соответствующее правило конвертации для справочника Номенклатура.
Включен флаг Заполнять из данных файла, если данные должны браться напрямую из XML.
Проверьте признак Не замещать значение свойства у существующих объектов в приемнике. Если он включен, то при наличии элемента в базе он не будет перезаписан, даже если в выгрузке пришло новое значение.

Шаг 3: Диагностика через параметры объекта

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

Логика действий:

В ПКС передайте номенклатуру как дополнительный параметр.
В обработчике После загрузки пробегите циклом по строкам табличной части и присвойте значение номенклатуры из сохраненного параметра.

Шаг 4: Поиск скрытых причин в конфигурации приемника

Это самый важный этап, который часто игнорируют. Если в базе-приемнике установлены подписки на события (например, ПередЗаписью или ПриЗаписи), они могут срабатывать автоматически при загрузке документа. Часто такие подписки содержат логику проверки данных, которая при определенных условиях очищает реквизиты, если считает их заполненными некорректно или не соответствующими правилам учета.

Как проанализировать влияние подписок:

Попробуйте временно отключить запись объекта в настройках выгрузки.
Используйте отладчик: установите точку останова в модуле объекта документа или в подписках на события.
Проверьте, не происходит ли очистка поля именно в момент выполнения метода Записать().

Шаг 5: Проверка механизмов поиска

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

Для принудительной проверки воспользуйтесь кодом:


ИскомаяСсылка = Справочники.Номенклатура.ПолучитьСсылку(Новый УникальныйИдентификатор(СтрокаGUID));
Если ИскомаяСсылка.Пустая() Тогда
    // Объект не найден по этому GUID
КонецЕсли;

В завершение, всегда помните: если данные в файле XML присутствуют, но пропадают после загрузки, проблема почти наверняка кроется не в Конвертации данных, а в бизнес-логике конфигурации-приемника, которая принудительно «корректирует» данные при записи. Анализ подписок на события — ключ к успеху в 90% таких случаев.