Как избежать дублирования физических лиц и подразделений при обмене между ЗУП, УТ и БП

При организации обмена данными между несколькими информационными базами (например, когда 1С:Зарплата и Управление Персоналом и 1С:Управление торговлей одновременно выгружают данные в 1С:Бухгалтерию предприятия) часто возникает проблема задвоения элементов справочников ФизическиеЛица и ПодразделенияОрганизаций. Разберем детально, по каким полям происходит сопоставление объектов, где расположены правила обмена и как правильно выстроить архитектуру потоков данных.

Причины возникновения дублей при загрузке данных

Проанализируем ситуацию, почему типовые механизмы обмена могут создавать дублирующиеся записи в базе-приемнике:

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

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

Рассмотрим, по каким ключевым реквизитам выполняется поиск объектов в типовых правилах конвертации:

1. Справочник «Физические лица»:
   1. Основной идентификатор: поиск по СНИЛС (реквизит СтраховойНомерПФР). Это наиболее надежный способ однозначной идентификации человека.
   2. Вторичный поиск: при отсутствии СНИЛС сопоставление выполняется по комбинации полей ФИО (Наименование) + ДатаРождения.
   3. Поиск по ИНН: в обменах на базе формата EnterpriseData также может задействоваться проверка по ИНН.
2. Справочник «Подразделения»:
   1. Поиск выполняется по связке Наименование + Головная организация / Владелец. При наличии сложной иерархии также может учитываться реквизит Родитель.

Где находятся правила обмена и как их скорректировать

Выясним причину, почему изменения в правилах внутри базы ЗУП 2.5 могут не оказывать влияния на загрузку в БП 3.0. В типовой конфигурации ЗУП правила выгрузки встроены в макет обработки Выгрузка данных в бухгалтерскую программу. При стандартном запуске используются именно встроенные правила.

Если нам необходимо переопределить алгоритмы поиска, выполним следующие шаги:

1. Сохраним макет правил обмена из ЗУП во внешний файл через конфигуратор или саму обработку выгрузки.
2. Откроем полученные правила в конфигурации 1С:Конвертация данных 2.1.
3. В правиле конвертации объекта (ПКО) ФизическиеЛица настроим обработчик «Поля поиска». Например, добавим нормализацию строк и обработку поиска только по ФИО, если СНИЛС или дата рождения не заполнены.
4. При выгрузке данных в ЗУП обязательно переключим режим обработки на «Использовать внешние правила обмена» и укажем путь к скорректированному XML-файлу.

Посмотрим на пример кода в обработчике «Поля поиска» для ПКО ФизическиеЛица в «Конвертации данных 2.1»:

// Очищаем входную строку наименования от лишних пробелов
ФИОПоиска = СокрЛП(СвойстваПоиска["Наименование"]);

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

Архитектурное решение проблемы дублирования

Разберем по шагам, как выстроить правильную схему ведения нормативно-справочной информации, чтобы исключить дублирование без постоянного редактирования правил:

1. Унификация реквизитов в существующих базах: перед синхронизацией убедимся, что для всех физических лиц в базах ЗУП и УТ заполнены реквизиты СтраховойНомерПФР и ДатаРождения. Наименования подразделений и организаций должны совпадать символ в символ.
2. Очистка и сопоставление дублей в БП: воспользуемся стандартной обработкой Поиск и удаление дублей в БП 3.0, объединив задвоенные элементы и выбрав в качестве основного элемент, пришедший из базы-мастера (ЗУП).
3. Разграничение зон ответственности систем:
   1. ЗУП назначается мастер-системой для сотрудников и кадровых подразделений. Все физические лица, являющиеся работниками, создаются исключительно в ЗУП.
   2. УТ является источником для физических лиц-контрагентов (покупателей, поставщиков).
   3. БП выступает консолидирующей базой, в которую стекаются данные из ЗУП и УТ.
4. Настройка сквозного обмена НСИ: организуем передачу физических лиц и подразделений по маршруту ЗУП → БП → УТ. При такой схеме в базу торговли сотрудники и подразделения попадают транзитом из БП, сохраняя исходные идентификаторы, что полностью предотвращает появление дублей.