Как в 1С настроить ограничение доступа по складам «чтение всех, запись только своего» без потери производительности?

Программист 1С v8.3 (Управляемые формы) 1С:ERP Управление предприятием Управленческий учет IT и автоматизация бизнеса

В крупных торговых и производственных компаниях часто возникает задача разграничения прав доступа сотрудников к складским данным. Классический сценарий, который в профессиональной среде называют системой «свой – чужой», формулируется следующим образом: пользователь должен беспрепятственно видеть остатки и документы по всем складам компании (для оперативной консультации клиентов или планирования логистики), но создавать, изменять и проводить документы может только по своему конкретному складу.

Решить эту задачу стандартными средствами платформы 1С не всегда просто, так как типовой механизм ограничения доступа на уровне записей (RLS — Record Level Security) по умолчанию скрывает объекты целиком. Если у пользователя нет прав на склад, он не увидит ни сам склад, ни документы по нему. В этой статье мы подробно разберем, как обойти это ограничение, настроить систему «чтение всех, запись своего», решить неизбежно возникающую проблему с перемещениями товаров и не допустить падения производительности информационной базы.

Рассмотрим по шагам все этапы реализации этой задачи в современных типовых конфигурациях 1С (ERP, Комплексная автоматизация, Управление торговлей) на базе платформы 1С:Предприятие 8.3.

Шаг 1. Настройка схемы «Чтение всех, запись своего» через типовые профили

Поскольку стандартное включение RLS для склада скрывает его из всех отчетов и списков, нам потребуется скомбинировать права доступа. Платформа 1С объединяет права пользователя из разных групп доступа по принципу логического ИЛИ. Это означает, что если одна роль разрешает чтение объекта, а вторая роль его запрещает — объект все равно будет доступен для чтения.

Для реализации схемы без изменения конфигурации выполним следующие действия:

Создадим профиль для сквозного чтения:
- Перейдем в раздел НСИ и администрирование — Настройки пользователей и прав — Профили групп доступа.
- Создадим новый профиль с именем «Чтение всех складов и документов».
- В списке разрешенных ролей отметим только те роли, которые дают право на чтение (без изменения) справочника Склады и всех необходимых документов (например, Чтение документов продаж, Чтение запасов и закупок).
- В данном профиле настройки RLS (ограничения доступа) оставляем полностью отключенными. Это обеспечит пользователю видимость всех данных в отчетах.
Создадим профиль для редактирования «своего» склада:
- Создадим второй профиль с именем «Редактирование документов по своему складу».
- Включим в него роли, дающие право на добавление и изменение документов (например, Добавление изменение документов продаж).
- На вкладке Ограничения доступа для вида доступа Склады укажем значение «Ограничивать».
Назначим права пользователю:
- Создадим две группы доступа на основании созданных профилей.
- В первой группе (для чтения) просто укажем нашего пользователя.
- Во второй группе (для изменения) укажем этого же пользователя, а в таблице разрешенных значений выберем конкретный склад (например, «Склад А»), по которому ему разрешено работать.

В результате такого объединения система позволит пользователю открывать отчеты по любым складам и видеть чужие документы, но при попытке записать или провести документ по любому складу, отличному от «Склада А», платформа выдаст ошибку нарушения прав доступа.

Шаг 2. Разрешение конфликта с документом «Перемещение товаров»

При внедрении схемы «свой – чужой» администраторы сразу же сталкиваются с технической проблемой проведения документов межскладского перемещения. Проанализируем причину ее возникновения.

Документ ПеремещениеТоваров содержит два ключевых реквизита: СкладОтправитель и СкладПолучатель. При проведении этот документ делает движения (записи) в регистры накопления (например, Товары на складах, Выручка и себестоимость продаж) одновременно по двум складам: списывает остатки с одного и приходует на другой.

Если у кладовщика «Склада А» есть права на запись только по своему складу, система заблокирует проведение перемещения на «Склад Б», так как у пользователя нет прав на запись движений по складу-получателю. Документ просто откажется проводиться.

Выделим три практических способа решения этой проблемы:

Переход на ордерную схему документооборота:
Это наиболее правильный методологический подход, не требующий программирования. Процесс перемещения разделяется на шаги:
- Менеджер офиса (у которого есть доступ ко всем складам) создает документ-распоряжение Заказ на перемещение или само Перемещение товаров в статусе «К отгрузке».
- Кладовщик «Склада А» на основании этого распоряжения создает и проводит документ Расходный ордер на товары. Для этого ему нужны права только на свой склад.
- Кладовщик «Склада Б» у себя на месте создает и проводит Приходный ордер на товары. Для этого ему также требуются права только на свой склад-получатель.
Использование виртуального транзитного склада:
Перемещение оформляется не напрямую, а через промежуточный виртуальный склад (например, «Товары в пути»). Доступ на запись к этому виртуальному складу открывается для всех участников процесса. Кладовщик «Склада А» делает перемещение на транзитный склад, а получатель со «Склада Б» забирает товары с транзитного склада на свой.
Доработка шаблона RLS в расширении конфигурации:
Если бизнес-процесс требует проведения документов перемещения напрямую одним пользователем, программисту придется доработать шаблон ограничения доступа. В стандартном RLS условие проверяет доступность обоих складов (используется логическое И). С помощью расширения конфигурации шаблон переписывается так, чтобы запись разрешалась, если пользователю доступен хотя бы один из складов (ИЛИ отправитель, ИЛИ получатель):
```
// Пример логики изменения шаблона RLS для Перемещения товаров
ГДЕ ДоступенСклад(СкладОтправитель) ИЛИ ДоступенСклад(СкладПолучатель)
```

Шаг 3. Производительность RLS: мифы и реальность

Многие специалисты отказываются от RLS, мотивируя это тем, что «РЛС замедляет абсолютно всё». Действительно, в старых версиях платформ (до 8.3) и конфигурациях на обычных формах (например, Управление производственным предприятием 1.3) RLS существенно замедлял работу СУБД. При каждом запросе платформа динамически дописывала к SQL-запросам сложные подзапросы с соединениями таблиц прав, что приводило к неоптимальным планам выполнения на сервере базы данных.

В современных конфигурациях на базе БСП (Библиотеки стандартных подсистем) разработан и успешно применяется Производительный режим RLS (RLS 2.0). Выясним, как он устроен:

Платформа больше не вычисляет права «на лету» при каждом обращении к СУБД.
Вместо этого в системе создаются специальные служебные регистры сведений, содержащие уже готовую, предварительно рассчитанную матрицу прав для каждой группы доступа и каждого пользователя (например, регистры КлючиДоступаКОбъектам, ТаблицыГруппДоступа).
При выполнении запроса к документам или справочникам платформа выполняет простейшее и быстрое соединение выборки с этой готовой таблицей ключей доступа по индексированным полям. Скорость чтения данных при этом практически не снижается.

Важная особенность: производительный режим смещает нагрузку с чтения на запись. Сами отчеты и списки открываются мгновенно, но при записи новых документов или изменении структуры групп доступа система запускает фоновые задания для пересчета этих служебных регистров. Чтобы избежать зависания базы, необходимо регулярно следить за актуальностью индексов СУБД и регламентными заданиями очистки устаревших ключей доступа.

Включить данный режим можно в меню: НСИ и администрирование — Настройка пользователей и прав — установить флаг Ограничивать доступ на уровне записей и выбрать производительный режим работы.

Шаг 4. Альтернативный вариант: «Мягкое» ограничение прав через расширение

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

Этот способ называют «мягким», так как он не скрывает данные из видимости пользователей на уровне СУБД, а лишь блокирует попытку физического изменения информации. Реализуется это с помощью небольшого расширения конфигурации.

Разберем по шагам алгоритм создания такой защиты:

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

Проанализируем пример программной реализации этого механизма:


&НаСервереБезКонтекста
Функция ДоступРазрешен(ТекущийПользователь, ТекущийСклад)
    
    // Если склад не указан в документе, пропускаем проверку (или обрабатываем отдельно)
    Если Не ЗначениеЗаполнено(ТекущийСклад) Тогда
        Возврат Истина;
    КонецЕсли;
    
    // Запрос к нашему регистру сведений разрешенных складов
    Запрос = Новый Запрос;
    Запрос.Текст = 
        "ВЫБРАТЬ
        |   ДоступныеСклады.Склад КАК Склад
        |ИЗ
        |   РегистрСведений.ДоступныеСкладыПользователей КАК ДоступныеСклады
        |ГДЕ
        |   ДоступныеСклады.Пользователь = &Пользователь
        |   И ДоступныеСклады.Склад = &Склад";
        
    Запрос.УстановитьПараметр("Пользователь", ТекущийПользователь);
    Запрос.УстановитьПараметр("Склад", ТекущийСклад);
    
    Выборка = Запрос.Выполнить().Выбрать();
    Возврат Выборка.Следующий(); // Если запись найдена, значит доступ разрешен
    
КонецФункции

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

Преимущества программного подхода:

Максимальное быстродействие: База данных работает на полной скорости, отсутствуют тяжелые SQL-запросы фильтрации таблиц, нет блокировок при параллельной работе пользователей.
Простота настройки: Администратору не нужно разбираться в сложных настройках RLS БСП, достаточно заполнить простой регистр сведений.
Информативные сообщения: Вместо стандартной системной ошибки «Нарушение прав доступа» пользователь получает понятное и вежливое предупреждение с указанием конкретной причины отказа.

Резюме

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

Если же главной задачей является защита от случайных или намеренных изменений чужих документов, а видимость остатков должна оставаться сквозной — смело внедряйте «мягкое» программное ограничение в расширении. Это сохранит высокую скорость работы вашей базы данных и сбережет нервы пользователям.

← На главную