Как настроить замену подразделения при обмене данными между КА 1.1 и БП 3.0 в Конвертации данных 2.0?

При настройке обмена данными между устаревшими конфигурациями (например, 1С:Комплексная автоматизация 1.1) и современными решениями (1С:Бухгалтерия предприятия 3.0) часто возникает задача сопоставления аналитики. Типичный пример: в источнике подразделение называется «Офис», а в приемнике оно должно называться «Офис новый». Ситуация осложняется тем, что справочники имеют разную структуру и внутренние идентификаторы (UUID). Рассмотрим подробнее, как реализовать такую подмену в правилах обмена Конвертации данных 2.0.

Вариант 1. Использование обработчика «Перед выгрузкой» в ПКС

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

Найдем в правилах конвертации документа (например, РеализацияТоваровУслуг) свойство Подразделение. В обработчике Перед выгрузкой этого Правила конвертации свойства (ПКС) мы можем программно изменить передаваемое значение. Проанализируем пример кода:

// В обработчике ПКС "Подразделение" -> "Перед выгрузкой"
Если Источник.Подразделение.Наименование = "Офис" Тогда
    Значение = "Офис новый";
Иначе
    Значение = Источник.Подразделение.Наименование;
КонецЕсли;

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

Вариант 2. Переопределение полей поиска в ПКО

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

Алгоритм работы выглядит следующим образом: при выгрузке мы передаем стандартное наименование «Офис», но в момент загрузки в БП 3.0 система меняет параметры поиска. Посмотрим на реализацию:

// В ПКО "ПодразделенияОрганизаций" -> обработчик "Поля поиска"
НаименованиеПоиска = СвойстваПоиска.Получить("Наименование");

Если НаименованиеПоиска = "Офис" Тогда
    СвойстваПоиска.Установить("Наименование", "Офис новый");
КонецЕсли;

Этот метод хорош тем, что он централизован. Где бы ни встретилось подразделение «Офис» (в реализациях, поступлениях или требованиях-накладных), оно всегда будет корректно сопоставлено с подразделением «Офис новый» в приемнике.

Вариант 3. Передача маркера через параметры (для продвинутых задач)

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

1. В источнике (КА 1.1) в ПКС Подразделение пишем: Значение = "МАРКЕР_ОФИС";.
2. В приемнике (БП 3.0) в событии ПКО После загрузки анализируем этот параметр:

// В обработчике ПКО документа "После загрузки"
Если ПараметрыОбъекта <> Неопределено Тогда
    Маркер = ПараметрыОбъекта.Получить("Подразделение");
    Если Маркер = "МАРКЕР_ОФИС" Тогда
        Объект.Подразделение = Справочники.ПодразделенияОрганизаций.НайтиПоНаименованию("Офис новый");
    КонецЕсли;
КонецЕсли;

Этот способ позволяет избежать жесткой привязки к структуре справочников на этапе выгрузки и дает больше гибкости при загрузке данных в сложную иерархию БП 3.0.

Почему КД 2.0 предпочтительнее Enterprise Data (КД 3.0) в данной связке?

В процессе обсуждения часто возникает вопрос: не лучше ли использовать современный формат Enterprise Data? Проанализируем ситуацию для связки КА 1.1 — БП 3.0. Комплексная автоматизация 1.1 — это конфигурация на «обычных формах», архитектура которой создавалась задолго до появления ED.

Посмотрим на основные преимущества использования КД 2.0 в данном контексте:

• Производительность: КД 2.0 выгружает данные напрямую в XML через последовательную запись, что значительно быстрее работы с тяжелыми XDTO-пакетами Enterprise Data на старых версиях платформы.
• Гибкость: В ED состав полей жестко ограничен схемой (XSD). Если вам нужно передать специфическую аналитику (например, данные о водителе или перевозчике, которых нет в стандарте ED 1.6), вам придется менять расширения или конфигурации в обеих базах. В КД 2.0 достаточно просто добавить ПКС.
• Отсутствие поддержки: Старые конфигурации часто поддерживают только ранние версии Enterprise Data (1.0–1.3), в которых отсутствуют механизмы для работы с кодами маркировки, прослеживаемостью и другими современными реквизитами, которые уже есть в актуальных версиях БП 3.0.

Рекомендации по синхронизации ГУИД

При обмене между разными конфигурациями крайне важно следить за уникальными идентификаторами объектов (UUID/GUID). Если в КА 1.1 и БП 3.0 справочники создавались независимо, поиск по внутреннему идентификатору может привести к созданию дублей или путанице. Рекомендуем в ПКО справочников отключать флаг Искать объект по внутреннему идентификатору и использовать поиск по коду или наименованию (с учетом иерархии или владельца, если это подразделения организации).

Также не забывайте, что в БП 3.0 подразделения организации могут быть обособленными. При программной подстановке («Офис новый») убедитесь, что у созданного или найденного элемента корректно заполнены счета учета и привязка к организации, иначе проведение документов в приемнике завершится ошибкой.