Подниму тему о том, что уже мало где используется или это ошибочное представление
И так, есть обычный куб (ZCUBE) с обычным полем(ZRKC, длина ключа 2 символа), требующим авторизации по нему.
Что было сделано мной и где ошибка:
1. Создан объект полномочий в rssm c привязкой только к этому полю ZRKC.
2. Создана роль, присвоена пользователю и в профиле заполнено значение для этого поля.
3. В Bex Query в фильтре создано две переменные:
3.1 Обычная переменная для ввода пользователем
3.2 Customer-exit, Input ready "снята" - которая обрабатывает полномочия, выводит в фильтр только допустимые значения

Но мне не нравится как это выглядит в бексе, так как на один признак создано 2 переменных. В поисках правды наткнулся на пост: viewtopic.php?f=12&t=35067
1. Создаете переменную в объекте авторизации ($ИМЯ) - Это где там создавать переменную?
2. Создаете в BEx User Exit переменную с таким же именем без $ (ИМЯ) - Это понятно
3. Создаете обычную переменную BEx основанную на полномочиях и ограничиваете ей признак. - Это понятно
..
4. В PFCG в выбранной роли добавить профиль этот объект и ограничить не фиксированным значением, а значением "$ИМЯ" (потом надо с таким же именем создать переменную в BEx) - Вот это не получается, так как в значения для объекта полномочий в роли можно ввести только 2 символа (так как ключ признака 2 символа). Это ограничение как-нибудь можно победить ?

Dynamic Authorization Concept and Role Assignment in BI.

Ооо здорво, я сейчас походим занимаюсь. Нужно разграничить полномочия по филиалам по пользователей. Почитал мануал, но что-то никак не могу понять зачем в RSSM создавать authorization object?

В Rssm создаешь объект полномочий, заполняешь его значением в профиле пользователя.
Ну и создаешь auth переменную в бексе и т.д.