Как перенести данные сотрудника из одной базы ЗУП 2.5 КОРП в другую при несовпадении ГУИДов и смене статуса на «Прием на работу»

В практике сопровождения «1С:Зарплата и управление персоналом 2.5 КОРП» часто возникает задача межбазового обмена. Типичный сценарий: сотрудник увольняется в одной информационной базе (источнике) и принимается на работу в другую (приемник). Сложность заключается в том, что базы велись независимо, и внутренние идентификаторы (GUID) одних и тех же физических лиц не совпадают. В этой статье мы разберем, как автоматизировать этот процесс, избежать дублирования данных и корректно трансформировать кадровые события.

Анализ проблемы: почему стандартная выгрузка XML может не подойти

Если мы воспользуемся стандартной обработкой ВыгрузкаЗагрузкаДанныхXML.epf, система будет пытаться сопоставить объекты исключительно по их внутренним идентификаторам. Поскольку наши базы идентичны по структуре, но имеют «разную историю» создания элементов, загрузка приведет к созданию дублей справочников ФизическиеЛица, Сотрудники, а также нормативно-справочной информации (НСИ), такой как Должности и Подразделения.

Разберем, какие инструменты и методики позволят нам решить задачу элегантно и без «ручного» ввода данных.

Решение 1: Использование «Конвертации данных 2.1» (КД)

Это наиболее профессиональный и гибкий метод. Рассмотрим пошагово, как настроить правила конвертации объектов (ПКО) для нашей ситуации.

Шаг 1. Сопоставление физических лиц

Так как ГУИДы разные, единственным надежным ключом связи будут персональные данные. Проанализируем настройки поиска в ПКО для справочника ФизическиеЛица. Нам необходимо снять флаг «Искать объект по внутреннему идентификатору» и установить флаги «Продолжить поиск по полям поиска, если по идентификатору объект не найден».

В качестве полей поиска рекомендуется использовать комбинацию:

• ИНН
• СтраховойНомерПФР (СНИЛС)

Если данные заполнены не у всех, добавим второстепенное правило поиска по Наименованию (ФИО) и ДатеРождения. Это гарантирует, что система найдет существующее физлицо в базе-приемнике и привяжет к нему нового сотрудника.

Шаг 2. Создание нового сотрудника

Важно помнить, что в ЗУП 2.5 справочники ФизическиеЛица и Сотрудники — это разные сущности. Один человек (физлицо) может иметь несколько карточек сотрудников (например, при внутреннем совместительстве или повторном приеме). Для корректного создания сотрудника в приемнике, настроим ПКО для справочника СотрудникиОрганизаций, используя поиск по:

• Физлицо (которое мы уже сопоставили на предыдущем шаге)
• Организация
• ТабельныйНомер (если политика нумерации совпадает)

Шаг 3. Трансформация документа «Увольнение» в «Прием на работу»

Проанализируем ситуацию: в источнике у нас есть документ УвольнениеИзОрганизаций, а в приемнике нам нужен ПриемНаРаботуВОрганизацию. Напрямую перенести реквизиты не получится из-за разной структуры. Рассмотрим программный подход в КД:

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

Пример кода в обработчике ПВД (схематично):

// Создаем структуру для передачи данных в ПКО Приема на работу
СвойстваПриема = Новый Структура;
СвойстваПриема.Вставить("Дата", Объект.ДатаУвольнения + 86400); // +1 день
СвойстваПриема.Вставить("Организация", Объект.Организация);
СвойстваПриема.Вставить("ФизЛицо", Объект.Сотрудник.Физлицо);
// Вызываем выгрузку по правилу для Приема на работу
ВыгрузитьПоПравилу(Объект, , СвойстваПриема, , "ПриемНаРаботуВОрганизацию");

Решение 2: Синхронизация НСИ и классификаторов

При переносе мы неизбежно столкнемся с перечислениями и справочниками. Рассмотрим, как избежать ошибок:

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

Решение 3: Универсальная выгрузка XML с фильтром

Если бюджет времени ограничен, и вы не хотите писать сложные правила в КД, разберем вариант с ВыгрузкаЗагрузкаДанныхXML.epf. Чтобы выгрузить не всех сотрудников, а конкретных 6-10 человек, выполним следующие действия:

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

Альтернативный путь: Загрузка из табличного документа

Проанализируем ситуацию, когда сотрудников мало (до 10 в месяц). Иногда проще и быстрее использовать стандартную обработку «Загрузка данных из табличного документа»:

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

Этот метод исключает технические сложности с КД 2.1 и гарантирует, что вы не перенесете «лишние» системные данные.

Итоги и рекомендации

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

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

Важный совет: При настройке поиска по наименованию в КД всегда используйте функцию СокрЛП() в обработчиках, чтобы исключить ошибки из-за случайных пробелов в строковых данных.