Как избежать дублей физических лиц при синхронизации 11 баз 1С:Бухгалтерия и одной базы 1С:ЗУП?

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

Анализ архитектуры обмена: 11 баз БП к 1 базе ЗУП против 11 к 11

Перед тем как переходить к техническим настройкам, разберем стратегический вопрос: как лучше организовать связь? Существует два основных подхода:

1. Схема «11 БП / 1 ЗУП»: Все организации ведутся в одной базе зарплаты, которая обменивается данными с одиннадцатью отдельными бухгалтерскими базами. Это удобно для кадровиков и расчетчиков, так как они работают в «едином окне», видят общую отчетность по всем сотрудникам и могут легко оформлять переводы сотрудников между юрлицами.
2. Схема «11 БП / 11 ЗУП»: Для каждой бухгалтерии создается своя копия базы ЗУП. Это значительно упрощает синхронизацию, так как исключает риск «перемешивания» данных разных организаций, но катастрофически усложняет администрирование (11 обновлений вместо одного) и работу пользователей.

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

Почему возникают дубли: механизмы сопоставления EnterpriseData

Современный обмен в 1С (на платформе 8.3) работает через универсальный формат EnterpriseData. Рассмотрим, как система «узнает» объект при загрузке, если он уже существует в базе:

1. Уникальный идентификатор (GUID): Это самый надежный способ. Если объект был создан в одной базе и перенесен в другую через синхронизацию, он получает тот же GUID. Система всегда найдет его.
2. Поля поиска: Если идентификаторы не совпадают (например, физлицо было заведено вручную в обеих базах до настройки обмена), система ищет совпадения по ключевым реквизитам. Для справочника Физические лица это обычно Наименование (ФИО) + Дата рождения или ИНН/СНИЛС.

Проанализируем причину дублей в вашей ситуации: скорее всего, данные заводились «нестандартно», то есть вручную в разных базах. При первом обмене система не смогла найти соответствие по полям поиска (из-за лишнего пробела, буквы «ё» вместо «е» или отсутствия даты рождения) и создала новый объект. В последующем система может продолжать создавать дубли, если правила поиска игнорируют ИНН или СНИЛС.

Шаг 1. Настройка правил сопоставления по ИНН и СНИЛС

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

Необходимо убедиться, что в обеих базах (БП и ЗУП) заполнены поля ИНН и СНИЛС. Если эти поля заполнены корректно, вы можете доработать правила обмена (если используется нетиповая синхронизация) или использовать стандартную обработку сопоставления данных при первой синхронизации.

Важный совет: Сделайте ЗУП «мастер-системой» для справочника физлиц. Это означает, что все новые сотрудники должны заводиться только в ЗУП, а в БП они должны попадать исключительно через синхронизацию.

Шаг 2. Работа с регистром «Соответствия объектов информационных систем»

Мало кто знает, что 1С хранит связи между объектами разных баз в специальном техническом регистре. Разберем, как это работает. Когда вы впервые сопоставляете Иванова из ЗУП с Ивановым из БП, в этом регистре создается запись: [ID базы ЗУП] + [GUID Иванова в ЗУП] = [GUID Иванова в БП].

Если вы уже получили дубли, простое удаление лишнего физлица может не помочь — при следующем обмене оно прилетит снова. Нужно:

1. Использовать стандартную обработку «Поиск и удаление дублей» в каждой базе.
2. После слияния дублей проверить записи в регистре сведений Соответствия объектов информационных систем.
3. При необходимости очистить или перепривязать записи соответствий, чтобы база БП «запомнила» правильный идентификатор из ЗУП.

Шаг 3. Использование ГУИД для синхронизации

Рассмотрим метод, предложенный опытными разработчиками: принудительная синхронизация по внутреннему идентификатору. Если у вас уже есть 11 баз БП и 1 ЗУП, и вы хотите «подружить» их без дублей, можно пойти по пути программной перепривязки. Выясним алгоритм:

// Пример логики поиска соответствия по ИНН перед загрузкой
Функция НайтиФизЛицоПоИНН(ЗначениеИНН)
    Запрос = Новый Запрос;
    Запрос.Текст = 
        "ВЫБРАТЬ ССЫЛКА 
        |ИЗ Справочник.ФизическиеЛица 
        |ГДЕ ИНН = &ИНН";
    Запрос.УстановитьПараметр("ИНН", ЗначениеИНН);
    Результат = Запрос.Выполнить();
    Если Не Результат.Пустой() Тогда
        Выборка = Результат.Выбрать();
        Выборка.Следующий();
        Возврат Выборка.Ссылка;
    КонецЕсли;
    Возврат Неопределено;
КонецФункции

Если вы используете правила обмена, созданные в Конвертации данных 2.0, добавьте в ПКС (Поля Конвертации Свойств) для физлиц поиск по ИНН и СНИЛС, установив флаг «Поиск». Это заставит систему игнорировать различия в написании ФИО, если ИНН совпал.

Шаг 4. Настройка узлов синхронизации в ЗУП

В архитектуре «11 к 1» в базе ЗУП будет создано 11 настроек синхронизации (11 узлов). Проанализируем важный нюанс: чтобы физлица из Организации №1 не попадали случайно в базу БП Организации №2, в настройках каждого узла на стороне ЗУП необходимо выставить фильтр «По организациям».

Несмотря на то что справочник Физические лица является общим для всей базы, механизм EnterpriseData умеет отсекать тех лиц, которые не имеют отношения к документам конкретной организации, выбранной в фильтре узла. Это значительно уменьшит «информационный шум» и риск появления лишних записей в бухгалтерских базах.

Что делать, если дубли уже созданы?

Разберем по шагам план спасения базы, если синхронизация уже запущена и дубли расплодились:

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

Резюме по выбору решения

Переход на схему 11 БП / 11 ЗУП, к которому склонился автор темы, — это «капитуляция» перед технической сложностью. Да, это решит проблему дублей, но создаст огромные трудозатраты в будущем. Если организация планирует рост, лучше один раз настроить корректный поиск по ИНН/СНИЛС и навести порядок в регистре соответствий в схеме 11 БП / 1 ЗУП. Помните: GUID — это сердце синхронизации, а ИНН — ее главный предохранитель.