Support The Site

Tuesday, October 27

Country Re-assignment / Multiple PERNRs




This has been a debated discussion for awhile. When a person goes on international transfer (aka: country reassignment), will they get a new PERNR? The simple answer is yes! SAP has a internal hard check that does not allow the same pernr to be in multiple different countries.
With SAP version 4.7  extension II and above, SAP deliver a functionality called Management of Global Employees, a subset of Concurrent Employment functionality. This in itself introduces a whole new concept of tracking employees (see my help document of MGE on this website). With the concept of PERSON ID, it is a central ID now link to multiple PERNRs (also known as personnel assignments).
When a person goes on international transfer / country re-assignment, it is required by SAP for you to get a new personnel assignment number (PERNR). With that, in your configuration of personnel action, there is a check box flag to signify the action type is a country re-assignment.
When you flip this flag, only purpose it serves is when you run an action via PA40, it ask you to choose an action to put one record in withdrawn status and another to put in active status. In blunt put, terminate one and hire other.
When using this method, be prepare to have 3 personnel actions setup to handle this. One to be trigger via the PA40 and two to be trigger within PA40 transaction.
In short, when a person goes on international transfer, you will be required by SAP to introduce to him/her a new PERNR. You can still track them as one individual through the PA side using PERSON ID or through the OM side using the central person concept.
Now it comes back to the population question. Can I "NOT" have SAP force me to create a new PERNR when a person goes on international transfer / country re-assignment. The answer is also yes. You can refer to SAP OSS Note 116007 for further detail. However, if you focus on the last phrase from SAP, this is NOT the recommended option and SAP will NOT support you if a problem does occur.

OM Audit Logging




Most people know you can activate infotype audit logging with Personnel Administration (PA) infotypes, such as infotype 0000 or 0008. The audit log is useful in a sense to see what data element changed by showing the old values and new values. But little people know there is also audit logging ability with Organizational Management (OM) infotypes as well. 

To setup the audit logging, you would have to configure / maintain the table T77CDOC_CUST or you can find it in the IMG at SPRO -> Personnel Management -> Organizational Management -> Basic Setting -> Activate Change Document. Once you configure what infotype and subtype you are interested in tracking, you could use the program RHCDOC_DISPLAY to access the audit log. Most company would level the program concept and create a custom "Z" program version of it with incorporating other elements important to them, such as the employee attached to a position or job object. 

Why don't you play around and see if you find it interesting?