SAP SuccessFactors EC-ECP Employee Data Replications – Part III
In this blog post I shall focus on the first step in the EC-ECP Employee Master Data Replication process. Please refer Part I where I introduce a high-level process flow for this replication and Part II where I share pre-requisites and general tips. For your quick reference, following is the process flow diagram I shared in Part I:
Focus Area: Step 1: ECP Replication Program makes a call to Compound API in EC for employee data.
Please refer the sub-bullet 1 under Business Scenario in consideration section in Part I. While EC (which is system of record for HR master data) shall be going live for the entire employee population of the subject company as on a single date, ECP shall go live by payroll area which might fall on different dates as per their pay period alignments.
Tip 1: Never ever plan to have EC go live by payroll area. Else, you shall end up breaking the org structure.
One of the critical configurations related to Step 1 is the Compound Employee API Query configuration.
Primary Table: T77SFEC_PTP_CONF
Secondary/Child Table: T77SFEC_PTP_SEGM
These two tables provide input to our replication program as to how to formulate the query for the EC Compound API call.
The first table (T77SFEC_PTP_CONF) has following fields:
- Config ID: I suggest you use following naming convention <Company Code>_<Payroll Area>. Thus, you shall have one config entry per pay area. This is because you will potentially have different go live for each pay area. Instead of Company Code as prefix (if there are multiple company codes for a company) you may come up with a unique code to identify each company in your landscape. Say, 1, 2, etc. or A, B, etc.
- Config. name: A descriptive name to identify this configuration.
- Company: List the applicable company codes for this configuration with comma as separator. In a multi-tenant environment, this will be critical entry.
- Country: E.g., USA for United States, CAN for Canada. These values are determined by EC picklist values for country. Avoid combining multiple countries in one configuration.
- Employee Class: I didn’t have to use this field in my project implementation.
- Comp. Pay Group: This shall be the pay area, assuming EC uses the same codes.
- Target System: Not of use. Can be kept blank.
- Full Transmission Start Date: FTSD for short. This is when ECP is going live for the concerned pay area.
- Use as From Date: I had it unchecked in my project implementation; EC had fresh employee records starting as of ECP FTSD for the critical portlets such as, job information, compensation information, etc.
- Mult. Actions: I had it checked; thus accepting more than one action on a given date (which will go into Infotype 302).
- Ext. Cost Center: I had it checked.
Here’s an example configuration entry for the pay area A1 of Company ABC LLC from our Business Scenario (refer Part I):
Tip 2: If you recollect in the earlier post, I had mentioned that you will need a custom program to directly update Full Transmission Start Date (FTSD) in the config table T77SFEC_PTP_CONF. The reason behind this is that, with multiple rounds of testing in lower environments (Dev and QA), where-in you might have different FTSDs which align with the most preferred pay periods for your testing, you will end up updating FTSD in config transports multiple times over until you have the FTSD for Production cutover in the final transport. To avoid having to do multiple transports, you can build a custom program which takes Config ID and FTSD as input, and directly updates the config table T77SFEC_PTP_CONF record’s FTSD field value. You can then have this program execution to “fix” the FTSD as a task in your cutover plan prior to switching on the replications.
The second table (T77SFEC_PTP_SEGM) lists out, for each Config ID in the primary table, the portlets whose data is to be fetched from EC. Example portlets that you may consider (and there could be more, especially if you happen to have custom or country-specific EC portlets to replicate):
Next, let’s talk about the Last Run Table HRSFEC_PTP_LMOD. This, as expected, is a transactional table. You might want to create a parameter transaction on top of SM30 to maintain this table, unless your SAP security team lets you access SM30 directly. This table will have one entry per Config ID defined in T77SFEC_PTP_CONF and the timestamp in format YYYY-MM-DDTHH:MM:SSZ. When the replication program executes, it queries EC using the last run date in this table to specify since when it wants the data changes to be selected. You will have to reset entry in this table if at any time you want to do a full refresh.
Tip 3: When the replication program executes the first time, there will obviously be no entry in this table for the concerned config id. I’ve noticed that in such a situation, when the replication program doesn’t query with a last run date, EC’s Compound Employee API returns records since the last EC conversion data load. Now, if your EC team had performed multiple conversion data loads before EC-ECP Replications are turned ON, you might miss replicating some earlier loaded employee data. Thus, it would be advisable to enter an old date (such as 1 month before your EC go live date) in the Last Run Table HRSFEC_PTP_LMOD before turning ON the EC-ECP Replications.
Now, let’s talk about selection screen inputs of the employee replication program RP_HRSFEC_PTP_EE_REPLICATION (transaction code: HRSFEC_PTP_EE_REPL).
- Configuration ID: It’s the same Config ID that you entered in table T77SFEC_PTP_CONF. It’s a mandatory input field. This means, you can replicate employee population corresponding to only one Config ID at a time.
- External Employee ID: This is an optional field. You shall enter a value only if you want to replicate ad hoc for a single employee due to some error corrections. The External Employee ID (aka “Person ID External”) in most instances will be same as PERNR. However, it can be different when you have an individual who has multiple PERNRs (that is, someone who has worked for multiple companies in your multi-tenant landscape.) For such cases, the first PERNR the employee had in the system will be the External Employee ID and all remaining PERNRs will be linked to the same External Employee ID. In a way, this is SuccessFactors EC equivalent of Central Person Object in ECC. For more information on different IDs in SuccessFactors EC, refer SAP KBA 2493579.
Tip 4: When you search for employees in SuccessFactors EC Search Toolbar, you typically search using peoples’ names. However, if you search by PERNR, do remember that it’s not the PERNR but the External Employee ID or Person ID External that you are looking up. This is critical to know when you have employees with more than one PERNR. The same will happen in ECP, when you are browsing the SLG1 Application Log. More of that in a later blog post when I discuss about SLG1.
Tip 5: In production, you shall run this replication program as a background job with a set frequency (say, hourly, and at a time different from the OM replication job). Since the program validates that there are no simultaneous runs, it would be advisable to have all executions of this program (one for each Config ID) as individual steps in the same background job to avoid any overlap runs.
This covers what all I had planned to share about Step 1. The knowledge matter is a bit intertwined (at least in my head), and I might touch upon some of the above items again in subsequent blog posts. Until then, shubhamastu.
Thanks for sharing nice and great information about PTP. I have a doubt how do we activate Multiple actions which business service or any note available. Currently we have issues with EC and ECP when an employee has multiple actions and unfortunately we are not using IT302. I will try to use the benefit of this option.
Hi Ravi, Multiple actions should work out of the box. Of course, you can't have multiple actions on IT 0 record on a single day. Those shall go into IT 302. As long as you have your SPRO config in place, and checked the "Mult. Actions" checkbox in config table T77SFEC_PTP_CONF it should work seamlessly. Do share your experience after you followed these steps.
Hi .. I have few employees where in EC need to be in One company code and in ECP will be in different company code because they all are deputees... In that case how can we handle the replication
I assume you have a custom field in an EC Portlet, say Job Information portlet, where you store the correct legal entity (company code) for the PERNR, which is different from the contents of legal entity standard field. In the Replication BADI for Infotype 1 (HRSFEC_B_CE_CHANGE_IT0001), your developer should update the company code that the standard replication framework populated (which shall be based on the standard legal entity field), to the custom legal entity field value. They should also remember to append BUKRS in the changed fields in the method IF_HRSFEC_CE_CHANGE_IT0001~DEFINE_FIELDS_TO_BE_CHANGED of the same BADI. Moreover, do note that the Employee Key Mapping Table shall carry the company code value on the standard legal entity field and not your custom legal entity field value.
Thanks for the details.
We are implementing Ec to ECp via PTP and facing below error 'max length 1 of target field exceeded.source field Job_informarion employee class AC_IN'.
Employee class in EC is AC_IN and in ECP it is mapping with employee group A via PTP mapping tables.
Can you please explain how to overcome this issue.
I can only guess your system configurations unless you can supply more details. I think you have chosen "Mapping via customer table or identical mapping" as the option for EMPLOYEE_CLASS data type in table T77SFEC_CVPROPC, and there is a missing mapping for an EC code, resulting in a mismatch in lengths of source value and destination field. Do check what is the errored employee's Employee Class in EC and whether you have it correctly mapped in ECP. You will have to look at the external code in EC picklist and not the displayed value. If it's a fresh implementation, do check with your EC team if they can use the same value in both EC and ECP, so "identical mapping" would then work without any need for mappings.
Thanks for your Feedback. Yes I have selected Mapping mode as Mapping via customer table or identical mapping" in table T77SFEC_CVPROPC. As per PTP document it suppose to be Mapping via customer table. However if I maintain that , then Employee class it self is not considering even though we maintained external code correctly. As per my understanding these two tables T77SFEC_CVPROPC and T77SFEC_CVMAPC are using for mapping. Is there any other table which we need to consider while doing PTP mapping. Please advise.
Sorry for the delay in response. Not sure if you resolve the issue. If not, put a breakpoint where the system generates the error. You should be able to make out why the mapping isn't working. There are no other tables in this process.
~ Rajendra Prabhu.
Thank you Rajendra.
The issue resolved.
Thanks for sharing some good insights on PTP. I have a quick question. Do you know the SAP standard table name where all the field mapping is done based on the Data type in Employee central where it is displayed under "Display Code Value Mapping as Delivered by SAP".
SAP provides the config table T77SFEC_CVPROPS with SAP's default settings. You are not supposed to modify any of it's contents. You should instead configure table T77SFEC_CVPROPC and the corresponding value mapping table T77SFEC_CVMAPC.
Does that answer your question?
~ Rajendra Prabhu.
Yes that answers my question. I was just curios to know if the default settings have any backend table. Also do you know why there is a restriction to select only handful of infotypes like 0001, 0007 and 0008 in the table/view V_HRSFEC_EXTMAP. If we need to extend any other Infotype fields for example 0016 then that is not possible via this extension.
Any alternative way to do it.