Как правильно настроить поиск объектов в приемнике при использовании Конвертации данных 3.0?

При переходе с «Конвертации данных 2.1» на версию 3.0 многие разработчики сталкиваются с тем, что привычные механизмы поиска работают иначе. В КД3 (основанной на формате EnterpriseData) логика поиска отделена от логики выгрузки данных, что часто приводит к ситуациям, когда объект сопоставляется не по тем полям, которые ожидает программист — решить эту проблему поможет готовый комплект правил обмена EnterpriseData. Разберем подробно, как работает этот механизм, почему система может игнорировать ваши настройки и как правильно проводить отладку.

Взаимосвязь ключевых свойств и полей поиска

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

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

Рассмотрим критически важный нюанс: если вы решите добавить в «Поля поиска» реквизит (например, Артикул), но не отметите его как «Ключевое свойство», то при передаче объекта «по ссылке» этого поля просто не будет в файле. В результате база-приемник получит пустую строку, и поиск по данному полю не даст результата. Следовательно, состав полей поиска всегда должен быть подмножеством ключевых свойств.

Почему объект ищется по «Наименованию», если указан «Артикул»?

Часто возникает ситуация: в правилах указан поиск только по артикулу, но система все равно находит и перезаписывает объект с совпадающим наименованием. Выясним причину такого поведения. В КД3 и Библиотеке стандартных подсистем (БСП) существует жесткая иерархия поиска:

1. Поиск по УИД (GUID): Это самый высокий приоритет. Если объект ранее уже участвовал в обмене, информация о соответствии (синхронизации) сохраняется в регистрах сведений. Система найдет объект по внутреннему идентификатору, даже если все текстовые поля в файле изменены.
2. Поиск по правилам КД3: Только если поиск по УИД не дал результатов, вступают в силу настроенные вами поля поиска.
3. Алгоритм в модуле менеджера обмена: В коде конфигурации-приемника может быть переопределена процедура ПОЛУЧИТЬ_ССЫЛКУ_ПО_ПОЛЯМ_ПОИСКА (для лучшего понимания работы этих механизмов рекомендуем изучить справочник по методам БСП). Если там жестко прописана логика поиска (например, «всегда искать по наименованию, если не найден артикул»), она будет иметь приоритет над визуальными настройками в КД3.
4. Стандартный фолбэк (fallback): В современных версиях БСП заложен алгоритм предотвращения дублей. Если основной поиск не сработал, система может совершить «последнюю попытку» найти объект по стандартным реквизитам (Код или Наименование), чтобы не создавать дублирующую запись.

Методы отладки и анализа выгружаемых данных

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

Способ 1. Использование специализированной обработки

Наиболее удобным инструментом является обработка ВыгрузкаЗагрузкаEnterpriseData. Она позволяет:

• Выгрузить конкретный объект (например, одну номенклатуру или один заказ).
• Просмотреть сформированный XML-код прямо в интерфейсе.
• Проверить, какие именно поля попали в узел Ссылка.

Способ 2. Тестирование через план обмена в файл

Рассмотрим по шагам процесс ручной проверки через регистрацию изменений:

1. Создаем тестовую папку на диске.
2. В настройках синхронизации указываем транспорт через «Локальный каталог».
3. Регистрируем нужный объект (например, Номенклатуру) к обмену через стандартную обработку или используя удобное расширение для регистрации объектов с формы — для этого отлично подойдёт расширение регистрации объектов на планах обмена 1С.
4. Запускаем синхронизацию и открываем созданный XML-файл любым текстовым редактором.

Проанализируем структуру файла. Если мы видим, что в узле номенклатуры отсутствует Артикул, значит, он не отмечен как ключевое свойство в правилах выгрузки. Если же он есть, но поиск в приемнике все равно идет неверно — проблему нужно искать в коде модуля менеджера обмена приемника.

Программная настройка логики поиска

Если стандартных настроек в интерфейсе «Конвертации данных 3.0» недостаточно, мы можем прибегнуть к написанию кода в обработчиках — а для интеграции старых конфигураций 1С пригодится обработка автоматизации обмена в формате EnterpriseData. В модуле менеджера обмена существует обработчик «При поиске». Рассмотрим пример логики, которую можно там реализовать:

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

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

Резюме и рекомендации

Чтобы поиск в КД3 работал предсказуемо, придерживайтесь следующих правил:

• Проверяйте состав ключевых свойств: все поля, по которым вы планируете искать объект, должны быть помечены как ключевые в ПОД (для создания легких правил пригодится выборочная выгрузка описания метаданных).
• Используйте инструменты отладки: всегда проверяйте содержимое XML-файла через ВыгрузкаЗагрузкаEnterpriseData, чтобы убедиться в наличии необходимых данных.
• Учитывайте УИД: помните, что если объект уже был сопоставлен, поиск по полям (артикулу, коду) выполняться не будет.
• Анализируйте модуль менеджера: при странном поведении поиска изучите код процедур ПОЛУЧИТЬ_ССЫЛКУ_ПО_ПОЛЯМ_ПОИСКА в конфигурации-приемнике.