In this blog, I would like to share my experience with the handling of country specific infotypes in global HCM Process & Forms. The customer has got a global SAP HCM instance and the HCM Process & Forms were used for handling all MSS related transactions across the globe.
One of the most widely used forms was for new hire and it was designed for managers to seamlessly complete the new hire process of their employees. This was form used globally and on completion of this form it automatically updates infotype 0, 1, 2, 7, 8, 14, 41 etc.
The biggest challenge we faced with this form was the handling of Personal Data - Infotype 2 (which is a country specific infotype) globally. Each country has it’s own set of fields in infotype 2 which makes it difficult to use a generic screen structure in design time for that infotype. Original plan was to automate infotype 2 only for US (which is the largest market) and for rest of the world, form will be routed to HR admins to manually update the infotype 2 data for that country. Form was built based on this design and the screen structure used for infotype 2 in the design time was HCMT_BSP_PA_US_R0002. This enables auto-updation of US, wherein rest of the world was handled manually by the HR admins.
This has worked fine for few months but as the number of transactions increased over time, admins outside the US started complaining about their work load. As a result a new strategy had to be devised in order to automate the creation of infotype 2 for rest of the world.
Two options were mainly considered:
1. Create individual forms for each country and have the manager hire employee to a particular country using the form designed for that country.
2. Use the international screen structure HCMT_BSP_PA_XX_R0002 to update the generic fields of infotype 2 and then use some custom methodology to update the country specific fields during runtime.
There were some problems with the first option, the most significant being:
1. Multiple forms to be developed and maintained. Huge development and on-going maintenance cost.
2. Sometimes manager will dynamically change the hiring country of the employee inside the form by changing the personnel area. When that happens, current form needs to be closed and a new form needs to be launched for the new country. It’s technically challenging to handle that kind of navigation without breaking the current functionality.
After carefully studying the pros and cons, it was decided to go with option 2. The approach we followed is as explained below:
1. The international screen structure HCMT_BSP_PA_XX_R0002 was used to map all the generic fields (fields which are common and shared by all countries) of infotype 2.
2. Five extension fields were added to the form scenario. These 5 fields act as dummy place holders for every country.
3. Based on the country, the labels of these 5 fields are changed dynamically in the form to make these fields appear as county specific fields to the manager.
4. The dummy fields are mapped to the actual database fields for every country in a custom table.
5. A custom task is created and is called as the last step of the workflow (after the save_data step).
6. Import the 5 extension fields from the workflow container into the custom task.
7. Inside the method (linked to the custom task), read the mapping table and do a mapping of the extension fields with the actual database fields.
8. Finally modify the existing infotype 2 record of the employee with the values in country specific fields.
Once this new approach was deployed, managers across globe were able to use one single form for new hire but could still update the entire infotype 2 data of the employee (including country-specific fields) in one shot. This has also significantly reduced the workload on HR admins globally.
- SAP Managed Tags:
1 Comment
| User | Count |
|---|---|
| 2 | |
| 2 | |
| 2 | |
| 2 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 |
