← На главную

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

Ограничения типового функционала и Библиотеки стандартных подсистем

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

При попытке реализовать такую настройку типовыми средствами мы сталкиваемся со следующими архитектурными особенностями платформы 1С:

1. Аддитивность прав доступа: права в платформе 1С всегда объединяются по логическому правилу «ИЛИ». Если пользователю назначена хотя бы одна базовая роль, в которой разрешено чтение документа без ограничения RLS, система предоставит доступ ко всем документам независимо от других назначенных ролей.
2. Разделение прав на редактирование и просмотр: стандартная дата запрета изменения данных блокирует только проведение, запись и удаление документов, но оставляет их полностью открытыми для чтения и формирования отчетов.

Технические риски и подводные камни ограничения доступа по дате

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

1. Появление битых ссылок (<Объект не найден>): документы прошлых периодов часто выступают аналитикой (субконто) в текущих проводках и взаиморасчетах — например, документы расчетов с контрагентами или партии поступления материалов. Если платформа запрещает пользователю чтение этих документов, во всех отчетах, журналах и формах текущего периода вместо названий документов будет отображаться строка <Объект не найден> с уникальным идентификатором.
2. Ошибки при проведении документов: алгоритмы списания себестоимости (по ФИФО), зачета авансов или регламентные операции закрытия месяца могут считывать реквизиты и движения документов заблокированных периодов. При отсутствии прав на чтение этих объектов проведение документов текущего периода завершится системной ошибкой нарушения прав доступа.
3. Падение производительности: добавление сложных условий RLS по полю Дата в таблицы документов и связанные регистры отключает часть оптимизаций СУБД, что может вызвать существенное замедление работы динамических списков и тяжелых отчетов.

Вариант 1. Разработка собственного RLS по дате

Рассмотрим вариант реализации полноценного ограничения на уровне записей через расширение конфигурации или изменение ролей:

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

Вариант 2. Визуальное скрытие в динамических списках (через расширение)

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

Разберем по шагам, как это работает:

1. В расширении подключаемся к событию ПриСозданииНаСервере форм списков и журналов документов.
2. Программно добавляем фиксированный отбор в свойство Список.Отбор или модифицируем текст запроса динамического списка:
   Скопировать код

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

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

Вариант 3. Свертка информационной базы или создание РИБ

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

1. Создаем копию информационной базы и выполняем стандартную процедуру свертки на начало требуемого периода (например, на 01.01.2016).
2. При свертке все движения прошлых лет сворачиваются во входящие остатки с помощью документов Ввод остатков или Корректировка записей регистров.
3. Для документов, оставшихся в качестве субконто (партии, расчетные документы), при необходимости выполняется замена ссылок на служебные объекты ввода остатков, после чего старые документы полностью удаляются из базы.
4. Пользователь работает в отдельной свернутой базе, где данные за 2014–2015 годы физически отсутствуют.