Как запретить или настроить редактирование чужих документов в 1С:Управление торговлей 11?

← На главную

При организации многопользовательской работы в «1С:Управление торговлей 11» часто возникает задача разделить зоны ответственности менеджеров. Типичное требование бизнеса — разрешить сотруднику создавать и редактировать только собственные документы, при этом полностью исключив возможность случайного или намеренного изменения документов коллег. Проанализируем, почему в современных типовых конфигурациях нет отдельного переключателя для этой задачи и какими способами можно реализовать требуемое поведение системы.

Особенности архитектуры типовых прав доступа в УТ 11

В устаревших конфигурациях (например, в «1С:Бухгалтерия предприятия 2.0») встречались упрощенные настройки прав. В современных конфигурациях на базе Библиотеки стандартных подсистем (БСП), таких как УТ 11, КА 2 и ERP, механизм ограничения доступа на уровне записей (RLS — Record Level Security) ориентирован на аналитические разрезы бизнеса. Типовыми разрезами выступают Организации, Подразделения, Склады, Партнеры и Группы партнеров.

Штатного разреза доступа по конкретному реквизиту Автор или Ответственный из коробки не предусмотрено. Это обусловлено тем, что в учетной системе документ редко принадлежит исключительно одному человеку: над заказом клиента последовательно работают менеджер по продажам, финансист, кладовщик и логист.

Вариант 1. Штатная настройка через разрез партнеров

Если бизнес-процесс компании предполагает персональное закрепление клиентов за определенными менеджерами, разберем типовой сценарий реализации ограничений без доработки конфигурации:

В разделе администрирования включаем ограничение доступа на уровне записей (RLS).
Настраиваем виды доступа по объекту Партнеры или Группы партнеров.
Распределяем клиентов по группам доступа и связываем их с группами пользователей.

В этом случае менеджер физически не сможет увидеть или отредактировать документы по тем контрагентам, к которым у него нет доступа, что решает задачу разделения данных штатными средствами.

Вариант 2. Настройка RLS на уровне прав метаданных

Рассмотрим вариант, когда необходимо применить строгое ограничение доступа на уровне ролей. Для этого в конфигураторе настраивается ограничение на право Изменение с использованием условий к таблицам документов.

Посмотрим на пример шаблона ограничения, который накладывается на документ:

ГДЕ Документ.Ответственный = &ТекущийПользователь

Однако при использовании RLS по автору или ответственному важно учитывать ряд критических нюансов:

Проблемы интерактивного создания: в момент создания нового объекта реквизит Ответственный может заполняться не мгновенно, а в процессе обработки формы. Если значение еще не совпадает с сеансом текущего пользователя, платформа выдает ошибку нарушения прав доступа.
Фоновые задания и обмены: регламентные процедуры, регламентированный учет или пакетная загрузка данных могут выполняться от имени служебных учетных записей, что приведет к сбоям при попытке модификации документов менеджеров.
Падение производительности: сложные условия RLS на операцию изменения в нагруженных регистрах и таблицах создают дополнительные блокировки на уровне СУБД.

Вариант 3. Ограничение через расширение конфигурации (рекомендуемый способ)

Наиболее надежный и гибкий подход в среде управляемых форм — программная проверка прав через расширение конфигурации без изменения типового механизма RLS. Разберем по шагам двухуровневую защиту.

Шаг 1. Блокировка формы документа на клиенте

В расширении подключаем обработчик ПриЧтенииНаСервере или ПриСозданииНаСервере формы документа. Проверяем соответствие текущего пользователя и ответственного:


&Вместо("ПриЧтенииНаСервере")
Процедура Расш_ПриЧтенииНаСервере(ТекущийОбъект)
    ПродолжитьВызов(ТекущийОбъект);
    
    // Если текущий пользователь не является ответственным, блокируем форму
    Если ЗначениеЗаполнено(Объект.Ответственный) 
        И Объект.Ответственный <> Пользователи.ТекущийПользователь() 
        И Не РольДоступна("ПолныеПрава") Тогда
        
        ЭтаФорма.ТолькоПросмотр = Истина;
    КонецЕсли;
КонецПроцедуры

Данный код переводит форму в режим «Только просмотр», скрывая командные кнопки проведения и делая поля недоступными для ввода.

Шаг 2. Контроль на сервере через подписку на событие

Для защиты от изменения документа через групповые обработки или контекстные меню списков создадим подписку на событие ПередЗаписью для группы нужных документов:


Процедура Расш_ПроверитьОтветственногоПередЗаписью(Источник, Отказ, РежимЗаписи, РежимПроведения) Экспорт
    // Новые документы пропускаем для первичного заполнения
    Если Источник.ЭтоНовый() Тогда
        Возврат;
    КонецЕсли;
    
    // Администраторов и руководство не блокируем
    Если РольДоступна("ПолныеПрава") Тогда
        Возврат;
    КонецЕсли;
    
    // Проверяем соответствие ответственного текущему пользователю
    Если ЗначениеЗаполнено(Источник.Ответственный) 
        И Источник.Ответственный <> Пользователи.ТекущийПользователь() Тогда
        
        Отказ = Истина;
        ОбщегоНазначенияКлиентСервер.СообщитьПользователю(
            "Редактирование чужих документов запрещено регламентом системы.");
    КонецЕсли;
КонецПроцедуры

Альтернативные организационные механизмы

Если нет возможности дорабатывать конфигурацию кодом, проанализируем смежные типовые инструменты:

Статусы документов: внедрение обязательных статусов (например, «К отгрузке», «Закрыт») с отбором прав на редактирование проведенных и закрытых статусов у рядовых менеджеров.
Даты запрета изменения данных: индивидуальная настройка дат запрета загрузки и редактирования прошлых периодов для групп пользователей.
Проверка документов: использование механизма подтверждения документов ответственными кураторами или аудиторами с последующей аппаратной блокировкой от изменений.