Автоматическое назначение полномочий

Всем привет.

Есть в системе такая волшебная штука, как назначение ролей полномочий на основании организационной структуры или автоматическое назначение полномочий. Это означает, что на оргструктуре мы можем сказать, какие роли и профиля структурных полномочий нужно назначить пользователям, которые в ней находятся. Например, если на отдел «Кадры» назначить роль «Кадровик» и профиль структурных полномочий «Вся структура», то при приеме или переводе на штатную должность нового человека и запуска спец программки система автоматически назначит ему эту роль и профиль. Получается, что не нужно делать заявки на пользователей и все такое. Это достаточно старый механизм, в нем мало гибкости, но может быть кому-то он пригодится. Новое и правильное решение по управлению ролями полномочий от САП, это SAP GRC.

Читать далее


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

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

Мой выход. Есть один табельный номер, который был переведен между двумя БЕ/РП. Назовем условно БЕ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.

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

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


Выключение менеджера объектов

Знакомый столкнулся с ситуацией, когда структурные полномочия были настроены так, что система перебирала табельники по всей компании. Доходчивый пользователь включил поиск всех табельных номеров в менеджере объектов в PA30, что привело к зависанию транзакции при запуске. То есть транзакции не хватало памяти обойти все табельники и выдать на экране. Что делать?

Отключить менеджер объектов. Но это можно сделать только в самой транзакции PA20/30, в которую мы не можем зайти. Выход есть. В параметрах пользователя (транзакции SU01/SU3) нужно прописать два параметра:
OM_OBJM_NO_DISPLAY X
OM_OBJM_NO_LAST_SEAR X

Это сбросит настройки последнего поиска для текущего пользователя и скроет менеджер объектов.