Restricting authorizations in PA30 within the payroll department

[former_member1087252]

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.

[Former Member]

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

[former_member1087252]

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

[Former Member]

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,

Authorization Objects P_ORGIN - Authorizations in Performance Management (Objective Setting and - SA...

P_ORGIN (HR: Master Data) (SAP Library - Authorizations in mySAP HR)

Regards,

pradip