Что это такое?

Можно сказать, что структурные полномочия основаны на организационной, а не административной структуре предприятия. Или же это дополнительное измерение системы полномочий в HR, когда мы можем определить параметры доступа к данным на основании принадлежности пользователя к тому или иному объекту организационной структуры. Например, специалист по табельному учету может видеть всех сотрудников по всей организационной структуре (вводить данные по учету рабочего времени), но вводить доплаты может только по своему участку. Либо нам нужно ограничить доступ к сотрудникам только своего подразделения или нижестоящих в тех случаях, когда административная структура (разделы, подразделы персонала) заданы достаточно широко и не позволяют решить эту задачу с их помощью.

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

Настройка структурных полномочий

Настройка структурных полномочий осуществляется в несколько этапов. Сначала мы устанавливаем управляющие ключи в системе. Затем создаем пути анализа, по которым система будет проверять объекты на наличие доступа. Далее определяем профили структурных полномочий. И финальным аккордом необходимо определить привычные нам “PFCG роли” с указанием созданных профилей структурных полномочий.

Логика работы структурных полномочий достаточно простая. В «PFCG роли» доступ к данным определяется не объектом P_ORGIN, как мы привыкли в HR, а объектом P_ORGINCON (описание можно посмотреть в транзакции SU21). Разница лишь в том, что в последнем есть дополнительное поле PROFL, где указывается профиль структурных полномочий. В свою очередь профиль структурных полномочий определяет к каким объектам организационного менеджмента  предоставить доступ. Таким образом, если в профиле указаны все объекты типа P (Лицо), то система предоставит доступ ко всем табельным номерам. Если указать, например, путь анализа C-P, то доступ будет предоставлен только к определенным табельным номерам, которые присвоены к указанной должности (наш пример с секретарями и старшим).

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

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

Итак, активируем механизм структурных полномочий. В таблице T77S0 нужно активировать ключ AUTSW          INCON                1. Это позволит нам использовать объект P_ORGINCON вместо P_ORGIN.

Параметр AUTSW ADAYS в той же таблице отвечает за количество дней, в течение которых пользователь будет иметь доступ к «устаревшему» объекту. Например, если у пользователя есть полномочия на «Отдел 1», а сотрудника перевели 10 марта в «Отдел 2», то у пользователя будет доступ к этому сотруднику то количество календарных дней, которое указано в параметре ADAYS. Например, если там стоит 10, то 21 марта доступ к переведенному сотруднику пропадет.  Следует отметить, что параметр применим и к обычной проверке доступа через объект P_ORGIN. Если установить значение параметра в 0, то ограничения снимаются.

В рамках этой статьи я постараюсь использовать стандартные решения, поэтому путь анализа изобретать не буду, а возьму стандартный O_S_P. Теперь нужно создать профиль структурных полномочий таким образом, чтобы система понимала, какую организационную единицу нужно предоставить пользователю со всеми подчиненными объектами. Стандартное решение SAP работает следующим образом: в инфотипе 0105 «Коммуникации» в подтипе 0001 указывается имя пользователя (логин). С помощью стандартного функционального модуля RH_GET_ORG_ASSIGNMENT система ищет организационную единицу, к которой присвоена штатная должность указанного нами табельного номера. Иными словами, если я работаю в «Отдел 1» и моему табельному номеру присвоили мой логин в инфотипе 0105, то система вернет ссылку на «Отдел 1». Таким способом мы получаем корневую организационную единицу, к которой применяется путь анализа и в результате на выходе система выдает список объектов O, S, P к которым мы имеем доступ.

«Живьем» это выглядит так. В транзакции OOSP создаем профиль структурных полномочий ZSTRUCT_1:

Рис. 1. Заголовок профиля полномочий

Рис. 2. Определение профиля структурных полномочий

Рис. 3. Определение профиля структурных полномочий (продолжение)

Что мы сделали? Мы создали профиль структурных полномочий, который пока «сам по себе и никакой власти не имеет». В профиле мы обозначили тип объекта - O “Организационная единица”. Можно указать идентификатор напрямую в поле “ИдОбъекта”, а можно указать функциональный модуль, который должен вернуть перечень объектов, к которым разрешен доступ. В нашем случае модуль возвращает только один объект – вышестоящую организационную единицу. Чтобы получить подчиненную структуру со всеми штатными должностями и табельными номерами (лицами), мы указываем путь анализа, который и предоставляет нужную информацию.

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

Рис. 4. Пример настройки роли ZSTRUCT_1

И финальный аккорд - присвоение роли. Создаем двух пользователей USER1 и USER2, который будут иметь доступ к своим отделам. Присваиваем им роли ZSTRUCT_1 и ZSTRUCT_2 соответственно. Для эксперимента считаем, что пользователь USER1 имеет полный доступ ко всем данным подразделения  «Отдел 1», а USER2 только к временным данным подразделения «Отдел 2». Ниже представлена организационная структура (Рис. 5).

Рис. 5. Образец организационной структуры для тестирования

И еще один нюанс со структурными полномочиями. Мы можем напрямую сказать, какой профиль структурных полномочий к какому пользователю применять. Система сама по себе не понимает какой профиль считывать для предоставления полномочий, несмотря на то что мы указали профиль в роли. Для этого существует отдельная таблица/ракурс OOSB. В ней мы можем указать пользователей поименно с нужными профилями. А можем указать системную запись «SAP*», которая будет по умолчанию применяться ко всем пользователям, которых мы не указали. Я бы рекомендовал сделать один профиль структурных полномочий, если это возможно, присвоить его системному пользователю «SAP*», чтобы этот профиль работал для всех пользователей. А системным пользователям для фоновых заданий и расчетчикам, которые запускают заработную плату по всей организационной структуре, присвоил бы профиль «ALL» - вся структура.

Итак, проверяем. Заходим под пользователем USER1 и проверяем наличие доступа только к подразделению «Отдел 1» и на все инфотипы. Заходим в транзакцию PA30 и запускаем средство поиска по табельным номерам.

Рис. 6. Проверка работы системы полномочий для пользователя USER1

Система честно предупредила, что «есть еще, но не дам» (Рис. 6). Если вернуться к организационной структуре выше, то вы увидите, что обе девушки работают в «Отдел 1». Заходим в инфотип 0008 «Основные выплаты» в режиме изменения (Рис. 7).

Рис. 7. Изменение инфотипа «Основные выплаты»

Доступ