Как работают поля поиска в 1С:Конвертация данных и почему объекты могут не синхронизироваться при выполнении условий?

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

Логика работы полей поиска: условие «И» или «ИЛИ»?

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

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

Выясним причину, почему это важно для иерархических справочников. Поле ЭтоГруппа является критически важным реквизитом. Если вы ищете объект по ИНН/КПП, но не учитываете ЭтоГруппа, может возникнуть ситуация, когда система попытается сопоставить группу (папку) из источника с элементом в приемнике. Включение ЭтоГруппа в поля поиска по условию «И» гарантирует, что папки будут сопоставляться только с папками, а элементы — только с элементами.

Приоритет уникального идентификатора (GUID)

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

Посмотрим на алгоритм работы загрузки:

1. Система считывает уникальный идентификатор (GUID) объекта из файла выгрузки.
2. Пытается найти объект в базе-приемнике именно по этому GUID.
3. Если объект найден по GUID: система прекращает всякий поиск по полям (ИНН, КПП и прочее). Она просто берет найденный объект и обновляет его реквизиты (если не установлены запреты на замещение).
4. Если объект НЕ найден по GUID: только тогда вступает в силу поиск по указанным в правилах полям (условие «И»).

Это объясняет ситуацию, когда пользователь меняет поля поиска (например, убирает Наименование), но система всё равно продолжает сопоставлять объекты «неправильно». Если ранее объект уже был загружен и связь по GUID установилась, поля поиска игнорируются.

Особенности работы через механизм «Синхронизация данных»

Если обмен идет не через простую обработку «Универсальный обмен данными XML», а через стандартную подсистему «Синхронизация данных» (через планы обмена), в процесс включается дополнительный уровень — регистр соответствий. Рассмотрим ситуацию, когда обмен идет между двумя узлами по расписанию.

В таких обменах связь между объектами фиксируется в специальном служебном регистре сведений (обычно это СоответствияОбъектовИнформационныхБаз). Как только объект из базы А был сопоставлен с объектом из базы Б (неважно, по GUID или по полям поиска при первом обмене), эта связь записывается в регистр навсегда.

Проанализируем последствия этого механизма:

• Даже если вы измените GUID объекта в источнике или отредактируете поля поиска в правилах, синхронизация будет «помнить» старую связь из регистра соответствий.
• Если объект при массовой выгрузке «не создается» в нужной группе, проверьте, не сопоставлен ли он ранее с каким-то другим объектом в приемнике. Возможно, он просто обновляет уже существующего контрагента в другой папке.

Программное управление поиском в обработчиках

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

Разберем пример кода в обработчике ПоляПоиска:

// Пример управления поиском
// НомерВарианта - позволяет переключать логику поиска внутри одного ПКО

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

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

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

Почему объект выгружается отдельно, но «пропадает» в общей массе?

Рассмотрим ситуацию автора темы: при выгрузке группы контрагент пропадает, а при выгрузке его одного — появляется. Выясним возможные причины этого поведения:

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

Практические рекомендации по настройке поиска

Для того чтобы поиск работал предсказуемо, выполним следующие шаги:

1. Минимизируйте количество полей поиска. Чем больше полей связано условием «И», тем выше вероятность, что из-за опечатки в одном из них (например, в КПП или Наименовании) система не найдет объект и создаст дубль.

2. Всегда включайте «ЭтоГруппа». Это обязательное поле для иерархических справочников, чтобы избежать путаницы между папками и элементами.

3. Используйте поиск по GUID осознанно. Если базы являются «родственными» (например, одна создана из копии другой), поиск по идентификатору — самый надежный способ. Если же базы создавались независимо, поиск по идентификатору лучше отключить в ПКО, оставив только поля (ИНН, Код и т.д.).

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

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