Simplifying Data Migration and Integration of Employee Address Data from and to SAP ERP On Premise System During Employee Central Success Factors Implementation
1. Business Scenario
A global customer is implementing SAP Success Factors Employee Central, using a core hybrid HCM deployment option where Employee Central is used as the system of record holding the employee data and reporting lines of all employees, but existing HR processes such as Payroll, Time Management, or custom HR processes still run in an SAP ERP HCM system landscape. As a part of it, you are migrating employee data from ERP HCM system to EC before go live and integrating employee data from EC to ERP HCM system using Business integration builder(BIB).
2. System Landscape
3. System Pre-requisites
SAP ERP HCM
|For this component …||
You are on this software component version…
|SAP NetWeaver||SAP_BASIS 700 SP18 or a higher version/SP|
|SAP ERP HCM||SAP_APPL 600 SP15 or a higher version/SP|
Integration add-on for SAP ERP HCM and SAP SuccessFactors Employee Central
PA_SE_IN 100 SP19
HR ERP System is set up with Employee Master Data and Organizational Assignment Replication.
Middleware: SAP Cloud Integration Platform is set up.
4. Problem Statement
Employee address data in standard SAP is maintained in country specific screens/fields and this data needs to be migrated to Success Factors address portlet that is part of CSF data model and integrated back to ERP. There are overall 120 countries address which are supported in Standard SAP and Success Factors System. Hence, the migration and integration become quite complex to maintain and troubleshoot with all the secondary mapping required in the address template of the BIB configuration. In addition to this, employee can also maintain foreign address as his/her address which is other than the country of employment, complicating the design of replication interface further. As per the standard design of replication interface, if the secondary mapping does not exist for all the countries in scope for address of employee, replication fails and rejects any other data changes relating to this employee, say for example, working hours change. This document mainly focusses on the integration part to explain how BIB configuration and standard decoupled framework can be effectively used for maintenance of foreign address of the employee.
5. Proposed Solution
- Implement a Global data model for address portlet in Employee Central in such a way that each field in Address portlet corresponds to a field in your P structure -P0006 of address infotype (0006) in HCM ERP system.
- Leverage the feature CSSCR provided in the decoupled infotype framework to determine the country specific screen (ITBLD) based on the country of address (LAND1) To be able to use the feature CSSCR, make sure all the fields have “Linking field” setting to be maintained as LAND1 in the field mapping.
6. EC to ERP field mapping based on customized global data model for address portlet.
|EC Technical Field||EC Label||SAP Technical Field (P0006)||SAP Label|
|address1||Care of||NAME2||Care of|
|address2||Property number and name||STRAS||Street and House No|
|address4||Street number and name||LOCAT||2nd address line|
|address5||Extra address Line1||ADR03||Street 2|
|address6||Extra address Line2||ADR04||Street 3|
|address11||Siruta code||RCTVC||Siruta Code|
|address12||House number||HSNMR||House No|
|address13||Egypt – Street name||STRAS||Street and House No|
|address14||Egypt – Flat||STRAS||Street and House No|
|address15||Street abbreviation||STRDS||Street abbreviation|
|zip-code||Zip Code||PSTLZ||Postal code / city|
|Custom-string1||Orientation Number||POSTA||Orientation Number|
7.Steps to implement the solution:
7.1 EC side
- Change the CSF data model for address to a global data model based on your above based on above suggested design template design and upload the new global data model (XML) through provisioning.
- Enable fields relevant for specific countries based on your current SAP system design. (Most countries don’t use county field, disable the unused fields on manage business configuration)
- Define which fields need to picklist enabled based on your SAP system and make the field picklist enabled in EC.
7.2 Picklist Clean up
- Align the picklists by creating/ editing picklists based on your standard SAP system, so that you don’t have challenges while migrating the data. Remove the picklist values that are not used in SAP system, as it will cause errors in replication if those values are selected.
- As a recommended tip, always use external code of the picklist value same as the SAP value stored at the data base level to avoid any value mapping in BIB. Though there are challenges with Picklist Management wherein preceding zeroes cannot be retained on EC side. Alternative is to leverage MDF picklist as per new SF release Q1-2019, picklists are editable.
- As highlighted in row 25, align EC external code based on SAP value to make sure all the picklist values are aligned.
7.3 BIB Configuration
- Under the node for Personnel Management, Integration with Success Factors Employee Central select Business Integration Builder
- Create a new EC entity by providing the same details as for standard EC entity for address. To make sure we are not affecting the existing mapping if any.
- Import Meta data for the EC entity.
- Complete the field mapping in the ERP entity.
- Make sure you enable linking field as LAND1 in all the field’s mapping. This is a mandatory configuration step to use LAND1 as the linking field as highlighted above as well. Without this setting, system will not be able to read feature CSSCR and determine the screen in ERP.
- As you can see, no secondary mapping is needed, and you can leverage cloning for subtypes of addresses.
8. How foreign address works?
- In standard SAP system allows employee to maintain foreign address
- Even if employee belongs to Egypt, you can maintain foreign address for that employee, say Italy, Italy screen pops up with relevant fields as required.
8.1 CSSCR Feature
- To support this functionality through replication as well, use feature CSSCR which is called in the decoupled framework classes for address.
- Maintain this feature taking into consideration, all the existing countries and respective screens being used in the ECC system. Please note that this feature is not used on standard PA30 screen which calls P0006 feature and hence, you need to customize this feature as part of your configuration for employee replication.
- Once this is maintained. You can maintain Foreign address in EC and it gets replicated to SAP as mentioned in the below example.
9.Example for replication
- Luxembourg employee has home address in Italy. Employee replication supports it.
- Address is replicated.
To maximize the benefit of BIB framework and decoupled infotype framework while implementing SF to ERP integration, standardizing the design of address portlet on the success factors EC has proven to be quite helpful. On contrary to the recommended approach of using secondary mapping in BIB, this approach has significantly simplified the mapping during integration and reduces the maintenance effort after go-live. Also, as we have completely eliminated secondary mapping, we can use cloning to map different subtypes using this approach. In addition, this simplifies the migration of employee data to Employee central before Go-live. Overall this approach has been helpful in reducing the errors during replication and supports foreign address replication as well.
PS: Despite all the doubts in moving the data model from CSF to global data model for address portlet, we were pretty unsure how things would turn out at Success Factors end, I would say it was worth the risk and it turned out be a straight forward solution to implement. I would like to thank Tushar Shinde who has been the main contributor in the solutioning of this design and also for reviewing this document. We hope this will be of some value add in your integration design approach during your project implementation.