В крупных информационных системах, таких как «1С:Управление производственным предприятием 1.3» (УПП), справочник Контрагенты является критически важным. Бесконтрольное изменение реквизитов (наименования, ИНН, банковских счетов) пользователями может привести к ошибкам в налоговой отчетности и путанице в расчетах. В этой статье мы подробно разберем, как настроить систему так, чтобы создание новых контрагентов было доступно многим, а редактирование уже существующих — только ограниченному кругу лиц.
Самый правильный и надежный метод с точки зрения архитектуры 1С — это использование ограничения прав доступа на уровне записей (RLS). Этот механизм позволяет разграничить доступ не ко всему справочнику сразу, а к конкретным элементам внутри него. Рассмотрим, как это настроить пошагово.
Шаг 1. Включение ограничений в параметрах учета
Прежде всего, нам необходимо убедиться, что в базе включена сама возможность использования RLS. Для этого перейдем в интерфейс «Заведующий учетом», далее выберем пункт меню «Настройка параметров учета». На закладке «Ограничение доступа» должна стоять галочка «Использовать ограничения прав доступа на уровне записей». Помните, что включение этой опции может потребовать монопольного доступа к базе и существенно повлиять на производительность системы.
Шаг 2. Настройка групп доступа контрагентов
В 1С:УПП контрагентов можно объединять в специальные группы доступа. Это не папки в иерархии справочника, а отдельный реквизит ГруппаДоступаКонтрагента, который находится на закладке «Прочее» в карточке контрагента. Разберем алгоритм действий:
Проанализируем ситуацию: если мы хотим запретить редактирование всех контрагентов, по которым уже есть документы, нам придется программно менять их группу доступа, что не всегда удобно. Поэтому RLS чаще используют для территориального разделения (например, филиал А видит только своих контрагентов).
Если штатных средств RLS недостаточно или они слишком замедляют работу базы, мы можем прибегнуть к программному методу. Нам важно, чтобы проверка срабатывала именно в момент записи объекта, независимо от того, меняется он из формы или через групповую обработку. Выясним причину, по которой код в форме (сообщение 6 в теме) считается плохим тоном: его легко обойти любым внешним скриптом или стандартной обработкой «Групповая обработка справочников и документов».
Для надежной защиты добавим код в Модуль объекта справочника Контрагенты в процедуру ПередЗаписью. Проанализируем пример кода, который проверяет наличие прав и наличие документов по данному контрагенту:
Процедура ПередЗаписью(Отказ)
// Если это новый контрагент, разрешаем запись всем
Если ЭтоНовый() Тогда
Возврат;
КонецЕсли;
// Проверяем наличие специальной роли у текущего пользователя
Если Не РольДоступна("_ПравоРедактированияКонтрагентов") Тогда
// Проверяем, есть ли по данному контрагенту проведенные документы
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ ПЕРВЫЕ 1
| ДокументыПоКонтрагенту.Ссылка КАК Ссылка
|ИЗ
| КритерийОтбора.ДокументыПоКонтрагенту(&Контрагент) КАК ДокументыПоКонтрагенту";
Запрос.УстановитьПараметр("Контрагент", Ссылка);
Результат = Запрос.Выполнить();
Если Не Результат.Пустой() Тогда
Сообщить("У вас недостаточно прав для изменения контрагента, по которому уже созданы документы!", СтатусСообщения.Важное);
Отказ = Истина;
КонецЕсли;
КонецЕсли;
КонецПроцедуры
В этом примере мы используем КритерийОтбора.ДокументыПоКонтрагенту. Это самый быстрый способ узнать, задействован ли контрагент в системе. Если документы найдены, а у пользователя нет специальной роли _ПравоРедактированияКонтрагентов, система заблокирует запись.
Рассмотрим ситуацию, когда конфигурация регулярно обновляется и вносить изменения напрямую в модуль объекта справочника Контрагенты нежелательно. Чтобы не усложнять процесс обновления, используем механизм «Подписки на события».
Разберем по шагам создание подписки:
ЗапретРедактированияКонтрагентов.СправочникОбъект.Контрагенты.ПередЗаписью.Текст процедуры в общем модуле будет практически идентичен коду из предыдущего примера, за исключением того, что сам объект передается в параметре Источник:
Процедура ЗапретРедактированияКонтрагентовПередЗаписью(Источник, Отказ) Экспорт
// Исключаем проверку при обмене данными
Если Источник.ОбменДанными.Загрузка Тогда
Возврат;
КонецЕсли;
Если Источник.ЭтоНовый() Тогда
Возврат;
КонецЕсли;
Если Не РольДоступна("ПолныеПрава") И Не РольДоступна("_ПравоРедактированияКонтрагентов") Тогда
// Проверка наличия ссылок через запрос
// (аналогично коду выше, используя Источник.Ссылка)
// ...
КонецЕсли;
КонецПроцедуры
Преимущества этого метода: мы не меняем типовой код справочника. При обновлении 1С:УПП наши изменения останутся в безопасности, а логика работы сохранится.
Помимо жесткого запрета на запись, мы можем реализовать вспомогательные механизмы, которые помогут дисциплинировать пользователей и отслеживать ошибки.
1. Версионирование объектов
В 1С:УПП предусмотрена подсистема «Версионирование объектов». Посмотрим на ее возможности: если ее включить для справочника Контрагенты, система будет сохранять «снимки» объекта при каждом изменении. Мы всегда сможем увидеть, какой пользователь изменил ИНН или краткое наименование, и при необходимости откатиться к старой версии. Это часто заменяет полный запрет на редактирование, так как пользователи знают, что любое их действие протоколируется.
2. Дата запрета изменения
Хотя чаще всего «Дату запрета» используют для документов, в настройках программы можно установить запрет и на изменение справочной информации. Если контрагент был создан и использован в закрытом периоде, программа не даст его редактировать без специальных прав.
3. Ограничение через «Основного менеджера»
Проанализируем еще один типовой шаблон RLS в УПП — По основному менеджеру. Если в карточке контрагента заполнен реквизит ОсновнойМенеджер, можно настроить права так, что править карточку сможет только этот ответственный сотрудник. Для всех остальных карточка будет доступна только на чтение.
Подведем итог нашему анализу. Выбор метода зависит от ваших технических возможностей и требований бизнеса:
Важное замечание по производительности: включение RLS по контрагентам в УПП — одна из самых тяжелых операций. Поскольку контрагенты присутствуют в 90% документов, каждый запрос к базе данных будет дополняться сложными подзапросами для проверки прав. Перед внедрением RLS на «боевой» базе обязательно проведите нагрузочное тестирование на копии.