Как передать таблицу значений со ссылочными данными в ПКО Конвертации Данных 2.0?

При разработке правил конвертации в Конвертация Данных 2.0 часто возникает задача передачи кастомных данных, сформированных запросом в базе-источнике, в базу-приемник. Когда такая таблица содержит ссылки (например, на Номенклатуру), простая сериализация через ЗначениеВСтрокуВнутр приводит к потере связи с объектами в приемнике, так как поиск по GUID не учитывает сложные правила поиска, прописанные для справочников. Давайте разберем, как грамотно решить эту задачу.

Почему прямой перенос через параметры — это костыль

Многие разработчики совершают ошибку, сериализуя таблицу значений в строку и передавая её через ПараметрыОбъекта. В приемнике приходится заново писать логику поиска объектов, дублируя настройки из ПКО Номенклатуры. Это создает риски: при изменении правил поиска в ПКО вам придется вручную править код в обработчиках загрузки, что нарушает инкапсуляцию логики КД 2.0.

Решение 1: Использование входящих данных и правил конвертации

Наиболее «правильным» с точки зрения архитектуры КД 2.0 является использование механизма конвертации свойств для каждого элемента таблицы. Вместо передачи «плоской» строки, мы можем подготовить таблицу в источнике и передать её как ВходящиеДанные.

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

Решение 2: Перенос логики распределения в «ПослеЗагрузки»

Если задача заключается в распределении данных (например, ГТД) по табличной части Товары, проанализируем ситуацию: стоит ли вообще пытаться конвертировать эту таблицу как единое целое? Часто гораздо надежнее действовать так:

1. Передавайте из источника только «сырые» данные для каждой строки (номенклатуру и количество), используя стандартный механизм ПКГС.
2. Не пытайтесь распределить суммы или ГТД на этапе выгрузки.
3. В базе-приемнике, в обработчике ПослеЗагрузки объекта, когда все ссылки на номенклатуру уже гарантированно созданы, выполните расчет.

Этот подход позволяет избежать проблем с контекстом документа, так как в ПослеЗагрузки у вас есть полная картина данных в приемнике. Вы сможете легко отфильтровать строки, которые уже были распределены вручную, и применить сложную бизнес-логику пересчета.

Технические рекомендации по реализации

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

// Пример логики в обработчике ПослеЗагрузки в приемнике
// Предположим, мы передали ТЗ через параметр "ТЗ_ГТД"
ТЗ = ПараметрыОбъекта.Получить("ТЗ_ГТД");
Для Каждого СтрокаТЗ Из ТЗ Цикл
    // Здесь номенклатура уже должна быть сконвертирована, 
    // если мы передавали её через ПКС с правилом
    НоменклатураПриемник = СтрокаТЗ.Номенклатура;
    Если ЗначениеЗаполнено(НоменклатураПриемник) Тогда
        // Выполняем распределение ГТД
        РаспределитьГТД(Объект, НоменклатураПриемник, СтрокаТЗ.Количество);
    КонецЕсли;
КонецЦикла;

Итоги и лучшие практики

Подводя итог нашей совместной работе по анализу задачи:

• Никогда не полагайтесь на ручной поиск по коду или GUID, если для объекта существует ПКО. Позвольте системе КД 2.0 сделать работу за вас через механизм ВыгрузитьПоПравилу или стандартное ПКС.
• Смещайте тяжелые вычисления в конец процесса. Этап ПослеЗагрузки — идеальное место для бизнес-логики, так как в этот момент все ссылки внутри документа уже разрешены и записаны в базу данных.
• Используйте вспомогательные табличные части. Если вам нужно передать структуру, которая не вписывается в штатные ТЧ документа, создайте в приемнике служебную ТЧ (можно через расширение), в которую вы будете «сливать» данные для последующей обработки в ПослеЗагрузки.

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