Как настроить ограничение доступа по физическим лицам в 1С:ЗУП 3.1 и какие есть нюансы с отчетами?

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

Настройка ограничения доступа на уровне записей (RLS)

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

1. Создание групп доступа физических лиц. В разделе настроек администрирования необходимо настроить профили групп доступа. Каждое физическое лицо должно быть включено в определенную группу.
2. Настройка профиля пользователя. Пользователю назначается профиль, который ограничивает его права на чтение справочника Физические лица только в рамках разрешенной ему группы доступа.
3. Применение ограничений. Как только настройки активированы, платформа 1С автоматически применяет фильтры к любым запросам к базе данных. Система начинает работать в режиме контроля доступа, скрывая записи, к которым у пользователя нет прав.

Важно понимать, что данное ограничение действует на уровне СУБД. Это означает, что если вы выполните запрос к справочнику Физические лица, система автоматически применит условия фильтрации, определенные правами доступа.

Почему возникают проблемы с регламентированными отчетами?

Регламентированная отчетность (такая как 6-НДФЛ, РСВ и прочие) имеет принципиальное отличие от обычных аналитических отчетов. Эти отчеты предназначены для формирования полной картины по всей организации, так как содержат сводные данные для налоговых органов. Возникают следующие проблемы:

• Ошибки доступа. В типовых регламентированных отчетах запросы часто написаны так, что обращаются ко всей совокупности данных. Если у пользователя ограничены права, выполнение таких запросов может привести к ошибкам доступа или формированию пустого отчета.
• Логика «Выбрать разрешенные». Стандартная практика разработки — замена конструкций ВЫБРАТЬ на ВЫБРАТЬ РАЗРЕШЕННЫЕ. Если разработчик 1С в типовой конфигурации не предусмотрел такую замену в конкретном отчете, данные просто не будут отображены из-за срабатывания механизма безопасности.
• Привилегированный режим. Если типовой код или регламентная процедура выполняются в привилегированном режиме, ограничения доступа игнорируются. Это сделано намеренно, чтобы системные задачи могли собирать данные по всей организации, несмотря на настройки RLS конкретного пользователя.

Возможные пути решения

Проанализируем доступные варианты решения проблемы, если типовые отчеты «не видят» данные или выдают ошибки:

Вариант 1: Использование прав с полным доступом.

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

Вариант 2: Доработка механизмов формирования отчетов.

Если бизнес-процессы требуют, чтобы конкретный пользователь формировал отчеты, можно проанализировать запросы в модулях отчетов. Вы можете заменить обращение к данным на конструкцию с ключевым словом РАЗРЕШЕННЫЕ:

// Пример логики запроса в коде
Запрос = Новый Запрос;
Запрос.Текст = "ВЫБРАТЬ РАЗРЕШЕННЫЕ
               |    Сотрудники.Ссылка
               |ИЗ
               |    Справочник.ФизическиеЛица КАК Сотрудники";

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

Итоги и рекомендации

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

Основные выводы:

• RLS работает на уровне СУБД, эффективно закрывая доступ к данным в большинстве справочников и отчетов.
• Регламентированные отчеты без доработки прав и кода, скорее всего, не смогут корректно работать у пользователя с ограничениями.
• Наилучшей практикой для работы с отчетностью является разделение ролей: рядовые пользователи работают с ограниченным доступом, а для формирования отчетности используется профиль с полными правами.

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