Как в Конвертации данных 3.0 выгрузить один вид документа, а загрузить в другой?

При разработке правил синхронизации в конфигурации «Конвертация данных 3.0» разработчики часто сталкиваются с задачей трансформации данных: когда документ одного вида в базе-источнике должен сформировать документ совершенно другого вида в базе-приемнике. Разберем архитектурные особенности формата EnterpriseData, выясним, чем подход в КД 3.0 отличается от КД 2.1, и подробно рассмотрим по шагам варианты реализации такой схемы обмена.

Архитектурная логика конвертации в КД 3.0

В отличие от классической «Конвертации данных 2.1», где правила сопоставляли метаданные источника напрямую с метаданными приемника, механизмы КД 3.0 работают на базе канонической модели данных — формата EnterpriseData (XDTO). Это означает, что перенос данных всегда разделен на два изолированных процесса:

1. Выгрузка на стороне источника: объект метаданных базы преобразуется в определенный тип объекта XDTO с помощью правил отправки данных (ПОД) и правил конвертации объектов (ПКО).
2. Загрузка на стороне приемника: полученный XDTO-объект считывается правилами получения данных (ПОД) и загружается в объект метаданных приемника через соответствующее ПКО.

Из этой архитектуры логично вытекают два основных сценария трансформации одного документа в другой: выполнение преобразования на этапе выгрузки (в источнике) либо на этапе загрузки (в приемнике).

Вариант 1. Трансформация на стороне источника через отдельное ПКО

Рассмотрим первый способ, когда решение о целевом виде документа можно принять непосредственно в базе-источнике. Это наиболее простой и чистый с точки зрения архитектуры путь: база-источник сразу формирует в сообщении обмена именно тот тип XDTO-объекта, который ожидает база-приемник.

Разберем порядок настройки этого варианта:

1. В правилах конвертации источника создаем новое Правило конвертации объекта (ПКО).
2. В качестве объекта-источника указываем исходный документ (например, ПоступлениеТоваровУслуг), а в качестве объекта-приемника выбираем соответствующий целевой тип XDTO (например, тип для документа ПоступлениеДопРасходов).
3. Настраиваем правила конвертации свойств (ПКС), перенося реквизиты исходного документа в поля XDTO-объекта целевого формата.
4. В Правиле обработки данных (ПОД) для выгрузки исходного документа связываем его с созданным ПКО. Если для одного документа-источника предусмотрено несколько вариантов выгрузки в зависимости от условий (например, от состава табличной части или вида операции), в обработчике ПОД ПриОбработке или при выборке данных программно определяем нужное ПКО через коллекцию ИспользованиеПКО.

В результате база-приемник получит стандартный XDTO-объект нужного типа и обработает его по своим типовым правилам без необходимости дополнительных доработок логики загрузки.

Вариант 2. Динамический выбор ПКО на стороне приемника в ПОД

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

В КД 3.0 в правилах получения данных (ПОД "Для получения") на вкладке «Основные сведения» для одного входящего типа данных XDTO можно указать сразу несколько доступных правил конвертации объектов (ПКО). Чтобы система поняла, какое именно ПКО применить к конкретной порции входящих данных, перейдем в обработчик ПриОбработке этого ПОД.

Посмотрим на пример программного кода, в котором выполняется анализ входящих данных XDTO и включается соответствующее правило конвертации:

Процедура ПОД_Документ_ПоступлениеТоваровУслуг_ПриОбработке(ДанныеXDTO, ЭлементДанных, ИспользованиеПКО, Пакет)

    // Сбрасываем флаги использования правил по умолчанию
    ИспользованиеПКО.ПТиУ_ПоступлениеТоваровУслуг = Ложь;
    ИспользованиеПКО.ПТиУ_ПоступлениеДопРасходов  = Ложь;

    // Анализируем содержимое входящего XDTO-пакета
    Если ДанныеXDTO.Свойство("Услуги") Тогда
        Для Каждого Услуги_Строка Из ДанныеXDTO.Услуги Цикл
            Если Услуги_Строка.ЭтоДопРасходы Тогда
                ИспользованиеПКО.ПТиУ_ПоступлениеДопРасходов = Истина;
            Иначе
                ИспользованиеПКО.ПТиУ_ПоступлениеТоваровУслуг = Истина;
            КонецЕсли;
        КонецЦикла;
    КонецЕсли;

КонецПроцедуры

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

Этот подход также позволяет реализовать сценарий расщепления (когда один входящий документ порождает сразу два разных документа в приемнике): если оба флага в структуре ИспользованиеПКО останутся в значении Истина, система последовательно выполнит конвертацию по обоим правилам.

Важные ограничения и тонкости идентификации объектов

При смене типа документа или его расщеплении важно учитывать механизмы работы Библиотеки стандартных подсистем (БСП):

1. Конфликты сопоставления по UUID: по умолчанию система сопоставляет объекты через регистр сведений СоответствияОбъектовИнформационныхБаз по связке типа объекта и его уникального идентификатора. Если из одного объекта XDTO создаются два документа или меняется целевой тип, стандартный поиск по идентификатору может привести к коллизиям или перезаписи объектов. В таких ситуациях в ПКО настраивают поля поиска (по номеру, дате, контрагенту) или переопределяют поиск в обработчике ПоляПоиска.
2. Двусторонний обмен и зацикливание: если в базе настроен двусторонний обмен, вновь созданный документ другого типа может автоматически зарегистрироваться к отправке обратно на узел плана обмена. Необходимо следить за правилами регистрации объектов (ПРО), чтобы исключить циклическую отправку измененных документов обратно в источник.
3. Состав полей XDTO: если реквизиты исходного документа отсутствуют в выбранном типе схемы EnterpriseData, их передают либо через коллекцию ДополнительныеРеквизиты (если она поддерживается типом XDTO), либо через расширение формата обмена.
4. Перенос алгоритмов в конфигурацию: в КД 3.0 полученный код правил обмена выгружается в виде модуля менеджера обмена через универсальный формат и встраивается непосредственно в саму конфигурацию (в общий модуль или через расширение).