Working with Foundation Objects

5.1 Introduction to Foundation Objects

Context

Foundation objects are used to set up data that can be shared across the entire company, such as job codes, departments, or business units. Foundation objects are sometimes referred to as “foundation tables”. Foundation objects are contained and configured in the Corporate Data Model.

Note

Starting with the November 2014 release, Foundation Objects are being migrated to the MetaData Framework (MDF) in a phased manner and will now be referred to as MDF Foundation Objects/Generic Objects(GO).

Migrated Foundation Objects will no longer be configured using the Corporate Data Model. Instead, the Configure Object Definition Page and the Manage Data Page in Admin Tools will be used. For more information on these MDF FOs, refer to the section Working with MDF Foundation Objects.

Table 27: Foundation Objects Migrated to MDF

Foundation Object Migrated in...

Cost Center November 2014 Release

Business Unit Q2 2015 Release

Department Q2 2015 Release

Division Q2 2015 Release

Legal Entity Q2 2015 Release

Legal Entity Local Q2 2015 Release

Foundation objects are the first objects you should load because some of the lists of values proposed in employment information come from the foundation objects.

You can use foundation objects to populate data at employee level. For example, if you assign a job code to an employee, that employee’s record is then populated with all information based on the attributes of the job code

● In such a case, you must first configure propagation of the relevant attributes in the propagation data model.

● You create and maintain foundation objects in the Corporate Data Model. For MDF Foundation Objects, the Admin Tools > Company Processes and Cycles > Company Settings > Configure Object Definitions

page will be used to configure these MDF Foundation Objects and the Admin Tools > Company Processes and Cycles > Employee Files > Manage Data page will be used to manage these MDF Foundation Objects .

● Existing ad-hoc reports now work based on the migrated Foundation Objects. For Advanced Reporting (ODS), the reports will be migrated when you first invoke the reports after migration.

Related Information

Setting Up the Corporate Data Model [page 77]

MDF Foundation Objects [page 142]

5.2 What are the characteristics of foundation objects?

Features

Here's a survey of the features available in foundation objects:

● Foundation objects consist of one or more fields. Some of them are required if you use the relevant object.

● Each foundation element has a technical ID, called an hris-element-id. You cannot change this.

● Each field within a foundation object also has a technical field ID. You cannot change this.

● However, you can change the labels for the foundation objects and the fields they contain. The label is the descriptor that appears on the user interface (UI).

● Except for the start date and, if defined, the end date, which always appear at the top of the screen, the order in which the fields are displayed on the UI is the same as the order in which you list them in the foundation object.

● You can decide whether a field actually appears on the UI and, if so, whether

○ It is required or optional.

○ It is only for display or whether users can change or edit it.

● Every foundation object contains custom fields. These are empty fields you can use to handle data not covered by the fields supplied as standard.

● Some, but not all foundation objects, are “effective dated”.

Related Information

Foundation Object Tables [page 384]

5.3 What are Associations?

Associations define relationships between foundation objects. For example, a business unit consists of several departments, so you would create an association of one business unit to many departments — a ONE-TO-MANY relationship. Whereas a location can only have one geozone associated with it — this is a ONE—TO—ONE association. The type of association restricts what the user can display or enter in Employee Central — for a ONE_TO_ONE association from location to geozone, for example, the user can enter exactly one geozone for a location on the UI.

The standard XML file for the Corporate Data Model already contains some associations. These are shown in the table below. You can add more ONE_TO_MANY associations, or change the existing associations in the XML file if needed. Each association has a “driving object” that acts as the basis for the association

5.3.1 Examples of Foundation Object Associations

Note

References to Department, Division, Legal Entity and Business Unit in these examples now point to the MDF FOs.

Table 28:

Source Target Multiplicity Description

Location Geozone ONE_TO_ONE A location can only belong to

one geozone. (Location is the driving object)

Location Legal Entity ONE_TO_MANY Several companies can have

the same location. (Legal En­

tity is the driving object)

Division Business Unit ONE_TO_MANY A division can be associated

with several business units.

(Business Unit is the driving object)

Department Division ONE_TO_MANY A department can be associ­

ated with multiple divisions.

(Division is the driving object)

Job Code Business Unit ONE_TO_MANY A job code can be used across

several business units. (Busi­

ness Unit is the driving object)

Source Target Multiplicity Description

Pay Range Geozone ONE_TO_ONE Companies generally have dif­

ferent pay ranges for each combination of Legal Entity, Job Code, and Geozone.

Pay Range Pay Grade ONE_TO_ONE A pay range is generally asso­

ciated with one pay grade.

Pay Range Legal Entity ONE_TO_ONE Companies generally have dif­

ferent pay ranges for each combination of Legal Entity, Job Code, and Geozone.

Pay Component Group Pay Component ONE_TO_MANY A Pay Component Group can

contain multiple Pay Compo­

nents.

5.4 What is effective dating?

Effective dating means that information records capture time as part of the data that is stored in SuccessFactors and the time element can be edited.

In the application, the HRIS fields “start-date” and “end-date” are used for effective dating. The “start-date” is mostly shown on top of all other fields on the UI. This is where the user has to enter the date when he wants the changes to be effective. Whether an HRIS element is effective-dated or not is defined by the system.

The HRIS field “end-date” does not appear on the UI but is used for reporting purposes. For example, if you change an effective-dated field such as pay grade and set the date when the change should be effective to 01/01/2012, the system records 12/31/2011 as the end date in the background. If you run a report on the pay grade in the time from 01/01/2011 until 12/31/2011, the pay grade value that was valid in that time frame will be shown.

The system does not change the stored data. Instead, it creates a new row of data to track the new values as of the effective date of the change, but continues to store the values that were effective before the change.

5.5 Which foundation objects can you use to structure your business?

There are different types of foundation objects. You can use one of these types, called organization objects, to define how your business is structured.