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

← На главную

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

Подводные камни ограничения доступа к документам прошлых периодов через RLS

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

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

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

Реализация RLS по дате через параметры сеанса

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

Разберем по шагам порядок реализации:

В ветке конфигуратора Общие > Параметры сеанса создаем новый параметр, например НачалоТекущегоГода с типом Дата.
Переходим в модуль сеанса конфигурации. В обработчике УстановкаПараметровСеанса прописываем установку значения. Важно учитывать, что в современных конфигурациях на базе БСП (Библиотеки стандартных подсистем) параметры сеанса инициализируются по требованию. Код установки должен выглядеть следующим образом:


Процедура УстановкаПараметровСеанса(ИменаПараметровСеанса)
    
    Если ИменаПараметровСеанса = Неопределено 
       Или ИменаПараметровСеанса.Найти("НачалоТекущегоГода") <> Неопределено Тогда
        ПараметрыСеанса.НачалоТекущегоГода = НачалоГода(ТекущаяДатаСеанса());
    КонецЕсли;

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

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

Далее перейдем к настройке роли. Создаем новую роль (или расширение с ролью) и для требуемых видов документов на право Чтение настраиваем условие ограничения доступа:

ГДЕ Документ.Дата >= &НачалоТекущегоГода

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


ГДЕ Выбор 
    Когда &НачалоТекущегоГода = ДатаВремя(1, 1, 1) Тогда Истина 
    Иначе Документ.Дата >= &НачалоТекущегоГода 
КОНЕЦ

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

Альтернативные безопасные решения без изменения прав на уровне СУБД

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

Вариант 1. Запрет редактирования через типовую «Дату запрета изменения»

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

Переходим в раздел Администрирование > Настройки пользователей и прав > Даты запрета изменения.
Включаем функционал и нажимаем Настроить.
Устанавливаем дату запрета в разрезе конкретных пользователей или групп (например, «Конец прошлого года»).

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

Вариант 2. Скрытие документов на уровне интерфейса через расширение

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

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

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