In my recent work I came across some questions if or how it could be achieved to check if a user with Finance/Controlling Authorisations can see employees of their cost centres or profit centres only.
SAP HR security is mainly based on the organisational assignment of employees which is stored in Infotype 0001 of the employee master record. Additionally a HR organisational structure check can be called to find out if the user has access to the part of the structure of the employee. The first option will mainly work with SAP authorisation object P_ORGIN. The second option however requires to switch on and to maintain at least HR structural authorisations.
A look at P_ORGIN will quickly show that there is no field cost centre or profit centre available. And who says that the HR organisational structure will match the Cost Centre or Profit Centre hierarchy of the company. There might be a manager who has responsibility for a cost centre but their cost centre might not be the only one with employees in a certain HR org unit.
Just a few weeks ago I found some SDN member with a quite similar issue in the forum.
He was after a solution to check whether the user has access to a certain Payroll Area. Now the Payroll Area is not included in P_ORGIN and it will be hard to find a HR authorisation object which will do the check.
But SAP is prepared for these sorts of specific needs in the area of HR security. SAP provided a BAdI. BAdIs are places in the SAP standard which allow to add customer specific logic without changing standard. Rich Heilman provided a good wiki on that: http://wiki.sdn.sap.com/wiki/display/ABAP/Enhancements+and+Modifications+-+BADI,+Enhancement+Framework,+User+Exits,+BTE
The BAdI which will help us to enhance the HR Authorisations is HRPAD00AUTH_CHECK
There are some things we should know about the BAdI when we start using it. The implementation will switch of the HR standard authorisation checks but no worries they can easily be called from our BAdI again. That is something what I would recommend. When the BAdI will be switched on always start with the implementation of every method and call the SAP standard authorisation class method with the same name.
Once this is done select the method you want to enhance and call additional checks in the method.
For example method ‘CHECK_AUTHORIZATION’. Here we can implement additional checks for certain and critical infotype records. In that case we could call the SAP standard authorisation check first. If standard checks are passed we can check additional customer specific criterias for the user who tries to get access to that specific infotype. Our customer check could for example look up the employee assignment to a cost centre. With the employee cost centre it could then call the authorisation check on authorisation object K_CSKS.
How good is that? That example will allow to check authorisations for a cost centre of an employee when accessing HR data. Even more, that example would do the check only for certain infotypes. And last but not least as long as we call the check of the authorisation object in the good old ABAP standard way, the result will show up in a security trace (transaction ST01).
You can think about many options which SAP provided us with that BAdI. The doors are open for all sorts customer enhancements of HR security. It is fantastic.
As mentioned earlier there was a question in the SDN forum about an authorisation check on the Payroll area. Following I will provide the screen shots of my answer. That will allow to follow the idea I have described above. Maybe some of you might find that there are too many screen shots in here. But I think that everybody should get the chance to read through and to understand. I like to enable people to start trying and playing even if they have not used BAdIs and ABAP as much.
The screen shots will document 2 topics which might help to get started on new ideas. They will explain how we can easily create customer authorisation objects and related to the topic of the blog they will show a really simple implementation of the BAdI.
Creation of an new authorisation object – Transaction SU21
In SU21 all authorisation classes will be displayed as folders and the authorisation objects are displayed within these folders.
The creation of own authorisation objects will start with the creation of a new authorisation class.
The new authorisation class will be shown in the tree structure.
Now the class should be highlighted and the Create Icon must be clicked again to create the new Authorisation Object.
After the new authorisation object is created it will appear in the folder of the authorisation object class.
Now it is time to implement the BAdI HRPAD00AUTH_CHECK – transaction SE19
Click on TAB Interfaces at the BAdI implementation screen.
The Interface TAB shows the name of the Implementing ABAP class.
A Double Click on the Implementing Class name will navigate to the ABAP class builder.
As described earlier I would always recommend to call the SAP standard authorisation checks. To do so, it will be required to call the SAP standard logic from another class.
Therefore the creation of a new class attribute is required. I called it
SAP_STANDARD_AUTH with TYPE REF TO CL_HRPAD00_CHECK_STD as shown below.
The new attribute will be used to keep an instance of the SAP standard authorisation class. The Instance will be created in method IF_EX_CL_HRPAD00_CHECK_STD~DELAYED_CONSTRUCTOR
The method will require the following coding block to create the instance of the SAP standard authorisation class.
CREATE OBJECT sap_standard_auth.
The instance should now always exist when methods of the BAdI will be called.
Back at the class overview of all methods I will show an example implementation of one method. The same must be repeated for every single method of the class.
To start double click on a method.
Start by copying the following code between Method IF…
IF sap_standard_auth IS INITIAL.
CREATE OBJECT sap_standard_auth.
IF sy-subrc = 1.
ELSEIF sy-subrc = 2.
The part where I check if we have an existing instance of SAP_STANDARD_AUTH might be redundant. But I think it is a good idea to avoid any unexpected errors. Now back to the code.
The cursor should be placed before the last IF clause and then we start to use the ABAP Pattern Function.
The method name in the pattern screen and the method we are working on must match.
The commented code should be uncommented. The parameter names will be the same.
Remember the same should be done for all methods except the DELAYED_CONSTRUCTOR of course.
Once that has all been done, the building of the customer logic can begin. In my example I will demonstrate now a very simple check on the new authorisation object.
The example however is not the end of what is possible. Surely many other employee related data could be read and checked here. The conditions for the checks can be built creative as well. For example could checks just be done if certain infotypes are requested by users etc.
The check on my new object will go into Interface Method: CHECK_AUTHORIZATION
In there I add some code just before the endmethod statement. The customer check will just be done if the standard checks have been passed before. In the example I run the checks only for a certain transaction.
CHECK is_authorized EQ ‘X’.
CHECK sy-tcode EQ ‘PC00_M99_CIPE’.
DATA : l_abkrs TYPE abkrs.
SELECT SINGLE abkrs FROM pa0001 INTO l_abkrs
WHERE pernr EQ pernr AND
endda GE sy-datum AND
begda LE sy-datum.
IF sy-subrc IS INITIAL.
AUTHORITY-CHECK OBJECT ‘Z_PY_AREA’
IF sy-subrc IS NOT INITIAL.
And that is all. By the way the Authorisation Check on the new authorisation object has been build using the ABAP editor pattern function again.
It is time to activate the Implementing Class of the BAdI.
Clicking the BACK button will take us back to the BAdI.
Finally the BAdI must be activated.
That is it. Now all is said and customer authorisation checks in HR should never be an issue again. 🙂