Как ограничить права доступа пользователей по подразделениям в 1С:Бухгалтерия 3.0 КОРП типовыми средствами?

← На главную

При работе в 1С:Бухгалтерия 3.0 КОРП часто возникает задача разграничения прав доступа пользователей к данным не только по организациям, но и по внутренним подразделениям. Это особенно актуально для крупных компаний, где каждый менеджер или бухгалтер должен видеть только те документы и данные, которые относятся к его зоне ответственности или конкретному подразделению.

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

В чем суть проблемы ограничения доступа по подразделениям?

Изначально, разработчики конфигурации 1С:Бухгалтерия Предприятия 3.0 КОРП не закладывали полноценную поддержку ограничения доступа по подразделениям, если эти подразделения не являются обособленными и не выделены на отдельный баланс. Это подтверждается официальным ответом: "Ограничение доступа в разрезе подразделений, невыделенных на отдельный баланс (по справочнику 'ПодразделенияОрганизаций') в типовой конфигурации не поддерживается."

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

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

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

Неоднозначность учета по подразделениям: Если организация является полноценным разделителем учета (ее реквизиты присутствуют практически везде), то с подразделением все не так однозначно. Существуют счета учета, где учет по подразделениям не ведется вовсе. Это означает, что даже если мы ограничим доступ к документам по подразделениям, агрегированные бухгалтерские отчеты могут быть некорректными или не поддаваться полноценной фильтрации по подразделениям.
Влияние на бухгалтерские отчеты: Ограничение доступа к документам реализации, например, ставит вопрос о том, что произойдет при формировании таких отчетов, как "Карточка счета". Если бухгалтер сможет видеть только часть документов, относящихся к его подразделению, то полная и корректная картина по счету будет недоступна, а сам отчет может формироваться неверно, показывая лишь часть данных. Механизм RLS может быть эффективен для оперативного учета, но для бухгалтерского, где важна целостность и полнота данных, возникают трудности.
Типовые ограничения RLS: В некоторых типовых решениях 1С (например, в 1С:ЗУП КОРП) ограничения по подразделениям могут работать для штатного расписания, но не для всех данных. Возможны ситуации, когда при переводе сотрудника из одного подразделения в другое, документы с начислениями могут стать недоступны для бухгалтера прежнего подразделения, если в документе присутствует хотя бы один сотрудник, к которому нет доступа.

Таким образом, типовой функционал 1С:Бухгалтерия 3.0 КОРП не доработан для полноценного разграничения прав доступа по подразделениям, если они не являются обособленными. Это приводит к необходимости использовать нетиповые подходы.

Общие принципы работы RLS в 1С:Бухгалтерии 3.0 КОРП

Для понимания того, как можно реализовать ограничение доступа по подразделениям нетиповыми способами, сначала вспомним, как работает механизм RLS в 1С:Предприятии 8. Это поможет нам спланировать доработку.

Механизм RLS (Record Level Security), или ограничение доступа на уровне записей, позволяет ограничивать доступ пользователей не ко всему справочнику или документу в целом, а к конкретным записям внутри них. Это критически важно для предприятий, где каждый сотрудник должен видеть только ту информацию, которая относится к его зоне ответственности.

Для включения RLS нам необходимо:

Активировать RLS: Установите флаг "Ограничивать доступ на уровне записей" в разделе "Администрирование" – "Настройки пользователей и прав".
Настроить роли и профили: В конфигурации есть роли (например, Бухгалтер), которые определяют общие права на объекты. Профили групп доступа объединяют роли и шаблоны ограничений.
Настроить группы доступа: В группах доступа, на вкладке "Ограничения доступа", вы можете выбрать требуемый уровень ограничений (например, по организациям) и указать нужные значения.
Использовать RLS-шаблоны: Внутри ролей могут быть прописаны RLS-шаблоны, которые определяют, при каких условиях записи доступны пользователю. Именно с этими шаблонами мы и будем работать при доработке.

Типовое ограничение прав доступа в разрезе организаций достигается за счет использования предопределенных RLS-шаблонов, которые фильтруют данные по значению реквизита Организация в объектах.

Доработка функционала для ограничения доступа по подразделениям

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

Сценарий 1: Ограничение документов реализации по подразделениям

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

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

Создание и инициализация параметра сеанса "ТекущееПодразделение"

Для того чтобы RLS-шаблон мог использовать подразделение текущего пользователя, нам понадобится параметр сеанса. Параметр сеанса доступен во всех модулях и запросах в течение пользовательской сессии.

В конфигурации создайте новый параметр сеанса ТекущееПодразделение с типом СправочникСсылка.ПодразделенияОрганизаций.
Инициализируйте этот параметр при старте системы или в модуле сеанса, основываясь на реквизите Подразделение текущего пользователя.


// Пример инициализации параметра сеанса в МодулеСеанса при установке основных параметров
// Этот код будет выполняться при старте сеанса пользователя

Процедура УстановкаПараметровСеанса()
    // ... Другие параметры сеанса
    Если ЗначениеЗаполнено(ПараметрыСеанса.ТекущийПользователь.Подразделение) Тогда
        ПараметрыСеанса.ТекущееПодразделение = ПараметрыСеанса.ТекущийПользователь.Подразделение;
    Иначе
        // Если у пользователя не заполнено подразделение, можно установить Неопределено
        // или подразделение по умолчанию, или оставить пустым для полного доступа
        ПараметрыСеанса.ТекущееПодразделение = Неопределено;
    КонецЕсли;
    // ...
КонецПроцедуры

Мы должны убедиться, что ПараметрыСеанса.ТекущийПользователь уже инициализирован, что обычно происходит в стандартных процедурах 1С.

Настройка RLS для документа "РеализацияТоваровУслуг"
Теперь мы можем добавить условие RLS для соответствующей роли, например, Добавление и изменение данных бухгалтерии, чтобы ограничить видимость документов реализации только своим подразделением.
- Откройте роль, которую используют пользователи, для которых нужно ограничить доступ (например, Бухгалтер или Добавление и изменение данных бухгалтерии).
- Найдите в этой роли объект Документ.РеализацияТоваровУслуг.
- На вкладке "Ограничение доступа к данным" добавьте или измените шаблон RLS. Нам нужно, чтобы шаблон сравнивал подразделение документа с подразделением текущего пользователя, хранящимся в параметре сеанса.
```
#Если &ОграничениеДоступаПоПодразделениям Тогда
    // Проверяем, заполнено ли подразделение у текущего пользователя в параметре сеанса
    #Если &ПараметрыСеанса.ТекущееПодразделение Тогда
        // Ограничиваем доступ к документам, где реквизит Подразделение совпадает с Подразделением пользователя
        // ИЛИ у документа Подразделение НЕ заполнено (если такие документы не должны быть ограничены)
        Объект.Подразделение = &ПараметрыСеанса.ТекущееПодразделение
        ИЛИ Объект.Подразделение ЕСТЬ NULL
    #Иначе
        // Если у пользователя не привязано подразделение в параметре сеанса,
        // можно предоставить полный доступ (для администраторов)
        // или полностью запретить (если пользователь обязан иметь подразделение)
        ИСТИНА // Или ЛОЖЬ, в зависимости от логики
    #КонецЕсли
#Иначе
    ИСТИНА // Если флаг &ОграничениеДоступаПоПодразделениям не установлен, доступ не ограничен
#КонецЕсли
```
В этом примере #Если &ОграничениеДоступаПоПодразделениям Тогда – это условный оператор, который позволяет включить или выключить данное ограничение через настройки программы. Объект.Подразделение – это реквизит документа реализации. Если такого реквизита в документе нет, его необходимо добавить.

Важно: убедитесь, что в документе РеализацияТоваровУслуг действительно присутствует реквизит Подразделение, иначе RLS работать не будет. При необходимости, добавьте этот реквизит в документ.
Учет сотрудников центрального офиса
Часто требуется, чтобы сотрудники центрального офиса имели полный доступ ко всем данным, независимо от подразделения. Для этого мы можем добавить дополнительный реквизит в справочник ПодразделенияОрганизаций.
- В справочник ПодразделенияОрганизаций добавьте булевый реквизит, например, ЦентральныйОфис.
- Отметьте этот реквизит для подразделения, которое является центральным офисом.
- Измените шаблон RLS таким образом, чтобы пользователи, чье подразделение является центральным офисом, имели неограниченный доступ.
```
#Если &ОграничениеДоступаПоПодразделениям Тогда
    #Если &ПараметрыСеанса.ТекущееПодразделение Тогда
        // Если подразделение пользователя отмечено как ЦентральныйОфис, то доступ полный
        Если &ПараметрыСеанса.ТекущееПодразделение.ЦентральныйОфис Тогда
            ИСТИНА
        Иначе
            // Иначе, ограничиваем доступ по подразделению пользователя
            Объект.Подразделение = &ПараметрыСеанса.ТекущееПодразделение
            ИЛИ Объект.Подразделение ЕСТЬ NULL
        КонецЕсли;
    #Иначе
        ИСТИНА // Пользователь без привязки к подразделению имеет полный доступ (или ЛОЖЬ)
    #КонецЕсли
#Иначе
    ИСТИНА
#КонецЕсли
```
Такой подход обеспечивает гибкость в настройке прав для различных групп пользователей.

Особенности и сложности при внедрении RLS по подразделениям

Внедрение RLS, особенно с учетом доработок, всегда сопряжено с определенными сложностями:

Объекты с полными правами: Некоторые объекты могут изначально быть доступны только ролям с полными правами. В таких случаях для них также потребуется доработка RLS, если мы хотим применить к ним ограничения.
Динамика штата: Если сотрудники часто перемещаются между подразделениями, потребуется либо создание промежуточных групп доступа, которые администрируются вручную, либо разработка автоматизированных механизмов формирования групп доступа на основе актуальных данных о сотрудниках.
Сложность настройки: Механизм RLS требует глубокого понимания структуры данных и работы 1С. Неправильная настройка может привести к непреднамеренному доступу или, наоборот, к полному блокированию работы.
Производительность: Сложные RLS-шаблоны могут влиять на производительность системы, особенно при работе с большими объемами данных. Необходимо тщательно тестировать каждое изменение.

В специализированных решениях, таких как БИТ.ФИНАНС для БП 3.0 КОРП, механизм RLS может обеспечивать разграничение данных по нескольким разрезам (организация, ЦФО, статьи оборотов, проект, пользователь). В этих решениях ограничение по организации обеспечивается типовым механизмом RLS от 1С, а по остальным разрезам – механизмом RLS от разработчика решения. Это демонстрирует, что для комплексного разграничения доступа по нескольким измерениям часто требуются нетиповые разработки.

Влияние на бухгалтерские отчеты

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

Неполные данные: Если пользователь видит только документы своего подразделения, то при формировании отчета, например, Карточка счета, он получит неполную информацию. Отчет будет включать только те проводки, которые созданы документами, к которым у пользователя есть доступ. Это может привести к некорректным выводам и ошибкам в анализе.
Отсутствие учета по подразделениям на некоторых счетах: Если на некоторых счетах бухгалтерский учет по подразделениям не ведется вовсе, то попытка отфильтровать эти счета по подразделениям будет затруднительна или невозможна, даже если RLS успешно ограничивает доступ к первичным документам.
Необходимость специальной обработки: Для корректного формирования агрегированных бухгалтерских отчетов, возможно, потребуется либо разрабатывать отдельные отчеты, которые не учитывают RLS-ограничения (например, для главного бухгалтера), либо модифицировать стандартные отчеты, чтобы они учитывали подразделения, но при этом давали полную картину для авторизованных пользователей.
Прозрачность и контроль: Мы должны четко понимать, какие пользователи и к каким данным имеют доступ, и как это отражается на формируемых ими отчетах. Это требует тщательного планирования и тестирования на всех этапах внедрения.

Вывод

Ограничение прав доступа по подразделениям в 1С:Бухгалтерия 3.0 КОРП является нетривиальной задачей, которая не поддерживается типовыми средствами, если подразделения не выделены на отдельный баланс. Нам придется прибегнуть к доработке конфигурации, используя механизм RLS.

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