Задача разделения прав доступа в рамках одной организации, но разных подразделений (департаментов, цехов, территориально удаленных офисов) — классическая проблема для крупных предприятий. Часто руководство требует, чтобы начальники отделов видели зарплату только своих подчиненных, а бухгалтерия на местах не имела доступа к документам соседнего филиала.
В этой статье мы подробно разберем, как реализовать такую схему в 1С:Зарплата и Управление Персоналом КОРП и 1С:Бухгалтерия КОРП, с какими архитектурными ограничениями мы столкнемся и как обойти «грабли», о которых знают только опытные внедренцы.
Рассмотрим типичную ситуацию для крупного холдинга:
Конфигурация ЗУП КОРП (в отличие от версии ПРОФ) имеет мощный встроенный механизм ограничения доступа на уровне записей (RLS). Однако «в лоб» настроить доступ по подразделениям бывает недостаточно из-за специфики кадрового учета (переводы, совместительство).
Самый надежный способ разделения прав в ЗУП — это использование штатного механизма ограничения доступа по Группам доступа физических лиц. Давайте разберем алгоритм настройки.
Суть метода заключается в том, что права назначаются не напрямую на подразделение в структуре предприятия, а на специальную группировку физлиц. Это позволяет гибко управлять доступом при переводах.
Алгоритм действий:
Группах доступа (справочник в администрировании) для конкретных пользователей мы указываем, какие группы физлиц им доступны — есть универсальная настройка прав и профилей доступа.Проконтролировать правильность и полноту настроек на всех этапах поможет специализированный отчет по ограничениям пользователей, который наглядно покажет, кто к каким данным в итоге получил доступ — для этого подойдёт отчет по анализу ограничений доступа RLS.
Мы рекомендуем написать регламентное задание, которое будет анализировать кадровые данные и обновлять привязки. Логика программного заполнения должна быть следующей:
// Примерная логика обновления групп доступа
Для Каждого ФизЛицо Из СписокСотрудников Цикл
ТекущееПодразделение = ПолучитьАктуальноеПодразделение(ФизЛицо);
// Находим или создаем группу доступа, соответствующую подразделению
ГруппаДоступаФЛ = НайтиГруппуДоступаПоПодразделению(ТекущееПодразделение);
// Присваиваем эту группу физлицу
УстановитьГруппуДоступа(ФизЛицо, ГруппаДоступаФЛ);
КонецЦикла;
Основная сложность возникает, когда сотрудник переводится из Подразделения А (доступно Пользователю 1) в Подразделение Б (доступно Пользователю 2). Если мы просто сменим группу доступа у физлица, то Пользователь 1 потеряет доступ к истории начислений и документов по этому сотруднику за тот период, когда он работал у него.
Решение: При переводе сотрудника мы должны не заменять доступ, а расширять его. То есть, исторически сотрудник должен оставаться видимым для старого руководителя (по старым документам) и стать видимым для нового.
Однако, в типовом RLS это может привести к коллизиям. Более практичный вариант:
При приеме на работу физлицо получает доступ от подразделения. При переводе — у него добавляется еще один ключ доступа от нового подразделения (если архитектура доработана) или же мы смиряемся с тем, что старый руководитель видит сотрудника только в старых отчетах, но не в списках текущих сотрудников.
Это самый серьезный «камень преткновения» в ЗУП. Представим ситуацию: есть документ НачислениеЗарплаты, в который попали сотрудники из Цеха №1 и Цеха №2.
Если у Расчетчика есть доступ только к Цеху №1, а в документе есть строки по Цеху №2, то платформа 1С отработает следующим образом:
<Объект не найден>.Как с этим бороться?
Обратите внимание на настройку производительности в ЗУП КОРП. Для крупных предприятий («Большое предприятие», как указано в задаче) критично использование Производительного режима RLS.
В стандартном режиме права рассчитываются «на лету» при каждом запросе к базе, что при большом количестве пользователей и записей положит систему. В производительном режиме используются ключи доступа, которые обновляются отложенно (регламентным заданием ОбновлениеДоступаНаУровнеЗаписей). Это значит, что после кадрового перевода видимость сотрудника для нового начальника может появиться не мгновенно, а спустя некоторое время (обычно несколько минут).
С Бухгалтерией ситуация сложнее. Архитектура бухгалтерского учета в 1С построена вокруг справочника Организации. Разделение баланса по подразделениям внутри одного юрлица не предусмотрено стандартами ПБУ (если это не выделенные на отдельный баланс филиалы).
Если мы попытаемся включить RLS по справочнику Подразделения для обычных документов, мы столкнемся с проблемой двойной записи. Любая проводка имеет Дебет и Кредит.
Рассмотрим перемещение материалов:
Если бухгалтер Цеха 1 не имеет прав на просмотр данных Цеха 2, то при формировании Оборотно-сальдовой ведомости (ОСВ) он увидит «разъехавшуюся» проводку. Одна часть проводки будет видна, а вторая — нет (или будет показана как пустая аналитика / объект не найден). Это приведет к тому, что:
Именно поэтому опытные специалисты называют деление бухгалтерии по подразделениям (в рамках одного баланса) «преступным» по отношению к учету.
Если разделить доступ всё-таки необходимо, проанализируем возможные компромиссы.
Вариант 1. Обособленные подразделения (филиалы)
Если подразделения фактически являются филиалами, используйте штатный функционал «Обособленные подразделения, выделенные на отдельный баланс». В этом случае обмен данными идет через счет 79, и каждый филиал ведет свой почти независимый учет. RLS в этом случае настраивается корректно по Организации (головной или филиальной).
Вариант 2. Ограничение доступа к документам через расширение
Более жизненный подход — ограничить доступ не к аналитике внутри проводок, а к самим документам. Например, запретить бухгалтеру из филиала А видеть документы филиала Б. Для этого часто используют расширения, как, например, готовое решение, которое позволяет настроить доступ только к определенным документам для конкретных пользователей.
При самостоятельной разработке подобного механизма потребуется создать Расширение конфигурации, в котором:
Важно помнить, что при самостоятельной доработке необходимо тщательно тестировать код.
Риски данного метода:
Реализация на основании Счета), и один из них недоступен, пользователь столкнется с ошибками.