Hi there,
time again to shed some lights on the latest enhancements in the EC Time Management area.
This release we got a couple of features where I know that many customers and consultant companies are eagerly awaiting its release. So, here we go, the overview first:
1) Import of attendance times with start / end times and multiple time types into EC Time Sheet
2) Vacation accruals based on worked hours recorded in EC Time Sheet
3) Configuration enhancement for time account deduction order: earliest expiry date first when a time type deducts multiple different time accounts
4) Enhancement for time account payout scenario and time admin workbench
5) Sickness handling for Colombia
6) Check tool enhancements
Prepare your oxygen cylinder, put on your diving googles, say bye to the normal world, we are going to deep dive into the beauty of time management:
I hate to start an announcement with: No, this feature is not .... but to avoid misunderstandings and misperceptions: No this feature is not a clock in / out terminal integration. But it is a step towards it - and many customers can already use this new import to either overcome the period till we provide a proper clock in / out integration (which is work in progress) or for many customers this import functionality will already be sufficient.
You might know that we have the "External time records" object that you can fill with Odata calls or file import. You can upload with this service per user and date a duration value. This duration gets send to the time sheet and in the time sheet a time record was created with the default time type that is maintained for this user in his time profile. Shortcoming of this service was so far that it was only a duration based record - like 8 hours, 6,5 hours.... - and it was only 1 time type possible to import. Many customers complaint on this and we reacted (admitted, sometimes I wished to be able to deliver things sooner for customers but some things I can´t change).
The new service is called "External time data" and this service allows you to import a duration based record OR a record with start / end times and of course, multiple time types. So you can send for example:
08:33-10:34 Working time
10:34- 10:55 Break
10:55 - 13:00 Training
13:00 - 13:30 Break
13:30 - 17:00 Working time
This allows you to:
a) send us time data from external time systems where you want that evaluation steps like overtime calculation, working time account postings, sunday-, holiday-premiums and so on are calculated in EC Time Sheet.
b) send us time data from time recording terminals or devices where employees perform punch in / out times. However, in this scenario you must ensure that you peform the so called "pair formation", which is combining a clock in with the logical correct clock out is done OUTSIDE Employee Central. Cause our new import service requires a "correct" time record with start / end times combined.
So all in all you don´t need the old "external time records" service anymore, cause with the new one you can import a duration based record, too, and when you are not yet using the old one, choose always the new "external time data" service cause new enhancements will be delivered only for this one.
In a nutshell you can upload per user / date:
You can use for the import all time types that are of the category "attendance" or "on-call". Hence allowances can´t be imported. Neither is it currently possible to state a deviating cost center in the import but this is already on our backlog list.
Apart from this the new enhancements the logic compared to the old import service has not changed:
There is an error handling and error log messages when a record could not be imported due to collision checks or when the user does not exist, the imported time type is not available in the employees time profile and other erroneous constellations. Furthermore you can upload time records for multiple users and for a single day only or for multiple days. When imported records for a user / date already exist and you send a new record for this day the existing one gets overwritten. And you can delete an already imported record with a deletion flag.
You might think what is new here? It is already possible to fill working time accounts via a daily comparison of recorded hours and the planned working time and post the delta to a working time account (or flextime account how it is often labelled as well). So, what is new here? The new feature got its difference in the nature of working time accounts and "real" vacation / leave accounts. Working time accounts are rather a means to balance out automatically when an employee has worked some additional hours. These hours do not necessarily result in an overtime pay, but are posted to a time account and the employee can work less than later on in the week or whenever he wants without requesting a leave request. He just leaves earlier, the system calculates a minus for this day and the plus hours he has received days or weeks before are balanced out. Check my earlier blogs when you want to learn on working time accounts in more detal.
Vacation accrual is something different. Often laws stiplulate that temporary staff or students working receive a vacation entitlement too. And due to the fact that they work rather flexible you can´t accrual for them like for a "real" full time employee based on active calendar months for example. Hence the monthly leave entitlement is calculated based on the hours they have worked in the previous month. In Australia / New Zealand similar regulations exists as well for regular leave entitlements.
To cover this requirements you can now use the time sheet attendance hours for our time account accrual engine. The attendance hours from the time sheet are filled into the Time Off Object "Accrual calculation base" and from there the accrual engine can read it and you can apply all other business rules, accrual rules, termination rules like in the regular time account accrual processing.
Configuration is however a bit tricky. I have created a separate blog where I describe step-by-step what you need to do. Check out this link:
Time account accruals based on recorded working time
This one goes especially to our dutch customers - but customers in other countries will benefit from this feature as well. The input channel for this feature was our influence tool - so, you see, it is worthwile using this ;-).
Time account deduction sequence can be configured in a way that when you have time account balances from previous years you can state if the oldest -or the time account that expires first - shall be deducted first. This works when you have got 1 time account type. Time account type is for example "Vacation" and you got a time account for 2018 that expires on 31. May 2019 but there are still remaining days in the time account 2017 which expires on 31. May 2018. When an employee records a vacation in January 2018 you can configure the deduction sequence that first the 2017er account gets deducted - cause it expires first.
However, there are also constellations where 1 timetype needs to deduct two different time account types in a sequence. The time type "vacation" shall first deduct the time account "special leave" till there is no balance left and then the time account "vacation". This can be configured as well in our deduction rules.
But now - I think you already guessed it - what happens when there are two different time accounts to be deducted and both have remaining balances from previous years? Bammmm. No chance to configure this. Up to now ;-).
You can now choose an option in a new field in the time type configuration (manage data). This field is called "posting priority". Options are:
When you choose the entry "post to time accounts by posting rule only" then you get the old behaviour. Upon deduction it gets checked what kind of posting rule is assigned to the time type and the time accounts deducted according to the posting rule......
But when you choose "post to time accounts by defined time account type period" a new field appears called "posting order" (you need to watch carefully where this field gets sorted in, cause MDF provides no possibility to bring the fields in a meaningful order). In this new field you can then choose
This periods refer always to the validity/bookable end date of the time accounts. The order in the posting rules of the time type is only considered if the validity/bookable end dates of two accounts are the same.
So when you choose here "oldest first by bookable period" the system checks which time accounts shall be deducted at all (posting rule) and takes the time account which has got the earliest coming bookable end date. Whith this you can ensure that those time accounts are deducted first that are in danger to forfeit first.
Of course in this complex constellations it can happen that there gets a bit a mess in the deduction sequence. Especially when an employee has recorded a leave which gets days later not approved or he cancels a leave, but in meantime the employee has recorded another leave. So deduction sequence can get really messed up due to normal business processes. Upon cancellation or rejection the time account postings are re-booked to the time account instance where they have been deducted from. When a new leave request gets then created afterwards the game of deducting time account balances that expires first begins anew.
This one is fastly explained.
First we brought some additional fields to the absence list in the time admin workbench. The fields are:
This feature was a kind of technical debt compared to the old Manage time off UI where this information was shown. Now we have got feature parity to the old Manage time off UI - and not only feature parity but the whole time admin workbench gives you much more information on an employees time data and possibilities to adapt times / time account adjustments that there is no need at all to use the old Manage time off UI anymore.
Second when you perform a time account payount in the time admin workbench email notifications were previously only triggered when a payout was created. Now employees get informed when a time admin edits or deletes a time account payout. So: much more transparency and automated notification to employees which eases business processes.
Furthermore we implemented some additional automated validation checks for the fields posting date, payout and rate. This helps to prevent erroneous data input and ensures data consistency in such a touchy area like time account payouts.
Sickness handling in combination with payroll is a very country specific topic. Nearly each country has its own payment regulations here. Payroll needs for correct payment (after some time in many countries the employees salary for a longer term illness is paid by the health insurance) or for payroll follow up processes (information exchange with health insurances, automated statements to pension funds), additional information. From a pure time management perspective this kind of information is not really relevant, but from a data perspective this information needs to be part of the recorded absence. Time Management does not care if an employees illness got the same cause like another illness for example. But payroll does care cause based on specific periods and dates an end of continous pay is calculated -and this in turn is very important for paying the correct amount to the employee. So, for payroll reasons some specific actions need to be done in time management with respect to illness records and some additional information recorded.
One of this actions is the "linking" of illness absences. This is done in Germany, Spain and other european countries. With this linking many single illness records receive a kind of bracket. This bracket has the meaning that these illness records belong together, for examle due to the fact that these linked illnesses all share the same "cause". Of course, HR does not know the medical cause in detail, this information obtains only the health insurance, but HR gets informed by the health insurance that certain absences belong together.
Well, long story, short end: this kind of linking is used in many countries for different payroll purposes. And the country extension for Colombia provides now this possibility as well. And due to the fact that it is payroll relevant it gets of course replicated to EC Payroll systems Infotype 2001 absences as part of our out-of-the-box integration to Infotype 2001. For those of you who are familiar with the SAP ERP Time world: Field KENN1 is filled in this infotype.
Last but not least we provide more checks in our configuration check tool that you can access via the admin centre. The check tool is very useful for implementation partners to check the correctness of -the admitted sometimes complex- time configuration. If you are not yet familiar with it please check my previous blogs where I have introduced and described the possibilities in detail - or simply try it out. It helps you in finding erroneous configuration and configuration skeletons in the closet and it is a small nice help helping you cleaning up your configuration.
The latest checks are:
This is it for the Q3 release. I hope you like the new features and that you can use them for your customers. Stay tuned, we are already working on the Q4 features and when you follow my blogs you will learn in around 3 months on the new features for Q4. Good thing for you and customers is that you will get new features soon, sad thing however: there will then be a dark, cold, wet german november as opposed to the fantastic current 35 degree summer with warm summer nights.
Enjoy the rest of the summer.
Best regards
Volker
time again to shed some lights on the latest enhancements in the EC Time Management area.
This release we got a couple of features where I know that many customers and consultant companies are eagerly awaiting its release. So, here we go, the overview first:
1) Import of attendance times with start / end times and multiple time types into EC Time Sheet
2) Vacation accruals based on worked hours recorded in EC Time Sheet
3) Configuration enhancement for time account deduction order: earliest expiry date first when a time type deducts multiple different time accounts
4) Enhancement for time account payout scenario and time admin workbench
5) Sickness handling for Colombia
6) Check tool enhancements
Prepare your oxygen cylinder, put on your diving googles, say bye to the normal world, we are going to deep dive into the beauty of time management:
1) Import of attendance times with start / end times
I hate to start an announcement with: No, this feature is not .... but to avoid misunderstandings and misperceptions: No this feature is not a clock in / out terminal integration. But it is a step towards it - and many customers can already use this new import to either overcome the period till we provide a proper clock in / out integration (which is work in progress) or for many customers this import functionality will already be sufficient.
You might know that we have the "External time records" object that you can fill with Odata calls or file import. You can upload with this service per user and date a duration value. This duration gets send to the time sheet and in the time sheet a time record was created with the default time type that is maintained for this user in his time profile. Shortcoming of this service was so far that it was only a duration based record - like 8 hours, 6,5 hours.... - and it was only 1 time type possible to import. Many customers complaint on this and we reacted (admitted, sometimes I wished to be able to deliver things sooner for customers but some things I can´t change).
The new service is called "External time data" and this service allows you to import a duration based record OR a record with start / end times and of course, multiple time types. So you can send for example:
08:33-10:34 Working time
10:34- 10:55 Break
10:55 - 13:00 Training
13:00 - 13:30 Break
13:30 - 17:00 Working time
This allows you to:
a) send us time data from external time systems where you want that evaluation steps like overtime calculation, working time account postings, sunday-, holiday-premiums and so on are calculated in EC Time Sheet.
b) send us time data from time recording terminals or devices where employees perform punch in / out times. However, in this scenario you must ensure that you peform the so called "pair formation", which is combining a clock in with the logical correct clock out is done OUTSIDE Employee Central. Cause our new import service requires a "correct" time record with start / end times combined.
So all in all you don´t need the old "external time records" service anymore, cause with the new one you can import a duration based record, too, and when you are not yet using the old one, choose always the new "external time data" service cause new enhancements will be delivered only for this one.
In a nutshell you can upload per user / date:
- Start / End Time and Timetype
- Start / End Time without time type (the default import time type as maintained in the employees time profile is used then)
- Duration and Timetype
- Duration without without time type (the default import time type as maintained in the employees time profile is used then)
You can use for the import all time types that are of the category "attendance" or "on-call". Hence allowances can´t be imported. Neither is it currently possible to state a deviating cost center in the import but this is already on our backlog list.
Apart from this the new enhancements the logic compared to the old import service has not changed:
There is an error handling and error log messages when a record could not be imported due to collision checks or when the user does not exist, the imported time type is not available in the employees time profile and other erroneous constellations. Furthermore you can upload time records for multiple users and for a single day only or for multiple days. When imported records for a user / date already exist and you send a new record for this day the existing one gets overwritten. And you can delete an already imported record with a deletion flag.
2) Vacation accruals based on worked hours recorded in EC Time Sheet
You might think what is new here? It is already possible to fill working time accounts via a daily comparison of recorded hours and the planned working time and post the delta to a working time account (or flextime account how it is often labelled as well). So, what is new here? The new feature got its difference in the nature of working time accounts and "real" vacation / leave accounts. Working time accounts are rather a means to balance out automatically when an employee has worked some additional hours. These hours do not necessarily result in an overtime pay, but are posted to a time account and the employee can work less than later on in the week or whenever he wants without requesting a leave request. He just leaves earlier, the system calculates a minus for this day and the plus hours he has received days or weeks before are balanced out. Check my earlier blogs when you want to learn on working time accounts in more detal.
Vacation accrual is something different. Often laws stiplulate that temporary staff or students working receive a vacation entitlement too. And due to the fact that they work rather flexible you can´t accrual for them like for a "real" full time employee based on active calendar months for example. Hence the monthly leave entitlement is calculated based on the hours they have worked in the previous month. In Australia / New Zealand similar regulations exists as well for regular leave entitlements.
To cover this requirements you can now use the time sheet attendance hours for our time account accrual engine. The attendance hours from the time sheet are filled into the Time Off Object "Accrual calculation base" and from there the accrual engine can read it and you can apply all other business rules, accrual rules, termination rules like in the regular time account accrual processing.
Configuration is however a bit tricky. I have created a separate blog where I describe step-by-step what you need to do. Check out this link:
Time account accruals based on recorded working time
3) Configuration enhancement for time account deduction order: earliest expiry date first when multiple time accounts are deducted
This one goes especially to our dutch customers - but customers in other countries will benefit from this feature as well. The input channel for this feature was our influence tool - so, you see, it is worthwile using this ;-).
Time account deduction sequence can be configured in a way that when you have time account balances from previous years you can state if the oldest -or the time account that expires first - shall be deducted first. This works when you have got 1 time account type. Time account type is for example "Vacation" and you got a time account for 2018 that expires on 31. May 2019 but there are still remaining days in the time account 2017 which expires on 31. May 2018. When an employee records a vacation in January 2018 you can configure the deduction sequence that first the 2017er account gets deducted - cause it expires first.
However, there are also constellations where 1 timetype needs to deduct two different time account types in a sequence. The time type "vacation" shall first deduct the time account "special leave" till there is no balance left and then the time account "vacation". This can be configured as well in our deduction rules.
But now - I think you already guessed it - what happens when there are two different time accounts to be deducted and both have remaining balances from previous years? Bammmm. No chance to configure this. Up to now ;-).
You can now choose an option in a new field in the time type configuration (manage data). This field is called "posting priority". Options are:
- Post to time accounts by defined time account type period
- Post to time accounts by posting rules only
When you choose the entry "post to time accounts by posting rule only" then you get the old behaviour. Upon deduction it gets checked what kind of posting rule is assigned to the time type and the time accounts deducted according to the posting rule......
But when you choose "post to time accounts by defined time account type period" a new field appears called "posting order" (you need to watch carefully where this field gets sorted in, cause MDF provides no possibility to bring the fields in a meaningful order). In this new field you can then choose
- oldest first by bookable period
- oldest first by validity period
- newest first by bookable period
- newest first by validity period
This periods refer always to the validity/bookable end date of the time accounts. The order in the posting rules of the time type is only considered if the validity/bookable end dates of two accounts are the same.
So when you choose here "oldest first by bookable period" the system checks which time accounts shall be deducted at all (posting rule) and takes the time account which has got the earliest coming bookable end date. Whith this you can ensure that those time accounts are deducted first that are in danger to forfeit first.
Of course in this complex constellations it can happen that there gets a bit a mess in the deduction sequence. Especially when an employee has recorded a leave which gets days later not approved or he cancels a leave, but in meantime the employee has recorded another leave. So deduction sequence can get really messed up due to normal business processes. Upon cancellation or rejection the time account postings are re-booked to the time account instance where they have been deducted from. When a new leave request gets then created afterwards the game of deducting time account balances that expires first begins anew.
4) Enhancement for time account payout scenario and time admin workbench
This one is fastly explained.
First we brought some additional fields to the absence list in the time admin workbench. The fields are:
- approved by (in case of rejection: rejected by)
- and approval date (in case of rejection: rejection date).
This feature was a kind of technical debt compared to the old Manage time off UI where this information was shown. Now we have got feature parity to the old Manage time off UI - and not only feature parity but the whole time admin workbench gives you much more information on an employees time data and possibilities to adapt times / time account adjustments that there is no need at all to use the old Manage time off UI anymore.
Second when you perform a time account payount in the time admin workbench email notifications were previously only triggered when a payout was created. Now employees get informed when a time admin edits or deletes a time account payout. So: much more transparency and automated notification to employees which eases business processes.
Furthermore we implemented some additional automated validation checks for the fields posting date, payout and rate. This helps to prevent erroneous data input and ensures data consistency in such a touchy area like time account payouts.
5) Sickness handling for Colombia
Sickness handling in combination with payroll is a very country specific topic. Nearly each country has its own payment regulations here. Payroll needs for correct payment (after some time in many countries the employees salary for a longer term illness is paid by the health insurance) or for payroll follow up processes (information exchange with health insurances, automated statements to pension funds), additional information. From a pure time management perspective this kind of information is not really relevant, but from a data perspective this information needs to be part of the recorded absence. Time Management does not care if an employees illness got the same cause like another illness for example. But payroll does care cause based on specific periods and dates an end of continous pay is calculated -and this in turn is very important for paying the correct amount to the employee. So, for payroll reasons some specific actions need to be done in time management with respect to illness records and some additional information recorded.
One of this actions is the "linking" of illness absences. This is done in Germany, Spain and other european countries. With this linking many single illness records receive a kind of bracket. This bracket has the meaning that these illness records belong together, for examle due to the fact that these linked illnesses all share the same "cause". Of course, HR does not know the medical cause in detail, this information obtains only the health insurance, but HR gets informed by the health insurance that certain absences belong together.
Well, long story, short end: this kind of linking is used in many countries for different payroll purposes. And the country extension for Colombia provides now this possibility as well. And due to the fact that it is payroll relevant it gets of course replicated to EC Payroll systems Infotype 2001 absences as part of our out-of-the-box integration to Infotype 2001. For those of you who are familiar with the SAP ERP Time world: Field KENN1 is filled in this infotype.
6) Check tool enhancements
Last but not least we provide more checks in our configuration check tool that you can access via the admin centre. The check tool is very useful for implementation partners to check the correctness of -the admitted sometimes complex- time configuration. If you are not yet familiar with it please check my previous blogs where I have introduced and described the possibilities in detail - or simply try it out. It helps you in finding erroneous configuration and configuration skeletons in the closet and it is a small nice help helping you cleaning up your configuration.
The latest checks are:
- take rules are checked that incorporate deleted time types
- accrual rule consistency
- time account bookings that are outside the bookable period
This is it for the Q3 release. I hope you like the new features and that you can use them for your customers. Stay tuned, we are already working on the Q4 features and when you follow my blogs you will learn in around 3 months on the new features for Q4. Good thing for you and customers is that you will get new features soon, sad thing however: there will then be a dark, cold, wet german november as opposed to the fantastic current 35 degree summer with warm summer nights.
Enjoy the rest of the summer.
Best regards
Volker
- SAP Managed Tags:
49 Comments
| User | Count |
|---|---|
| 5 | |
| 4 | |
| 4 | |
| 2 | |
| 2 | |
| 2 | |
| 2 | |
| 1 | |
| 1 | |
| 1 |
