- SAP Managed Tags:
Hello Time Community,
I promised in a blog on a similar but more complex requirement (click here to learn how the employees planned hours are posted to a time off in lieu account when he... to describe how to post a fix number of hours to a time off in lieu account in specific circumstances. Here we go:
In this blog I want to show how a fix value is posted to a time off in lieu account when the employee works overtime on a non-working day. Quite easy, straightforward thing.
So assume a customer want to post always 5 hours into a time off in lieu account when an employee performs overtime on a non-working day. Even when he works only 1 hour or 10 hours. Non-working day could be a day without planned working time or a public holiday. In this example I show how this can be achieved with a view configuration steps.
So lets get started. I don´t write on how to detect overtime at all - I assume you are already familiar enough with time valuation when you read my blogs to cover this part on your own.
So lets assume we have already created some valuation rules to get a time type group called "calculated overtime". This could be the result of a daily, weekly or monthly overtime calculation.
Now you take this time type group and apply a filter on it that checks if the overtime was performed on a non-working day. Of course you can also apply more/different filters like on a specific weekday, inbetween a specific clocktime frame and / or on a public holiday. But here we only check on non-working day.
Lets describe the filter first.
We need a filter that can be applied to check if attendance times exist on a non-working day. So the criteria is "non-working day". We got an extra parameter for this in our filters. Looks like this:
screenshot
Now lets have a look on the valuation rule we need:
This time valuation rule uses as a to be processed input time type group the "calculated overtime" hours. The above described filter is applied via the valuation type "Filter input group" on the input time type group (calculated overtime) and those hours that "pass" the filter, means that fulfill the filter criterias, land in the "time type group below" time type group called "overtimes on non-working day". The time type group above field can be blank. Here would land all overtime hours on a working day but we don´t need them further for our example.
Remember: the above / below concept is THE concept in our time valuation engine. When you understand how this works only the sky is the limit (okay, that´s a bit exaggerated ;-)). But it is essential to understand how this works, so let me tell you how I am doing it.
For me the above / below thing works like a big sieve. You pour something into the sieve, it gets processed on the basis of the valuation type. The hours that met the criterias pass the big sieve and land in the section "time type group below". The remaining hours (cause they do not met the criteria or are splitted based on a threshold) remain in the upper section of the sieve, hence the time type group above section.
In our example overtime is filtered with a non-working day filter. The hours that met the criteria (overtime performed on a non-working day) are passing the sieve and put into the time type group below section. Overtime hours performed on a working day do not met the criterias of our filter and would be stored into the time type group above section. But in our example we don´t need them for further calculations so we can leave this field empty.
We got now the overtime hours based on working time on a non-working day. Now we need to "reduce" the overtime hours to 1 in order to be able to apply a multiplication factor to it. We could do this again with some comparisons with a threshold and route input function, but we can make life ourselves much more easier and just use the "counted events" for it.
Lets sort this out:
Remember, we are only interested in the fact that an employee has performed overtime on a non-working day, not on the actual hours that he has recorded. So we create a time type group of the category "counted events" for this. These events have the fantastic habbit to count just 1 when the defined criterias are met.
So we create first the counter (note that it is category "counted events" to get the 1 counting, a "collector" would give you the actual hours)
Now we need another time valuation rule that examines the overtime that we have pressed through to our non-working day filter and when some hours exist in this time type group a value 1 is posted to the counter:
This is exactly what in above time valuation rule is done. Input time type group is our initially created "overtime on non-working day" time type group that contains overtime hours performed on a non-working day. The valuation rule is a "valuate per day" rule and not "per period" - cause otherwise the counter would increase throughout the time sheet week. We compare with the fix value 0 and write all above into our counter.
This means in essence: each time the time type group contains overtime on a non-working day a counter with value 1 is created per day.
So, we got our 1. Now the last piece is to apply a multiplication factor to it and post this to the time off in lieu account.
Quite easy thing:
This time valuation rule takes as input time type group our above created counter for overtime on non-working days. We use the "aggregate input group and split" valuation function. The rule is triggered per day and we compare the counter value (it can be only 1 or 0 in the counter due to the rules we applied before) with the fix value 0. When there is a value 1 in the counter it is forwarded to what is defined in the "time type group above section". And there we have got a time type group "hours to be posted to toil". That´s it. But wait, where is the multiplication happening?
Check the line at the bottom of the rule where the Input time type group is defined. At the very end of the line you see a field called "factor" and a value 300. This means our event counter for non-working days value is not 1, but 300. So 300 is compared with 0 and passed to the time type group above. 300? Okay, this is now again a bit a weired technical thing where you have to think across 5 corners in order to come to the conclusion. Let me help you:
In the end we want to post hours and minutes to the time off in lieu account. Our time valuation rules calculate with minutes. When we post a value 300 to a time off in lieu account than these are 5 hours. 300 / 60= 5 hours.
And just for the sake of completeness here a screenshot of the time type group that we used in the above rule which is used as a tool to post the hours to the time of in lieu account.
And here is the result, we configured for better visualizing the result some of the time type groups as UI components (which you probably not do in real business implementations). Employee has recorded in the above example 1 hour on a Saturday (non-working day). You can see this below in the background of the result pop-up.
You see that 1 hour of calculated overtime is created. (In the configuration of this system are more evaluation rules triggered that calculate for example also a premium pay of Overtime 1.5- please neglect this). Consider only the end result which is: 5:00 hours have been posted to the time off in lieu account although only 1 hour has been recorded.
Success !
The time type group above in our example is defined as being an overtime premium. The hours are posted to the time off in lieu account when in the employees job info the "overtime compensation method" is set to: time off. If you want to pay out the hours the employees need to have the compensation method "pay out" set in the job information.
By the way, due to the fact that always several paths lead to Rome: you could have used a slightly different way as well to get the same end result.
Check again the valuation rule "Multiply counter by fix factor" 3 screenshots above where the 300-factor was used. You could have dropped the 300 factor-thing here and just use no factor at this place at all. Result would have been that the collector is filled with 1 and 1 passed to the "hours to be posted to toil" time type group. In the definition of the time type group there is also a factor possibility. This factor is used to multiply for example overtime hours with a premium factor. Like for example 1.5 when you want to pay out 1.5 hours for each calculated overtime hours. This factor can be used for our use case as well - but here you would need to enter 5 as a factor. So one time a factor is used within a valuation rule, the other time it is used at the very end of valuation process where results are created. This two different possibilities give you more flexibility to challenge more complex requirements.
But why do I have to use one time 300 and the other time 5? In the time valuation rule processing we calculate deep in our evaluation engine with minutes. So in order to achieve a result of 5 hours we need a factor of 300 cause here everything is in minutes. But when it comes to the end processing where pay types are created or postings to time off in lieu accounts are done we calculate with hours and minutes, so here are factor of 5 is needed.
Hope this helps.
Thanks to Priyanka Agarwal from the Time development team for providing the rules and the screenshots.
And compare the approach above with the already mentioned more complex requirement where employees work in different shifts. Some are 9 hours long, others 11 hours. And they need to work on public holidays. In the event of "normal" work on a public holiday due to the shift planning employees get not only for each hour worked a payment of 1.5. But additionally gets the planned hours completly posted into a time off in lieu account – even if he has worked not the full shift but only 6 hours or even more than his shift.
For this requirement the "route" function is needed. How this is done is described here:
How to use the "route" function
Stay tuned, more to come in future
Volker Ruof
EC Time Product Management
I promised in a blog on a similar but more complex requirement (click here to learn how the employees planned hours are posted to a time off in lieu account when he... to describe how to post a fix number of hours to a time off in lieu account in specific circumstances. Here we go:
In this blog I want to show how a fix value is posted to a time off in lieu account when the employee works overtime on a non-working day. Quite easy, straightforward thing.
So assume a customer want to post always 5 hours into a time off in lieu account when an employee performs overtime on a non-working day. Even when he works only 1 hour or 10 hours. Non-working day could be a day without planned working time or a public holiday. In this example I show how this can be achieved with a view configuration steps.
So lets get started. I don´t write on how to detect overtime at all - I assume you are already familiar enough with time valuation when you read my blogs to cover this part on your own.
So lets assume we have already created some valuation rules to get a time type group called "calculated overtime". This could be the result of a daily, weekly or monthly overtime calculation.
Now you take this time type group and apply a filter on it that checks if the overtime was performed on a non-working day. Of course you can also apply more/different filters like on a specific weekday, inbetween a specific clocktime frame and / or on a public holiday. But here we only check on non-working day.
Lets describe the filter first.
We need a filter that can be applied to check if attendance times exist on a non-working day. So the criteria is "non-working day". We got an extra parameter for this in our filters. Looks like this:
screenshot
Now lets have a look on the valuation rule we need:
This time valuation rule uses as a to be processed input time type group the "calculated overtime" hours. The above described filter is applied via the valuation type "Filter input group" on the input time type group (calculated overtime) and those hours that "pass" the filter, means that fulfill the filter criterias, land in the "time type group below" time type group called "overtimes on non-working day". The time type group above field can be blank. Here would land all overtime hours on a working day but we don´t need them further for our example.
Remember: the above / below concept is THE concept in our time valuation engine. When you understand how this works only the sky is the limit (okay, that´s a bit exaggerated ;-)). But it is essential to understand how this works, so let me tell you how I am doing it.
For me the above / below thing works like a big sieve. You pour something into the sieve, it gets processed on the basis of the valuation type. The hours that met the criterias pass the big sieve and land in the section "time type group below". The remaining hours (cause they do not met the criteria or are splitted based on a threshold) remain in the upper section of the sieve, hence the time type group above section.
In our example overtime is filtered with a non-working day filter. The hours that met the criteria (overtime performed on a non-working day) are passing the sieve and put into the time type group below section. Overtime hours performed on a working day do not met the criterias of our filter and would be stored into the time type group above section. But in our example we don´t need them for further calculations so we can leave this field empty.
We got now the overtime hours based on working time on a non-working day. Now we need to "reduce" the overtime hours to 1 in order to be able to apply a multiplication factor to it. We could do this again with some comparisons with a threshold and route input function, but we can make life ourselves much more easier and just use the "counted events" for it.
Lets sort this out:
Remember, we are only interested in the fact that an employee has performed overtime on a non-working day, not on the actual hours that he has recorded. So we create a time type group of the category "counted events" for this. These events have the fantastic habbit to count just 1 when the defined criterias are met.
So we create first the counter (note that it is category "counted events" to get the 1 counting, a "collector" would give you the actual hours)
Now we need another time valuation rule that examines the overtime that we have pressed through to our non-working day filter and when some hours exist in this time type group a value 1 is posted to the counter:
This is exactly what in above time valuation rule is done. Input time type group is our initially created "overtime on non-working day" time type group that contains overtime hours performed on a non-working day. The valuation rule is a "valuate per day" rule and not "per period" - cause otherwise the counter would increase throughout the time sheet week. We compare with the fix value 0 and write all above into our counter.
This means in essence: each time the time type group contains overtime on a non-working day a counter with value 1 is created per day.
So, we got our 1. Now the last piece is to apply a multiplication factor to it and post this to the time off in lieu account.
Quite easy thing:
This time valuation rule takes as input time type group our above created counter for overtime on non-working days. We use the "aggregate input group and split" valuation function. The rule is triggered per day and we compare the counter value (it can be only 1 or 0 in the counter due to the rules we applied before) with the fix value 0. When there is a value 1 in the counter it is forwarded to what is defined in the "time type group above section". And there we have got a time type group "hours to be posted to toil". That´s it. But wait, where is the multiplication happening?
Check the line at the bottom of the rule where the Input time type group is defined. At the very end of the line you see a field called "factor" and a value 300. This means our event counter for non-working days value is not 1, but 300. So 300 is compared with 0 and passed to the time type group above. 300? Okay, this is now again a bit a weired technical thing where you have to think across 5 corners in order to come to the conclusion. Let me help you:
In the end we want to post hours and minutes to the time off in lieu account. Our time valuation rules calculate with minutes. When we post a value 300 to a time off in lieu account than these are 5 hours. 300 / 60= 5 hours.
And just for the sake of completeness here a screenshot of the time type group that we used in the above rule which is used as a tool to post the hours to the time of in lieu account.
And here is the result, we configured for better visualizing the result some of the time type groups as UI components (which you probably not do in real business implementations). Employee has recorded in the above example 1 hour on a Saturday (non-working day). You can see this below in the background of the result pop-up.
You see that 1 hour of calculated overtime is created. (In the configuration of this system are more evaluation rules triggered that calculate for example also a premium pay of Overtime 1.5- please neglect this). Consider only the end result which is: 5:00 hours have been posted to the time off in lieu account although only 1 hour has been recorded.
Success !
The time type group above in our example is defined as being an overtime premium. The hours are posted to the time off in lieu account when in the employees job info the "overtime compensation method" is set to: time off. If you want to pay out the hours the employees need to have the compensation method "pay out" set in the job information.
By the way, due to the fact that always several paths lead to Rome: you could have used a slightly different way as well to get the same end result.
Check again the valuation rule "Multiply counter by fix factor" 3 screenshots above where the 300-factor was used. You could have dropped the 300 factor-thing here and just use no factor at this place at all. Result would have been that the collector is filled with 1 and 1 passed to the "hours to be posted to toil" time type group. In the definition of the time type group there is also a factor possibility. This factor is used to multiply for example overtime hours with a premium factor. Like for example 1.5 when you want to pay out 1.5 hours for each calculated overtime hours. This factor can be used for our use case as well - but here you would need to enter 5 as a factor. So one time a factor is used within a valuation rule, the other time it is used at the very end of valuation process where results are created. This two different possibilities give you more flexibility to challenge more complex requirements.
But why do I have to use one time 300 and the other time 5? In the time valuation rule processing we calculate deep in our evaluation engine with minutes. So in order to achieve a result of 5 hours we need a factor of 300 cause here everything is in minutes. But when it comes to the end processing where pay types are created or postings to time off in lieu accounts are done we calculate with hours and minutes, so here are factor of 5 is needed.
Hope this helps.
Thanks to Priyanka Agarwal from the Time development team for providing the rules and the screenshots.
And compare the approach above with the already mentioned more complex requirement where employees work in different shifts. Some are 9 hours long, others 11 hours. And they need to work on public holidays. In the event of "normal" work on a public holiday due to the shift planning employees get not only for each hour worked a payment of 1.5. But additionally gets the planned hours completly posted into a time off in lieu account – even if he has worked not the full shift but only 6 hours or even more than his shift.
For this requirement the "route" function is needed. How this is done is described here:
How to use the "route" function
Stay tuned, more to come in future
Volker Ruof
EC Time Product Management
15 Comments
| User | Count |
|---|---|
| 13 | |
| 11 | |
| 5 | |
| 4 | |
| 4 | |
| 4 | |
| 3 | |
| 2 | |
| 2 | |
| 2 |
