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

← На главную

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

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

Метод 1. Настройка параметров учета (Методический подход)

Прежде чем приступать к программированию, рассмотрим наиболее простой и «чистый» с точки зрения методологии 1С способ. Если основная цель — скрыть персональные данные сотрудников (кто сколько получил), мы можем изменить детализацию учета на 70-м счете.

Разберем этот процесс по шагам:

Перейдем в раздел Зарплата и кадры — Настройки зарплаты.
В пункте Общие настройки найдем гиперссылку Порядок учета зарплаты.
На вкладке Зарплата установим переключатель В этой программе или Во внешней программе.
Главный параметр здесь — Способ учета расчетов с персоналом. Если установить значение Сводно по всем сотрудникам, то в проводках по счету 70 вместо конкретных фамилий будет отображаться пустое субконто или техническое значение «Все работники».

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

Метод 2. Программная фильтрация через расширение конфигурации

Если нам нужно именно скрыть документы из журналов и списков «Банковские выписки», наиболее эффективным и быстрым способом будет использование расширения. Мы воспользуемся механизмом перехвата события ПриСозданииНаСервере для формы списка.

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


&НаСервере
Процедура Расш1_ПриСозданииНаСервереПосле(Отказ, СтандартнаяОбработка)
    
    // Определим список запрещенных операций
    ЗапрещенныеОперации = Новый Массив;
    ЗапрещенныеОперации.Добавить(Перечисления.ВидыОперацийСписаниеДенежныхСредств.ПеречислениеЗаработнойПлатыПоВедомостям);
    ЗапрещенныеОперации.Добавить(Перечисления.ВидыОперацийСписаниеДенежныхСредств.ПеречислениеЗаработнойПлатыРаботнику);
    
    // Находим элемент компоновки данных для отбора
    ОбщийОтбор = Список.КомпоновкаДанных.Настройки.Отбор;
    
    // Проверим, нет ли уже такого отбора, чтобы не дублировать
    Для Каждого ЭлементОтбора Из ОбщийОтбор.Элементы Цикл
        Если ТипЗнч(ЭлементОтбора) = Тип("ЭлементОтбораКомпоновкиДанных") 
            И ЭлементОтбора.ЛевоеЗначение = Новый ПолеКомпоновкиДанных("ВидОперации") Тогда
            ОбщийОтбор.Элементы.Удалить(ЭлементОтбора);
        КонецЕсли;
    КонецЦикла;

    // Добавляем новый фиксированный отбор
    НовыйЭлемент = ОбщийОтбор.Элементы.Добавить(Тип("ЭлементОтбораКомпоновкиДанных"));
    НовыйЭлемент.ЛевоеЗначение = Новый ПолеКомпоновкиДанных("ВидОперации");
    НовыйЭлемент.ВидСравнения = ВидСравненияКомпоновкиДанных.НеВСписке;
    НовыйЭлемент.ПравоеЗначение = ЗапрещенныеОперации;
    НовыйЭлемент.Использование = Истина;
    НовыйЭлемент.РежимОтображения = РежимОтображенияЭлементаНастройкиКомпоновкиДанных.Недоступный;

КонецПроцедуры

Важный нюанс: данный метод является «косметическим». Документы исчезнут из основного списка, но останутся доступными через универсальные отчеты, консоль запросов или ссылки в других документах. Тем не менее, для 90% повседневных задач бухгалтерии этого решения достаточно.

Метод 3. Использование механизма RLS (Row Level Security)

Для обеспечения реальной безопасности данных на уровне платформы необходимо использовать RLS. Этот механизм позволяет ограничивать чтение данных на уровне СУБД. В современных версиях платформы (8.3.15+) рекомендуется использовать производительный режим ограничений.

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

Создать новую роль в расширении.
Для объекта Документ.СписаниеСРасчетногоСчета в правах на Чтение прописать шаблон ограничения.
Шаблон будет выглядеть примерно так: ГДЕ ВидОперации <> Значение(Перечисление.ВидыОперацийСписаниеДенежныхСредств.ПеречислениеЗаработнойПлатыПоВедомостям).

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

Метод 4. Ограничение доступа к регистрам

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

Рассмотрим, как это реализовать:

Создаем копию профиля Бухгалтер.
Исключаем из него роли, дающие доступ к просмотру зарплатных регистров.
Проверяем, чтобы у пользователя не было полных прав, так как они игнорируют любые ограничения RLS и настройки ролей.

Проблема «информационных утечек» через отчеты

Нужно понимать, что скрытие документа — это только половина дела. Опытный пользователь может увидеть данные через другие механизмы. Разберем их подробнее:

История (кнопка «часики»): Если документ был создан или открыт ранее, он сохранится в истории. Ограничение в форме списка здесь не поможет, сработает только RLS или программный запрет открытия формы.
Оборотно-сальдовая ведомость (ОСВ): Если бухгалтер имеет право формировать ОСВ по счету 70, он увидит суммы выплат. Даже если он не сможет открыть сам документ, итоговые цифры по дебету и кредиту будут ему доступны.
Глобальный поиск: Поиск по всей конфигурации может индексировать данные документов. Для полной изоляции необходимо настраивать область поиска.

Итоговые рекомендации

Для решения задачи мы рекомендуем комбинированный подход:

Использовать расширение для фильтрации динамических списков (это уберет документы из глаз пользователя и снизит вероятность случайного доступа).
Настроить права доступа к регистрам, чтобы при попытке «провалиться» в документ пользователь видел минимум информации.
Если безопасность критична — использовать производительный RLS по полю ВидОперации, предварительно протестировав скорость работы системы на больших объемах данных.

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