При организации работы в крупной компании с филиальной структурой часто возникает задача разделения прав доступа: сотрудники и расчетчики филиалов должны видеть только данные своего подразделения, а головная организация должна иметь доступ к документам и справочникам всех подразделений. В конфигурации 1С:Зарплата и Управление Персоналом редакции 2.5 на платформе 1С:Предприятие 8.2 решение этой задачи имеет ряд специфических нюансов и методологических ограничений.
Рассмотрим подробно варианты реализации данной схемы — как через штатный функционал, так и путем доработки конфигурации или использования альтернативных архитектурных подходов.
Проанализируем, почему в типовой конфигурации ЗУП 2.5 разграничение прав по подразделениям не реализовано «из коробки» в полном объеме. Согласно законодательству РФ, расчет НДФЛ и страховых взносов выполняется в целом по физическому лицу (налогоплательщику), а не отдельно по его рабочим местам или подразделениям.
Из-за этого полная жесткая изоляция подразделений с помощью механизма RLS (Record-Level Security) сталкивается со следующими проблемами:
НачислениеЗарплатыРаботникамОрганизаций или ЗарплатаКВыплатеОрганизаций) присутствует хотя бы один сотрудник, к которому у текущего пользователя нет прав, платформа полностью блокирует просмотр и проведение всего документа.Выясним, как настроить права средствами типового функционала без изменения конфигурации. Для этого используется разграничение доступа по группам физических лиц.
Разберем процесс настройки по шагам:
ГруппыДоступностиФизическихЛиц создаем отдельные группы для каждого филиала или подразделения.ФизическиеЛица по соответствующим группам доступа.ГруппыПользователей. По кнопке Права на закладке Физ лица прописываем доступные группы физических лиц для каждой группы пользователей.Важное замечание: данный способ требует постоянного контроля при перемещении сотрудников между подразделениями, а также вызывает повышенную нагрузку на СУБД при открытии динамических списков и журналов документов.
Если штатного функционала недостаточно, проанализируем вариант с модификацией шаблонов RLS. Для обеспечения корректной работы списков и документов в конфигураторе изменяются условия ограничений доступа.
В справочнике СотрудникиОрганизаций и основных расчетных документах стандартный параметр шаблона RLS Организация меняется на проверку по полю ОбособленноеПодразделение или ПодразделениеОрганизации.
При использовании доработанного RLS в отчетах и запросах необходимо следить за присутствием инструкции ВЫБРАТЬ РАЗРЕШЕННЫЕ, иначе при попытке формирования отчета пользователь с ограниченными правами будет получать ошибку недостаточности прав.
Посмотрим на практические альтернативы, которые позволяют избежать падения производительности и проблем с расчетом налогов:
Создаются узлы РИБ с отбором данных по подразделениям. Филиалы работают в своих периферийных базах и видят только свои данные. Головной узел объединяет данные всех подразделений. Это полностью исключает нагрузку от RLS и гарантирует изоляцию данных, однако требует настройки регулярного обмена.
Вместо тяжелого механизма RLS на уровне СУБД применяется динамическая установка отборов в формах списков при открытии. Контроль записи и проведения документов переносится в подписки на события ПередЗаписью и ОбработкаПро проведения. Этот вариант сохраняет высокую скорость работы базы данных.
При проведении кадровых документов (ПриемНаРаботуВОрганизацию, КадровоеПеремещениеОрганизаций) система с помощью программного кода добавляет физическое лицо в группу доступа нового подразделения, сохраняя при этом исторические группы, чтобы расчетчики прошлых периодов не теряли доступ к архивным документам.
В современной редакции 3.1 на платформе 8.3 применяется производительный режим RLS (ключи доступа) и развитый штатный механизм разграничения прав по подразделениям и филиалам, который лишен ключевых недостатков версии 2.5.