← На главную

При настройке взаимодействия между конфигурациями «Зарплата и управление персоналом», редакция 2.5 и «Бухгалтерия предприятия», редакция 3.0 часто возникает вопрос: каким образом программа сопоставляет элементы справочника ФизическиеЛица? Это особенно критично в режиме, когда учет расчетов по заработной плате и кадровый учет ведутся во внешней программе.

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

Ключевые поля сопоставления при первом обмене

Выясним, как работает типовой алгоритм поиска объектов в базовых правилах конвертации. При выполнении первой синхронизации, когда уникальный идентификатор (УИД / GUID) между объектами двух баз еще не установлен, система производит поиск по следующей комбинации реквизитов:

1. ЭтоГруппа — флаг, определяющий, является ли элемент папки или отдельной карточкой физлица;
2. Наименование — полное ФИО физического лица в текстовом виде;
3. ДатаРождения — дата рождения физического лица.

Сочетание ФИО и даты рождения является достаточно уникальным для корректного сопоставления большинства записей. Если элемент с такими данными находится в приемнике («Бухгалтерия предприятия 3.0»), программа привязывает к нему переносимую карточку из «ЗУП 2.5».

Почему ИНН и СНИЛС не используются как первичные ключи

У многих специалистов возникает вопрос: почему стандартный обмен не ищет физлиц по кодам ИНН или СтраховойНомерПФР (СНИЛС)? Проанализируем причину такого решения разработчиков 1С:

1. Необязательность занесения: ИНН и СНИЛС могут отсутствовать в карточке на момент приема сотрудника на работу или первичной выгрузки данных.
2. Задержка ввода персональных данных: Если бы поиск базировался на ИНН/СНИЛС, то при отсутствии этих реквизитов в одной из баз программа создавала бы дубли или выдавала ошибки сопоставления.

Дальнейшая синхронизация и привязка по УИД

Посмотрим, что происходит после успешного проведения первого обмена. Как только элемент перенесен и сопоставлен, система запоминает его уникальный идентификатор (УИД/GUID).

При всех последующих обменах поиск происходит строго по УИД. Это означает, что если сотрудница выйдет замуж и сменит фамилию, изменения, внесенные в «ЗУП 2.5», автоматически обновят карточку в «БП 3.0» без создания дублирующих записей.

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

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

1. Ручной ввод данных в БП 3.0: Если создать физлицо вручную в бухгалтерской базе до обмена и допустить опечатку в ФИО (разный регистр, буква «ё», пробелы), первичный поиск по Наименованию не сработает, и программа создаст новую карточку.
2. Изменение персональных данных до первого обмена: Если фамилию или дату рождения изменили до того, как установилась связь по УИД, сопоставить записи не удастся.

Для исправления сложившейся ситуации и предотвращения дублирования рекомендуется придерживаться следующего порядка действий:

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

2. Использование стандартной обработки поиска дублей
Если дубли уже появились в базе «БП 3.0», откройте раздел Администрирование -> Обслуживание -> Корректировка данных и запустите обработку Поиск и удаление дублей. В качестве эталонного элемента выберите карточку, пришедшую из ЗУП, и слейте с ней дублирующие записи.

3. Доработка правил обмена в Конвертации Данных
При необходимости строгого сопоставления по ИНН или СНИЛС (например, если в базах много однофамильцев) выгрузите правила обмена, откройте их в конфигурации 1С:Конвертация данных 2.0 и в правиле конвертации объектов (ПКО) для справочника ФизическиеЛица установите флаги поиска по реквизитам ИНН или СтраховойНомерПФР.