I contemplated writing this blog for quite a while and have delayed it for some time, because it is not a new issue and it is basic HR security. However, I have seen many SAP clients struggling to get that basic setup right. So, why not blog about it? It might help some of you.

We all know that authorisation object P_ORGIN is used to limit access to infotypes and related activities, don’t we?

We also know that authorisation object P_PERNR gives us an opportunity to restrict users to either their own records or to everyone else’s record, don’t we?

That was easy.

Now we might encounter an issue. Imagine an employee needs ESS access and within that lots of infotypes like 0007, 0008, 0188, 2001 or 2002. Alright, we restrict P_ORGIN to display these infotypes and we set P_PERNR to restrict the ESS access to the employee's own record only.

Suddenly, we find that our new ESS user also needs another SAP backend authorisation to display infotype 0024 (qualifications) in combination with transaction PA20. But this is not where our requirement ends. Just imagine that the ESS user doing the qualification reporting must also check the basic pay. As we all know highly skilled people should earn higher salaries. That is why our ESS user will get infotype 0008 (basic pay) display access as well.  The access for infotype 0008 is restricted to certain employee subgroups, so that our user cannot display the basic pay records of the company’s executives.

Now we face the issue of cross pollination. The ESS role contains P_ORGIN with infotypes 0007, 0008, 0188, 2001 or 2002 and no further restrictions. The qualification role restricts infotype 0008 access through P_ORGIN to certain employee subgroups. The dilemma is that P_ORGIN assigned through the ESS role would override the restriction for the employee subgroup of infotype 0008 enforced by the qualification reporting role.

Here is an example how the setup is done WRONGLY. Sadly, I have seen it at many sites like that.

ESS

Qualification Reporting

The setup shown above won’t work. The restriction on infotype 0008 of the qualification report role is resolved by the P_ORGIN in the ESS role. And the P_PERNR of the qualification report role will override the ESS restriction. As result the ESS employee with qualification report access can happily report on anyone’s pay without restriction.

Surely there must be a way to resolve that.  Logic tells us that we need to find a way to give everyone access through ESS without creating a generic infotype access which would then cross pollinate all other roles.

Here is how it works:

ESS

Qualification Reporting

Why does that work?

Looking at the ESS role first, we find that the P_ORGIN object has neither an infotype specification nor a subtype specification and will therefore not grant any access if it is considered without the context of P_PERNR. That means in other words, we could go further and completely remove P_ORGIN from the ESS role as it doesn't grant any access at all.  The authorisation check will look at this as follows:

“Ok let's see what are you allowed to see? First I like to know if you have permissions through P_PERNR. There you go, you have permission to see your own data for infotypes 0007, 0008, 0188, 2001 and 2002.

Now lets see if you have permissions through P_ORGIN to further HR groupings. No you don't but anyway, that is all right, as you only request display access to your own data through ESS”

The P_ORGIN will not cross pollinate any longer as it cannot grant authorisation by itself. The P_PERNR object will grant access to the employee's own records which is absolutely sufficient for ESS. It doesn't matter that the subsequent check for P_ORGIN fails.

Now, that means for the Qualification Report role that the P_PERNR object of the ESS role will no longer restrict the infotype 0008 access to the employee’s own basic pay record.  Therefore it is no longer required to have the P_PERNR object (overriding setup with '*' in field PSIGN) in the qualification role. The access to infotype 0008 is now restricted correctly through the employee subgroup restrictions of P_ORGIN in the Qualification Report role.

Everyone will be happy and thanks to Karsten Arold

Reports that are available for HR partner

SAP reports are of three types, based on the location they are created and executes. One is SAP ECC reports that are run in SAP ECC using a transaction code. The send is a portal report, that is executed by logging in to Umoja Portal and clicking the appropriate link. The third one is the BI report, that is run out of Umoja BI system.

This blog is on the first category, the ECC reports that are executable by a HR partner. All HR ECC reports are part of HR Display All roll and it is embedded in HR Partner All role.

Please note, the HR partner all for an entity can administer all staff under that entity, but can view (display/run reports) all staff under Umoja Common system.

To select and run the reports, please see the screenshot below. All reports under these nods are executable by a user with HR Partner All role.

Checking My Certifying Officers

In Umoja, it is advised to check your certifying officers before you start a transaction that needs financial certification. For example creation of official business needs a financial certification by the travel and shipment Approver. In order to avoid the approval workflow, each and every user is encouraged to try the following steps to proactively determine the certifying officers before even creating the transaction. Please note, the certification is based on the cost objects (Fund and Cost center) and the the users who are mapped to these cost objects based on the delegation of Authority (DOA) will be the approvers for those transactions.

• Log on to Portal; and you will be landing in Home tab. Click/select User map.

• The User map will default your name and will get all information in and around you

• On the User or Employee Search, please enter the Fund and Cost center for which you need to find the certifying officer
• Press Enter

• Select from the first tab ‘My Approvers’ the travel view

• The people who are listed under Travel and Shipment approver are the certifying officers for the travel request you will be creating.