Greetings to all exciting people working with SAP SuccessFactors Time Off Module (And not Only!)!
In this blog today, I would like to demonstrate a specific scenario of how to configure and apply a new function that has been released in the new H1 2020 Release in SAP SuccessFactors Employee Central – Called: ‘Periodic Time Account Updates’.
This function allows you to schedule periodic and automatic updates on Time Accounts, based on certain parameters you apply on your rule.
You can find all relevant information of what this function can do, if you read the revised Time Off Implementation Guide or the revised Implementation Guide for Time Management Scenarios.
Before deep diving in the cool stuff, here are some important highlights you need to have in mind for this function:
You can of course use this function in its simplest form, which would be to update the Time Account with the current Time Account Balance, at the time of execution, and taking into account the applied frequency. It is relatively quite easy to configure this function, if you just follow the steps from the guides provided.
In this blog, I was urged to challenge myself a bit more (Time Off does that to me a lot! ?), and demonstrate to you a more complex scenario of using this function. Let’s get to it!
We will not go through the steps on how to activate and assign the Periodic Update Account Rules, since this is very well explained in the Time Off Implementation Guides.
Note at this point: I have not found or become aware of any other function or process that can actually handle such cases, so please feel free to comment or share your own experiences if you had this request and if/how you were able to implement it! The configuration I will be demonstrating is very custom approach, so if there is a more standard approach to handle this, it would be great to hear about.
Business Requirement:
HR Admin can add one day of On Call Balance to an employee’s Time Account Type for them to use. If the added day is not used by the employee in one month’s period, then the added day needs to be ‘expired’ and removed from the balance.
By reading the above business requirement, someone can directly say that this has way too many variants and anything can go sideways in a configuration approach.
For example, how can we check in the system when the added balance has been posted, so that we know when to get it expired? Or,
How do we know for which added day, should we add an expiring negative day, each time? Or,
What happens, if we have more than one day added in the one month interval?
And so many other vague points.
I have tried to create some scenarios first in an excel sheet and then tried to reproduce them in the system, and after several attempts I have managed to get it to a point where I am pretty confident that I have actually figured it out!
Let’s see the proposed configuration setup and the relevant Business Rule that does the magic and then break it down:
As you can see from the above setup, I preferred having a validation of an employee’s balance done on a weekly basis, in order to generate a relevant periodic update.
I did not go for a monthly update, since this would be too broad, and the required time for making any relevant adjustments (periodic updates) would be too far away from the day they should be posted.
On the other hand, I did not go for a daily update (although this would be a more accurate approach for updating on the exact day), since this would mean too many periodic updates records on the time account being posted.
So by having a weekly update frequency, I then had to find a way to check on each week the balance of the employee two months before each periodic update, and also check any absences during the month before the periodic update.
In order to be able to put this into context, I am sharing the below excel with some scenarios used:
Example 1:
One step further:
Based on the Business Rule Screenshot, here is the logic behind each pinpoint:
1. Calculate number of days posted two months before periodic update, taking into account posting types of “Manual Adjustment”, “Periodic Update”, “Employee Time”. I need all three posting types, since I also need to ensure that I take into consideration past updates or absences posted.
2. Calculate and remove from first element, any Absences occurred during the past one month before periodic update. So this way I ensure that I get a clear remaining balance of whatever is left in balance from the past month when I deduct the second element from the first.
Then, moving to our IF criteria for a Periodic Update to take place; in this section I am using essentially the same mindset as above, to capture the criteria of when the rule should trigger a periodic update based on the past transactions between two and one month before the next periodic update.
3. I am using the same function in pinpoint 3, since I am only interested to capture any relevant transactions that took place in the past two months and were bigger than Zero (so it means there is some balance still pending to be expired).
In 4 and 5 I want to essentially make my above check more specific and check whether there are any Time Absences during the past month, and so therefore, covered from the relevant past transactions that took place two months before. In this way I am doing a validation for one month. If the result is >= 0, it means there are still pending balances that have not been used.
I am using the Opposite Sign in 5 , since the calculation of balances on Employee Time and Periodic Update actually result to positive amount (even though you see them in your UI as negative amounts!)
6 Finally, if all the above criteria are met, then the next periodic rule should post a new Periodic Update Record with the amount resulted in my Variable calculated in pinpoints 1 minus 2.
Again, here I am using the opposite sign, since I need to actually deduct this ‘remaining balance’ from the employee’s time account.
And now let’s put all these little functions in effect to see the end result! I have replicated the same steps as the transactions recorded in my Excel Sheet above. In the below screenshot you can see the final effect of how this weekly periodic update rule has progressed through time, since the first time it started running on January 07th 2020 (Remember: start date was set on January 01st 2020 and was running on a weekly basis).
And Voila!! Pretty cool right?? All the expected periodic updates based on that excel sheet, were posted on spot.
The only weak spots I have for this approach are mainly two:
Other than that, I am still playing around with this and examining different scenarios and so far it works very nice.. so hopefully this will keep working in a stable way!
So, this concludes this blog on how to use the new function of Periodic Update Rule (with a bit more ambition than normal!)
I hope you have enjoyed this, and please leave your feedback and comments below of any thoughts of improvement or similar experience!
Cheers,
Evangelia
In this blog today, I would like to demonstrate a specific scenario of how to configure and apply a new function that has been released in the new H1 2020 Release in SAP SuccessFactors Employee Central – Called: ‘Periodic Time Account Updates’.
This function allows you to schedule periodic and automatic updates on Time Accounts, based on certain parameters you apply on your rule.
You can find all relevant information of what this function can do, if you read the revised Time Off Implementation Guide or the revised Implementation Guide for Time Management Scenarios.
Before deep diving in the cool stuff, here are some important highlights you need to have in mind for this function:
- It can run automatically using various frequency options!!
- You can review all relevant postings using the new screen ‘Review Periodic Time Account Updates’
- It cannot be used in Recurring Time Accounts (if you need to do something similar in recurring Time Accounts, you should use the ‘Interim Account Update Rule’ function)
- This function generates postings with posting Type: ‘Periodic Update’ only.
- It cannot close Time Accounts
- It cannot transfer balances to different time accounts (i.e. in time off in lieu)
- Posting Date needs to be the Period End Date
You can of course use this function in its simplest form, which would be to update the Time Account with the current Time Account Balance, at the time of execution, and taking into account the applied frequency. It is relatively quite easy to configure this function, if you just follow the steps from the guides provided.
In this blog, I was urged to challenge myself a bit more (Time Off does that to me a lot! ?), and demonstrate to you a more complex scenario of using this function. Let’s get to it!
We will not go through the steps on how to activate and assign the Periodic Update Account Rules, since this is very well explained in the Time Off Implementation Guides.
Note at this point: I have not found or become aware of any other function or process that can actually handle such cases, so please feel free to comment or share your own experiences if you had this request and if/how you were able to implement it! The configuration I will be demonstrating is very custom approach, so if there is a more standard approach to handle this, it would be great to hear about.
Business Requirement:
HR Admin can add one day of On Call Balance to an employee’s Time Account Type for them to use. If the added day is not used by the employee in one month’s period, then the added day needs to be ‘expired’ and removed from the balance.
By reading the above business requirement, someone can directly say that this has way too many variants and anything can go sideways in a configuration approach.
For example, how can we check in the system when the added balance has been posted, so that we know when to get it expired? Or,
How do we know for which added day, should we add an expiring negative day, each time? Or,
What happens, if we have more than one day added in the one month interval?
And so many other vague points.
I have tried to create some scenarios first in an excel sheet and then tried to reproduce them in the system, and after several attempts I have managed to get it to a point where I am pretty confident that I have actually figured it out!
Let’s see the proposed configuration setup and the relevant Business Rule that does the magic and then break it down:
As you can see from the above setup, I preferred having a validation of an employee’s balance done on a weekly basis, in order to generate a relevant periodic update.
I did not go for a monthly update, since this would be too broad, and the required time for making any relevant adjustments (periodic updates) would be too far away from the day they should be posted.
On the other hand, I did not go for a daily update (although this would be a more accurate approach for updating on the exact day), since this would mean too many periodic updates records on the time account being posted.
So by having a weekly update frequency, I then had to find a way to check on each week the balance of the employee two months before each periodic update, and also check any absences during the month before the periodic update.
In order to be able to put this into context, I am sharing the below excel with some scenarios used:
Example 1:
- 1 day added on 06th January 2020.
- If the day is not consumed until 06th February 2020 --> it should be removed from balance
One step further:
- 1 additional day added on 22nd January 2020
- In the same sense, if this day is not consumed by 22nd February 2020 --> it should be removed from balance.
- The system checks past transactions every week. So on the 06th January 2020, we would need to check any previous manual adjustments added two months before, and whether any absence has been posted the month following (in this way we ensure the one month validation).
- When we repeat these checks on a weekly basis, we get a relatively accurate result with an offset of around 6 days.
Based on the Business Rule Screenshot, here is the logic behind each pinpoint:
- Design of the Variable: Get the total number of days that should be periodically updated on employee Time Account Balance by calculating the below elements:
1. Calculate number of days posted two months before periodic update, taking into account posting types of “Manual Adjustment”, “Periodic Update”, “Employee Time”. I need all three posting types, since I also need to ensure that I take into consideration past updates or absences posted.
2. Calculate and remove from first element, any Absences occurred during the past one month before periodic update. So this way I ensure that I get a clear remaining balance of whatever is left in balance from the past month when I deduct the second element from the first.
Then, moving to our IF criteria for a Periodic Update to take place; in this section I am using essentially the same mindset as above, to capture the criteria of when the rule should trigger a periodic update based on the past transactions between two and one month before the next periodic update.
3. I am using the same function in pinpoint 3, since I am only interested to capture any relevant transactions that took place in the past two months and were bigger than Zero (so it means there is some balance still pending to be expired).
In 4 and 5 I want to essentially make my above check more specific and check whether there are any Time Absences during the past month, and so therefore, covered from the relevant past transactions that took place two months before. In this way I am doing a validation for one month. If the result is >= 0, it means there are still pending balances that have not been used.
I am using the Opposite Sign in 5 , since the calculation of balances on Employee Time and Periodic Update actually result to positive amount (even though you see them in your UI as negative amounts!)
6 Finally, if all the above criteria are met, then the next periodic rule should post a new Periodic Update Record with the amount resulted in my Variable calculated in pinpoints 1 minus 2.
Again, here I am using the opposite sign, since I need to actually deduct this ‘remaining balance’ from the employee’s time account.
And now let’s put all these little functions in effect to see the end result! I have replicated the same steps as the transactions recorded in my Excel Sheet above. In the below screenshot you can see the final effect of how this weekly periodic update rule has progressed through time, since the first time it started running on January 07th 2020 (Remember: start date was set on January 01st 2020 and was running on a weekly basis).
And Voila!! Pretty cool right?? All the expected periodic updates based on that excel sheet, were posted on spot.
The only weak spots I have for this approach are mainly two:
- The system will post a Periodic Update record even if the amount is Zero. So you end up having a huge list of records. It would be great if at least, you could filter these records out on the employee UI, based on amount, not only type as it currently is possible.
- The weekly frequency has a minor slag on the dates that each periodic update should occur. For example, if you compare the dates of periodic updates between the excel sheet and the instance, you would see that the latter happen just a few days after the expected transaction should.
Other than that, I am still playing around with this and examining different scenarios and so far it works very nice.. so hopefully this will keep working in a stable way!
So, this concludes this blog on how to use the new function of Periodic Update Rule (with a bit more ambition than normal!)
I hope you have enjoyed this, and please leave your feedback and comments below of any thoughts of improvement or similar experience!
Cheers,
Evangelia
- SAP Managed Tags:
11 Comments
