This article came into being because there is currently no help guide that comprehensively describes the definitions of Field Criteria for MDF Objects.
Here we not only demonstrate all possible options of the Field Criteria definitions but also use the most common examples from real Employee Central projects.
Field Criteria are very important attributes of MDF objects that facilitate data consistency and data entry through dependent lists.
The idea of Field Criteria is simple: selected object for the parent field determines the list of child objects in the child field; however, in Employee Central, it is not always clear what value ought to be configured in the Source Field Name and Destination Field Name of the Field Criteria.
The most important use of Field Criteria is the selection of Company Structure on Position, when the selected Business Unit determines the list of child Divisions, and the selected Division determines the list of child Departments available for selection. For more details of the business case, see blog post “Mirroring of the SAP ERP HCM Organizational Structure in the EC Company Structure” (Latyshenko, 2021) and the IDP document “Employee Central Core Hybrid: Organization Structure Design Consideration”.
In this article, we will collect all possible options of Field Criteria definitions for MDF objects when both the parent and the child are MDF objects and linked through a field or a valid-when association.
The picture below shows what fields and associations are used to assemble the values for Source Field Name and Destination Field Name of Field Criteria.
Picture 1. Fields and associations used to assemble the Field Criteria
The values required for the Field Criteria depend on the three factors:
On the maintained object, the child “field” can be either a field or an association, whereas the parent field can be only a field and cannot be an association. The field must be visible on the UI and cannot be hidden.
In this article, we will demonstrate the following cases:
For example, Department is a child object of Division. Division is linked to Department through association cust_toDivision. On Position, field division determines values available in field department.
In this case, the Field Criteria definitions for field department of Position ought to be as follows:
* The name of the Database Field Name internalCode, which in 99% cases is internalId for standard MDF objects and mdfSystemInternalCode for custom MDF objects.
For example, there are several levels of object Department linked through standard field parentDepartment. On Position field cust_Deparetment_Level1 determines values available in field cust_Department_Level2.
In this case, the Field Criteria definitions for field cust_Department_Level2 of Position ought to be as follows:
For example, custom object cust_PersonnelArea is a child object of LegalEntity. LegalEntity is linked to cust_PersonnelArea through the custom field cust_LegalEntity.** On Position, field company (which strores Legal Entity) determines values available in field cust_PersonnelArea.
In this case, Field Criteria definitions for field cust_PersonnelArea of Position ought to be as follows:
** Currently the Core Hybrid program ECPAO_TRANSFER_FO_OBJ_TO_EC does not replicate associations. If you use the program for replication of Personnel Areas from ERP to EC, then you have to replicate the link to Legal Entity as a field.
For example, Division is a child object of cust_RouteObject. Object cust_RouteObject is linked to Division through association cust_toRouteObject. On Position, the field cust_RouteObject determines values available in field division.
Case 4 is similar to Case 1, except for the internalId of the parent object cust_RouteObject:
For example, Division is a child object of cust_RouteObject. Object cust_RouteObject is linked to Division through custom field cust_RouteObject. On Position, field cust_RouteObject determines values available in field division.
Case 5 is similar to Case 3, except for the internalId of the parent object cust_RouteObject:
*** If the parent object is a custom object and the child object is a standard object, then the Source Field Name can be either with mdfSystemInternalCode or without it.
The Field Criteria definitions depend on the type of parent object (standard or custom), the type of child object (standard or custom), and the type of the parent-child relationship (association or field).
Name of the internalCode (i.e. internalId or mdfSystemInternalCode) of the parent object is added to the Source Field Name only if the parent object is liked to the child object through an association or if the child object is a custom object.
Author: Vladimir Latyshenko
Here we not only demonstrate all possible options of the Field Criteria definitions but also use the most common examples from real Employee Central projects.
Introduction
Field Criteria are very important attributes of MDF objects that facilitate data consistency and data entry through dependent lists.
The idea of Field Criteria is simple: selected object for the parent field determines the list of child objects in the child field; however, in Employee Central, it is not always clear what value ought to be configured in the Source Field Name and Destination Field Name of the Field Criteria.
The most important use of Field Criteria is the selection of Company Structure on Position, when the selected Business Unit determines the list of child Divisions, and the selected Division determines the list of child Departments available for selection. For more details of the business case, see blog post “Mirroring of the SAP ERP HCM Organizational Structure in the EC Company Structure” (Latyshenko, 2021) and the IDP document “Employee Central Core Hybrid: Organization Structure Design Consideration”.
In this article, we will collect all possible options of Field Criteria definitions for MDF objects when both the parent and the child are MDF objects and linked through a field or a valid-when association.
The picture below shows what fields and associations are used to assemble the values for Source Field Name and Destination Field Name of Field Criteria.
Picture 1. Fields and associations used to assemble the Field Criteria
The values required for the Field Criteria depend on the three factors:
- If the parent object is a custom or a standard MDF object.
- If the child object is a custom or a standard MDF object.
- If the parent object is linked to the child object through a field or an association.
On the maintained object, the child “field” can be either a field or an association, whereas the parent field can be only a field and cannot be an association. The field must be visible on the UI and cannot be hidden.
In this article, we will demonstrate the following cases:
- The parent object is a standard MDF object that is linked to the child MDF object through a valid-when association.
- The parent object is a standard MDF object that is linked to the child standard MDF object through a field.
- The parent object is a standard MDF object that is linked to the child custom MDF object through a field.
- The parent object is a custom MDF object that is linked to the child MDF object through a valid-when association.
- The parent object is a custom MDF object that is linked to the child MDF object though a field.
Details
Case 1, where the parent object is a standard MDF object linked to the child (custom or standard) MDF object through a valid-when association
For example, Department is a child object of Division. Division is linked to Department through association cust_toDivision. On Position, field division determines values available in field department.
In this case, the Field Criteria definitions for field department of Position ought to be as follows:
| Source Field Name | Destination Field Name | |
| cust_toDivision | .internalId | division |
| Valid-when association on child Department to parent Division | Name of the internalCode* field on Division | The field division on Position |
* The name of the Database Field Name internalCode, which in 99% cases is internalId for standard MDF objects and mdfSystemInternalCode for custom MDF objects.
Case 2, where the parent object is a standard MDF object linked to the child standard MDF object through a field
For example, there are several levels of object Department linked through standard field parentDepartment. On Position field cust_Deparetment_Level1 determines values available in field cust_Department_Level2.
In this case, the Field Criteria definitions for field cust_Department_Level2 of Position ought to be as follows:
| Source Field Name | Destination Field Name* |
| parentDepartment | cust_Department_Level1 |
| Name of the field that links the child Department to the parent Department | Name of the field on Position that stores the Department of Level 1 |
Case 3, where the parent object is a standard MDF object linked to the child custom MDF object through a field
For example, custom object cust_PersonnelArea is a child object of LegalEntity. LegalEntity is linked to cust_PersonnelArea through the custom field cust_LegalEntity.** On Position, field company (which strores Legal Entity) determines values available in field cust_PersonnelArea.
In this case, Field Criteria definitions for field cust_PersonnelArea of Position ought to be as follows:
| Source Field Name | Destination Field Name | |
| cust_LegalEntity | .internalId | company |
| The field on the child custom object cust_PersonnelAreas that stores the parent Legal Entity | Name of the internalCode field on Legal Entity | The field company on Position (the field stores Legal Entity) |
** Currently the Core Hybrid program ECPAO_TRANSFER_FO_OBJ_TO_EC does not replicate associations. If you use the program for replication of Personnel Areas from ERP to EC, then you have to replicate the link to Legal Entity as a field.
Case 4, where the parent object is a custom MDF object linked to the child MDF object through a valid-when association
For example, Division is a child object of cust_RouteObject. Object cust_RouteObject is linked to Division through association cust_toRouteObject. On Position, the field cust_RouteObject determines values available in field division.
Case 4 is similar to Case 1, except for the internalId of the parent object cust_RouteObject:
| Source Field Name | Destination Field Name | |
| cust_toRouteObject | .mdfSystemInternalCode | cust_RouteObject |
| Valid-when association on child Division to parent cust_RouteObject | Name of the internalCode field on cust_RouteObject | The field cust_RouteObject on Position |
Case 5, where the parent object is a custom MDF object linked to the child (custom or standard) MDF object though a field
For example, Division is a child object of cust_RouteObject. Object cust_RouteObject is linked to Division through custom field cust_RouteObject. On Position, field cust_RouteObject determines values available in field division.
Case 5 is similar to Case 3, except for the internalId of the parent object cust_RouteObject:
| Source Field Name | Destination Field Name | |
| cust_RouteObject | .mdfSystemInternalCode*** | cust_RouteObject |
| The custom field on child Division that stores the parent cust_RouteObject | Name of the internalCode field on cust_RouteObject | The field cust_RouteObject on Position |
*** If the parent object is a custom object and the child object is a standard object, then the Source Field Name can be either with mdfSystemInternalCode or without it.
Conclusion
The Field Criteria definitions depend on the type of parent object (standard or custom), the type of child object (standard or custom), and the type of the parent-child relationship (association or field).
Name of the internalCode (i.e. internalId or mdfSystemInternalCode) of the parent object is added to the Source Field Name only if the parent object is liked to the child object through an association or if the child object is a custom object.
Reference list
- Shameer Thajudeen, 2019. Employee Central Association Concepts. SAP Community Blogs, [online]. Available at https://blogs.sap.com/2019/01/15/employee-central-association-concepts (Accessed: 17 July 2021).
- Implementing Employee Central Core. Document Version: 1H 2021 – 2021-07-04. Available at https://help.sap.com/doc/cc751d98800d414ca72fc4695a9bf3e7/latest/en-US/SF_EC_Master_Impl.pdf (Accessed: 17 July 2021).
- Implementing the Metadata Framework (MDF). Document Version: 1H 2021 – 2021-07-09. Available at https://help.sap.com/doc/067c84408d824c7382637fc264e11310/latest/en-US/SF_IMP_MDF.pdf (Accessed: 17 July 2021).
- Employee Central Core Hybrid: Organization Structure Design Consideration. Document Version 1.2 – 2020-07-28. Available at https://d.dam.sap.com/a/Hf6JH6M/IDP%20Employee%20Central%20Core%20Hybrid%20-%20Organization%20Struct... (Accessed: 17 July 2021).
- Vladimir Latyshenko, 2021. Mirroring of the SAP ERP HCM Organizational Structure in the EC Company Structure. SAP Community Blogs, [online]. Available at https://blogs.sap.com/2021/04/25/mirroring-of-the-sap-erp-hcm-organizational-structure-in-the-ec-com... (Accessed: 17 July 2021).
- Vladimir Latyshenko, 2020. The Core Hybrid integration model on the example of Cost Centers. SAPinsider, [online]. Available at https://www.sapinsideronline.com/wp-content/uploads/2020/12/The-Core-Hybrid-Integration-Model-on-the... (Accessed: 17 July 2021).
Author: Vladimir Latyshenko
- SAP Managed Tags:
4 Comments
