Довольно часто перед разработчиками и администраторами баз данных 1С встает задача: как скрыть информацию о заработной плате руководства от рядовых сотрудников бухгалтерии. Кажется логичным использовать механизм ограничения прав доступа на уровне записей (RLS) и настроить его по конкретному субконто (например, Сотрудники) на 70 счете. Давайте подробно разберем эту ситуацию, проанализируем технические ограничения платформы и рассмотрим правильные пути решения этой непростой задачи.
Первое, с чем мы сталкиваемся при попытке решить задачу "в лоб" — это архитектурные особенности платформы 1С. Выясним причину, по которой стандартный механизм RLS не подходит для скрытия данных по конкретному счету учета.
Дело в том, что механизм RLS эффективно работает только по измерениям регистров. В случае с регистром бухгалтерии стандартными балансовыми измерениями выступают, например, Организация или Подразделение. Сам по себе Счет или вид субконто не являются измерениями регистра в классическом понимании физической структуры таблиц базы данных. Из-за этих архитектурных ограничений платформы данные с сервера SQL всегда будут передаваться целиком. Попытка отсечь их исключительно по 70 счету через стандартные настройки RLS просто не сработает.
Проанализируем ситуацию дальше. Некоторые разработчики, столкнувшись с невозможностью настроить RLS по субконто, приходят к идее: "А давайте добавим новое балансовое измерение в регистр бухгалтерии специально под RLS!". Разберем по шагам, почему это крайне плохая идея, которая приведет к катастрофическим последствиям для вашей базы.
Посмотрим на методологически правильное решение, которое рекомендует сама фирма "1С". Самый надежный способ защитить зарплатные данные — это изначально не тащить детализацию в бухгалтерскую базу.
Как это реализовать на практике? Расчет заработной платы должен вестись в специализированной программе (например, "1С:Зарплата и управление персоналом"). При настройке синхронизации данных между зарплатной и бухгалтерской базами необходимо выбрать режим выгрузки Сводно по сотрудникам.
В этом случае в бухгалтерию вообще не будут попадать данные по конкретным физическим лицам. Все проводки по начислению зарплаты, НДФЛ и взносов формируются общими, обезличенными суммами. Детальная информация по каждому человеку остается исключительно в кадровой базе, доступ к которой строго регламентирован и предоставляется только расчетчикам и руководителю.
Но что делать, если детальные данные по зарплате уже имеются в бухгалтерии, и удалить их по каким-то причинам невозможно? Рассмотрим технические обходные пути. В таких случаях программисты используют не тяжелый RLS на уровне базы данных, а интерфейсные ограничения с помощью механизма расширений конфигурации.
Разберем основные методы защиты на уровне интерфейса:
ДоступКЗарплате) в запросы отчетов принудительно вшивается условие, исключающее 70 счет из результатов. Можно даже пойти простым путем: полностью запретить формирование оборотно-сальдовой ведомости по счету 70 для определенных пользователей.Конечно, стоит учитывать, что скрытие данных на уровне отчетов и форм — это не полноценная защита на уровне СУБД. Продвинутый пользователь теоретически может попытаться найти обходной путь (например, если у него есть доступ к универсальному отчету или консоли запросов). Однако на практике от рядовых сотрудников бухгалтерии эти интерфейсные ограничения защищают вполне надежно.
В заключение, если руководство категорически настаивает на хранении детальных данных в бухгалтерии, но при этом требует скрыть зарплаты, иногда самым эффективным оказывается организационное решение. Как шутят на форумах: "Пусть ваши топы свыкнутся с мыслью, что бухгалтеры видят их зарплату — все так живут". Но если действовать технически грамотно — переходите на сводные проводки, это избавит вас от множества проблем с производительностью и безопасностью данных.