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