Как организовать обмен кадровыми данными между 1С:УПП 1.3 и 1С:ЗУП 3.1

← На главную

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

Вариант 1. Использование «Конвертации данных 2.0» (КД2)

Несмотря на появление более новых технологий, Конвертация данных 2.0 остается самым востребованным инструментом для связи УПП и ЗУП 3.1. Разберем, почему этот метод до сих пор актуален. КД2 позволяет гибко настроить соответствие полей (ПКС) и правила поиска объектов (ПКО), что критично при несовпадении структур метаданных.

Рассмотрим основные этапы настройки:

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

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

Вариант 2. Универсальный формат обмена EnterpriseData (КД3)

Многие разработчики ошибочно полагают, что в УПП нет поддержки EnterpriseData. Однако в современных релизах УПП присутствует модуль МенеджерОбменаЧерезУниверсальныйФормат. Рассмотрим, как это работает.

Проанализируем ситуацию: обмен через универсальный формат в УПП реализован преимущественно для связи с 1С:Бухгалтерией 3.0, но его можно адаптировать. Основная проблема заключается в том, что в старых версиях формата (например, 1.8), поддерживаемых УПП, могут отсутствовать некоторые кадровые объекты, появившиеся в новых версиях формата (1.13+), используемых в ЗУП 3.1.

Посмотрим на фрагмент кода в модуле менеджера обмена, который отвечает за сопоставление:


Процедура ПриОтправкеДанных(ДанныеИБ, ДанныеXDTO, КомпонентыОбмена)
    Если ТипЗнч(ДанныеИБ) = Тип("ДокументОбъект.ПриемНаРаботуВОрганизацию") Тогда
        // Здесь выполняется ручное наполнение свойств XDTO объекта
        // в соответствии со схемой EnterpriseData
    КонецЕсли;
КонецПроцедуры

Выясним причину избыточности XML при использовании этого формата. Как было замечено в обсуждении, EnterpriseData дублирует ключевые поля поиска (ФИО, Дата рождения) внутри узлов ссылок. Это нормальное поведение формата, обеспечивающее возможность поиска или создания объекта в приемнике без наличия полной информации о нем в основном пакете данных.

Вариант 3. Метод «Мимикрии» под ЗУП 2.5

Один из самых оригинальных и эффективных способов — использование типового помощника перехода, встроенного в ЗУП 3.1. Поскольку подсистема кадрового учета в УПП 1.3 практически идентична ЗУП 2.5, мы можем использовать штатную обработку выгрузки данных из ЗУП 2.5.

Разберем алгоритм действий:

Возьмем обработку ВыгрузкаДанныхДляПереходаНаЗУП3.epf (идет в комплекте с дистрибутивом ЗУП 3).
Запустим ее в базе УПП. В некоторых случаях потребуется минимальная корректировка кода обработки, чтобы она «узнала» конфигурацию УПП как ЗУП 2.5.
Выгрузим данные в файл. Этот метод идеален для первоначального переноса всей истории кадровых документов и справочников.
Для последующего регулярного обмена этот метод менее удобен, так как он предназначен для разового перехода, но его можно адаптировать для периодической выгрузки новых документов.

Вариант 4. HTTP-сервисы и REST API

Если требуется «живой» обмен (например, чтобы при создании приказа в ЗУП он мгновенно появлялся в УПП для планирования производства), рассмотрим вариант с HTTP-сервисами. В ЗУП 3.1 на базе БСП создать HTTP-сервис гораздо проще, чем в УПП.

Схема взаимодействия может выглядеть так:

В ЗУП 3.1 создается HTTP-сервис с методом POST, принимающий JSON с данными сотрудника или документа.
В УПП в модуле объекта документа (например, ПриемНаРаботуВОрганизацию) в процедуре ПослеЗаписи прописывается код отправки данных.

Пример кода для отправки данных из УПП через HTTP:


Соединение = Новый HTTPСоединение("server_zup", , "user", "pass");
Запрос = Новый HTTPЗапрос("/zup_base/hs/integration/v1/employee");
Запрос.УстановитьТелоИзСтроки(ДанныеВФорматеJSON, КодировкаТекста.UTF8);
Ответ = Соединение.ОтправитьДляОбработки(Запрос);
Если Ответ.КодСостояния <> 200 Тогда
    ЗаписьЖурналаРегистрации("Обмен", УровеньЖурналаРегистрации.Ошибка, , , "Ошибка передачи: " + Ответ.ПолучитьТелоИзСтроки());
КонецЕсли;

Проблема мастер-системы и синхронизации Физлиц

Важно решить, какая система будет мастер-системой для кадровых данных. Если кадровики работают в ЗУП, а УПП используется только как приемник для отражения затрат и формирования доверенностей, необходимо настроить запрет редактирования загруженных данных в УПП.

Особое внимание уделим справочнику ФизическиеЛица. Проанализируем ситуацию с дублями: при обмене между УПП и ЗУП 3.1 часто возникают дубли из-за разного заполнения ФИО или несовпадения уникальных идентификаторов (GUID). Мы рекомендуем настроить поиск исключительно по СНИЛС, так как это единственный действительно уникальный идентификатор физического лица в РФ, не меняющийся при смене фамилии или паспорта.

Рассмотрим типичный сценарий сопоставления в КД2:

В ПКО ФизическиеЛица установим поиск по свойству СтраховойНомерПФР.
В обработчике ПоляПоиска пропишем логику: если СНИЛС не заполнен, искать по комбинации ФИО + Дата рождения.
Обязательно включим флаг «Продолжить поиск по остальным полям, если по текущему не найдено».

Заключение

Подводя итоги, можно сказать, что для разового переноса истории лучше всего подходит модифицированный помощник перехода из ЗУП 2.5. Для регулярного обмена наиболее стабильным и гибким решением остается Конвертация данных 2.0 с использованием планов обмена. Использование КД3 (EnterpriseData) в связке с УПП возможно, но потребует серьезных трудозатрат на доработку менеджера обмена на стороне УПП из-за различий в версиях формата. Выбирайте решение исходя из ваших ресурсов и требований к оперативности передачи данных.