on 09-20-2016 5:26 AM
I would like to know how Identity Management 8.0 handles returning employee scenarios.
Example is a contractor who used to work for the company and left last year once the contract was over. Now employer has decided to rehire the person as a permanent employee. Company policy insist on reusing the old user ID (SAP username) thus IDM should be able to reactivate the old user account and link it to the new PA.
Assumption is that IDM will read data from employee's old HR master data and if any user ID exists (under infotype 0105) it would then validate it with information provided within the new HR employee master data.
If the data matches with new HR master data then reactivate the user ID (SAP account) if not create a new account for employee.
Would be great if anyone can shed some light on this.
Many thanks,
Ali
Hi Ali,
This is a pretty standard scenario in IDM.
If corporate policy is to use the original value ID and that value exists in HCM, it should just be a matter of making the adjustments in HCM by changing employee status back to active, making whatever other changes need to be made and then save the record. The changes would then be picked up by IDM next time the LDAP extract is run and then processed by IDM.
So as long as the 105 information is still attached to the original account all should be fine.
I can't imagine that this would have changed from IDM 7.2 to IDM 8.0, but I am not 100% sure (99% sure though)
Is there something that makes you believe otherwise or are you just trying to make sure?
Thanks,
Matt
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Matt
Thanks for your response!
The issue (or difference) is that the corporate HR policy is to create a new employee record (i.e. new PA) when people return with a different employment types. Every time they change the employment type (Contractor, Permanent full time, Casual) employee will get a new employee record in HCM unless rehired with the same employment type (example: previous permanent employee rehired as permanent).
This makes it a bit complicated as the logic to find the relevalt employee record and extract 0105 data in HCM wouldn't be easy.
Regards
Ali
Hi Ali,
How is the use case set up?
HR date limits 0105 record for old pernr while terminating the employee? And then when rehire HR adds existing user id as 0105 record for new pernr?
If so, then details of old record will not be fetched (as it wouldn't be in delta table for extraction) and only new pernr (with existing userid) details will be sent to VDS - IDM.
IDM will then overwrite the values of attributes as per new pernr for the existing userid in database.
This is my understanding and I do not have a system to verify before posting. Please check for one user if it works as you expected.
Kind regards,
Jai
Hi Jai
0105 is not maintained by HR and they do not control the attributes as per our ICT policy.
Helpdesk was responsible to maintain HR employee record (infotype 0105) but moving forward we want IDM to update/amend 0105.
According to what we were told, IDM is capable of doing so but complexity is within the logic to find the old user ID (original account) which is linked to the withdrawn employee HR record for returning users (permanent to contractor and contrariwise).
If employee gets the same HR record (with same number) things would be easy and can be handled with a simple logic but not in the scenario i explained.
Unfortunately we don't have the system ready yet so i can't test anything. But would like to prepare for such scenarios.
Many thanks,
Ali
Hi Ali,
Yes, its complex. It depends on the script logic you write to calculate the userid for the pernr. If IDM will have to calculate/determine the 0105 record for a pernr, how will you dictate that it's the returning employee? It might just assume another user with same name is hired and calculate a new userid.
Maybe you can have a custom infotype that holds the value old pernr and include them in extract and use that value in script to check if user is rehired and calculate accordingly.
Kind regards,
Jai
Hi Jai
Thanks for your response!
Considering the facts, we might end up allocating new user ids to rehired employees or if possible create a new infotype to store old pernr as you suggested. But again we need to configure IDM to store the old pernr for employees who get terminated/leave in the new infotype.
Regards
Ali
User | Count |
---|---|
93 | |
10 | |
10 | |
9 | |
9 | |
7 | |
6 | |
5 | |
5 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.