Setting up event-reason derivation rules

Pay-Related Objects A-Z

8 Creating Rules

8.2 Setting up event-reason derivation rules

</hris-propagations>

To have the system execute this propagation rule, you need to insert a mapping from the location foundation object to the jobInfo employment object. If such a propagation mapping already exists in the XML file, you do not have to add it again. But if it is not there yet in the XML file, add the following propagation mapping at the end of the XML file:

<propagation—mapping foundation-field=”location.externalCode” hris-field=”jobInfo.location” />

3. Upload the propagation rules in Provisioning under Succession Management Import/Export HRIS Propagation Configuration XML .

Related Information

Foundation Object Tables [page 384]

Employment Object Tables [page 472]

8.2 Setting up event-reason derivation rules

Prerequisites

1. Upload events and employee status picklists.

There is a predelivered list of events and employee statuses that you should not change. You can change the labels, but you cannot add new events or employee statuses. You can also choose to use only part of the predelivered events.

For more information about picklists, see How do you manage picklists?

2. In Provisioning, go to Edit Company Settings Company Settings . Under Employee Central, select the checkbox Enable youCalc rules engine for HRIS [Not Ready for Sales/Production] — requires “Employee Central V2 (i.e., Event Reason Derivation)” and “Effective Dated Data Platform”.

Note

Only after enabling this setting will you see the link for importing/exporting the XML file for event-reason derivation rules. If you do not enable this setting, you cannot upload the XML file, and the user has to manually select the event and event-reason from the UI when changing an employee’s data.

3. The Admin creates event reasons in the system. You might have to show the Admin where this is done in the system:

○ To create an event reason, go to Administration Tools. In the Company Processes & Cycles portlet, select Employee Files Manage Organization, Pay and Job Structures .

○ To mass upload event reasons via CSV file, go to Administration Tools. In the Company Processes &

Cycles portlet, select Employee Files Import Foundation Data .

Note

SuccessFactors delivers a predefined list of standard event reasons. You can use this as a basis, even if you decide to use just some of them. You can find the most current version of this list as CSV file under this link: https://mysp.successfactors.com/productcentral/Pages/display/prodinfo/data+models +and+picklists/default.aspx .

Partners use this link: https://partners.successfactors.com/productcentral/Pages/display/prodinfo/

data+models+and+picklists/default.aspx

○ If an event or event reason leads to a change of the employee status, the Admin has to define the

corresponding employee status accordingly. For example, if the contract with an employee is terminated, the employee status should change to “Terminated”. If the employee is rehired, the employee status becomes “Active” again.

If the event or event reason does not lead to a change of the employee status, for example, if an employee is promoted, the Admin has to leave this field on No Selection.

○ The Admin has to tell you the external code (Event ID) that was used to define the event reasons, as you need these later for the <trueoutput> value in the XML file for event-reason derivation rules.

Context

What are event-reason derivation rules?

When the manager or Admin changes an employee’s data, for example, by increasing the salary or changing the department information, the reason behind this change is normally that an event has taken place in that

employee’s professional life. In our example, the event could be a promotion or a transfer to another department.

The information about which event lies behind this change is stored in the system for reporting purposes.

However, such a change might also include a change to the employee’s status, for example, if the employee leaves the company, the employee status would be changed accordingly to reflect that the employee is no longer an active user in the system.

You can create rules that define the event reason according to what change is done to an employee’s data, so that the system automatically selects the appropriate event reason. Depending on the event reason, the employee status is updated, if necessary.

Why do you want to use event-reason derivation rules?

If you don’t create derivation rules, the user has to manually select the event and the event-reason from the UI every time the user makes a change to the employee data that is linked to an event. However, this is time-consuming and more error-prone, as the employee status depends on the event reason that is selected.

What are events?

Events are occurrences that span the various stages of an employee’s lifecycle from hire to rehire. Technically, events are defined in picklists. Events are predelivered by SuccessFactors; you can’t create new events or change existing ones, except for their labels.

This is a list of events delivered by SuccessFactors:

● Additional Job

Event reasons are defined by the customer. They are used to define more specifically the reason why an event has taken place. For example, the event “Termination” can take place either because the employee’s performance was not sufficient, or because the employee wanted to change company. In this example, if the company wants to differentiate between the two possibilities, you define two event reasons that you could call

“Terminated-Performance Issues”, or “Terminated – By Employee”. You can create as many event reasons for an event as you like.

Technically, event reasons are foundation objects. This means that the Admin can create event reasons under Administration Tools, in the Company Processes & Cycles portlet, under Employee Files Manage Organization, Pay and Job Structures , or mass upload data via CSV file under Administration Tools, in the Company Processes

& Cycles portlet, under Employee Files Import Foundation Data . Are event reasons mandatory?

Yes. Even if a company decides not to create own event reasons for the purpose of narrowing down the reasons why an event takes place, the Admin has to create an event reason for each event that the company uses. This is

because the system defines the employee status after an event has taken place by what has been defined in the event reason. For example, the employee status after the event reason “Terminated – By Employee” is

“Terminated”. If the employee status was “Active” before, it will change to “Terminated” after the event with the corresponding event reason has taken place.

For a minimum setup, the Admin should create one (or several) event reasons for the following:

● Hire event

● Rehire event

● Termination event

● changes to Job Information and Compensation Information

You can associate the event reason for such changes to the Data Change event, or you create more specific event reasons for the events Promotion, Transfer, Pay Rate Change, and so on.

● If Leave of Absence is activated, you need to create event reasons for the events Leave of Absence and Return to Work.

Procedure

1. Download the XML file for event-reason derivation rules.

○ If you're setting up event-reason derivation rules the first time for a company, download the most current version from this link: https://mysp.successfactors.com/productcentral/Pages/display/prodinfo/data +models+and+picklists/default.aspx .

Partners use this link: https://partners.successfactors.com/productcentral/Pages/display/prodinfo/

data+models+and+picklists/default.aspx

○ If you're changing already uploaded event-reason derivation rules, download the XML file from

Provisioning under Succession Management Import/Export Rules XML for EventReason Derivation . 2. Open the XML file in an XML editor and adjust it according to the company's requirements. You do this by

copying an existing rule and changing the following values:

a. Enter a unique rule ID (for example, rule-18).

b. Enter the external code of the event reason the Admin has created before as the <trueoutput> value of the event-reason derivation rule.

Consider the following:

○ You can only configure rules for events and event reasons that are used under Employment Information in the Job Information portlet (HRIS-element ID: jobInfo) or in the Compensation Information portlet (HRIS-element ID: compInfo), and for the foundation object

payComponentGroup which is used to identify salary changes.

○ You cannot create rules for the following events:

○ Hire

○ Rehire

○ Termination

○ Leave of Absence

○ Return to Work

○ Consider the sequence of events as the system reads the file from top to bottom and the first rule that is met is applied (see below under Sequence of event reasons in the XML file).

c. Choose the logical operand you want to use: <and>, <or>, or <xor>. For some examples, see below under XML examples in section Logical operands for rules configuration.

d. Choose the comparative operand you want to use: <greater>, <lesser>, or <equal>. For some examples, see below under XML examples in section Comparative operands for rules configuration.

e. Enter the ID for the field change that is supposed to trigger the rule. Follow this format:

hris-element-id.hris-field-id

You can find examples below under XML examples in section Examples for event-reason derivation rules.

f. A catch-all event reason is included at the end of the standard XML file — keep this in the XML file and do not change it.

For more information, see below under XML examples in section Catch-all event.

3. Upload the XML file in Provisioning under Succession Management Import/Export Rules XML for EventReason Derivation .

Related Information

XML Examples (Event-reason derivation rules) [page 202]

8.2.1 What do you need to do before you can use event-reason derivation rules?

Procedure

1. Upload events and employee status picklists.

For more information about picklists, see Working with ECV2 (Legacy) Picklists [page 345]

Note

3. The Admin creates event reasons in the system. You might have to show the Admin where this is done in the system:

In document EC Implementation Guide (Page 196-200)