← На главную

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

Решение через ограничение доступа на уровне записей (RLS)

Для решения данной задачи не обязательно настраивать распределенную информационную базу (РИБ). В 1С предусмотрен мощный механизм ограничения доступа на уровне записей (RLS). Рассмотрим подробнее, как его правильно настроить.

Шаг 1. Включение механизма RLS

Для того чтобы ограничения через профили и группы доступа вообще заработали, необходимо включить соответствующую опцию в системе. Перейдем в раздел НСИ и администрирование — Настройки пользователей и прав. Здесь нам нужно установить глобальный флажок Ограничивать доступ на уровне записей. Без этой настройки любые правила, прописанные вами в группах доступа, будут просто игнорироваться программой.

Шаг 2. Настройка профиля групп доступа

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

1. Откроем карточку нужного профиля групп доступа.
2. Перейдем на вкладку Ограничения доступа.
3. В списке видов доступа найдем строку Склады.
4. Установим значение: Все запрещены, исключения назначаются в группах доступа.

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

Шаг 3. Настройка группы доступа

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

1. В карточке группы доступа перейдем на вкладку Ограничения доступа.
2. Для вида доступа Склады установим правило: Все запрещены, кроме 1 значения.
3. В табличной части ниже выберем конкретный склад, к которому должен быть открыт доступ у участников данной группы.

Подводные камни и конфликты ролей

При настройке прав проанализируем важный нюанс архитектуры 1С: права работают по принципу сложения. Если у пользователя назначено несколько ролей (или он состоит в нескольких группах доступа), и хотя бы одна из них разрешает чтение данных без ограничений, доступ будет открыт ко всем складам.

Например, если пользователю дополнительно назначена типовая расширенная роль (бухгалтер, финансист, контролер), которая имеет полное право на чтение регистров накопления, таких как ТоварыНаСкладах или СвободныеОстатки, ограничение по складу не сработает. Чтобы обойти эту проблему, нам придется создавать собственные (урезанные) профили доступа, исключая из них типовые роли с избыточными правами на чтение.

Проблемы при использовании строгого RLS

Несмотря на эффективность механизма ограничения на уровне записей, выясним возможные побочные эффекты его применения:

1. Снижение производительности: Механизм RLS неявно добавляет условия фильтрации в каждый запрос к базе данных. В базах с большим документооборотом это может привести к заметному замедлению работы при открытии списков номенклатуры, форм подбора и при формировании отчетов.
2. Проблемы со связанными документами: Если сотрудники работают с документами товародвижения между разными складами (например, «Перемещение товаров»), отсутствие прав на склад-отправитель или склад-получатель приведет к тому, что в документе вместо названия чужого склада отобразится <Объект не найден>. Проведение таких документов также может вызывать ошибку нарушения прав доступа.

Альтернативные варианты решения (без тяжелого RLS)

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

1. Решение через расширение конфигурации
Вместо включения ограничений на уровне базы данных мы можем использовать расширения. В расширении программно добавляется жесткий отбор по доступным складам при открытии формы подбора товаров, списков документов и при формировании складских отчетов. Этот подход не нагружает систему сложными SQL-запросами на уровне платформы и позволяет избежать конфликтов прав при проведении документов перемещения.

2. Пользовательские варианты отчетов
Если наша основная цель состоит лишь в том, чтобы пользователи не видели чужие остатки при формировании отчетов, а строгая секретность на уровне базы данных не требуется, настроим персональные варианты отчетов. Мы можем взять стандартный отчет «Ведомость по товарам на складах», установить в нем отбор по нужному складу и заблокировать этот отбор от изменений пользователем. Сохранив такой вариант отчета для конкретного сотрудника, мы решим базовую задачу. Однако стоит помнить, что технически грамотный пользователь всё равно сможет посмотреть общие остатки, например, через «Универсальный отчет», если у него есть к нему доступ.