Как в КД 3.0 настроить разный поиск для юрлиц (по ИНН) и физлиц (по наименованию) при обмене через Enterprise Data

← На главную

При настройке обмена данными через универсальный формат Enterprise Data (ED) с использованием Конвертации данных 3.0 (КД 3.0) разработчики часто сталкиваются с проблемой идентификации объектов. Типичный пример — справочник Контрагенты. В одной базе это может быть единый список, где перемешаны юридические и физические лица, и логика их поиска должна кардинально отличаться. Для юрлиц критически важен поиск по ИНН и КПП, тогда как для физлиц (особенно если ИНН не заполнен) основным критерием становится Наименование (ФИО).

В этой статье мы подробно разберем, как правильно настроить правила поиска, чтобы избежать дублирования записей и корректно сопоставить данные при наличии "грязных" данных в полях КПП.

Механизм последовательных попыток поиска

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

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

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

Разделение на разные ПКО (самый надежный метод)

Если логика поиска физических и юридических лиц слишком сильно различается, или вы хотите полностью исключить риск сопоставления физлица с юрлицом по случайному совпадению наименования, рекомендуется использовать разделение на два отдельных ПКО. Рассмотрим, как это реализовать:

Создадим два правила конвертации: Контрагенты_ЮрЛица и Контрагенты_ФизЛица. В каждом из них настроим свои поля поиска:

В ПКО для юрлиц выставляем поиск по ИНН и КПП.
В ПКО для физлиц выставляем поиск по Наименованию и, например, Дополнительной информации.

Чтобы система понимала, какое правило применить к конкретному объекту XDTO, необходимо прописать алгоритм выбора в Правилах Обработки Данных (ПОД) или в событии «Перед конвертацией». Выясним причину выбора конкретного ПКО, анализируя свойства входящих данных:


// Пример логики выбора ПКО в обработчике
Если ДанныеXDTO.ЮридическоеФизическоеЛицо = "ЮридическоеЛицо" Тогда
    ИмяПКО = "Контрагенты_ЮрЛица";
Иначе
    ИмяПКО = "Контрагенты_ФизЛица";
КонецЕсли;

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

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

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

Разберем по шагам, как настроить этот обработчик:

Система получает данные в формате XDTO.
В обработчике мы проверяем значение свойства ЮридическоеФизическоеЛицо.
Если это юрлицо — оставляем в массиве поиска только ИНН.
Если это физлицо — очищаем массив и добавляем туда Наименование.

Пример программной реализации в менеджере обмена:


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

Проблема "грязных" данных в поле КПП

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

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

Особенности идентификации ИП и Физлиц

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

Для ИП приоритетным полем поиска должен оставаться ИНН.
Для обычных физлиц, у которых нет ИНН в базе, поиск должен идти по комбинации ФИО + Телефон или ФИО + Электронная почта. Это значительно снизит вероятность "склеивания" полных тезок.

Использование дополнительных свойств (AdditionalInfo) в формате Enterprise Data позволяет передать любые уточняющие признаки, которые помогут идентифицировать объект, если стандартных полей недостаточно.

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