Сейчас я себе вынесу моск. Вы посидите рядом, посмотрите, покрутите пальцем у виска в мой адрес. Я пока разберусь для себя, что же все-таки входит в полномочия 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. Пройти по структуре мы можем по-разному.
- Можно взять путь анализа и прогуляться по нему. Стандартный и скучный O-S-P или любой веселый свой. Для пути анализа нужна отправная точка — корневой объект, который нужно указать.
- Можно взять функциональный модуль, который на вход получит что-то, на выходе отдаст корневой объект организационного менеджмента, который уже по пути анализа из пункта выше отдаст перечень объектов, к которым нужен доступ.
Теперь расширяем понятие структурных полномочий на организационную структуру. Оргструктура это тоже объекты, такие же как P. Поэтому, определяя доступ к организационной структуре с помощью объекта полномочий PLOGI мы определяем КАКОЙ доступ дать к определенному объекту, а САМ объект можно получить через структурные полномочия.
То есть аналогия такова. Для администрирования персонала есть разграничение полномочий по разделу/подразделу/группе/категории. Для организационного менеджмента ничего такого нет, поэтому разграничение можно сделать с помощью путей анализа и корневых объектов. Например, задать всю структуру второго уровня, не ниже. Тоже вариант 😉
Профиль структурных полномочий определил объекты, к которым мы можем обратиться. Объекты полномочий PLOGI и P_ORGIN определили как мы можем обратиться к этим объектам. Вроде бы все логично. Теперь нужно связать меня, Поцелуева, он же в простоинтернетии VirVit, с нашим профилем структурных полномочий, который даст те или иные права мне.
Есть несколько вариантов решения задачи.
- В транзакции OOSB присвоить моему пользователю созданный профиль.
- В транзакции OOSB присвоить пользователю SAP* созданный профиль. Тогда все, кто НЕ указан в транзакции OOSB автоматически, по-умолчанию получат этот профиль.
- Использовать BADi HRBAS00_GET_PROFL
И есть окольное решение. Сделать связь US — O. Сделать свой функциональный модуль, который присвоить в профиль структурных полномочий, а профиль присвоить SAP*. Тогда доступ будет определяться исключительно на основании того, к какой организационной единице я привязан. Это наиболее гибкий путь. Для примера посмотрите функциональный модуль RH_GET_ORG_ASSIGNMENT.
Контекстные полномочия призваны свернуть мозг любому. Постараюсь объяснить на примере.
- Включены обычные полномочия. Доступ Вася получил на основании раздела персонала АБВГ. Видит всех, редактирует всех. Вася счастлив. Классический PFCG.
- В один раздел персонала АБВГ приняли много селедок так, что в консервной банке стало тестно. Взяли в помощь Васе Машу. Теперь Вася и Маша могут видеть всех в разделе персонала АБВГ и редактировать всех. Вот только незадача, что стали они другу другу мешать. Один другого блокирует, селедки жалуются. Разделили селедок на две организационные единицы поровну. Теперь включаем структурные полномочия. Васе доступ на одну единицу, Маше на другую. При этом у обоих одинаковый PLOGI, P_ORGIN. Но благодаря структурным полномочия Вася видит своих селедок, а Маша своих. Мы либо напрямую прописали каждому свой профиль с указанными ID для объектов типа O, либо сделали красиво и динамически через US — O. Вы поняли, да?
- Маша хорошо работала и ее повысили. Сделали ей совмещение профессий так, что она теперь для раздела персонала АБВГ может все редактировать, а для двух селедок, которых выделили в отдельную организационную единицу, еще и зарплату может считать. Структурные полномочия уже не могут отдельных селедок выделить. Точнее могут, но доступ-то им дает P_ORGIN, а он един на весь раздел персонала. Вот тут и появляются контекстные полномочия, которые скрещивают обычные со структурными в одном месте. Теперь система говорит, что она даст полномочия из P_ORGIN только тем, кого вернет ей особый профиль структурных полномочий. Отсюда и появился новый объект полномочий P_ORGINCON. В нем есть поля из привычного нам P_ORGIN и указание, на какие объекты действуют эти полномочия — ссылка на профиль структурных полномочий. Что же получается. У Маши теперь будет два профиля структурных полномочий: один вернет всех для целей редактирования, другой вернет только две селедки для целей расчета заработной платы. Будет условно два объекта P_ORGINCON, где один будет содержать права на редактирование, скажем, отсутствий — всем селедкам, и с указанием профиля 1. И второй объект с правами на изменением ИТ0009 с профилем 2, указывающим на двух селедок. Как разграничить селедок? Мне кажется по отдельной связи US — O (может редактировать, может считать зарплату).
Проверка пользовательского объекта полномочий OOAC — NNNNN. А вот тут самое интересное. Мы можем сделать свой объект полномочий в транзакции SU21. В нем нужно прописать обязательные стандартные поля
INFTY: Infotype
SUBTY: Subtype
AUTHC: Authorization Level
А еще можно нарисовать любые поля из структуры PA0001. Вы понимаете, какая это офигенная круть? А чтобы довести вас до экстаза, надо добавить еще поле TCD, которое будет заполняться кодом текущей транзакции. Таким образом, можно назначать полномочия в зависимости от транзакции, которую вы запускаете. Если это отчет для налоговой, где нужно дать доступ на ТОПов, то делаете все группы и категории = *, а TCD = 4-ФСС.
Полномочия на инфонабор в SQ02. При создании инфонабора можно заполнить поле Authorization group, которое затем позволит ограничить доступ к запросам (SAP QUery) на основании этой группы полномочий. Сама группа проверяется в объекте полномочий S_PROGRAM.