Как в КД 3.0 конвертировать несколько видов документов в один объект: минимизируем количество правил

При настройке обмена данными через Конвертацию данных 3.0 (КД 3.0) по технологии Enterprise Data разработчики часто сталкиваются с ситуацией, когда в базе-источнике существует несколько видов документов, выполняющих схожие функции, а в базе-приемнике им соответствует всего один объект метаданных. Классический пример — выгрузка ведомостей на выплату зарплаты из ЗУП 3.1 (где их 6 видов) в документ ЗарплатаКВыплатеОрганизаций в УПП 1.3 или ERP.

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

Понимание архитектуры КД 3.0 и формата обмена

Для начала проанализируем основное отличие КД 3.0 от КД 2.1. В новой версии обмен происходит не напрямую между объектами, а через промежуточный формат XDTO. Это означает, что:

1. На стороне источника (ЗУП) нам нужно превратить 6 разных документов в один тип объекта XDTO (например, Document.PayrollSheet).
2. На стороне приемника (УПП) нам нужно превратить этот один тип XDTO в один документ 1С.

Таким образом, основная сложность заключается в настройке правил на стороне источника, так как КД 3.0 требует жесткой привязки ПОД и ПКО к конкретному типу метаданных.

Шаг 1: Создание правил на стороне источника (ЗУП)

Выясним причину, почему нельзя обойтись одним ПКО: в интерфейсе КД 3.0 при создании ПКО вы обязаны указать конкретный объект метаданных. Следовательно, для 6 ведомостей из ЗУП нам в любом случае придется создать 6 ПКО и 6 ПОД на отправку.

Однако, чтобы не дублировать код заполнения данных, мы применим следующий алгоритм:

1. Создадим один Общий модуль в конфигурации ЗУП (или воспользуемся существующим для кастомных правил), в котором опишем процедуру заполнения структуры данных.
2. В каждом из 6 ПКО в обработчике ПриОтправкеДанных будем вызывать эту общую процедуру.

Рассмотрим пример кода в общем модуле:

Процедура ЗаполнитьДанныеВедомостиДляВыгрузки(ДанныеXDTO, Объект) Экспорт
    // Заполняем общие реквизиты, которые есть во всех ведомостях
    ДанныеXDTO.Номер = Объект.Номер;
    ДанныеXDTO.Дата  = Объект.Дата;
    ДанныеXDTO.Организация = Объект.Организация;
    ДанныеXDTO.СуммаПоДокументу = Объект.Зарплата.Итог("КВыплате");
    
    // При необходимости добавляем логику ветвления
    Если ТипЗнч(Объект) = Тип("ДокументСсылка.ВедомостьНаВыплатуЗарплатыВБанк") Тогда
        ДанныеXDTO.СпособВыплаты = "ЧерезБанк";
    КонецЕсли;
КонецПроцедуры

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

// В обработчике ПКО "При отправке данных"
МойОбщийМодуль.ЗаполнитьДанныеВедомостиДляВыгрузки(ДанныеXDTO, ДанныеИБ);

Шаг 2: Настройка ПОД на отправку

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

Шаг 3: Настройка на стороне приемника (УПП)

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

Важный момент: Если вам важно в УПП знать, какой именно вид ведомости был в ЗУП, рекомендуется добавить в XDTO-пакет дополнительное свойство (например, ТипВедомостиИсточник) и заполнять его в ПКО источника. Это позволит в приемнике использовать условия при заполнении реквизитов.

Шаг 4: Решение проблемы коллизий GUID

Разберем важный технический нюанс, упомянутый опытными специалистами. Теоретически разные виды документов в ЗУП могут иметь одинаковые УникальныйИдентификатор (GUID), если они были созданы специфическим образом или перенесены из других систем. Если в УПП поиск идет только по GUID, один документ может "затереть" другой.

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

• Номер документа
• Дата документа
• Организация

Или использовать Ключи синхронизации, добавив в них информацию о типе исходного объекта.

Шаг 5: Использование универсальных алгоритмов в КД 3.0

Если вы хотите еще больше сократить количество ручных настроек в интерфейсе КД, можно воспользоваться обработчиком ПередОбработкой в ПОД. В некоторых случаях это позволяет программно переопределять ИмяПКО, однако стандартным и более прозрачным способом для КД 3.0 остается использование схемы "6 ПКО источника -> 1 тип XDTO -> 1 ПКО приемника".

Посмотрим на структуру ПКО на стороне приемника (УПП):

1. Создаем ПКО, где объект формата — Document.PayrollSheet, а объект метаданных — Документ.ЗарплатаКВыплатеОрганизаций.
2. В таблице свойств сопоставляем реквизиты формата и реквизиты документа.
3. В обработчике ПослеЗагрузкиДанных прописываем специфичную логику для УПП (например, установку учетной политики или заполнение счетов учета).

Резюме по реализации

Подводя итог, можно сказать, что попытка запихнуть 6 разных метаданных в одно ПКО на стороне источника противоречит архитектуре КД 3.0. Правильная стратегия — это типизация через формат:

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

2. На стороне приемника: 1 ПОД и 1 ПКО, работающие с этим универсальным типом формата.

3. Безопасность: Настройка полей поиска для предотвращения коллизий GUID между разными видами ведомостей.

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