В процессе работы в 1С:Управление торговлей (УТ) 11.3 часто возникает ситуация, когда необходимо ограничить права менеджеров так, чтобы они могли просматривать все документы продаж (Заказы клиентов, Реализации товаров и услуг), но редактировать могли только свои. Это критически важно для корректного расчета бонусов, предотвращения случайного изменения данных и обеспечения персональной ответственности за сделки.
В рамках данной статьи мы разберем несколько способов решения этой задачи: от простых организационных мер до технических настроек системы и использования механизмов расширений. Мы проанализируем ситуацию с разных сторон и выберем оптимальный путь.
Самый простой и зачастую самый действенный инструмент — это административный регламент. Если в компании небольшое количество сотрудников, иногда проще внедрить систему контроля, чем вносить изменения в программный код.
Рассмотрим, как реализовать этот подход технически:
Ответственный заполнено другим сотрудником. За нарушение — дисциплинарная ответственность.Разберем преимущество этого метода: система будет хранить все версии документа. Если менеджер Иванов изменил документ менеджера Петрова, в отчете "История изменений" вы сразу увидите, какое именно поле было изменено и под чьей учетной записью. Это позволяет быстро выяснить причину вмешательства в чужую сделку.
Если мы хотим, чтобы сама программа блокировала попытки записи, проанализируем штатные возможности RLS (Record Level Security). В типовой УТ 11.3 нет прямой настройки "Запретить редактировать, если я не ответственный", но есть обходные пути через группы доступа.
Вариант А: Группы доступа партнеров.
Рассмотрим ситуацию: мы можем разделить клиентов (партнеров) по группам доступа. Если за каждым менеджером закреплен свой пул клиентов, мы создаем группы доступа партнеров, называем их по фамилиям менеджеров и в профилях групп доступа ограничиваем видимость/редактирование по этим группам.
Однако здесь есть минус: если с одним контрагентом работают два менеджера, этот способ потребует создания дублей партнеров, что может привести к "помойке" в справочнике.
Вариант Б: Использование подразделений.
Посмотрим на поле Подразделение. В настройках пользователей и прав можно настроить ограничение доступа по подразделениям. Если создать для каждого менеджера отдельное "подразделение" (в иерархии структуры компании), можно добиться изоляции документов. Это позволит менеджерам видеть документы своего подразделения и запретит правку чужих. Но это сильно раздувает справочник структуры предприятия.
Выясним наиболее надежный способ, который требует минимального вмешательства программиста, но гарантирует результат. Использование расширения конфигурации позволяет не снимать базу с поддержки и сохранить возможность легкого обновления.
Нам необходимо решить две задачи: визуально запретить редактирование в форме и программно запретить запись объекта, если его пытаются изменить в обход формы (например, через групповую обработку).
Разберем пример кода для расширения формы документа (процедура ПриСозданииНаСервере):
&НаСервере
Процедура Расш1_ПриСозданииНаСервереПосле(Отказ, СтандартнаяОбработка)
ТекущийПользователь = Пользователи.АвторизованныйПользователь();
// Проверяем, что документ не новый и ответственный не совпадает с текущим пользователем
Если ЗначениеЗаполнено(Объект.Ссылка) И Объект.Ответственный <> ТекущийПользователь Тогда
ЭтаФорма.ТолькоПросмотр = Истина;
КонецЕсли;
КонецПроцедуры
Важно понимать, что только настройки формы ТолькоПросмотр недостаточно. Опытный пользователь может попытаться изменить статус документа или другие реквизиты через списки. Поэтому проанализируем необходимость подписки на событие ПередЗаписью в модуле объекта документа в расширении.
&НаСервере
Процедура Расш1_ПередЗаписьюПеред(Отказ, РежимЗаписи, РежимПроведения)
Если ОбменДанными.Загрузка Тогда
Возврат;
КонецЕсли;
// Если документ уже существует в базе
Если Не ЭтотОбъект.ЭтоНовый() Тогда
// Получаем старого ответственного из базы данных для сравнения
СтарыйОтветственный = ОбщегоНазначения.ЗначениеРеквизитаОбъекта(ЭтотОбъект.Ссылка, "Ответственный");
ТекущийПользователь = Пользователи.АвторизованныйПользователь();
Если СтарыйОтветственный <> ТекущийПользователь И Не ПользователиИнформационнойБазы.ТекущийПользователь().Роли.Содержит(Метаданные.Роли.ПолныеПрава) Тогда
Сообщить("У вас нет прав на редактирование чужого документа!");
Отказ = Истина;
КонецЕсли;
КонецЕсли;
КонецПроцедуры
В 1С:УТ 11 существует возможность тонкой настройки ролей. Проанализируем стандартную роль ДобавлениеИзменениеДокументовПродаж. Если мы создадим копию этой роли и в шаблоне ограничений (RLS) пропишем условие по полю Ответственный, система будет автоматически фильтровать данные.
Шаблон ограничения в схеме прав доступа может выглядеть примерно так (на уровне метаданных):
ГДЕ Ответственный = &ТекущийПользователь
Однако стоит учесть, что включение RLS в "производительном" режиме требует корректного заполнения таблиц групп доступа. Если менеджеры должны видеть чужие документы (Чтение), но не изменять их (Изменение), то в роли "Чтение" ограничений быть не должно, а в роли "Изменение" — должно стоять ограничение по ответственному.
Рассмотрев все варианты, сделаем выводы:
Помните, что поле Ответственный в 1С:УТ — это ссылка на справочник Пользователи. При настройке прав всегда проверяйте, не обладает ли пользователь ролью ПолныеПрава, так как для администраторов никакие ограничения (включая RLS и проверки в расширениях) обычно не действуют.