Hello Time Community,
me again, writing from Sankt Leon Rot, Germany, during late summer times some words on the new feature and functions of our EC Time and Attendance Management product (this is the official name, but please allow me to simply call it "EC Time"). Trying to give you useful updates/insights on the development and our plannings and some hints and tips for configuration of our new features.
Let me give you first an overview on the most important features in this release. Our engineering team has developed for you:
Lets directly jump into it. Unfortunately this will be most probably a little deep dive into the time valuation and won´t probably be understood easily by EC Time newbies. But don´t let this daunt you. When you take away the basic ideas and learn roughly what is possible in our time valuation I am already happy. Take the implementation guide, play with the system and you will learn quite fast.
The first new feature is a very useful one. Especially, when you want to ensure that employees meet working time regulations upon time recording:
Cryptical heading. What is meant with this?
In Europe and elsewhere in the world there are working time laws - or guidelines - dealing with the maximum duration of working time per day / week of employees. Laws and guidelines are always a big topic for interpretation in time management and I often had customers same branch, same trade union contract, same region but yet doing time management completly different. But one thing can be found often: customers want to have a maximum duration of time recording. Be it due to laws / guide lines, be it due to the fact that they don´t want to pay overtime payments.
To cater this requirement we provide now error message generation in the time sheet. You could say, wait! There was two releases ago the introduction of business rule availabilty in the time sheet that can be used for error processing, and now we provide something similar in the time valuation. Why this?
Reason is quite simple: Some validations where you need to perform calculations can´t be done in the business rules at all. Additionally business rule performance is quite slow, time valuation is much more faster. But there are still occasions where you need to apply business rules. A business rule is probably easier configured than a validation rule (cause most people know the business rules, but only few know the time valuation rules) and there are constellations that you can´t query in the time valuation rule. Allowances can´t be consumed in time valuation. So when you have got the need for errors around allowance recording (no allowance on an off day; allowance only when a specific working time type is recorded on this day, too; allowance not or only when a specific absence exists for the same day....) you should still use the business rules. More complicated validations (like checking the time sheet period, month, or create sums / calculations) are not possible in the business rule. For this you should always use the new time valuation error possibility.
What are more complex checks? Quite easy:
Take the example of maximum allowed 10 hours of working time on day. This could be covered with business rules by checking a time type and 10 hours. Works. But when it gets a bit more tricky the rules don´t work. When employees record for example two records with "working time", one 5 hours and the other 6 hours the business rule does not give an error. Condition not met. You can´t do summarization in the business rules. Or when an employee records 8 hours working time and 3 hours another attendance time type like travel time: no error. Condition not met. You can always check in the rules only 1 time type and not doing a collection. Or when your employees record times with start / end time and you have an automated break deduction configured. Employee records from 08:00 - 18:30 (10.5 hours), but time valuation deducts a recorded (or automatically generated) break of 1 hour. The rule will give you an error although the net working time of the employee was only 9.5 hours. But the 9.5 hours can only be calculated by time valuation.
This is why we enhanced our time valuation with the possibility to generate errors.To enable you validate more complex constellations and trigger errors on this.
You can now define an automated error generation that blocks the time sheet for further time recording when the time valuation calculates more than xx hours per day or more than xx hours per week. What this calculation contains, is completly up to you. The configuration possibilites are very flexible. You can add several time types, deduct breaks and recorded absence times. You can furthermore raise errors not only based on hours, but also on "events". This means when an employee records more than 3 times (hence, not hours, but events!) on call times in a week. Very flexible. How is this flexibility achieved? We use the already established concept of "time type groups". When you are not familiar with this term, please conduct the time sheet implementation guide that you can find on help.sap.com, book Employee Central; Payroll Time Sheet, cause understanding of this time type groups and the time valuation rules are essential for configuring the time valuation.
Lets have a closer look.
You can define time type groups that are a kind of calculation bucket. In the time valuation rules you assign input time type groups, apply time valuation rules on it and you get most often a value "below" and a value "above". I always imagine to myself the time valuation rules as a kind of funnel where you pure a liquid (input time type groups) into it. The processing of the rule is when the liquid tries to pass the funnel. In the upper part of the funnel the things that did not pass are remaining (bigger items in the liquid than the condition set). The hours of the "gooey liquid" are put into the "above" time type group that is defined in the valution rule. The thinner liquid is meeting the conditions and can pass the funnel and are put to the "below" time type group. I am not that logically minded as our software architects, this is why I am a product manager ;-). But this kind of pictures help me understand how the things work.
An example: you have an input time type group "recorded attendance times". You assign all possible attendance time types (working time, travel time, training, works meeting...) to this group in the definition of it. Now you use a time valuation rule. You check against a fix value of 50 hours per week (or you even can use a calculated threshold that you have created earlier, like for example scheduled working time containing the sum of planned hours of the employee). When the valuation method is set to "daily valuation" only the value of the time type group of this day is checked against the threshold. But when the valuation method is set to "whole sheet" than the whole time sheet period is processed real time. So, in this example the input time type group "recorded attendance time" would be checked upon each time recording if in the time sheet period the value is greater than 50. If yes you would have a value in the "above time type group". If no you would have the calculated value in the "below time type group". Both values are available "fluently", not stored in the database in the actual time valuation run for further calculations (if you need them). You don´t always need to set an entry in both fields above / below. Many times like for the check on 50hours per week you don´t need an entry in the "below time type group". But important: these data is not persisted on the database. It is all on-the-fly calculation. So, up to now nothing new. This is all how time valuation has worked in the past already.
Here comes the new feature:
You can now trigger an error when the time valuation processes a value into the "above time type group" or even into the "below time type group". And you even can define the error message text. In our example: when an employee records over the week more than 50 hours attendance times the time valuation rule sends the hours above 50 to the "above time type group". Once there is a value in it the condition is fullfilled and the error message gets created for the time sheet user interface and the employee can´t save the time sheet. In fact, the error is thrown immediatly with the time recording and not only upon save.
What do you need to configure this? See some screenshots that illustrate this:
First you need a kind of technical time type group where the value "above 50" can be sent to by time valuation. It is rather a dummy container needed for technical reasons. So we create one:
Now you need to create a time valuation rule that validates the whole time sheet. You need choose as input time type groups what you want to check. In my example I use 2 calculated input time type groups. One where in another time valuation step the recorded attendance times have been subtracted by recorded or scheduled breaks. Cause I don´t want to check only the recorded net times, which means attendance times minus breaks. In addition I put as another input time type group a group where in previous time valuation steps paid absence times (again less breaks) have been collected and calculated. Cause when my employee is 4 days on vacation and records 12 hours on the fifth day I want to have this constellation checked against the 50 hours, too. Absences are not worked time, sure, but for me they are "paid times" hence I include them into the check. But this is now a flavour that varies from customer to customer and that you need to clarify in your project: shall absence times be incorporated in this weekly check or not. But thanks to our engineering team - you can configure all variants you want to have to.
The time valuation rule looks like this:
The new thing now is that you can set an error flag an that you can define the error message text. The rule does following: it sums up the input time type groups in the whole time sheet period and compares it with a fix threshold 50. Is the sum bigger than 50 than everything beyond the threshold is put into the time type group stated in the "time type group above" field. And here I assigned exactly the dummy-time type group created earlier. The error is processed and the message text displayed in the time sheet User Interface when there is a value in this time type group. Looks then like this:
You can use our really good time valuation trace in the implementation phase to check what the time valuation has calculated per day in detail. Screenshot below. You see in this trace that not the recorded times 08:00 - 17:00 (I call them "gross times" or "raw recorded data") are taken for the valuation, but the attendance times minus the automated generated breaks. This is due to the input time type group I have choosen in my valuation rule. Cause the employee records in my example each day working time from 08:00 - 17:00, less 1h break per day. Sums up to 40 hours from Mon-Friday. Now on Saturday he records from 08:00 - 19:00 working time. Here no break deduction is applied (cause no break defined or recorded for this day). 11 hours are added to the 40 hours. Sum is 51. We have used a valuation rule with the valuation type "aggregate input group and split" and we defined a threshold of 50, all above shall be put to the time type group "Group for 50h check". And here we go, this is exactly what you see in the trace result: 1 hour has been put by the calculation mechanisms into this time type group. And hence in this time type group is a value other than 0, the condition for the error is met and the error message generated:
Wasn´t that complicated, was it?
Of course this works also for all daily error checks. Then you simply don´t use the parameter "whole sheet" valuation in the valuation rule, but set it to "daily valuation".
And the flexibility of the input time type groups allow all our time valuation types to be applied in order to calculate the "output" time type group (the above/below thing) for the valuation rule that generates the error. You could for example use the "filter and split" options to collect only those times recorded on a specific weekday, before (or after) a specific clocktime. When you for example want to prevent that employees record on days with planned times after 20:00 o´clock times, you can use the filter options. All times after 20:00 are sent to a specific time type group. This group is used as an input time type group for the next valuation rule where you check if there is a value above 0. The result is put into the "above time type group" and then you can process your error message.
Currently we unfortunately support only error messages in the user interface with this feature. But on my wish list is that we also can generate warning messages. And that you will be able to define if a warning is generated for an employee and / or send to a time administrator. You would then be able to sent warnings to a time admin when an employee has performed more than 10 overtime hours per week, when he has recorded less hours than his planned times, when he has recorded working time after the start time of his workschedule, when the working time account balance reaches a specific threshold and so on. But these are currently only ideas for future releases and not yet build.
Now let me add some more complexity, or positively formulated, flexibility 😉
Our time valuation calculated up to now only with the unit hours. But very often, customers don´t need hours but count occurences to trigger an error message. For example an error when an employee records more than 4 times a week on call times. Or the occurence per week where an employee starts to work later than 10:00 in the morning. You are not interested in the hours of the recording, but only on the number of the event.
This can now be done with a new time valuation calculation type called:
When you use this valuation type basically not hours are counted / collected, but the value 1 with the daily valuation. Afterwards you can sum up this events in the time sheet week (via valuate whole sheet) to find out if more than 4 times on call times are recorded. If yes, error, if not: fine.
And again: due to the flexibility of the time type groups you can apply all the other valuation types to process the calculation and set conditions when the event shall be counted. You can use the filter options to count times only on a specific weekday, on days with or without planned times, after a certain clock time (on calls after 18:00 for example) or on working days with a specific shift class.
Lets have a look on a more simple example. You want to ensure that employees do not perform on call times more often than 2 times a week.
You need first a time type group that works as "input time type group". You assign the time type "on call" to this group. The time type is what the employees records in his time sheet.
Now you need to create another time type group that works as counter. You need to use as "Time Category" the entry "Counted events". This is your vehicle with which the events are detected. Looks like this:
Now you have got your input time type group, your container (I am deliberately not using the term "collector", cause we also build a new feature "time collector" as you see in the next chapter and which are technically something different. Even I had hard times in understanding the difference ;-)) to sum up events. And finally you need a valuation rule that actually performs the counting. And here we need to use the new valuation type "Compare threshold with Input Groups and Count Events". Looks like this:
The rest should be know: you check against a fix value of 0 and you use the "time type group above" parameter to write the result of the valuation rule into your counter "On call counter for week" time type group. You need to use here "Valulate per day", cause when you use "valuate whole sheet" the result for the overall time sheet would be 1, regardless on how many days an on call time is recorded. The valuate per day ensures that on each day where on call times are recorded 1 is added to the counter (and here it does not matter if an employee records this timetype twice or often per day. When the condition is met 1 is counted).
You assign this rule to your time recording profile. And it should already work. I have changed the UI component of my "On call counter for week" time type group to "yes" in order to show you the result of the collector in the time sheet (you would not normally do this in production system):
I have recorded on 4 days on call times. The counter shows you 0:04 as a sum of the counter in the week (we are working on showing the counter in a neutral format, not in hh:mm ;-)).
And you can see this also in our time sheet trace:
So, you have got your counter. But what use is it of? Up to now it is only a further time valuation result. But you have seen in new feature 1 (described above) that this result can be used for error processing. So when you want to raise an error as soon as the employee records more than two days per week on call times, you combine the new feature 1 with the collector.
How does this look like?
You need a further time valution rule that consumes the counter and creates an error message when the value is above 2. Hence you need first another time type group that you can use as tool to create the error:
This is more or less only an empty time type group for the error processing, unfortunately it is necessary due to processing reasons.
Now you create a time valuation rule that checks our counter against a threshold of 2 using the valuation method "Aggregate input groups and split". This rule sums the daily detected events per time sheet week and compares the value against the threshold. Please note, that you need to choose here the time valuation method "valuate whole sheet" in order to get all the detected single day events in the whole week.
It is admittedly not that nice that you have assign the above mentioned dummy-time type group into the time type group above parameter that the error can be created, but this is how it works.
And this is the result when you record more than 2 on call times per week:
So, you have seen how it is possible to raise error messages in the time sheet (new feature Error messages in time sheet based on time valuation results) combined with the new valuation method Counting events.
Nice thing, the counters. You could even get the idea of why not using it for reporting purpose. When you want for example report on early shifts performed by employees in a month. Or when you want to check the occurence of recorded work on Sunday in a month (not more than 3 times for example). Check also the step-by-step example given on help.sap.com that you can find when you search for "Count events". There you find what you need to set up when you want to check that on call times (or any other times) recorded on Sundays may not exceed the occurence 2 per month.
Wait.
Per month? And using counters for reporting?
Time sheet was capable so far only to valuate a day or the weekly time sheet period. How can this now be done for a month? And are other periods possible? And reporting needs data stored on the database. However, the counters are not really stored, but only calculated on the fly. How can this then be achieved? Let me introduce you for this our next new feature, our Time Collectors:
I hope you are still fully with me. If not, take a break and a coffee. Cause for the following I need your full attention, it gets again a bit tricky. Especially to understand the difference of a counter and collector and there is even the possibilty of a counter that is a collector (okay, I stop now) and when to use what best:
I gave in my previous blogs already a kind of sneak preview on the counters and this time I really can announce: we finally made it. The first version of our "Time Collectors" has been released. This is by far the most important topic in our Q3 release. But I have to say already in the beginning: the time counter have not yet their full functionality and flexibilty. But we started to provide the basic principle of it.
As you might know the Time Sheet can only consider times / calculations within the actual time sheet week. But there are time valuation requirements where you need to consider times that span a time sheet. Sometimes a month, 13 weeks, bi-weekly, yearly and so on. Examples of this calculations would be:
You learnt that latter example is possible without the "collectors" (see above). And you learnt that not only hours can now be calculated, but also "events counted". These two features are independent from the Time Collectors, but are based on the developments and architectural changes we did for the development of the Time Collectors. But please be aware that with the first version of the time collectors not all of the above mentioned use cases can be covered. They are only examples for more complex calculation needs. As always for complex things: we ship first a basic version that gets in the subsequent releases enhanced with more functionality.
So, what the heck are Time Collectors, what are they good for and how can you configure and use them?
In a nutshell: time collectors collect data for valuation purpose and for database storage purpose.
"Valuation purpose" means in this release currently only generating of error messages. Furthermore due to the fact that the values are stored on the database reporting can pick them up easily.
You may say: this is it? This is all the collectors do? Generating error message and for reporting? Yes indeed, the usage of the collectors is in the first release limited. And you saw in the described feature above that generating of errors is even possible on daily / weekly basis without the need of a collector. So where exactly is the benefit of the collectors now?
First: you can generate errors on a period different than the time sheet period. Currently only month and week is supported.
Second: As already mentioned the most important thing in this release is that we laid the basis for further enhancements. We established now the architecture of calculating and storing these things real time, we got now the technic of the collectors, we got now its fundament and we can add more features in the future to them. I will write a bit on the future plans on collectors further below.
Third: the possibility to report on data that is up to now not stored. Compared to SAP ERP Time with its Clusters B1 and B2 we don´t store that much on the database. We are cloud. Times are changing. We focus on calculating everything on the fly and store only little data. But business processes of course need for some things the storage and now you can define what is stored on the database - which is very helpful for reporting.
For those of you who are rather familiar with SAP ERP Time it might help in explaining the collectors with an analogy to this system. When you have implemented SAP ERP Time you know the technical time types in table T555a very well. They were the main mechanism in SAP time valuation and you could set up a periodicy for them and decide if they are stored or only available during the time valuation run. If the value shall be forwarded to the next day and if results shall be stored on the database. See, we got something similar when you regard our time type groups with the new collector parameter.
And where exactly is the difference to the already described new feature "Error message in time sheet based on valuation results" described above?
But lets have a look on the Time collectors in detail and what you can do with them today - and how you configure them. Maybe first some practical business examples that show where you can use time collectors in this August release. This gives hopefully a better picture of this rather abstract topic.
Time Collectors come into the game:
I think the principle is clear: time recordings (or to be precise: time type groups) can be collected on a daily, weekly, monthly basis and can be compared with a threshold. When the threshold gets passed an error can be generated. On top each collectors value is stored in the database. Hence you can use the result of a collector also for reporting.
So, what about the configuration of the collectors? How can you set them up?
Again, we use our time type groups as basis for the collectors. A new parameter is added to the time type group that defines a time type group as "collector". When this is done, you need to define the periodicity of the collector. You can choose (in this first release) among:
- daily
- weekly
- monthly
When you choose "weekly" you need to set a start day of the weekly time collector (like Sunday, Friday, Wednesday....). Please note that this start day does not need to be the same day like the time sheet period start day (which you configure under Time Sheet Period) which is used for first day of week display and a weekly overtime calculation. The collector can differ from this period. Time Sheets first day could be Monday, but you want to count weekly from Wednesday to Tuesday specific things. Admitted, there might be only few occasions where you need this cause normally you count within the same period than the time sheet period, but I am long enough into time that only few strange requirements surprise me any more ;-). If you don´t need this feature, forget it. But you never know... And when we provide in subsequent releases more flexibility in the period definition we need anyhow a kind of start date (for example counter shall start biweekly each wednesday). I stop on this now, cause otherwise this might lead to knots in the brain.
But important to remember: when you don´t need to store the collector value on the database due to reporting requirements and only want to perform validations within the "normal" time sheet period to generate errors, you don´t need to configure a collector!
So, back to the set up of collectors. Basic configuration is done. You labelled it, defined it as collector and have choosen the periodicity. You got a time collector set up ;-). When using it the collector collects and when the periodicity of the time collector reaches its last day the collector gets automatically set to zero and is ready to receive data for the next periodicity.
But now the crucial question is: how to fill the collector? And how to define actions once a specific threshold has been reached?
The good thing about the time collectors is, that they are designed the same way as the already known "Time type groups". Hence all valuation types that already exist can be used to fill a time collector type. You can use already existing or new time type groups and apply all existing time valuation types for the collector calculation. You can use "Aggregate Input Groups and Splits"; "Filter Input Groups"; "Filter Segments from Input Groups"; "Difference from Input and Threshold". The collector works with the same already known principle with the "above" and "below" concept.
So essentially for a time collector you can apply all the conditions that are available with the already existing time valuation types to decide if the collector / counter shall be filled or not. If for example an event shall be counted or a collector filled only when the employee has worked minimum hours of 4 on each day you can do this with for example the method "aggregate input groups and split" and a check against a fix threshold of 4 hours.
Other examples for a condition to fill collectors would be the filter segment from input groups: you can fill a collector with recorded hours only when an employee records on call times on a Sunday (or non-working day). And only between 12:00 - 18:00 for example. Or you can create a collector only based on the overtime hours the time valuation has calculated. So, not the recorded times are relevant in this example, but the calculated times. You see, very flexible.
Lets look at one concrete example in more detail with screen shots which hopefully makes this topic more transparent (you can find this and other examples with set up in our documentation on help.sap.com, too):
You want to throw an error message in the time sheet when the time sheet calculates real time more than 20 overtime hours per month (and hence block the employee from further time recording).
First we need the definition of the collector itself. You need to define a time type group with time collector = yes and the periodicity monthly.
Second we need a time type group that works as a filter for 20hours on which later an error message can be created:
Now we need a time valuation rule that checks for each day the input time type group "Calculated overtime" (assuming you have created one beforehand that gives you this). The hours therin are put via the rule (time type group above for the hours above threshold 0) into the monthly collector "Overtime hours per month". We use for this the "aggregate input groups and split" valuation type. When there is a value above 0 in the input time type group all the hours are put into the "time type group above" where we maintained our collector. "time type group below" is not relevant here, cause we want to have all overtime hours in the collector.
So, what would the result be so far? Not much. We collect each day the calculated overtime hours (when there are any) and sent them to the collector. The collector would increase and increase for each day in the month were overtime was calculated. At the end of the month the collector would be set automatically to zero to have a clean start on the next month. Hence something is missing. We wanted to have an error in the timesheet. We need to add a second valuation rule that creates the error:
This rule compares upon each time recording if the collector (stated in the "Input time type group") has reached the value 20. When yes, then the hours above are put into the "Overtime more than 20 hours per month" time type group. You need to assign this time type group to the attribute "time type group above". You also need to set the error flag (which is triggered when there is a value in the time type group above) and you can indicate the text of the error in the Error Message field. The error type must be "error" cause currently "warnings" are not yet supported.
Result is then that when an employee records his time in the time sheet and there is once a point within a month where time valuation calculates all in all more than 20 hours overtime per month you get an error in the time sheet:
And you can do this with all kind of calculated / recorded time type groups. The time type group concept is very flexible and allows you many things. Not only can you apply the filters to collect only times within a specific time frame or on specific weekdays / public holidays, but you can also weigh time types with a factor. For example you can built a collector to check that employees do not have got productive working time in a month / week more than 200hours / 50 hours. But travel time does count only 50%, so for 1 hour recorded travel time the collector shall count only 30minutes. This is possible, too. You can use the "factor" parameter for a time type group when setting up the time valuation rule. See here:
This is it, hope you learnt the difference between a counter and a collector, when to use collector as opposed to "normal" time type groups and how to set them up.
One sad thing is: we did not manage to bring in the August release a nice UI in the time admin workbench where you easily can check the collectors values. But engineering team is already working on this UI and we hope to get it ready for the November release. This UI will be put into the time admin workbench. For now the only possibility to see the values of the counter is via the time evaluation trace (you need to switch this feature on for the role of the time administrator in the permissions section).
Future plans for time collectors:
I need to mention here that all I write on future plans is subject to change and does not define any official comittments and you should not rely in your decision making on product buy on the following outlook. Things can change, priorities can change. Take this as my personal wish list ;-).
You saw that we laid the foundation for new valuation possibilities with our collectors. I would be very happy to enhance the time collector functionality in near future with following:
These are only some ideas. The foundation is laid. I´ll keep you informed on the collector enhancements.
Last but not least I need to mention one hard limitation: due to the fact that the collectors are stored on the database what consumes performance and storage place we put initially an amount limitation onto the collectors: you cannot assign more than 13 different collectors to a time recording profile. So please make up your mind when creating the collectors what you really need. And remember: you don´t need a collector for each and anything. All daily checks / weekly checks where time data needs to be summed up can be done without a collector. Only when you want to store values on the database for reporting purpose or when you have got monthly calculations you need a collector right now.
This is a new valuation type that adds more functionality to our time valuation. I have written an extra small blog with practical business examples on this:
https://blogs.sap.com/wp-admin/post.php?post=538373&action=edit
You might know that in Europe and US there is a complete different time account entitlement / accrual philosophy. Unlike in Europe employees in US never get the full yearly vacation amount entitled at the beginning of the year. They rather get each month an accrual. In most countries in Europe employees get the full years entitlement posted and fully available already on 1st January (or even earlier, to allow in December to request already skiing vacation for January).
Hence when it comes to the remaining balance display in the EC Time leave request there are different requirements to meet based on the accrual / entitlement difference. Up to today a quite simple logic was implemented: display of the balance based on a key date. Default was todays date or when you enter a vacation then this date was the key date. In Europe however you don´t want see the remaining balance only as of today, but by default till the end of the time account validity (usually years end) and recorded vacations till that date already deducted. You don´t want to use the cumbersome "balance as of..." selection in the leave request user interface and set it till end of year to get information on your overall remaining balance. Hence, a configuration option was necessary. You can now choose if you still want to use the existing logic or use the new logic. In simplified words: The new logic sums up all accruals and deductions of a time account and shows the delta.
So for a standard time account in Germany where you get 30 days at the beginning of the year, 5 days vacation are recorded in January, 10 days vacation already in advance for december and I open the UI today in August I get a remaining balance of 15 days.
When there is a monthly accrual of 2 days per month, 5 days vacation are recorded in January, 10 days in december and I open the UI today (August) I get a balance of: 11 days (8x2 minus 5. The absence in the future is covered by the future accrual). When I open the UI in September it would still be 11 days although I have received another 2 days accrual in the beginning of September - due to the fact that the absence in december is covered by the future outstanding accruals. But these are already consumed by the vacation record that is recorded for december.
All clear? Most important take away: a configuration possibility is now introduced to cater better for european remaining balance calculations requirements.
Please not that you do this configuration on the time type level, not on the time account level. Hence the balance display on the time account overview is not changed, only the display of the value in the boxes you see above. But this is where each employee looks at.
The configuration of this feature looks like this:
In some countries in Europe working time accounts (flex time accounts) are very common. Please check my previous blog posts where I have explained the concept of working time accounts.
Due to the fact that this information is important for an approver we enhanced the time sheet approval list with the information on the working time account balance. Hence not only recorded and planned times are shown, but also the actual working time account balance. When an employee does not have a working time account assigned in his time recording profile you won´t see this entry at all. Looks like this:
Lets come to the next topic:
You know that we have got "recurring" time accounts and "permanent" time accounts. For recurring time accounts a new time account instance is created automatically upon the end of the previous time account. Well, to be precise, not automatically but via the time account calendar runs. The recurring frequency could for example be monthly or yearly. "Permanent" time account don´t have got a recurrence or an end date. They exist ongoing as long as the employee got the corresponding time profile.
The new feature is only relevant for recurring accounts:
The new start date of a recurring time account could up to now only be set to the hire date or to a fix date, like for example 1.st March. With the new feature we add much more flexibility. You can now use as recurring time account start date each and any date field in the employees job information- even a custom field. This allows for example to let the recurring time account start on the employees aniversay date or even on his birthday. Yes, there are countries and customers that need this functionality. To do this you need to assign a business rule to the time account type. In the business rule you can choose each date field - or even a custom date field. The value is then passed to the time account upon time account creation with the calendar runs.
But having only this new start day would of course not be sufficient. This date can also be picked up by the accrual engine and perform a monthly accrual on this date.
Good news for our customers in Mexico: they can now link illness records the same way as already provided for Germany and Spain. And in addition we provide a country specific field where a so-called "reference number" can be entered. This number is important for further HR related processes in Mexico. The reference number comes in Mexico from the health insurances and must be available in the payroll process, too. This is why we also incorporated this field into the replication to EC Payroll into the infotype 2001 Absences for Mexico. Prerequisite is that you choose the illness category for your time types and then you can link them. EC payroll can then do its further processes based on the reference number recorded in EC Time.
This is it. These were the new features of the August 2017 release. I hope you can use them in your implementations / projects. Follow my blogs and you will learn on next releases features once it is released.
Enjoy the rest of the summer.
Volker Ruof
Product Manager Employee Central Time and Attendance Management
me again, writing from Sankt Leon Rot, Germany, during late summer times some words on the new feature and functions of our EC Time and Attendance Management product (this is the official name, but please allow me to simply call it "EC Time"). Trying to give you useful updates/insights on the development and our plannings and some hints and tips for configuration of our new features.
Let me give you first an overview on the most important features in this release. Our engineering team has developed for you:
- Possibilty to generate error messages in the time sheet based on time valuation results
- Introduction of new time valuation type: "counting events"
- Time Collectors
- New time valuation type "Route input"
- Configuration option for the display of the remaining time account balance
- Display of working time account balance in the approval workflow Ui
- Flexible start day for recurring time accounts
- Possiblity for mexican customers to link illness records and assign a reference number to illnesses
Lets directly jump into it. Unfortunately this will be most probably a little deep dive into the time valuation and won´t probably be understood easily by EC Time newbies. But don´t let this daunt you. When you take away the basic ideas and learn roughly what is possible in our time valuation I am already happy. Take the implementation guide, play with the system and you will learn quite fast.
The first new feature is a very useful one. Especially, when you want to ensure that employees meet working time regulations upon time recording:
1. Error messages in time sheet based on time valuation results
Cryptical heading. What is meant with this?
In Europe and elsewhere in the world there are working time laws - or guidelines - dealing with the maximum duration of working time per day / week of employees. Laws and guidelines are always a big topic for interpretation in time management and I often had customers same branch, same trade union contract, same region but yet doing time management completly different. But one thing can be found often: customers want to have a maximum duration of time recording. Be it due to laws / guide lines, be it due to the fact that they don´t want to pay overtime payments.
To cater this requirement we provide now error message generation in the time sheet. You could say, wait! There was two releases ago the introduction of business rule availabilty in the time sheet that can be used for error processing, and now we provide something similar in the time valuation. Why this?
Reason is quite simple: Some validations where you need to perform calculations can´t be done in the business rules at all. Additionally business rule performance is quite slow, time valuation is much more faster. But there are still occasions where you need to apply business rules. A business rule is probably easier configured than a validation rule (cause most people know the business rules, but only few know the time valuation rules) and there are constellations that you can´t query in the time valuation rule. Allowances can´t be consumed in time valuation. So when you have got the need for errors around allowance recording (no allowance on an off day; allowance only when a specific working time type is recorded on this day, too; allowance not or only when a specific absence exists for the same day....) you should still use the business rules. More complicated validations (like checking the time sheet period, month, or create sums / calculations) are not possible in the business rule. For this you should always use the new time valuation error possibility.
What are more complex checks? Quite easy:
Take the example of maximum allowed 10 hours of working time on day. This could be covered with business rules by checking a time type and 10 hours. Works. But when it gets a bit more tricky the rules don´t work. When employees record for example two records with "working time", one 5 hours and the other 6 hours the business rule does not give an error. Condition not met. You can´t do summarization in the business rules. Or when an employee records 8 hours working time and 3 hours another attendance time type like travel time: no error. Condition not met. You can always check in the rules only 1 time type and not doing a collection. Or when your employees record times with start / end time and you have an automated break deduction configured. Employee records from 08:00 - 18:30 (10.5 hours), but time valuation deducts a recorded (or automatically generated) break of 1 hour. The rule will give you an error although the net working time of the employee was only 9.5 hours. But the 9.5 hours can only be calculated by time valuation.
This is why we enhanced our time valuation with the possibility to generate errors.To enable you validate more complex constellations and trigger errors on this.
You can now define an automated error generation that blocks the time sheet for further time recording when the time valuation calculates more than xx hours per day or more than xx hours per week. What this calculation contains, is completly up to you. The configuration possibilites are very flexible. You can add several time types, deduct breaks and recorded absence times. You can furthermore raise errors not only based on hours, but also on "events". This means when an employee records more than 3 times (hence, not hours, but events!) on call times in a week. Very flexible. How is this flexibility achieved? We use the already established concept of "time type groups". When you are not familiar with this term, please conduct the time sheet implementation guide that you can find on help.sap.com, book Employee Central; Payroll Time Sheet, cause understanding of this time type groups and the time valuation rules are essential for configuring the time valuation.
Lets have a closer look.
You can define time type groups that are a kind of calculation bucket. In the time valuation rules you assign input time type groups, apply time valuation rules on it and you get most often a value "below" and a value "above". I always imagine to myself the time valuation rules as a kind of funnel where you pure a liquid (input time type groups) into it. The processing of the rule is when the liquid tries to pass the funnel. In the upper part of the funnel the things that did not pass are remaining (bigger items in the liquid than the condition set). The hours of the "gooey liquid" are put into the "above" time type group that is defined in the valution rule. The thinner liquid is meeting the conditions and can pass the funnel and are put to the "below" time type group. I am not that logically minded as our software architects, this is why I am a product manager ;-). But this kind of pictures help me understand how the things work.
An example: you have an input time type group "recorded attendance times". You assign all possible attendance time types (working time, travel time, training, works meeting...) to this group in the definition of it. Now you use a time valuation rule. You check against a fix value of 50 hours per week (or you even can use a calculated threshold that you have created earlier, like for example scheduled working time containing the sum of planned hours of the employee). When the valuation method is set to "daily valuation" only the value of the time type group of this day is checked against the threshold. But when the valuation method is set to "whole sheet" than the whole time sheet period is processed real time. So, in this example the input time type group "recorded attendance time" would be checked upon each time recording if in the time sheet period the value is greater than 50. If yes you would have a value in the "above time type group". If no you would have the calculated value in the "below time type group". Both values are available "fluently", not stored in the database in the actual time valuation run for further calculations (if you need them). You don´t always need to set an entry in both fields above / below. Many times like for the check on 50hours per week you don´t need an entry in the "below time type group". But important: these data is not persisted on the database. It is all on-the-fly calculation. So, up to now nothing new. This is all how time valuation has worked in the past already.
Here comes the new feature:
You can now trigger an error when the time valuation processes a value into the "above time type group" or even into the "below time type group". And you even can define the error message text. In our example: when an employee records over the week more than 50 hours attendance times the time valuation rule sends the hours above 50 to the "above time type group". Once there is a value in it the condition is fullfilled and the error message gets created for the time sheet user interface and the employee can´t save the time sheet. In fact, the error is thrown immediatly with the time recording and not only upon save.
What do you need to configure this? See some screenshots that illustrate this:
First you need a kind of technical time type group where the value "above 50" can be sent to by time valuation. It is rather a dummy container needed for technical reasons. So we create one:
Now you need to create a time valuation rule that validates the whole time sheet. You need choose as input time type groups what you want to check. In my example I use 2 calculated input time type groups. One where in another time valuation step the recorded attendance times have been subtracted by recorded or scheduled breaks. Cause I don´t want to check only the recorded net times, which means attendance times minus breaks. In addition I put as another input time type group a group where in previous time valuation steps paid absence times (again less breaks) have been collected and calculated. Cause when my employee is 4 days on vacation and records 12 hours on the fifth day I want to have this constellation checked against the 50 hours, too. Absences are not worked time, sure, but for me they are "paid times" hence I include them into the check. But this is now a flavour that varies from customer to customer and that you need to clarify in your project: shall absence times be incorporated in this weekly check or not. But thanks to our engineering team - you can configure all variants you want to have to.
The time valuation rule looks like this:
The new thing now is that you can set an error flag an that you can define the error message text. The rule does following: it sums up the input time type groups in the whole time sheet period and compares it with a fix threshold 50. Is the sum bigger than 50 than everything beyond the threshold is put into the time type group stated in the "time type group above" field. And here I assigned exactly the dummy-time type group created earlier. The error is processed and the message text displayed in the time sheet User Interface when there is a value in this time type group. Looks then like this:
You can use our really good time valuation trace in the implementation phase to check what the time valuation has calculated per day in detail. Screenshot below. You see in this trace that not the recorded times 08:00 - 17:00 (I call them "gross times" or "raw recorded data") are taken for the valuation, but the attendance times minus the automated generated breaks. This is due to the input time type group I have choosen in my valuation rule. Cause the employee records in my example each day working time from 08:00 - 17:00, less 1h break per day. Sums up to 40 hours from Mon-Friday. Now on Saturday he records from 08:00 - 19:00 working time. Here no break deduction is applied (cause no break defined or recorded for this day). 11 hours are added to the 40 hours. Sum is 51. We have used a valuation rule with the valuation type "aggregate input group and split" and we defined a threshold of 50, all above shall be put to the time type group "Group for 50h check". And here we go, this is exactly what you see in the trace result: 1 hour has been put by the calculation mechanisms into this time type group. And hence in this time type group is a value other than 0, the condition for the error is met and the error message generated:
Wasn´t that complicated, was it?
Of course this works also for all daily error checks. Then you simply don´t use the parameter "whole sheet" valuation in the valuation rule, but set it to "daily valuation".
And the flexibility of the input time type groups allow all our time valuation types to be applied in order to calculate the "output" time type group (the above/below thing) for the valuation rule that generates the error. You could for example use the "filter and split" options to collect only those times recorded on a specific weekday, before (or after) a specific clocktime. When you for example want to prevent that employees record on days with planned times after 20:00 o´clock times, you can use the filter options. All times after 20:00 are sent to a specific time type group. This group is used as an input time type group for the next valuation rule where you check if there is a value above 0. The result is put into the "above time type group" and then you can process your error message.
Currently we unfortunately support only error messages in the user interface with this feature. But on my wish list is that we also can generate warning messages. And that you will be able to define if a warning is generated for an employee and / or send to a time administrator. You would then be able to sent warnings to a time admin when an employee has performed more than 10 overtime hours per week, when he has recorded less hours than his planned times, when he has recorded working time after the start time of his workschedule, when the working time account balance reaches a specific threshold and so on. But these are currently only ideas for future releases and not yet build.
2. New time valuation type: Counting events
Now let me add some more complexity, or positively formulated, flexibility 😉
Our time valuation calculated up to now only with the unit hours. But very often, customers don´t need hours but count occurences to trigger an error message. For example an error when an employee records more than 4 times a week on call times. Or the occurence per week where an employee starts to work later than 10:00 in the morning. You are not interested in the hours of the recording, but only on the number of the event.
This can now be done with a new time valuation calculation type called:
Compare Threshold with Input Groups and Count Events
When you use this valuation type basically not hours are counted / collected, but the value 1 with the daily valuation. Afterwards you can sum up this events in the time sheet week (via valuate whole sheet) to find out if more than 4 times on call times are recorded. If yes, error, if not: fine.
And again: due to the flexibility of the time type groups you can apply all the other valuation types to process the calculation and set conditions when the event shall be counted. You can use the filter options to count times only on a specific weekday, on days with or without planned times, after a certain clock time (on calls after 18:00 for example) or on working days with a specific shift class.
Lets have a look on a more simple example. You want to ensure that employees do not perform on call times more often than 2 times a week.
You need first a time type group that works as "input time type group". You assign the time type "on call" to this group. The time type is what the employees records in his time sheet.
Now you need to create another time type group that works as counter. You need to use as "Time Category" the entry "Counted events". This is your vehicle with which the events are detected. Looks like this:
Now you have got your input time type group, your container (I am deliberately not using the term "collector", cause we also build a new feature "time collector" as you see in the next chapter and which are technically something different. Even I had hard times in understanding the difference ;-)) to sum up events. And finally you need a valuation rule that actually performs the counting. And here we need to use the new valuation type "Compare threshold with Input Groups and Count Events". Looks like this:
The rest should be know: you check against a fix value of 0 and you use the "time type group above" parameter to write the result of the valuation rule into your counter "On call counter for week" time type group. You need to use here "Valulate per day", cause when you use "valuate whole sheet" the result for the overall time sheet would be 1, regardless on how many days an on call time is recorded. The valuate per day ensures that on each day where on call times are recorded 1 is added to the counter (and here it does not matter if an employee records this timetype twice or often per day. When the condition is met 1 is counted).
You assign this rule to your time recording profile. And it should already work. I have changed the UI component of my "On call counter for week" time type group to "yes" in order to show you the result of the collector in the time sheet (you would not normally do this in production system):
I have recorded on 4 days on call times. The counter shows you 0:04 as a sum of the counter in the week (we are working on showing the counter in a neutral format, not in hh:mm ;-)).
And you can see this also in our time sheet trace:
So, you have got your counter. But what use is it of? Up to now it is only a further time valuation result. But you have seen in new feature 1 (described above) that this result can be used for error processing. So when you want to raise an error as soon as the employee records more than two days per week on call times, you combine the new feature 1 with the collector.
How does this look like?
You need a further time valution rule that consumes the counter and creates an error message when the value is above 2. Hence you need first another time type group that you can use as tool to create the error:
This is more or less only an empty time type group for the error processing, unfortunately it is necessary due to processing reasons.
Now you create a time valuation rule that checks our counter against a threshold of 2 using the valuation method "Aggregate input groups and split". This rule sums the daily detected events per time sheet week and compares the value against the threshold. Please note, that you need to choose here the time valuation method "valuate whole sheet" in order to get all the detected single day events in the whole week.
It is admittedly not that nice that you have assign the above mentioned dummy-time type group into the time type group above parameter that the error can be created, but this is how it works.
And this is the result when you record more than 2 on call times per week:
So, you have seen how it is possible to raise error messages in the time sheet (new feature Error messages in time sheet based on time valuation results) combined with the new valuation method Counting events.
Nice thing, the counters. You could even get the idea of why not using it for reporting purpose. When you want for example report on early shifts performed by employees in a month. Or when you want to check the occurence of recorded work on Sunday in a month (not more than 3 times for example). Check also the step-by-step example given on help.sap.com that you can find when you search for "Count events". There you find what you need to set up when you want to check that on call times (or any other times) recorded on Sundays may not exceed the occurence 2 per month.
Wait.
Per month? And using counters for reporting?
Time sheet was capable so far only to valuate a day or the weekly time sheet period. How can this now be done for a month? And are other periods possible? And reporting needs data stored on the database. However, the counters are not really stored, but only calculated on the fly. How can this then be achieved? Let me introduce you for this our next new feature, our Time Collectors:
3. Time Collectors
I hope you are still fully with me. If not, take a break and a coffee. Cause for the following I need your full attention, it gets again a bit tricky. Especially to understand the difference of a counter and collector and there is even the possibilty of a counter that is a collector (okay, I stop now) and when to use what best:
I gave in my previous blogs already a kind of sneak preview on the counters and this time I really can announce: we finally made it. The first version of our "Time Collectors" has been released. This is by far the most important topic in our Q3 release. But I have to say already in the beginning: the time counter have not yet their full functionality and flexibilty. But we started to provide the basic principle of it.
As you might know the Time Sheet can only consider times / calculations within the actual time sheet week. But there are time valuation requirements where you need to consider times that span a time sheet. Sometimes a month, 13 weeks, bi-weekly, yearly and so on. Examples of this calculations would be:
- You let the system automatically generate a monthly 2 days vacation accrual only when they have worked more than 20 days in a month. Whereas "worked" could mean that you also count specific absences (illnesses = yes, vacation = yes, but not unpaid vacation) into the "collector" that counts the working days.
- You got a 13 weeks, 2-weeks or a monthly overtime calculation period
- You grant an additional payment when an employee works more than 100 early shifts in a year, or your premium pay for each consecutive early shift is higher than those below 100 worked
- When an employee performs more than 5 times on call times on Sundays within 3 months he gets a higher payment for the on call times
- You want not to allow emloyees record more than 180hours per month, perform more than 20 Overtime hours per month and so on.
- You want to raise an error message when an employee works more than 50 hours per week
You learnt that latter example is possible without the "collectors" (see above). And you learnt that not only hours can now be calculated, but also "events counted". These two features are independent from the Time Collectors, but are based on the developments and architectural changes we did for the development of the Time Collectors. But please be aware that with the first version of the time collectors not all of the above mentioned use cases can be covered. They are only examples for more complex calculation needs. As always for complex things: we ship first a basic version that gets in the subsequent releases enhanced with more functionality.
So, what the heck are Time Collectors, what are they good for and how can you configure and use them?
In a nutshell: time collectors collect data for valuation purpose and for database storage purpose.
"Valuation purpose" means in this release currently only generating of error messages. Furthermore due to the fact that the values are stored on the database reporting can pick them up easily.
You may say: this is it? This is all the collectors do? Generating error message and for reporting? Yes indeed, the usage of the collectors is in the first release limited. And you saw in the described feature above that generating of errors is even possible on daily / weekly basis without the need of a collector. So where exactly is the benefit of the collectors now?
First: you can generate errors on a period different than the time sheet period. Currently only month and week is supported.
Second: As already mentioned the most important thing in this release is that we laid the basis for further enhancements. We established now the architecture of calculating and storing these things real time, we got now the technic of the collectors, we got now its fundament and we can add more features in the future to them. I will write a bit on the future plans on collectors further below.
Third: the possibility to report on data that is up to now not stored. Compared to SAP ERP Time with its Clusters B1 and B2 we don´t store that much on the database. We are cloud. Times are changing. We focus on calculating everything on the fly and store only little data. But business processes of course need for some things the storage and now you can define what is stored on the database - which is very helpful for reporting.
For those of you who are rather familiar with SAP ERP Time it might help in explaining the collectors with an analogy to this system. When you have implemented SAP ERP Time you know the technical time types in table T555a very well. They were the main mechanism in SAP time valuation and you could set up a periodicy for them and decide if they are stored or only available during the time valuation run. If the value shall be forwarded to the next day and if results shall be stored on the database. See, we got something similar when you regard our time type groups with the new collector parameter.
And where exactly is the difference to the already described new feature "Error message in time sheet based on valuation results" described above?
- Time collectors are needed when you want to perform calculations other than a day or time sheet week. In the August release only the periodicity month is supported. But more flexibility here is planned for future releases. In addition when you use the weekly periodicity you can define the start day of the week for this collector. And calculation here means currently only creating error messages.
- Time collectors are necessary when you want to report specific things that is not available in normal reporting. When you want a report on recorded times versus planned times per month. You need to create monthly collector for both values. The hours are summed up and stored on the database, hence reporting can pick them up.
Or when you want to report on late coming of employees on Monday mornings which could not be supported up to now in reporting. But you can create a time collector that counts this event and stores it on the database. You need to create a counter event when the recorded times are after a specific clocktime. If yes, a counter is created based on the new valuation type "counting events" and the result send to a time type group that is marked as being a collector. And you can report on it, cause collector values are stored on the database. - Time collectors are necessary when you want to create key figures for a time admin. Like number of recorded travel time in a month (or later other periods), number of performed overtime, Illness days.....These figures are planned to be visualized in a dedicated time collector overview UI for a employee (planned for November release). In future releases we could also think on bringing these figures in a combined way on a managers home page.
But lets have a look on the Time collectors in detail and what you can do with them today - and how you configure them. Maybe first some practical business examples that show where you can use time collectors in this August release. This gives hopefully a better picture of this rather abstract topic.
Time Collectors come into the game:
- when you want to raise an error message when an employee records more than 180 hours per month
- when you want to raise an error when an employee comes more than 4 times too late too work in a month
- when you want to control the weekly (or monthly) recorded times compared with the planned times
- when you want to raise an error when an employee records more than 3 times a month on a Sunday and / or any other non-working day "On-call times"
- when you want to get a list of employees (or an erorr) working more than 10 nightshifts per month
- when you want to get a list of employees (or an error) recording more than 20 hours or 5 times on call times
I think the principle is clear: time recordings (or to be precise: time type groups) can be collected on a daily, weekly, monthly basis and can be compared with a threshold. When the threshold gets passed an error can be generated. On top each collectors value is stored in the database. Hence you can use the result of a collector also for reporting.
So, what about the configuration of the collectors? How can you set them up?
Again, we use our time type groups as basis for the collectors. A new parameter is added to the time type group that defines a time type group as "collector". When this is done, you need to define the periodicity of the collector. You can choose (in this first release) among:
- daily
- weekly
- monthly
When you choose "weekly" you need to set a start day of the weekly time collector (like Sunday, Friday, Wednesday....). Please note that this start day does not need to be the same day like the time sheet period start day (which you configure under Time Sheet Period) which is used for first day of week display and a weekly overtime calculation. The collector can differ from this period. Time Sheets first day could be Monday, but you want to count weekly from Wednesday to Tuesday specific things. Admitted, there might be only few occasions where you need this cause normally you count within the same period than the time sheet period, but I am long enough into time that only few strange requirements surprise me any more ;-). If you don´t need this feature, forget it. But you never know... And when we provide in subsequent releases more flexibility in the period definition we need anyhow a kind of start date (for example counter shall start biweekly each wednesday). I stop on this now, cause otherwise this might lead to knots in the brain.
But important to remember: when you don´t need to store the collector value on the database due to reporting requirements and only want to perform validations within the "normal" time sheet period to generate errors, you don´t need to configure a collector!
So, back to the set up of collectors. Basic configuration is done. You labelled it, defined it as collector and have choosen the periodicity. You got a time collector set up ;-). When using it the collector collects and when the periodicity of the time collector reaches its last day the collector gets automatically set to zero and is ready to receive data for the next periodicity.
But now the crucial question is: how to fill the collector? And how to define actions once a specific threshold has been reached?
The good thing about the time collectors is, that they are designed the same way as the already known "Time type groups". Hence all valuation types that already exist can be used to fill a time collector type. You can use already existing or new time type groups and apply all existing time valuation types for the collector calculation. You can use "Aggregate Input Groups and Splits"; "Filter Input Groups"; "Filter Segments from Input Groups"; "Difference from Input and Threshold". The collector works with the same already known principle with the "above" and "below" concept.
So essentially for a time collector you can apply all the conditions that are available with the already existing time valuation types to decide if the collector / counter shall be filled or not. If for example an event shall be counted or a collector filled only when the employee has worked minimum hours of 4 on each day you can do this with for example the method "aggregate input groups and split" and a check against a fix threshold of 4 hours.
Other examples for a condition to fill collectors would be the filter segment from input groups: you can fill a collector with recorded hours only when an employee records on call times on a Sunday (or non-working day). And only between 12:00 - 18:00 for example. Or you can create a collector only based on the overtime hours the time valuation has calculated. So, not the recorded times are relevant in this example, but the calculated times. You see, very flexible.
Lets look at one concrete example in more detail with screen shots which hopefully makes this topic more transparent (you can find this and other examples with set up in our documentation on help.sap.com, too):
You want to throw an error message in the time sheet when the time sheet calculates real time more than 20 overtime hours per month (and hence block the employee from further time recording).
First we need the definition of the collector itself. You need to define a time type group with time collector = yes and the periodicity monthly.
Second we need a time type group that works as a filter for 20hours on which later an error message can be created:
Now we need a time valuation rule that checks for each day the input time type group "Calculated overtime" (assuming you have created one beforehand that gives you this). The hours therin are put via the rule (time type group above for the hours above threshold 0) into the monthly collector "Overtime hours per month". We use for this the "aggregate input groups and split" valuation type. When there is a value above 0 in the input time type group all the hours are put into the "time type group above" where we maintained our collector. "time type group below" is not relevant here, cause we want to have all overtime hours in the collector.
So, what would the result be so far? Not much. We collect each day the calculated overtime hours (when there are any) and sent them to the collector. The collector would increase and increase for each day in the month were overtime was calculated. At the end of the month the collector would be set automatically to zero to have a clean start on the next month. Hence something is missing. We wanted to have an error in the timesheet. We need to add a second valuation rule that creates the error:
This rule compares upon each time recording if the collector (stated in the "Input time type group") has reached the value 20. When yes, then the hours above are put into the "Overtime more than 20 hours per month" time type group. You need to assign this time type group to the attribute "time type group above". You also need to set the error flag (which is triggered when there is a value in the time type group above) and you can indicate the text of the error in the Error Message field. The error type must be "error" cause currently "warnings" are not yet supported.
Result is then that when an employee records his time in the time sheet and there is once a point within a month where time valuation calculates all in all more than 20 hours overtime per month you get an error in the time sheet:
And you can do this with all kind of calculated / recorded time type groups. The time type group concept is very flexible and allows you many things. Not only can you apply the filters to collect only times within a specific time frame or on specific weekdays / public holidays, but you can also weigh time types with a factor. For example you can built a collector to check that employees do not have got productive working time in a month / week more than 200hours / 50 hours. But travel time does count only 50%, so for 1 hour recorded travel time the collector shall count only 30minutes. This is possible, too. You can use the "factor" parameter for a time type group when setting up the time valuation rule. See here:
This is it, hope you learnt the difference between a counter and a collector, when to use collector as opposed to "normal" time type groups and how to set them up.
One sad thing is: we did not manage to bring in the August release a nice UI in the time admin workbench where you easily can check the collectors values. But engineering team is already working on this UI and we hope to get it ready for the November release. This UI will be put into the time admin workbench. For now the only possibility to see the values of the counter is via the time evaluation trace (you need to switch this feature on for the role of the time administrator in the permissions section).
Future plans for time collectors:
I need to mention here that all I write on future plans is subject to change and does not define any official comittments and you should not rely in your decision making on product buy on the following outlook. Things can change, priorities can change. Take this as my personal wish list ;-).
You saw that we laid the foundation for new valuation possibilities with our collectors. I would be very happy to enhance the time collector functionality in near future with following:
- having a nice User Interface for the time administrator to visualize the collector values for the employees (as mentioned, this is on the short term plan). This would allow a nice overview on the planned / recorded weekly or monthly hours in one collector to see the deviations for example. The time admin would get an overview on the time recording completeness then.
- using the collector values for the time account accrual engine (automated daily time account accrual based on the net working hours calculated in the time sheet for example)
- allow different collector periods than daily / weekly / monthly like for example yearly, 13 weekly, bi-weekly, monthly starting on day xx in order to provide for example more overtime calculation possibilities
- sending warning messages to employee and / or time admins once a collector reaches a threshold
- generating automatically a pay type once a collector reaches a specific value. Example would be: when an employee works more than 100 early shifts in a year he gets an additional bonus-payment. Or each consecutive early shift is paid higher.
- using the collectors to retrieve nice configurable key figures for managers and time admins
These are only some ideas. The foundation is laid. I´ll keep you informed on the collector enhancements.
Last but not least I need to mention one hard limitation: due to the fact that the collectors are stored on the database what consumes performance and storage place we put initially an amount limitation onto the collectors: you cannot assign more than 13 different collectors to a time recording profile. So please make up your mind when creating the collectors what you really need. And remember: you don´t need a collector for each and anything. All daily checks / weekly checks where time data needs to be summed up can be done without a collector. Only when you want to store values on the database for reporting purpose or when you have got monthly calculations you need a collector right now.
4. New time valuation type "Compare Threshold with Comparison Group to Route Input"
This is a new valuation type that adds more functionality to our time valuation. I have written an extra small blog with practical business examples on this:
https://blogs.sap.com/wp-admin/post.php?post=538373&action=edit
5. Configuration possibility of remaining leave balance display
You might know that in Europe and US there is a complete different time account entitlement / accrual philosophy. Unlike in Europe employees in US never get the full yearly vacation amount entitled at the beginning of the year. They rather get each month an accrual. In most countries in Europe employees get the full years entitlement posted and fully available already on 1st January (or even earlier, to allow in December to request already skiing vacation for January).
Hence when it comes to the remaining balance display in the EC Time leave request there are different requirements to meet based on the accrual / entitlement difference. Up to today a quite simple logic was implemented: display of the balance based on a key date. Default was todays date or when you enter a vacation then this date was the key date. In Europe however you don´t want see the remaining balance only as of today, but by default till the end of the time account validity (usually years end) and recorded vacations till that date already deducted. You don´t want to use the cumbersome "balance as of..." selection in the leave request user interface and set it till end of year to get information on your overall remaining balance. Hence, a configuration option was necessary. You can now choose if you still want to use the existing logic or use the new logic. In simplified words: The new logic sums up all accruals and deductions of a time account and shows the delta.
So for a standard time account in Germany where you get 30 days at the beginning of the year, 5 days vacation are recorded in January, 10 days vacation already in advance for december and I open the UI today in August I get a remaining balance of 15 days.
When there is a monthly accrual of 2 days per month, 5 days vacation are recorded in January, 10 days in december and I open the UI today (August) I get a balance of: 11 days (8x2 minus 5. The absence in the future is covered by the future accrual). When I open the UI in September it would still be 11 days although I have received another 2 days accrual in the beginning of September - due to the fact that the absence in december is covered by the future outstanding accruals. But these are already consumed by the vacation record that is recorded for december.
All clear? Most important take away: a configuration possibility is now introduced to cater better for european remaining balance calculations requirements.
Please not that you do this configuration on the time type level, not on the time account level. Hence the balance display on the time account overview is not changed, only the display of the value in the boxes you see above. But this is where each employee looks at.
The configuration of this feature looks like this:
6. Working time account balance display in approval list
In some countries in Europe working time accounts (flex time accounts) are very common. Please check my previous blog posts where I have explained the concept of working time accounts.
Due to the fact that this information is important for an approver we enhanced the time sheet approval list with the information on the working time account balance. Hence not only recorded and planned times are shown, but also the actual working time account balance. When an employee does not have a working time account assigned in his time recording profile you won´t see this entry at all. Looks like this:
Lets come to the next topic:
7. Flexible start date for recurring time accounts
You know that we have got "recurring" time accounts and "permanent" time accounts. For recurring time accounts a new time account instance is created automatically upon the end of the previous time account. Well, to be precise, not automatically but via the time account calendar runs. The recurring frequency could for example be monthly or yearly. "Permanent" time account don´t have got a recurrence or an end date. They exist ongoing as long as the employee got the corresponding time profile.
The new feature is only relevant for recurring accounts:
The new start date of a recurring time account could up to now only be set to the hire date or to a fix date, like for example 1.st March. With the new feature we add much more flexibility. You can now use as recurring time account start date each and any date field in the employees job information- even a custom field. This allows for example to let the recurring time account start on the employees aniversay date or even on his birthday. Yes, there are countries and customers that need this functionality. To do this you need to assign a business rule to the time account type. In the business rule you can choose each date field - or even a custom date field. The value is then passed to the time account upon time account creation with the calendar runs.
But having only this new start day would of course not be sufficient. This date can also be picked up by the accrual engine and perform a monthly accrual on this date.
8. Possiblity for mexican customers to link illness records and assign a reference number to illnesses
Good news for our customers in Mexico: they can now link illness records the same way as already provided for Germany and Spain. And in addition we provide a country specific field where a so-called "reference number" can be entered. This number is important for further HR related processes in Mexico. The reference number comes in Mexico from the health insurances and must be available in the payroll process, too. This is why we also incorporated this field into the replication to EC Payroll into the infotype 2001 Absences for Mexico. Prerequisite is that you choose the illness category for your time types and then you can link them. EC payroll can then do its further processes based on the reference number recorded in EC Time.
This is it. These were the new features of the August 2017 release. I hope you can use them in your implementations / projects. Follow my blogs and you will learn on next releases features once it is released.
Enjoy the rest of the summer.
Volker Ruof
Product Manager Employee Central Time and Attendance Management
- SAP Managed Tags:
26 Comments
