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