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

← На главную

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

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

Почему в 1С:ЗУП 3.1 нет типового ограничения по подразделениям?

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

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

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

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

Типовое решение: Ограничение доступа по группам физических лиц

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

Шаг 1. Включение RLS в программе:

Перейдем в раздел Администрирование, затем выберем пункт Настройки пользователей и прав.
Развернем группу настроек Группы доступа.
Установим флаг Ограничивать доступ на уровне записей.

Шаг 2. Активация доступа по физическим лицам:

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

Шаг 3. Создание групп доступа физических лиц:

Перейдем в справочник Группы доступа физических лиц (его можно найти через функции для технического специалиста или в настройках прав).
Создадим новые группы, соответствующие нашим обособленным подразделениям (например, «Сотрудники филиала Север» и «Сотрудники Центрального офиса»).

Шаг 4. Привязка физических лиц к группам:

Откроем карточку физического лица (важно: именно в справочнике ФизическиеЛица, а не Сотрудники).
В поле Группа доступа укажем созданную на предыдущем шаге группу.

Шаг 5. Настройка прав пользователя:

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

Подводные камни и ограничения типового подхода по физлицам

Рассмотрим подробнее проблемы, с которыми столкнется организация при использовании этого метода. К сожалению, этот механизм не идеален и имеет ряд существенных минусов:

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

Альтернативные и нетиповые решения (доработки)

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

Вариант 1. Автоматическое управление группами доступа физлиц

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

Посмотрим на пример кода, реализующего такую логику:


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

Вариант 2. Облегченный RLS (фильтрация на уровне динамических списков)

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

Разберем по шагам, как это работает:

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

Посмотрим на пример программного наложения отбора:


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

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

Вариант 3. Разделение баз данных и организация обмена

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

В этой схеме кадровик удаленного подразделения работает в своей локальной базе 1С:ЗУП, где заведены только его сотрудники. В конце месяца кадровые и табельные данные выгружаются в центральную базу с помощью настроенного обмена (РИБ или универсальный обмен XML/JSON). Расчетчики в центральной базе видят общую картину, рассчитывают налоги и формируют регламентированную отчетность без нарушения методологии 1С.