В практике работы с 1С:Бухгалтерия предприятия 3.0 (БП 3.0) часто возникает задача разграничения прав доступа. Типичный сценарий: в базе работают несколько менеджеров, каждый из которых должен видеть только те счета на оплату, которые он выставил самостоятельно. При этом бухгалтер должен сохранять полный доступ ко всем документам для корректного ведения учета.
Проблема осложняется тем, что 1С:БП 3.0 — это конфигурация, жестко завязанная на принципе двойной записи и целостности проводок. Ограничение доступа «на лету» может привести к ошибкам в отчетах или невидимости связанных данных. Рассмотрим несколько способов решения этой задачи: от самых простых пользовательских настроек до глубокой кастомизации через механизмы RLS и расширения.
Этот метод считается наиболее сбалансированным. Мы не меняем типовую конфигурацию, сохраняя возможность легкого обновления, и при этом жестко задаем правила видимости, которые пользователь не сможет обойти самостоятельно. Основная идея заключается в перехвате события создания формы списка и наложении фиксированного отбора на динамический список документов. Для реализации такого механизма без программирования можно использовать расширение для фильтрации документов продаж по ответственному.
Разберем ситуацию подробнее. Документ СчетНаОплатуПокупателю имеет реквизит Ответственный. Именно по этому полю мы и будем фильтровать данные. Создадим расширение и добавим в него форму списка документов «Счета покупателям». Нам понадобится обработчик события ПриСозданииНаСервере.
Проанализируем пример кода, который необходимо внедрить:
&НаСервере
Процедура Расш1_ПриСозданииНаСервереПосле(Отказ, СтандартнаяОбработка)
// Проверяем, не является ли пользователь администратором
Если Не РольДоступна("ПолныеПрава") Тогда
// Находим нужный элемент отбора в компоновщике настроек динамического списка
ОбщийОтбор = Список.КомпоновщикНастроек.ФиксированныеНастройки.Отбор.Элементы.Добавить(Тип("ЭлементОтбораКомпоновкиДанных"));
ОбщийОтбор.ЛевоеЗначение = Новый ПолеКомпоновкиДанных("Ответственный");
ОбщийОтбор.ВидСравнения = ВидСравненияКомпоновкиДанных.Равно;
ОбщийОтбор.ПравоеЗначение = ПараметрыСеанса.ТекущийПользователь;
ОбщийОтбор.Использование = Истина;
ОбщийОтбор.РежимОтображения = РежимОтображенияЭлементаНастройкиКомпоновкиДанных.Недоступный;
КонецЕсли;
КонецПроцедуры
В данном примере мы используем ФиксированныеНастройки. Это критически важный момент: такие отборы не отображаются в стандартном окне настроек списка пользователя, и он не может их отключить или изменить. Таким образом, менеджер при открытии журнала всегда будет видеть только свои документы.
Ограничение доступа на уровне записей (RLS) — это встроенный механизм платформы 1С, позволяющий ограничивать доступ к конкретным строкам таблиц базы данных. В обсуждениях часто звучит мнение, что использование RLS в «Бухгалтерии» не рекомендуется. Выясним причину этого опасения.
Основной риск RLS в БП 3.0 заключается в том, что если ограничить доступ к объектам, участвующим в проводках (например, к контрагентам или счетам учета), то бухгалтерские отчеты (ОСВ, карточка счета) начнут показывать «Объект не обнаружен» или вовсе выдавать неверные итоги, так как суммы по «невидимым» записям могут не включаться в расчет. Однако для документа СчетНаОплатуПокупателю этот риск минимален, так как данный документ в типовой БП 3.0 не является проводимым (не делает записей в регистры бухгалтерии). Он служит лишь печатной формой и основанием для последующих документов.
Рассмотрим, как настроить RLS правильно:
Важное примечание: В современных версиях 1С (8.3.18+) рекомендуется использовать «Производительный режим RLS». В этом режиме данные об ограничениях хранятся в специальных вспомогательных таблицах, что значительно ускоряет работу системы по сравнению со старым методом динамического формирования SQL-запросов с множественными вложениями.
Если в компании работает много менеджеров, логичнее настраивать доступ не к каждому конкретному пользователю, а к подразделению. Это упрощает администрирование: при приеме нового сотрудника достаточно добавить его в соответствующее подразделение, и он автоматически получит доступ к документам своего отдела.
Проанализируем шаги для реализации этой схемы:
Этот способ более «чистый» с точки зрения методологии 1С, так как подразделение часто является сквозным аналитическим разрезом во всей конфигурации. Если же возможностей текущей программы перестает хватать для полноценного управленческого учета, можно запланировать переход в более комплексную систему, выполнив перенос данных из БП 3.0 в КА 2.
Посмотрим на ситуацию со стороны пользователя. Как упоминалось в обсуждениях, можно просто вынести поле Ответственный в список и настроить обычный пользовательский фильтр. Мы можем даже скопировать эти настройки всем пользователям через меню Администрирование — Настройки пользователей и прав — Копирование настроек.
Однако у этого метода есть существенный минус: безопасность. Продвинутый пользователь может в любой момент нажать кнопку «Настроить список», снять галочку с отбора и увидеть документы всех коллег, включая суммы сделок и списки клиентов. Если политика компании подразумевает строгую конфиденциальность, этот метод не подходит.
При реализации любого из способов ограничения важно помнить о цепочке документов. Если менеджер видит только свой Счет на оплату, но при этом имеет полный доступ к списку Реализаций (актов, накладных) или Платежных поручений, он все равно сможет косвенно увидеть чужие продажи. Для комплексного разграничения прав подойдёт расширение для ограничения доступа к счетам и реализациям чужих авторов.
Рассмотрим вариант комплексного подхода:
Счет на оплату по ответственному (через RLS или расширение).Контрагенты. Это самый сложный момент в БП, так как контрагенты используются во всех проводках. Здесь лучше использовать вариант «чтение без права изменения» или программно скрывать чужих контрагентов только в формах выбора.Выясним, какой путь выбрать именно вам. Если вам нужно быстрое решение «здесь и сейчас» и вы не боитесь правок кода — используйте расширение с фиксированным отбором в динамическом списке. Это надежно и не влияет на производительность базы. Если же ваша компания требует стандартных методов администрирования и у вас настроен производительный режим RLS — используйте типовой механизм ограничений прав доступа по подразделениям или ответственным, предварительно убедившись, что это не «ломает» специфические бухгалтерские отчеты в вашем случае.
Помните, что любая настройка прав доступа должна заканчиваться тестированием под учетной записью обычного менеджера, чтобы убедиться в отсутствии критических ошибок типа «Нарушение прав доступа» при попытке провести связанный документ или сформировать печатную форму.