on 2014 Jul 21 4:34 PM
Hello everyone,
Short version:
I know two FM that can modify PA infotype data: HR_MAINTAIN_MASTERDATA and HR_INFOTYPE_OPERATION. However, neither of those includes a parameter that allows using them without them automatically checking authorizations (like you can do with, say, FM RH_INSERT_INFTY which has parameter AUTHY to disable authorization checks but only works with OM infotypes, but not PA infotypes).
Does anybody know a solution?
Long version:
We want the travel department to be able to maintain infotype 17, and only infotype 17. In fact, there are only two fields there that need to be maintained in our company. That department should not have access to any other infotypes, and we are not going to give them PA30. On the other hand, they shall be able to do so for any employee, no matter from which personnel area, subarea, and organizational unit.
So I have created a small program with a mask specifically tailored to their needs. But we do not want to give them any PA authorizations. Giving them P_ORGIN to infotype 17 might not be a big deal, but then we would also need to give them structural authorization to all companies (= org units and personnel areas). Unlimited structural authorization is a big deal, and I would rather avoid granting that to someone who is not supposed to be doing anything but this tiny bit in HR. The only authorization that I would like to see in place is transaction authorization for my program. Anyone who has that should be allowed to maintain these IT 17 fields for any employee, but nothing else.
The problem is that upon writing the data, FM HR_INFOTYPE_OPERATION auto-checks the authorization required for maintaining the infotype, including structural authorization, and so does FM HR_MAINTAIN_MASTERDATA, as far as I understand. Is there an alternative I could go for?
Hi Jens,
One option is to create wrapper RFC function module for HR_INFOTYPE_OPERATION and call that function module with local destination which uses the user with sufficient access. (e.g: WORKFLOW_LOCAL* which uses the WF-BATCH user id). But the Drawback is: Changed by will have RFC User ID.
Thanks,
Shrinivas Shenoy
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
94 | |
9 | |
8 | |
8 | |
6 | |
5 | |
5 | |
5 | |
4 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.