- SAP Managed Tags:
Hello EC Time folks,
autumn has finally arrived in Europe, again another year comes close to its end and the last release for 2018 is about to be released.
As usual I gonna give you a bit a more detailed look onto the new features for EC Time. Some business backgrounds and some deeper insights than this could be possible in our implementation guides. Especially one topic needs due to its importance and business complexity be explained in more detail. I am talking on our new feature "dynamic break" which I am really glad to announce. Some call it "minimum break deduction" also. It´s a topic that is needed for flexibilization of working time as well as to help customers adhering to working time laws and regulations and a topic that was long due in our time solution. Big topic, even in this blog ;-).
But let me provide first the overview on all of our new features:
Before I get to the dynamic / minimum break details let me first draw your attention to our new time off user interface - cause new end user user interfaces always brings the necessity of end users to get familiar with the new tool and this switch needs to be prepared well and communicated good by existing customers:
You know this User Interface:
This is the Time Off leave request and time account balance overview user interface. Currently used by more than 800 customers around the world.
In Q4 we deliver a new Time Off user interface. But no worries, for existing customer there will be a transition phase. We know that a new end user interface causes always trouble for some users to adapt, things look different than before, user experience is different. This is why we ship the new user interface now and plan to retire the old one only around mid 2019. This gives existing customers enough time to get aquainted with the new look and feel, update end user training material and how-to-guides.
So, in a nutshell:
The new user interface will be based on SAP UI5 technology and with so-called Fiori style patterns.
Let me provide you a glimpse on how this new user interface is going to look like. Here we go:
As you can see the look and feel is different than the old UI. The calendar is more prominent and on the right side you got the time account balances displayed and below the upcoming time off events.
Due to the fact that a new end user interface always bring a bit of disruption for existing customers we recommend that you switch on this new user interface in your test landscape and get familiar with this new look and feel. It is not possible to switch it on only for a limited employee group, the switch is for the whole company. So there is not the possibility to have in your productive landscape a small population using the new one and the larger still using the old one. Therefore, switch it on in your test instance and get familiar with the new user interface there.
Why did we develop a new user interface?
First it is build on state of the art user interface technology SAP UI5 Fiori patterns. Second we designed it to be a bit more like a mobile application. And third we provide cool new features in this user interface that provide a real benefit for end users:
So, whats new in the new Time off Ui?
The whole application looks more modern and app like. We provide a new color codeing that represents not the time type as it was up to now, but the approval status of the record. A user sees on a glimpse what records have been approved or are still awaiting approval. And of course we provide a legend for the calendar colour codes that makes it easier for end user to understand the visualization. But that´s not all:
Display of public holidays
A small enhancement - but with a big usability effect and lots of employees will love it.
In the "upcoming time off" section we show not only the future dated absences as it was in the past, but also the public holidays that are upcoming. And you even can toggle between showing only the upcoming public holidays, upcoming absences, both or also for all options the historical data. Why is this useful?
Well, you might know this year-to-year activity where one checks the next years calendar on web calendards to find out if a public holiday lays good enough for taking a bridge day and spending a prolonged weekend with your family, book right in advance a cheap city-travel-trip or some hotels in the mountains or arrange something with your friends or familiy. What if you would not need to consult external calendars, but can see this in the application where you need to request your leave anyhow?
Tataaa: with our list of public holidays in the upcoming event section you can do this right there! Small enhancement with a big usability effect I believe. At least I am always keen on finding out when the next public holiday comes ;-). This is how this looks:
(Apologies for the mixed language - this was screenshot is taken from an early development phase).
And here is the list of upcoming and historical absences.
The tab "all" shows the combined list.
I think this feature alone is worth to switch to the new UI 😉
Recurring absences enabled for employees
We enabled the "recurring absence" feature now for endusers also in this UI. You might know that in the time admin workbench a time admin had the chance to record an absence with a recurrence option - a bit like a series in an outlook calendar. You could record for example with a few clicks a vacation for each monday the next 3 months. Looks like this:
There is a check-box for employees where you can switch the "recurrence" on and you define then the type of recurrence - daily, weekly, monthly and when this series ends. The system creates then as many single records as you have defined.
And this feature is now available not only for time admins but also for the employee himself. This eases recording of recurring absence events to a great extend. There are customers who provide working time accounts or long term accounts to their employees and they can compensate this with a 6-months sabbatical or with 1 year reducing not the contractual working time, but the "real" working time with having the next year each Monday off by deducting this time account. In SAP ERP Time an employee has to record 52 single records - this costs at least 15 minutes boring activity. With our new feature this is done in 5 seconds.
Split and delimit is supported
Another function that worked previously only for absences recorded in the time admin workbench: "split and delimit" of absences when they overlap. You can configure your absence collision checks not only in a way that in the case of overlapping recording of absences an error is createdit that prevents this action. But you also can configure a "stronger" absence that overwrites an existing one and even splits an original record. Why should this be done?
Cause it facilitates time recording. Imagine an employee is on a 3 week vacation and he gets inbetween 1 week ill. Before the split and delimit feature was delivered neither an employee nor a time admin could record the illness cause it ended up in an error saying that there exist already another absence. You had to manually touch the original record, create two out of them with a gap in between and create the illness afterwards into the gap. Cause you can´t have parallel absences. Now, when you use the split and delimit the "stronger" absence gets cut into the existing absence and the original record splitted automatically. Hence, you don´t need to delete the 3 weeks vacation, create a vacation record before the illness, the illness record itself and then the vacation after the illness. You just need to record the illness record and the overlapping vacation record gets automatically delimited and splitted into two records. This feature was possible when a time admin recorded the absence, but not when an employee has recorded the illness. And this has changed with the new User interface.
So "split and delimit" of absences is supported for an employees absence recording with this new user interface.
Now, how is the upgrade / transition done?
As said, new customers will get only this new user interface from Q4. There is no chance to switch on the old one for them.
For existing customers there is the already mentioned transition phase in which you can test and get your experience with this UI, provide us feedback, prepare and update your end user documentation and guides. This transition phase will end probably mid 2019 and the old user interface will be terminated.
You can switch on the new time off user interface very easily via the upgrade center. Go to the administration tool, search for upgrade center and there for the time off fiori. With one click you can activate it.
So, most important thing here: try out this new user interface and give us feedback if you like it or not. You can use the comment boxes below to give feedback.
Lets come to the next topic. This one is a big and complex topic, but makes our Time Product much more flexible and eases break handlings of customers and flexibiliazation of working time. It is called:
Break handling in time management can be a very complex and nasty topic. A simple regulation like: an employee should not work more than 6 hours without having a break of 30 minutes can easily end up in quite a complexity in real business life as soon as you think of constellations like: an employee records working time, but has got gaps in between or partial day absence records or did only work 06:10 minutes.
But one step after the other, let me first explain what this new feature is about.
Currently in EC Time Management only "fix breaks" are provided. This means you have got a break in your daily workschedule with start/ end times. When an employee records an attendance record or even an absence record that overlaps with this defined break a break time type gets generated in the time sheet and for the absence record the break reduces the absence quantity.
This "fix breaks" are not really flexible. When an employee starts his working time at 11:00 and has got a break defined from 12:00 - 13:00 than already after 1 hour the break gets generated. Or when he starts at 13:00 no break is generated, cause there is no overlap. Not really good.
With the new dynamic break variant we can cover those use cases and provide a much more flexible usage of breaks. You can define one or multiple durations after which a break shall be generated. So for example:
After 6 hours of working time 30minute break
After 9 hours additional 15 minute break
After 12 hours again an additional 15 minute break.
The most important thing for the new break is that we collect the recorded working time and absence times and generate a break after a specified number of hours after the start of the first working time / absence time.
This is the "dynamic break" feature in a nutshell. For those readers who just want an overview you better skip the next passages, cause we deep dive into details. For those who want to promote this feature, implement it, consult it, please read carefully. There is a lot of underlying complexity and assumptions we had to do to provide a best practice solution without having a configuration monster. Due to the complex nature of this topic there are some constellations where a customer might expect a different behaviour. And it is very crucial that these constellations get discussed and clarified with the customer before the feature is implemented.
1.) Set up of the new dynamic break
Fix breaks are configured in the daily workschedule of an employee. Hence the new dynamic breaks are NOT configured in the workschedule, but in a new configuration object which is assigned directly in employees job information. Why did we do this? Couple of reasons.
First is that this kind of break deductions are not bound to a daily workschedule, but are rather generic trade union regulations, business process rules or even part of laws / legislative regulations on working time. So, whatever daily working time an employee has got, this kind of rules are always valid. This is why the workschedule is the wrong place to assign this rule, but the job information the appropriate one.
Moreover, for a customer work schedule maintenance is getting even easier: You create this rule once and assign it to all employees. You don´t have to repeat this break information (which are to 90% always the same regulations) for each and any daily workschedule time model anymore.
Furthermore situations are covered where an employee needs to work overtime on a weekend or a non-working day. If you want to have an automated break deduction usually you could cover this only by assigning a break to a day model that was marked as non-working day which worked, but was maintenance effort and not really nice. And even you could not know if the break from 12:00 - 13:00 was suitable, cause the employee could work his overtime starting from 14:00 - 21:00 for example and then no automated break deduction would have been applied. With the fact that the new break rule is assigned in the job information it applies for all days - working days and non-working days. Again a facilitation of configuration and handling of our system.
How does the new configuration object look like? Quite simple:
You can see the header information like external name, code and description. In the lower part you see then the definition of the break time. You can enter the time that needs to pass and then the break duration in minutes that shall then be generated. We labeled the field for simplicity reasons "working time" - but you will see that this is not limited to "working time" only but includes absence times as well. Take this field as duration that needs to pass for a break deduction.
The list is limited to 5 break definitions - I haven´t experienced more than 3 in my consulting times, so this must be sufficient.
Last step is to assign this new break rule in the employees Job Information:
And you are done. Dynamic break defined and assigned. Quite easy isn´t it?
In really complex time management implementations projects dynamic break handling takes long time of finding out what customers really do in non-standard constellations where not only a working time record from 10:00 - 19:00 exists. There are lots of time to be spent to analyze and configure and depending on the software even based on customer specific coding. Cause in real business life strange constellations can come together and all should be handled correctly with respect to break handling. We are a cloud product and we always have to find a balance of a cloud software that can´t and won´t provide as much flexibility and complexity than an onprem solution (cause you don´t want to have month or years of implementation time) but yet offer best business practises and a set of configuration options to fine tune these. Due to the incremental development process in our cloud world we ship this feature without much configuration possibilites cause based on the best practise approach this feature can already be used by many customers without much more configuration. However, we are already working on more configuration options and will enhance this feature in the up-coming releases with more options. I´ll come at the end of this topic to some words on this.
One last remark regarding configuration before we get to calculation examples: You can have a workschedule assigned to an employee that contains fix breaks AND in the job information a dynamic break assigned. There is no error thrown. However, this makes not much sense. Either you have a fix break or a dynamic break. When both is true for an employee on a given day, the dynamic break rule is not processed, but only the work schedule breaks. And this is done by design, cause it gives you a further possibiliy:
You will see in the next section that the dynamic break deduction cannot be changed by an employee. The break gets generated, an employee can´t edit or delete it. However, there might be constellations where you want to switch the dynamic break generation of, cause there was really an extraordinary circumstance where the employee really could not take his break. Or only a few minutes break and not the full configured break. In this circumstances a time administrator can create an "temporary change of workschedule" using an individual workschedule that contains the employees planned time plus a different break. The dynamic break does not get processed then, cause now a work schedule break exist for this day. The break can even lay outside of the employees performed or planned time - the dynamic break gets not generated and the employee experiences than no break deduction at all.
So, this is a way to "overrule" in very specific circumstances the dynamic break generation.
Now, lets come to the examples to show you how we calculate:
2. Examples of dynamic break handling
Lets get to the tricky part - how the break deduction is done in reality. Step by step I gonna set up more complex examples to show how our break generation / deduction works. One thing I need to mention right in the beginning: when I use the term "break deduction" this means for time sheet that a break time type is generated. However, this does not yet mean that the break reduces automatically the recorded working time for time valuation or payroll purposes. If you want to calculate premium pays, working time accounts or any other time valuation results in net times - without breaks - you need as a first step in time valuation deduct the generated break time type in time valuation rules using the aggregate input group and split operation from overlapping attendance or absence time type groups. So same behaviour as for fix breaks: here you need to configure time valuation as well in order to deduct breaks for time valution result purpose. Otherwise you have only a break time type that you can see in the time sheet but nothing else, no reducing of working time by the break for example. So you always have to use time valuation rules to consum the break time type that is either recorded or generated. How this is done is explained in the time sheet implementation guide. This approach gives you even some more flexibility, you can for example configure that a break shall not be deducted in the time valuation result when a "travel time type" is recorded. This would have the effect that although there is a break time type generated you do not reduce the travel time time type in time valuation with this generated break.
And, important as well: for absence records (see examples below) there is no break time type generated in the time sheet. The absence quantity gets automatically reduced by the breaks "under-the-counter". Time Sheet just reads then the already by the break reduced absence record. This is based on the fact that you can use dynamic breaks for time off only as well. You don´t have to have time sheet.
So, back to the examples. Lets assume for all examples a dynamic break configured like:
after 6 hours 30 minute break and after 9 hours additionally 15minute break
2.1 Break in normal working time
An employee records working time from 08:00 to 18:00. Straight forward, just 1 record of working time. As a result you get in the time sheet two breaks automatically generated:
Break from 14:00 - 14:30 (cause after 6 hours) and a break from 17:30 - 17:45 (cause at 17:30 9 hours of working time have passed. The first generated break does not count as "working time").
2.2 Working time with gaps
Now lets come to a more complex constellation. The employee records working time from 08:00 - 12:00 and from 14:00 - 17:00. So, there is a gap of 2 hours in between of the recorded working times. What shall we do here? Is the gap itself to be regarded as break and hence no further break deduction should be done?
No. We do not regard the gap as a break at all. When the employee wants to document this as a break he needs to record manually a break time type and then no further automated break deduction is done (see next example).
Hence, the result of the break generation is:
A break is generated from 16:00 - 16:30 cause at 16:00 6 hours of working time have been reached. The gap is not counted as a break.
This might be one additional point that customers would like to configure - and we are already working on it. Hence in future it is planned that a customer can configure if gaps in between working time shall automatically be regarded as a break or not.
2.3 Working time with a manual recorded break
The dynamic break is a mandatory break that gets automatically generated and that cannot be edited by an employee. However, you might have the constellation that employees record manual breaks, too. Or you use our import API with which you can upload working time and breaks from 3rd party systems. So lets assume you have got a working time record from 08:00 - 18:00 and a manually recorded break from 10:00 - 10:15.
Now the question is: does this manual recorded break outrule the dynamic break configuration?
Answer: No. The recorded break does not outrule the dynamic break and due to the fact that the break is not sufficient according to the configured dynamic break there needs to be an additional break generated. Hence the result is the manual recorded break from 10:00 - 10:15 plus a generated break of 15 minutes from 14:15 - 14:30 (cause after 6 hours) plus another break from 17:30 - 17:45 (cause after 9 hours).
The important thing here is that the manually recorded break is not sufficient and we auto-generate the remaining mandatory break according to the configured dynamic break rule.
And of course the dynamic break gets not only "dumb" generated, but considers the manually recorded break so that overall the configured rule is met including manually recorded breaks.
2.4 Full day absence
Employees go on vacation or are ill or got other full day absences. Do we need to take care on this? Absences are absences and most of the regulations say literally "after 6 hours of working time" - like the European Regulation on Working Time for example. Well, unfortunately official laws and regulations are not formulated out of a time management software perspective cause otherwise they would be a bit clearer in its messages.
So, yes of course, we need to consider dynamic breaks for full day absences as well. Imagine an employee requests a full day absence that deducts the working time account. His planned working time from 08:00 - 17:00 is used to calculate the time account deduction quantity. But the employee hasn´t got 9 hours of planned time - cause planned breaks need to be deducted. The time account deduction should not be 9 hours, but 8 hours. Just like the employee would have with a workschedule fix break from 12:00 - 13:00. Here, the break reduces the absence quantity or time account deduction as well. And in order to not deduct wrong amount of hours from a time account the dynamic break deduction needs to be performed for absences as well. So, just like a configured fix break the new dynamic break reduces the absence quantity. The start time of the absence record is taken and then the dyamic break rule applied.
Note: in the time sheet you won´t see a generated break time type in this constellation. This is done based on the fact that time sheet reads already the absence record reduced by the break. This is why a break time type is not generated, cause the so-called "net-record", reduced by breaks, is read by time sheet. But this is nothing dynamic break specific, cause this is already happening for fix breaks in the same way.
2.5 Working time and partial day absence
Stay with me, this is the last example. Promise. But probably the most complex one. Employee records working time from 08:00 - 15:30 and he leaves earlier, hence he records a partial day absence from 15:30 - 18:00. Now, this is tricky. Where to place the breaks?
First break is clear: after 6 hours of working time a break of 30minutes is generated. Hence from 14:00 - 14:30 a break time type is generated. And the absence record? Absence records are regarded just as working time (see previous example), hence the 2.5 absence hours are added to the recorded working time and the absence quantity gets reduced by the 15 minute break so that at the end the break has got only a deduction quantity of 2:15. Why is this? Cause again, when the employee would fully work there would be a break deduction cause this break is "planned" according to the configured rule. And here it is the same as for the full day absence example: there could be a time account deduction necessary and this needs to be correct. Or other example: there is a daily overtime calculation. When the employee has got a planned time from 08.00 - 18:00 and records working time from 08:00 - 15:30 and an absence from 15:30 - 18:00 (and absence records mostly count for daily overtime calculations) the employee would receive 15 minutes overtime pay when we would not reduce the absence hours by the dynamic break.
Enough of this examples ;-). I hope you could get an understanding that there are tricky constellations possible that need to be handled in one or the other way. We did apply best business practices to handle those. As mentioned for gap handling and probably even for absence handling there are in future releases more configuration options planned.
2.6 Full or partial break deduction?
Another planned configuration option - and this is now really the last thing I want to touch for the dynamic break topic - is what shall be done when there is not sufficient working time remaining for a dynamic break deduction.
So an employee has got working time of 6 hours and 10 minutes. What to do? Shall the full 30 minutes break be deducted that the employee ends up with less net hours as his colleague who left earlier after 5:55 hours? In this release we generate only a break for the time that is beyond the configured threshold, so a break of 10 minutes is generated. But we are already working on another configuration option that you will be able to set up for this kind of constellations if the break shall be fully deducted (30 minutes) or only partially (10 minutes).
2.7 Important things to know
You see, all in all a very big and complex topic. Here are in a nutshell and as a summary what you need to take away:
These were the two main topics of the Q4 delivery. But we have also done some smaller parts:
Since a couple of releases we have got this API for internal replication of time account balances to SAP onprem or EC Payroll. This API is now public available and can be used for other payroll systems or other applications.
What does this API do? You can create a time account snapshot for a given date. This can also be a date in the future. And the machinery is started and creates a record in the database with the time account balance. The time account snapshot as such exists since Q2 2017 (see my blog on that release for more details). The new thing is now that the API to read the time account balances is general available to extract the records.
Just a quick reminder how you create the snapshots: You do this via the calendar runs:
You run the snapshot per time account type. Read the documentation in the time off implementation guide for more details on the time account snapshot (but be careful: don´t mix the term with the time account snapshot report - same name, but one is a real report in the report center, the other a snapshot that stores data on the database that can be extracted.
We introduce new hard coded time sheet attributes. The main purpose of these new attributes is first and foremost internal time sheet processing, to speed up and optimize calculations, internal jobs and to have more attributes to hard code on for faster time sheet processing. But customers can use this new attributes as a filter criteria in reporting or in business/workflow rules as well.
The new attributes are:
- Full time sheet
Is set to yes when a time sheet covers in sum planned working time either with attendance,
absence or break records
- Absences
Is set to yes when at least one absence is recorded in the time sheet
- Manual entries
Is set to yes when at least one manual time recording (attendance, break, on call or allowance) is
recorded in the time sheet
- Imported entries
Is set to yes when at least one via the “external time data service” imported time record (attendance, break or on call) is in the time sheet
- Generated entries
Is set to yes when at least one system generated time record (attendance or break) is in the time sheet
- Time Recording Method
Contains the time recording method of the employee in the time sheet period (positive, negative or overtime)
Why do I mention this rather technical things? First we are using this attributes to automate processes:
Currently when for a positive time recorder a time sheet is full of absence records cause the employee is on an one week vacation he needs to submit this time sheet manually in order that paytypes are generated when the absence is paid and the employee is a hourly employee (or when salaried and the absence time period is paid differently than his normal salary - including shift differentials for example). Which is a bit cumbersome cause the employee is on vacation but the time sheet needs to be submitted manually in order to get the absence time paid. We are currently working on a new feature that automatically submits this time sheet. And here we are reading this new attributes: for a positive time recorder when the attribute "full time sheet" is yes and "absences" is yes and "manual entries" and "imported entries" is no, then the time sheet is full of absences and can automatically be submitted.
Second, customers can use this attributes in business rule, time sheet input validations and in workflow rules. Lets stick to above mentioned time sheet. When you have assigned a workflow rule to a time sheet the workflow gets triggered for each time sheet. Even when it is full of absences. You might now ask - well, the one week vacation has already been approved by the time off request why does the time sheet than needs to be approved once more? And here you can use the above mentioned attributes in your workflow rule. You can use them and find out if a time sheets consist only of absences. If so, you do not trigger a time sheet approval and the time sheet is automatically approved. This reduces the workflow inbox of your managers. Again a small enhancement but customers approver will be thankful.
Third we need to do other hard coded things in order to process algorhitms and to optimize performance so that the application is even more faster. This hard coding depends on certain assumptions that we need to do. And basic assumptions are that time types which are in its business meaning an absences are configured as absence time type and time types that are in its business meaning an attendance are configured as attendance time type and maintained in the time sheet (and not in the time off UI for example).
So what makes an absence to an absence and an attendance to an attendance? This question is quite simply answered:
When the employee is active doing something for the employer which is regarded as productive time it is an attendance.
When the employee is not active doing something it is an absence.
So: vacation, illness, jury duty, strike, working time account deductions, time off in lieu deductions, are absences. I am not active doing something for the employer.
Working time, overtime, home office, training, business travel, travel time - are attendances, cause I am active doing something for the employer.
This distinction is important and important to follow in your implementations. As mentioned, the above set parameters are used for internal time sheet processing. And they are hardcoded based on for example if an absence exists or not. And when you use for example a timetype with an absence category for "home office" - which is not an absence but an attendance - it might lead to wrong internal follow up processings.
Or take the daily sums and the bar charts that are displayed in the time sheet. The calculation of this is hardcoded by the clear distinction on what is an absence and what is an attendance record. When you configure absences facts as an attendance or vice versa this leads to weird effects and confuses your employees, cause the visualization and calculations are not correct anymore.
Next topic is the blocking of time account details for permanent time accounts. This is relevant for data protection and privacy where we already have delivered configurable purging, blocking, read access and change log and information report (see my Q1 blog 2018 for details on data privacy features).
This feature is a round-off to the already delivered features. Recurring time accounts and it´s postings could already be blocked from access for example by a time admin or a manager when the time accounts end date has passed 3 years. But for permanent time accounts this was not possible - cause permanent time accounts do not have an end date. And when the full time time account is blocked than a time admin or a manager does not see the balance or anything else of this time account. Hence we needed to separate the time account postings for blocking purpose from the time account itself. This new feature allows now to block the details separatly from the time account. You can configure the system that the actual balance is visible and the postings to and from this time account for example only for the last 2 years in the case of a permanent time account for specific user groups. This enhances date protection and privacy.
This is not really a new feature - it is rather a description how this really complex paid leave entitlement for sicknesses in South Africa can be covered with existing functionality.
In South Africa employees got a 3 years sick leave cycle of paid leave. The basic conditions for employment (BCOE) for South Africa stipulates that Sick Leave should be based on a 3 year cycle, but pro-rated in the first year. New Hires 1 day a month for first 6 months, then 24 days on the 7th month. This cycle is for 3 years, when your 2nd cycle starts you get 30 days upfront for the next 3 years.
We received this request from many customers in South Africa as it is a legal requirement. And based on the fact that in Employee Central only monthly, yearly or permanent time accounts but no 3-years time accounts are possible it did cost a bit of brain power to find a solution for this. Well, this time the brain power did not come from me, but from my colleague Hans-Georg Bingler with support from the time off development team. They found a solution that was accepted by the South African Customers. If you are interested in the concrete requirement and its solution proposal you can check either the Country specific time off documenation or in the solution proposal described on the influence.sap.com page.
For Time Off and the Time Administrator Workbench a deep link did already exist, for Time Sheet now as well.
Last but not least let me mention some new mobile time enhancements. It is now not only possible for positive time recorders to use the mobile time sheet, but also for negative and overtime recorders.
If you aren´t familiar with the terms "positive", "negative" (no, this is not only time off recording) or "overtime" recording please consult my other blog where I shed some lights on this philosophical time management aspects ;-).
Are you a negative or a positive time recorder?
That´s it. Sorry for the many words on the new features but especially the dynamic / minimum break needed some explanations so that everyone understands what happens in detail when this feature is used. I hope I could make it a bit clearer.
Stay tuned, as usual you will get news on the Q1 features 2019 in about 4 months.
Take care and have nice christmas / years end vacations.
Volker Ruof
Product Manager EC Time
autumn has finally arrived in Europe, again another year comes close to its end and the last release for 2018 is about to be released.
As usual I gonna give you a bit a more detailed look onto the new features for EC Time. Some business backgrounds and some deeper insights than this could be possible in our implementation guides. Especially one topic needs due to its importance and business complexity be explained in more detail. I am talking on our new feature "dynamic break" which I am really glad to announce. Some call it "minimum break deduction" also. It´s a topic that is needed for flexibilization of working time as well as to help customers adhering to working time laws and regulations and a topic that was long due in our time solution. Big topic, even in this blog ;-).
But let me provide first the overview on all of our new features:
New Time Off User Interface
Dynamic Break deduction
Time Account Snapshot API
New time sheet status
Blocking of time account details for data privacy and protection
South African 3-years sick leave cycle
Time Sheet deep link
Mobile time enhancements
Before I get to the dynamic / minimum break details let me first draw your attention to our new time off user interface - cause new end user user interfaces always brings the necessity of end users to get familiar with the new tool and this switch needs to be prepared well and communicated good by existing customers:
1. New Time Off User Interface
You know this User Interface:
This is the Time Off leave request and time account balance overview user interface. Currently used by more than 800 customers around the world.
In Q4 we deliver a new Time Off user interface. But no worries, for existing customer there will be a transition phase. We know that a new end user interface causes always trouble for some users to adapt, things look different than before, user experience is different. This is why we ship the new user interface now and plan to retire the old one only around mid 2019. This gives existing customers enough time to get aquainted with the new look and feel, update end user training material and how-to-guides.
So, in a nutshell:
- new time off customers will only get the new user interface
- existing customers can use the exisiting time off user interface till approximately mid 2019. Then the old time off User interface will be switched off.
The new user interface will be based on SAP UI5 technology and with so-called Fiori style patterns.
Let me provide you a glimpse on how this new user interface is going to look like. Here we go:
As you can see the look and feel is different than the old UI. The calendar is more prominent and on the right side you got the time account balances displayed and below the upcoming time off events.
Due to the fact that a new end user interface always bring a bit of disruption for existing customers we recommend that you switch on this new user interface in your test landscape and get familiar with this new look and feel. It is not possible to switch it on only for a limited employee group, the switch is for the whole company. So there is not the possibility to have in your productive landscape a small population using the new one and the larger still using the old one. Therefore, switch it on in your test instance and get familiar with the new user interface there.
Why did we develop a new user interface?
First it is build on state of the art user interface technology SAP UI5 Fiori patterns. Second we designed it to be a bit more like a mobile application. And third we provide cool new features in this user interface that provide a real benefit for end users:
So, whats new in the new Time off Ui?
The whole application looks more modern and app like. We provide a new color codeing that represents not the time type as it was up to now, but the approval status of the record. A user sees on a glimpse what records have been approved or are still awaiting approval. And of course we provide a legend for the calendar colour codes that makes it easier for end user to understand the visualization. But that´s not all:
Display of public holidays
A small enhancement - but with a big usability effect and lots of employees will love it.
In the "upcoming time off" section we show not only the future dated absences as it was in the past, but also the public holidays that are upcoming. And you even can toggle between showing only the upcoming public holidays, upcoming absences, both or also for all options the historical data. Why is this useful?
Well, you might know this year-to-year activity where one checks the next years calendar on web calendards to find out if a public holiday lays good enough for taking a bridge day and spending a prolonged weekend with your family, book right in advance a cheap city-travel-trip or some hotels in the mountains or arrange something with your friends or familiy. What if you would not need to consult external calendars, but can see this in the application where you need to request your leave anyhow?
Tataaa: with our list of public holidays in the upcoming event section you can do this right there! Small enhancement with a big usability effect I believe. At least I am always keen on finding out when the next public holiday comes ;-). This is how this looks:
(Apologies for the mixed language - this was screenshot is taken from an early development phase).
And here is the list of upcoming and historical absences.
The tab "all" shows the combined list.
I think this feature alone is worth to switch to the new UI 😉
Recurring absences enabled for employees
We enabled the "recurring absence" feature now for endusers also in this UI. You might know that in the time admin workbench a time admin had the chance to record an absence with a recurrence option - a bit like a series in an outlook calendar. You could record for example with a few clicks a vacation for each monday the next 3 months. Looks like this:
There is a check-box for employees where you can switch the "recurrence" on and you define then the type of recurrence - daily, weekly, monthly and when this series ends. The system creates then as many single records as you have defined.
And this feature is now available not only for time admins but also for the employee himself. This eases recording of recurring absence events to a great extend. There are customers who provide working time accounts or long term accounts to their employees and they can compensate this with a 6-months sabbatical or with 1 year reducing not the contractual working time, but the "real" working time with having the next year each Monday off by deducting this time account. In SAP ERP Time an employee has to record 52 single records - this costs at least 15 minutes boring activity. With our new feature this is done in 5 seconds.
Split and delimit is supported
Another function that worked previously only for absences recorded in the time admin workbench: "split and delimit" of absences when they overlap. You can configure your absence collision checks not only in a way that in the case of overlapping recording of absences an error is createdit that prevents this action. But you also can configure a "stronger" absence that overwrites an existing one and even splits an original record. Why should this be done?
Cause it facilitates time recording. Imagine an employee is on a 3 week vacation and he gets inbetween 1 week ill. Before the split and delimit feature was delivered neither an employee nor a time admin could record the illness cause it ended up in an error saying that there exist already another absence. You had to manually touch the original record, create two out of them with a gap in between and create the illness afterwards into the gap. Cause you can´t have parallel absences. Now, when you use the split and delimit the "stronger" absence gets cut into the existing absence and the original record splitted automatically. Hence, you don´t need to delete the 3 weeks vacation, create a vacation record before the illness, the illness record itself and then the vacation after the illness. You just need to record the illness record and the overlapping vacation record gets automatically delimited and splitted into two records. This feature was possible when a time admin recorded the absence, but not when an employee has recorded the illness. And this has changed with the new User interface.
So "split and delimit" of absences is supported for an employees absence recording with this new user interface.
Now, how is the upgrade / transition done?
As said, new customers will get only this new user interface from Q4. There is no chance to switch on the old one for them.
For existing customers there is the already mentioned transition phase in which you can test and get your experience with this UI, provide us feedback, prepare and update your end user documentation and guides. This transition phase will end probably mid 2019 and the old user interface will be terminated.
You can switch on the new time off user interface very easily via the upgrade center. Go to the administration tool, search for upgrade center and there for the time off fiori. With one click you can activate it.
So, most important thing here: try out this new user interface and give us feedback if you like it or not. You can use the comment boxes below to give feedback.
Lets come to the next topic. This one is a big and complex topic, but makes our Time Product much more flexible and eases break handlings of customers and flexibiliazation of working time. It is called:
2. Dynamic break handling
Break handling in time management can be a very complex and nasty topic. A simple regulation like: an employee should not work more than 6 hours without having a break of 30 minutes can easily end up in quite a complexity in real business life as soon as you think of constellations like: an employee records working time, but has got gaps in between or partial day absence records or did only work 06:10 minutes.
But one step after the other, let me first explain what this new feature is about.
Currently in EC Time Management only "fix breaks" are provided. This means you have got a break in your daily workschedule with start/ end times. When an employee records an attendance record or even an absence record that overlaps with this defined break a break time type gets generated in the time sheet and for the absence record the break reduces the absence quantity.
This "fix breaks" are not really flexible. When an employee starts his working time at 11:00 and has got a break defined from 12:00 - 13:00 than already after 1 hour the break gets generated. Or when he starts at 13:00 no break is generated, cause there is no overlap. Not really good.
With the new dynamic break variant we can cover those use cases and provide a much more flexible usage of breaks. You can define one or multiple durations after which a break shall be generated. So for example:
After 6 hours of working time 30minute break
After 9 hours additional 15 minute break
After 12 hours again an additional 15 minute break.
The most important thing for the new break is that we collect the recorded working time and absence times and generate a break after a specified number of hours after the start of the first working time / absence time.
This is the "dynamic break" feature in a nutshell. For those readers who just want an overview you better skip the next passages, cause we deep dive into details. For those who want to promote this feature, implement it, consult it, please read carefully. There is a lot of underlying complexity and assumptions we had to do to provide a best practice solution without having a configuration monster. Due to the complex nature of this topic there are some constellations where a customer might expect a different behaviour. And it is very crucial that these constellations get discussed and clarified with the customer before the feature is implemented.
1.) Set up of the new dynamic break
Fix breaks are configured in the daily workschedule of an employee. Hence the new dynamic breaks are NOT configured in the workschedule, but in a new configuration object which is assigned directly in employees job information. Why did we do this? Couple of reasons.
First is that this kind of break deductions are not bound to a daily workschedule, but are rather generic trade union regulations, business process rules or even part of laws / legislative regulations on working time. So, whatever daily working time an employee has got, this kind of rules are always valid. This is why the workschedule is the wrong place to assign this rule, but the job information the appropriate one.
Moreover, for a customer work schedule maintenance is getting even easier: You create this rule once and assign it to all employees. You don´t have to repeat this break information (which are to 90% always the same regulations) for each and any daily workschedule time model anymore.
Furthermore situations are covered where an employee needs to work overtime on a weekend or a non-working day. If you want to have an automated break deduction usually you could cover this only by assigning a break to a day model that was marked as non-working day which worked, but was maintenance effort and not really nice. And even you could not know if the break from 12:00 - 13:00 was suitable, cause the employee could work his overtime starting from 14:00 - 21:00 for example and then no automated break deduction would have been applied. With the fact that the new break rule is assigned in the job information it applies for all days - working days and non-working days. Again a facilitation of configuration and handling of our system.
How does the new configuration object look like? Quite simple:
You can see the header information like external name, code and description. In the lower part you see then the definition of the break time. You can enter the time that needs to pass and then the break duration in minutes that shall then be generated. We labeled the field for simplicity reasons "working time" - but you will see that this is not limited to "working time" only but includes absence times as well. Take this field as duration that needs to pass for a break deduction.
The list is limited to 5 break definitions - I haven´t experienced more than 3 in my consulting times, so this must be sufficient.
Last step is to assign this new break rule in the employees Job Information:
And you are done. Dynamic break defined and assigned. Quite easy isn´t it?
In really complex time management implementations projects dynamic break handling takes long time of finding out what customers really do in non-standard constellations where not only a working time record from 10:00 - 19:00 exists. There are lots of time to be spent to analyze and configure and depending on the software even based on customer specific coding. Cause in real business life strange constellations can come together and all should be handled correctly with respect to break handling. We are a cloud product and we always have to find a balance of a cloud software that can´t and won´t provide as much flexibility and complexity than an onprem solution (cause you don´t want to have month or years of implementation time) but yet offer best business practises and a set of configuration options to fine tune these. Due to the incremental development process in our cloud world we ship this feature without much configuration possibilites cause based on the best practise approach this feature can already be used by many customers without much more configuration. However, we are already working on more configuration options and will enhance this feature in the up-coming releases with more options. I´ll come at the end of this topic to some words on this.
One last remark regarding configuration before we get to calculation examples: You can have a workschedule assigned to an employee that contains fix breaks AND in the job information a dynamic break assigned. There is no error thrown. However, this makes not much sense. Either you have a fix break or a dynamic break. When both is true for an employee on a given day, the dynamic break rule is not processed, but only the work schedule breaks. And this is done by design, cause it gives you a further possibiliy:
You will see in the next section that the dynamic break deduction cannot be changed by an employee. The break gets generated, an employee can´t edit or delete it. However, there might be constellations where you want to switch the dynamic break generation of, cause there was really an extraordinary circumstance where the employee really could not take his break. Or only a few minutes break and not the full configured break. In this circumstances a time administrator can create an "temporary change of workschedule" using an individual workschedule that contains the employees planned time plus a different break. The dynamic break does not get processed then, cause now a work schedule break exist for this day. The break can even lay outside of the employees performed or planned time - the dynamic break gets not generated and the employee experiences than no break deduction at all.
So, this is a way to "overrule" in very specific circumstances the dynamic break generation.
Now, lets come to the examples to show you how we calculate:
2. Examples of dynamic break handling
Lets get to the tricky part - how the break deduction is done in reality. Step by step I gonna set up more complex examples to show how our break generation / deduction works. One thing I need to mention right in the beginning: when I use the term "break deduction" this means for time sheet that a break time type is generated. However, this does not yet mean that the break reduces automatically the recorded working time for time valuation or payroll purposes. If you want to calculate premium pays, working time accounts or any other time valuation results in net times - without breaks - you need as a first step in time valuation deduct the generated break time type in time valuation rules using the aggregate input group and split operation from overlapping attendance or absence time type groups. So same behaviour as for fix breaks: here you need to configure time valuation as well in order to deduct breaks for time valution result purpose. Otherwise you have only a break time type that you can see in the time sheet but nothing else, no reducing of working time by the break for example. So you always have to use time valuation rules to consum the break time type that is either recorded or generated. How this is done is explained in the time sheet implementation guide. This approach gives you even some more flexibility, you can for example configure that a break shall not be deducted in the time valuation result when a "travel time type" is recorded. This would have the effect that although there is a break time type generated you do not reduce the travel time time type in time valuation with this generated break.
And, important as well: for absence records (see examples below) there is no break time type generated in the time sheet. The absence quantity gets automatically reduced by the breaks "under-the-counter". Time Sheet just reads then the already by the break reduced absence record. This is based on the fact that you can use dynamic breaks for time off only as well. You don´t have to have time sheet.
So, back to the examples. Lets assume for all examples a dynamic break configured like:
after 6 hours 30 minute break and after 9 hours additionally 15minute break
2.1 Break in normal working time
An employee records working time from 08:00 to 18:00. Straight forward, just 1 record of working time. As a result you get in the time sheet two breaks automatically generated:
Break from 14:00 - 14:30 (cause after 6 hours) and a break from 17:30 - 17:45 (cause at 17:30 9 hours of working time have passed. The first generated break does not count as "working time").
2.2 Working time with gaps
Now lets come to a more complex constellation. The employee records working time from 08:00 - 12:00 and from 14:00 - 17:00. So, there is a gap of 2 hours in between of the recorded working times. What shall we do here? Is the gap itself to be regarded as break and hence no further break deduction should be done?
No. We do not regard the gap as a break at all. When the employee wants to document this as a break he needs to record manually a break time type and then no further automated break deduction is done (see next example).
Hence, the result of the break generation is:
A break is generated from 16:00 - 16:30 cause at 16:00 6 hours of working time have been reached. The gap is not counted as a break.
This might be one additional point that customers would like to configure - and we are already working on it. Hence in future it is planned that a customer can configure if gaps in between working time shall automatically be regarded as a break or not.
2.3 Working time with a manual recorded break
The dynamic break is a mandatory break that gets automatically generated and that cannot be edited by an employee. However, you might have the constellation that employees record manual breaks, too. Or you use our import API with which you can upload working time and breaks from 3rd party systems. So lets assume you have got a working time record from 08:00 - 18:00 and a manually recorded break from 10:00 - 10:15.
Now the question is: does this manual recorded break outrule the dynamic break configuration?
Answer: No. The recorded break does not outrule the dynamic break and due to the fact that the break is not sufficient according to the configured dynamic break there needs to be an additional break generated. Hence the result is the manual recorded break from 10:00 - 10:15 plus a generated break of 15 minutes from 14:15 - 14:30 (cause after 6 hours) plus another break from 17:30 - 17:45 (cause after 9 hours).
The important thing here is that the manually recorded break is not sufficient and we auto-generate the remaining mandatory break according to the configured dynamic break rule.
And of course the dynamic break gets not only "dumb" generated, but considers the manually recorded break so that overall the configured rule is met including manually recorded breaks.
2.4 Full day absence
Employees go on vacation or are ill or got other full day absences. Do we need to take care on this? Absences are absences and most of the regulations say literally "after 6 hours of working time" - like the European Regulation on Working Time for example. Well, unfortunately official laws and regulations are not formulated out of a time management software perspective cause otherwise they would be a bit clearer in its messages.
So, yes of course, we need to consider dynamic breaks for full day absences as well. Imagine an employee requests a full day absence that deducts the working time account. His planned working time from 08:00 - 17:00 is used to calculate the time account deduction quantity. But the employee hasn´t got 9 hours of planned time - cause planned breaks need to be deducted. The time account deduction should not be 9 hours, but 8 hours. Just like the employee would have with a workschedule fix break from 12:00 - 13:00. Here, the break reduces the absence quantity or time account deduction as well. And in order to not deduct wrong amount of hours from a time account the dynamic break deduction needs to be performed for absences as well. So, just like a configured fix break the new dynamic break reduces the absence quantity. The start time of the absence record is taken and then the dyamic break rule applied.
Note: in the time sheet you won´t see a generated break time type in this constellation. This is done based on the fact that time sheet reads already the absence record reduced by the break. This is why a break time type is not generated, cause the so-called "net-record", reduced by breaks, is read by time sheet. But this is nothing dynamic break specific, cause this is already happening for fix breaks in the same way.
2.5 Working time and partial day absence
Stay with me, this is the last example. Promise. But probably the most complex one. Employee records working time from 08:00 - 15:30 and he leaves earlier, hence he records a partial day absence from 15:30 - 18:00. Now, this is tricky. Where to place the breaks?
First break is clear: after 6 hours of working time a break of 30minutes is generated. Hence from 14:00 - 14:30 a break time type is generated. And the absence record? Absence records are regarded just as working time (see previous example), hence the 2.5 absence hours are added to the recorded working time and the absence quantity gets reduced by the 15 minute break so that at the end the break has got only a deduction quantity of 2:15. Why is this? Cause again, when the employee would fully work there would be a break deduction cause this break is "planned" according to the configured rule. And here it is the same as for the full day absence example: there could be a time account deduction necessary and this needs to be correct. Or other example: there is a daily overtime calculation. When the employee has got a planned time from 08.00 - 18:00 and records working time from 08:00 - 15:30 and an absence from 15:30 - 18:00 (and absence records mostly count for daily overtime calculations) the employee would receive 15 minutes overtime pay when we would not reduce the absence hours by the dynamic break.
Enough of this examples ;-). I hope you could get an understanding that there are tricky constellations possible that need to be handled in one or the other way. We did apply best business practices to handle those. As mentioned for gap handling and probably even for absence handling there are in future releases more configuration options planned.
2.6 Full or partial break deduction?
Another planned configuration option - and this is now really the last thing I want to touch for the dynamic break topic - is what shall be done when there is not sufficient working time remaining for a dynamic break deduction.
So an employee has got working time of 6 hours and 10 minutes. What to do? Shall the full 30 minutes break be deducted that the employee ends up with less net hours as his colleague who left earlier after 5:55 hours? In this release we generate only a break for the time that is beyond the configured threshold, so a break of 10 minutes is generated. But we are already working on another configuration option that you will be able to set up for this kind of constellations if the break shall be fully deducted (30 minutes) or only partially (10 minutes).
2.7 Important things to know
You see, all in all a very big and complex topic. Here are in a nutshell and as a summary what you need to take away:
- dynamic breaks in general work only for clock time based time recording
- you can use dynamic breaks even when you do not use time sheet - means also for time off usage only
- a dynamic break can be deducted after a certain amount of attendance time has been recorded
- a break time type is generated in the time sheet
- just as with fix breaks the generated time type does not do a break deduction in time valuation without configuration. You need to configure time valuation rules that performs the break deduction in time valuation. This gives you more flexibility to when you really want to deduct breaks for which recorded time types
- a dynamic break cannot be edited by an employee
- a gap in between working time is not regarded as break
- absences get reduced by dynamic breaks just as if they were attendance times, but in the time sheet no time type is generated cause time sheet reads already the net absence time
These were the two main topics of the Q4 delivery. But we have also done some smaller parts:
3. Time Account Snapshot API
Since a couple of releases we have got this API for internal replication of time account balances to SAP onprem or EC Payroll. This API is now public available and can be used for other payroll systems or other applications.
What does this API do? You can create a time account snapshot for a given date. This can also be a date in the future. And the machinery is started and creates a record in the database with the time account balance. The time account snapshot as such exists since Q2 2017 (see my blog on that release for more details). The new thing is now that the API to read the time account balances is general available to extract the records.
Just a quick reminder how you create the snapshots: You do this via the calendar runs:
You run the snapshot per time account type. Read the documentation in the time off implementation guide for more details on the time account snapshot (but be careful: don´t mix the term with the time account snapshot report - same name, but one is a real report in the report center, the other a snapshot that stores data on the database that can be extracted.
4. New time sheet attributes
We introduce new hard coded time sheet attributes. The main purpose of these new attributes is first and foremost internal time sheet processing, to speed up and optimize calculations, internal jobs and to have more attributes to hard code on for faster time sheet processing. But customers can use this new attributes as a filter criteria in reporting or in business/workflow rules as well.
The new attributes are:
- Full time sheet
Is set to yes when a time sheet covers in sum planned working time either with attendance,
absence or break records
- Absences
Is set to yes when at least one absence is recorded in the time sheet
- Manual entries
Is set to yes when at least one manual time recording (attendance, break, on call or allowance) is
recorded in the time sheet
- Imported entries
Is set to yes when at least one via the “external time data service” imported time record (attendance, break or on call) is in the time sheet
- Generated entries
Is set to yes when at least one system generated time record (attendance or break) is in the time sheet
- Time Recording Method
Contains the time recording method of the employee in the time sheet period (positive, negative or overtime)
Why do I mention this rather technical things? First we are using this attributes to automate processes:
Currently when for a positive time recorder a time sheet is full of absence records cause the employee is on an one week vacation he needs to submit this time sheet manually in order that paytypes are generated when the absence is paid and the employee is a hourly employee (or when salaried and the absence time period is paid differently than his normal salary - including shift differentials for example). Which is a bit cumbersome cause the employee is on vacation but the time sheet needs to be submitted manually in order to get the absence time paid. We are currently working on a new feature that automatically submits this time sheet. And here we are reading this new attributes: for a positive time recorder when the attribute "full time sheet" is yes and "absences" is yes and "manual entries" and "imported entries" is no, then the time sheet is full of absences and can automatically be submitted.
Second, customers can use this attributes in business rule, time sheet input validations and in workflow rules. Lets stick to above mentioned time sheet. When you have assigned a workflow rule to a time sheet the workflow gets triggered for each time sheet. Even when it is full of absences. You might now ask - well, the one week vacation has already been approved by the time off request why does the time sheet than needs to be approved once more? And here you can use the above mentioned attributes in your workflow rule. You can use them and find out if a time sheets consist only of absences. If so, you do not trigger a time sheet approval and the time sheet is automatically approved. This reduces the workflow inbox of your managers. Again a small enhancement but customers approver will be thankful.
Third we need to do other hard coded things in order to process algorhitms and to optimize performance so that the application is even more faster. This hard coding depends on certain assumptions that we need to do. And basic assumptions are that time types which are in its business meaning an absences are configured as absence time type and time types that are in its business meaning an attendance are configured as attendance time type and maintained in the time sheet (and not in the time off UI for example).
So what makes an absence to an absence and an attendance to an attendance? This question is quite simply answered:
When the employee is active doing something for the employer which is regarded as productive time it is an attendance.
When the employee is not active doing something it is an absence.
So: vacation, illness, jury duty, strike, working time account deductions, time off in lieu deductions, are absences. I am not active doing something for the employer.
Working time, overtime, home office, training, business travel, travel time - are attendances, cause I am active doing something for the employer.
This distinction is important and important to follow in your implementations. As mentioned, the above set parameters are used for internal time sheet processing. And they are hardcoded based on for example if an absence exists or not. And when you use for example a timetype with an absence category for "home office" - which is not an absence but an attendance - it might lead to wrong internal follow up processings.
Or take the daily sums and the bar charts that are displayed in the time sheet. The calculation of this is hardcoded by the clear distinction on what is an absence and what is an attendance record. When you configure absences facts as an attendance or vice versa this leads to weird effects and confuses your employees, cause the visualization and calculations are not correct anymore.
5. Blocking of time account details
Next topic is the blocking of time account details for permanent time accounts. This is relevant for data protection and privacy where we already have delivered configurable purging, blocking, read access and change log and information report (see my Q1 blog 2018 for details on data privacy features).
This feature is a round-off to the already delivered features. Recurring time accounts and it´s postings could already be blocked from access for example by a time admin or a manager when the time accounts end date has passed 3 years. But for permanent time accounts this was not possible - cause permanent time accounts do not have an end date. And when the full time time account is blocked than a time admin or a manager does not see the balance or anything else of this time account. Hence we needed to separate the time account postings for blocking purpose from the time account itself. This new feature allows now to block the details separatly from the time account. You can configure the system that the actual balance is visible and the postings to and from this time account for example only for the last 2 years in the case of a permanent time account for specific user groups. This enhances date protection and privacy.
6. South African 3-years sick leave cycle
This is not really a new feature - it is rather a description how this really complex paid leave entitlement for sicknesses in South Africa can be covered with existing functionality.
In South Africa employees got a 3 years sick leave cycle of paid leave. The basic conditions for employment (BCOE) for South Africa stipulates that Sick Leave should be based on a 3 year cycle, but pro-rated in the first year. New Hires 1 day a month for first 6 months, then 24 days on the 7th month. This cycle is for 3 years, when your 2nd cycle starts you get 30 days upfront for the next 3 years.
We received this request from many customers in South Africa as it is a legal requirement. And based on the fact that in Employee Central only monthly, yearly or permanent time accounts but no 3-years time accounts are possible it did cost a bit of brain power to find a solution for this. Well, this time the brain power did not come from me, but from my colleague Hans-Georg Bingler with support from the time off development team. They found a solution that was accepted by the South African Customers. If you are interested in the concrete requirement and its solution proposal you can check either the Country specific time off documenation or in the solution proposal described on the influence.sap.com page.
7. Time Sheet Deep Link
Deep links can be used anywhere where hyperlinks are possible. You can use them in offline content, such as your internal documentation, or on intranet sites, like your company portal. They can also be used in third-party applications, such extensions built on the SAP Cloud Platform. You can even use deep links within the SAP SuccessFactors system itself, such as on a custom tile on the home page or in custom navigation links on the Employee Profile.
For Time Off and the Time Administrator Workbench a deep link did already exist, for Time Sheet now as well.
8. Mobile time enhancements
Last but not least let me mention some new mobile time enhancements. It is now not only possible for positive time recorders to use the mobile time sheet, but also for negative and overtime recorders.
If you aren´t familiar with the terms "positive", "negative" (no, this is not only time off recording) or "overtime" recording please consult my other blog where I shed some lights on this philosophical time management aspects ;-).
Are you a negative or a positive time recorder?
That´s it. Sorry for the many words on the new features but especially the dynamic / minimum break needed some explanations so that everyone understands what happens in detail when this feature is used. I hope I could make it a bit clearer.
Stay tuned, as usual you will get news on the Q1 features 2019 in about 4 months.
Take care and have nice christmas / years end vacations.
Volker Ruof
Product Manager EC Time
16 Comments
| User | Count |
|---|---|
| 8 | |
| 7 | |
| 5 | |
| 2 | |
| 2 | |
| 2 | |
| 1 | |
| 1 | |
| 1 | |
| 1 |
