Как реализовать поиск по ИНН или Наименованию в зависимости от статуса в 1С:Конвертация данных 2.0

При настройке обмена данными между конфигурациями 1С часто возникает задача гибкого сопоставления объектов. Стандартный механизм поиска в Правилах конвертации объектов (ПКО) позволяет выбрать фиксированный набор полей, но в реальной практике этого часто недостаточно. Например, для юридических лиц основным идентификатором должен выступать ИНН (или связка ИНН + КПП), а для физических лиц, у которых ИНН может быть не заполнен, логичнее использовать Наименование. В рамках данной статьи мы разберем, как реализовать такую логику, используя стандартные механизмы "Конвертации данных 2.0".

Использование обработчика «Поля поиска»

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

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

Рассмотрим пример кода, который решает поставленную задачу:

// Проверяем тип контрагента (ЮрЛицо или ФизЛицо)
// Важно: сравниваем через строковое представление или метаданные
Если Строка(СвойстваПоиска.Получить("ЮрФизЛицо")) = "ЮридическоеЛицо" Тогда
    // Для юридических лиц ищем по ИНН
    СтрокаИменСвойствПоиска = "ИНН";
Иначе
    // Для всех остальных (физлица, ИП) ищем по Наименованию
    СтрокаИменСвойствПоиска = "Наименование";
КонецЕсли;

Важное замечание: Чтобы свойство ЮрФизЛицо (или аналогичный флаг) было доступно в структуре СвойстваПоиска, оно обязательно должно быть описано в Правилах Конвертации Свойств (ПКС) данного объекта. При этом галочку "Поиск" у этого свойства ставить не обязательно — достаточно того, что оно передается в приемник.

Тонкости сравнения значений перечислений

Проанализируем типичную ошибку начинающих разработчиков. Часто пытаются написать сравнение вида: Если СвойстваПоиска.ЮрЛицо = Перечисления.ЮрФизЛицо.ЮридическоеЛицо. В контексте обработчика ПоляПоиска это может привести к ошибке или некорректной работе, так как в структуре СвойстваПоиска значение может храниться не как ссылка, а как строковое имя значения перечисления или XML-идентификатор.

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

1. Приведение к строке: Строка(СвойстваПоиска.Получить("ИмяСвойства")) = "ИмяЗначения".
2. Использование функции Врег() для исключения ошибок регистра.
3. Проверка через СвойстваПоиска.Получить("ЮрЛицо"), так как обращение через точку к структуре может вызвать исключение, если ключ отсутствует.

Многоэтапный поиск с использованием НомерВариантаПоиска

Иногда требуется более сложная логика: сначала попытаться найти по одному набору полей, а если объект не найден — по другому. Для этого в 1С:КД 2.0 предусмотрен параметр НомерВариантаПоиска. Система вызывает обработчик ПоляПоиска циклично, пока не будет найден объект или пока разработчик не прекратит поиск.

Рассмотрим пример реализации многоступенчатого поиска:

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

Такой подход позволяет значительно повысить качество сопоставления данных, особенно при миграции из "грязных" баз, где ИНН может быть дублирован или не заполнен.

Как избежать создания лишних объектов

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

Чтобы управлять этим процессом, воспользуемся следующими методами:

1. Отключение автоматического создания: В обработчике ПослеПоиска можно прописать условие:
   Скопировать код

   
   Если Ссылка = Неопределено Тогда
       Отказ = Истина;
   КонецЕсли;
   

   Это предотвратит создание нового элемента, если поиск не дал результатов.
2. Настройка ПКС: Для свойства Контрагент в правилах конвертации документа можно установить флаг "Не выгружать объекты свойства непосредственно". В этом случае в файл выгрузки попадут только поля поиска контрагента, и если он не будет найден в базе-приемнике, поле в документе останется пустым, а новый контрагент создан не будет.

Рекомендации по поиску юридических лиц

Проанализируем ситуацию с поиском по ИНН. Использование только одного ИНН для юридических лиц в крупных компаниях — это риск. У филиальных структур ИНН совпадает, а различаются они по КПП. Поэтому при формировании СтрокаИменСвойствПоиска для ЮЛ всегда старайтесь включать оба поля: "ИНН, КПП".

Для физических лиц ситуация иная: у них нет КПП, а ИНН часто отсутствует в базе. Поэтому разделение логики через ПоляПоиска, которое мы рассмотрели в начале, является "золотым стандартом" разработки правил обмена.

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