Hello EC Time fellows,
we are currently experiencing with Covid-19 changes no one of us experienced ever before affecting our lifes, the lifes of familiy members and friends, the way we work, the way we live and our daily routines. But yet there are some things that do not change. One is that Successfactors delivers a new release, the other is that I write a blog on the new EC Time Features coming with this release.
And this release there is really lots of good stuff in it for Time Management. You know that Successfactors has changed is release cylce from quarterly to bi-yearly. Hence there was much more time for the development team to develop new features. But we also increased our development man- (and woman) power for EC Time significantly. There are much more development teams now working for EC Time than ever before - and I bet that you will be as impressed as I am after reading through this blog on the tons of really good, big new EC Time features.
But the ability to provide now lots of new EC Time features with this stronger development power in a longer period means also that this blog is going to be longer. More features - more words needed to explain them. And what was in the past a short read through on the new features with some details and easy-to-understand example results now rather in a real effort to read all of this. The word-counter above says that you need to spend more than 30 minutes to read this - which is a lot. So, maybe you can give me some feedback in the comment section below if you still find this blog / channel useful or if it is now too long and too big to be consumed well.
But although the blog is going to be longer this time I stick to the usual pattern from my past blogs: I try as usual to find the balance in explaining the many new features in dedicated sections which you can read stand-alone and in a way that enough deep dive information is shared but also non-time experts understand what the new feature is about.
So, again, as always: fasten your seat belts, the EC Time journey continues, now with much more power under the engine bonnet (or more watts in the battery).
First a summary that you can get an overview what we have done and jump to the single sections:
Lets first start with long-awaited enhancements for the team absence calendar:
We have received lots of enhancement requests via influence.sap.com regarding further enhancements for the Team Absence Calendar (TAC). And we reacted and delivered. Let me present you the new features for the TAC:
Let´s come to the details:
Visualization of multiple reporting line units hierarchy
In the previous versions of the Team Absence Calendar we showed only the direct reports or peers view. But when a manager has got multiple hierarchy levels down many managers do need to see more levels down than only just one. This long awaited feature is now available.
You can see in above example that not only the direct reports are shown, but when other employees report to one of the direct reports you got a small arrow at this person and you can drill down to the reports of the direct report. Or when it is multiple level downs than the full hierarchy is visualized here. Of course, the user drilling down needs to have the permissions to do so. This is defined in the target group for the team absence calendar specific permissions.
Toggle between weekly and monthly view
Another new feature for the Team Absence Calendar is the toggle functionality between the weekly and the monthly view. Until now there was only a weekly view. But from Q1 2020 there is a new monthly view as well as you can see above. This facilitates the planning process to a great extend and makes the navigation much more easier when you want to check in March for team absences in December for example.
Adding users to the Team absence Calendar
Worth mentioning is also the new "add people" functionality. You can search and add here each and any person you are allowed for via the General User search permission. So, each person you can search for in the people search you can add to the TAC list. This is very helpful when you need to check the availability across a team / reporting line units. You mark on the left side the direct reports or even subordinate employees you want to include in your own list and you search then in the "add people" field for other employees and you can add them to the list. In the manager view those employees absences are shown with time type name when the employee is in the managers permission target group. If not, an anonymized entry not showing the real absence type name is shown. Update 21.05.2020 on the new "Search" Feature:
We have added in H2 2020 an own permission object for the search feature. See this blog for more details:
https://blogs.sap.com/2020/11/06/ec-time-and-attendance-new-features-h2-2020/
Now let´s come to a really big new feature, one that covers a whole new time management scenario:
What is flextime? Flextime employees do not work in fix shifts. They can come and go within a certain boundary as they like. They do not have to be in office punctually at 08:00 and leave at 17:00. They can start at 07:33, 08:45 and leave at 15:00 or 18:03 - just as they want and how the daily work and workload they have to cover permits. Why is this offered to employees? First to give employees the chance in modern times to balance out personell needs and work-life balance with the workload that may change from day to day or week to week. There might be periods where it is necessary that I work longer than my planned time. And there might be days where there is less work which allows me to leave earlier than my planned end time. Or why not allowing employees to work 1 hour longer during the week and allowing them to leave Friday at 12:00 for a prolonged weekend to do some hikes in the Alps? Without loss of pay, without having an absence request recorded, just by automatically deducting the missing hours on Friday from the Flextime account?
But it is not only the employee who benefits from flextime. Even employers can benefit - cause usually in the Flextime scenario they do not pay overtime payment when an employee works longer than his planned hours as long as it is within the flextime bandwidth. So, the employee can work 9 or 10 hours a day but he receives no overtime premium for this extra hours. Cause this plus hours are the hours that are used to balance out when he does work less on other days.
So, a classical win-win situation ;-).
But wait - how to ensure with this flexibility that the employee works overall in a longer period according to his contractually agreed hours? Cause flextime employees are usually salaried employees, so they are not paid by the recorded hour. But they have for example a 40 hours per week contract. Does someone need to sum up manually the hours worked of an employee per month to verify that he at least works his monthly contractual hours?
Yes.
Or you let the system do it automatically ;-). You can use our already available working time accounts that does this automatically on a daily basis. But one step after the other. First lets see how you set up the flextime bandwidth at all to get all this running, than I show you how to use the working time accounts for tracking the flextime delta and at last the new possibility to automatically process the flextime/working time account on a regular basis (bi-weekly, monthly, yearly, bi-monthly or any other regular period) to ensure that for example the flextime account does not increase infinite, but only a balance of 40 hours are carried over to the next flextime cylce.
But let´s first start with the basics. The workschedule and the definition of the flextime bandwidth.
Flextime bandwidth
The flextime bandwidth is usually part of the work schedule. Yes, there might be companies where a company wide flextime bandwidth exists - like for all employees from 06:00 - 18:00, but usually this is part of the workschedule cause you might have part time employees where the flextime bandwidth is for example only till 14:00. Or you have early and late shifts and the bandwidth is always till two hours after the shift ends. Hence, you define the flextime bandwidth in the daily work schedule model.
In the workschedule object this is just another "segment" that you define. Or when you use individual workschedules (without day models) you simply add a segment with the flextime bandwidth for each day.
This is how the configuration of the day model now looks like:
And of course this additional information is shown everywhere where the workschedule details are displayed, like in the work schedule viewer in an employees job info
and in the time sheet when you hover over the planned time:
But why do you need a flextime bandwidth AND still the planned working time defined?
The answer is: the flextime bandwidth defines only the boundaries within which an employees recorded times are allowed. And the "planned working time" is still needed for several reasons:
So, it is important to understand the difference of flextime bandwidth and planned working time: the flextime bandwidth is just a boundary in which attendance times can be recorded, the planned working time still defines hours for absence deduction and what an employee needs to work on a day either based on the employees contract or shift. The planned working time is still the most important information and is mandatory, a flextime bandwidth can, but must not exist.
The flextime bandwidth can then be used in time valuation to detect if attendance times are recorded inside or outside the bandwidth. And you can then process this different time slices. How is this done?
Cut out times outside of a flextime bandwidth
Why should you do this? Cause the flextime bandwidth has a purpose. Usually the flextime bandwidth defines the time span where an employee is allowed to work. Hence any working time recorded inside is regarded as normal paid working time. Does an employee stay longer as the end time of the flextime bandwidth or even start earlier usually this time is then not regarded to be "normal working time". Usually it is non-productive time. Not paid, not counted for anything. And this you can do in the time valuation. You need to use the valuation type "Deduct group from input groups". Here is how you set this up:
As an input time type group you choose a timetype group that represents all your attendance types for example. This is then used and compared against a "deduction group". In this example it is "Flextime bandwidth". Of course you need to create this deduction group beforehand and here it is important to note that you need to choose for this deduction group our new delivered time type category "Flextime". Only then it works. Cause in this hard coded group the flextime bandwidth information from the workschedule is read - if there is any defined.
Looks like this:
But coming back to the time valuation rule above. The times from the input time type group are then compared with the deduction group (flextime bandwidth) and everything that is inside falls into the below time type group "Paid time", everything that does not match with the time interval from the flextime bandwidth falls into the time type group that is defined in the "above" bucket, which is here labelled "times outside the flextime bandwidth".
Just a small recap for the non-valuation-experts how I do my mnemonic on how this above / below thing in our time valuation works. I always imagine a big siever. You pour something into - which is the input time type group. Then there is a condition like for example the deduction group. And what fulfills the condition is passed through the siever and falls "below", hence into the below time type group. And what does not pass just stays "above" in the siever, hence is put into the above timetype group.
So, you have now separated via the time valuation the times inside and outside of the flextime bandwidth. Good. First step done !
And now it is up on the customers requirement what to make out of this time type groups. The times inside the bandwidth are now in the group "Paid Time" and you can process this group further in the next valuations (calculating working time account difference, pay type generation, overtime calculations and so on). And you have got the times outside the bandwidth in an group "Times outside the Flextime Bandwidth". When your business case is that this times are immediately overtime then you can generate for this time type group an overtime premium (or route it into further overtime calculations like when on a sunday it is premium xyz, if it is on a weekday it is premium abc and so on). Or you just say this are unpaid times - like in our example - and you don´t regard it any further in the time valuation.
Let´s follow the example that this times are unpaid and we come back to our scenario. Remember - the flextime bandwidth is from 06:00 - 19:00. When an employee records now times from 05:00 - 16:00 1 hour is outside the flextime bandwidth. And based on our rule described above time valuation cuts this out and sets it as "Unpaid Time":
Paid hours - which are the hours inside the flextime bandwidth - are only 9 hours. But you might ask why 9 and not 10 hours? From 06:00 - 16:00 it is 10 hours. Well, this is due to the automated break deduction. 1 hour break gets automatically deducted.
I have written lots on our break deduction capabilities already in previous blogs (please check them) - just a short reminder: you can have fix unpaid breaks like for example a break definition in the workschedule from 12:00 - 13.00 and whenever an employee records times (attendances or absences) overlapping with this time span, the break is automatically deducted.
Or you can have dynamic breaks or sometimes called minimum breaks that are defined in the time recording profile where you state that after 6 hours of working time 30minutes and after 9 hours another 15 minute break shall be deducted. Why is this break version called "dynamic"? Cause it has not got any fix start / end time. The 6 hours are counted after the employee has started his working time. When he starts at 06:00 then the first break is deducted at 12:00, when he just starts at 08:00 then the break is deducted from 14:00 onwards. Of course the employee can record a break as well, and when this break is already sufficient then the system does not deduct any further breaks. But when he records only 15minute break and works longer than 6 hours, then the system deducts another 15minute break automatically to meet the minimum break rule of 30 minutes.
This was just a small reminder of what is already possible in EC Time. In most cases Flextime employees will have the dynamic break regulation - cause they are free to choose their start of working time for each day and hence most probably fix breaks won´t meet then legal break regulations and the dynamic breaks are then most probably the choice.
But coming back to our employee who came 1 hour earlier to work cause he had to finish a quote that he needed to send out before 12:00 and if he just would have come at the beginning of his flextime bandwidth he would not been able to finish this work in time. And now? Now it is really bad luck for the employee - he stood up in the middle of the night to arrive early in the office and now he only gets a shoulder clapping from his manager but the time is not paid? You can argue: yes, this is what the flextime bandwidth is for and the employee knows this. But we all know: this kind of special circumstances exist. And just setting this time to unpaid is not really nice, isn´t it? Especially not when no one is informed on this.
This is why you can now send an alert to an time administrator based on time valuation results. In our example this means sending an alert as soon as there is a value in the time type group "Unpaid times". This informs the employee and a manager or time administrator on the fact that times outside the flextime bandwidth exist. And this is not done with a nightly job or whatever, but real-time upon save of the time sheet. So the manager / time admin gets immediately this alerts!
The alerting feature out of the time evaluation is another new feature, let me explain how this works just continuing with our above example:
Alerts to time administrators / managers that times outside a bandwidth exist
One important thing before I start with this: the new alerting is not limited to Flextime. This is a new feature that you can use in time valuation for multiple purposes. Up to now you could only create errors in time valuation that where shown immediately real-time in the time sheet. This errors came with a configurable error message and blocked the time sheet for any further time recording. This makes sense for "real" error constellations, but sometimes you just want to inform someone on a specific constellation / time recording or time evaluation fact. Sometimes you just want an alert to an employee and a time admin when he has recorded more than 10 hours net on a day. Or when he has not performed sufficient break time. Or -like in our example- when there are times outside the flextime bandwidth. So, let´s see how the alerts are configured. Lets continue with the flextime example.
You have seen above how to create a time type group when times are recorded outside the flextime bandwidth. And with a simple enhancement in the configuration you trigger an alert once times outside exist. We enhanced the "message type" with a new value. You can now not only choose "error" but also "alert and warning":
And this rule works just like all the other rules for hard errors: You use the "deduct group from input group" as valuation type. This type checks the time type group that is assigned in the "Input time type group" section, deducts the time type group "allowed flextime violation" (we come later to this) and when there is a remaining rest the hours are moved to the time type group above "Unpaid Time" - which is shown to the employee in the time sheet UI - and on top there is an alert raised based on the new setting as you can see in the screenshot plus the error message: "There is unpaid times outside the flextime bandwidth."
In the time sheet this looks like this:
But the alert is not only shown to the employee. We send this alert also to a manager or a time administrator into the Admin Alerts 2.0.
The admin alerts page is a multi-employee list error/alert list that has been released in 2019 (if you want to learn more on it, check this blog: New features in Admin Alert 2.0 ). Up to now this was the list for hard time management errors (for example time account recalculation errors or time sheet generate job errors). Now this list is used to show the alerts as well. You can filter on alerts / errors to process first the time management alerts and then the others or you can filter by employee.
Lets have a look on the alert list in general first. You can navigate to it via an own tile:
And you come to a list where all alerts and errors are shown. There is an own dedicated time management section and you can select the errors coming from recalculation jobs for example, or you choose the heading "Time Valuation" in order to get the alerts that the time valuation has created:
If the alert list is going to be too long you can sort and apply filters:
But in our case there are only 2 time valuation alerts, so we just check those. And this is how our alert looks like:
So, the time administrator is now notified that an employee has yesterday performed work outside the flextime bandwidth. What can he do now? Multiple options - depending on your business needs.
Using the new time type category "extra" to acknowledge times outside a flextime bandwidth
So we still got the example scenario that an employee has recorded times outside the flextime bandwidth. Those times are configured that they do not contribute to the flextime account calculation or that no pay type is generated for it. You can of course create an UI component for it so that an employee sees in his total section that times outside the flextime bandwidth exists, but that´s it. No payment, no regarding as productive working time. This is what we have seen above.
The manager gets notified via an alert that this situation exists. And he knows that this week it was an extraordinary workload and that the employee only come in before the flextime bandwidth to deliver this time sensitive quote. And he wants to confirm the hours as normal hours worked. He can do so with recording in the employees time sheet a timetype of the new category "extra" . This time type categories speciality is that it can overlap fully or partially with the hours outside of the flextime bandwidth.
Lets record this kind of permission not for the full hour from 05:00 - 06:00 but only from 5:30 to 06:00 and let´s see what is happening:
Whats the effect of this new time type category that can be recorded overlapping with other attendance or even absence records? Well, it gives you flexibility in the time valuation to treat this time slice in a special way. In the context of flextime you can use it in a way that all times recorded outside the flextime bandwidth but covered with this new time type category are treated as times inside the flextime bandwidth - you can count them for flextime calculation, create pay types for it and just do the same as with your normal times. And this is exactly shown in the example above: The "unpaid times" are reduced from 1 hour to 30 minutes and the Working time account balance that was previously only 15 hours contain now with this permission 15 hours and 30 minutes. Hence the 30 minutes are now treated as "normal" working time and increase the flextime account.
Or, you can configure the time valuation that this times need to be treated in a special way like for example immediately calculate an overtime premium for it cause your business case is that all times recorded outside the flextime bandwidth but acknowledged by a manager / time admin are per se overtime.
Hence, this new time type category can be used quite flexibly when it comes to the time valuation calculations.
But this new extra category can be used independent of the flextime scenario as well. You can use it for example as pre-approval of overtime. A manager or time admin can record this time types in advance for next week for example from the end of an employees working time till 20:00. If an employee then records normal working time in that time span, you immediately can consider this times as overtime and generate an overtime payment for it. When an employee does not record working time overlapping with this extra-time type nothing happens. Cause it is only a kind of pre-approval. And when the employee records in the following week working time exactly in the same time slot but this extra time type does not exist - you just cut out this times in time valuation and don´t regard it as paid times, cause the "permission" is missing.
So, the important thing is that this new time type category can be recorded overlapping with existing attendances (or even absences). We don´t change or split the original record - cause this is what the employee has recorded as raw data and should not be changed. But with this new category overlapping you can let the original record untouched but still treat the overlapping part in a special way. This a powerful and flexible new thing. And of course you can configure in an employees time profile that this time type can only be recorded from a manager / time admin, and not by the employee himself. The employee gets this time type than in an display only mode.
And how is this all done in the time valuation?
Now I come back again to the time valuation rule some screenshots above where I mentioned that I come back to this later again ;-):
This time valuation rule with the valuation type "deduct group from input groups" takes all times summed in the "times outside the flextime bandwidth" group (which is listed as input time type group) and subtracts all possible times stored in the "Allowed flextime violation" time type group in the field "deduction group". And the "Allowed flextime violation" group contains the times recorded with the new "extra" time type category:
If I would drill down into the time type listed above you would see that the category of this time type is the new "extra" category.
So, I hope you are still with me. This was now admitted a little bit a deep dive into the time valuation. But I hope I could make the necessary configuration a little bit understandable for you.
As a key take away it is important to remember:
But we are not yet full done with the flextime scenario. Cause when the employees can flexibly work as they want, how is it tracked that on the long run a employee works according to his work contract? This can be done with our already existing "working time accounts" or:
Flextime accounts
This is now a point I do not much elaborate on, cause this is existing feature. You can read in detail how to configure working time accounts in this blog: working time accounts
Here I just explain how our working time accounts - or flextime accounts- fit into this flextime process.
As you know the working time accounts perform a daily comparison of planned vs. recorded times. And when there is a delta this delta is posted to working time account. This can be either a positive value or a negative value. And this working time accounts can be used for your Flextime employees to ensure that they adhere to there contractual working hours in the long run. If an employee continuously works less than planned this results in an ever-growing negative working time account balance, does he work more than planned there is an growing positive balance which in turn the employee can use to take some off days with deducting the flextime account.
And now another new feature kicks in. Cause customers usually don´t want the flextime account to grow infinite into the positive or negative. There are often points in time it might be end of month, biweekly, end of quarter, end of year... where the balance of the flextime account shall be automatically checked and processed. And this is provided with our next new feature:
What´s this?
A regular, automated processing of time account balances at a specific point in time
And what´s that for?
As mentioned above: you can cap automatically time account balances at a configured threshold and in a periodical interval.
Let´s come from the UI first - it is easier to explain then. The new feature comes with a new time account monitoring UI. You get a list of all employees (own permission for this) that gives you for a selected date the employees having the selected time account assigned, their time account balances before the automated processing, the new time account balance after and of course what the automated update process has done. Currently we support only a cap of time account balances - but further potential enhancement ideas could be an transfer to a different time account or even an automated payout (but no concrete plans so far to support this - this depends on customer feedback).
So an example: You have got the rule that on the last day of a month the flextime account shall be capped at maximum of 40 hours. This amount can be transferred to next month, but not more.
The UI gives you now exactly this information to monitor what has happened:
You see for example that for Lisa Clark the balance before this automated run the balance was 53:00 hours. But then there was an automated minus posting of 13:00 hours according to the configured rule so that the balance after this process is 40:00 hours. Hence there was a capping of 13:00 hours.
From this UI you can navigate directly to the employees time admin workbench or even to the time sheet. This is necessary if you want to analyze the postings further, or if you want to correct them. Cause it might be that you have had a verbal agreement with Lisa that she can take over this month more hours than the 40, cause there was extra ordinary work load and she had not had the chance to take days off. And now there are several possibilities:
a) you can record in the time sheet an allowance type with 13 hours that is send to payroll for paying out the capped hours
b) you can go to the time admin workbench and record a correction of this automated update run. You can add or deduct hours and hence "undo" fully or partially what this automated process has performed:
But there could even be the case of a too big negative balance at the end of a cycle. When a manager monitors the time account balances with this new UI he will see that at the end of the period the negative balance is too big and he can for example create either in the time admin workbench or in the time sheet an unpaid absence that is replicated to payroll and a salary deduction is performed. Or you create an allowance type with the corresponding hours and payroll reads this specific allowance type as a deduction. Multiple of options....
The results of this automated time account updates are stored with a specific posting type, so you can even navigate into the history and check what previous automated time account updates had been done and you can report on it. The navigation is done with the selection date in the filter option.
But how is this all set up and what flexibility does it allow? Well, lots of.
You need to have first a "Time account update profile" in which the basic configuration is stored. This profile is assigned to the time account itself in a new field. And only those time accounts that have this profile assigned are processed. Second you need to have a business rule in which you maintain all the concrete parameters.
But lets first check the time account update profile. Here is an example:
This profile contains the update frequency like 4 weeks (or months), a reference date from which this weeks shall be counted and an offset in days. The offset is relevant when your flex cycle period is for example monthly and you want to ensure that all employees time sheets are handed in and submitted till end of month. With the offset you can give a little extra time, a small grace period to ensure that all time sheets are approved before this time account update is performed and time accounts are processed.
And you have got the business rule assigned in this profile. And in the business rule you know that you can do lots of things to steer what shall happen with the time account. You can use lots of rule parameters like for example considering future postings (after the planned next update) or not considering and many more options. Here is just an example that reads the employees average weekly working hours from the job info and caps then everything that is beyond this value and not considering any future recordings after the next update date, this means that for example even absences that are already recorded in the future and that deduct from this time account are not regarded:
So, you see, there is no fix value needed and you do not need to apply dozends of different profiles when you got lots of part time employees all having a different average weekly hours contract, you just need one profile, one rule that reads this value.
And there is much more possible: if for example there are some specific employees or employees in a specific department or location that you want to exclude permanently from this automated capping then you can define them in the business rule.
And you can even set a comment in the rule that in turn can be visualized in the time admin workbench to give some more explanations why and what this rule has been done. Check the comment in the rule above and compare it with what is shown in the time admin workbench in the comment section:
You see in the time admin workbench that
a) there is a new posting type "periodic update" that comes from this new business process
b) the comment box is filled with what you have maintained in the comment section of the business rule. This can be used for further explanation to the time admin / manager why a balance has been capped.
Let me stop here, think this is sufficient detail for this new feature. The only important thing that has to be mentioned is that this new function is currently only available for permanent time accounts not for recurring time accounts. Recurring time accounts can only be handled via the period end processing function.
But due to the fact that we are already in the time admin workbench an don the time account tab, let me briefly mention another minor new feature:
This one is really briefly explained. Up to now there was not the possibility to edit or delete an already performed manual time account adjustment in the time admin workbench. If you have created a manual adjustment of +5 hours but you originally wanted to record only +3 hours, then you had to create another manual adjustment with a counterposting of -2 hours. And this pain point has now been removed by enabling an edit and even a delete of already existing manual time account adjustments - you can see the little pencil and dustbin icon in the time admin workbench for manual adjustments:
And since we are still dealing with time accounts, let me draw your attention to the next feature that was strongly requested from our customers:
You know that time accounts can be paid out by a time administrator or a manager via our time administrator workbench:
But many customers have the requirement that employees are allowed to request for pay out. And cause we always listen to our customers we provide now a self service for time account payout. This will give your employees much more flexibility and ease your time administrators from lots of administrative and repetitive tasks and facilitate this whole business process in your company.
But how can an employee access the cash out leave scenario?
There is going to be a new extra tile on the homepage for this scenario:
and when clicking on it employees get an overview on the time account balances for the cash out-allowed time accounts:
He sees all the up-to-date time account balances as well as past payout requests with approval status.
He can then click on the "request payout" link on the respective time account and enter the hours or days (depeding on the time account unit) he wants to cash out:
You can upload an attachment if needed and upon submitting the request a workflow can be triggered (usually this scenario is used together with a workflow approval). When approved the hours / days are deducted from the time account and the cash out is transferred automatically to EC Payroll (Infotype 0015). Payroll calculates then the monetary equivalent of the requested days / hours and pays this out with the next payroll run.
A nice feature here is that upon submitting the request we show the workflow recipient:
Another nice thing is that as you can see on the left screenshot you can even enhance the pop-up with further customer specific explanations and a link to external leave or cash out policy documentation.
Some customers have got the requirement that this scenario is only enabled for employees during a specific time period in the year. For example from 1st March till end of April for last years time accounts. It is not possible to hide the cash out tile for the rest of the year, but you can create save rules that allow requesting only in that specific time frame.
Is each time account type going to be enabled for ESS payout? Only if you want. We of course deliver a configuration option for it. Cause most often not each and any time account shall be enabled for this ESS scenario but only specific accounts. Hence there is a configuration setting on time account type level. You can choose which time accounts shall be enabled for ESS cash out request and which time accounts shall still only be possible to be paid out by a time administrator. This is done in the time account configuration (manage data: time account type):
The relevant field for the configuration is the "payout eligibility" field. Not eligible means: no payout possible at all. The value "eligible" means that only time administrators via the time administration workbench can perform payouts and "eligible for self service" - is self explanatory ;-). This is the new option that allows the ESS payout service for this time account type.
But you can and need to do a little bit more. There is also a new "time account payout profile" that is assigned to the time account type as well and which need to be configured:
This profile contains for example the pay component info with which this time account shall be paid out (and in the pay component itself you define if EC Time shall calculate and hand over to payroll the gross monetary amount or just only the hours and days). You can furthermore assign a separate pay component for the termination process and for accruals on termination. And you can assign workflow rules and validation rules in this profile. Workflow rule is clear - you assign the workflow configuration here when you want to trigger a workflow. And the validation rules are helpful when you want to do eligibility and threshold checks. You can use them when you do not want to allow a payout leading to a remaining time account balance smaller then 10 days for example. Or you can even check not only this time accounts balance, but also other time accounts. Or you can check that an employee needs to have a specific service length in order to allow him a ESS pay out. As usual - the business rules give you lots of freedom and variability in configuration. And finally the time account payout profile holds the customer own explanatory text for the UI as mentioned above and with so-called standard BB-codes you can add an external url that holds for example company policies regarding the payout.
If you want to have a detailed step-by-step guide how to set this scenario up, then please check this blog from Ruchi Tandon:
Overview
Configuration step-by-step
Let´s come now to a feature that is linked to absences, but only relevant for one country: Australia.
This is a country specific topic developed for public service in the australian country version. Assume you want to celebrate your 10th wedding day with your wife at a special place and want to surprise your wife with fulfilling her long lasting dream of going once in a lifetime to Tanzania for a photo safari. This trips are usually quite expensive and you haven´t got sufficient savings to book this vacation. What could you do? Taking unserious loans at really high interest rates? Or asking your employer to pay your salary or vacation payments in advance? Latter would be more save to your health and more serious ;-). And asking your employer for payment in advance is possible in Australia. You can state together with your leave record if you want to have your vacation payment that you receive during the time of your absence already with the next pay cycle. And this is supported end-to-end from leave request via workflow to EC Payroll and payout.
So, if you use the country extension for Australia you can configure for which leave type you want to enable the possibility to choose leave advance payment. When employees choose this timetype they will see to additional check boxes in the lower right section of the leave request:
When they tick first checkbox they apply in general for leave advance payment.
When they tick second checkbox the payment is even splitted across financial years.
Of course this whole scenario does not fly without an integration to payroll. Cause payroll needs to know on the fact that it needs to payout money in advance. Our leave advance payment is only supported end-to-end in the integration to EC Payroll. In the SAP ERP country version for Australia there is a specific infotype that handles the leave advance payment, Infotype 0573. However, with the EC Time and EC Payroll in place the integration of this information will be handled completely through the IT2001 absence replication to EC Payroll. Hence, there is no need for maintaining IT0573 anymore.
In some countries on this earth it is allowed to have a so-called double or half pay leave. The concept is quite easy to understand:
For half pay leaves: for on absence day only half day time account deduction is done. Sounds good - isn´t it? Cause then a 20-days vacation entitlement would turn out to last then for 40 off days. But, and here comes the little but, this days are not fully paid, but only half paid. So, half time account deduction, half payment.
Why is this possibility provided to employees? Cause it might be that their normal vacation balance is not sufficient any more to take 10 days off, they only have 5 days left. Then this is an option to enable nevertheless the employee taking his desired 10 days off - but at half pay.
The contrary is the double pay. For 1 day vacation you get deducted 2 days from your time account. Hmm - nobody would do this, wouldn´t you? 😉 Unless this is reflected in the payment - and here it is. Cause the employee gets then 2 days payment for 1 day off.
This scenario can be used where at the end of the year an employees vacation account balance is too big, he can´t take it fully till the end of the year and afterwards it might forfeit. Hence, he can take 5 days off at double pay. This means 10 days are deducted from the time account and he gets for this 5 days a double payment. Another example for this would be -just like above - the expensive poto-safari trip to Tanzania. He can afford this with "paying" double time account deduction. He spents 20 days for a two-week vacation but receives double payment for it so that he can afford his trip.
So, this scenario is closely coupled to payroll handling. EC Time itself does not generate payments, the scenario works only end-to-end with EC Payroll or SAP onprem payroll. How does it work in detail?
Quite simple. We brought a new "deduction factor" into our time type configuration. So you need to create a new absence timetype and maintain this deduction factor according to your needs - be it 50%, 200% or whatever percentage you need:
This is done in the absence counting method which is assigned to the timetype. And to make the effect of this time type transparent to the employee I would suggest to label the time type correspondingly as "half pay" or "double pay".
The time account deduction in EC is then done according to the configured deduction factor.
But how is this information passed to Payroll? Is there an additional infotype replicated? No. Our time type is replicated to the absence infotype in EC Payroll or SAP onprem Payroll. And there you need to take care that the absence counting method in EC Payroll / SAP onprem Payroll has the same deduction factor than in EC time configuration. Cause the absence calculation is triggered again in the Infotype 2001 and the deduction factor has an effect on the absence hours. And cause this special timetype is mapped to an SAP Infotype-subtype Payroll can use this and the calculated absence hours to adapt the salary payment as needed.
If you don´t find the deduction factor field in our absence counting method then make sure you have switched it on via configure object definition 😉
This is just a short one - in case you jumped directly to this heading. Cause I elaborated already in the Flextime section above on the new alerting capabilities out of the time valuation. In a nutshell again:
And if you want to read more on the new Admin Alert 2.0 tool, check out this blog:
New features in Admin Alert 2.0
This one will ease your time sheet / time valuation configuration to a great extend. It will reduce your long list of time valuation rules, reduce the complexity and make the configuration overall more transparent and simple.
You know that in the past we had filters that you could apply in a time valuation rule to detect if times have been worked on a specific weekday or on a specific public holiday in order to grant then a special payment for it:
However, the bad thing was - you were able to define only 1 weekday and not multiple weekdays. If the same special payment was for Saturday work, too, then you had to create a second filter. And based on the fact that you can only use one filter in one time valuation rule you already needed two time valuation rules. And this blew up the amount of time valuation rules. All not that nice, but we delivered an enhancement:
The new enhancement is now that you can add multiple days into a filter. So, if you want to check on working time on Saturday and Sunday vs. working time during the week you can add now multiple days to your filter:
When you apply this filter in a time valuation rule with the "Aggregate input group and split" method then you can route all times from Monday-Friday into the time type group below, and what is put then into the time type group above is logically the working times on Saturday / Sunday. And you have two different time type groups representing working time during the week and working time on the weekend.
But this is not yet the end of the story - cause we adapted an already existing time valuation method so that this new filters are even more powerful.
Cause, you might say: nice that I now can have multiple days in one filter instead of creating for each day a filter, but what about the start / end time conditions? Cause normally you have not only conditions on the day for creating specific wage types / payments or time valuation results, but also on top within an additional clock time span. Like for example: Monday - Friday from 18:00 - 22:00 you want to have a late shift premium generated. Or on public holidays between 00:00 and 24:00.
This was already possible in the past releases, but you have to have multiple time valuation rules to configure this. With the new approach, this is much more easier and transparent. Cause we enhanced the time valuation method "Filter Input groups" with the new filter options AND a start / end time condition. So, from the functional point of view this looks now a bit like the SAP ERP Time management table T510S for wage type generation ;-).
And how does this look like in EC time? As mentioned, take the above new filter for multiple days and use the new enhanced time valution method "Filter Input Groups":
So, overall to sum up:
This will reduce the amount of time valuation rules you need in your system and make facilitates the configuration and providing much more transparency.
Many of you now that the workschedule in EC Payroll infotype 0007 is a vital part for the payroll to work correctly. Payroll needs for lots of calculations either the correct planned working time of an employee or the average daily / weekly hours. Be it to calculate an unpaid absence correctly (monthly salary divided by the planned days to get a monetary value to deduct or 1 unpaid day) for tax reasons regarding correct company car tax calculations, for bonus payments calculations and many more payroll use cases. Or be it to have the correct absence hours calculated by from EC replicated absences - cause the absence quantity calculation happens again in EC Payroll and here again the work schedule is the basis for this.
But the problem till now was:
Currently the workschedule gets replicated from EC Time Job Info to IT0007 in EC Payroll. But first you have to double maintain the workschedule: in EC time and again in EC Payroll cause it is only a code mapping in the replication and both workschedules need to exist in both worlds. Second EC Time provides features like the so-called "individual workschedules" that cannot be replicated to Infotype 0007. And we have the possibility to perform short- or mid-term shift changes via the "temporary change of workschedule" which works similar to the IT2003 substitution infotype, so you can for example overwrite for next week the job info workschedule that contains a 5 working days week with a 4 day week shift but therefore the week after with a 6-days week. This feature is used for short term shift swapping for example. And this information is not replicated to EC Payroll, cause the job info workschedule was not touched physically.
But all this comes to an end now. Cause we provide a daily planned working time replication to EC Payroll and you get rid of double maintaining the workschedules and IT2003 records.
How is this working?
First a kind of process overview:
There is a day-by-day replication of the planned working time into the IT2003 record on EC Payroll side. This allows you to have only a few dummy workschedules on EC Payroll side and the real planned working time comes from EC Time on a daily basis. How you set up this dummy workschedule depends on your business needs - it can be a 24/7 workschedule, or you can have a couple of workschedules that reflects basically how your employees work contractually (like a 40 hours week with 5 working days a 8 hours). This depends a bit on what you need in payroll.
You can configure how long into the future the work schedule replication shall be done in advance (to cater for example for payroll simulation runs) and then the replication for this employee is only triggered automatically again for this period when changes are detected (like change of workschedule in EC or the recording of a temporary change of workschedule). This is done in a so-called replication period object. The default is 32 days into the future so that in any case for monthly payrolls the planned working time is provided for next payrolls run date.
And of course, when there are retroactive changes to the workschedule in EC Time (be it changes in the Job Info workschedule or by a forgotten short term shift change that is created retroactively via the temporary time object) then so-called replication proxies are set. This proxies are read by the replication program and from this date onwards the replication to IT2003 is triggered anew.
In the IT2003 record start / end time of the planned work time plus break information (coming from fix break schedules in EC Time or from dynamic breaks in EC Time) is replicated as well as the public holiday class to transfer even the public holiday information.
When absences are already replicated for a future period then of course they get re-evaluated based on this IT2003 record so that always the correct absence hour / days information is in EC Payroll.
If you want to use this replication only for a bunch of workschedules - cause for example you have already set up in EC Payroll the workschedules for a group of employees that don´t have got lots of shift changes - then you can stick for those employees to the existing IT007 workschedule replication method and not using the IT2003 replication. You can do so by entering those workschedules in a block-list that you want to exclude from the IT2003 replication. Each employee that has got this workschedule assigned is then excluded - but of course real short term shift swaps recorded in EC Time via the temporary workschedule function are nevertheless replicated.
When errors occur during this replication process you get alerts into the Admin Alert 2.0 List and you find more information on those in the Data Replication Monitor.
The whole integration scenario is very well documented - but you won´t find it in the EC Time implementation guide. It is described in the Employee Central Payroll Implementation Guide. There is lots of detailed explanation what you need to do - from setting the permissions, over the replication configuration, mapping of entities till the monitoring of this replication process.
Another topic that is eagerly awaited by many customers. You might have got 3rd party shift planning tools in place where you do the shift planning and shift assignment. Each time management systems needs however correct planned working time information to perform overtime calculations and correct time account deductions for example. Hence if you are having shift planning systems and want to use the time evaluation and time account calculation mechanisms in EC Time, there was no other chance up to now than to double maintain the workschedules - which is admittedly not a real practical solution.
But now this has changed. You can now connect shift planning systems to EC Time. This is done with Odata APIs. You can send us per employee and day a shift via a day model. Or you send even for a period in advance a couple of day models. For each day one. Or you can even send if it is larger period a reference to a workschedule. Of course, day model and workschedule must exist in EC Time ! This is then loaded into the "temporary time information" object and gets of course displayed in the time administrator workbench (and can even be edited there). But it is not only updating the time administrator workbench - everywhere where the planned working time is displayed (in the time sheet Ui for example or in the employees workschedule viewer) or everywhere where the planned working time is used for calculation purpose this new uploaded information in the temporary time information object is read.
When absences are already in the system and you update afterwards with this API the temporary workschedule then of course the absence (or even time sheet) gets re-calculated again (when you have switched on the re-calculation what you anyhow should do). When this leads to error constellations those errors are shown in the Admin Alert 2.0 list.
Error situation could for example be: you load a week with 6 working days from the shift planning tool where previously based on the EC workschedule there was only a 4-days week and the employee has already requested a leave and only 4 days left in his account. As a result there is then not enough balance left for this absence in the time account. - But why would you load a shift change for an employee that has already got an absence recorded for this time? But it can happen.
And how is the upload done?
With an OData API call. This is an example of the structure and the import from 16th - 20th March of a day model CLT-Early shift:
This results then in an tempoary time information record for the period given in the Odata call.
And, as mentioned, you can not only import a day model, but also a reference to a workschedule. This can be used when an employee works for a longer period according to a specific workschedule and there is no daily re-planning in the shift planning tool. What you need to do is just to replace the "day model" parameter with a "work schedule" parameter in the Odata API:
Some things to consider when you want to use this:
So, seeing those two enhancements around work schedule replication and import from shift planning systems this is overall now a nice end to end scenario, isn´t it? In external shift planning systems you perform the shift planning, this information is send to EC Time, employees record their absences and time sheets and based on the correct planned working time all the evaluation calculations are done. This updated workschedule information is replicated to EC Payroll into the IT2003 along with the absences into IT2001 and the time valuation results into IT2010 and Payroll has got all it needs for a proper payroll run.
And we have got two enhancements coming from the workflow team (many thanks to them !) that are very useful for time management processes as well:
This one is explained quickly. You can set in your workflow rule an option that you want to have the time sheet or leave requests workflow approved automatically after a certain number of days. The workflow is then set to approved when the number of days have elapsed after submitting the workflow and no one has either approved or declined it. This is useful when you for example want to ensure that specific workflows are not in the pending status for ages cause some managers do not take the approval as seriously as they should do.
Just set the corresponding option in the workflow rule and enter the number of days:
And the last really good workflow feature is the auto-delegation possibility. There is the possibility to choose another user as a delegatee for all your workflow requests. This is very usefull when you as a time sheet or leave request approver go for a 3-weeks vacation and you want that all workflows are automatically routed to a different person for this period. You can access this via the quick link section on the homepage:
You get then a dialogue in which you can enter another user as delegatee and the period in which this person shall be the delegatee:
But this process would be only of little help when the one who is entered as delegate is not notified on this or when he has no chance to reject this delegation - cause he himself is on vacation for a period for which someone else wants to delegate the approvals to him. Hence this person gets this request and he can either accept or reject. If he accepts the delegation request then all workflows are routed automatically to this person in the stated period.
And of course, this whole scenario comes with an own permission, means you can define in the target group of the permission who can be entered as a delegate - this is to avoid that each and any user can be entered as a delegate, but only those who shall be allowed to.
This was it. All new features in Q1 2020. And finally you made it till the end. I did cover only the major things we shipped - there are a couple of more time related new features mainly for the country version Australia and for public service - please refer to the release notes on this. Otherwise the blog gets really too long ;-). I hope you can use what we have shipped. Please feel free to add comments on the new features - if yo like them, if they are usefull... and especially comments to this blog. I would really like to know if you still find this blog useful- despite the length this thing has grown into. Cause next release we plan to have the same amount of cool new features that are long awaited for from customers. Just think on the big two topics that are missing in our EC Time solution. I give you a bit to think over it.....
Okay, no secrets, cause you can find this in our official roadmap: we plan to tackle cross midnight (first for absence recording, afterwards attendances) and clock in / out integration with terminals and other time devices, and of course a bunch of other good things.
So, stay tuned. Give me feedback whether this lengthy blog is useful or not.
Take care, stay healthy and save.
Volker Ruof
EC Time Product Management
we are currently experiencing with Covid-19 changes no one of us experienced ever before affecting our lifes, the lifes of familiy members and friends, the way we work, the way we live and our daily routines. But yet there are some things that do not change. One is that Successfactors delivers a new release, the other is that I write a blog on the new EC Time Features coming with this release.
And this release there is really lots of good stuff in it for Time Management. You know that Successfactors has changed is release cylce from quarterly to bi-yearly. Hence there was much more time for the development team to develop new features. But we also increased our development man- (and woman) power for EC Time significantly. There are much more development teams now working for EC Time than ever before - and I bet that you will be as impressed as I am after reading through this blog on the tons of really good, big new EC Time features.
But the ability to provide now lots of new EC Time features with this stronger development power in a longer period means also that this blog is going to be longer. More features - more words needed to explain them. And what was in the past a short read through on the new features with some details and easy-to-understand example results now rather in a real effort to read all of this. The word-counter above says that you need to spend more than 30 minutes to read this - which is a lot. So, maybe you can give me some feedback in the comment section below if you still find this blog / channel useful or if it is now too long and too big to be consumed well.
But although the blog is going to be longer this time I stick to the usual pattern from my past blogs: I try as usual to find the balance in explaining the many new features in dedicated sections which you can read stand-alone and in a way that enough deep dive information is shared but also non-time experts understand what the new feature is about.
So, again, as always: fasten your seat belts, the EC Time journey continues, now with much more power under the engine bonnet (or more watts in the battery).
First a summary that you can get an overview what we have done and jump to the single sections:
Team absence calendar enhancements
Did your upper level manager always wanted to look multiple levels down in the team absence calender? Ever wanted a toggle between weekly and monthly view?
Flextime
Flextime allows your employees to come / leave work not on a fix daily start / end but more flexibly. The tracking of the hours worked can be done against a working time account (to ensure an employee meets his contractual hours). This is a great big new scenario and comes with:
- Flextime bandwidth definition in workschedule
- Cut out of times that are outside the flextime bandwidth
- Alerts to time administrators / managers that times outside a bandwidth exists
- Possibility for a time admin / manager to confirm the times performed outside a bandwidth as normal hours worked or as overtime
- Automated periodical processing of Flextime / working time accounts to cut off for example a balance of more than 20 hours before the new month start
Automated periodical time account update
Cool thing if you want automatically Time off in lieu accounts or Working time accounts processed in a way that at the end of a configurable period (end of month, 3 months, 3 days before end of month...) a time off in lieu or working time account balance gets automatically capped. Plus a multi-employee UI to review this and of course make adjustments
Delete / edit possibility for manual time account adjustments
You don´t have to create counterpostings to a manual time account adjustment anymore. Just edit or delete it.
Employee Self Service for time account payout
Long awaited by lots of customers: now life of time admins get easier cause employees can request a time account payout in an own ESS scenario
Leave on half pay / double pay (and half / double time account deduction)
Employees can request a half pay leave (or double pay) in the sense that only half (or double) time account deduction is done and payroll only pays half (or double) daily salary
Advance leave payment
This is rather Australia specific: when employees get an extra holiday payment they can decide if they want to have it paid prior to the actual pay period
Real planned working time replication to EC Payroll
This sends on a daily basis the real planned time to EC Payroll and you don´t have the need to double configure workschedules in EC and in EC Payroll anymore
Upload of planned time from shift planning systems to Employee Central on a daily basis
This allows you using external shift planning systems and feeding those shifts to EC Time so that absence and attendance recording can be done and our valuations using this external shifts as planned working time
Alerting possibilities in time sheet
You can trigger now alerts in the time sheet that are presented to the employee in the time sheet and send to managers / admins into the admin alert page
Simplification of time valuation filters
Ever found the amount of time valuation rules needed cumbersome when you want to pay a special pay type for work on a sunday between 06:00 and 18:00 for example? We combined the filter for days and the filter for clocktimes
Workflow enhancements
- Autoapproval of absence request and time sheets. When you use this feature you can set leave requests and time sheets for example to auto-approve after 3 days.
- Delegation of workflow
This allows an employee to choose a workflow delegate for all workflows
- Autoapproval of absence request and time sheets. When you use this feature you can set leave requests and time sheets for example to auto-approve after 3 days.
Lets first start with long-awaited enhancements for the team absence calendar:
Team Absence Calendar Enhancements
We have received lots of enhancement requests via influence.sap.com regarding further enhancements for the Team Absence Calendar (TAC). And we reacted and delivered. Let me present you the new features for the TAC:
- Visualization of multi-level hierarchy in the TAC
- New monthly view in addition to the weekly view
- Possibility to search for people in the organization and add them to the TAC list
Let´s come to the details:
Visualization of multiple reporting line units hierarchy
In the previous versions of the Team Absence Calendar we showed only the direct reports or peers view. But when a manager has got multiple hierarchy levels down many managers do need to see more levels down than only just one. This long awaited feature is now available.
You can see in above example that not only the direct reports are shown, but when other employees report to one of the direct reports you got a small arrow at this person and you can drill down to the reports of the direct report. Or when it is multiple level downs than the full hierarchy is visualized here. Of course, the user drilling down needs to have the permissions to do so. This is defined in the target group for the team absence calendar specific permissions.
Toggle between weekly and monthly view
Another new feature for the Team Absence Calendar is the toggle functionality between the weekly and the monthly view. Until now there was only a weekly view. But from Q1 2020 there is a new monthly view as well as you can see above. This facilitates the planning process to a great extend and makes the navigation much more easier when you want to check in March for team absences in December for example.
Adding users to the Team absence Calendar
Worth mentioning is also the new "add people" functionality. You can search and add here each and any person you are allowed for via the General User search permission. So, each person you can search for in the people search you can add to the TAC list. This is very helpful when you need to check the availability across a team / reporting line units. You mark on the left side the direct reports or even subordinate employees you want to include in your own list and you search then in the "add people" field for other employees and you can add them to the list. In the manager view those employees absences are shown with time type name when the employee is in the managers permission target group. If not, an anonymized entry not showing the real absence type name is shown. Update 21.05.2020 on the new "Search" Feature:
We have added in H2 2020 an own permission object for the search feature. See this blog for more details:
https://blogs.sap.com/2020/11/06/ec-time-and-attendance-new-features-h2-2020/
Now let´s come to a really big new feature, one that covers a whole new time management scenario:
Flextime
What is flextime? Flextime employees do not work in fix shifts. They can come and go within a certain boundary as they like. They do not have to be in office punctually at 08:00 and leave at 17:00. They can start at 07:33, 08:45 and leave at 15:00 or 18:03 - just as they want and how the daily work and workload they have to cover permits. Why is this offered to employees? First to give employees the chance in modern times to balance out personell needs and work-life balance with the workload that may change from day to day or week to week. There might be periods where it is necessary that I work longer than my planned time. And there might be days where there is less work which allows me to leave earlier than my planned end time. Or why not allowing employees to work 1 hour longer during the week and allowing them to leave Friday at 12:00 for a prolonged weekend to do some hikes in the Alps? Without loss of pay, without having an absence request recorded, just by automatically deducting the missing hours on Friday from the Flextime account?
But it is not only the employee who benefits from flextime. Even employers can benefit - cause usually in the Flextime scenario they do not pay overtime payment when an employee works longer than his planned hours as long as it is within the flextime bandwidth. So, the employee can work 9 or 10 hours a day but he receives no overtime premium for this extra hours. Cause this plus hours are the hours that are used to balance out when he does work less on other days.
So, a classical win-win situation ;-).
But wait - how to ensure with this flexibility that the employee works overall in a longer period according to his contractually agreed hours? Cause flextime employees are usually salaried employees, so they are not paid by the recorded hour. But they have for example a 40 hours per week contract. Does someone need to sum up manually the hours worked of an employee per month to verify that he at least works his monthly contractual hours?
Yes.
Or you let the system do it automatically ;-). You can use our already available working time accounts that does this automatically on a daily basis. But one step after the other. First lets see how you set up the flextime bandwidth at all to get all this running, than I show you how to use the working time accounts for tracking the flextime delta and at last the new possibility to automatically process the flextime/working time account on a regular basis (bi-weekly, monthly, yearly, bi-monthly or any other regular period) to ensure that for example the flextime account does not increase infinite, but only a balance of 40 hours are carried over to the next flextime cylce.
But let´s first start with the basics. The workschedule and the definition of the flextime bandwidth.
Flextime bandwidth
The flextime bandwidth is usually part of the work schedule. Yes, there might be companies where a company wide flextime bandwidth exists - like for all employees from 06:00 - 18:00, but usually this is part of the workschedule cause you might have part time employees where the flextime bandwidth is for example only till 14:00. Or you have early and late shifts and the bandwidth is always till two hours after the shift ends. Hence, you define the flextime bandwidth in the daily work schedule model.
In the workschedule object this is just another "segment" that you define. Or when you use individual workschedules (without day models) you simply add a segment with the flextime bandwidth for each day.
This is how the configuration of the day model now looks like:
And of course this additional information is shown everywhere where the workschedule details are displayed, like in the work schedule viewer in an employees job info
and in the time sheet when you hover over the planned time:
But why do you need a flextime bandwidth AND still the planned working time defined?
The answer is: the flextime bandwidth defines only the boundaries within which an employees recorded times are allowed. And the "planned working time" is still needed for several reasons:
- correct absence calculation purpose (when an absence is created how many hours shall be deducted from a time account)
- to have the net planned time that is relevant for overtime calculation purpose
- to have a value that time evaluation can use to calculate the working time account difference
- to have a value that is replicated to EC Payroll as planned time (see feature description below)
- and for all other calculation steps where you need the planned working time.
So, it is important to understand the difference of flextime bandwidth and planned working time: the flextime bandwidth is just a boundary in which attendance times can be recorded, the planned working time still defines hours for absence deduction and what an employee needs to work on a day either based on the employees contract or shift. The planned working time is still the most important information and is mandatory, a flextime bandwidth can, but must not exist.
The flextime bandwidth can then be used in time valuation to detect if attendance times are recorded inside or outside the bandwidth. And you can then process this different time slices. How is this done?
Cut out times outside of a flextime bandwidth
Why should you do this? Cause the flextime bandwidth has a purpose. Usually the flextime bandwidth defines the time span where an employee is allowed to work. Hence any working time recorded inside is regarded as normal paid working time. Does an employee stay longer as the end time of the flextime bandwidth or even start earlier usually this time is then not regarded to be "normal working time". Usually it is non-productive time. Not paid, not counted for anything. And this you can do in the time valuation. You need to use the valuation type "Deduct group from input groups". Here is how you set this up:
As an input time type group you choose a timetype group that represents all your attendance types for example. This is then used and compared against a "deduction group". In this example it is "Flextime bandwidth". Of course you need to create this deduction group beforehand and here it is important to note that you need to choose for this deduction group our new delivered time type category "Flextime". Only then it works. Cause in this hard coded group the flextime bandwidth information from the workschedule is read - if there is any defined.
Looks like this:
But coming back to the time valuation rule above. The times from the input time type group are then compared with the deduction group (flextime bandwidth) and everything that is inside falls into the below time type group "Paid time", everything that does not match with the time interval from the flextime bandwidth falls into the time type group that is defined in the "above" bucket, which is here labelled "times outside the flextime bandwidth".
Just a small recap for the non-valuation-experts how I do my mnemonic on how this above / below thing in our time valuation works. I always imagine a big siever. You pour something into - which is the input time type group. Then there is a condition like for example the deduction group. And what fulfills the condition is passed through the siever and falls "below", hence into the below time type group. And what does not pass just stays "above" in the siever, hence is put into the above timetype group.
So, you have now separated via the time valuation the times inside and outside of the flextime bandwidth. Good. First step done !
And now it is up on the customers requirement what to make out of this time type groups. The times inside the bandwidth are now in the group "Paid Time" and you can process this group further in the next valuations (calculating working time account difference, pay type generation, overtime calculations and so on). And you have got the times outside the bandwidth in an group "Times outside the Flextime Bandwidth". When your business case is that this times are immediately overtime then you can generate for this time type group an overtime premium (or route it into further overtime calculations like when on a sunday it is premium xyz, if it is on a weekday it is premium abc and so on). Or you just say this are unpaid times - like in our example - and you don´t regard it any further in the time valuation.
Let´s follow the example that this times are unpaid and we come back to our scenario. Remember - the flextime bandwidth is from 06:00 - 19:00. When an employee records now times from 05:00 - 16:00 1 hour is outside the flextime bandwidth. And based on our rule described above time valuation cuts this out and sets it as "Unpaid Time":
Paid hours - which are the hours inside the flextime bandwidth - are only 9 hours. But you might ask why 9 and not 10 hours? From 06:00 - 16:00 it is 10 hours. Well, this is due to the automated break deduction. 1 hour break gets automatically deducted.
I have written lots on our break deduction capabilities already in previous blogs (please check them) - just a short reminder: you can have fix unpaid breaks like for example a break definition in the workschedule from 12:00 - 13.00 and whenever an employee records times (attendances or absences) overlapping with this time span, the break is automatically deducted.
Or you can have dynamic breaks or sometimes called minimum breaks that are defined in the time recording profile where you state that after 6 hours of working time 30minutes and after 9 hours another 15 minute break shall be deducted. Why is this break version called "dynamic"? Cause it has not got any fix start / end time. The 6 hours are counted after the employee has started his working time. When he starts at 06:00 then the first break is deducted at 12:00, when he just starts at 08:00 then the break is deducted from 14:00 onwards. Of course the employee can record a break as well, and when this break is already sufficient then the system does not deduct any further breaks. But when he records only 15minute break and works longer than 6 hours, then the system deducts another 15minute break automatically to meet the minimum break rule of 30 minutes.
This was just a small reminder of what is already possible in EC Time. In most cases Flextime employees will have the dynamic break regulation - cause they are free to choose their start of working time for each day and hence most probably fix breaks won´t meet then legal break regulations and the dynamic breaks are then most probably the choice.
But coming back to our employee who came 1 hour earlier to work cause he had to finish a quote that he needed to send out before 12:00 and if he just would have come at the beginning of his flextime bandwidth he would not been able to finish this work in time. And now? Now it is really bad luck for the employee - he stood up in the middle of the night to arrive early in the office and now he only gets a shoulder clapping from his manager but the time is not paid? You can argue: yes, this is what the flextime bandwidth is for and the employee knows this. But we all know: this kind of special circumstances exist. And just setting this time to unpaid is not really nice, isn´t it? Especially not when no one is informed on this.
This is why you can now send an alert to an time administrator based on time valuation results. In our example this means sending an alert as soon as there is a value in the time type group "Unpaid times". This informs the employee and a manager or time administrator on the fact that times outside the flextime bandwidth exist. And this is not done with a nightly job or whatever, but real-time upon save of the time sheet. So the manager / time admin gets immediately this alerts!
The alerting feature out of the time evaluation is another new feature, let me explain how this works just continuing with our above example:
Alerts to time administrators / managers that times outside a bandwidth exist
One important thing before I start with this: the new alerting is not limited to Flextime. This is a new feature that you can use in time valuation for multiple purposes. Up to now you could only create errors in time valuation that where shown immediately real-time in the time sheet. This errors came with a configurable error message and blocked the time sheet for any further time recording. This makes sense for "real" error constellations, but sometimes you just want to inform someone on a specific constellation / time recording or time evaluation fact. Sometimes you just want an alert to an employee and a time admin when he has recorded more than 10 hours net on a day. Or when he has not performed sufficient break time. Or -like in our example- when there are times outside the flextime bandwidth. So, let´s see how the alerts are configured. Lets continue with the flextime example.
You have seen above how to create a time type group when times are recorded outside the flextime bandwidth. And with a simple enhancement in the configuration you trigger an alert once times outside exist. We enhanced the "message type" with a new value. You can now not only choose "error" but also "alert and warning":
And this rule works just like all the other rules for hard errors: You use the "deduct group from input group" as valuation type. This type checks the time type group that is assigned in the "Input time type group" section, deducts the time type group "allowed flextime violation" (we come later to this) and when there is a remaining rest the hours are moved to the time type group above "Unpaid Time" - which is shown to the employee in the time sheet UI - and on top there is an alert raised based on the new setting as you can see in the screenshot plus the error message: "There is unpaid times outside the flextime bandwidth."
In the time sheet this looks like this:
But the alert is not only shown to the employee. We send this alert also to a manager or a time administrator into the Admin Alerts 2.0.
The admin alerts page is a multi-employee list error/alert list that has been released in 2019 (if you want to learn more on it, check this blog: New features in Admin Alert 2.0 ). Up to now this was the list for hard time management errors (for example time account recalculation errors or time sheet generate job errors). Now this list is used to show the alerts as well. You can filter on alerts / errors to process first the time management alerts and then the others or you can filter by employee.
Lets have a look on the alert list in general first. You can navigate to it via an own tile:
And you come to a list where all alerts and errors are shown. There is an own dedicated time management section and you can select the errors coming from recalculation jobs for example, or you choose the heading "Time Valuation" in order to get the alerts that the time valuation has created:
If the alert list is going to be too long you can sort and apply filters:
But in our case there are only 2 time valuation alerts, so we just check those. And this is how our alert looks like:
So, the time administrator is now notified that an employee has yesterday performed work outside the flextime bandwidth. What can he do now? Multiple options - depending on your business needs.
- If needed the time administrator can navigate from the alert into the employees time sheet directly to the day where the alert was raised with one click to investigate the overall time recordings on this day. And he can decided to do nothing. He can ignore the alert. Bad luck for the employee who worked longer. The times he has worked have been in vain (at least from a monetary point of view).
- But to keep track that this alert has been read and investigated he can "acknowledge" the alert. This option is new in the Alert List. Acknowledge means to document that the manager or time admin have noticed and read the alert. The alert moves then from the "New" section to the "Acknowledged" section. With this you can track that this kind of alerts really have been monitored, watched upon and noticed.
- But this is not yet the whole end of the story. Cause the time administrator knows that the employee had to come earlier to office in order to finish this important quote before 12:00. So, he can decide that he "confirms" the times that the employee has recorded outside. How is this been done? Again, we created a new feature for this:
Using the new time type category "extra" to acknowledge times outside a flextime bandwidth
So we still got the example scenario that an employee has recorded times outside the flextime bandwidth. Those times are configured that they do not contribute to the flextime account calculation or that no pay type is generated for it. You can of course create an UI component for it so that an employee sees in his total section that times outside the flextime bandwidth exists, but that´s it. No payment, no regarding as productive working time. This is what we have seen above.
The manager gets notified via an alert that this situation exists. And he knows that this week it was an extraordinary workload and that the employee only come in before the flextime bandwidth to deliver this time sensitive quote. And he wants to confirm the hours as normal hours worked. He can do so with recording in the employees time sheet a timetype of the new category "extra" . This time type categories speciality is that it can overlap fully or partially with the hours outside of the flextime bandwidth.
Lets record this kind of permission not for the full hour from 05:00 - 06:00 but only from 5:30 to 06:00 and let´s see what is happening:
Whats the effect of this new time type category that can be recorded overlapping with other attendance or even absence records? Well, it gives you flexibility in the time valuation to treat this time slice in a special way. In the context of flextime you can use it in a way that all times recorded outside the flextime bandwidth but covered with this new time type category are treated as times inside the flextime bandwidth - you can count them for flextime calculation, create pay types for it and just do the same as with your normal times. And this is exactly shown in the example above: The "unpaid times" are reduced from 1 hour to 30 minutes and the Working time account balance that was previously only 15 hours contain now with this permission 15 hours and 30 minutes. Hence the 30 minutes are now treated as "normal" working time and increase the flextime account.
Or, you can configure the time valuation that this times need to be treated in a special way like for example immediately calculate an overtime premium for it cause your business case is that all times recorded outside the flextime bandwidth but acknowledged by a manager / time admin are per se overtime.
Hence, this new time type category can be used quite flexibly when it comes to the time valuation calculations.
But this new extra category can be used independent of the flextime scenario as well. You can use it for example as pre-approval of overtime. A manager or time admin can record this time types in advance for next week for example from the end of an employees working time till 20:00. If an employee then records normal working time in that time span, you immediately can consider this times as overtime and generate an overtime payment for it. When an employee does not record working time overlapping with this extra-time type nothing happens. Cause it is only a kind of pre-approval. And when the employee records in the following week working time exactly in the same time slot but this extra time type does not exist - you just cut out this times in time valuation and don´t regard it as paid times, cause the "permission" is missing.
So, the important thing is that this new time type category can be recorded overlapping with existing attendances (or even absences). We don´t change or split the original record - cause this is what the employee has recorded as raw data and should not be changed. But with this new category overlapping you can let the original record untouched but still treat the overlapping part in a special way. This a powerful and flexible new thing. And of course you can configure in an employees time profile that this time type can only be recorded from a manager / time admin, and not by the employee himself. The employee gets this time type than in an display only mode.
And how is this all done in the time valuation?
Now I come back again to the time valuation rule some screenshots above where I mentioned that I come back to this later again ;-):
This time valuation rule with the valuation type "deduct group from input groups" takes all times summed in the "times outside the flextime bandwidth" group (which is listed as input time type group) and subtracts all possible times stored in the "Allowed flextime violation" time type group in the field "deduction group". And the "Allowed flextime violation" group contains the times recorded with the new "extra" time type category:
If I would drill down into the time type listed above you would see that the category of this time type is the new "extra" category.
So, I hope you are still with me. This was now admitted a little bit a deep dive into the time valuation. But I hope I could make the necessary configuration a little bit understandable for you.
As a key take away it is important to remember:
- We can support Flextime Bandwidth in the Workschedule
- You can cut out times outside the flextime bandwidth with time valuation rules
- You can send alerts when this situation exists to the Admin Alert UI (or many other alerts independent from the flextime scenario)
- A manager / time admin can monitor the alerts and just acknowledge them
- For the flextime scenario a time admin can record in special cases a kind of flextime violation permission
- And the new "extra" time type category can be used for multiple purposes, not only for flextime violation permissions but also for overtime pre-approval for example
But we are not yet full done with the flextime scenario. Cause when the employees can flexibly work as they want, how is it tracked that on the long run a employee works according to his work contract? This can be done with our already existing "working time accounts" or:
Flextime accounts
This is now a point I do not much elaborate on, cause this is existing feature. You can read in detail how to configure working time accounts in this blog: working time accounts
Here I just explain how our working time accounts - or flextime accounts- fit into this flextime process.
As you know the working time accounts perform a daily comparison of planned vs. recorded times. And when there is a delta this delta is posted to working time account. This can be either a positive value or a negative value. And this working time accounts can be used for your Flextime employees to ensure that they adhere to there contractual working hours in the long run. If an employee continuously works less than planned this results in an ever-growing negative working time account balance, does he work more than planned there is an growing positive balance which in turn the employee can use to take some off days with deducting the flextime account.
And now another new feature kicks in. Cause customers usually don´t want the flextime account to grow infinite into the positive or negative. There are often points in time it might be end of month, biweekly, end of quarter, end of year... where the balance of the flextime account shall be automatically checked and processed. And this is provided with our next new feature:
Automated periodical time account update
What´s this?
A regular, automated processing of time account balances at a specific point in time
And what´s that for?
As mentioned above: you can cap automatically time account balances at a configured threshold and in a periodical interval.
Let´s come from the UI first - it is easier to explain then. The new feature comes with a new time account monitoring UI. You get a list of all employees (own permission for this) that gives you for a selected date the employees having the selected time account assigned, their time account balances before the automated processing, the new time account balance after and of course what the automated update process has done. Currently we support only a cap of time account balances - but further potential enhancement ideas could be an transfer to a different time account or even an automated payout (but no concrete plans so far to support this - this depends on customer feedback).
So an example: You have got the rule that on the last day of a month the flextime account shall be capped at maximum of 40 hours. This amount can be transferred to next month, but not more.
The UI gives you now exactly this information to monitor what has happened:
You see for example that for Lisa Clark the balance before this automated run the balance was 53:00 hours. But then there was an automated minus posting of 13:00 hours according to the configured rule so that the balance after this process is 40:00 hours. Hence there was a capping of 13:00 hours.
From this UI you can navigate directly to the employees time admin workbench or even to the time sheet. This is necessary if you want to analyze the postings further, or if you want to correct them. Cause it might be that you have had a verbal agreement with Lisa that she can take over this month more hours than the 40, cause there was extra ordinary work load and she had not had the chance to take days off. And now there are several possibilities:
a) you can record in the time sheet an allowance type with 13 hours that is send to payroll for paying out the capped hours
b) you can go to the time admin workbench and record a correction of this automated update run. You can add or deduct hours and hence "undo" fully or partially what this automated process has performed:
But there could even be the case of a too big negative balance at the end of a cycle. When a manager monitors the time account balances with this new UI he will see that at the end of the period the negative balance is too big and he can for example create either in the time admin workbench or in the time sheet an unpaid absence that is replicated to payroll and a salary deduction is performed. Or you create an allowance type with the corresponding hours and payroll reads this specific allowance type as a deduction. Multiple of options....
The results of this automated time account updates are stored with a specific posting type, so you can even navigate into the history and check what previous automated time account updates had been done and you can report on it. The navigation is done with the selection date in the filter option.
But how is this all set up and what flexibility does it allow? Well, lots of.
You need to have first a "Time account update profile" in which the basic configuration is stored. This profile is assigned to the time account itself in a new field. And only those time accounts that have this profile assigned are processed. Second you need to have a business rule in which you maintain all the concrete parameters.
But lets first check the time account update profile. Here is an example:
This profile contains the update frequency like 4 weeks (or months), a reference date from which this weeks shall be counted and an offset in days. The offset is relevant when your flex cycle period is for example monthly and you want to ensure that all employees time sheets are handed in and submitted till end of month. With the offset you can give a little extra time, a small grace period to ensure that all time sheets are approved before this time account update is performed and time accounts are processed.
And you have got the business rule assigned in this profile. And in the business rule you know that you can do lots of things to steer what shall happen with the time account. You can use lots of rule parameters like for example considering future postings (after the planned next update) or not considering and many more options. Here is just an example that reads the employees average weekly working hours from the job info and caps then everything that is beyond this value and not considering any future recordings after the next update date, this means that for example even absences that are already recorded in the future and that deduct from this time account are not regarded:
So, you see, there is no fix value needed and you do not need to apply dozends of different profiles when you got lots of part time employees all having a different average weekly hours contract, you just need one profile, one rule that reads this value.
And there is much more possible: if for example there are some specific employees or employees in a specific department or location that you want to exclude permanently from this automated capping then you can define them in the business rule.
And you can even set a comment in the rule that in turn can be visualized in the time admin workbench to give some more explanations why and what this rule has been done. Check the comment in the rule above and compare it with what is shown in the time admin workbench in the comment section:
You see in the time admin workbench that
a) there is a new posting type "periodic update" that comes from this new business process
b) the comment box is filled with what you have maintained in the comment section of the business rule. This can be used for further explanation to the time admin / manager why a balance has been capped.
Let me stop here, think this is sufficient detail for this new feature. The only important thing that has to be mentioned is that this new function is currently only available for permanent time accounts not for recurring time accounts. Recurring time accounts can only be handled via the period end processing function.
But due to the fact that we are already in the time admin workbench an don the time account tab, let me briefly mention another minor new feature:
Delete / edit possibility for manual time account adjustments
This one is really briefly explained. Up to now there was not the possibility to edit or delete an already performed manual time account adjustment in the time admin workbench. If you have created a manual adjustment of +5 hours but you originally wanted to record only +3 hours, then you had to create another manual adjustment with a counterposting of -2 hours. And this pain point has now been removed by enabling an edit and even a delete of already existing manual time account adjustments - you can see the little pencil and dustbin icon in the time admin workbench for manual adjustments:
And since we are still dealing with time accounts, let me draw your attention to the next feature that was strongly requested from our customers:
ESS scenario to cash out leave
You know that time accounts can be paid out by a time administrator or a manager via our time administrator workbench:
But many customers have the requirement that employees are allowed to request for pay out. And cause we always listen to our customers we provide now a self service for time account payout. This will give your employees much more flexibility and ease your time administrators from lots of administrative and repetitive tasks and facilitate this whole business process in your company.
But how can an employee access the cash out leave scenario?
There is going to be a new extra tile on the homepage for this scenario:
and when clicking on it employees get an overview on the time account balances for the cash out-allowed time accounts:
He sees all the up-to-date time account balances as well as past payout requests with approval status.
He can then click on the "request payout" link on the respective time account and enter the hours or days (depeding on the time account unit) he wants to cash out:
You can upload an attachment if needed and upon submitting the request a workflow can be triggered (usually this scenario is used together with a workflow approval). When approved the hours / days are deducted from the time account and the cash out is transferred automatically to EC Payroll (Infotype 0015). Payroll calculates then the monetary equivalent of the requested days / hours and pays this out with the next payroll run.
A nice feature here is that upon submitting the request we show the workflow recipient:
Another nice thing is that as you can see on the left screenshot you can even enhance the pop-up with further customer specific explanations and a link to external leave or cash out policy documentation.
Some customers have got the requirement that this scenario is only enabled for employees during a specific time period in the year. For example from 1st March till end of April for last years time accounts. It is not possible to hide the cash out tile for the rest of the year, but you can create save rules that allow requesting only in that specific time frame.
Is each time account type going to be enabled for ESS payout? Only if you want. We of course deliver a configuration option for it. Cause most often not each and any time account shall be enabled for this ESS scenario but only specific accounts. Hence there is a configuration setting on time account type level. You can choose which time accounts shall be enabled for ESS cash out request and which time accounts shall still only be possible to be paid out by a time administrator. This is done in the time account configuration (manage data: time account type):
The relevant field for the configuration is the "payout eligibility" field. Not eligible means: no payout possible at all. The value "eligible" means that only time administrators via the time administration workbench can perform payouts and "eligible for self service" - is self explanatory ;-). This is the new option that allows the ESS payout service for this time account type.
But you can and need to do a little bit more. There is also a new "time account payout profile" that is assigned to the time account type as well and which need to be configured:
This profile contains for example the pay component info with which this time account shall be paid out (and in the pay component itself you define if EC Time shall calculate and hand over to payroll the gross monetary amount or just only the hours and days). You can furthermore assign a separate pay component for the termination process and for accruals on termination. And you can assign workflow rules and validation rules in this profile. Workflow rule is clear - you assign the workflow configuration here when you want to trigger a workflow. And the validation rules are helpful when you want to do eligibility and threshold checks. You can use them when you do not want to allow a payout leading to a remaining time account balance smaller then 10 days for example. Or you can even check not only this time accounts balance, but also other time accounts. Or you can check that an employee needs to have a specific service length in order to allow him a ESS pay out. As usual - the business rules give you lots of freedom and variability in configuration. And finally the time account payout profile holds the customer own explanatory text for the UI as mentioned above and with so-called standard BB-codes you can add an external url that holds for example company policies regarding the payout.
If you want to have a detailed step-by-step guide how to set this scenario up, then please check this blog from Ruchi Tandon:
Overview
Configuration step-by-step
Let´s come now to a feature that is linked to absences, but only relevant for one country: Australia.
Leave advance payment
This is a country specific topic developed for public service in the australian country version. Assume you want to celebrate your 10th wedding day with your wife at a special place and want to surprise your wife with fulfilling her long lasting dream of going once in a lifetime to Tanzania for a photo safari. This trips are usually quite expensive and you haven´t got sufficient savings to book this vacation. What could you do? Taking unserious loans at really high interest rates? Or asking your employer to pay your salary or vacation payments in advance? Latter would be more save to your health and more serious ;-). And asking your employer for payment in advance is possible in Australia. You can state together with your leave record if you want to have your vacation payment that you receive during the time of your absence already with the next pay cycle. And this is supported end-to-end from leave request via workflow to EC Payroll and payout.
So, if you use the country extension for Australia you can configure for which leave type you want to enable the possibility to choose leave advance payment. When employees choose this timetype they will see to additional check boxes in the lower right section of the leave request:
When they tick first checkbox they apply in general for leave advance payment.
When they tick second checkbox the payment is even splitted across financial years.
Of course this whole scenario does not fly without an integration to payroll. Cause payroll needs to know on the fact that it needs to payout money in advance. Our leave advance payment is only supported end-to-end in the integration to EC Payroll. In the SAP ERP country version for Australia there is a specific infotype that handles the leave advance payment, Infotype 0573. However, with the EC Time and EC Payroll in place the integration of this information will be handled completely through the IT2001 absence replication to EC Payroll. Hence, there is no need for maintaining IT0573 anymore.
Leave on half pay / double pay (and half / double time account deduction)
In some countries on this earth it is allowed to have a so-called double or half pay leave. The concept is quite easy to understand:
For half pay leaves: for on absence day only half day time account deduction is done. Sounds good - isn´t it? Cause then a 20-days vacation entitlement would turn out to last then for 40 off days. But, and here comes the little but, this days are not fully paid, but only half paid. So, half time account deduction, half payment.
Why is this possibility provided to employees? Cause it might be that their normal vacation balance is not sufficient any more to take 10 days off, they only have 5 days left. Then this is an option to enable nevertheless the employee taking his desired 10 days off - but at half pay.
The contrary is the double pay. For 1 day vacation you get deducted 2 days from your time account. Hmm - nobody would do this, wouldn´t you? 😉 Unless this is reflected in the payment - and here it is. Cause the employee gets then 2 days payment for 1 day off.
This scenario can be used where at the end of the year an employees vacation account balance is too big, he can´t take it fully till the end of the year and afterwards it might forfeit. Hence, he can take 5 days off at double pay. This means 10 days are deducted from the time account and he gets for this 5 days a double payment. Another example for this would be -just like above - the expensive poto-safari trip to Tanzania. He can afford this with "paying" double time account deduction. He spents 20 days for a two-week vacation but receives double payment for it so that he can afford his trip.
So, this scenario is closely coupled to payroll handling. EC Time itself does not generate payments, the scenario works only end-to-end with EC Payroll or SAP onprem payroll. How does it work in detail?
Quite simple. We brought a new "deduction factor" into our time type configuration. So you need to create a new absence timetype and maintain this deduction factor according to your needs - be it 50%, 200% or whatever percentage you need:
This is done in the absence counting method which is assigned to the timetype. And to make the effect of this time type transparent to the employee I would suggest to label the time type correspondingly as "half pay" or "double pay".
The time account deduction in EC is then done according to the configured deduction factor.
But how is this information passed to Payroll? Is there an additional infotype replicated? No. Our time type is replicated to the absence infotype in EC Payroll or SAP onprem Payroll. And there you need to take care that the absence counting method in EC Payroll / SAP onprem Payroll has the same deduction factor than in EC time configuration. Cause the absence calculation is triggered again in the Infotype 2001 and the deduction factor has an effect on the absence hours. And cause this special timetype is mapped to an SAP Infotype-subtype Payroll can use this and the calculated absence hours to adapt the salary payment as needed.
If you don´t find the deduction factor field in our absence counting method then make sure you have switched it on via configure object definition 😉
Alerting possibilities in time sheet
This is just a short one - in case you jumped directly to this heading. Cause I elaborated already in the Flextime section above on the new alerting capabilities out of the time valuation. In a nutshell again:
- you can create via time evaluation rules each kind of alerts to the employee and the time admin / manager. Be it if an employee has worked more than 10 hours, not sufficient break times, recorded times on an non-working day and much more scenarios. Everything you can detect in the time valuation can trigger an alert
- This is done with the new message type "alert and warning" in the time valuation rule
- The alerts are send to the Alert List where time admins / managers can confirm them as read.
And if you want to read more on the new Admin Alert 2.0 tool, check out this blog:
New features in Admin Alert 2.0
Simplification of time valuation results filter
This one will ease your time sheet / time valuation configuration to a great extend. It will reduce your long list of time valuation rules, reduce the complexity and make the configuration overall more transparent and simple.
You know that in the past we had filters that you could apply in a time valuation rule to detect if times have been worked on a specific weekday or on a specific public holiday in order to grant then a special payment for it:
However, the bad thing was - you were able to define only 1 weekday and not multiple weekdays. If the same special payment was for Saturday work, too, then you had to create a second filter. And based on the fact that you can only use one filter in one time valuation rule you already needed two time valuation rules. And this blew up the amount of time valuation rules. All not that nice, but we delivered an enhancement:
The new enhancement is now that you can add multiple days into a filter. So, if you want to check on working time on Saturday and Sunday vs. working time during the week you can add now multiple days to your filter:
When you apply this filter in a time valuation rule with the "Aggregate input group and split" method then you can route all times from Monday-Friday into the time type group below, and what is put then into the time type group above is logically the working times on Saturday / Sunday. And you have two different time type groups representing working time during the week and working time on the weekend.
But this is not yet the end of the story - cause we adapted an already existing time valuation method so that this new filters are even more powerful.
Cause, you might say: nice that I now can have multiple days in one filter instead of creating for each day a filter, but what about the start / end time conditions? Cause normally you have not only conditions on the day for creating specific wage types / payments or time valuation results, but also on top within an additional clock time span. Like for example: Monday - Friday from 18:00 - 22:00 you want to have a late shift premium generated. Or on public holidays between 00:00 and 24:00.
This was already possible in the past releases, but you have to have multiple time valuation rules to configure this. With the new approach, this is much more easier and transparent. Cause we enhanced the time valuation method "Filter Input groups" with the new filter options AND a start / end time condition. So, from the functional point of view this looks now a bit like the SAP ERP Time management table T510S for wage type generation ;-).
And how does this look like in EC time? As mentioned, take the above new filter for multiple days and use the new enhanced time valution method "Filter Input Groups":
So, overall to sum up:
- the time records filter are enhanced to include multiple days
- the time valuation type "Filter input Groups" was enhanced in a way that you can combine the time records filter with start and end times in one rule
This will reduce the amount of time valuation rules you need in your system and make facilitates the configuration and providing much more transparency.
Real planned working time replication to EC Payroll
Many of you now that the workschedule in EC Payroll infotype 0007 is a vital part for the payroll to work correctly. Payroll needs for lots of calculations either the correct planned working time of an employee or the average daily / weekly hours. Be it to calculate an unpaid absence correctly (monthly salary divided by the planned days to get a monetary value to deduct or 1 unpaid day) for tax reasons regarding correct company car tax calculations, for bonus payments calculations and many more payroll use cases. Or be it to have the correct absence hours calculated by from EC replicated absences - cause the absence quantity calculation happens again in EC Payroll and here again the work schedule is the basis for this.
But the problem till now was:
Currently the workschedule gets replicated from EC Time Job Info to IT0007 in EC Payroll. But first you have to double maintain the workschedule: in EC time and again in EC Payroll cause it is only a code mapping in the replication and both workschedules need to exist in both worlds. Second EC Time provides features like the so-called "individual workschedules" that cannot be replicated to Infotype 0007. And we have the possibility to perform short- or mid-term shift changes via the "temporary change of workschedule" which works similar to the IT2003 substitution infotype, so you can for example overwrite for next week the job info workschedule that contains a 5 working days week with a 4 day week shift but therefore the week after with a 6-days week. This feature is used for short term shift swapping for example. And this information is not replicated to EC Payroll, cause the job info workschedule was not touched physically.
But all this comes to an end now. Cause we provide a daily planned working time replication to EC Payroll and you get rid of double maintaining the workschedules and IT2003 records.
How is this working?
First a kind of process overview:
There is a day-by-day replication of the planned working time into the IT2003 record on EC Payroll side. This allows you to have only a few dummy workschedules on EC Payroll side and the real planned working time comes from EC Time on a daily basis. How you set up this dummy workschedule depends on your business needs - it can be a 24/7 workschedule, or you can have a couple of workschedules that reflects basically how your employees work contractually (like a 40 hours week with 5 working days a 8 hours). This depends a bit on what you need in payroll.
You can configure how long into the future the work schedule replication shall be done in advance (to cater for example for payroll simulation runs) and then the replication for this employee is only triggered automatically again for this period when changes are detected (like change of workschedule in EC or the recording of a temporary change of workschedule). This is done in a so-called replication period object. The default is 32 days into the future so that in any case for monthly payrolls the planned working time is provided for next payrolls run date.
And of course, when there are retroactive changes to the workschedule in EC Time (be it changes in the Job Info workschedule or by a forgotten short term shift change that is created retroactively via the temporary time object) then so-called replication proxies are set. This proxies are read by the replication program and from this date onwards the replication to IT2003 is triggered anew.
In the IT2003 record start / end time of the planned work time plus break information (coming from fix break schedules in EC Time or from dynamic breaks in EC Time) is replicated as well as the public holiday class to transfer even the public holiday information.
When absences are already replicated for a future period then of course they get re-evaluated based on this IT2003 record so that always the correct absence hour / days information is in EC Payroll.
If you want to use this replication only for a bunch of workschedules - cause for example you have already set up in EC Payroll the workschedules for a group of employees that don´t have got lots of shift changes - then you can stick for those employees to the existing IT007 workschedule replication method and not using the IT2003 replication. You can do so by entering those workschedules in a block-list that you want to exclude from the IT2003 replication. Each employee that has got this workschedule assigned is then excluded - but of course real short term shift swaps recorded in EC Time via the temporary workschedule function are nevertheless replicated.
When errors occur during this replication process you get alerts into the Admin Alert 2.0 List and you find more information on those in the Data Replication Monitor.
The whole integration scenario is very well documented - but you won´t find it in the EC Time implementation guide. It is described in the Employee Central Payroll Implementation Guide. There is lots of detailed explanation what you need to do - from setting the permissions, over the replication configuration, mapping of entities till the monitoring of this replication process.
Upload of planned time from shift planning systems to Employee Central on a daily basis
Another topic that is eagerly awaited by many customers. You might have got 3rd party shift planning tools in place where you do the shift planning and shift assignment. Each time management systems needs however correct planned working time information to perform overtime calculations and correct time account deductions for example. Hence if you are having shift planning systems and want to use the time evaluation and time account calculation mechanisms in EC Time, there was no other chance up to now than to double maintain the workschedules - which is admittedly not a real practical solution.
But now this has changed. You can now connect shift planning systems to EC Time. This is done with Odata APIs. You can send us per employee and day a shift via a day model. Or you send even for a period in advance a couple of day models. For each day one. Or you can even send if it is larger period a reference to a workschedule. Of course, day model and workschedule must exist in EC Time ! This is then loaded into the "temporary time information" object and gets of course displayed in the time administrator workbench (and can even be edited there). But it is not only updating the time administrator workbench - everywhere where the planned working time is displayed (in the time sheet Ui for example or in the employees workschedule viewer) or everywhere where the planned working time is used for calculation purpose this new uploaded information in the temporary time information object is read.
When absences are already in the system and you update afterwards with this API the temporary workschedule then of course the absence (or even time sheet) gets re-calculated again (when you have switched on the re-calculation what you anyhow should do). When this leads to error constellations those errors are shown in the Admin Alert 2.0 list.
Error situation could for example be: you load a week with 6 working days from the shift planning tool where previously based on the EC workschedule there was only a 4-days week and the employee has already requested a leave and only 4 days left in his account. As a result there is then not enough balance left for this absence in the time account. - But why would you load a shift change for an employee that has already got an absence recorded for this time? But it can happen.
And how is the upload done?
With an OData API call. This is an example of the structure and the import from 16th - 20th March of a day model CLT-Early shift:
This results then in an tempoary time information record for the period given in the Odata call.
And, as mentioned, you can not only import a day model, but also a reference to a workschedule. This can be used when an employee works for a longer period according to a specific workschedule and there is no daily re-planning in the shift planning tool. What you need to do is just to replace the "day model" parameter with a "work schedule" parameter in the Odata API:
Some things to consider when you want to use this:
- make sure in the temporary time information the field "day model" is set to editable (via configure object definitions)
- make sure the day models / workschedules you want to import exist in EC Time. If it does not exist you will get an error as response message in the Odata API
- make sure you have switched on the recalculation in EC Time. This is done in the Time Management Configuration Object. Either you trigger an immediate recalculation or you plan this as a nightly job for example
- The date values need to be passed with time UTC 00:00:00 to the API. For example, see http://www.epochconverter.com/ to transfer values. The value must be passed in milliseconds, for example 1581292800000 is the value for Monday, February 10, 2020 12:00:00 AM GMT
So, seeing those two enhancements around work schedule replication and import from shift planning systems this is overall now a nice end to end scenario, isn´t it? In external shift planning systems you perform the shift planning, this information is send to EC Time, employees record their absences and time sheets and based on the correct planned working time all the evaluation calculations are done. This updated workschedule information is replicated to EC Payroll into the IT2003 along with the absences into IT2001 and the time valuation results into IT2010 and Payroll has got all it needs for a proper payroll run.
Workflow Enhancements
And we have got two enhancements coming from the workflow team (many thanks to them !) that are very useful for time management processes as well:
Auto approval for leave requests and time sheet
This one is explained quickly. You can set in your workflow rule an option that you want to have the time sheet or leave requests workflow approved automatically after a certain number of days. The workflow is then set to approved when the number of days have elapsed after submitting the workflow and no one has either approved or declined it. This is useful when you for example want to ensure that specific workflows are not in the pending status for ages cause some managers do not take the approval as seriously as they should do.
Just set the corresponding option in the workflow rule and enter the number of days:
Delegation of workflows items
And the last really good workflow feature is the auto-delegation possibility. There is the possibility to choose another user as a delegatee for all your workflow requests. This is very usefull when you as a time sheet or leave request approver go for a 3-weeks vacation and you want that all workflows are automatically routed to a different person for this period. You can access this via the quick link section on the homepage:
You get then a dialogue in which you can enter another user as delegatee and the period in which this person shall be the delegatee:
But this process would be only of little help when the one who is entered as delegate is not notified on this or when he has no chance to reject this delegation - cause he himself is on vacation for a period for which someone else wants to delegate the approvals to him. Hence this person gets this request and he can either accept or reject. If he accepts the delegation request then all workflows are routed automatically to this person in the stated period.
And of course, this whole scenario comes with an own permission, means you can define in the target group of the permission who can be entered as a delegate - this is to avoid that each and any user can be entered as a delegate, but only those who shall be allowed to.
This was it. All new features in Q1 2020. And finally you made it till the end. I did cover only the major things we shipped - there are a couple of more time related new features mainly for the country version Australia and for public service - please refer to the release notes on this. Otherwise the blog gets really too long ;-). I hope you can use what we have shipped. Please feel free to add comments on the new features - if yo like them, if they are usefull... and especially comments to this blog. I would really like to know if you still find this blog useful- despite the length this thing has grown into. Cause next release we plan to have the same amount of cool new features that are long awaited for from customers. Just think on the big two topics that are missing in our EC Time solution. I give you a bit to think over it.....
Okay, no secrets, cause you can find this in our official roadmap: we plan to tackle cross midnight (first for absence recording, afterwards attendances) and clock in / out integration with terminals and other time devices, and of course a bunch of other good things.
So, stay tuned. Give me feedback whether this lengthy blog is useful or not.
Take care, stay healthy and save.
Volker Ruof
EC Time Product Management
- SAP Managed Tags:
48 Comments
| User | Count |
|---|---|
| 5 | |
| 4 | |
| 2 | |
| 2 | |
| 2 | |
| 2 | |
| 1 | |
| 1 | |
| 1 | |
| 1 |
