В практике автоматизации кадрового учета часто возникает специфическая задача: обеспечить постоянный или временный обмен данными между версиями 1С:Зарплата и управление персоналом ПРОФ и КОРП. Обычно это продиктовано необходимостью параллельного ведения регламентированного (официального) учета в одной базе и управленческого учета в другой. Несмотря на внешнюю схожесть конфигураций, штатные механизмы синхронизации часто оказываются недостаточными для полноценного переноса кадровой истории.
В данной статье мы подробно разберем, почему стандартные средства обмена работают ограниченно, проанализируем технические различия между версиями и рассмотрим эффективные способы реализации синхронизации кадровых документов и справочников.
Рассмотрим стандартный механизм «Синхронизация данных» в линейке 1С 8.3. Он базируется на универсальном формате EnterpriseData. Основная цель этого формата — передача данных для бухгалтерского и налогового учета в 1С:Бухгалтерию или 1С:ERP. Для этих целей важны итоговые суммы, сведения о выплатах и налогах.
Однако для полноценного «зеркалирования» кадровой базы этого недостаточно. Выясним основные причины «бедности» штатного обмена:
EnterpriseData документы ПриемНаРаботу, КадровыйПеревод и Увольнение часто передаются в усеченном виде или игнорируются, так как принимающей стороне (например, Бухгалтерии) не нужна полная история перемещений сотрудника для формирования проводок.Проанализируем ситуацию, описанную в теме. Если задача стоит в том, чтобы просто начать работать в КОРП, сохранив данные из ПРОФ, оптимальным решением будет штатный переход. Это не синхронизация, а апгрейд базы. Процедура выполняется путем обновления конфигурации ПРОФ файлом конфигурации (cf) КОРП соответствующего релиза. В этом случае все данные сохраняются, а дополнительные возможности КОРП просто становятся доступными.
Если же требуется именно постоянный обмен (односторонний или двусторонний), нам придется прибегнуть к разработке собственных правил обмена.
Это классический путь, который выбрал автор темы. Метод заключается в создании правил обмена (xml-файл), которые описывают сопоставление объектов двух баз. Разберем основные этапы и способы оптимизации этого процесса:
При настройке правил для Справочник.Сотрудники и Справочник.ФизическиеЛица крайне важно настроить поиск по Уникальному Идентификатору (GUID). Если базы создавались независимо, придется настраивать поиск по полям ИНН и СНИЛС.
Чтобы ускорить работу правил в КД 2.0, рекомендуем минимизировать использование обработчиков «При загрузке» и «После загрузки», которые выполняют тяжелые запросы к базе. Посмотрим на пример кода в обработчике «Перед выгрузкой», который может замедлять процесс при неправильном использовании:
// Неоптимальный поиск данных внутри цикла выгрузки
Запрос = Новый Запрос;
Запрос.Текст = "ВЫБРАТЬ Ссылка ИЗ Справочник.Сотрудники ГДЕ Код = &Код";
Запрос.УстановитьПараметр("Код", Источник.Код);
// ... выполнение запроса для каждого объекта
Вместо этого старайтесь передавать все необходимые данные через входящие параметры или выгружать связанные объекты целиком.
Если обмен через КД 2.0 работает слишком медленно, проанализируем возможности Конвертации данных 3.0. В отличие от версии 2.0, она работает с форматом XDTO, что дает ряд преимуществ:
Для ускорения «тяжелых» обменов (например, при переносе документов за несколько лет) эффективнее использовать прямое соединение между базами. Это исключает промежуточный этап записи данных в файл на диске.
Рассмотрим пример функции для создания COM-соединения из базы ПРОФ к базе КОРП:
Функция УстановитьСоединениеСБазойКОРП(ПараметрыСоединения)
Connector = Новый COMObject("V83.COMConnector");
СтрокаСоединения = "Srvr=""" + ПараметрыСоединения.Сервер + """;Ref=""" + ПараметрыСоединения.База + """;Usr=""" + ПараметрыСоединения.Пользователь + """;Pwd=""" + ПараметрыСоединения.Пароль + """;";
Попытка
Connection = Connector.Connect(СтрокаСоединения);
Возврат Connection;
Исключение
Сообщить("Ошибка подключения: " + ОписаниеОшибки());
Возврат Неопределено;
КонецПопытки;
КонецФункции
Используя такое соединение, мы можем напрямую обращаться к метаданным КОРП, создавать документы и заполнять их реквизиты, читая данные из текущей базы ПРОФ.
При постоянной синхронизации между ЗУП ПРОФ и ЗУП КОРП возникает серьезный риск появления дублей. Выясним причину: в зарплатных конфигурациях объекты Сотрудники и ФизическиеЛица тесно связаны. Если в базе КОРП сотрудник уже заведен вручную, а из ПРОФ прилетает тот же сотрудник с другим GUID, система создаст дубль.
Рекомендации по предотвращению дублей:
ФизическиеЛица это самый надежный уникальный ключ.УникальныйИдентификатор, что гарантирует связность объектов при последующих обменах.Подведем итог нашему анализу. Построение полноценного обмена между ЗУП ПРОФ и ЗУП КОРП — это всегда кастомная задача, не имеющая «коробочного» решения для всех кадровых документов.
Если вам необходимо быстро синхронизировать кадровый состав, разберем краткий алгоритм действий:
Помните, что ведение параллельного учета в двух разных редакциях ЗУП требует жесткого административного контроля за вводом справочной информации, иначе сопоставление цифр в конце месяца превратится в бесконечный поиск расхождений из-за дублирующихся записей.