How the content of the SF field "Full-time employee" is transferred to the field "Part-time employee" in infotype 7
This is the third part of the series "Integration SuccessFactors to SAP HCM". in the past post we dealt with the architecture and the system landscape. In this context, we also looked at the SAP cloud platform as a middleware solution. In addition to the detailed technical process, the individual predefined integration packages were presented.
In this article you will learn how the SF field "full-time employee" becomes the HCM field "part-time employee".
Figure 1 - Illustration of the field "part-time employee" in SAP HCM and "full-time employee" in SF EC
The graphic illustrates the two fields of the different systems. The SF system with the job information from Employee Central is shown on the left. Accordingly, the information about the full-time employee status is displayed there as "Is Fulltime Employee". In this context, "Yes" means that the employee has a full-time job. The equivalent in SAP HCM is infotype 0007 (planned working time). The information about the part-time worker field is shown here. Accordingly, in this context, "Yes" means that the employee works part-time. This illustrates the need for a well thought-out mapping concept. The following graphic illustrates such a conflict.
Figure 2 – Illustration of 1:1 field mapping
As part of the standard integration between SAP HCM and SF EC, there are various options for harmonizing the data models. Due to the difference in the data models, the following problem arises, which must be considered when creating a concept. On the one hand, the different structure of data storage between the SAP HCM infotypes and the object-oriented storage in portlets in SF EC. This results in the constellation that a storage object in SuccessFactors EC must be harmonized with two or more infotypes. For this reason, one-to-one mapping between infotype and storage object is usually not possible. On the other hand, the difference in the time logic between the SAP HCM time commitment concept and SF EC-effective dating represents the challenge of harmonizing these.
A primary mapping can be defined for each bay from the SF EC system. In this context, this primarily means that this is the actual assignment. A secondary assignment means that, for example, a different field assignment can be defined for a specific country. Regardless of the primary or secondary mapping, the implementation is as follows: First, the source field from the SF EC system must be specified. Based on the conceptualized value mapping, a mapping mode must be chosen. There are three options: BAdI mapping, infotype mapping, or preconfigured mapping. With the BAdI assignment, a customer-specific assignment logic is implemented, which must be implemented using SAP's own ABAP programming language. In contrast to this, the infotype, if necessary the subtype and the technical infotype field are specified for the infotype assignment. The pre-configured assignment is defined by SAP and maps specific logic. The preconfigured assignments are not discussed in detail in this entry, since they are not required for the given example. A value assignment entity can also be specified if there is a selection list for the respective fields or the value is to be converted using constant values.
Figure 3 - Customizing of the field mapping
The figure shows the technical configuration of the mapping in Customizing. For the mapping of the full-time employee information, an infotype assignment is made first. This shows the already mentioned conflict, so that a one-to-one mapping is not possible. In addition to the field mapping, processing logic is required that inverts the information content.
Figure 4 - Field mapping with BadI processing
Due to the additional BadI processing, the value from the SF system is now inverted, so that "Yes" -> "No" and vice versa.
In addition to the BadI processing shown, there are other options for adding logic to a one-to-one field mapping. No ABAP programming is required for this. There are a total of twelve predefined conversion rules to implement the conceptual requirements for data harmonization. For example, constant prefixes/suffixes can be appended or the received value can be multiplied by a defined number. Values can also be replaced by others based on a pattern.
Complex data harmonization can be carried out using the board tools mentioned, which are provided by the predefined standard integration. With a well thought-out concept, we help you to successfully integrate the systems.
As part of this article, you have learned from an example of how data fields can be harmonized between SAP HCM and SF EC. The possibilities for data harmonization of the standard integration were presented. In the next article in this series, we will show you how you can identify master data errors when operating the interface and which protocols are available in the respective systems.
If you already have questions, suggestions or feedback regarding the integration, please use our contact form.
