Как работает поиск по полям в 1С:Конвертация данных, если отключен поиск по GUID?

← На главную

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

Базовые принципы и приоритеты поиска

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

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

Ситуация, когда система выполняет дефолтный поиск по коду (для справочников), возникает только в одном случае: если поиск по GUID отключен и при этом не задано ни одного поля поиска. Галка «Продолжить поиск по полям поиска» предназначена именно для того, чтобы дать команду системе искать по реквизитам в случае, когда элемент по GUID не был найден.

Расширенная настройка через обработчик «Поля поиска»

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

Динамическое изменение приоритета: В обработчике мы можем переопределить системную переменную СтрокаИменСвойствПоиска. Это укажет платформе, в какой последовательности проверять поля. Например, мы можем приказать искать сначала по ИНН и КПП, а если совпадений нет — по полному наименованию.
Собственный алгоритм запроса: Если нам нужен поиск по сложным условиям или связанным регистрам, мы можем написать произвольный запрос к базе-приемнику.

Посмотрим на пример использования собственного алгоритма. После того как запрос отработает и нужная ссылка будет найдена, нам необходимо присвоить её системной переменной СсылкаНаОбъект и обязательно прервать дальнейший стандартный поиск:


// Пример произвольного поиска в обработчике ПКО "Поля поиска"
Запрос = Новый Запрос;
Запрос.Текст = "ВЫБРАТЬ ПЕРВЫЕ 1
    |    Контрагенты.Ссылка КАК Ссылка
    |ИЗ
    |    Справочник.Контрагенты КАК Контрагенты
    |ГДЕ
    |    Контрагенты.ИНН = &ИНН
    |    И Контрагенты.КПП = &КПП";

Запрос.УстановитьПараметр("ИНН", СвойстваПоиска.Получить("ИНН"));
Запрос.УстановитьПараметр("КПП", СвойстваПоиска.Получить("КПП"));

Результат = Запрос.Выполнить();
Если Не Результат.Пустой() Тогда
    Выборка = Результат.Выбрать();
    Выборка.Следующий();
    
    // Передаем найденную ссылку механизму обмена
    СсылкаНаОбъект = Выборка.Ссылка;
    
    // Останавливаем стандартный поиск
    ПрекратитьПоиск = Истина;
КонецЕсли;

Риски и ограничения при отключении поиска по GUID

Выясним, с какими проблемами мы можем столкнуться, если полностью откажемся от поиска по внутреннему идентификатору и перейдем исключительно на поиск по полям:

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

Альтернативы: КД 3.0 и Универсальный формат EnterpriseData

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

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