Point to Point integration (P2P) has made the replication of master data from EC to ECPY system very easy.
My blog post here would provide the details necessary to replicate a custom MDF object in Employee Central (EC) to ECPY system using the standard P2P framework. SAP documentation and notes does provide you with a few hints on how to achieve this replication. I would cover the relevant SAP notes and documentation along with the missing details to achieve such a replication as part of my blog post below.
The replication process will require the involvement of ABAP consultant as a BADI has to be implemented wherein data has to be parsed.
The details about the above points are mentioned clearly in note 2597777 - How to add custom MDF entities in the SFAPI CompoundEmployee.
You can find the details about ECPY configuration in the standard ECPY help documentation. Employee Central Payroll using Point-to-Point Integration àOverview of Master Data integration->defining Customer Specific activitiesàMapping Options->ExtensibilityàAdvanced ExtensibilityàReplication of custom MDF objects
It is also possible to replicate a custom MDF object which has a parent-child relationship. You have to ensure that you include the parent object as part of the replication and not the child object.
After the necessary pre-requisites have been performed as above, we will have to implement a BADI to parse the data from the custom MDF object and then populate the necessary infotypes or tables in ECPY system.
The standard replication program (transaction HRSFEC_PTP_EE_REPL) performs the hard job of making a compound API call to EC system, does XML transformation and updates the XML provider class.
We just have to parse the custom MDF data that is already available as part of the XML provider class.
The note -2679852 - PTP - How to parse a custom MDF object for employee master data to ECP gives you a fair idea on how to do the parsing.
However, the sample classes CL_HRSFEC_EX_PROC_EE_2 or the BADI that it points to -HRSFEC_B_PROCESS_EMPLOYEE isn’t used in P2P framework.
In P2P framework, the BADI that is called is HRSFEC_B_CE_PROCESS_EMPLOYEE and the sample class that has to be referred is CL_HRSFEC_EX_PROC_EE_<1 or 2 or 3)_CE .
When you create an implementation, you can mention the implementation class to be created as a copy of one of the above classes.
On further analysis, we found that HRSFEC_B_PROCESS_EMPLOYEE is used in EC to on premise payroll system replication as it is called in the class CL_HRSFEC_EE_MDR_IMPL.
Whereas HRSFEC_B_CE_PROCESS_EMPLOYEE is called in the P2P framework as part of the class CL_HRSFEC_EE_MDR_MAIN
Coming back to implementing the logic to parse the custom MDF data, all the entities are referred as an child to the Employment Id. You just have to iterate through every child entities-> identify the custom MDF entity and then query through all the fields of the custom MDF object. The below screenshot are references from the sample classes.
The information obtained from custom MDF object can be used to update a standard/custom infotype in the ECPY system.
The sample classes provide a good idea on how the child entities have to be queried from the XML provider classes.
The P2P framework provides you with some useful static methods like cl_hrsfec_service_lib=>update_mass_pnnnn_data which can be used to update the infotype as well.
For one of the customer , we had a requirement wherein a loan is requested by an employee and then the same amount is recovered in equal installments. For a few cases, interest also has to levied on the loan along with preclosure, changing of installment amounts ,etc has to be provided.
EC does provide with Advances feature , but it is very limited and cannot handle all the requirements above.
The loan functionality (IT0045) in ECPY system will cater to all the requirements and hence we decided to leverage on IT0045 .
We created a custom MDF object in EC which would be used by the employee to raise request for a loan. It would contain fields like eligible amount, amount requested, installment amount,etc.,
Once the employee raises the request, it would be routed to through various levels of approval.
Once approved, the standard replication program would get the details of the custom MDF object and create IT0045 in ECPY system.
In the BADI HRSFEC_B_CE_PROCESS_EMPLOYEE implementation, we wrote the code to parse the data from custom MDF object by taking the sample class code as a reference. This data was used to populate the necessary structure of IT0045 and then the logic for updating IT0045 was called.
The custom MDF object we used had parent-child association as well. This will just introduce a nested child entity in the XMl provider. Once you are able to parse one of the child object, parsing a nested child object wont be an issue.
Hint: Updating the Loans infotype is a little tricky because IT0078 also has to be updated. So kindly note that SET_P0078_DATA of CL_HRPA_IT0045_CONTAINER has to be called so that IT0078 is also updated successfully.
The IT0045 record that has been created can be exposed as mashup screen in the employee profile accessible by the administrator. Other subsequent changes to the existing loan record can be done by the admin directly via the mashup screen by the administrator.
With the above information and with help of a ABAP consultant, it would be possible to replicate any custom MDF object from EC to ECPY .
As major goal of cloud implementation is to avoid major development in EPCY system, it is upto the consultant to take a call on proceeding further with such replication as it involved certain development effort.
Kindly feel free to post your views or feedback on the approach above.
My blog post here would provide the details necessary to replicate a custom MDF object in Employee Central (EC) to ECPY system using the standard P2P framework. SAP documentation and notes does provide you with a few hints on how to achieve this replication. I would cover the relevant SAP notes and documentation along with the missing details to achieve such a replication as part of my blog post below.
The replication process will require the involvement of ABAP consultant as a BADI has to be implemented wherein data has to be parsed.
Pre-Requisites :
- Ensure that the custom MDF that is created in EC has the externalCode mentioned as ‘User’ .
- The API Visibility of the custom MDF object is set to ‘Editable’
- Include the MDF object in ‘Compound Employee API Object Types’ via Manage Data option
- In ECPY system , you will have to include the custom MDF object as a Segment in the customizing node for Configuring Compound Employee API query.
The details about the above points are mentioned clearly in note 2597777 - How to add custom MDF entities in the SFAPI CompoundEmployee.
You can find the details about ECPY configuration in the standard ECPY help documentation. Employee Central Payroll using Point-to-Point Integration àOverview of Master Data integration->defining Customer Specific activitiesàMapping Options->ExtensibilityàAdvanced ExtensibilityàReplication of custom MDF objects
It is also possible to replicate a custom MDF object which has a parent-child relationship. You have to ensure that you include the parent object as part of the replication and not the child object.
Parsing CUSTOM MDF data in ECPY
After the necessary pre-requisites have been performed as above, we will have to implement a BADI to parse the data from the custom MDF object and then populate the necessary infotypes or tables in ECPY system.
The standard replication program (transaction HRSFEC_PTP_EE_REPL) performs the hard job of making a compound API call to EC system, does XML transformation and updates the XML provider class.
We just have to parse the custom MDF data that is already available as part of the XML provider class.
The note -2679852 - PTP - How to parse a custom MDF object for employee master data to ECP gives you a fair idea on how to do the parsing.
However, the sample classes CL_HRSFEC_EX_PROC_EE_2 or the BADI that it points to -HRSFEC_B_PROCESS_EMPLOYEE isn’t used in P2P framework.
In P2P framework, the BADI that is called is HRSFEC_B_CE_PROCESS_EMPLOYEE and the sample class that has to be referred is CL_HRSFEC_EX_PROC_EE_<1 or 2 or 3)_CE .
When you create an implementation, you can mention the implementation class to be created as a copy of one of the above classes.
On further analysis, we found that HRSFEC_B_PROCESS_EMPLOYEE is used in EC to on premise payroll system replication as it is called in the class CL_HRSFEC_EE_MDR_IMPL.
Whereas HRSFEC_B_CE_PROCESS_EMPLOYEE is called in the P2P framework as part of the class CL_HRSFEC_EE_MDR_MAIN
Coming back to implementing the logic to parse the custom MDF data, all the entities are referred as an child to the Employment Id. You just have to iterate through every child entities-> identify the custom MDF entity and then query through all the fields of the custom MDF object. The below screenshot are references from the sample classes.
The information obtained from custom MDF object can be used to update a standard/custom infotype in the ECPY system.
The sample classes provide a good idea on how the child entities have to be queried from the XML provider classes.
The P2P framework provides you with some useful static methods like cl_hrsfec_service_lib=>update_mass_pnnnn_data which can be used to update the infotype as well.
Use Case
For one of the customer , we had a requirement wherein a loan is requested by an employee and then the same amount is recovered in equal installments. For a few cases, interest also has to levied on the loan along with preclosure, changing of installment amounts ,etc has to be provided.
EC does provide with Advances feature , but it is very limited and cannot handle all the requirements above.
The loan functionality (IT0045) in ECPY system will cater to all the requirements and hence we decided to leverage on IT0045 .
We created a custom MDF object in EC which would be used by the employee to raise request for a loan. It would contain fields like eligible amount, amount requested, installment amount,etc.,
Once the employee raises the request, it would be routed to through various levels of approval.
Once approved, the standard replication program would get the details of the custom MDF object and create IT0045 in ECPY system.
In the BADI HRSFEC_B_CE_PROCESS_EMPLOYEE implementation, we wrote the code to parse the data from custom MDF object by taking the sample class code as a reference. This data was used to populate the necessary structure of IT0045 and then the logic for updating IT0045 was called.
The custom MDF object we used had parent-child association as well. This will just introduce a nested child entity in the XMl provider. Once you are able to parse one of the child object, parsing a nested child object wont be an issue.
Hint: Updating the Loans infotype is a little tricky because IT0078 also has to be updated. So kindly note that SET_P0078_DATA of CL_HRPA_IT0045_CONTAINER has to be called so that IT0078 is also updated successfully.
The IT0045 record that has been created can be exposed as mashup screen in the employee profile accessible by the administrator. Other subsequent changes to the existing loan record can be done by the admin directly via the mashup screen by the administrator.
With the above information and with help of a ABAP consultant, it would be possible to replicate any custom MDF object from EC to ECPY .
As major goal of cloud implementation is to avoid major development in EPCY system, it is upto the consultant to take a call on proceeding further with such replication as it involved certain development effort.
Kindly feel free to post your views or feedback on the approach above.
- SAP Managed Tags:
13 Comments
