Configuring Foundation Object association during implementation

Objectives
After completing this lesson, you will be able to:

After completing this lesson, you will be able to:

  • Configure Foundation Object association during implementation

Configuration of Foundation Object association during implementation

Foundation Object Associations 

Associations enable you to define relationships between Foundation Objects and their records. The associations are built in the Foundation Object configurations, on the MDF object, or within the XML. Once the association is built, the records are linked together.

The standard predelivered Foundation Objects include prebuilt associations, such as the Location object. These have built-in associations with the Legal Entity object or the Pay Range object with its own built-in association with the Pay grade object.

Employee records rely on the Foundation Object structure. Any Foundation Object associations must also be aligned with the employee data. The choices that you see on the different lists will be restricted based on the relationships and hierarchies built. This makes it easier for the person working on the employee file to find the correct value and ensures the information complies with the defined hierarchy.

For example, ACE Corp has 30 locations worldwide. Only 13 of these locations are within the United States. The association between the Legal Entity Foundation Object and the Location Foundation Object establishes the relationship between these objects. The 13 US Location records are connected to the United States Legal Entity. When Ace USA Legal Entity is chosen on the employee data, only those 13 locations will display as options, even though we have 30 active Location records in the system.

Supported Associations

Multiplicity

Multiplicity determines how many records you can associate together. Whether you're creating Composite or Valid When associations, there are two types of Multiplicities: one to one and one to many. We'll go through examples of both types of multiplicities.

One to One Associations 

Here, you can see an example of a one-to-one association between Location Groups and Locations for ACE Corp. At the bottom of the chart, notice that the Seattle Location only belongs to the NA_West Location Group. Seattle does not connect to the NA_East Location Group. If none of the Location records ever belong to more than one Location Group, then you can set the multiplicity as one-to-one.

This means that a location can only belong to one Location Group.

One-to-one associations will display at the record level as picklists since you can only choose one option.

Note

There are existing one-to-one relationships that come standard with Employee Central. SAP SuccessFactors recommends that any new custom associations be created as one-to-many.

One to Many Association

The most common type of multiplicity for Foundation Object records is one-to-many. The figure shows an example from ACE’s configuration of a one-to-many relationship between Job Classification and Country Specific Fields for Job Classification. The Account Manager job classification (parent) is associated with many country-specific job classifications (child), where the country-relevant fields for Account Manager are stored in the child object. The system displays one-to-many associations as a separate section at the bottom of the Foundation Object record, where multiple records can be connected.

Note
Just because you create a one-to-many association, this does not mean you have to always choose multiple records. In the example, ACE could have maintained country-specific fields relevant only to the United States but not Germany or France. One-to-many opens the possibility of being connected to more than one option and makes it easier to add associated records if the need arises.

Categories of Foundation Object Association

There are four categories of Foundation Object associations. We'll cover MDF to MDF and XML to MDF associations in detail. XML to XML and MDF to XML will be discussed at a high level, as the processes are similar to the first two.

Association Properties

These are the fields required to be filled in when configuring relationships between objects:

  • Name: a unique name for the association. All customer defined association is automatically prefixed with "cust_"
  • Multiplicity: One to One or One to Many
  • Destination Object: Depends on whether the association is composite or valid-when
    • For composite, it is the child object on which the association is added
    • For valid-when, it is the higher-level object in the hierarchical structure
  • Type: Composite or valid-when (the other type, Join By column, is not used in this training).
  • Label: Display label identifying one or more related records.
  • Field Criteria: Restricts the possible values for the field.

MDF to MDF Associations 

In this association, we are creating a hierarchical relationship (and a filtering effect) between two MDF-based objects. Business Unit to filter Division records. The steps to configure this type of association can be divided into three high-level steps:

  1. Creating the relationship in the object.
  2. Aligning the relationship in the Employee File.
  3. Aligning the relationship in Position Management (applicable only if Position Management is enabled).

Create the Relationship 

Configure the association on the Foundation Object to be filtered (lower-level object in the hierarchy). The Business Unit is the higher-level object in the hierarchy structure, and the Division is the lower-level object.

The steps are as follows:

  1. Type Configure Object Definitions in Action Search.
  2. From the Search dropdown, select Object Definition and then from the next dropdown, select Division (the object to be filtered). The division's object definition is displayed.
  3. Go to Take Action → Make Correction.
  4. Go to the Associations section at the bottom.
  5. Select Details. We will now set the association.

a. In the Name field, specify a name for the association.

b. In the Multiplicity field, select One to Many.

c. In the Destination Object field, select the higher-level object that will filter the values for the source object.

d. In the Type field, select Valid When

Align the Relationship in the Employee File

Ensure that the relationship between Foundation Object records is aligned with employee records by defining field criteria in BCUI (Manage Business Configuration UI) or Succession Data Model.

The steps are as follows:

  1. Type Manage Business Configuration in Action Search
  2. Go to HRIS Elements → jobInfo.
  3. Navigate to the division field, which corresponds to the lower-level object (the object getting filtered). Go to Details → Field Criteria
  4. The Destination Field Value is the HRIS field identifier of the higher-level object (the field doing the filtering), in this case, business-unit.
  5. The Source Field Name has two parts. The first part is the Name of the association in Configure Object Definition. The second part is the fieldname of the internal code in the higher-level object. In this example, Source Field Name is written as cust_toBusinessUnit.internalId.

    The field name of the internal code on the parent Object (in this example, internalID) can be derived from the Configure Object Definition page. Look for the Database Field named InternalCode.

  6. Save your changes.

Align the Relationship in Position Management

This step is to be done only when Position Management is enabled. Define Field Criteria for the field related to the MDF FO being filtered. Just like the employee files, this ensures the relationships defined between FO records translate to the Position records.

The steps are as follows:

  1. Go to Configure Object Definition in Action Search.
  2. Go to Search → Object Definition → Position. The Object Definitions page is displayed.
  3. Take Action → Make Correction.
  4. In the Fields section, scroll to the MDF FO field to be filtered. In this case, division.
  5. To view the configuration select Details
  6. In the Field Criteria section, fill in the values mentioned in the figure.

XML to MDF Associations

In this association, we are creating a hierarchical relationship (and a filtering effect) between an XML-based and MDF-based object. Legal Entity to filter Location records. The steps to configure this type of association can be divided into three high-level steps:

  1. Creating the relationship in the Foundation Object.
  2. Aligning the relationship in the Employee File.
  3. Aligning the relationship in Position Management (applicable only if Position Management is enabled).

Create the Relationship

Configure the association on the Object to be filtered. This allows you to attach the higher-level MDF Foundation Object doing the filtering (Legal Entity) to the lower-level XML Foundation Object being filtered (Location). Since the object being filtered is XML, the association is built in the Corporate Data Model. The steps are as follows:

  1. Open the latest version of your corporate-datamodel.xml.
  2. Navigate to the source Foundation Object to be filtered: location.
  3. In the HRIS-associations section of the Foundation Object, add an association line:
    1. Set the multiplicity to ONE_TO_MAN
    2. The destination entity should be the id/code of the MDF destination object, which in this case: LegalEntity. This can be found in Configure Object Definitions.

  4. Validate your data model.
  5. Save your file as a new version. 
  6. Upload your data model.

Align the Relationship in the Employee File 

Ensure that the relationship between records is aligned with employee records by defining field criteria in BCUI (Manage Business Configuration UI) or the Succession Data Model. In the Succession Data Model, define the Field Criteria for the filtered XML Legacy Foundation Object field. Just like with the MDF/MDF associations, the XML/MDF association also needs field criteria to maintain the relationships in the employee files. While the step is the same, the information needed differs slightly.

The steps are as follows:

  1. Type Manage Business Configuration in Action Search.
  2. Go to HRIS Elements → jobInfo.
  3. Navigate to the location field corresponding to the lower-level object (the object getting filtered). Go to Details → Field Criteria.
  4. The Destination Field Value is the HRIS field identifier of the higher-level object (the field doing the filtering), in this case, company.
  5. The Source Field Name is the id/code of the object doing the filtering in Configure Object Definition. In this example, the Source Field Name is written as LegalEntity.
  6. Save the changes.

Align the Relationship in Position Management 

Do this step only when Position Management is enabled. Define Field Criteria for the source XML Foundation Object being filtered. The steps are as follows:

  1. Go to Admin Center.
  2. In the Tools Search field, type Configure Object Definitions.
  3. From the Search dropdown, select Object Definition and then select Position from the dropdown next to it. The Configure Object Definitions page is displayed.
  4. From the Take Action dropdown, select Make Correction.
  5. In the Fields section, scroll to the field to be filtered. In this case, Location.
  6. To view the configuration select Details .
  7. In the Field Criteria section, fill in the values mentioned in the figure.

XML to XML Association

In this association, the configuration steps are similar to XML to MDF association.

EXAMPLE: Location Group to Filter Location records.

1. Create the association in the Corporate Data Model.

Code snippet
 
 <hris-associations> 
           <association id="id" multiplicity="ONE_TO_MANY" destination- entity="locationGroup" required="false"/> 
    </hris-associations> 
 
Copy code

2. Align the association in the Succession Data Model (or BCUI). Custom-string3 (definition not visible) is used to store the Location Group the user is assigned. We use a custom field because Location Group is not a standard field in Job Information.

Code snippet
<hris-field max-length="128" id="location" visibility="both"> 
      <label>Location</label> 
      <label xml:lang="en-US">Location</label> 
    <field-criteria destinationFieldValue="custom-string3"  sourceFieldName="locationGroup"/> 
    </hris-field> 
Copy code

3. The steps for aligning in Position Management are the same as other association types. 

MDF to XML Association

When configuring custom associations to XML-based Foundation Objects, a wrapper object for the legacy Foundation Object must be used. This is because you cannot directly define the associations to legacy foundation objects. Foundation Object wrappers are predelivered objects. The association steps are similar to that of MDF-to-MDF Associations.

EXAMPLE: Location to filter Garage records

1. Create the associations in Configure Object Definition.

An association to wrapper uses Composite Type association.

2. Align the association in Succession Data Model or BCUI. In the video, custom-string4 is used because Garage is not a standard field in Job Information.

We use externalCode because it's the field that connects the wrapper to the legacy Foundation Object.

3. Same steps for aligning in Position Management as other association types.

Exercise: Create a generic object with an association

Business Example

ACE Corp is providing free parking spaces for employees in some locations but intends to expand this to all locations in the future. They would like to keep track of the parking spaces available at each location. The information is to be managed centrally and is effective dated. Each garage is associated with one or more locations. The record should reflect the garage ID, name, and number of cars that can be accommodated.

Steps

  1. Create the object that reflects the customer requirements.

    1. Go to Configure Object Definition using Action Search.

    2. Select Create New Object Definition.

    3. Fill out the object as follows.

      FieldValue
      CodeGarage
      Effective DatingBasic
      LabelGarage
    4. Fill out the field definition.

      FieldsData TypeVisibilityLabel
      externalCodeAutonumberNot visible 
      externalNameStringVisibleGarage Name
      carCapacityNumberVisibleCar Capacity
    5. Create the association.

      NameMultiplicityDestination ObjectTypeLabel
      toLocationOne to ManyLocation WrapperCompositeLocation
    6. Set Security to NO.

    7. Save the object.

  2. Create two garage records for testing. 

    1. Go to Manage Data →  Create New →  Garage.

    2. Use the table, Garage Records, for reference. 

      Garage Records

      externalNameEffective DateCar CapacityAssociated Location
      Gala Garage01/01/1990125San Mateo/Francisco
      Amidi Garage01/01/199060Arlington
    3. Save records.

Save progress to your learning plan by logging in or creating an account

Login or Register