При настройке интеграции между конфигурациями 1С:Зарплата и управление персоналом КОРП (ЗУП) и 1С:Производственная безопасность (ПБ) версии 1.1 пользователи часто сталкиваются с ситуацией, когда справочники и большинство документов синхронизируются успешно, но регистр Кадровая история сотрудников остается пустым. Это критическая проблема, так как без истории перемещений невозможно корректно учитывать данные по охране труда и промышленной безопасности. Рассмотрим подробно, почему это происходит и как исправить ситуацию.
Проанализируем структуру хранения данных в конфигурации Производственная безопасность. В этой системе регистр Кадровая история сотрудников тесно завязан на объектах штатного расписания. Если в настройках синхронизации вы не выбрали выгрузку штатного расписания или если позиции штатного расписания не сопоставились (например, из-за различий в иерархии подразделений или кодах должностей), записи в кадровой истории будут игнорироваться при загрузке. Выясним, перенесены ли актуальные позиции штатного расписания в базу ПБ, прежде чем приступать к отладке самого регистра.
Интеграция между современными конфигурациями 1С строится на универсальном формате Enterprise Data. В релизах ЗУП 3.1.23 и выше используются обновленные версии формата (например, 1.13). Однако «1С:Производственная безопасность» версии 1.1 — это достаточно старая редакция, которая может работать на версии формата 1.3 или 1.5. Разберем, к чему это приводит: в новых версиях формата структура передачи кадровых изменений была оптимизирована, и принимающая сторона (старая ПБ) просто «не видит» входящие узлы с историей. Попробуем в настройках синхронизации на стороне ЗУП принудительно установить более низкую версию формата (например, 1.8), которую гарантированно поддерживают обе системы.
Даже при идеально настроенных правилах данные не попадут в пакет выгрузки, если они не зарегистрированы к обмену. Проверим этот момент по шагам:
Кадровая история сотрудников.Для принудительной регистрации воспользуемся стандартной обработкой Регистрация изменений для обмена. Выберем нужный регистр и нажмем Зарегистрировать изменения всех объектов выбранных типов. Это заставит систему включить все записи регистра в следующий пакет выгрузки.
Выясним важный нюанс версии КОРП: в ней реализовано разделение на регламентированный (кадровые приказы согласно ТК РФ) и управленческий учет. Типовые планы обмена часто настроены на передачу только регламентированных данных. Если в вашей организации кадровые перемещения оформляются документами управленческого учета, они могут игнорироваться правилами выгрузки. Проанализируем настройки фильтрации в плане обмена: нет ли там ограничений по типам документов или по конкретным организациям, которые могли отсечь данные истории.
В конфигурации 1С:ПБ записи в кадровой истории часто не являются самостоятельными объектами при загрузке, а формируются на основании документов Прием на работу, Кадровый перевод и Увольнение. Разберем ситуацию: если вы решили сэкономить трафик и отключили выгрузку этих документов, надеясь перенести только «голый» регистр, то в принимающей базе записи истории просто не будут созданы. Обязательно включим указанные кадровые документы в состав обмена.
Если вышеперечисленные методы не помогли, перейдем к методам для разработчиков. Нам нужно понять, на каком этапе «пропадают» данные: при выгрузке из ЗУП или при загрузке в ПБ. Для этого в ЗУП найдем процедуру ПриОтправкеДанных в модуле плана обмена или в соответствующей обработке выгрузки. Поставим точку останова на проверке типа выгружаемого объекта.
Рассмотрим пример кода для отладки:
Процедура ПриОтправкеДанных(ЭлементДанных, ОтправкаЭлемента)
// Проверяем, является ли текущий элемент записью нужного регистра
Если ТипЗнч(ЭлементДанных) = Тип("РегистрСведенийЗапись.КадроваяИсторияСотрудников") Тогда
// Здесь можно посмотреть структуру ЭлементДанных и понять, почему он может быть проигнорирован
Сообщить("Выгружаем историю для сотрудника: " + ЭлементДанных.Сотрудник);
КонецЕсли;
КонецПроцедуры
Если при выполнении синхронизации отладчик не заходит в это условие, значит, записи либо не зарегистрированы, либо отсекаются программными фильтрами (например, проверка на дату запрета загрузки или соответствие префиксам организации). Если же данные уходят, но не появляются в ПБ, следует проверить Журнал регистрации в принимающей базе — там могут содержаться ошибки о невозможности сопоставить Физическое лицо или Сотрудник из-за несовпадения уникальных идентификаторов (GUID).
Напоследок проанализируем версию программного продукта. Редакция 1.1 является устаревшей. В последних релизах ЗУП 3.1.23+ существенно изменилась логика работы с кадровыми данными (внедрение периодов, работа с электронными трудовыми книжками и т.д.). Старая конфигурация ПБ может быть просто не готова к такой структуре данных. В этом случае единственным надежным решением будет либо обновление ПБ до актуальной редакции (например, 2.1 или 3.0), либо ручная доработка правил обмена (файла xml), чтобы сопоставить новые поля ЗУП со старыми полями ПБ.