Как исправить ошибку «Недопустимое значение» в документе «Отпуск» для пользователя с правами кадровика в ЗУП 3.1?

Программист 1С:Зарплата и Управление Персоналом
← На главную

При работе в конфигурации 1С:Зарплата и управление персоналом 3.1 (особенно начиная с релизов ветки 3.1.17 и выше) администраторы и программисты часто сталкиваются с неприятной ситуацией: пользователь с типовым профилем Кадровик не может открыть документ Отпуск. Вместо привычной формы отображается критическая ошибка платформы: «Недопустимое значение». Эта проблема официально зарегистрирована под номером 10229662. Рассмотрим подробнее, почему она возникает и как мы можем её устранить, не нарушая логику разделения прав доступа.

Анализируем причину возникновения ошибки

Для начала разберем техническую природу проблемы. Ошибка «Недопустимое значение» в управляемых формах 1С обычно свидетельствует о том, что программный код пытается установить значение реквизиту или элементу формы, к которому у текущего пользователя нет прав доступа на уровне RLS (Record Level Security) или обычных метаданных. В случае с документом Отпуск, форма при открытии выполняет ряд проверок в процедуре ПриСозданииНаСервере. Система пытается определить, рассчитан ли документ, заполнены ли данные о среднем заработке и должна ли быть видима группа элементов, относящаяся к расчету зарплаты.

Проанализируем ситуацию: в новых релизах ЗУП 3.1 усилен контроль за правами доступа. Если форма обращается к данным регистров расчета или специфическим функциям модуля ЗарплатаКадрыБазовый, а у пользователя роль Кадровик не имеет прав на чтение этих объектов, платформа блокирует инициализацию элементов формы. Фирма «1С» классифицировала это не как ошибку программного кода, а как «ошибку настройки профилей», фактически переложив задачу по исправлению на плечи специалистов на местах.

Способ 1. Корректировка состава ролей профиля «Кадровик»

Самый простой, на первый взгляд, путь — добавить пользователю права на чтение зарплатных данных. Официальная рекомендация подразумевает добавление в профиль доступа следующих ролей:

  1. Чтение начисленной зарплаты
  2. Чтение начисленной зарплаты расширенная

Однако этот метод имеет серьезный побочный эффект. Разберем его: как только кадровик получает эти роли, система начинает воспринимать его как пользователя, имеющего отношение к расчету. При попытке записать кадровые изменения в документе (например, изменить период отпуска), программа инициирует проверку актуальности расчета. В результате кадровик получает новую ошибку: документ невозможно записать, так как он «не рассчитан» или «требует утверждения». Это блокирует работу, так как кадровик не должен и часто не умеет производить расчет начислений.

Вместо «тяжелых» ролей попробуем добавить точечные права. Проанализируем возможность добавления роли Чтение данных для расчета среднего заработка. Это часто позволяет форме документа Отпуск корректно инициализировать поля, связанные с периодами расчета, не давая при этом доступа к самим суммам начислений в расчетных листках.

Способ 2. Использование типового профиля «Аудитор»

Посмотрим на альтернативный вариант настройки прав. В типовой конфигурации существует профиль Аудитор. Этот профиль обладает правами на чтение практически всех регистров системы, но не дает прав на изменение данных. Если назначить пользователю-кадровику дополнительный профиль Аудитор (или включить входящие в него роли в копию профиля кадровика), ошибка «Недопустимое значение» исчезает, так как форма получает доступ ко всем необходимым метаданным для отрисовки интерфейса.

Способ 3. Изменение настроек расчета зарплаты

Иногда проблему удается минимизировать через изменение общих настроек системы. Выясним, как влияют настройки на поведение формы. Перейдем в раздел Настройка — Расчет зарплаты. Попробуем выполнить следующие действия:

  1. Снимем флаг Выполнять автоматический перерасчет документов при их редактировании. Это может помочь кадровику записывать документы без принудительного вызова процедур расчета.
  2. Проверим состояние настройки Расчет и выплата зарплаты выполняется отдельными документами. Если она включена, логика работы формы Отпуск меняется, и в некоторых случаях это обходит конфликт прав.

Способ 4. Программное решение через расширение конфигурации

Если административные меры не помогают, нам придется прибегнуть к написанию расширения. Это самый надежный способ, позволяющий сохранить чистоту прав доступа. Нам нужно вмешаться в процесс инициализации формы и записи документа. Разберем пример реализации.

Во-первых, создадим расширение и добавим в него форму документа Отпуск. Нам нужно переопределить процедуру ПриСозданииНаСервере. Наша задача — обернуть обращения к расчетным данным в блок Попытка...Исключение или добавить проверку прав.


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

Во-вторых, решим проблему невозможности записи документа кадровиком. Система требует расчет, так как флаг ДокументРассчитан установлен в Ложь, а при наличии прав на чтение зарплаты проверка становится обязательной. Мы можем использовать расширение для объекта документа, чтобы принудительно устанавливать признак проверки для кадровиков.


&НаСервере
Процедура ПередЗаписьюНаСервере(Отказ, ТекущийОбъект, ПараметрыЗаписи)
    // Проверяем, есть ли у пользователя права расчетчика
    Если Не РольДоступна("ПолныеПрава") И Не РольДоступна("ДобавлениеИзменениеНачисленнойЗарплаты") Тогда
        // Разрешаем запись кадровых данных без расчета
        ТекущийОбъект.ДокументРассчитан = Истина;
        // В некоторых релизах используется реквизит Проверен
        Если ОбщегоНазначения.ЕстьРеквизитОбъекта("Проверен", ТекущийОбъект.Метаданные()) Тогда
            ТекущийОбъект.Проверен = Истина;
        КонецЕсли;
    КонецЕсли;
КонецПроцедуры

Подводим итоги

Мы проанализировали проблему, возникшую в результате обновления ЗУП 3.1, и выяснили, что ошибка 10229662 является следствием конфликта между программным кодом формы и жесткими правилами RLS. Для оперативного решения мы рекомендуем:

Используя данные методы, мы обеспечим стабильную работу кадровой службы без предоставления им избыточного доступа к конфиденциальным данным о заработной плате сотрудников.

← На главную