что такое роли в сап
Виды полномочий в 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
NNCON — включает или выключает пользовательские контекстные полномочия P_NNNNNCON (об этом ниже).
NNNNN — включает или выключает пользовательские обычные полномочия
ORGIN — включает или выключает использование стандартной проверки полномочий с помощью P_ORGIN
ORGPD — включает или выключает сам механизм использования структурных полномочий. Значения такие же, как у DFCON. Не понял в чем разница. Ушел думать дальше.
ORGXX включает или выключает расширенную проверку полномочий с помощью объекта P_ORGXX. Внутри объекта P_ORGXX можно расширить проверку полномочий на поля блока администраторов из ИТ0001 (администратор кадров, времени, зарплаты). Например, если вам мало разграничить полномочия по разделам персонала, но еще и нужно по отдельным людям, которые будут заниматься этими табельниками, то вполне можно ввести табельщиков как администраторов рабочего времени и раздать им полномочия по людям. Тогда не нужно использовать структурные полномочия, и одновременно можно разграничить доступ по бригадам или цехам в одном большом структурном подразделении.
PERNR — определяет доступ к самому себе. Если этот переключатель включен, то с помощью объекта P_PERNR можно переопределить полномочия своей же роли только для своего табельника. Например, я Поцелуев, главный зарплатчик. По своей роли я могу менять всем ИТ0008 и считать зарплату. Но я вредный, и иногда хочу поменять себе зарплату. Вот чтобы такого не случилось, вредный администратор добавляет в мою роль полномочия P_PERNR, где стоит PSIGN = E (Exclude — исключить) и AUTHC = W,D,S (удалить из моих полномочий права на изменение 8 ит для меня самого). Как система узнает что я, это я. Легко. В ИТ0105 мы записываем USER = VIRVIT для табельника 1235. Поэтому разумно мне, вредному Поцелуеву, не давать полномочия на изменение 105 инфотипа. Этот объект полномочий часто используется в ESS, когда мы хотим дать работникам поменять что-то в своих персональных данных. Чтобы они не могли менять у всех, мы даем права только на самих себя с помощью P_PERNR-PSIGN = I.
XXCON аналогичен ORGXX, но работает для контекстных полномочий, когда мы хотим сначала ограничить доступ по организационной структуре, а затем еще и администраторами добить полномочия. Капут, короче, полный, аллес. Объек для надругательства — P_ORGXXCON
С ключиками все, идем дальше.
Основные расширенные полномочия всего навсего расширяются ключиком в OOAC-ORGXX, а в роли добавляется объект P_ORGXX. Как уже было сказано задачей этого объекта является уточнить доступ внутри раздела/подраздела персонала, группы/категории с помощью полей Администраторов из инфотипа Организационное присвоение.
Контекстные расширенные аналогичны основным расширенным, только ключик XXCON и объект P_ORGXXCON.
Проверка самого себя P_PERNR. Рассмотрели выше для ключика OOAC — PERNR.
Полномочия P_TCODE это такая архаичная штука, которая зачем-то еще жива. Этот обьект полномочий определяет доступ исключительно к части HR транзакций, которые удовлетворяют условиям: а) код транзакции начинается с P*, б) внутри этой транзакции осуществляется проверка на объект полномочий P_TCODE. Найти такие транзакции можно в SE93 через Utilities — Find, Edit — All Selection. У меня таких набралось 301 штука. То есть сначала система проверяет на уровне базиса код транзакции по S_TCODE, а потом на уровне HR еще и P_TCODE. Это нужно для того, что в HR иногда одна транзакция вызывает другую, поэтому таким образом разграничиваются полномочия. Негуманно, но факт.
А теперь настало время ада. Есть структурные полномочия, а есть контекстные полномочия. Оставайтесь на связи, не перегрейтесь. Я закипаю.
Структурные полномочия решают одну простую задачу — к какому конкретному табельному номеру дать доступ. Неважно какой доступ, важно кому. То есть, задача структурных полномочий пробежаться по организационной структуре, собрать все объекты типа P Лицо и отдать их в механизм проверки стандартных полномочий P_ORGIN и P_ORGXX. Все.
Включаются структурные полномочия в OOAC — ORGPD. Структурные полномочия представляют собой Профиль структурных полномочий. Не путать с профилем полномочий обычных, который можно увидеть в SU01 (SAP_ALL это тоже профиль, для тех кто не знал). Профиль структурных полномочий определяет КАК пройти системе по организационной структуре и вытащить объекты типа P. Пройти по структуре мы можем по-разному.
Теперь расширяем понятие структурных полномочий на организационную структуру. Оргструктура это тоже объекты, такие же как P. Поэтому, определяя доступ к организационной структуре с помощью объекта полномочий PLOGI мы определяем КАКОЙ доступ дать к определенному объекту, а САМ объект можно получить через структурные полномочия.
То есть аналогия такова. Для администрирования персонала есть разграничение полномочий по разделу/подразделу/группе/категории. Для организационного менеджмента ничего такого нет, поэтому разграничение можно сделать с помощью путей анализа и корневых объектов. Например, задать всю структуру второго уровня, не ниже. Тоже вариант 😉
Профиль структурных полномочий определил объекты, к которым мы можем обратиться. Объекты полномочий PLOGI и P_ORGIN определили как мы можем обратиться к этим объектам. Вроде бы все логично. Теперь нужно связать меня, Поцелуева, он же в простоинтернетии VirVit, с нашим профилем структурных полномочий, который даст те или иные права мне.
Есть несколько вариантов решения задачи.
И есть окольное решение. Сделать связь US — O. Сделать свой функциональный модуль, который присвоить в профиль структурных полномочий, а профиль присвоить SAP*. Тогда доступ будет определяться исключительно на основании того, к какой организационной единице я привязан. Это наиболее гибкий путь. Для примера посмотрите функциональный модуль RH_GET_ORG_ASSIGNMENT.
Контекстные полномочия призваны свернуть мозг любому. Постараюсь объяснить на примере.
Проверка пользовательского объекта полномочий OOAC — NNNNN. А вот тут самое интересное. Мы можем сделать свой объект полномочий в транзакции SU21. В нем нужно прописать обязательные стандартные поля
AUTHC: Authorization Level
А еще можно нарисовать любые поля из структуры PA0001. Вы понимаете, какая это офигенная круть? А чтобы довести вас до экстаза, надо добавить еще поле TCD, которое будет заполняться кодом текущей транзакции. Таким образом, можно назначать полномочия в зависимости от транзакции, которую вы запускаете. Если это отчет для налоговой, где нужно дать доступ на ТОПов, то делаете все группы и категории = *, а TCD = 4-ФСС.
Полномочия на инфонабор в SQ02. При создании инфонабора можно заполнить поле Authorization group, которое затем позволит ограничить доступ к запросам (SAP QUery) на основании этой группы полномочий. Сама группа проверяется в объекте полномочий S_PROGRAM.
Рубрика Полномочия SAP HCM и безопасность SAP HCM
Полномочия SAP
Друзья, я решил заняться этим сайтом, сделать его удобнее, привлекательнее и информативнее. Для начала я собрал все заметки про полномочия SAP, SAP HCM в одном месте для вашего удобства. Справа вы увидите новую категорию «Полномочия SAP HCM» https://saphr.ru/sap-permissions/, милости прошу осмотреться и вспомнить что-то старенькое или забытое новенькое. В настоящий момент в категории 25 заметок.
Настраиваем аудит изменений в SAP HCM
Для объектов оргменеджмента:
Настройка в ракурсе T77CDOC_CUST
Смотреть отчет по аудиту в программе RHCDOC_DISPLAY
Для объектов администрирования персонала:
Настройка в ракурсах
V_T585A — включить определенный инфотип в аудит
V_T585B — включить конкретные поля инфотипа для аудита
V_T585C — определить группы полей для аудита. В группах полей есть признак срока хранеиня документов. Он позволяет определить, для каких целей мы хотим хранить историю изменений. Если L — long-term, то эта информация больше подходит именно для целей аудита изменений. Если S — short-term, то эту информацию SAP рекомендует использовать для целей передачи во внешние системы (по сути как IDOC, но проще).
Смотреть в отчете RPUAUD00_PNPCE
Для создания своего объекта для учета изменений можно воспользоваться транзакцией SCDO.
Виды полномочий в 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
Наблюдаем за пользователями в SAP Query
Вы же наверняка читали курсы внимательно и очень внимательно. И наверняка знаете о возможностях протоколирования SAP Query. А я не знал. Почитал курсы и столько там интересного узнал, что сейчас поделюсь с вами.
Например, можно протоколировать все, что запускает пользователь в оперативном запросе или SAP Query. Настраивается элементарно.
Заходим в SQ02, меню Extras — Set Logs. 
Тут прописываем инфо-наборы и области, которые мы хотим наблюдать. Первая колонка это глобальная или локальная область (G и пробел соответственно). Вторая сам инфонабор.
Теперь при запуске пользователями отчетов, построенных на указанных инфонаборах система запишет все и вся вот в таком виде.
А если вы хотите посмотреть в таком же виде, то нужно вашего пользователя присвоить группе пользователей /SAPQUERY/SQ в глобальной области, а затем открыть в оперативном запросе отчетики.
Не забываем кликать вот сюда:
Персонализация настроек пользователя
Есть в САП любопытный зверек в ролях полномочий, который отвечает за персональные параметры пользователя. Если нам нужно что-то массово присваивать пользователям, а затем дать возможность изменять индивидуально, то персонализация это наш конек. Параметры пользователя массово по бизнес-функции не присвоить. Объекты полномочий индивидуально на уровне пользователя тоже не изменить. Остается городить свои таблички либо воспользоваться механизмом персонализации настроек пользователя.
Некоторые приложения уже начали его использовать. Суть в том, что мы на уровне роли можем определить специализированные параметры, которые по-умолчанию будут заданы пользователям, у которых есть роль. Если нужно переопределить на уровне пользователя, то в SU01 мы это можем сделать. Очень удобно на мой взгляд.
Сам объект персонализации определяется в транзакции PERSREG. Это могут быть простые данные, так и табличные. Очень удобно хранить зависимые от пользователя настройки для расширений отчетов, например. 
Настройка ролей пользователей¶
В зависимости от функциональных обязанностей пользователю должны быть присвоены соответствующие системные роли для работы в Продукте. Присвоение ролей пользователю может быть осуществлено несколькими способами:
с помощью транзакции ведения пользователей SU01 ;
Присвоение роли в транзакции SU01¶
Для присвоения роли пользователю выполните следующие действия.
Присвоение роли в транзакции PFCG¶
Для присвоения пользователя роли выполните следующие действия.
Ролевая модель xDE для SAP ERP¶
В Продукте предусмотрено разделение полномочий пользователей по ролям, представленным в таблице ниже.
