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