Data models are used to set up Employee Central in that way that satisfies a company's requirements. You define how a company's organization structure is reflected in the system and what entries a user can make to set up company, person, and employment data. You can add customer-specific fields and rename fields.
The data models are:
● Corporate Data Model
This is where you set up a company's organization, pay and job structure. The data model refers to data that is used throughout the entire instance of the customer.
● Succession Data Model
This is where you set up the data structure of data that relates to the people working in a company, such as compensation and address information.
● Country-specific Corporate Data Model
This is where you set up fields that are specific to a single country. This data model might be needed if the company has locations in more than one country, for example, to define the corporate address fields for each country.
● Country-specific Succession Data Model
This is where you set up international formats and fields, for example, for addresses and national IDs. You might want to set this data model up even if a company operates in only one country, as your employees might live or come from abroad.
What are foundation objects, generic objects, person objects, and employment objects?
These are the four types of data objects that are used in the data models:
● Foundation objects
● Generic objects
● Person objects
● Employment objects
Foundation objects define company data. Generic objects make available certain settings and functions relating to employees, such as vacation and position information. Person and employment objects define employee data and are sometimes referred to as HR data objects. In the following section, you can find more information about these data objects.
What are foundation objects?
With foundation objects you set up data that can be shared across the entire company, such as job codes, departments, or cost centers. Foundation objects can be subdivided into four main areas:
● Organization structures
● Job structures
● Pay structures
● Other data objects, such as event reasons, workflows, and dynamic roles
You define foundation objects in the Corporate Data Model and the country-specific Corporate Data Model.
You can find more information about foundation objects in What are foundation objects? [page 78] and under Foundation object tables [page 203].
What are generic objects?
You use generic objects for settings and information relating to the people working for a business. This information includes, for example, vacation and position information.
You have to enable generic objects in your installation before you can use them. You do this in Provisioning, by checking the Enable Generic Objects box.
You define generic objects in the Succession Data Model and the country-specific Succession Data Model.
What are person objects?
Person objects include information that is linked to the person and does not depend on the job, such as the employee's address and national ID.
You define person objects in the Succession Data Model and the country-specific Succession Data Model.
You can find more information about person objects under Person object tables [page 240].
What are employment objects?
Employment objects include job-related information about a person, such as compensation and hire date.
You define employment objects in the Succession Data Model.
You can find more information about employment objects under Employment object tables [page 255].
How do you work with data models?
The data models are XML files that you can adjust according to a company's requirements. The XML files have standard elements and fields included, so you need only touch those parts of it you want to adjust. You can use the existing XML coding as a guideline, and you also find XML examples and explanations in the following chapters.
General information on data model XML files
The following information is meant to help you understand how the XML files are structured and what you can change.
XML example
The following is an example of how a foundation object is defined in the Corporate Data Model:
<hris-element id=”company”>
<label>Legal Entity</label>
<hris-field max-length=”32” id=”externalCode” visibility=”both” required=”true”
pii=”false”>
<label>Legal Entity ID</label>
</hris-field>
</hris-element>
The main sections of this XML code are the following:
HRIS element: Data objects are set up as HRIS elements in the XML files. Each HRIS element has an ID that you cannot change. In our example, the foundation object “Legal Entity” has the ID “company”. Whenever you refer to this foundation object in one of the XML files, you reference this ID.
HRIS field: Each HRIS elements has certain HRIS fields assigned to it. This is the field that appears on the UI, except when the visibility of the field is set to “none”.
Field types
In the data models, you define the data objects and the fields they refer to. There are different field types:
● Standard fields
Each HRIS element has a number of standard fields to handle the most common customer requirements.
Standard fields have a predefined ID you should not change. The predefined XML files for the data models contain only a selection of the most widely used fields; for a detailed overview of all possible fields, check the data object tables:
○ Foundation object tables [page 203]
○ Person object tables [page 240]
○ Employment object tables [page 255]
● Custom fields
Each HRIS element has several custom fields to add customer-specific information. These can be text fields, date fields, or number fields. Some custom fields are included in the standard XML files and are by default hidden, so you have to explicitly change their visibility attribute if you want them to appear on the UI. You should also change the standard label to a meaningful name.
This is what a custom field looks like in the XML code that is by default hidden:
<hris-field max-length=”45” id=”custom-string1” visibility=”none”
required=”false” />
<label>Custom String1</label>
...
To find out how many custom fields you can use for an HRIS element and what their field ID is, check the corresponding tables for the data objects:
○ Foundation object tables [page 203]
○ Person object tables [page 240]
○ Employment object tables [page 255]
● Country-specific fields
You can add country-specific fields using the country-specific data models. For more information, see Setting up country-specific data models [page 69].
Field order
The order in which the fields are displayed on the UI is determined by the order in which they are listed in the Corporate or Succession Data Model. Exception is the start date: This always appears on top of the screen as the date when the change is supposed to be effective. For the order of specific fields, refer to chapter Setting up country-specific data models [page 69].
Visibility of fields
You define if a field is visible on the UI by setting the value of the attribute visibility accordingly:
● “none”: Field is hidden. You cannot import data for this field via CSV files.
● “view”: Field is read-only. You cannot import data for this field via CSV files.
● “both”: Field is visible on the UI and can be edited
Mostly, you would use either the values “none” — to hide fields that are not needed — or “both” — to allow data entry and data import.
This is what the XML code looks like for a hidden field:
<hris-element id=”company”>
<label>Legal Entity</label>
<hris-field id=”end-date” visibility=”none” required=”false” pii=”false”>
...
If you want to allow data import for a field that is read-only (that is, with visibility=”view”), you can add the attribute allow-import=”true” to it in the corresponding data model. This could be the case for the employee ID field: If the ID is system-generated, you prevent the user from accidentally changing the ID by setting it to read-only. However, you might want to upload existing data for the employees, including their IDs, via CSV file. To make this possible, add the allow-import=”true” attribute as in this example:
<hris-field max-length=”32” id=”person-id-external” visibility=”view” allow-import=”true”>
<label>Employee ID</label>
</hris-field>
Note that the person-id-external field is an exception: You can also use the allow-import attribute when this field is hidden (that is, with visibility=”none”).
Mandatory fields
You can make a field mandatory by setting the attribute “required” accordingly:
● “true”: The field is mandatory. It is flagged as such on the UI and the user has to enter a value to be able to save changes.
● “false”: The field is optional.
This is what it looks like in the XML code when a field is mandatory:
<hris-element id=”location”>
<label>Location</label>
<hris-field max-length=”32” id=”externalCode” visibility=”view” required=”true” />
<label>Code</label>
...
For which fields can you not change the “required” attribute?
The following HRIS fields still require a user entry on the UI, even if you change the attribute in the XML file to required=”false”:
● start-date
● externalCode
● status
…plus the following HRIS fields as listed below:
For this HRIS element in the Corporate Data Model... ...this HRIS field is always required:
company country
corporateAddress country
dynamicRoleAssignment person
eventReason event
frequency annualizationFactor
For this HRIS element in the Corporate Data Model... ...this HRIS field is always required:
For this HRIS element in the Succession Data Model... ...this HRIS field is always required:
compInfo currency-code
For this HRIS element in the country-specific Succession Data Model... ...this HRIS field is always required:
globalInfo country
homeAddress country
Labels
The label is the descriptor that appears on the UI. You can change this label by overwriting it with a name that the customer prefers.
In the following example, the value of the <label> tag of the HRIS element is the descriptor for the foundation object
“location”:
<hris-element id=”location”>
<label>Location</label>
...
In the following example, the value of the <label> tag of the HRIS field is the descriptor for the field “externalCode”:
<hris-element id=”location”>
<label>Location</label>
<hris-field max-length=”32” id=”externalCode” visibility=”both” required=”true” />
<label>Code</label>
...
Translatability of labels
The label is the descriptor that appears on the UI. You can change this label. It can also be translated into other languages using the xml:lang attribute and the corresponding language code. The corresponding translations are stored in the XML file for the data model as shown below:
<hris-element id=”company”>
<label>Legal Entity</label>
<hris-field max-length=”32” id=”externalCode” visibility=”both” required=”true”
pii=”false”>
<label>Legal Entity ID</label>
<label xml:lang="de-DE">Kennung der juristischen Einheit</label>
<label xml:lang="en-GB">Legal Entity ID</label>
<label xml:lang="es-ES">ID de entidad legal</label>
<label xml:lang="fr-CA">ID d’entité juridique</label>
<label xml:lang="fr-FR">ID de la personne morale</label>
<label xml:lang="it-IT">ID entità legale</label>
</hris-field>
</hris-element>
If the system does not find a corresponding label for the system language, it displays the label that has been configured without the xml:lang attribute; in the example above, “Legal Entity ID” would then be displayed.
Effective Dating
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.
This is what the XML code looks like for start and end date:
<hris-field id=”start-date” visibility=”both” required=”true” pii=”false”>
<label>Start Date</label>
</hris-field>
<hris-field id=”end-date” visibility=”none” required=”false” pii=”false”>
<label>End Date</label>
</hris-field>
Search criteria
You can define search criteria that are used to find an entry in the system. In the following example, you define that you can search for a location by entering a city or a country. The system then tries to find a match with the information stored in the corporate address and shows the corresponding result.
<hris-element id=”location”>
List of XML elements and attributes
The following tables provide a quick overview of the XML elements and attributes that are most commonly used in the data models.
● XML elements can contain other XML elements nested inside them. For example, the hris-element XML hris-element can contain label and hris-field XML hris-elements:
<hris-element id=”location”>
● XML elements can contain several attributes, for example, the XML element hris-field contains the attributes max-length and id:
<hris-field max-length=”256” id=”amount”>
● Attributes are name-value pairs; it is predefined which values can be entered for which attributes. In the following example, the attribute with the name max-length can have a number as value:
max-length=”256”
<hris-element>
...can include these XML elements
or attributes: How to use this XML element or attribute:
Attribute id This is the identifier for an HRIS element, which represents one foundation object, or one person or employment object.
You cannot change the ID; to find out which data object has which ID, refer to the hris-element id of the data object tables:
● Foundation object tables [page 203]
● Person object tables [page 240]
● Employment object tables [page 255]
Element description This is where you enter a text that describes an XML element, or what the data model is used for, for example. This description does not appear on the UI.
Element label This is the text that is shown on the UI. You can change it if the customer wants to use a different naming. This text is also translatable.
Element trigger-rule This is used to assign a configurable rule the customer has created to a user action on the user interface. For example, when a page is loaded or saved, a specific system behavior defined in the configurable rule is triggered.
For more information, see Setting up configurable rules [page 105].
Element hris-field With hris-field you define each individual field within this HRIS element.
Element
hris-associations
Associations define the relationship between foundation objects.
Associations can only be defined in the Corporate Data Model.
Element search-criteria
Search criteria define what fields can be used to search this HRIS element.
<hris-field>
...can include these XML elements or attributes:
These are possible attribute
values: How to use this XML element or attribute:
Attribute max-length 256 This defines the maximum length of this field on the UI.
For boolean fields, you can leave out this attribute.
Attribute id start-date This is the identifier for a field within an HRIS element.
You cannot change the ID; to find out which HRIS field has which ID, refer to the column Field ID in the data object tables:
● Foundation object tables [page 203]
● Person object tables [page 240]
● Employment object tables [page 255]
Attribute visibility ● none
● view
● both
The visibility defines if this field is visible on the UI:
● “none”: Field is hidden. You cannot import data for this field via CSV files.
● “view”: Field is read-only. You cannot import data for this field via CSV files.
● “both”: Field is visible on the UI and can be edited
Attribute required ● true
● false
If this is set to “true”, the field becomes mandatory — that means a user entry is required — and is marked as such on the UI.
...can include these XML elements or attributes:
These are possible attribute
values: How to use this XML element or attribute:
Attribute pii ● true
● false
If this setting is true (pii=”true”), it defines that the field is a sensitive field; as such, it will be masked on the screen for security reasons. This is a setting used for password fields, for example. When the user enters his data, only asterisks or similar symbols are shown on the UI instead of the actual data entered. This is done to prevent over-the-shoulder snooping for the user's password.
With this XML attribute you define how many decimal digits are shown after the decimal point. Depending on the number of decimal digits you indicate here, the numbers displayed in the system get rounded up or down.
You can use this property only for HRIS fields with the data type DOUBLE, and you can define up to 5 decimal places. If you do not use this attribute for a DOUBLE data type, the number is rounded to three decimal places by default. If you define a value higher than 5, the system uses the maximum value, which is 5. If you define a negative value, for example, -1, the default value of 3 decimal places is used. Example:
maximumFractionDigits=”2”
If the user enters 4.394 on the UI and the
maximumFractionDigits have been defined to 2, the system reduces the decimal digits from 3 to 2 as defined in the data model and rounds down the value to show the following:
4.39
Make sure that the following HRIS fields use the same maximumFractionDigits value:
● payComponentValue of HRIS element payComponent
● paycompvalue of HRIS element payComponentRecurring
● value of HRIS element
payComponentNonRecurring
The pay component value field of the pay component foundation object is reused in the compensation
The pay component value field of the pay component foundation object is reused in the compensation