Первичная синхронизация ЗУП 3.1 и БП 3.0: как не потерять данные и правильно сопоставить объекты?

При настройке обмена между конфигурациями «Зарплата и управление персоналом 3.1» (ЗУП) и «Бухгалтерия предприятия 3.0» (БП) один из самых острых вопросов — это сохранность данных в принимающей базе. Часто возникает ситуация, когда в обеих базах уже накоплены сведения (например, об организациях, контрагентах или физических лицах), и при первом обмене велик риск получить дубли или, что еще опаснее, некорректное обновление реквизитов. Разберем детально, как работает этот механизм, в каком порядке система ищет объекты и как предотвратить нежелательное перезатирание информации.

Механизм поиска и приоритет сопоставления объектов

В современных типовых решениях 1С, работающих на платформе 8.3, используется формат обмена Enterprise Data. В отличие от старых правил обмена (КД 2.0), здесь логика поиска объектов жестко зашита в механизмы платформы и программный код конфигурации. Проанализируем иерархию поиска, которая применяется при получении данных:

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

Будут ли перезатерты данные: кейс «Ромашка» и «Василек»

Рассмотрим классическую ситуацию: в ЗУП организация называется «Ромашка», а в БП та же самая организация по каким-то причинам заведена как «Василек» (но ИНН совпадает). Вы запускаете первичную синхронизацию.

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

Важный вывод: при синхронизации ЗУП -> БП «главной» базой считается ЗУП. Все справочные данные, которые приходят из зарплатной базы, имеют приоритет. Если в ЗУП данные заполнены небрежно, они испортят качественные данные в БП.

Как настроить односторонний обмен и защитить данные

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

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

// В правилах регистрации для конкретного объекта
// или в общем обработчике для всех объектов
Отказ = Истина;

Однако стоит помнить, что даже если вы запретили выгрузку через Отказ = Истина, система все равно будет обмениваться служебными сообщениями и квитанциями (подтверждениями получения пакетов). Чтобы полностью исключить влияние БП на справочники в ЗУП, проанализируем следующие шаги:

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

Риски при работе со справочниками «Физические лица» и «Сотрудники»

Проанализируем наиболее критичный момент обмена. В ЗУП 3.1 основная работа ведется в справочнике Сотрудники, но в БП 3.0 вся аналитика на счетах учета зарплаты (70, 68, 69) строится в разрезе справочника Физические лица.

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

• Проводки в документе «Отражение зарплаты» лягут на новое физлицо (созданное обменом).
• Выплаты (ведомости) в БП могут быть привязаны к старому физлицу.
• Взаиморасчеты по 70 счету «разъедутся», и в оборотно-сальдовой ведомости вы увидите развернутое сальдо.

Практические рекомендации по проведению первичного обмена

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

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

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