Как настроить произвольное сопоставление объектов по GUID в 1С:Конвертация данных 2.1

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

Основная сложность здесь заключается в том, чтобы заставить механизм «Конвертации данных 2.1» (КД 2.1) найти существующий заказ в приемнике по его GUID, не создавая дублей и не перезаписывая важные данные. Разберем по шагам, как это реализовать максимально корректно.

Способ 1. Использование «пустого» ПКО для сопоставления

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

Алгоритм настройки:

1. Создадим новое ПКО для объекта ДокументСсылка.ЗаказПокупателя -> ДокументСсылка.ЗаказПокупателя.
2. В настройках этого ПКО на закладке «Настройки поиска» установим следующие флаги:
   • Искать по внутреннему идентификатору — это заставит систему сравнивать GUID объекта в XML-файле с GUID в базе-приемнике.
   • Не замещать существующие объекты в приемнике — крайне важный флаг, который гарантирует, что данные уже существующего заказа в Базе №1 не будут затерты пустыми значениями из выгрузки.
   • Не создавать новый объект, если он не найден — если по какой-то причине заказа в базе нет, система просто вернет пустую ссылку (или ОбъектНеНайден), но не создаст «пустышку».
3. В ПКС (правила конвертации свойств) этого правила не нужно добавлять никаких реквизитов, кроме тех, что могут понадобиться для идентификации, если GUID не совпадет (хотя в нашей задаче GUID приоритетен).
4. В основном правиле конвертации (Чек ККМ -> ПКО) для свойства ВведенНаОсновании (или ДокументОснование) укажем созданное нами «пустое» правило конвертации заказа.

Таким образом, при загрузке ПКО система увидит ссылку на заказ, обратится к специальному правилу, найдет объект по GUID в Базе №1 и подставит его в реквизит, не совершая лишних действий по записи заказа.

Способ 2. Принудительная установка GUID через «УстановитьСсылкуНового»

Иногда требуется, чтобы сам загружаемый документ (ПКО) в Базе №1 получил тот же GUID, что и Чек ККМ в Базе №2. Это полезно для обеспечения двусторонней синхронности в будущем. Рассмотрим, как реализовать это программно в обработчиках КД.

В ПКО для Чека ККМ в обработчике «Перед загрузкой» мы можем прописать логику установки ссылки. Посмотрим на пример кода:

// В обработчике "Перед загрузкой"
Если ОбъектМодифицирован = Ложь Тогда
    // Создаем GUID на основании переданного из источника идентификатора
    СсылкаНаОбъект = Документы.ПриходныйКассовыйОрдер.ПолучитьСсылку(Новый УникальныйИдентификатор(ПараметрыОбъекта["ВнутреннийИдентификатор"]));
    Объект.УстановитьСсылкуНового(СсылкаНаОбъект);
КонецЕсли;

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

Способ 3. Программная выгрузка ссылки через «ВыгрузитьПоПравилу»

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

Мы можем явно передать GUID заказа, даже если сам объект заказа не выгружается целиком в данный момент:

// ПКС "ВведенНаОсновании" -> Перед выгрузкой
УзелСсылки = ВыгрузитьПоПравилу(Источник.ЗаказПокупателя, , , , "ЗаказПокупателя_ТолькоПоиск");
Значение = УзелСсылки;

Здесь "ЗаказПокупателя_ТолькоПоиск" — это имя ПКО, настроенного по методу №1 (с флагами поиска по UID и запретом создания).

Важные технические нюансы при сопоставлении

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

• Проблема разных типов GUID: Выясним причину, если поиск не срабатывает. В некоторых конфигурациях разработчики создают строковый реквизит с именем GUID. Важно помнить, что внутренний идентификатор 1С (метод УникальныйИдентификатор()) и строковый реквизит — это разные сущности. Если в Базе №1 поиск должен идти по строковому реквизиту, необходимо использовать обработчик «Поля поиска» и устанавливать ПрекратитьПоиск = Истина.
• Оптимизация через «ЗначениеВыгрузки»: Чтобы не плодить лишние XML-узлы, для передачи ссылки можно использовать тип УникальныйИдентификатор. Система сформирует узел ссылки автоматически, если тип приемника однозначно определен в метаданных.
• Конфликты нумерации: При создании ПКО на основании Чека ККМ часто сбиваются номера. Рекомендуем в правилах для ПКО использовать обработчик «Установить новый номер» или вызывать стандартный метод Объект.УстановитьНовыйНомер() в событии «После загрузки», чтобы сохранить логику нумерации Базы №1.

Использование параметров для передачи дополнительных данных

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

В источнике (База №2) в ПКО в обработчике «При выгрузке»:

ПередатьПараметр("ИмяКассира", Источник.Кассир.Наименование);

В приемнике (База №1) в обработчике «После загрузки»:

Если ПараметрыОбъекта <> Неопределено Тогда
    Объект.Комментарий = "Загружено из кассы. Кассир: " + ПараметрыОбъекта["ИмяКассира"];
КонецЕсли;

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