Как в ЗУП 3.1 отобразить подписи ответственных лиц, если у пользователя ограничен доступ к их персональным данным?

При работе в крупных организациях часто возникает ситуация, когда доступ рядовых сотрудников (например, кадровиков отдельных подразделений или табельщиков) к данным руководства компании жестко ограничен. В 1С:ЗУП 3.1 это реализуется через механизм Ограничения доступа на уровне записей (RLS) по группам физических лиц. Однако при такой настройке возникает техническая коллизия: когда рядовой пользователь формирует приказ или справку, где в качестве подписанта выступает директор, программа не может вывести ФИО руководителя в печатную форму. Система "честно" скрывает данные физлица, к которому нет доступа, и в результате в поле подписи отображается пустота.

В этой статье мы подробно разберем, почему так происходит, и рассмотрим три основных способа решения проблемы: от административной настройки прав до разработки небольшого расширения.

Почему RLS блокирует подписи? Выясним причину

Проанализируем ситуацию с точки зрения архитектуры базы данных. Сведения о том, кто является руководителем или главным бухгалтером организации, хранятся в регистре сведений ОтветственныеЛицаОрганизаций. Сам по себе этот регистр обычно открыт для чтения. Однако поле ФизическоеЛицо в этом регистре содержит ссылку на справочник ФизическиеЛица.

Когда система формирует печатную форму, она выполняет запрос к справочнику ФизическиеЛица, чтобы получить текстовое представление (ФИО) и должность. Если для текущего пользователя включено ограничение по группам физлиц и искомый руководитель не входит в разрешенную пользователю группу, механизм RLS на уровне платформы просто исключает эту запись из выборки. Программа получает пустой результат вместо ФИО, что мы и видим в печатной форме.

Решение 1: Настройка специальной группы доступа (Административный метод)

Самый правильный путь с точки зрения типовой методологии 1С — это настройка прав таким образом, чтобы пользователь "видел" ФИО, но не имел доступа к конфиденциальной информации. Рассмотрим, как это реализовать по шагам.

1. Перейдем в раздел Администрирование — Настройки пользователей и прав — Группы доступа физических лиц. Создадим новую группу, например, "Руководство (только для подписей)".
2. В карточках физических лиц, которые являются подписантами, на вкладке "Администрирование" укажем созданную группу доступа.
3. Создадим новый Профиль групп доступа (или отредактируем существующий у пользователей). В этом профиле нам нужно разрешить чтение справочника ФизическиеЛица для новой группы.
4. Важный нюанс: Чтобы пользователи не увидели лишнего (паспортные данные, ИНН, СНИЛС), необходимо убедиться, что у них нет прав на чтение регистров сведений, содержащих персональные данные (например, ПаспортныеДанныеФизЛиц), именно по этой группе лиц.

Такой подход позволяет системе успешно выполнять запросы для печатных форм, так как ссылка на физлицо становится "видимой". При этом попытка открыть карточку такого физлица в справочнике покажет пользователю только ФИО, а остальные поля останутся недоступными или пустыми.

Решение 2: Использование стандартной роли для чтения ФИО

Проанализируем возможности типовых ролей. В конфигурации ЗУП 3.1 существует специализированная роль (в разных релизах название может варьироваться, например, ЧтениеПерсональныхДанныхФизическихЛиц), которая при определенной настройке позволяет видеть только ФИО.

Посмотрим на пример настройки через профиль безопасности:

1. Добавим пользователю роль Чтение данных физических лиц зарплата кадры.
2. В настройках ограничений доступа для этого профиля установим доступ к виду "Физические лица" — Все разрешены, кроме исключений (если это допустимо политикой безопасности) или добавим конкретную группу подписантов в разрешенные.
3. Если мы хотим, чтобы расчетчики видели всех физлиц, но не могли смотреть их начисления, мы разделяем права на Данные сотрудников и Данные физических лиц.

Это решение требует тщательного тестирования, чтобы случайно не открыть доступ к ведомостям на выплату зарплаты руководству.

Решение 3: Программное решение через расширение (Привилегированный режим)

Если административные методы не подходят (например, политика безопасности запрещает даже минимальную видимость руководства в списках), воспользуемся программным методом. Суть заключается в том, чтобы заставить систему собирать данные о подписантах в привилегированном режиме, игнорируя настройки RLS текущего пользователя.

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

Пример кода для расширения (общий модуль):

&Вместо("СформироватьДанныеДляПечати")
Функция Расш1_СформироватьДанныеДляПечати(Параметры)
    
    // Включаем привилегированный режим, чтобы RLS не отсекал ФизЛиц
    УстановитьПривилегированныйРежим(Истина);
    
    // Вызываем стандартную обработку в привилегированном режиме
    Результат = ПродолжитьВызов(Параметры);
    
    // Возвращаем результат, который теперь содержит ФИО подписантов
    Возврат Результат;
    
КонецФункции

Разберем, почему это работает. Команда УстановитьПривилегированныйРежим(Истина) отключает проверку прав доступа (включая RLS) на уровне текущего сеанса для выполнения конкретного блока кода. Поскольку печатная форма лишь отображает строковое представление ФИО и должности, никакой утечки критически важных персональных данных (таких как номер паспорта или сумма дохода) не происходит.

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

Функция ПолучитьПредставлениеПодписантаПривилегированно(СсылкаФизЛицо, Дата) Экспорт
    
    УстановитьПривилегированныйРежим(Истина);
    
    Запрос = Новый Запрос;
    Запрос.Текст = 
        "ВЫБРАТЬ
        |	ФизическиеЛица.Наименование КАК ФИО,
        |	ФИОФизическихЛицСрезПоследних.Фамилия + "" "" + ЛЕВ(ФИОФизическихЛицСрезПоследних.Имя, 1) + "". "" + ЛЕВ(ФИОФизическихЛицСрезПоследних.Отчество, 1) + ""."" КАК ФИОИнициалы
        |ИЗ
        |	Справочник.ФизическиеЛица КАК ФизическиеЛица
        |		ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.ФИОФизическихЛиц.СрезПоследних(&Дата, ) КАК ФИОФизическихЛицСрезПоследних
        |		ПО ФизическиеЛица.Ссылка = ФИОФизическихЛицСрезПоследних.ФизическоеЛицо
        |ГДЕ
        |	ФизическиеЛица.Ссылка = &Ссылка";
    
    Запрос.УстановитьПараметр("Ссылка", СсылкаФизЛицо);
    Запрос.УстановитьПараметр("Дата", Дата);
    
    Выборка = Запрос.Выполнить().Выбрать();
    Если Выборка.Следующий() Тогда
        Возврат Выборка.ФИОИнициалы;
    КонецЕсли;
    
    Возврат "";
    
КонецФункции

Рекомендации по выбору решения

Проанализируем, какой метод лучше выбрать в вашей ситуации:

• Используйте административный метод (Решение 1), если ваша организация придерживается принципа "минимум доработок в коде". Это прозрачный механизм, предусмотренный разработчиками 1С.
• Используйте программный метод (Решение 3), если требования безопасности настолько суровы, что руководство не должно появляться даже в результатах поиска или в общих списках физлиц у рядовых сотрудников.
• Избегайте создания "двойников" физических лиц (одна карточка для зарплаты, другая без данных — для подписей). Это приведет к дублированию данных, ошибкам в учете и проблемам при обновлении программы.

Не забудьте, что после изменения настроек RLS (особенно в "Производительном" режиме доступа) может потребоваться запуск регламентного задания Обновление данных для максимально оперативного управления доступом. Только после обновления кэша прав новые настройки вступят в силу для всех пользователей.