Как настроить ограничение доступа к документу «Заявка на расход денежных средств» в БИТ.ФИНАНС?

В процессе автоматизации казначейства и управленческого учета часто возникает задача разграничения прав доступа. Типовой сценарий: рядовой сотрудник должен видеть только свои документы, руководитель — заявки своего подразделения, а топ-менеджмент или руководители смежных направлений — документы по определенным проектам или ЦФО. В системе БИТ.ФИНАНС, работающей на базе 1С:Бухгалтерия, существует несколько подходов к решению этой задачи: от штатных настроек подсистемы прав до написания собственных правил RLS (Record Level Security). Для последующей проверки итоговых настроек можно использовать специальные обработки, позволяющие выполнить наглядный анализ и изменение прав пользователей.

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

Метод 1. Использование штатной подсистемы «БИТ.Права доступа»

Проанализируем возможности встроенного механизма БИТ.ФИНАНС. В отличие от типовой бухгалтерии, здесь уже реализована мощная система разграничения прав на уровне записей. Основным разрезом доступа в этой конфигурации является Центр финансовой ответственности (ЦФО).

Рассмотрим пошагово, как работает эта схема:

1. Связь сотрудника и ЦФО: Каждого сотрудника (автора заявок) мы относим к определенному ЦФО. В документе ЗаявкаНаРасходДенежныхСредств реквизит ЦФО является обязательным для заполнения.
2. Настройка профиля пользователя: В настройках прав БИТ мы указываем для каждого руководителя список доступных ему ЦФО.
3. Механизм ограничения: Система автоматически отфильтрует список документов так, что руководитель увидит только те заявки, в которых указаны «его» подразделения. Проверить, какие именно роли дают право на просмотр документа конкретному пользователю, можно с помощью утилит для просмотра прав доступа.

Этот способ является наиболее «чистым» с точки зрения методологии, так как не требует изменения конфигурации. Если руководителю нужно видеть заявки смежных подразделений, мы просто добавляем соответствующие ЦФО в его профиль доступа.

Метод 2. Доступ через механизм визирования (маршруты согласования)

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

Проанализируем ситуацию: если руководитель участвует в цепочке согласования документа, он автоматически получает право на его просмотр. В настройках БИТ.ФИНАНС можно включить опцию «Чтение по участию в визировании». Это решит проблему доступа следующим образом:

• Сотрудник видит документ, так как он является Автором.
• Руководитель видит документ, так как он назначен Согласующим на одном из этапов маршрута.
• Руководитель смежного подразделения увидит документ только в том случае, если его роль или конкретное физлицо включены в маршрут для определенных условий (например, при превышении лимита или по специфической статье затрат). Чтобы детально разобраться, какой профиль дает доступ на этапе визирования, администраторы часто используют анализ прав доступа к объекту.

Метод 3. Реализация иерархического доступа через RLS и регистры

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

Посмотрим на структуру решения. Нам потребуется создать регистр сведений ДоступностьСотрудников со следующими измерениями:

• Руководитель (Тип: СправочникСсылка.Пользователи)
• Подчиненный (Тип: СправочникСсылка.Пользователи или СправочникСсылка.ФизическиеЛица)

Далее, в механизме RLS (Ограничение доступа на уровне записей) для документа ЗаявкаНаРасходДенежныхСредств прописывается запрос. Рассмотрим пример логики такого запроса:

ГДЕ Автор = &ТекущийПользователь
ИЛИ Автор В (
    ВЫБРАТЬ Рег.Подчиненный 
    ИЗ РегистрСведений.ДоступностьСотрудников КАК Рег 
    ГДЕ Рег.Руководитель = &ТекущийПользователь
)

Важный момент: Как отмечалось в обсуждении, методологически правильнее связывать права не с конкретными фамилиями (физлицами), а с Должностями или Штатными единицами. Это обеспечит преемственность доступа: когда один сотрудник увольняется и на его место приходит другой, новый руководитель автоматически получит доступ к архиву документов предшественника.

Метод 4. Настройка «Заместительства»

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

В БИТ.ФИНАНС при создании записи о заместительстве, пользователь-заместитель получает права (в том числе на просмотр документов), аналогичные правам замещаемого лица. Это позволяет гибко управлять доступом без внесения правок в программный код.

Практические советы по реализации

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

1. Отказ от фильтров в формах: Никогда не ограничивайте видимость документов только через отборы в динамических списках. Даже если существуют удобные расширения для контроля видимости элементов на форме, этот метод небезопасен. Проанализируем почему: пользователь сможет обойти такой фильтр через отчеты или консоль запросов. Настоящее ограничение должно работать на уровне RLS.
2. Использование аналитики «Проект»: Если сотрудники разных отделов должны видеть документы друг друга, проверьте, не объединены ли они общим проектом. В БИТ.ФИНАНС ограничение по Проектам настраивается аналогично ЦФО и часто является более логичным решением для «смежных» сотрудников.
3. Контроль производительности: При написании собственных запросов RLS через регистры иерархии, старайтесь избегать вложенных запросов большой вложенности, так как это может существенно замедлить открытие списков документов.

Подводя итог, для системы БИТ.ФИНАНС наиболее рациональным путем будет сначала максимально использовать возможности доступа по ЦФО и Визированию. Если же иерархия слишком специфична — внедряйте расширение с использованием регистра сведений, завязанного на штатные должности, а не на персональные данные сотрудников. Вне зависимости от выбранного пути, важно регулярно проводить администрирование и аудит пользователей, чтобы обеспечить корректность и безопасность действующих прав.