Вопрос обеспечения конфиденциальности данных о заработной плате является одним из самых острых при автоматизации бухгалтерского учета. Часто возникает ситуация, когда рядовым бухгалтерам необходим доступ к базе для ведения учета по другим участкам, но руководство требует скрыть информацию о доходах сотрудников. В этой статье мы подробно разберем, как ограничить видимость аналитики по счету 70 в «1С:Бухгалтерия 3.0» (БП 3.0), не прибегая к сложному и ресурсоемкому механизму RLS (Row Level Security), который может существенно замедлить работу системы.
Самый правильный и надежный способ скрыть персональные данные в бухгалтерской базе — это перестать их туда передавать. Если в организации используется «1С:Зарплата и управление персоналом 8» (ЗУП), то детальный учет по каждому сотруднику должен вестись именно там. В бухгалтерию же данные должны попадать в агрегированном виде.
Разберем алгоритм перехода на сводный учет:
Важное замечание: При изменении этой настройки система выдаст предупреждение о том, что данные в разрезе сотрудников на счете 70 будут потеряны. Это именно то, чего мы добиваемся. Поскольку первичные данные и детальные расчеты хранятся в ЗУП, в бухгалтерии нам достаточно видеть общие суммы начислений и выплат для формирования баланса и налоговой отчетности.
После смены настройки на «Сводно», субконто РаботникиОрганизации на счете 70 станет неактивным, и во всех отчетах (ОСВ по счету, карточка счета) суммы будут отражаться одной строкой.
Часто после включения сводного учета пользователи сталкиваются с проблемой: в документах Списание с расчетного счета в поле «Назначение платежа» всё равно фигурируют ФИО сотрудников, если банк присылает подтверждение по каждому платежу отдельно. Это происходит, когда выплаты идут не через зарплатный проект, а индивидуальными платежками.
Рассмотрим, как это исправить через настройку зарплатного проекта:
Ведомость в банк. При использовании зарплатного проекта банк списывает общую сумму ведомости одним платежным поручением.Списание с расчетного счета в качестве получателя будет указан банк, а в назначении платежа — «Перечисление заработной платы по реестру №...». Таким образом, детализация по сотрудникам исчезнет из банковской выписки.Если же выплаты идут на карты разных банков (не в рамках проекта), проанализируем возможность использования транзитного счета. Вместо прямого перечисления Дт 70 — Кт 51 можно использовать схему через счет 76.10 или 76.05. В этом случае в БП заводится технический контрагент «Все сотрудники», и выплаты обезличиваются на уровне проводок.
Если методологические способы не подходят и вам необходимо оставить аналитику по сотрудникам в базе, но скрыть ее от определенных пользователей, мы можем применить механизм расширений. Это позволит нам вмешаться в процесс формирования представления объектов без изменения основной конфигурации.
Проанализируем ситуацию: нам нужно, чтобы пользователи с определенной ролью вместо реальных ФИО видели текст «***» или «Данные скрыты». Для этого воспользуемся обработчиками событий в менеджере справочника Сотрудники или ФизическиеЛица.
Пример кода для расширения (модуль менеджера справочника Сотрудники):
&НаСервере
Процедура ОбработкаПолученияПредставления(Данные, Представление, СтандартнаяОбработка)
// Проверяем наличие специальной роли у пользователя
Если НЕ РольДоступна("ПолныеПрава") И НЕ РольДоступна("ПросмотрЗарплаты") Тогда
СтандартнаяОбработка = Ложь;
Представление = "Сотрудник [ДАННЫЕ СКРЫТЫ]";
КонецЕсли;
КонецПроцедуры
&НаСервере
Процедура ОбработкаПолученияПолейПредставления(Поля, СтандартнаяОбработка)
// Мы можем принудительно изменить состав полей, участвующих в представлении
СтандартнаяОбработка = Ложь;
Поля.Добавить("Код");
КонецПроцедуры
Этот метод хорош тем, что он подменяет визуальное отображение сотрудника во всех динамических списках, отчетах и формах документов, но при этом в самой базе данных значения остаются неизменными. Однако помните, что продвинутый пользователь всё равно сможет увидеть данные через консоль запросов, если у него есть права на чтение справочника.
Разберем еще один способ — программное ограничение выбора счета 70 в стандартных отчетах. Мы можем создать расширение для формы настройки отчета ОборотноСальдоваяВедомостьПоСчету.
Посмотрим на пример логики, которую можно реализовать в расширении формы:
&НаСервере
Процедура ПослеСозданияНаСервере(Отказ, СтандартнаяОбработка)
// Проверяем роль текущего пользователя
Если Пользователи.РолиДоступны("БухгалтерБезЗарплаты") Тогда
// Если пользователь пытается выбрать счет 70, очищаем выбор или выдаем ошибку
Если Отчет.Счет = ПланыСчетов.Хозрасчетный.РасчетыСПерсоналомПоОплатеТруда Тогда
Отчет.Счет = ПланыСчетов.Хозрасчетный.ПустаяСсылка();
Сообщить("У вас недостаточно прав для формирования отчета по данному счету!");
КонецЕсли;
КонецЕсли;
КонецПроцедуры
Данный подход не является полноценной защитой данных, но он создает эффективный барьер для рядового пользователя, не позволяя ему стандартными средствами программы просматривать обороты по «запретному» счету.
Выясним, как правильно настроить права доступа, чтобы минимизировать риски. Вместо того чтобы редактировать типовые роли, создадим новый Профиль групп доступа.
ЧтениеЗарплаты, ДобавлениеИзменениеДанныхЗарплаты) и снимем с них флажки.УправлениеДоступомПереопределяемый, где можно прописать программное исключение ролей из типовых профилей. Это более профессиональный подход, который сохранит работоспособность системы после обновлений.Мы рассмотрели несколько уровней защиты данных по счету 70. Подведем итоги:
ОбработкаПолученияПредставления.Выбор конкретного метода зависит от технических возможностей вашего штата и критичности требований безопасности. Сочетание методологических и технических мер позволит добиться требуемого уровня конфиденциальности без использования RLS и падения производительности системы.