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

Всем привет.

Оригинал статьи можно увидеть  на сайте Издательства SAPLAND.

Что такое структурные полномочия в модуле SAP HCM?

Можно сказать, что структурные полномочия основаны на организационной, а не административной структуре предприятия. Или же это дополнительное измерение системы полномочий в 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:

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

Создание роли полномочий для использования структурных полномочий

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

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

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

Проверка работы структурных полномочий

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

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

Доступ есть. Проверяем тоже самое с пользователем USER2. У него должны быть полномочия только на «Отдел 2» и временные данные.

Нет доступа к инфотипу 0008, но есть возможность создавать отсутствия в инфотипе 2001 «Отсутствия».

Таким образом проверка ролей пройдена.

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

Расширяем задачу. Теперь нам нужно нашему пользователю USER2 предоставить дополнительные полномочия на изменение основных выплат в подразделении «Отдел 1». Сейчас, как вы помните, у него нет таких прав. Для этого создаем отдельный профиль структурных полномочий, чтобы нам как-то сказать, что этому пользователю еще можно «туда ходить».

Профиль сделаем простым с прямым указанием кода объекта организационной структуры.

В OOSB присвоим этот профиль пользователю USER2. И создадим роль в PFCG.

Проверяем. Должно быть:

1. «Отдел 1». Доступ на изменение инфотипа 0008. Нет доступа на 2001.
2. «Отдел 2». Доступ на 2001. Нет доступа на 0008.

Для начала мы стали видеть все табельный номера.

Есть доступ на инфотип 0008 девушки из первого отдела.

Но нет полномочий на ведение отсутствий у нее же.

Задача номер один выполнена.

Есть доступ на создание отсутствия у девушки из второго отдела.

Но нет доступа к ее заработной плате.

Задача номер два выполнена.

Это решение, когда мы использовали два профиля, я считаю несколько неэффективным для реальной работы. Я бы предложил вам домашнее задание. Сделать функциональный модуль, который по наличию связи пользователя с организационной единицей (US – O) определяет эту организационную единицу. А в профиле структурных полномочий уже с помощью пути анализа формируется список объектов. Плюс в том, что вы можете предоставлять полномочий на организационные единицы простым созданием соединения US-O. Для удобства делается новый ракурс в транзакции PPOME, где будут отражаться пользователи и структура, к которой они имеют доступ. Этот ракурс оформляется отдельной транзакцией и предоставляется администраторам системы. Теперь они могут самостоятельно по заявке управлять доступами: присвоить PFCG роль, присвоить организационную единицу.

Рекомендации по тестированию структурных полномочий

При тестировании механизма нужно проверять ряд ситуаций, таких как:

1. Разделение полномочий. Сотрудник с полномочиями на «Отдел 1» не имеет доступ к «Отдел 2».
2. Пересечение полномочий. У сотрудника есть доступ к табельному учету подразделений «Отдел 1» и «Отдел 2», доступ к заработной плате подразделения »Отдел 1». При этом не должно быть доступа к заработной плате подразделения «Отдел 2».
3. Доступ при ограничении структур организационного менеджмента. У сотрудника есть доступ к подразделению«Отдел 1». Но отдел упразднили (ограничили). Остались ли полномочия у сотрудника на этот отдел за прошлые периоды?
4. Доступ при перемещении персонала между подразделениями. У сотрудника есть полномочия на персонал из подразделения «Отдел 1». Часть персонала перевели в другой отдел. Создалось 2 записи в ИТ0001 «Организационное присвоение». Остались ли полномочия у сотрудника на прошлые периоды?

Побочные эффекты при внедрении структурных полномочий

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

Возможно отказаться от использования индексов, что в небольшой компании никак не скажется на производительности. Но, если у вас есть планы использовать систему аналитичеcкой отчетности SAP BW и использовать структурные полномочия из системы HR, то индексы необходимы. Стандартное решение SAP предполагает загрузку этих индексов в BW для целей управления полномочиями.

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

Некоторые рекомедации при использовании структурных полномочий

Начну с вопроса: стоит ли сегодня делать «все то, что может понадобиться в следующие пятнадцать лет»? Во-первых, не стройте сложных систем полномочий, так как их сложно отлаживать и сопровождать. В частности, когда вы создаете пути анализа для профилей структурных полномочий, то помните, что в системе уже есть большое количество стандартных путей анализа и имеет смысл сначала изучить их. Во-вторых, старайтесь указывать путь анализа с конкретными связями и объектами. Иными словами избегайте «звездочек», так как это усложняет понимание, что именно вы хотили включить в разрешенные объекты (например, соединение S -> * может выдать табельные номера, а также особые условия труда, рабочие места, пользователей и так далее в зависимости от настроек системы. А нужно было всего лишь получить табельные номера). В противном случае система выдаст большое количество объектов, что существенно замедлит скорость системы.

Также старайтесь избегать двух и более путей анализа в профиле. Представьте, что один путь анализа выдает информацию о табельных номерах, а второй — о должностях в выбранной организационной единице. Обоим путям анализа нужно «пройти» путь сверху вниз по одним и тем же объектам O, S для того, чтобы выдать конечный перечень объектов для предоставления доступа. Таким образом, система проделает одну и ту же работу два раза, что опять же скажется на производительности.

Обе рекомендации приведены на сайте компании SAP.