Перенос данных между двумя одинаковыми конфигурациями «1С:Зарплата и управление персоналом 3.1» — задача, которая часто встречается при разделении баз, создании новых филиалов или исправлении ошибок ведения учета. В отличие от простого копирования, перенос сотрудников требует понимания внутренней структуры программы, так как справочник Сотрудники тесно связан с физическими лицами, кадровой историей и персональными данными. Рассмотрим подробно, как осуществить этот процесс эффективно и без потерь.
Самым надежным инструментом для обмена данными между идентичными конфигурациями является универсальная обработка «Выгрузка и загрузка данных XML» (обычно используется версия для платформы 8.3). Проанализируем основные шаги по работе с этим инструментом:
Сотрудники. Важно понимать, что по умолчанию обработка настроена на выгрузку объектов вместе со связанными данными по ссылкам. Это означает, что при выборе сотрудника программа автоматически попытается выгрузить связанный элемент из справочника ФизическиеЛица.Разберем важный нюанс архитектуры ЗУП 3.1. В системе разделены понятия человека как субъекта (ФизическиеЛица) и человека как трудовой единицы (Сотрудники). У одного физического лица может быть несколько карточек сотрудников (например, при внутреннем совместительстве).
Проанализируем ситуацию: если мы выгрузим только справочник Сотрудники, система подтянет ссылку на ФизическиеЛица, но персональные данные (ИНН, СНИЛС, паспортные данные, адреса) могут не перенестись в полном объеме, так как они хранятся в независимых регистрах сведений. Поэтому при настройке выгрузки мы рекомендуем дополнительно отметить следующие регистры:
ФИОФизическихЛицПерсональныеДанныеФизическихЛицДокументыФизическихЛицАдресаУдельныхПодразделений (и другие части контактной информации)Часто стоит задача перенести не всю базу, а только актуальный штат. В стандартном интерфейсе обработки XML нет простого фильтра по статусу, но мы можем воспользоваться вкладкой «Дополнительные объекты для выгрузки» и режимом «Добавить запросом».
Рассмотрим алгоритм формирования запроса:
Сотрудники.КадроваяИсторияСотрудников.СрезПоследних.ВидСобытия <> ЗНАЧЕНИЕ(Перечисление.ВидыКадровыхСобытий.Увольнение).Пример логической схемы запроса для отбора работающих (на текущую дату):
ВЫБРАТЬ
Сотрудники.Ссылка КАК Ссылка
ИЗ
Справочник.Сотрудники КАК Сотрудники
ГДЕ
Сотрудники.Ссылка В
(ВЫБРАТЬ
КадроваяИсторияСотрудниковСрезПоследних.Сотрудник
ИЗ
РегистрСведений.КадроваяИсторияСотрудников.СрезПоследних КАК КадроваяИсторияСотрудниковСрезПоследних
ГДЕ
КадроваяИсторияСотрудниковСрезПоследних.ВидСобытия <> ЗНАЧЕНИЕ(Перечисление.ВидыКадровыхСобытий.Увольнение))
Выясним причину, по которой после обычного переноса справочника сотрудники в новой базе могут отображаться некорректно или не попадать в отчеты. Справочник — это лишь визуальная оболочка. Чтобы сотрудник «ожил» в программе, необходимо перенести данные регистров, которые определяют его состояние:
КадроваяИсторияСотрудников хранит данные о приемах, перемещениях и увольнениях. Без него программа не «поймет», в каком подразделении и на какой должности числится человек.ПлановыеНачисления.ТекущиеСтатусыСотрудников отвечает за быстрое отображение состояния (Работает, В отпуске, Уволен) в списках.Важный совет: При выгрузке данных по ссылкам (галочка «Выгружать с объектами по ссылкам») система потянет справочники Подразделения, Должности и ГрафикиРаботы. Если в базе-приемнике уже есть такие объекты с другими внутренними идентификаторами (GUID), могут возникнуть дубли.
Проанализируем техническую сторону: обработка XML сопоставляет объекты по их внутреннему UUID (GUID).
Сценарий А: База-приемник абсолютно пустая. В этом случае никаких проблем не возникнет — данные загрузятся как точная копия. Для реализации такой выгрузки можно использовать обработку для переноса данных в чистую базу ЗУП 3.1 на базе XML.
Сценарий Б: В базе-приемнике уже вручную созданы те же подразделения или даже физлица. В этом случае после загрузки через XML вы получите дубли. Например, будет два «Ивана Ивановича Иванова»: один созданный вами, другой — перенесенный из старой базы. С точки зрения программы это разные объекты, так как их GUID различаются.
Чтобы избежать этой проблемы, перед переносом рекомендуется либо очистить базу-приемник, либо предварительно синхронизировать справочники (например, с помощью обработки «Поиск и замена дублей» после загрузки).
Рассмотрим подробнее другой способ — использование «Универсального формата обмена» (EnterpriseData). Этот метод более современный и гибкий.
В отличие от XML-выгрузки, синхронизация через EnterpriseData позволяет настраивать правила сопоставления объектов. Например, можно указать, что физические лица должны сопоставляться по ИНН и СНИЛС, а не по внутреннему идентификатору. Это позволяет избежать дублирования данных, если в базах уже есть частично заполненная информация.
Посмотрим на ситуацию с контактной информацией. В ЗУП 3.1 адреса и телефоны хранятся в табличных частях справочника ФизическиеЛица (или Сотрудники, в зависимости от версии и настроек) в специальном формате. При использовании обработки ВыгрузкаЗагрузкаДанныхXML83 обязательно проверьте настройки выгрузки табличных частей. Если вы используете фильтрацию запросом, убедитесь, что в выборку попадают все необходимые вложенные данные, иначе поля адреса после загрузки могут оказаться пустыми.
Подводя итог, выделим оптимальный план действий для успешного переноса сотрудников:
ВыгрузкаЗагрузкаДанныхXML83.epf для максимально полного переноса данных.КадроваяИсторияСотрудников.Такой комплексный подход гарантирует, что справочник Сотрудники будет перенесен корректно, а данные в новой базе будут пригодны для дальнейшего кадрового учета и расчета заработной платы. Для комплексного переноса сведений о стаже, остатках отпусков и данных среднего заработка можно использовать обработку для переноса данных и остатков по сотрудникам между базами ЗУП 3.1.