Как ограничить доступ к остаткам по кассе с сохранением возможности ввода документов в 1С:Управление торговлей?

В практической работе с конфигурацией «1С:Управление торговлей» нередко возникает задача: кассир или менеджер должен оформлять приходные и расходные кассовые ордера, но при этом не должен видеть текущий остаток денежных средств в кассе — ни в отчетах, ни в журналах документов, ни в интерфейсе программы. Разберем особенности реализации этой задачи, выясним системные ограничения и рассмотрим основные варианты решения.

Почему не подходит стандартное ограничение по справочнику «Кассы»

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

1. Ограничение по справочнику Кассы запрещает пользователю чтение самого элемента справочника.
2. Если кассиру закрыт доступ к конкретной кассе на уровне справочника, программа не позволит даже выбрать эту кассу в документах «Приходный кассовый ордер» или «Расходный кассовый ордер».
3. Пользователь потеряет возможность видеть в списках и журналах уже созданные по этой кассе документы.

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

Вариант 1. Ограничение на уровне записей (RLS) к регистру остатков

Рассмотрим подход с установкой RLS на чтение регистра накопления. В «1С:Управление торговлей 11» остатки наличных денег хранятся в регистре накопления ДенежныеСредстваНаличные (в УТ 10.3 — в регистре ДенежныеСредства).

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

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

Посмотрим на пример текста условия ограничения:

ГДЕ НЕ ДенежныеСредстваНаличные.Касса В (&КассыЗапретаОстатков)

Подводные камни и риски использования RLS на регистр:

1. Проведение документов и контроль остатков. При проведении расходных кассовых ордеров типовые механизмы обращаются к таблице остатков регистра для контроля отрицательных остатков. Если в конфигурации контроль выполняется без включения привилегированного режима (через вызов УстановитьПривилегированныйРежим(Истина)), то кассир при попытке провести расходный ордер получит ошибку «Нарушение прав доступа» либо ложное сообщение о нехватке денег в кассе (система увидит нулевой остаток). В УТ 11 проведение большинства документов вынесено в серверные привилегированные модули, однако в УТ 10.3 контроль остатков выполняется в контексте прав текущего пользователя, что потребует доработки кода проведения.
2. Запросы без ключевого слова РАЗРЕШЕННЫЕ. Если в нетиповых отчетах, обработках или динамических списках выполняется обращение к регистру без конструкции ВЫБРАТЬ РАЗРЕШЕННЫЕ, система вызовет критическое исключение при открытии формы.
3. Производительность. Наложение RLS на регистры накопления с постоянным обращением к виртуальным таблицам остатков создает дополнительную нагрузку на СУБД, так как к каждому запросу добавляется проверка прав по строкам.

Вариант 2. Ограничение через ролевую модель без RLS

Если на предприятии нет жесткого требования блокировать доступ к таблице на уровне СУБД, рассмотрим более надежный и производительный вариант: разделение прав на уровне объектов метаданных.

Разберем данный подход по шагам:

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

При таком подходе документы будут проводиться штатно, механизм контроля отрицательных остатков не пострадает, а производительность базы данных останется максимальной.

Вариант 3. Скрытие остатков на формах через расширение конфигурации

В современных версиях «1С:Управление торговлей» текущий остаток по кассе часто выводится динамически в виде надписи или реквизита на форме журнала кассовых документов либо в окне документа. Чтобы скрыть эти данные от кассира без снятия конфигурации с поддержки, применим расширение конфигурации.

Рассмотрим пример скрытия элемента формы при ее инициализации. Создаем расширение и перехватываем событие ПриСозданииНаСервере формы журнала или документа:

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

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