In Belgium and France, it is common practice to use time accounts with A&E. Leave is accrued in one year (e.g. 2022), with/without the possibility of taking advance leaves depending on the customer. In the following year (e.g. 2023), the previous year’s accrual is transferred as an vacation entitlement which can be taken up to some point in the year after which the remaining entitlement would be forfeited, then.
In our current SuccessFactors time management solution, we support entitlement transfer only for permanent accounts for regions like ANZ.
But how do we cater to this requirement of recurring accounts which start and end every year? Well, I have a workaround approach which would help you do achieve this. And the good news is that, this is also part of our HXM best practices solution for Time. So, you don’t have to go that extra yard to build it yourself and can use our upgrade centre services to deploy them in one shot
Now lets get to the solution part
Firstly we will need one time account type to accrue monthly . In this example we will consider the accrual period as June – May which (example for France). This would be called ‘acquisition account’ or ‘accrual account’.
Secondly, we will have another time account type which would valid from next period of June to May. The job of this account is to fetch balance from previous acquisition account and present them as vacation entitlements which can be consumed. This would be called ‘Vacation Taking Account’ or simply ‘Entitlement Account’
The ‘acquistion account’ would be assigned to a dummy time type which cannot be used for leave booking. You can have a take rule to prevent such booking
‘Entitlement account’ would be linked to a proper time type which will allow leave booking
Here is an example:
In France, the employee gets 2.5 days of accruals. So the employee would have 30 days of vacation accrued (2.5 days every month) from say June 2022 – May 2023 in the Acquisition account
These accruals are transferred on a regular basis to Vacation Taking Account which is valid from June 2023 – May 2024.
Time Account and Time Type Configuration
Vacation Acquisition Account Type
Monthly Accrual Rule:
This is just a snippet of rule. If you want the complete details, you can deploy the best practices for time off using upgrade center
Vacation Taking Account and Time Type
The accrual rule would fetch the balance from the previous acquisition account and update it on a regular basis.
Accrual calendar process
First the accrual for vacation acquisition period would run monthly and provide 2.5 days. If you want to reduce the accrual per month based on LOA or unpaid leaves, you can also do that additional part in your accrual rule. This accrual calendar can be automatic.
You need to schedule accrual calendar run for vacation taking account period regularly like every month (after the accruals of vacation acquisition is run). This calendar should be run with ‘Recalculation Flag’ as ON. This ensures that the latest balance from acquisition account is transferred every month. You need to do this every month since employees can book leaves in advance from next period.
If you don’t want the employees to book the leave in advance, you can run it only once in a year i.e at the end of vacation acquisition period i.e May 31st of a year.
Now let’s test for an employee who has an Acquisition account as of June 2023
You can see that the acquisition period is from Jun 2023 – May 2024. And since we are currently in august, you can only see three monthly accruals of 2.5 days i.e 2.5 *3 = 7.5 days in total
Now if you want employees to consume this balance in advance from next period, you can run the vacation taking account calendar run
Currently, it shows a balance of 0 since the accruals are not yet transferred as entitlements
Run the calendar
Now you can see that a balance of 7.5 is transferred as entitlements in vacation taking account valid from June 2024- May 2025
If you want to deploy this config in your instance, you can look at Time off best practices for France via upgrade centre
This concludes the blog. Please note in the end, this is still a workaround approach which I think is reasonable to meet such requirements across different regions. Please note, I am not a payroll expert and I am not sure what is the payroll impact of this solution. So please do the payroll workaround from a payroll expert