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

← На главную

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

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

Почему стандартные настройки не подходят?

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

Если мы просто создадим новую роль, ограничивающую доступ к справочнику, мы столкнемся с проблемой объединения ролей. В системе 1С права суммируются по принципу «ИЛИ». Если у пользователя есть хотя бы одна роль, разрешающая просмотр всех счетов (а такие права есть во многих стандартных ролях профиля «Бухгалтер»), то ваша новая ограничивающая роль просто не сработает.

Способ 1. Визуальное скрытие через программные отборы

Разберем вариант, который часто называют «быстрым», но не самым безопасным. Его суть заключается в установке принудительного фильтра в формах списка и формах выбора справочника БанковскиеСчета. Для этого используется метод глобального общего модуля ОбщегоНазначенияКлиентСервер.УстановитьЭлементОтбораДинамическогоСписка.

Проанализируем пример кода, который можно разместить в процедуре ПриСозданииНаСервере формы списка:


// Установка отбора по конкретной ссылке или списку ссылок
ОбщегоНазначенияКлиентСервер.УстановитьЭлементОтбораДинамическогоСписка(
    Список, 
    "Ссылка", 
    ДопустимыйСчетСсылка, 
    ВидСравненияКомпоновкиДанных.Равно
);

Важные нюансы этого метода:

Этот способ скрывает счета только в конкретной форме списка. Если пользователь откроет документ, где выбран другой счет, он сможет «провалиться» в него по ссылке.
Для полной блокировки придется дописывать проверку в модуле объекта или форме элемента справочника при открытии.
В отчетах (например, в ОСВ по счету 51) данные по скрытым счетам все равно будут видны, так как динамический список формы никак не влияет на запросы к регистрам бухгалтерии.

Способ 2. Полноценное ограничение доступа на уровне записей (RLS)

Рассмотрим более фундаментальный подход. Чтобы пользователь действительно «не видел» данные ни в списках, ни в отчетах, ни в документах, необходимо использовать механизм RLS. Выясним, как правильно реализовать это в современной конфигурации, не снимая её с поддержки.

Шаг 1. Создание расширения. Все доработки крайне рекомендуется делать в расширении. Создадим новое расширение и добавим в него новую роль (например, ОграничениеДоступаПоБанковскимСчетам).

Шаг 2. Настройка шаблона ограничений. В новой роли для справочника БанковскиеСчета на право «Чтение» необходимо прописать запрос ограничения. Посмотрим на логику условия:


ГДЕ Ссылка = &ДопустимыйБанковскийСчет
ИЛИ ЭтоГруппа = ИСТИНА

Однако использование жестких ссылок в коде — плохая практика. Проанализируем более профессиональный подход с использованием параметров сеанса. Вы можете создать параметр сеанса РазрешенныеБанковскиеСчета (типа ФиксированныйМассив) и заполнять его при старте системы, основываясь, например, на данных дополнительного регистра сведений.

Шаг 3. Включение производительного режима. В платформе 8.3.15 и выше рекомендуется использовать производительный режим RLS. Разберем его преимущество: вместо добавления подзапросов к каждому обращению, система создает вспомогательную таблицу прав. Это критично для БП 3.0, так как сложные RLS могут значительно замедлить формирование оборотно-сальдовой ведомости.

Проблема «разрыва» учета в бухгалтерских отчетах

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

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

Альтернатива: Использование функциональных опций

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

Резюме

Выбор метода зависит от строгости требований безопасности:

Если нужно строго запретить доступ (даже просмотр отчетов) — используем RLS в производительном режиме через расширение, но помним про искажение сальдо в отчетах.
Если нужно удобство работы (чтобы лишнее не мешалось под рукой) — используем программные отборы в формах списка и выбора через ОбщегоНазначенияКлиентСервер.

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