Listing Enhancements and Features for SAP ERP-SAP SuccessFactors Full Cloud Core Hybrid Integration in the 1H 2024 Release

We introduced the EMPLOYMENT_END_DATE filter in the WHERE clause of the Compound Employee API to filter terminated employments from the Compound Employee API response.

It targets the end_date attribute of the Employment Information entity and requires the employment_information segment to be requested.

Until this current release, there was no filter available to remove terminated employments from the response.

How It Looks Now

Sample Code: Result for query with employment_end_date >= to_date('2014-01-01')

1234567891011121314151617181920212223
<person>
  [...]
     <employment_information>
       [...]
          <assignmentIdExternal>179</assignmentIdExternal>
	     [...]
          <employment_id>1061</employment_id>
          [...]
          <start_date>2012-08-01</start_date>
          <user_id>179</user_id>
          [...]
    </employment_information>
    <employment_information>
          [...]
          <assignmentIdExternal>employee1</assignmentIdExternal>
          [...]
          <employment_id>570</employment_id>
          [...]
          <start_date>2008-12-03</start_date>
          <user_id>employee1</user_id>
          [...]					 
     </employment_information>
</person>

How it Looked Before

Sample Code: Result for query without using the employment_end_date-filter

123456789101112131415161718192021222324252627282930313233343536373839404142434445
<person>
  [...]
     <employment_information>
        [...]
           <assignmentIdExternal>179</assignmentIdExternal>
	      [...]
           <employment_id>1061</employment_id>
           [...]
           <start_date>2012-08-01</start_date>
           <user_id>179</user_id>
           [...]
      </employment_information>
      <employment_information>
           [...]
           <assignmentIdExternal>180</assignmentIdExternal>
	      [...]
           <employment_id>1081</employment_id>
           <end_date>2012-07-15</end_date>
		 [...]
           <start_date>2012-07-02</start_date>
           <user_id>180</user_id>
	      [...]					 
       </employment_information>
       <employment_information>
	      [...]				
           <assignmentIdExternal>181</assignmentIdExternal>
		 [...]
           <employment_id>1082</employment_id>
           <end_date>2012-07-15</end_date>
		 [...]
           <start_date>2012-07-01</start_date>
           <user_id>181</user_id>
		 [...]
       </employment_information>
       <employment_information>
           [...]
           <assignmentIdExternal>employee1</assignmentIdExternal>
           [...]
           <employment_id>570</employment_id>
           [...]
           <start_date>2008-12-03</start_date>
           <user_id>employee1</user_id>
	      [...]
       </employment_information>
</person>

For the Job Information segment in the Compound Employee API, we introduced manager_assignment_id_external and manager_person_uuid as additional attributes.

We added the attributes manager_assignment_id_external and manager_person_uuid to provide consumers additional options to identify the manager. Like for manager_employment_id, manager_person_id and manager_person_id_external, the field values are determined based on the manager_id contained in the Job Information segment.

How It Looks Now

Sample Code:

12345678910
<job_information>
  […]
   <manager_assignment_id_external>Manager21711</manager_assignment_id_external>
   <manager_employment_id>1868</manager_employment_id>
   <manager_id>Manager21711</manager_id>
   <manager_person_id>1497</manager_person_id>
   <manager_person_id_external>Manager21711</manager_person_id_external>
   <manager_person_uuid>35558A821F4B4609A4DD6222DB94AC4B</manager_person_uuid>
  […]
</job_information>

How it Looked Before

Sample Code:

12345678
<job_information>
  […]
   <manager_employment_id>1868</manager_employment_id>
   <manager_id>Manager21711</manager_id>
   <manager_person_id>1497</manager_person_id>
   <manager_person_id_external>Manager21711</manager_person_id_external>
  […]
</job_information>

In the current version, you can use the Identify to Exclude from Processing (ECPAO_IN_EE_EXCP) transaction to find the employee for whom the exception occurred. You can suspend processing directly from this transaction and include the employee in processing again when the error is resolved.

In the previous version, we provided the Exclude Employees from Processing (ECPAO_IN_QUAR) transaction to suspend the processing of the data replicated for a specific employee from Employee Central if an exception occurred. But you had to find the employee for whom the error occurred by yourself. You can still use this transaction. Alternatively, you can use the new Identify to Exclude from Processing transaction.

You can now migrate data from all concurrent employments based on the new configuration options in SAP S/4HANA system.

Currently for concurrent employment, the entities like personal info (WS_5), address (WS_10), email (WS_7), and phone (WS_8) are always extracted from the first employment, irrespective of whether the first PERNR is active or withdrawn.

In the current release, we have added new configurational options for migrating Personal Information and Address Information from a specific employment or from all employments. And you can choose the employment for migrating email and phone data based on the configuration.

Support package 3 of the SFSF EC S4 HCM INTEGRATION (ECS4HCM) add-on must be installed in your SAP S/4HANA system.

In the previous version, personal information (WS_5), email (WS_7), phone (WS_8), and address (WS_10) is extracted from the first employment even if it is inactive.

In the current version, there are two options provided to migrate the Personal Information and Address Information from the active PERNR. You can either use the EX_ECPAO_IDNTFY_MAIN_PERNR BAdI or the ERP to EC: Determine Personal Data for Concurrent Employment switch in the V_ECPAO_CONSTANT  view. The BAdI could be implemented to mention the main personnel number of the concurrently employed person. The switch can be used to fetch information (Personal information and Address information) from all the employments as per their dates.

You can now connect multiple Employee Central instances to the same client of your SAP S/4HANA system. For example, if your company has different legal entities that require separate management of employee data and therefore separate instances of SAP SuccessFactors Employee Central, but you want to ensure that common processes, such as payroll that you run in SAP S/4HANA, run consistently for all your employees.

Use this feature if you use separate Employee Central instances and want to continue to run payroll in the same SAP S/4HANA system for all your employees. For each Employee Central instance that you connect, you set up the replication separately.

Core hybrid customers such as service providers who provide payroll in an SAP S/4HANA system and other HR capabilities in Employee Central or conglomerates with different legal entities managed in separate Employee Central instances have asked for this feature. Migration of employee data from one SAP S/4HANA client to different Employee Central instances is also supported

Support package 3 of the SFSF EC S4 HCM INTEGRATION (ECS4HCM) add-on must be installed in your SAP S/4HANA system.

If you use the external assignment ID in Employee Central, you must configure your business rules so that the external assignment ID is unique across all Employee Central instances.