9.4 Events, Event Reasons, and Event Reason Derivation
Key Takeaways
- Events come from a standard picklist and cannot be added; event reasons are XML-based foundation objects that set the employee status.
- Every Job and Compensation Information transaction requires an event and an event reason.
- Event Reason Derivation (ERD) is an onSave rule on Job or Compensation Information Model; its first condition should stop processing if the event reason is not null.
- Hire, rehire, and termination event reasons are selected manually and cannot be derived.
- Insert New Record in History bypasses ERD and workflows; SAP calls this an HR Edit and reserves it for administrators.
9.4 Events, Event Reasons, and Event Reason Derivation
Quick Answer: Events (hire, promotion, transfer, termination) come from a standard picklist. You can relabel or deactivate events but cannot add new ones. Event reasons are XML foundation objects that explain the event and set the employee status. Event Reason Derivation (ERD) uses onSave rules to pick the reason automatically from the data change. SAP recommends ERD because it gives cleaner reporting.
Events and Event Reasons
Employee Central delivers a standard, exhaustive Events picklist. You cannot add a custom event, but you can deactivate or relabel event values. To distinguish why an event happened, you use the Event Reason foundation object. A promotion, for example, could be a lateral move without a pay change or a vertical move with an increase.
Events and event reasons let customers:
- keep clear reports of what changed
- comply with legal or corporate policy on employee changes
Every Job and Compensation Information change requires an event and an event reason.
Event Reason is an XML-based foundation object, managed in Manage Organization, Pay and Job Structures. Event reasons are tied to events and define the employee status, so do not modify or repurpose the employee-status picklist. The event reason can also carry termination settings such as Delete Future-Dated Records After Termination (Section 8.1).
With or Without Derivation
| Without ERD | With ERD (preferred) |
|---|---|
| The user chooses the event and reason manually | Business rules set the event, event reason, and workflow from the data change |
| Business rules connect a workflow to the chosen reason | Needs more initial setup |
| Quicker, simpler solution | More accurate reporting and more user-friendly |
When managers pick reasons manually, errors are common and reports become unreliable. With ERD, the system selects the reason and updates the employee status if needed. ERD needs careful design: every possible change in Job and Compensation Information must be anticipated and tied to a reason. If no rule sets the reason, the system raises an error the initiator cannot resolve.
Without ERD, for Job Information edit and history transactions, managers and admins see only events that have at least one event reason they have Edit permission for.
What Cannot Be Derived
Hire, rehire, and termination event reasons are always selected manually. You cannot create a derivation rule for them.
Setting Up an ERD Rule
- Create a rule with the scenario Trigger Event Reason Derivation (EC Core).
- Give a name and ID. Do not use spaces in the rule ID, or it will not trigger correctly.
- The base object is limited to Job Information Model or Compensation Information Model.
- First IF: event reason is not equal to null, with an empty THEN. This keeps a reason already supplied, by a user or an import, from being overwritten.
- Add ELSE IF / THEN pairs for each change scenario. For example, if Standard Weekly Hours is not equal to its previous value, set the event reason. Use as many as needed.
- Add a catch-all, either an ELSE in the last rule or a separate final rule.
- Assign the rule as onSave to the right HRIS element (for example Job Information) in BCUI, with the same Model base object.
Only one event reason can be assigned to a transaction.
SAP's ERD Best Practices
- Check for event reason not equal to null first, to avoid overwriting.
- Group the derivation logic in a single rule for performance, because fewer onSave rules perform better. Split it only when complexity or maintenance requires it, accepting some performance cost.
- Use a catch-all. Without one, MSS users can see "Unable to determine the event reason for the proposed changes". This is a configuration issue.
Worked Example (THR81)
| Setting | Value |
|---|---|
| Scenario / ID | Trigger Event Reason Derivation / ERD_JOBINFO |
| Base object | Job Information Model |
| IF 1 | Event Reason ≠ Null → no derivation |
| ELSE IF | Is Eligible for Benefit ≠ previous value → Event Reason = Benefits Adjustment (PAYBEN) |
| Assignment | BCUI > jobInfo > Trigger Rules: Job Information Model, onSave, placed above the existing jobInfoModel_ERD_migrated_rule so it is processed first |
Changing Is Eligible for Benefit now saves with the Benefits Adjustment reason. Without a workflow rule, it saves without approval. Adding the WF_jobInfo rule derives the Data Change workflow as well (Section 9.5).
Bypassing ERD: the HR Edit
Even with ERD on, users with RBP rights to Insert New Record from the History of jobInfo and compInfo bypass derivation:
- Through Take Action or the pencil icon, the system derives the event and reason and triggers a workflow if configured.
- Through History > Insert New Record, the user chooses the event and reason manually, the change is saved immediately, and no workflow is ever triggered.
SAP calls this an HR Edit, and it should be given only to administrators.
ERD During Imports
To derive event reasons during imports, enable the permission Enable Business Rules for selected entities for imports. A value in the event reason column takes precedence over the onSave derivation. If the column is empty, the onSave rule derives the reason.
Country-Specific Event Reasons
Customers in many countries often have country-specific event reasons. Because each employee belongs to one legal entity and one country, the system can show only the relevant reasons on all screens with an event reason field. This helps large multi-country customers and customers with many country-specific reasons.
- Change the Country/Region object to include a composite association with the Event Reason Wrapper.
- In Manage Data, add the applicable event reasons per country, or import them with Import and Export Data.
A customer wants a new event called 'Sabbatical'. What does Employee Central allow?
What should the first condition of an Event Reason Derivation rule be?
With ERD active, an HR administrator inserts a new Job Information record from History. What happens?