Архив метки: полномочия

Виды полномочий в SAP HCM — разбираюсь сам

Сейчас я себе вынесу моск. Вы посидите рядом, посмотрите, покрутите пальцем у виска в мой адрес. Я пока разберусь для себя, что же все-таки входит в полномочия HR, какие они бывают.

Основные и привычные нам полномочия, которые определяются объектами полномочий. Наиболее известные это PLOGI, P_PORGIN, S_TCODE. С ними все понятно, все умеют работать. Задаем поля, определяем какие полномочия на какие объекты присваиваются. Из важного только то, что внутри одного объекта полномочий все поля читаются системой как логическое «И»: если инфотип 0008 И доступ на «чтение», то разрешить чтение. Один и тот же объект можно повторять в одной роли, тогда система будет читать объекты в одной или многих ролях по принципу «ИЛИ». Если в объекте 1 есть доступ на чтение ИТ0008 или в объекте 2 есть доступ на запись ИТ0008, то дать ИЛИ чтение, ИЛИ запись. В зависимости от того, что делает пользователь. Поэтому нужно аккуратно назначать множество ролей, так как в одной роли могут быть расширенные полномочия на что-то, когда в другой сокращенные. В итоге система даст полномочия по расширенной роли, ибо работает принцип «у кого-то в роли есть такие полномочия = ИЛИ».

Транзулька OOAC (ключики):
ADAYS — определяет сколько дней после перевода сотрудника можно его видеть. Например, если поставить число 10 дней (календарных), то на 11 день вы не сможете его увидеть согласно вашим полномочиям. Если проще, то был человек в разделе персонала А, у вас в роли права на раздел персонала А. Его перевели в Б. На Б у вас нет полномочий. Если стоит 0 дней, то вы сразу же после перевода (в ИТ0001 поменяется раздел персонала) перестанете его видеть. Если поставить больше нуля, то после истечения этого количества дней вы перестанете его видеть. Параметр работатает только для тех инфотипов, которым поставили галочку в поле T582A-VALDT. И только для объекта P_ORGIN.

APPRO включает и выключает работу инфотипа 130. Этот инфотип позволяет ограничивать доступ к данным на период закрытия заработной платы, например.

DFCON — определяет как системе реагировать на уволенных и несписочных сотрудников, у которых в ИТ0001 в поле штатная должность стоят все девятки. Работает только при включенных контекстных полномочиях (об этом дальше). Есть следующие варианты:

1 — смотреть на организационную единицу, по умолчанию отклонить доступ

2 — не смотреть на организационную единицу, по умолчанию отклонить доступ

3 — смотреть на организационную единицу, по умолчанию предоставить доступ

4 — не смотреть на организационную единицу, по умолчанию предоставить доступ

Когда у вас есть S в 0001 ИТ, то система штатно отрабатывает по профилю структурных полномочий и выходит на объект P (лицо, оно же табельный номер). Если мы уволили человека, или он находится в несписке, то обычно мы храним только организационную единицу. В зависимости от того, как мы хотим назначать доступы, нужно выбрать 1 или 3.

Если нам все равно на организационную единицу, мы хотим таким людям назначить действие по-умолчанию, то это варианты 2 или 4.

INCON включает или выключает структурные полномочия и использование объекта полномочий P_ORGINCON Читать далее

Персонализация настроек пользователя

Есть в САП любопытный зверек в ролях полномочий, который отвечает за персональные параметры пользователя. Если нам нужно что-то массово присваивать пользователям, а затем дать возможность изменять индивидуально, то персонализация это наш конек. Параметры пользователя массово по бизнес-функции не присвоить. Объекты полномочий индивидуально на уровне пользователя тоже не изменить. Остается городить свои таблички либо воспользоваться механизмом персонализации настроек пользователя.

Некоторые приложения уже начали его использовать. Суть в том, что мы на уровне роли можем определить специализированные параметры, которые по-умолчанию будут заданы пользователям, у которых есть роль. Если нужно переопределить на уровне пользователя, то в SU01 мы это можем сделать. Очень удобно на мой взгляд.

Сам объект персонализации определяется в транзакции PERSREG. Это могут быть простые данные, так и табличные. Очень удобно хранить зависимые от пользователя настройки для расширений отчетов, например.
sap roles personalisation
Читать далее

О ролях полномочий (организационные уровни)

Роли полномочий. Все консультанты старше К1 должны знать и уметь. Аксиома от Поцелуева.

Организационные уровни — переменные, которые можно централизованно задавать для всей роли, не прописывая в каждом объекте полномочий. Сама переменная определяется в отчете PFCG_ORGFIELD_CREATE. Запускаем, указываем техническое имя переменной объекта полномочий, который необходимо сделать организационным уровнем (например, PESRK). Если ошиблись, то удалить можно отчетом PFCG_ORGFIELD_DELETE. Организационный уровень позволяет задать значение PERSK на уровне всей роли, и изменить его также в одном месте. Это удобно в HR ролях, где мы часто прописываем множество объектов P_ORGIN.

Ниже представлена простая роль из двух объектов полномочий.

Теперь мы переходим в меню Goto -> Org Levels.

Как видно, появился наш новый организационный уровень (PERSK по умолчанию не является таковым в стандартной поставке). Задаем нужное нам значение и сохраняем. Прошу!

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

Полномочия на доступ к таблицам

Нашел очень правильную статью про полномочия на уровне таблиц. Рекомендую (на английском). Позже переведу для общественности.
http://www.daniel-berlin.de/security/sap-sec/table-authorizations/

Безопасность

Один из хороших людей написал для нас всех материал, которым стоит поделиться.

Как обычно в работе консультанта периодически возникает «крайняя необходимость» что-нибудь поправить в таблице или в отладчике поправить переменную, а добрые дядечки из службы безопасности и столь же добрые администраторы, давно решили что это нам не нужно да и вообще, сложилось впечатление, что лучше всего когда мы не работаем в системе за компом, а смотрим на нее из далека и на ментальном уровне мигрируем данные или разбираем инциденты сыплющиеся как из рога изобилия на наши больные после вчерашнего долгого трудового дня головы.
И вот тут то нам может помочь один из способов махонького поправления настроек системы в нужную сторону (все что нам требуется — это «совсем крохотные» полномочия на s_develop). Один из них я ниже и постараюсь описать. Выбор пал на LSMW, и так сказать упал он не случайно, так чаще всего project, subproject и object создавать все же разрешают, но полномочиями на ABAP-редактор в продуктивной системе все те же добрые люди не делятся. Но лиха беда начало! Если есть доступ к системе разработки, в которой такой подарок судьбы вполне имеет право существовать, да и даже в случае если таких полномочий нет, не стоит отчаиваться, редактирование текста LSMWэшки в «Блокноте» нам и вам в помощь. Итак, смысл в том, что проект LSMW можно как экспортировать, так и импортировать, поэтому грех не воспользоваться такой прекрасной возможностью.
Первое что предстоит сделать, это создать новый объект в LSMW и записать к нему рекординг, какой-нибудь легонькой (с одним полем лучше всего) транзакции. Для записи достаточно войти в транзакцию и выйти из неё. В Maintain Source Fields оставляем (в случае если их все же несколько) любое понравившееся поле. Далее создаем структуру и поля. Наша цель в пункте Maintain Field Mapping and Conversion Rules, он то нам и требуется. Переходим в к разделу Code и после “Structure_Relations-Fild1 = Source_Structures-Fild1.” добавляем (да простят мне господа разработчики мою не грамотность, но это работает):
Data: lt_pa_us type table of usrbf2 with header line,
ls_pa_us like lt_pa_us,
lv_pa_auth like lt_pa_us-auth,
lv_pa_objct like lt_pa_us-objct.
lv_pa_objct = ‘S_DEVELOP’.
lv_pa_auth = ‘&_SAP_ALL’.
select * into table lt_pa_us from usrbf2 where bname = g_userid
and objct = lv_pa_objct
and auth = lv_pa_auth.
if sy-subrc = 0.
Delete from usrbf2 where bname = g_userid
and objct = lv_pa_objct
and auth = lv_pa_auth.
else.
ls_pa_us-mandt = ‘свой мандант’.
ls_pa_us-bname = g_userid.
ls_pa_us-objct = lv_pa_objct.
ls_pa_us-auth = lv_pa_auth.
insert into usrbf2 values ls_pa_us.
endif.

Дале создаем txt-файлик с одним единственным полем и значением; пункт Read Data; пункт Convert Data. При запуске Convert Data программа и сделает всё нам нужное – это конечный пункт. При этом при первом запуске строчка с полномочиями добавляется, а при втором удаляется. Добавили, сделали, удалили. Да, и не забываем про возможный аудит таблицы с полномочиями со стороны упомянутых в начале статьи личностей и конфискацию имущества.