В процессе администрирования и сопровождения конфигурации «1С:Зарплата и управление персоналом 3.1» (ЗУП 3.1) специалисты часто сталкиваются с загадочным исчезновением ключевых данных. Одной из типичных проблем является внезапная пропажа или изменение стажей сотрудников. Поскольку данные о стажах напрямую влияют на расчет больничных листов и пособий, оперативное выявление причин их изменения становится первоочередной задачей.
В этой статье мы подробно разберем, как устроено хранение стажей в системе, почему стандартный механизм версионирования конфигурации не отображает регистры сведений, и рассмотрим три практических метода решения этой проблемы: от использования встроенных платформенных механизмов до создания быстрого логирования изменений через расширение конфигурации.
Прежде чем приступать к отслеживанию изменений, выясним структуру хранения этих данных в базе. В конфигурации ЗУП 3.1 сведения о стажах (страховой стаж, общий стаж, стаж работы на севере и другие виды) жестко привязаны к физическому лицу. Они хранятся в независимом периодическом регистре сведений РегистрСведений.СтажиФизическихЛиц. Этот регистр имеет следующую структуру:
ФизическоеЛицо (ссылка на справочник Справочники.ФизическиеЛица) и ВидСтажа (ссылка на справочник Справочники.ВидыСтажа).ДатаОтсчета (дата, с которой начинается отсчет стажа), РазмерМесяцев и РазмерДней (исходный размер стажа на дату отсчета).Когда пользователь вносит изменения в карточке сотрудника по ссылке «Трудовая деятельность», система производит перезапись набора записей в этом регистре сведений по конкретному физическому лицу.
При переходе в меню «Администрирование — Общие настройки — История изменений» пользователи и администраторы видят список справочников и документов, для которых можно включить запись версий. Однако независимых регистров сведений в этом списке нет. Проанализируем, почему так происходит.
Типовой механизм «Версионирование объектов», входящий в состав Библиотеки стандартных подсистем (БСП), ориентирован исключительно на работу с ссылочными типами данных (справочники, документы). Вся история версий записывается в регистр сведений РегистрСведений.ВерсииОбъектов, где ведущее измерение Объект имеет тип ссылки. Поскольку отдельная запись или набор записей независимого регистра сведений не обладает уникальной ссылкой (UUID), механизм БСП технически не может хранить их истории «из коробки».
Для решения этой задачи нам потребуется прибегнуть к альтернативным методам.
Начиная с версии платформы 1С:Предприятие 8.3.11, разработчикам доступен мощный встроенный механизм — «История данных». В отличие от версии БСП, этот механизм реализован на уровне СУБД самой платформой и умеет работать с любыми таблицами базы данных, включая независимые регистры сведений.
Выясним по шагам, как активировать этот инструмент для отслеживания изменений стажа:
РегистрыСведений и выберите СтажиФизическихЛиц. В палитре свойств этого регистра найдите свойство «История данных» и установите для него значение «Использовать».СтажиФизическихЛиц отмечены права:
Чтение истории данныхПросмотр истории данныхОбновление истории данных
МенеджерИстории = ИсторияДанных.СоздатьМенеджер(Метаданные.РегистрыСведений.СтажиФизическихЛиц);
// Далее производится выборка версий по конкретному ключу записи
Если вам требуется мгновенный результат без изменения структуры метаданных и разворачивания тяжелых механизмов хранения версий, самым надежным решением станет перехват события записи в модуле набора записей регистра с фиксацией изменений в системном Журнале регистрации.
Для реализации этого метода мы создадим расширение конфигурации и добавим в него обработчик события ПередЗаписью для регистра сведений СтажиФизическихЛиц. Рассмотрим пример реализации кода, который сравнивает записываемые данные с уже существующими в базе и детально логирует факт удаления или изменения стажа:
&Вместо("ПередЗаписью")
Процедура Расш1_ПередЗаписью(Отказ, Замещение)
// Если запись производится с замещением, проанализируем старые данные
Если Замещение Тогда
Для Каждого ЗаписьНовая Из ЭтотОбъект Цикл
// Сформируем запрос для получения текущего состояния записи в базе
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ
| Стажи.ДатаОтсчета КАК ДатаОтсчета,
| Стажи.РазмерМесяцев КАК РазмерМесяцев,
| Стажи.РазмерДней КАК РазмерДней
|ИЗ
| РегистрСведений.СтажиФизическихЛиц КАК Стажи
|ГДЕ
| Стажи.ФизическоеЛицо = &ФизическоеЛицо
| И Стажи.ВидСтажа = &ВидСтажа";
Запрос.УстановитьПараметр("ФизическоеЛицо", ЗаписьНовая.ФизическоеЛицо);
Запрос.УстановитьПараметр("ВидСтажа", ЗаписьНовая.ВидСтажа);
РезультатЗапроса = Запрос.Выполнить();
Если Не РезультатЗапроса.Пустой() Тогда
Выборка = РезультатЗапроса.Выбрать();
Выборка.Следующий();
// Проверим, изменились ли данные стажа
Если Выборка.ДатаОтсчета <> ЗаписьНовая.ДатаОтсчета
Или Выборка.РазмерМесяцев <> ЗаписьНовая.РазмерМесяцев
Или Выборка.РазмерДней <> ЗаписьНовая.РазмерДней Тогда
ТекстЛога = ШаблонФМ(
"Изменен стаж по физ. лицу: %1. Вид стажа: %2. Старые значения: %3 (Месяцев: %4, Дней: %5). Новые значения: %6 (Месяцев: %7, Дней: %8)",
ЗаписьНовая.ФизическоеЛицо,
ЗаписьНовая.ВидСтажа,
Выборка.ДатаОтсчета, Выборка.РазмерМесяцев, Выборка.РазмерДней,
ЗаписьНовая.ДатаОтсчета, ЗаписьНовая.РазмерМесяцев, ЗаписьНовая.РазмерДней
);
ЗаписьЖурналаРегистрации(
"ИзменениеСтажаСотрудника",
УровеньЖурналаРегистрации.Предупреждение,
Метаданные.РегистрыСведений.СтажиФизическихЛиц,
,
ТекстЛога
);
КонецЕсли;
КонецЕсли;
КонецЦикла;
// Обработка ситуации полного удаления записей по физлицу
Если ЭтотОбъект.Количество() = 0 И ЭтотОбъект.Отбор.ФизическоеЛицо.Использование Тогда
ФизЛицоОтбор = ЭтотОбъект.Отбор.ФизическоеЛицо.Значение;
ТекстЛогаОчистки = "Произведено удаление или полная очистка записей о стажах по физическому лицу: " + СокрЛП(ФизЛицоОтбор);
ЗаписьЖурналаРегистрации(
"УдалениеСтажаСотрудника",
УровеньЖурналаРегистрации.Предупреждение,
Метаданные.РегистрыСведений.СтажиФизическихЛиц,
,
ТекстЛогаОчистки
);
КонецЕсли;
КонецЕсли;
// Вызов оригинального обработчика события
ПродолжитьВызов(Отказ, Замещение);
КонецПроцедуры
Этот простой алгоритм гарантирует, что любое интерактивное или программное изменение записей о стажах мгновенно отразится в Журнале регистрации с фиксацией автора изменений, времени и компьютера, с которого была выполнена операция.
Если вы хотите использовать исключительно типовой интерфейс БСП «История изменений» без написания сложных обработок просмотра истории, можно применить архитектурный обходной путь.
Поскольку записи регистра СтажиФизическихЛиц логически подчинены элементам справочника ФизическиеЛица, мы можем искусственно вызывать запись новой версии справочника при любом изменении его стажей. Для этого:
ПриЗаписи регистра сведений СтажиФизическихЛиц в расширении.
// Пример программного создания версии объекта БСП
Справочники.ФизическиеЛица.ЗаписатьВерсиюОбъекта(ФизическоеЛицо);
При сравнении версий физического лица в стандартном отчете БСП вы увидите, что в момент изменения записей в подчиненном регистре была зафиксирована новая версия карточки физлица с указанием автора изменений.
Проанализируем ситуацию, когда пользователи утверждают, что не удаляли стаж. В ЗУП 3.1 существует ряд фоновых автоматических процессов, способных непреднамеренно перезаписывать или очищать данные регистра сведений:
Перенос данных расчет стажей может быть привязан к кадровой истории. Повторное перепроведение документов ввода начальных остатков или исправление кадровых приказов задним числом может запустить фоновые процедуры пересчета стажей, перезаписывая ручные корректировки пользователей.Использование предложенного нами экспресс-метода логирования в Журнал регистрации (Решение 2) позволит быстро определить, под чьим сеансом (конкретного пользователя или системной учетной записи фонового задания обмена) произошло удаление записей.