How to stop incorrect way of assigning a position to a person

[Former Member]

Hi group

We have found that our users change an employee's position by editing the relationship (HRP1001) between the position and the person in PO13. In my mind this is incorrect usage of the system. I believe a person should always be assigned a new position from PA using an action (we open the position field only from IT0000).

We have stopped the possibility to drag&drop a person in PPOME. But I want to stop the ability to edit HRP1001 from PO13. My thinking is to catch this in our instance of HRBAS00INFTY in method after input, by checking s_tcode and otype/sclass.

Two questions:
- Do you agree with my instinct that assigning a new position should happen from PA?

- Do you agree with my approach, or see other approaches?

Thanks in advance

/Kirsten

[jagan_gunja · Accepted solution]

Direct changes:  Sometimes Position re-assignment may not complete all related changes e.g., HRP1001 delimiting with setting as vacant if selected, and new one created, etc.  This could be due to various reasons.

In such cases, it would become necessary to do the changes in PO13, etc.

Using (a)badi, (b)ABAP enhancement, (c)LXPADU01 used by the user function exit in the maintenance module or (d)some such approach would be fine.

[Former Member · Accepted solution]

I think I will write this so that our support team will be able to change via PO13, but our end users not. As you state - it is exceptions to the rule that makes PO13 necessary. So in such cases I think it is OK to have our support team handle the case.  (We can distinguish this by usergroup).

Thanks for sharing thoughts on this issue.

/Kirsten

[jagan_gunja · Accepted solution]

It is also necessary and helps to discuss with users for a smooth change management.

Good to know a problem has been resolved.

[jagan_gunja]

Kirsten

You are very much right, a person should be assigned to a position from PA.  In fact should be with PA40 txn, because the change may involve change in ESG grpg or/and PSA grpg.  This means change in WSR, Pay scale area, etc, which means IT 7 & 8 should be in the pers action config. 

Sometimes even with PA40, users skip infotype screen.  This often leads to time eval or/and payroll falling over.  Such problems may be avoided with suitable user exits for validation in the maintenance modules.  

Also user guides for HR/Payroll admin staff must include standard operating procedures and must be followed. Even if user copies/creates IT 7 & 8 it would still be better.

Best of Luck!

Rgds, JG

[Former Member]

It puzzles me actually why SAP opens for direct changes in HRP1001 when integration is on. Any thoughts on my approach to stop this in a BaDI?

/Kirsten