Как в Конвертации данных 3.0 определить, в какой справочник переносятся данные

← На главную

Работа в Конвертации данных 3.0 (КД 3) существенно отличается от привычной многим версии 2.1. Если в КД 2.1 мы настраивали правила напрямую «Источник — Приемник», то в КД 3 используется концепция универсального формата EnterpriseData (ED). Это означает, что конфигурация-отправитель ничего не знает о структуре конфигурации-получателя. Она лишь выгружает данные в «шину» (формат XDTO), а приемник забирает их оттуда и интерпретирует по своим правилам.

Разберем подробно, как в этой цепочке найти конечную точку — справочник или документ, в который попадают данные при загрузке в целевую базу.

Понимание архитектуры обмена через EnterpriseData

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

Выгрузка (Отправка): Объект конфигурации-источника (например, Справочник.СпецификацииНоменклатуры в БП 3.0) конвертируется в объект формата XDTO (например, Справочник.СпецификацииНоменклатуры в пакете EnterpriseData).
Загрузка (Получение): Объект формата XDTO считывается из файла и конвертируется в объект конфигурации-приемника (например, Справочник.РесурсныеСпецификации в ERP 2.5).

Следовательно, чтобы понять, куда попадают данные, нам нужно смотреть не правила источника, а именно правила получения в конфигурации-приемнике.

Поиск объекта-приемника в справочнике ПКО

Рассмотрим по шагам, где в интерфейсе КД 3 скрыта связь с реальным объектом метаданных. Основным инструментом здесь является справочник «Правила конвертации объектов» (ПКО).

Выполним следующие действия в базе КД 3:

Перейдем в раздел настроек конвертации для вашей целевой конфигурации (например, ERP).
Откроем список «Правила конвертации объектов».
В списке правил необходимо найти записи, предназначенные для получения данных. Обычно они имеют суффикс _Получение.
Найдем правило, у которого в колонке «Объект формата» указан нужный нам тип XDTO (например, Справочник.СпецификацииНоменклатуры).
Посмотрим на значение в колонке «Объект конфигурации». Именно здесь указывается справочник-приемник в данной конкретной базе.

Например, в случае с ERP 2.4, для объекта формата Справочник.СпецификацииНоменклатуры в качестве объекта конфигурации будет указан Справочник.РесурсныеСпецификации. Если это поле пустое, значит, загрузка для данного типа объектов в текущих правилах не предусмотрена.

Проверка правил обработки данных (ПОД)

Бывают ситуации, когда ПКО (правила конвертации) созданы, но данные все равно не загружаются. Проанализируем роль ПОД (Правил обработки данных). Если ПКО говорит «как» превратить формат в объект, то ПОД определяет «нужно ли» это делать вообще.

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

Анализ состава EnterpriseData и версий формата

Иногда корень проблемы кроется в несовпадении версий формата. Выясним причину, почему в новых релизах (например, ERP 2.5.x) объект может «исчезнуть». С развитием конфигураций 1С меняет структуру метаданных. Справочник.СпецификацииНоменклатуры — это довольно простой объект, тогда как РесурсныеСпецификации в ERP — сложный многоуровневый механизм.

Рассмотрим важные моменты:

Проверьте актуальность XDTO-пакета EnterpriseData, загруженного в КД 3. Если ваша ERP работает на формате 1.13, а в КД загружена версия 1.8, вы можете не увидеть новых связей.
Убедитесь, что объект Справочник.СпецификацииНоменклатуры вообще входит в состав используемой версии формата.

Техническая диагностика через модуль менеджера обмена

Если визуальный редактор КД 3 не дает однозначного ответа, мы можем проанализировать программный код, который генерируется этими правилами. В современных конфигурациях на базе БСП (Библиотеки стандартных подсистем) правила обмена часто встроены в саму базу в виде Модуля менеджера обмена через универсальный формат.

Выполним поиск в конфигураторе приемника (ERP):

Найдем общий модуль МенеджерОбменаЧерезУниверсальныйФормат (или аналогичный с версией формата в названии).
Воспользуемся поиском (Ctrl+F) по строке ПКО_Справочник_СпецификацииНоменклатуры_Получение.
Найдем процедуру инициализации этого правила. В коде это выглядит примерно так:


Процедура ДобавитьПКО_Справочник_СпецификацииНоменклатуры_Получение(ПравилаКонвертации)
    
    Правило = ПравилаКонвертации.Добавить();
    Правило.Имя = "Справочник_СпецификацииНоменклатуры_Получение";
    Правило.ОбъектДанных = "Справочник.РесурсныеСпецификации";
    Правило.ОбъектФормата = "Справочник.СпецификацииНоменклатуры";
    
    // Далее идет описание полей
КонецПроцедуры

Строка Правило.ОбъектДанных = "Справочник.РесурсныеСпецификации"; является окончательным подтверждением того, куда именно записываются данные.

Почему данные выгружаются, но не появляются в приемнике?

Проанализируем типичную ситуацию: в файле выгрузки (XML) данные спецификаций присутствуют, но в ERP справочник пуст. Рассмотрим основные причины:

Отказ в загрузке по условию: В ПКО получения могут быть прописаны обработчики событий (например, ПередЗаписью или ПриКонвертацииДанныхXDTO), которые проверяют заполнение обязательных реквизитов. Если для ERP не хватает данных (например, не указано «Подразделение-диспетчер»), объект может просто не записаться.
Фильтрация по статусам: Часто правила настроены так, что переносятся только спецификации в статусе «Активна».
Поиск соответствий: Если система не нашла номенклатуру, к которой относится спецификация, она может пропустить создание зависимого объекта.

Для диагностики рекомендуем открыть Журнал регистрации в базе-приемнике. При загрузке через EnterpriseData система фиксирует ошибки заполнения объектов. Ищите сообщения от источника «Обмен данными», где будет указано: «Ошибка при записи объекта Справочник.РесурсныеСпецификации... Не заполнено поле...». Это самый быстрый способ понять, почему ПКО «не сработало» в реальности.