В практической деятельности крупных и средних предприятий часто возникает необходимость разграничения прав доступа. Одна из наиболее популярных задач в этой сфере — скрыть от рядовых сотрудников (например, бухгалтеров на первичной документации или менеджеров) информацию о движении денежных средств на банковских счетах (счет 51) и в кассе компании (счет 50). При этом у пользователей должен оставаться полноценный доступ к остальным разделам учета для выполнения их повседневных обязанностей.
В этой статье мы подробно разберем, почему стандартные механизмы ограничения доступа на уровне записей (RLS) в типовой конфигурации «1С:Бухгалтерия 3.0» не позволяют решить эту задачу «из коробки», проанализируем технические сложности и рассмотрим три практических способа реализации такого ограничения с помощью расширения конфигурации.
Для начала выясним причину, по которой типовой механизм ограничения доступа на уровне записей (RLS) не решает задачу напрямую. Технология платформы «1С:Предприятие 8» накладывает жесткие архитектурные рамки на работу с регистрами бухгалтерии:
Организация. Поля СчетДт (Счет дебета) и СчетКт (Счет кредита) являются системными реквизитами проводки, а не измерениями регистра. Платформа физически не позволяет настроить RLS на чтение регистра бухгалтерии с условием по конкретному счету.Хозрасчетный), это приведет к серьезным ошибкам интерфейса. При формировании стандартных отчетов (например, Оборотно-сальдовой ведомости) пользователь вместо номеров счетов увидит надпись <Объект не найден...>. При этом сами суммы проводок никуда не исчезнут, так как физические записи в регистре бухгалтерии по-прежнему доступны для чтения.счету 60 или с покупателями по счету 62), сотрудник легко поймет, куда ушли или откуда пришли деньги.Таким образом, для качественного решения задачи нам потребуется кастомизация системы. Рассмотрим подробнее основные варианты технической реализации с помощью механизма расширений, который позволяет сохранить конфигурацию на поддержке и гарантирует простоту последующих обновлений.
---
Этот подход является наиболее безопасным и производительным. Он не затрагивает структуру базы данных и не снижает скорость проведения документов. Мы будем программно модифицировать настройки Системы компоновки данных (СКД) при формировании стандартных отчетов.
Проанализируем ситуацию: все стандартные отчеты в «1С:Бухгалтерия 3.0» (ОСВ, ОСВ по счету, Карточка счета, Анализ счета) строятся на базе СКД. Мы можем создать расширение и перехватить процедуру компоновки результата отчета, принудительно добавив туда отбор, исключающий 50 и 51 счета.
Разберем по шагам, как это реализовать:
1. Создайте новое расширение конфигурации и добавьте в него общий модуль или перехватите модуль менеджера необходимых отчетов.
2. Внедрите обработчик события компоновки результата. Посмотрим на пример кода, который добавляет жесткий отбор в настройки компоновщика:
Процедура ПередКомпоновкойРезультата(РежимВывода) Экспорт
// Проверяем, нужно ли применять ограничение для текущего пользователя
Если РольДоступна("ПолныеПрава") Тогда
Возврат; // Администраторам и главбухам разрешено видеть всё
КонецЕсли;
// Находим или создаем группу отборов в компоновщике
ГруппаОтбора = КомпоновщикНастроек.Настройки.Отбор.Элементы;
// Создаем новый элемент отбора для исключения счетов кассы и банка
НовыйОтбор = ГруппаОтбора.Добавить(Тип("ЭлементОтбораКомпоновкиДанных"));
НовыйОтбор.ЛевоеЗначение = Новый ПолеКомпоновкиДанных("Счет");
НовыйОтбор.ВидСравнения = ВидСравненияКомпоновкиДанных.НеВГруппеИзСписка;
СписокСчетов = Новый СписокЗначений;
СписокСчетов.Добавить(ПланыСчетов.Хозрасчетный.Касса, "50");
СписокСчетов.Добавить(ПланыСчетов.Хозрасчетный.РасчетныеСчета, "51");
НовыйОтбор.ПравоеЗначение = СписокСчетов;
НовыйОтбор.Использование = Истина;
// Блокируем изменение этого отбора пользователем в интерфейсе
НовыйОтбор.РежимОтображения = РежимОтображенияЭлементаНастройкиКомпоновкиДанных.Недоступный;
КонецПроцедуры
Важные нюансы при использовании этого метода:
Универсальному отчету, так как с его помощью можно обойти установленные фильтры и прочитать записи регистра напрямую.Режим "Панель функций для технического специалиста" (в старых версиях — «Все функции»), чтобы исключить возможность открытия таблицы регистра бухгалтерии напрямую.---
Если требуется абсолютная безопасность на уровне базы данных (чтобы данные нельзя было извлечь даже через внешние отчеты или API), придется использовать более радикальный метод. Он заключается в добавлении дополнительного балансового измерения в регистр бухгалтерии Хозрасчетный.
Рассмотрим этот алгоритм по шагам:
1. Через расширение конфигурации добавьте в регистр бухгалтерии Хозрасчетный новое измерение. Назовем его, например, Доступ Ограничен с типом данных Булево.
2. Создайте подписку на событие ПередЗаписью для набора записей регистра бухгалтерии. В обработчике подписки мы будем анализировать проводки. Если в проводке задействован 50 или 51 счет, мы будем устанавливать признак ограничения в значение Истина.
Посмотрим на пример реализации кода подписки:
Процедура ОпределитьДоступностьПроводкиПередЗаписью(Источник, Отказ, Замещение) Экспорт
Для Каждого Проводка Из Источник Цикл
// Проверяем дебет и кредит проводки
Если Проводка.СчетДт.ПринадлежитГруппе(ПланыСчетов.Хозрасчетный.Касса)
Или Проводка.СчетДт.ПринадлежитГруппе(ПланыСчетов.Хозрасчетный.РасчетныеСчета)
Или Проводка.СчетКт.ПринадлежитГруппе(ПланыСчетов.Хозрасчетный.Касса)
Или Проводка.СчетКт.ПринадлежитГруппе(ПланыСчетов.Хозрасчетный.РасчетныеСчета) Тогда
// Если задействован 50 или 51 счет, помечаем проводку как скрытую
Проводка.ДоступОграничен = Истина;
Иначе
Проводка.ДоступОграничен = Ложь;
КонецЕсли;
КонецЦикла;
КонецПроцедуры
3. Настройте ограничение доступа на уровне записей (RLS) для роли целевого пользователя. В шаблоне ограничений для регистра бухгалтерии укажите условие:
ГДЕ ДоступОграничен = ЛОЖЬ
Преимущества метода: Данные защищены на уровне СУБД. Ни один отчет, консоль запросов или внешняя обработка не смогут прочитать эти записи под правами ограниченного пользователя.
Минусы метода: Любое изменение структуры регистра бухгалтерии в крупных базах данных может привести к существенному замедлению работы при проведении документов и реструктуризации базы во время обновлений. Кроме того, могут возникнуть сложности с регламентными операциями закрытия месяца, если они выполняются под правами пользователя с ограничениями.
---
Если жесткой необходимости в шифровании данных нет, а требуется лишь оградить сотрудника от случайного просмотра конфиденциальной информации и работы с «чужими» документами, можно ограничиться настройкой интерфейса и ролей.
Проанализируем шаги для реализации этого варианта:
Поступление на расчетный счет, Списание с расчетного счета, Приходный кассовый ордер и Расходный кассовый ордер.Банк и касса на панели разделов.Этот способ самый простой в поддержке, но помните: технически подкованный пользователь сможет обойти такие ограничения, если у него останется доступ к СКД-отчетам или консоли запросов.
---
В завершение анализа проблемы необходимо поднять ключевой вопрос методологии бухгалтерского учета. Из-за принципа двойной записи любая хозяйственная операция отражается одновременно по дебету одного счета и кредиту другого.
Даже если вы идеально заблокируете отображение счетов 50 и 51 во всех отчетах, у пользователя останется доступ к расчетам с контрагентами (счета 60, 62, 76) или расчетам по оплате труда (счет 70). Открыв ОСВ по счету 60, сотрудник увидит дебетовые обороты (оплату поставщикам), которые в 99% случаев корреспондируют именно с 51 счетом (расчетные счета). Таким образом, конфиденциальные суммы выплат все равно будут раскрыты.
Резюме: Полностью скрыть финансовые потоки в единой базе «1С:Бухгалтерия 3.0» практически невозможно без критического урезания прав пользователя на просмотр смежных участков учета. Наиболее жизнеспособным компромиссом является комбинация первого способа (программная модификация СКД стандартных отчетов через расширение) и отключение прав на просмотр первичных платежных документов.