Рубрика Полномочия SAP HCM и безопасность SAP HCM

Полномочия при переводе сотрудника

Предлагаю поделиться опытом по вопросу полномочий при переводе сотрудника.

Мой выход. Есть один табельный номер, который был переведен между двумя БЕ/РП. Назовем условно БЕ1, БЕ2, и, соответственно, кадровик 1, кадровик 2. Есть данные по деньгам — ИТ0008, который мы хотим показывать только тому кадровику и в том объеме, на которую БЕ у него есть полномочия.

Стандартная система работает так. Кадровик 1 увидит только свою информацию. Кадровик 2 увидит свою и Кадровика 1. Все дело в одной проверке в стандартном классе проверки полномочий CL_HRPAD00AUTH_CHECK_STD->CONSIDER_SY_DATUM. Здесь в коде прописана такая логика, что полномочия предоставляются на дату СЕГОДНЯ МИНУС КОЛВО ДНЕЙ ИЗ T77S0 (AUTSW ADAYS) по дату оргприсвоения. Соответственно, первый кадровик увидит только свое, второй все.

Вопрос в этом кусочке кода:

IF READ_LEVELS CS LEVEL.
* Read access.
DESCRIBE TABLE AUTHORIZATION_PERIODS_TAB.
* The table is assumed to be normalized hence the last entry
* will have the highest ENDDA.
READ TABLE AUTHORIZATION_PERIODS_TAB INTO PERIOD INDEX SY-TFILL.
CLEAR AUTHORIZATION_PERIODS_TAB.

PERIOD-BEGDA = LOW_DATE.

* If SY_DATUM is not after the highest ENDDA + ADAYS, then grant
* authorization until HIGH_DATE.
IF SY_DATUM_MINUS_ADAYS <= PERIOD-ENDDA. PERIOD-ENDDA = HIGH_DATE. ENDIF. " SY_DATUM_MINUS_ADAYS <= PERIOD-ENDDA. APPEND PERIOD TO AUTHORIZATION_PERIODS_TAB. ELSE. " READ_LEVELS CS LEVEL. Единственный способ полностью отключить возможность просмотра конфиденциальной информации, это переопределить весь класс и исключить вызов этого метода для определения периодов доступа к данным. Вторая заметка. В ракурсе настройки инфотипов V_T582A-VALDT есть поле "Полномоч/Доступ" (VALDT), которое определяет как будет работать вышеуказанный метод. Если для инфотипа галочка снята, то система не анализирует текущую дату и предоставляет полномочия на все периоды! Если галочка стоит, то в работу включается параметр КОЛВО ДНЕЙ ИЗ T77S0 (AUTSW ADAYS) для определения, сколько дней кадровик 2 может видеть данные кадровика 1. Но это не касается самого последнего перевода.


Ограничение доступа к тарифным ставкам

Уже не первый человек спрашивает меня, как можно сделать ограничение доступа к тарифным ставкам, чтобы пользователи различных БЕ не видели ставки друг друга.

Ниже несколько вариантов реализации такого ограничения приведены ниже:

1. Скрывать полномочия на весь ИТ 1005/8. Отдельно на тарифные сетки нельзя, это объект настройки.
2. Делать свою разработку, в которой все это проверять с помощью своего объекта полномочий.
3. На самом верхнем уровне тарифной зоны вынести балансовые единицы. В инфотипах с помощью признака жестко прописывать тарифную зону, а пользователям закрыть поля от изменения.

Ваши мысли?


Вопрос-ответ 15. Полномочия

Вопрос:
Здравствуйте.
Однажды вы поднимали тему «Ограничение кол-ва профилей полномочий». Скажите, пожалуйста, вы находили какой-нибудь обход данной ситуации? Огромное количество БЕ и количество технических ролей в бизнес-ролях вызывает постоянные переполнения профилей. Сжимание ролей невозможно в связи с рисками.

Ответ:
Привет. Короткий ответ — никак. Это техническое ограничение системы, его не обойти. Была даже нота по этому поводу. На самом деле мы укрупняли роли. Я не верю, что есть в мире компания, где был бы человек, которому нужно было бы присвоить 124 профиля. Это означает, что роли неверно спроектированы. Если это самый главный по самому главному, то нужно сделать ему индивидуальную роль, где будет все внутри. Такая роль будет краснеть в GRC, но ее просто надо согласовать со службой безопасности и добавить в список исключений GRC.

Есть роли контроллеров, которые отвечают за множество БЕ. Делаем одну роль по терриориальному признаку или еще какому. И присваиваем один профиль, а не сотню по кол-ву БЕ.

Больше никак. Только реорганизацией ролей. Готов пообщаться, если убедите меня примером в обратном 🙂 Спасибо за вопрос!


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

Всем привет.

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

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

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

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

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

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

Читать далее


Инфотип 0130 Полномочия

Привет.

Для своих читателей решил протестировать механизм ограничения доступа к изменению данных прошлым периодом — инфотип 0130. Вы знаете, что обычными полномочиями мы не можем регулировать доступ во временном пространстве. Если есть доступ на изменение, то изменить можно записи в прошлом, настоящем и будущем. А если нам нужно закрыть возможность изменять данные в «закрытых» периодах? Для этого есть инфотип 0130.

Процедура проверки — подтип инфотипа 130. К процедуре присваиваются инфотипы и подтипы, который мы хотим ограничить. Например, проверка называется «Временные данные», а к ней присваиваем инфотипы 7, 2001, 2002, 2003. Таким образом работник не сможет изменять данные в этих инфотипах в прошлых периодах.

Активировать механизм нужно в транзакции OOAC ключ AUTSW APPRO.

Сама процедура проста. Для табельных номеров, которым нужно ограничить изменение в прошлом периоде(-ах) создается запись инфотипа 0130 с подтипом «Временные данные» (или другим, какой вы определите). В инфотипе указывается дата, до которой нельзя вносить изменения. Например, если это 1 мая 2014 года, то этому табельному номеру нельзя внести данные до 1 мая 2014 года по временным инфотипам.

Для создания инфотипа 0130 можно воспользоваться LSMW.

Для массового изменения даты деблокирования для ввода данных в 130 инфотипе есть программа RPTAPPU0. Она показывает баланс рабочего времени за период, и по кнопочке может установить новую дату деблокирования.

При этом для корректной работы системы нужно на уровне полномочий (объект P_ORGIN) разделить доступ к инфотипу 0130 и его подтипам. Всем, кто вводит данные, дать права на чтение. А тому, кто деблокирует (изменяет дату, до которой нельзя будут вносить изменения), дать права на изменение.