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”.

   Sample code for BADI: HRSFEC_B_CE_DECIDE_HIRE_REHIRE Method: IF_HRSFEC_CE_DECIDE_HIRE_REHIR~DECIDE_HIRE_REHIRE

   * 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: lt_p0000 TYPE STANDARD TABLE OF p0000 WITH DEFAULT KEY.
       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.
         RETURN.
       ENDIF.
   
       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
         ENDIF.
   
         "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
         ENDIF.
   
         "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.
         READ TABLE lt_job_info TRANSPORTING NO FIELDS
         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.
           CONTINUE.
         ENDIF.
   
         "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.
             CONTINUE.
           ENDIF.
   
           "Rehire Event check
           IF <ls_job_info>-event NE 'R'.
             EXIT. "Should only proceed if the very first event after FTSD is Rehire Event.
           ENDIF.
   
           "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.
           TRY.
               CALL METHOD cl_hrsfec_service_lib=>itf_read_all_it
                 EXPORTING
                   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
                 IMPORTING
                   et_pnnnn           = lt_pnnnn.
             CATCH cx_hrsfec_root INTO lx_root.
               CLEAR lx_root.
               EXIT. "Quit the loop
           ENDTRY.
   
           "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
               EXPORTING
                 prelp_tab = lt_prelp
               IMPORTING
                 pnnnn_tab = lt_p0000.
             SORT lt_p0000 BY begda.
             CLEAR: lt_pnnnn, lt_prelp.
           ENDIF.
   
           "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
           ENDIF.
   
           "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
           ENDCASE.
   
           "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.).