В работе кадровой службы часто возникает ситуация, когда период для редактирования данных уже закрыт (например, после окончательного расчета зарплаты за месяц), но кадровику необходимо внести или актуализировать сведения о воинском учете сотрудников. Программа 1С:Зарплата и управление персоналом 3.1 (ЗУП) по умолчанию блокирует любые изменения в закрытом периоде, даже если эти данные напрямую не влияют на расчет налогов и взносов. Рассмотрим, почему так происходит, и разберем все доступные способы решения этой проблемы — от простых настроек до программной доработки системы.
Механизм даты запрета изменения данных в 1С предназначен для защиты уже рассчитанных показателей (зарплаты, налогов, отчетов) от случайных правок. Однако данные воинского учета — это сведения, которые могут поступать в любое время. При попытке сохранить карточку воинского учета система проверяет дату сведений. Если эта дата или дата самого объекта попадает в закрытый период, срабатывает общая проверка ДатыЗапретаИзменения. Проблема усугубляется тем, что данные воинского учета часто хранятся в регистрах сведений, связанных с физическим лицом или сотрудником, и система может считать их частью кадровой истории, критичной для расчетов.
Прежде чем переходить к программированию, проанализируем штатные возможности программы. В 1С:ЗУП реализован механизм разделения дат запрета по функциональным областям. Это позволяет закрыть расчет зарплаты, но оставить открытыми персональные данные.
Кадровый учет и Персональные данные.Зарплата и Кадровый учет актуальную дату (конец прошлого месяца), а для раздела Персональные данные (куда зачастую относятся сведения воинского учета) установим дату гораздо более раннюю или вовсе ее не будем устанавливать.Важный нюанс: В некоторых релизах данные воинского учета могут быть жестко привязаны к кадровым данным. Если разделение по разделам не помогает, перейдем к следующему способу.
Чтобы кадровик не зависел от администратора или главного бухгалтера с полными правами, мы можем наделить его полномочиями временно сдвигать дату запрета. Для этого пригодится ручная настройка профиля групп доступа:
Управление датами запрета изменения, обеспечив доступ к дате запрета определенным пользователям независимо от полных прав.Этот способ требует дисциплины от сотрудников, но полностью решает проблему "несамостоятельности" кадровой службы.
Если мы хотим автоматизировать процесс так, чтобы программа сама понимала, какие данные можно менять, а какие нет, нам потребуется создать расширение. Мы будем использовать переопределяемый модуль системы запрета изменений.
Проанализируем ситуацию: нам нужно разрешить запись в определенные регистры сведений (воинский учет, паспортные данные, инвалидность), даже если период закрыт. Для этого внесем изменения в общий модуль ДатыЗапретаИзмененияПереопределяемый.
Рассмотрим пример кода, который нужно добавить в расширение:
&После("ПередПроверкойЗапретаИзменения")
Процедура Расш1_ПередПроверкойЗапретаИзменения(Объект, ПроверкаЗапретаИзменения, УзелПроверкиЗапретаЗагрузки, ВерсияОбъекта)
// Создадим массив типов, для которых мы хотим отключить проверку
мТипыБезПроверки = Новый Массив;
мТипыБезПроверки.Добавить(Тип("РегистрСведенийНаборЗаписей.ВоинскийУчет"));
мТипыБезПроверки.Добавить(Тип("РегистрСведенийНаборЗаписей.ГражданствоФизическихЛиц"));
мТипыБезПроверки.Добавить(Тип("РегистрСведенийНаборЗаписей.ДокументыФизическихЛиц"));
мТипыБезПроверки.Добавить(Тип("РегистрСведенийНаборЗаписей.ФИОФизическихЛиц"));
// Если проверка включена, проверим, входит ли наш объект в список разрешенных
Если ПроверкаЗапретаИзменения Тогда
Если мТипыБезПроверки.Найти(ТипЗнч(Объект)) <> Неопределено Тогда
// Дополнительно проверим права пользователя
Если (РольДоступна("АдминистраторСистемы") ИЛИ РольДоступна("ДобавлениеИзменениеДанныхФизическихЛицЗарплатаКадры")) Тогда
ПроверкаЗапретаИзменения = Ложь;
КонецЕсли;
КонецЕсли;
КонецЕсли;
КонецПроцедуры
В этом коде мы перехватываем процедуру проверки запрета и принудительно устанавливаем флаг ПроверкаЗапретаИзменения в значение Ложь, если изменяемый объект относится к воинскому учету или персональным данным. Это позволяет кадровикам работать в штатном режиме, не беспокоя ИТ-отдел.
Еще один программный подход — использование привилегированного режима при записи справочников Сотрудники и Физические лица. Рассмотрим этот вариант подробнее. Часто блокировка происходит не в самом регистре воинского учета, а при попытке записи владельца этих данных. В расширении можно прописать включение привилегированного режима в модуле объекта справочника ФизическиеЛица перед записью. Это позволит обойти ограничения прав доступа и даты запрета, так как в привилегированном режиме проверки безопасности системы БСП (Библиотека стандартных подсистем) для текущего пользователя игнорируются.
Важно помнить, что вносить данные о воинском учете следует напрямую через карточку сотрудника (справочник Сотрудники), а не через документы (например, "Прием на работу"). Если вы пытаетесь изменить данные внутри старого документа приема, программа неизбежно заблокирует действие, так как документ является регистратором для множества других, расчетных регистров. Работа через справочники в 1С:ЗУП 3.1 организована более гибко по отношению к датам запрета.
Стоит отметить, что разработчики 1С признали данную "нелогичность" и в последних версиях ЗУП (начиная с 3.1.27.148) функционал был частично скорректирован. В актуальных релизах система лучше разделяет расчетные данные и сведения воинского учета. Если ваша информационная база позволяет выполнить обновление, это может стать самым простым решением проблемы без написания кода.
Подведем итог: для оперативного решения используйте настройку даты запрета по разделам, а для полной автоматизации и комфорта пользователей — внедрение расширения с переопределением логики проверки запрета изменений.