Skip to Content
Technical Articles
Author's profile photo Rajendra Prabhu

SAP SuccessFactors EC-ECP Employee Data Replications – Part V

So far I covered overall process flow (Part I), pre-requisites (Part II), step 1 (Part III) and steps 2 to 4 (Part IV). Now, lets discuss more on the configuration and customization aspects in this and upcoming blog posts, before we eventually come to step 5. I shall try to cover each element in as much detail as I can, based on what I have experienced working in a live multi-tenant implementation environment. I shall restrict to only those which I’ve actively worked upon, and there could be more which might be relevant for your specific case. Moreover, SAP might finetune some of these in the future, and hence, you should refer to SAP’s latest documentation or support notes to validate if what I mention here is still applicable.

As earlier, re-sharing the overall process flow from Part I for easy reference.


PTP Process Flow Diagram


Focus Area: PERNR Mapping Table: HRSFEC_D_EEKEYMP

This table is to map the different person identification elements in EC to PERNR in ECP. Do pause here, and check the SAP KBA 2493579 to learn about these EC elements.

Fields of the PERNR Mapping Table:

  1. Employee ID: From EC. E.g., 00ABE6F19F134430B8352D280080A641
  2. Employment ID: From EC. E.g., 6130
  3. Work Agreement ID: Usually hire or termination date in YYYYMMDD format. E.g., 20200608
  4. Personnel Number: PERNR. E.g., 1001234.
  5. Company Code: BUKRS. E.g., 1000.
  6. External Employee ID: From EC. E.g., 1001234. (As mentioned in earlier blog post, this shall likely be same as PERNR, unless you have a cross-company employee.)
  7. User ID: From EC. E.g., 1001234. Usually, this is the EC field you shall map to PERNR in ECP.
  8. Internal Person ID of an Employee: PERSON_ID_INTERNAL field in EC. E.g., 6102

If the replication program while processing an employee’s data received in the EC query response is unable to locate an entry in this table, it considers that this as a fresh hire and shall make an entry for it in the table at the end of a successful replication.

Tip 1: As part of conversions load, if you had migrated historical infotype records from legacy on-premise HCM system into EC Payroll using an HR Data Cloning Utility (such as, NEXUS Suite by TIK as was done in my project), you would have to also load the key mapping table for all of these legacy PERNRs before you switch on the replications. If you don’t, employee replication will result in these errors: Person already hired (PG 002) or External PERNR &1 is already hired. Please check longtext. (HRSFEC_SERVICES 285).

To upload data to this PERNR Mapping Table as part of conversion load, SAP has provided utility program: RP_HRSFEC_UPLOAD_EEKEY_MAPPING. It accepts a .csv file (or with any other column separator character, such as pipe) and with column order sequence matching the field structure mentioned above, except for “1. Employee ID” and “8. Internal Person ID of an Employee”, which for some unfathomable reason are flipped in the acceptable input file format.

Tip 2: You may request your EC team to build a report in EC, or have CPI team build an integration iFlow to query EC and generate the above data as a file, with an additional Payroll Area column. Payroll Area addition would come handy, as ECP shall go live by pay area and you would want to limit your PERNR Mapping Table uploads to only the go-live population. You may enter any date for Work Agreement ID for your initial load (e.g., 19000101) without having to determine the true hire or termination date.


Focus Area: PERNR-specific Full Transmission Start Date: HRSFEC_PN_FTSD

By default, employee data is replicated from EC to ECP onwards from FTSD of the Config ID under which the employee belongs to. It’s configured in table T77SFEC_PTP_CONF which we covered in Part III. Since Config ID is by payroll area, you can quickly make out the default FTSD for the employee. In our example, for an employee who is currently on A1 payroll area, her FTSD would be 6/10/2020.

Now there are situations when you want to deviate from this date:

  1. This PERNR was in withdrawn status at go live, aka “converted term”, and was loaded with minimal information into EC. You don’t want this data to land into ECP and overwrite good infotype data that you migrated from the legacy on-premise HCM system. The “converted term” would then be loaded under pay area XX (non-pay) in EC, which we don’t replicate into ECP.

    When this PERNR is rehired in EC sometime in the future, you want the data replication to start from this rehire date onwards. That’s when you shall maintain table HRSFEC_PN_FTSD for this PERNR with the Rehire Date as the PERNR-specific FTSD. You can optionally (and preferable for business user) automate this by implementing the BADI HRSFEC_B_CE_DECIDE_HIRE_REHIRE (available under Enhancement Spot HRSFEC_CE_MASTER_DATA_REPL) to plug the PERNR-specific FTSD record as on initial rehire events of “converted terms”.


    * LOGIC:
    * 1. Processing is only for rehire scenario.
    * 2. Confirm that the employee is first time rehire of a converted term.
    * 3. Set the PERNR's FTSD as the job information start date.
        DATA: ls_ptp_config TYPE zcl_hrsfec_ce_itmap_helper=>ts_ptp_config.
        DATA: lv_endda TYPE sy-datum.
        DATA: lt_pnnnn TYPE hrpay99_prelp_table,
              lt_prelp TYPE prelp_tab.
        DATA: lx_root  TYPE REF TO cx_hrsfec_root,
              lv_dummy TYPE string,
              ls_msg   TYPE symsg.
        DATA: lv_person_id_external TYPE pad_sfec_employment_id_v2.
        DATA: lv_pernr TYPE pernr-pernr.
        DATA: ls_pn_ftsd TYPE hrsfec_pn_ftsd.
        DATA: lt_job_info TYPE pad_sfec_ce_job_info_tab.
        "Confirm it's not a new hire.
        IF NOT cv_new_hire IS INITIAL.
        ls_ptp_config = mo_itmap_helper->get_ptp_config( ).
        LOOP AT is_person-employment_information ASSIGNING FIELD-SYMBOL(<ls_emp_info>)
          WHERE employment_id = iv_employment_id.
          "Fetch PERNR from User ID field
          lv_pernr = <ls_emp_info>-user_id.
          IF lv_pernr IS INITIAL.
            RETURN. "Pernr not found
          "Check if the employee's PERNR already has a FTSD override.
          SELECT SINGLE * INTO ls_pn_ftsd
                 FROM hrsfec_pn_ftsd WHERE pernr = lv_pernr.
          IF sy-subrc EQ 0.
            RETURN. "No need to proceed further
          "Sort Job Info
          CLEAR lt_job_info.
          lt_job_info = <ls_emp_info>-job_information.
          SORT lt_job_info BY  start_date end_date. "Sort chronologically.
          "Ensure we have the employment information which contains the job info we are processing.
          WITH KEY end_date = is_job_information-end_date
                   start_date = is_job_information-start_date
                   company = is_job_information-company.
          IF sy-subrc NE 0.
          "Process in chronological sequence of the Job Info portlet records.
          LOOP AT lt_job_info ASSIGNING FIELD-SYMBOL(<ls_job_info>).
            "Skip if record is prior to or on FTSD date
            "NOTE: If the Rehire happens on the FTSD date, there is no need to override.
            IF <ls_job_info>-start_date LE ls_ptp_config-full_trans_start_date.
            "Rehire Event check
            IF <ls_job_info>-event NE 'R'.
              EXIT. "Should only proceed if the very first event after FTSD is Rehire Event.
            "Fetch all of infotype 0 records between FTSD and 1 day prior to Job Information Start Date.
            lv_endda = <ls_job_info>-start_date - 1.
            CLEAR: lt_p0000, lt_pnnnn, lt_prelp.
                CALL METHOD cl_hrsfec_service_lib=>itf_read_all_it
                    iv_pernr           = lv_pernr
                    iv_infty           = '0000'
                    io_message_handler = io_messsage_handler
                    iv_from_date       = ls_ptp_config-full_trans_start_date
                    iv_to_date         = lv_endda
                    et_pnnnn           = lt_pnnnn.
              CATCH cx_hrsfec_root INTO lx_root.
                CLEAR lx_root.
                EXIT. "Quit the loop
            "Convert to infotype 0 structure.
            IF NOT lt_pnnnn IS INITIAL.
              APPEND LINES OF lt_pnnnn TO lt_prelp.
              CALL METHOD cl_hr_pnnnn_type_cast=>prelp_to_pnnnn_tab
                  prelp_tab = lt_prelp
                  pnnnn_tab = lt_p0000.
              SORT lt_p0000 BY begda.
              CLEAR: lt_pnnnn, lt_prelp.
            "There should be exactly 1 record present, which is a term record.
            DESCRIBE TABLE lt_p0000 LINES sy-tfill.
            IF sy-tfill NE 1. "Expect exactly 1 record
              EXIT. "Quit the loop
            "That record should be of term status.
            READ TABLE lt_p0000 ASSIGNING FIELD-SYMBOL(<ls_p000>) INDEX 1.
            CASE <ls_p000>-stat2.
              WHEN '0' "Withdrawn
                OR '2'. "Retiree
              WHEN OTHERS.
                EXIT. "Quit the loop
            "Have Individual FTSD override
            ev_full_trans_start_date = <ls_job_info>-start_date.
            "Note: Subsequent standard replication process shall update the
            "      table hrsfec_pn_ftsd with this FTSD value for the PERNR.
            EXIT. "We got what we wanted. Done with the loop.
          ENDLOOP. "AT lt_job_info
        ENDLOOP. "AT is_person-employment_information​

    NOTE: The above sample code makes use of a custom class ZCL_HRSFEC_CE_ITMAP_HELPER. I shall share more about this class in a future post. This class will have static data as well as static methods to buffer and extract relevant configuration table entries for the concerned T77SFEC_PTP_CONF Config ID under execution.

  2. Another reason why you might need to make entry to PERNR-specific FTSD table (HRSFEC_PN_FTSD) would be because data in EC isn’t suitable for successful replication until a later date. E.g., retro-effective changes to EC data which unfortunately can’t be replicated into ECP without errors. We are talking of bad data scenarios, which do happen in the real world. So, you then come up with a date from when you want the data to replicate, and accordingly have EC portlet record start dates aligned to that date. This would be on a case-by-case basis, and hence not something you can automate via a BADI.

I shall cover more such interesting customization aspects in upcoming blog posts. Stay tuned. Until then ‘Sarve janah sukhino bhavantu, samasta sanmangalani santu’ (Let all beings be happy. Let all beings be comfortable.).

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Sankarsan Dey
      Sankarsan Dey

      Hi Rajendra,

      I have a query on the already terminated employee replication as Rehired post Go Live. Is it possible ?

      Post Go Live if we are trying to replicate the Rehired case where as those employee is not available in ECP then system won't accept the entry with the help of PN_FTSD table or BADI.

      As per your post , it looks like you have done the similar requirement with code change via Badi.

      But with the similar code , for us it's not accepting . Are you considered same terminated employee as Rehire or pass them as new hire/new employee id only?


      Waiting your response.



      Author's profile photo Rajendra Prabhu
      Rajendra Prabhu
      Blog Post Author

      For my client, we had migrated the entire history of all employees (including terminated ones) from the legacy on-premise ECC HR system to EC Payroll. In EC, we had loaded only minimal information for the converted terms and thus didn't want them to be considered for replications overwriting good migrated data in ECP. We achieved this by putting the converted terms in a non-replicated payroll area. Now, when they are rehired, they shall be placed in the correct payroll area for replications, and the BADI code mentioned in the blog post would set the individual FTSD for them as per their rehire date.

      Now, if you are not migrating history into EC Payroll, it would be advisable to not skip replicating converted terms from EC into ECP. You can have them in payroll area which is not considered for payroll runs. That way, when they are rehired, ECP shall accept "Rehire Action".

      Hope this helps, or else, please elaborate further on your business scenario. Thanks,

      Author's profile photo Sankarsan Dey
      Sankarsan Dey

      Thanks Rajendra.

      Yes that is current SAP standard behavior to replicate any employee from EC to ECP.

      We are also following the same.

      Author's profile photo Divyashree rai
      Divyashree rai



      Could you please let me know how did you fix the replication issue for rehire . Even I have same requirement.

      Author's profile photo Emre Kucuksari
      Emre Kucuksari

      Hi Rajendra Prabhu

      I had a question. I am trying to trigger all employee data with RP_HRSFEC_PTP_EE_REPLICATION. I left blank the personel id field. I am trying to trigger but when I checked the SLG1; SFAPI query returned "0".

      I cannot trigger initial load for all employees. Is there any way to trigger full employees at the same time.