Почему загруженные через Конвертацию данных 2.0 объекты не появляются в базе?

← На главную

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

Анализ настроек Правил Конвертации Объектов (ПКО)

Первым делом проанализируем настройки самих правил обмена в конфигурации «Конвертация данных». Часто причина кроется в установленных флажках на вкладке «Настройки» конкретного ПКО. Проверим следующие опции:

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

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

Особенности работы в клиент-серверном режиме

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

Для того чтобы гарантированно увидеть отладочную информацию, заменим Сообщить() на запись в журнал регистрации. Разберем пример кода для вставки в обработчик:


ТекстДляЖурнала = "Загрузка объекта: " + Строка(Объект);
ЗаписьЖурналаРегистрации("ЗагрузкаКД", УровеньЖурналаРегистрации.Информация, , , ТекстДляЖурнала);

После выполнения загрузки откройте Журнал регистрации в базе-приемнике и отфильтруйте события по событию «ЗагрузкаКД». Если записей нет — значит, выполнение кода до этого обработчика просто не доходит, либо происходит тихий отказ.

Отладка обработчиков событий и параметр ОбъектНайден

Для глубокого анализа процесса загрузки воспользуемся внешней обработкой отладки. Рассмотрим алгоритм действий:

В обработке «Универсальный обмен данными в формате XML» на вкладке «Дополнительно» включим режим отладки обработчиков.
Сформируем модуль отладки и сохраним его как внешнюю обработку.
Важный нюанс: если система выдает ошибку «Внешняя обработка отладки, загружаемая из файла на диске, не поддерживается», это означает, что сервер не может дотянуться до файла на вашем локальном диске. В этом случае необходимо либо запускать базу в файловом режиме, либо разместить файл обработки в каталоге, доступном пользователю USR1CV8 на сервере.

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

Конфликты GUID и поиск по идентификатору

Выясним причину, связанную с уникальными идентификаторами. КД 2.0 приоритетно ищет объекты по GUID.

Возможна ситуация, когда в базе-приемнике уже существует объект (возможно, другого типа или помеченный на удаление) с тем же GUID, который вы переносите для номенклатуры. Платформа может «найти» этот объект, но из-за несовпадения типов или условий ПКО запись не будет произведена. Проанализируем базу-приемник с помощью консоли запросов, выполнив поиск по уникальному идентификатору, который можно подсмотреть в XML-файле выгрузки (атрибут {http://v8.1c.ru/8.1/data/enterprise}Value).

Транзакции и «тихие» ошибки записи

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

При этом обработка может успеть вывести сообщение «Загружено 5 объектов», так как она считает объекты, успешно прочитанные из файла, а откат транзакции происходит уже в самом финале. Попробуйте отключить использование транзакций и повторить загрузку — в этом случае система должна выдать конкретную ошибку записи на проблемном объекте.

Проверка RLS и функциональных опций

Если программно объект создается, но его не видно в интерфейсе, проанализируем настройки доступа.

Во многих современных конфигурациях (УТ 11, БП 3.0) работают механизмы RLS (Record Level Security). Если вы загружаете номенклатуру, которая не попадает под разрешенные группы доступа текущего пользователя, вы ее не увидите ни в списке, ни в обычном запросе. Попробуйте найти объект под пользователем с полными правами или через запрос с конструкцией ВЫБРАТЬ РАЗРЕШЕННЫЕ.

Также проверьте Функциональные опции. Например, если вы загружаете номенклатуру с типом «Работа», а в константах базы-приемника использование работ отключено, этот объект может быть скрыт платформой из всех стандартных списков.