Почему в КД 2.1 для одного и того же объекта применяется не то ПКО и как это исправить?

← На главную

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

Разбор ситуации: почему движок КД 2 игнорирует настройки

Проанализируем механику работы выгрузки. Основная причина «странного» поведения кроется в двух аспектах: порядке следования правил и кэшировании выгруженных объектов.

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

Решение №1: Использование параметров и одного ПКО

Создание двух ПКО для одного справочника считается плохим тоном в разработке на КД 2 именно из-за вышеописанных проблем с кэшем. Рассмотрим, как реализовать задачу с помощью одного ПКО и параметров выгрузки.

Шаг 1. Определение параметра. Создадим параметр в объекте «Конвертация», например, ВыгружатьКодСтатьи. Этот параметр мы будем устанавливать в ПВД.

Шаг 2. Настройка ПВД. В правиле выгрузки данных, где код НЕ нужен, в обработчике Перед обработкой или При выгрузке пропишем установку параметра:

Параметры.ВыгружатьКодСтатьи = Ложь;

Шаг 3. Настройка ПКО. В ПКО ПрочиеДоходыИРасходы для свойства Код (ПКС) в обработчике Перед выгрузкой добавим условие:


Если Параметры.ВыгружатьКодСтатьи = Ложь Тогда
    Отказ = Истина;
КонецЕсли;

Таким образом, мы используем одно и то же правило, но гибко управляем составом полей. Это исключает конфликты кэширования.

Решение №2: Гибкий поиск на стороне приемника

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

Рассмотрим пример кода, который позволяет менять поля поиска «на лету» в зависимости от того, переданы данные или нет:


// Если Код не пришел (мы его отключили в ПКО), ищем только по Наименованию
Если СвойстваПоиска["Код"] = Неопределено Тогда
    СтрокаИменСвойствПоиска = "Наименование,ЭтоГруппа";
Иначе
    // Если код есть, используем стандартный поиск
    СтрокаИменСвойствПоиска = "Код,Наименование";
КонецЕсли;

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

Решение №3: Жесткое указание ПКО в ПКС и иерархии

Если вы все же решили оставить два ПКО, необходимо «ткнуть систему носом» в каждое правило. Рассмотрим, где это нужно сделать.

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

В ПКО в правиле конвертации свойства Родитель обязательно нужно прописать обработчик Перед выгрузкой:

ИмяПКО = "ПрочиеДоходыИРасходыБезКода"; // Явное указание имени правила

Это заставит движок использовать конкретное правило при выгрузке иерархических связей, игнорируя настройки по умолчанию.

Как отладить «странное» поведение?

Если ситуация не проясняется, разберем по шагам, как воспользоваться механизмом отладки обработчиков:

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

Резюме

Для стабильной работы обмена в КД 2 рекомендуем придерживаться следующих правил:

Минимизируйте количество ПКО для одного типа метаданных. Лучше одно сложное ПКО с параметрами, чем три простых, конфликтующих между собой.
Используйте параметры для управления логикой выгрузки полей.
Всегда контролируйте поиск: если вы меняете состав выгружаемых полей, обязательно перепроверьте алгоритм сопоставления в обработчике Поля поиска.
Предопределенные элементы выгружайте с осторожностью, помня, что они первыми попадают в кэш объектов.

Проанализировав ситуацию, можно сделать вывод: поведение КД 2 не «странное», а строго детерминированное. Понимание алгоритмов работы кэша и выбора правил по умолчанию позволяет создавать надежные системы интеграции без использования «костылей».