Restricting P_ORGIN checks to the current state of an employee

[jensupetersen]

Hello everyone,

as part of our authorization concept, we are using the field PERSG in authorization object P_ORGIN (and P_ORGINCON) to determine whether a user has access to the infotypes of a given employee.

In the current example, the user may access employees with a personnel group (PERSG) '1' - '9', but not 'M', because our PERSG 'M' stands for 'manager', so his P_ORGIN and P_ORGINCON are restricted to PERSG BETWEEN '1' AND '9'. Basically, this works nicely.

However, there are cases in which an employee is promoted to manager level. His former PERSG in infotype 0001 is '1', but beginning from a certain date, his PERSG changes to 'M'. The autorization system now lets the user still see the former periods of time of this employee during which his PERSG was still '1', even though now he is 'M'. I understand that this is correct system behavior as SAP designed it. However, in our case it is undesired by the management. Once an employee has been promoted to PERSG 'M', none of his infotype periods should be visible to any user who does not have the 'M' authorization level.

Is there a way to achieve this?

[Eva_1 · Accepted solution]

Hello Jens,

yes, it is standard time logic in HR authorization (see note 2054808's attachment). You can implement HRPAD00AUTH_CHECK/BAdI HRPAD00AUTH_TIME  to bypass it.

Cheers

Eva

[jensupetersen · Accepted solution]

Hello Eva,

thank you very much, that appears to be the right track already. Trouble is, HRPAD00AUTH_TIME is very poorly documented. It has two methods "CONSIDER_SY_DATUM_EXIT" and "BEGDA_ENDDA_COMPARE_EXIT" which have documentations of their own.

• The documentation of CONSIDER_SY_DATUM_EXIT says that this method is only applicable if T528A-VALDT is set to 'X'. However, the whole table T528A does not even exist in our system?! (7.40)
• Documentation of BEGDA_ENDDA_COMPARE_EXIT leaves me pretty clueless how to interpret the IMPORTING parameters. I would have expected to be able to set the new time for which the system shall check the authorization. However, the only available export parameters allow me to set whether authorization is given or not, overriding the standard coding. So it seems that with this method I am not changing the time period for the check, but overriding the whole authorization process altogether?!

My other hope was note 570161, but the BADI HRPAD00CHECK_TIME which is referred to there does not seem to exist in our release anymore, so I assume it is obsolete.

Do you happen to know anything more about the BADI that would make its usage for my purpose more transparent?

[Former Member · Accepted solution]

The table is T582A which is the infotype table.

I found this interesting link:

http://sap-consalt.ru/vanilla/discussion/58174/note-570161-badi-time-logic-in-pa-authorization-check...

Apparently, as per this link, HRPAD00CHECK_TIME cannot be used if custom time dependent logic is dependent on employee group (PERSK) as is in your case.

[Eva_1 · Accepted solution]

Hello Jens,

it is HRPAD00AUTH_TIME. The note itself is obsolete because this badi is delivered in standard in higher releases but I would say this example coding still can be used.

Hope it helps

Eva

[Eva_1 · Accepted solution]

Hello Donnie,

I think there is a small misunderstanding here. Time logic is ment to describe how the authorization check works for an administrator if an employee has an organizational change. This can be PERSK, or PERSG or any other P_ORGIN relevant field from IT0001. For this case there is a standard time logic delievered (see note 385635). If you want to change it you can use HRPAD00AUTH_TIME.

The author in this documentation you copied here ment "PERSK  dependent time logic"! Which is not the case here.

Cheers

Eva

[jensupetersen · Accepted solution]

Hello Eva,

with HRPAD00AUTH_TIME I am having the problems I described in my previous reply. (see the two bullets and their preceding text)-

The BADI from note 570161 is apparently not delivered in standard because it does not exist at all on our system.

[Eva_1 · Accepted solution]

Hello Jens,

I think there are some typos here. The table is T582a and not T528A!

The badi to implement is  HRPAD00AUTH_TIME. In the solution part of the note  570161 it talks about this as well.

E

[Former Member · Accepted solution]

Hello Eva,

Thanks for the clarification.

[jensupetersen]

Thank you very much. That pretty much explains it. So the mistakes are on SAP's side (wrong table name in the documentation of method CONSIDER_SY_DATUM_EXIT in interface IF_EX_HRPAD00AUTH_TIME and repeatedly wrong BADI name in "Symptom"-section of note 570161). Sad that they never cared to fix this.

Unfortunately, it seems as if HRPAD00AUTH_TIME will not do for me, because the logics I described is only desired for the personnel group (PERSG), not e.g. for the personnel area (PERSA). We do not want a user who may see e.g. personnel area Z001 to be able to view the employee data from the time when the target employee belonged to a different personnel area. In other words, as far as the personnel area is concerned, we need the SAP standard time logics.

I understand that this can onyl be implemented using the big BADI HRPAD00AUTH_CHECK, which is a risky thing to do. We will now ponder our options.