Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

P_PERNR does not exclude changes, related to the use of P_ORGINCON?

l_borsboom
Active Participant
0 Kudos

Hi there,

I have the following question:

I want to restrict a HR Administrator to be able maintain its own infotypes 0008 and 0105.

The role contains the following authorizations:

P_ORGINCON:

Authorization level D, E, M, R, S, W

Infotype 0008, 0105

Personnel Area 2000

Employee Group *

Employee Subgroup *

Authorization Profile *

Subtype *

Organizational Key *

P_PERNR:

Manually HR: Master Data - Personnel Number Check

Authorization level D, E, S, W

Infotype 0008, 0105

Interpretation of assigned per E

Subtype *

However, the user is still able to maintain its own salary

The ST01 trace shows that P_PERNR only performs checks for read access, write access is only checked for P_ORGINCON:

P_PERNR RC=4 tcode=PA30;AUTHC=R;PSIGN=*;INFTY= ;SUBTY= ;

P_PERNR RC=4 tcode=PA30;AUTHC=R;PSIGN=E;INFTY=;SUBTY=;

P_PERNR RC=4 tcode=PA30;AUTHC=R;PSIGN=I;INFTY= ;SUBTY= ;

The followin switches have been turned on in OOAC:

AUTSW ADAYS 15 HR: Tolerance Time for Authorization Check

AUTSW APPRO 0 HR: Test Procedures

AUTSW DFCON 1 HR: Default Position (Context)

AUTSW INCON 1 HR: Master Data (Context)

AUTSW NNCON 0 HR:Customer-Specific Authorization Check (Context)

AUTSW NNNNN 0 HR: Customer-Specific Authorization Check

AUTSW ORGIN 0 HR: Master Data

AUTSW ORGPD 0 HR: Structural Authorization Check

AUTSW ORGXX 0 HR: Master Data - Extended Check

AUTSW PERNR 1 HR: Master Data - Personnel Number Check

AUTSW XXCON 0 HR: Master Data - Enhanced Check (Context)

I am a little confused why this customer has activated the context switch, because all P_ORGINCON values for PROFL are '*'

Could this be the reason for ignoring the P_PERNR authorization?

I want to know for sure before making any changes in customizing.

Can anybody rule out [note 1434022|https://service.sap.com/sap/support/notes/1434022] ?

Thanks in advance for your suggestions.

Kind regards,

Lodewijk Borsboom

1 ACCEPTED SOLUTION

Former Member
0 Kudos

Hi,

Everything is looking fine only one thing Can we hvae a check in the IT0105 that subtype 01 ( user id ) is maintained for the Personnel administrator.

Best Rega

Vikas

8 REPLIES 8

Former Member
0 Kudos

Hi,

Everything is looking fine only one thing Can we hvae a check in the IT0105 that subtype 01 ( user id ) is maintained for the Personnel administrator.

Best Rega

Vikas

0 Kudos

You're right, I forgot to mention that.

My test userid has been entered in IT0105 for the personnel number I am testing, so that's OK as well.

Still no solution though

Regards,

Lodewijk

Former Member
0 Kudos

If I understood the note correctly, you might have applied the related notes via note assistant and then corrected it again via transaction SPAU when applying the SPs.

Take a look in SPAU whether anything relates to this? (I am not sure what you mean about "rule out" the note).

Also you appear to have a 15 day context tollerance. Are those 15 days over yet?

Cheers,

Julius

Former Member
0 Kudos

Hi Lodewijk,

This may sound silly idea but I guess you are willing to try even this.

Add also following:

P_PERNR

Authorization level R, M

Infotype 0008, 0105

Interpretation of assigned per I

Subtype *

I remember one or two situations where system was checking first read option and when the check failed then system assumed that this is not the person and continued with P_ORGINCON which is of course incorrect.

But it's only SAP you know So I would try adding the read access also and try to see if that helps.

Regards,

Saku

0 Kudos

That would be a bug if it was the case, because according to the SU21 documentation you cannot assign combinations of I and E interpretations and the example of using the object in SU21 is exactly the one which Lodewijk is also using here.

Cheers,

Julius

0 Kudos

I don't have my HR940 book with me right now but I am pretty sure I have done something like this before:

P_PERNR:
Authorization level R, M
Infotype *
Interpretation of assigned per I
Subtype *

P_PERNR:
Authorization level D, E, S, W
Infotype 0008, 0105
Interpretation of assigned per E
Subtype *

And it has worked even I have had mixed I and E in separate objects in the same role. What I understand from SU21 is that I can't have the combination of I and E in a single object like this because that wouldn't make any sense:

P_PERNR:
Authorization level D, E, S, W
Infotype 0008, 0105
Interpretation of assigned per I, E
Subtype *

I have a vague memory that there might even been a exercise in HR940 where two P_PERNRs were added to role and another one had I and another one had E in the sign field.

I have never understood why P_PERNR has been made so difficult to understand. Even the third field name is something what doesn't make sense to me at all. My opinion is that third field is useless. P_PERNR should work as P_ORGIN(CON) and you can only give access to own data using it. Nothing what you don't list as given would be automatically excluded. I think that might make also some HR ABAPers happy.

My 2 cents... I feel for anyone getting frustrated with P_PERNR. So many times I've had a feeling that I finally completely understand the beast but I keep second guessing everytime when I have to think the bugger...

'saku

Former Member
0 Kudos

Hi,

You might have already checked it but its worth mentioning again that P_PERNR check is only applicable if the user has an Active personnel number and IT0105 subtype 0001 is assigned correctly to link its system user name.

Can you confirm if you have checked these too?

Thanks

Sandipan

0 Kudos

Hi

Can you add exactly the same values of AUTHC in P_PERNR as that of P_ORGINCON and let us know what happens?

Leave rest of the fields in P_PERNR as it is you have added before.