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

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

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

1. Как платформа 1С объединяет права доступа (Принцип «ИЛИ»)

Для начала проанализируем, как платформа «1С:Предприятие 8» обрабатывает права пользователя, если ему назначено несколько ролей или групп доступа с настроенными ограничениями RLS (Record Level Security). Это ключевой момент для понимания логики решения.

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

1. Создаем Группу доступа №1 на основе профиля с правами на изменение (например, стандартный «Кадровик»). В настройках ограничения доступа указываем: Разрешена только Организация А. По этой организации у пользователя будут полные права (чтение и запись).
2. Создаем Группу доступа №2 на основе специально подготовленного профиля «Только чтение». В настройках ограничения указываем: Разрешена только Организация Б.

В результате система объединит эти настройки следующим образом:

• по Организации А пользователь может читать и записывать данные (разрешено первой группой);
• по Организации Б пользователь может только читать данные (разрешено второй группой, прав на запись по этой организации нет ни в одной из групп).

Таким образом, мы получаем именно ту схему, которую планировали настроить.

2. Пошаговая настройка профилей и групп доступа в интерфейсе

Перейдем к практической реализации этой схемы в типовой конфигурации. Все настройки выполняются в режиме «1С:Предприятие» под учетной записью с административными правами.

Шаг 1. Включение ограничения доступа на уровне записей:

1. Переходим в раздел Администрирование — Настройки пользователей и прав.
2. Разворачиваем группу Ограничивать доступ на уровне записей и устанавливаем соответствующий флаг.

Шаг 2. Создание профиля «Только чтение»:

1. В этом же разделе переходим по гиперссылке Профили групп доступа.
2. Нажимаем кнопку Создать. Назовем профиль, например, «Просмотр подразделений и организаций».
3. На вкладке Разрешенные действия (роли) находим и отмечаем флажками роли, отвечающие за чтение нормативно-справочной информации (например, Чтение подразделений, Чтение организаций, Чтение базовой нормативно-справочной информации). Важно не выбирать роли, содержащие слово «Добавление» или «Изменение».
4. На вкладке Ограничения доступа для видов доступа Организации и Подразделения устанавливаем значение «Все запрещены, исключения назначаются в группах доступа».
5. Записываем профиль.

Шаг 3. Создание и настройка групп доступа для пользователя:

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

После этого права пользователя будут ограничены нужным образом.

3. Архитектурные ограничения «1С:ЗУП 3.1» по подразделениям

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

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

В связи с этим в типовой системе настройка ограничения доступа «по подразделениям» ограничивает видимость и изменение только элементов справочника подразделений и позиций штатного расписания. Кадровые приказы (приемы, переводы) и расчетные документы по сотрудникам этих подразделений все равно останутся видимыми пользователю, если у него есть доступ к самой организации.

4. Официальный обходной путь: доступ по физическим лицам

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

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

5. Решение проблемы с интерфейсом через расширение конфигурации

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

Чтобы сделать интерфейс дружелюбным к пользователю (сразу блокировать форму для редактирования и окрашивать поля в серый цвет при открытии), необходимо использовать механизм расширений. Мы можем программно устанавливать свойство формы ТолькоПросмотр = Истина.

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

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

Такой подход убережет пользователей от бесполезного заполнения реквизитов, которые они в итоге не смогут сохранить в базе данных.

6. Важные подводные камни использования RLS

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

• Проблема «сборных» документов. Если расчетчик ограничен по организациям или физическим лицам, он не сможет провести или даже открыть общие межрасчетные документы (такие как Начисление зарплаты и взносов или Ведомость в банк), если в табличную часть попадет хотя бы один сотрудник из запрещенной для него организации. Документ заблокируется полностью для этого пользователя. Решением является строгое разделение документов начисления и выплаты по организациям при их создании.
• Игнорирование ограничений администраторами. Обратите внимание, что назначение пользователю стандартного профиля Администратор полностью отключает любые механизмы RLS. Ограничить администратора штатными средствами невозможно — у него всегда будет доступ ко всей базе.
• Снижение производительности СУБД. Включение RLS заставляет платформу модифицировать каждый поисковый запрос к базе данных, добавляя в него неявные соединения таблиц и проверку условий доступа. На крупных базах (от 1000 сотрудников) это может привести к заметному замедлению формирования отчетов, проведения кадровых документов и расчета заработной платы. Рекомендуется регулярно выполнять оптимизацию индексов СУБД и тестировать скорость работы на копии базы.