The other day I’ve been asked to do an HR authorisations review / training for a mid-size international company. As ever so often, this wasn’t a pro-active measure, but triggered by unpleasant incidents of HR users in one country seeing and even involuntarily changing data with impact on payroll in another country. Whenever I’m looking for a quick win in this kind of workshops, asking about rights for the data medium workbench often hits the first issue – particularly in a setup, where module specialists are not involved in authorisations.
The first right required, apart from the transaction code PC00_M99_FPAYM in object S_TCODE, is the HR authorisation object P_ABAP with full rights for the reports SAPFPAYM and SAPMFDTA. This is actually one of the few cases, where P_ABAP is really required, rather than just a way to improve performance or make things simpler.
Many authorisation admins stop at that point, because, in the default SAP setup, it will work now. However, you may get more than you’ve asked for. Per default there is no specific check on company code or any other organisational concepts. Therefore, your UK payroll team would be able to see pay data for Sweden and the other way round. You probably won’t like that and even, if you don’t care, your next data privacy audit will. So, what needs to be done?
Well, you need to climb a wall now: the wall between your HR and Finance teams. This is what makes this particular issue difficult: it’s cross process and requires experts from both worlds to liaise. There are two steps:
1) Activate authorisation checks for HR payments by making this entry in table view V_DFPM_AUTH:
There’s no need for any content in the second column. You could use that column to implement a bespoke check, but the empty entry is enough to trigger the standard check.
2) This standard check is checking rights for authorisation object F_PAYRQ, where you can restrict the company codes a user has access to as well as the kind of payments (vendor payments, payroll,…) and the activities allowed (display, change,…). So, the following example would give the user all rights for payroll payments (but not for travel expense payments) for two company codes.
And that’s it :-)
So, in a nutshell: authorisation objects P_ABAP and S_TCODE give you basic access to the program, but would usually allow too much. Table DFPM_AUTH activates further checks and then object F_PAYRQ sorts out the detail.
We recently found quite a few of these gaps in HR authorisation designs, although the technical concepts required are not new at all. So, we’ll be sharing some more of these tips in the not too distant future. If you want to arrange for a quick review of your organisation’s HR authorisations, just get in touch
I was searching for a solution to a DME authorization problem and found this very interesting article, thanks for the sharing.
I have a similar but yet a different issue. The 2 HR users are from the same company, 1 handle top management payroll and the other handle normal staff payroll (controlled by payroll area and employee subgroup using object p_orgin). There is no problem to control their access in Pre-DME but unfortunately it is not the case in payment program SAPFPAYM due to the powerful P_ABAP access given.
Do you have any suggestion to resolve this issue? I really appreciate any help you can provide.
as you don’t want to differentiate by company code, but EE subarea and/or payroll area, you may need a custom function module to add in table view V_DFPM_AUTH
Thanks for your reply.
I tried the custom function module but unfortunately the parameters that passed in to this FM are only the following fields:
Laufd – Date on Which the Program Is to Be Run
Laufi – Additional Identification
Xvorl – Indicator: Only Proposal Run?
zbukr – Paying company code
DOrigin – Grouping Origin
Uname – user who has run the pre-DME
EE subarea and payroll area are not included, neither it has pernr number.
I guess I have to explore some other ways, probably a customized payment program.
Hello there:
Well, thank you very much for this Sven… even though I accidentally came by this post; it actually is solving an issue I had!
Giving P_ABAP to users for payroll payment was not really convincing since P_ABAP is so powerful.
This F_PAYRQ object just made them go away.
Cheers.
Hi Antoine,
great to hear it helped :-)