Как жестко указать объект загрузки по GUID и разделить данные в Конвертации Данных 2?

Часто при настройке обменов между базами 1С через конфигурацию «Конвертация данных 2» (КД 2) возникает нетривиальная задача: в базе-источнике данные хранятся в одном формате, а в базе-приемнике их нужно структурировать иначе. Разберем типичную ситуацию: мы выгружаем остатки из «Бухгалтерии предприятия 3.0» в «УПП 1.3». В источнике номенклатура и серия заведены в виде единой строки, например: "Анальгин; серия: 1587". В базе-приемнике нам необходимо разделить эту строку на два отдельных справочника — «Номенклатура» (сам Анальгин) и подчиненный справочник «Серии номенклатуры» (1587).

При этом сам «Анальгин» в приемнике уже существует, и мы хотим жестко указать его конкретный GUID, чтобы не плодить дубли. Рассмотрим подробнее несколько способов решения этой проблемы.

Способ 1: Переопределение ссылки при загрузке (Обработчик «Поля поиска»)

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

Для этого в правиле конвертации номенклатуры в обработчике «Поля поиска» напишем следующий код:

СсылкаНаОбъект = Справочники.Номенклатура.ПолучитьСсылку(Новый УникальныйИдентификатор(СтрокаGUID));
ПрекратитьПоиск = Истина;

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

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

Способ 2: Разделение одного объекта на два через «ВыгрузитьПоПравилу»

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

В правиле выгрузки данных (ПВД) или в обработчике ПКО «При выгрузке» мы парсим исходное наименование, выделяем отдельно название номенклатуры и отдельно номер серии. Затем формируем исходящие данные:

// Создаем структуру для передачи данных
ИсходящиеДанные = Новый Структура;
ИсходящиеДанные.Вставить("Наименование", ОчищенноеНаименованиеНоменклатуры);

// Вызываем выгрузку номенклатуры
ВыгрузитьПоПравилу(Неопределено, Неопределено, ИсходящиеДанные, Неопределено, "ИмяПравилаНоменклатуры");

// Очищаем структуру и заполняем данными серии
ИсходящиеДанные.Очистить();
ИсходящиеДанные.Вставить("НомерСерии", ВыделенныйНомерСерии);
ИсходящиеДанные.Вставить("Владелец", ОчищенноеНаименованиеНоменклатуры); // Или GUID владельца

// Вызываем выгрузку серии
ВыгрузитьПоПравилу(Неопределено, Неопределено, ИсходящиеДанные, Неопределено, "ИмяПравилаСерии");

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

Способ 3: Синхронизация по ключу поиска без GUID

Если нет жесткой необходимости привязываться именно к GUID (особенно если баз несколько и GUID могут отличаться), разберем альтернативный путь. Мы можем настроить поиск по строковым реквизитам. Создаем правила конвертации:

1. Номенклатура - Номенклатура: Поиск осуществляется по наименованию. При выгрузке (в обработчике «Перед выгрузкой» ПКС Наименования) мы программно обрезаем из строки все, что относится к серии.
2. Номенклатура - Серия: Поиск настраивается по владельцу и номеру серии. В ПКС вырезаем все, что не относится к номеру серии.

На стороне базы-приемника поиск произойдет автоматически по совпадению подготовленных очищенных строк. Этот подход часто оказывается более гибким, так как избавляет разработчика от необходимости манипулировать уникальными идентификаторами и писать дополнительный код на стороне загрузки (в базе-приемнике).

Проанализируем ситуацию: какой метод выбрать? Если номенклатурных позиций всего несколько штук и их состав не меняется, использование глобальных параметров с жестко прописанными GUID (Способ 1) сэкономит время и ресурсы системы. Если же справочник динамично пополняется, целесообразнее применять парсинг наименования и программную выгрузку через структуру исходящих данных (Способ 2) или поиск по наименованию (Способ 3).