on 2014 Mar 19 10:13 PM
Hello,
I was tasked with changing authorizations so the payroll clerks cannot enter their own time using a specific profile. Done. I was also tasked with preventing the clerks from modifying their own master data using PA30. Partly done. They can not create, edit, or delete their own records, it is essentially display only.... except they are still allowed to copy a record and modify it. Does anyone know how to stop them from the ability to copy their
own records? They haven't copied their records up to this point but we need to mitigate the risk.
Thanks in advance for you help.
Jenn.
Request clarification before answering.
Hi ,
Please tell your basis guys to give the authorization to display(02) for the authorization object P_ORGIN for that specific user.
Regards,
pardip
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Pradip,
Thanks for the info, however, my department manages basis and a wide range of other things, and I have just been given the job to manage roles and authorizations.
I have tried modifying P_ORGIN as you suggested and it restricted them to edit all other employees but not allowing them to display their own records as they cannot enter their own employee number anymore. I had done the same thing using P_PERNR, it is just the "Copy" button still works, everything else is display.
I am looking to shut down the use of the copy button while still being able to display their records with the ability to modify all other employees in the organization.
Can you pass along the settings in P_ORGIN so I know what they should look like?
Thanks again,
Jenn
Hi,
if you want to use the personnel number check (authorization object:
P_PERNR) you have to activate it via transaction OOAC. In case
you want to achieve that one user can only maintain his own personnel
number we would recommend not to use P_ORGIN in the authorization
profile, but only P_PERNR. You can assign all infotypes that are
necessary via P_PERNR in the authorization profile. But
please activate 'P_PERNR' AND 'P_ORGIN' via transaction OOAC as
described in the attached note 362675.
Additionally, if you have IT0316 & IT328 defined, you might want to
consider just using IT0316.
IT0316 represents the authorization for data entry profiles and
depends on the profile setting. If a user has authorization for
IT0316 and for a specific profile authorization group (subtype of
infotype 0316) that has profiles not requiring approval assigned to it
the user can approve the data, even if he/she does not have
authorization for infotype 0328.
The good news is that this behaviour can be controlled on the infoset level by activating the corresponding switch "PROC_PERNR_PARTIAL_AUT" in the DATA section of the infoset code. Once this switch is set to "X", ad hoc query will always process all PERNR records and leave blanks where the user doesn't have authorization.
Note that this only works for PNP and PNPCE database.
For example:
I have developed many roles with auth object P_ORGIN. I need to develop a new role with NEW auth object Z_XXXXX. Transactions PA20,PA30, PA51 and PA61 are required in all roles to maintain HR Master data.
I found a conflict between P_ORGIN and Z_XXXXX:
=> When I assign Z_XXXXX auth object to new role. The new roles checks only to P_ORGIN values to assess the restrictions.
I don't want to assign Z_XXXXX to transactions PA20,PA30, PA51 and PA61 because I would force my previously created roles to check for this new object.
I created new auth object, because I need restrictions based on personnel subarea,
P_ORGIN (HR: Master Data) (SAP Library - Authorizations in mySAP HR)
Regards,
pradip
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.