In this blog post I’ll share how we can achieve one very common requirement from customers using Employee Central: How can we check if an employee has future dated transactions recorded in his/her Job Information section when you need to record a Termination.
This is a requirement that is critical for a lot of integrations between Employee Central and Payroll systems and/or Benefits systems, the implication is that these systems should not receive records with transactions after the termination effective date, specially events that can change the Employee Status like Return to Work, or events that can change their eligibility for Benefits like a Job Change or Promotion.
There is currently a Customer Influence request for this change that got already 18+ votes (link below):
The specific description of the requirement from the Customer Influence request is:
“Give a brief description of what business problem your suggestion helps to solve
When a termination is being entered in EC, display a message if there are future dated transactions which asks to clean it up. (alternatively, make this possible via business rules and we can make our own message, currently business rules can’t identify if there’s a future dated transaction)
Have a notification and/or message during imports which state which records have future dated transactions. This would be beneficial for both terminations and regular effective dated record imports. Terminations require a subsequent clean-up activity, and other loads would need to be validated to ensure propagation occurs correctly.”
Solution – Proposed Configuration
The way I found to check for these future dated events is to create a business rule using a function called “Has Job Change Event For Period ()“, but the trick is that this function will only become available if you activate the Calibration Alerts feature under Manage Calibration Settings.
I created the video below with a step-by-step on how to configure this solution, a simple way to meet a “big” requirement:
This solution can be used not only when you are recording a Termination but also for any other events as needed. The only “down side” of using this solution is that the function uses the Event Reason as a criteria, so you will need to add one condition for each Event Reason you need to check in your rule, but still it should be a low maintenance solution as customers don’t keep creating new Event Reasons all the time, or they shouldn’t be at least 🙂
Thanks for reading/watching, I hope this helped 😉