Last month Bill Cradick provided a live demo session(in ECPY learning Rooms) on the Employee Central payroll PTP topics which was very informative. During the session, there was a question raised about how to handle PTP replication for non-localized countries. There is a thread still open in the employee Central Payroll learning room where details are being shared and discussed with Mr. Joaquin Muela.
I would be covering the details on one of the options available to handle non localized country replication in Employee Central Payroll(ECPY).
What is the issue?
As you would all know, Employee Central provides localization for 98 countries whereas ECPY localization is available for 45 countries. When a requirement comes for implementing payroll for a non-localized country in ECPY, it’s a common practice to use the international version (country version 99) in ECPY system.
Lets take an example of implementing payroll for the country Peru (PE ). As Peru localization is available in EC, an employee hired under Peruvian entity would have country code as PE.
IN ECPY, as localization isn't available for Peru, the enterprise structure would be designed with 99(international version) as the country code.
When you run the standard replication program, the replication process fails as the system cannot map a ‘PE’ country employee from EC to ‘99’ country in ECPY.
PTP framework
In the PTP framework, there are country specific replication classes available which are mapped in the table ‘HRSFEC_CNTRY’. This table is delivered by SAP and shouldn’t be altered. SAP has provided a customer table ‘HRSFEC_CNTRY_CC’ wherein customer specific entries can be maintained.
Determination of the replication classes happen in the class ‘CL_HRSFEC_EE_MDR_BNDL_PROC’ where the Molga of the pernr is identified and the relevant classes is obtained from HRSFEC_CNTRY/HRSFEC_CNTRY_CC. If a country doesn’t exist , then ’CL_HRSFEC_EE_MDR_MAIN’ is taken as the replication class by default.
Also note that ’CL_HRSFEC_EE_MDR_MAIN’ is the superclass for all the country specific replication classes.
’CL_HRSFEC_EE_MDR_MAIN’ has a logic in the method ‘CHECK_MOLGA_OF_PERNR’ which stops the replication if the incoming country from EC (PE in our example) is different than the country (99) assigned in ECPY.
WorkAround:
To resolve the issue, a custom class can be created with the superclass mentioned as ‘CL_HRSFEC_EE_MDR_MAIN’ so that it inherits all the methods of the superclass.
The method ‘CHECK_MOLGA_OF_PERNR’ in the custom class can be redefined so that the existing check can be suppressed and the replication logic can be allowed to continue.
You can also redefine other methods or include your own methods in case of any country specific logics required .For example, replicating national id information/bank details specific to Peru,etc., form EC to ECPY
The custom class has to be entered in the table HRSFEC_CNTRY_CC against country PERU and replication type as ‘ECEMD’ (Employee Master Data Replication).
With the above changes, the standard replication program would pick up the custom replication class and proceed with the replication logic without any issue.
There is another option available in ECPY to handle non localized countries wherein a new country version called PE can be activated along with the PE payroll cluster. But in such a case, we need to spend some effort in developing payroll programs where the new PE payroll cluster is accessed.
Kindly feel free to share your inputs on the above options and special thanks to Joaquin Mela and Bill Cradick .
