Creating foundation object records during implementation

As mentioned in previous units, SAP SuccessFactors Employee Central has a fundamental corporate and employee data structure. Corporate data includes information about the company's organization, pay, and job structures.

The data is organized in different data tables or objects. Objects that hold company-specific data are called Foundation Objects. These must be built before any employee data can be added to the system. Employee Central comes with standard predelivered objects which can be customized to meet the customer requirements.

Complete the following interaction to learn the status of standard predelivered Foundation Objects.

Foundation Object structures are managed either in XML or MDF. Several FO's are in the corporate data model while others are managed without XML intervention in the Admin Center.

XML-based and MDF-based objects are managed using different tools.

Use the interaction below to learn the tools used for XML and MDF-based foundation objects.

Configuration tasks such as relabeling fields and creating associations of Legacy Foundation Objects (XML-Based FO) remain in the Corporate Data Model. Record creation and management are done in the Manage Organization, Pay, and Job Structures tool.

The configuration of MDF-based corporate data (MDF-based Foundation Objects, also known as Generic Objects) is performed in the Configure Object Definitions and it's record management in Manage Data.

To manage foundation records through import, XML-based entities use Import Foundation Data while MDF-based objects use Import and Export Data.

You can control access to the Foundation Objects and Foundation Object records with these role-based permissions:

• Manage Foundation Objects
• Manage Foundation Object Types
• MDF Foundation Objects

In the figure, Manage Data, you can see a Foundation Object Record. Ace Germany (ACE_DEU) is an example of a Legal Entity record.

Like Employee Records, Foundation Objects are effectively dated. The start date for any record is the first date entered. For previous records, the end date is one day before the new record begins.

The system records the changes between updates using cross-outs. Most Foundation Objects are effective dated; on the screen, look for Effective as of. 

Use the interaction to learn how changes are made to effective-dated foundation objects.

As mentioned previously, corporate data MUST be created first before any employee data is added to the system, as it provides the underlying information for employee files.

Once the Foundation Objects are made, the information can be used to propagate the employee file.

For example, your company is hiring multiple employees with the same Job Classification. The HR admin selects the Job Classification: Engineer (ENG) during the new hire process. Propagation automatically populates subordinate fields like Job Title, Pay Grade, Regular/Temporary, and so on using information from the Foundation Object records. Rules are built for the system to know which employee field is auto-populated by which Foundation Object record. We call this process ‘propagation’. You will learn how to create propagation rules in a later unit.

Complete the interaction below to see how propagation works.

Each Foundation Object has standard fields and custom fields. In addition, several objects have country-specific fields, which allow you to collect locally-relevant data.

Foundation Objects can also have relationships; known as associations. For example, the Location object is associated with the Legal Entity object. In the figure, Relationships: Associations, you can see that the San Mateo office belongs to the ACE_USA Legal Entity. When you change an employee’s company to ACE_USA, you can only see records in the Location field associated with the ACE_USA Legal Entity record.

You will learn how to configure associations in a later lesson.

Picklists are lists of values defined in the instance, which you can reference from any of your Corporate Data Models, Succession Data Models, or MDF Objects. Picklists can streamline data and make data entry more efficient. Picklists determine dropdown options available to the users. Some picklists are already specified in your instance; for example, the Job Level dropdown menu is populated from a list of job levels defined in the JobLevel picklist.

As an administrator, you manage picklists using the Picklist Center. To do that, you will need Picklist Management and Picklist Mappings Set Up permission in RBP.

Organizational structure is one of several foundational structures of Employee Central. These objects describe the various units of a Company. They are structured according to task and function-related aspects which are shared across the entire company. Together, these objects with their hierarchical relationships forms an Organization Structure. They are linked together using associations which provides flexibility to perform HCM planning, forecasting and reporting.

This is the company or legal entity where the employee is hired and has their contract of employment. A Legal Entity represents a company as registered against country laws. It cannot span across more than one country. The country assigned to the legal entity controls the country specific data which is available on the employee's Job Information, Employment Details and Compensation Information.

The legal entity in SAP SuccessFactors Employee Central is a one to one mapping with the company code in ECP/SAP HCM/S4. In EC, the legal entity assigned to the Position object must be the same as the legal entity in Job information. In SAP SuccessFactors, the Legal Entity is the highest object that can be used in the organization hierarchy.

In the figure, Legal Entity, the fields below the Country field are specific to the United States. Country-specific fields will differ based on the country selected for that Legal Entity.

Business Unit is the Business area of the company, representing one operating unit or the business function or line of business within the Company (not geographical).

Division is a level of organization hierarchy lower than the Business Unit. It is a sub division of the business function. In Employee Central, the Division object comes with a standard "Parent Division" field, which allows for hierarchical levels among the division records. Using associations, you can link a division to one or more business units.

A Department has similar properties to a division. A Department stores information for all departments within a company. You can create a hierarchy using the Parent Department field. In this example, one Department can belong to multiple divisions.

The Cost Center is where the employee's costs get assigned in payroll and finance. Cost centers are  budget units in the ERP financial systems. Cost centers do not form part of the organizational hierarchy; it is usually assigned to the legal entity and sometimes assigned at department level. You can store external IDs for integration with financial systems when they do not support the Code field assigned to the Cost Center records in Employee Central. The Cost Center object comes with a standard "Parent Cost Center" field, which allows for hierarchical levels among the cost center records.

The Location object stores the address information of all physical offices for a company where the employee works. Using associations, a location can be linked to a Geo Zone and Legal Entities. International address formats are supported and defined in the Business Address (Corporate Address) in the Country-Specific Corporate Data Model.

Geographical grouping of multiple locations. This is optional. For example, Location Group West Coast contains several locations, including the San Mateo Office, San Diego Office, etc. Location groups are primarily used for EEO reporting in the USA.

You can group multiple locations into one Geo Zone. For example, Geo Zone North America, Western Region contains business locations in San Mateo, San Diego, etc. Geo Zone includes an Adjustment Percentage field, which allows the pay range to be adjusted based on the cost of living. For example, a company can adjust the pay for employees on the West Coast by 15%.

The Pay data provide remuneration-related information such as the different pay components, pay frequency, and pay group.

Job Data provides repeatable job codes to assign employees and stores job-specific data like Full-Time and Standard Hours.

Job Classification stores all job codes and associated information for a company. It helps to identify and classify the employee's work. Common fields include the following: Supervisor Level, Job Level, Regular/Temporary, Full/Part Time, Employee Class, Job Title, and Pay Grade. You can also have country-specific fields for Job Classification.

Several jobs can be sorted based on functional work performed. For example, the Job Classifications: Developer and Developer Manager belong to the Job Function: Engineering (ENG). By default, the Job Function does not display on the employee’s Job Information record; it is used strictly for reporting purposes.

Administrators can add, delete, and update records for any Foundation Object directly in the instance or by using the import tool.

To add, delete, and update records of objects in the Corporate Data Model, use the Manage Organization, Pay, and Job Structures tool. Import records with the Import Foundation Data tool.

Use the Manage Data tool to add, delete, and update records of objects in the Configure Object Definition.

Once you have navigated to Manage Organization, Pay, and Job Structures, you can see the main administration page.

Complete the following interaction to see how the tool works.

Once you navigate to Manage Data, you can see the main MDF administration page.

Complete the interaction below to know how the tool works.

Actions for managing a single record, like Creating, Editing, and Deleting, can be processed in bulk, whether you are administering bulk changes for XML- or MDF-based records. The import file must always match the object configuration; a template must always be downloaded before any import action.

Complete the two interactions below to see the difference in importing XML-based from MDF-based foundation records.