Introduction:
Most often we come across requirement to update employee master data, with synchronously update / modify multiple info type in one transaction.
Intent of given document to brief about approach to update multiple info type by using standard functional module HR_INFOTYPE_OPERATION.
Overview:
To explain more, we’ll take following illustrating example:
Business needs to created new records automatically in info type 033 as and when records got changed or created for Organizational Assignment (info type 0001).
Thus during updating of info type 0001, simultaneously info type 033 three sub type new records should be created in background.
Trouble Area:
During such type of requirement we need to give leverage on Dynamic Action i.e. SPRO->Personnel Management->Personnel Administration->Customizing Procedures->Dynamic Actions. But there is lot of challenges with Dynamic action esp. when we need to Create/Update / Delete record with certain validations or substitute some values where integration with legacy system involved.
From ABAP side we do face lot of challenges while using HR_INFOTYPE_OPERATION, primary one will be employee locking issue along with inconsistent commit transaction as internally given functional module called PA40 through means of BDC - Batch Data Communication.
Addition of info group will be another approach but it will involve manual intervention. Thus most of the user will discard that approach.
Implementation:
Step 1: As a first step, we’ll create / change in employee master data for Organizational Assignment i.e. 0001 Info Type through transaction code PA40.
Step 2: With “SAVE” action of the above, Update task will be triggered .We’ll implement standard BADI HRPAD00INFTY, Method IN_UPDATE, which will be called during update task. As required, we’ll lock employee to create other info type data synchronously in background.
Afterwards,we’ll call our custom functional module ZHR_FM_UPDATE. So, all required business logic will be encapsulated in custom
functional module ZHR_FM_UPDATE.All import / export parameters can be custom adjusted as per requirement.
Step 3: In this functional module ZHR_FM_UPDATE, we’ll create new LUW, with unique identifier w.r.t Info type + Date + Time for background task.
Step 4: As we need to trigger HR_INFOTYPE_OPERATION in new background task, we must to have RFC enable functional module. But
HR_INFOTYPE_OPERATION is not RFC enabled thus we need to create wrapper for the same.
Thus we’ll create new wrapper functional module ZHR_FM_UPDATE_LUW, containing below given flow logic to create info type data for 33 i.e. Statistics records will be created.
Good part we can have re-usability to implement any custom logic in case if needed before updating of records . :smile:
As needed, we can create multiple LUW (Task) to update different info type one after another.
Step 5: Last but not least, employee needs to be unlock through BAPI_EMPLOYEE_DEUEUE and HR_PSBUFFER_INITIALIZE. Afterwards execution will be back to update info type 001 – Org. Assignment records. Thus in one transaction, multiple records created for given employee.
Hope document will be helpful to cater synchronous employee details update.
