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

Роли полномочий. Все консультанты старше К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/


Безопасность продуктива и LSMW

Один из хороших людей написал для нас всех материал, которым стоит поделиться. Речь про дырки в системах, про безопасность продуктива и как ее обойти с помощью LSMW – инструмента миграции данных, стандартного для проектов SAP.

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

И вот тут то нам может помочь один из способов махонького поправления настроек системы в нужную сторону (все что нам требуется – это «совсем крохотные» полномочия на s_develop). Один из них я ниже и постараюсь описать. Выбор пал на LSMW, и так сказать упал он не случайно, так чаще всего project, subproject и object создавать все же разрешают, но полномочиями на ABAP-редактор в продуктивной системе все те же добрые люди не делятся. Но лиха беда начало! Если есть доступ к системе разработки, в которой такой подарок судьбы вполне имеет право существовать, да и даже в случае если таких полномочий нет, не стоит отчаиваться, редактирование текста LSMWэшки в «Блокноте» нам и вам в помощь. Итак, смысл в том, что проект LSMW можно как экспортировать, так и импортировать, поэтому грех не воспользоваться такой прекрасной возможностью.

Читать далее


Полномочия ArhiveLink

Вы знали, что ArchiveLink умеет работать с HCM полномочиями и P_ORGIN? Цитирую: при правильно настроенной системе можно прикреплять документы к любым инфотипам, а доступ к документам предоставлять на основании доступа к инфотипу. Таким образом, если данные о семье прицепить к 21 инфотипу, то видеть документы будут только те люди, у кого есть доступ на 21 инфотип. (с) WHITE PAPER SAP Employee File Management.

Никогда сам такой штукой не пользовался, ибо все документы прикреплял к табельнику и/или 2 инфотипу. А тут такая приятность нарисовалась и совершенно бесплатно.

White paper – An Introduction to SAP Employee File Management-1


Вопрос-ответ. Перевод сотрудника

Вопрос. Перевод сотрудника

:
В системе настроено мероприятие технического перевода по группе компаний с изменением раздела персонала. В рамках этого мероприятия через динамику происходит создание нового табельного номера и копирование данных инфотипов и кластера с существующего. В старом разделе табельный увольняют. Всё работает относительно корректно.
Вопрос в том, если человек возвращается обратно в первый раздел персонала, то хотелось бы принимать его на старый табельный номер.

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

Как решить проблему с соединением кластера? Может быть есть какие то еще варианты? Ввести “лишнее” видами оплат?

Ответ

:
Отвечу честно – никогда не озадачивался вопросом копирования кластера. Изначально считаю это плохой практикой, что называется, одним местом чую, что это неверно.

Я лично попробовал бы решить задачу двумя способами.

1. Через глобальных сотрудников, когда физлицо определяется центральным лицом, а далее в каждой компании есть свой табельный номер, который связан через центральное лицо. Сам не настраивал, только читал. Увы.
2. Через переработку системы полномочий как в части бизнеса, Так и по системе. У меня сейчас на одном проекте схожая ситуация. В рамках холдинга нужно видеть всех сотрудников, их историю и так далее. Мы пока склоняемся к варианту переработки класса анализа полномочий таким образом, чтобы сотрудник Компании 1 мог видеть всю инфу по уволенным сотрудникам Компании 2. Тогда он сможет сделать повторный прием на тот же табельный номер, что решит проблему с переводами.