Technical Articles
EC Time – Tipps and hints Nr. 5: how to accrual vacation time accounts based on EC time sheet data
Hi,
this blog describes how to set up a mechanism in EC Time Management that allows to do time account accruals based on recorded hours / days in the time sheet.
Before I start, I first need to write a bit on theory and describe the different ways that exist in Time Management in general to create postings to a time account.
I don´t know in detail how other time management software is handling this, but I know in detail how it is done in SAP ERP Time management, Business byDesign Time Management and of course in our new EC Time Management. I assume other time management solution do this the same way cause these are usually generic business processes independent from a specific software solution.
And the 3 ways of building leave entitlements are:
1. Via an time account accruals engine in a leave management component
This is usually done for leave entitlements based on solid regulations and an employees master data. Usually they are done for recurring time accounts (yearly for example) and are used for generating vacation / leave entitlements based on your contractual working days per week or full time / part time status. In Germany these are for example at least 20 days vacation for a full time employee working a 5-days week. But it can be of course more depending on trade union contracts, company agreements and personell factors like age, service age and other parameters.
This kind of time account accrual can be done by a leave management solution stand alone.
2. Time account postings based on recorded working time or overtime
There are time management processes where an leave entitlement solemly build on employees master data is not sufficient. Employees record their working time and when they have “flextime” or “Gleitzeit” the recorded hours are compared with the duration of the planned working time. Is it less a minus posting is booked to the time account, if it is more then the employee has worked longer than planned and a plus posting is done – and usually no overtime payment is paid for this. Cause the employee can work less the following days / weeks and compensate “flexibly” the too many hours worked (don´t want to call it “overtime” cause normally overtime is associated with a higher payment). There can be of course boundaries – like only the hours performed within a “flextime bandwidth” count, or the time account can only go up to 35hours per month and each plus hour more is then really overtime and paid with an premium and many variations more.
But the important part is: an accruals calculation engine is not needed here. Usually this can be calculated by time valuation alone. The recorded hours are calculated (breaks deducted, times outside a flextime bandwidth capped….) and a direct posting to a time account is performed from the time valuation engine. A pure leave management application can´t do this.
Same is true for the time off in lieu hours. You need to calculate first overtime based on the recorded hours. Overtime by day, week, month or a combination of it, calculate a premium payment (which can be different if the overtime is performed on a Sunday, public holiday (even difference amongst public holidays exist), during night hours and then either the full overtime (base hours plus premium pay) is posted to a time off in lieu account, or only a portion of it (premium part banked, base hours paid out)
This can´t be done by a time accounts accrual engine or with a standalone absence management tool. Time Valuation is needed for this and of course the recording and valuation of the hours worked.
If you want to post overtime into different time accounts, like overtime on Sunday in Time account 1, Overtime on public holiday in time account 2 and normal overtime in Time account 3, then please don´t use the approach described here, but better use this approach:
https://blogs.sap.com/2021/04/30/employee-central-time-off-multiple-time-off-in-lieu-toil-solution/
3. Accruals done by an accrual engine based on hours recorded
And finally, there is the mixed version. You need a time valuation to calculate a value based on the hours recorded, days worked or something else based on the attendance time an employee records AND this value needs to be used by an accruals engine to apply accrual calculation rules and employees master data to generate a leave entitlement.
And up to now the latter was not possible in EC Time. But with our earlier introduced time collectors and some enhancements to them it is now possible.
Business scenario:
In some countries it is a common business process to use recorded attendance time in order to use them for daily, weekly or monthly time account vacation accruals. Means the time account accrual engine shall be fed by time sheet data.
In France for example an employee gets only a monthly vacation accrual (but the real entitlement is granted only the following year) when he has worked at least 20 days in the month.
In Australia for each worked day (including some absences but excluding other absence types) employees get an accrual of 0.416438356 hours annual leave.
In some US state you get 1 hour of sick leave for each 30 hours worked.
And there are many more business use cases where a regular leave entitlement is calculated based on the hours / days worked.
So, in short words: it is necessary for the time account accruals engine to consume hours worked recorded in the time sheet.
This is possible with some configuration.
The time account accrual engine reads an object called “accrual base calculation”. This can be used when customers use 3rd party attendance systems but want to do the time account accrual in EC Time. The hours worked can be uploaded via this object for the time account accrual calculation.
But what when the attendance time is recorded in EC Time Sheet? Can those hours be used for time account accrual engine as well?
Yes, we can. It is a bit tricky cause you need to use integration center, but it is possible. We use the integration center for it and the already existing “accrual base calculation” object. However, the “accrual base calculation” object needs the data in a specific format. The data needs to be in the structure of the object which is:
-
-
- External code
- user
- date
- actual quantity
- quantity 1 – 5
-
Check the documentation of this object here:
Hence we need to massage a little bit the time sheet output that it fulfills the format requirement of this object.
Lets take the Australian leave accrual use case as an example.
Employees accrual per each day worked a small portion for their yearly leave entitlement.
So lets take the example in Australia where for a day worked 30 minutes or 0.416438356 hours vacation are granted. In real life, it is a bit more complex cause some specific absence days count as “day worked” as well, and for part time employees it works differently, but this is only a question on how detailed the configuration is. Lets use an easy example, cause I want to show only the principle on how this is set up.
For collecting the attendance days we need a time collector in the time sheet. First step is hence configuring a time collector:
Step 1: Configure a time collector
When you want to use time sheet hours and especially when you want to count number of days on which an employee has performed work, you need to configure a time collector. Please check my other blogs on how to set up a collector in detail.
The collector is of the type “counted events” and we count therein per month the days on which an employee has attendance times (if you want to add specific absence days to it, just use different input time type groups for the collector).
So we got a time type group filled daily for a month by time valuation based on times recorded in the EC Time Sheet.
Time collector looks like this:
Note, that we marked the time collector as UI Component = Yes, so an employee can easily check real time on the Time Sheet UI the actual value of the month.
The time valuation rule that counts all worked day per month to fill the collector looks like this:
The ‘above’ group is the time type group we just created. The input group(s) depend on your already available time type groups. Since the resulting time type group is a collector for counted events, it does not matter how many hours or minutes are recorded, it only matters the fact that one (or multiple) time recordings exist on a day. With the threshold of 0 the valuation will count every day where there is at least one minute of working time for example.
Assign this evaluation rule to a time recording profile and this in turn needs to be assigned to an employee.
After you have done so, you can check in the employees time sheet (or via the time sheet trace feature), whether the time collector works as expected. If you open the time sheet for the user, you should find a link to display the time collectors at the lower left of the screen. Using this link should display the newly defined time collector.
Step 2: Configuring the Integration Center
Now the tricky part is how to extract the value of the time type group out of the time valuation to feed the accrual engine. This can be done with the Integration Center. Here is a step to step description:
Access the integration center.
Click on “My Integrations” and create a new integration scenario by clicking the +create button and select “more integration types”.
Choose on the next pop up
- as trigger type “scheduled”
- as destination type “SuccessFactors”
- as source type “SuccessFactors”
- and as Format “Odata v2”.This means it is going to be an internal MDF to MDF integration which makes some things easier.
On the next screen choose Time Collectors as the base object for the integration. Cause you want to use the time collector we have created above, the one that counts the overtime days per month.
Now you come into a guided activity. Step one here is that you need to give an integration name for your scenario.
Afterwards you need to define and configure the fields that you want to have in your integration scenario.
Select as target object the “accrual calculation base” object. This is the object of the time account accrual engine to upload external accrual base values.
Now we come to the formatting topic. The accrual calculation base object needs as external code the form userid_YYYY-MM-DD. In order to get the field mapping in the appropriate format, we need to make this field as an “calculated field”. You do so by marking the external code field and clicking on the little calculator symbol.
On the following pop-up make exactly this entries:
- Field Value = User (userId) from Time Collector (select the drop down menu and select ‘Associate Field’, then select the User field from the Entity Tree View)
- Concatenate/Append _ (select the operation and enter an underscore in the next field)
- Concatenate/Append Valid to (endDate) from Time Collector
- Remove All T00:00:00Z (select that operation and enter the string ‘T00:00:00Z’ in the next field)
You can test the format output in the calculation trace. Should look like this:
Check if the result has the desired format. In my example it is: chekhov_2017-09-30.
So it is exactly the userid_YYYY-MM-DD format that the accrual base object needs. Luckily ;-).
But we are not yet finished with the field formatting. We need to tackle the other fields as well. But these are simple field associations for:
- Actual Quantity ← Collector Value
- Date ← Valid To
- User ← User
As a last step, make sure that the Operation for the Accrual Calculation Base is set to Upsert MuLTIPLE.
Please note: please choose UPSERT MULTIPLE instead of UPSERT SINGLE as shown in the screenshot. This makes the process more faster and performant.
Step 4: Filtering the Time Collectors
For the planned integration scenario, we have to filter the time collectors according to their external code – we only want to use our new time collector ‘COL – Working Days per Month’. A second filter needs to be defined to only read those time collectors, which contain the final value for that collector. Since Time Collectors are saved per time sheet, they have a field named Last Posting Date, which contains the end date of the time sheet for which the time collector’s value was calculated for or the End Date of the time collector, if its period ends in the middle of a time sheet. For the creation of accruals from time collectors, we are only interested in the end value of the time collector. This is the case for those collectors where the Last Posting Date is the same as the period End Date of the collector. Therefore, we add a ‘Calculated Filter’ to filter out all time collectors, where those two fields are not the same.
The Calculated Filter for the Last Posting Date looks like follows:
With these settings, you can run the integration scenario to test whether it creates the desired results. In the case of our example, this means it will create objects of type Accrual Calculation Base for each instance of a time collector with name where the Last Posting Date is equal to the Valid to date.
Step 5: Time Account Setup
The setup of the time account which will receive the accruals based on time collectors is the same as for any time account for ‘Accruals on Actuals’. That is, the time account type must have the field Accruals Based On set to ‘Recorded Times’.
If employees have time types in their time profile, which deduct from time accounts of that time account type, the Accrual Calculation Base objects, which are created with the new integration scenario will be automatically considered on the next accrual generation run.
What you will setup for the accrual run, is the actual factor to post to the time account for each time collector. This means, the factor of 0.416438356 hours for each working day will be used in an Accrual Rule for this time account type. A possible Accrual Rule could look like this:
Step 6: Making it Happen
For testing the integration scenario, you probably used the option ‘Run Now’ in the Review and Run section. To let the system perform the integration scenario automatically, you will want to set a schedule for it.
Basically, you can schedule the scenario to run at arbitrary intervals, depending on the specific use case you need to configure. However, you need to make sure that only those Time Collectors are processed, which were created or changed since the last time the integration scenario was processed. You can do that by setting an additional filter for the objects, you want to select:
Use a Time-Based Filter, which selects only objects, which were modified since the last run time of the scenario. This reduces too many data volume and you get even those collectors that have changed based on amended time sheets or retro-active changes in the time sheet.
The accrual calculation base object gets filled. When you got retro active changes the old values in this object get overwritten and the accrual calculation run automatically runs from this period onwards again.
That´s it. Enjoy.
Many thanks to Hagen Eck for delivering the input.
7. To be considered in the time account accrual
Just added this one, cause there are some things you need to pay attention for in the time account setup and accrual.
When you use this kind of accrual variant – instead of the normal accrual where you get for each month or for each year vacation independent from your actual hours worked – you need to configure your time account in a specific way. Choose in the time account type (manage data) daily accrual as accrual frequency and accruals based on recorded times, not “standard accrual”:
We provide a dedicated time account accrual run for this scenario. The accrual change scenario is “Accruals on reported times” and not “accrual” like for a “normal” accrual run. Keep this in mind when monitoring the jobs via “Manage time off calendars”.
This change scenario runs then daily based on the “Trigger TLM task job” that needs to be switch on in provisioning. The TLM trigger task job is the main job for Time Management, doing lots of things not only the accrual. So, please ensure that this job is switched on (but it should be already, otherwise lots of things won´t work in your system).
Hi Sir!
We're actually in the middle of our implementation of Employee Central and we parked the Time Off/Time sheet module in the project because based on initial diagnosis, Time sheet is not sufficient for our business requirements. I have two questions re: the article above:
Hope to get your feedback soon!
Hi Jean,
the second point first, cause that´s clear to me:
Yes, the 2.0 multiplier for an overtime / time off accrual can be applied for those employees that are more than 5 years employed. However, you need to assign a different time recording profile to this employee in the job infor then starting from his 5th anniversary date. There is no query that checks automatically the anniversary date of the employee and if less 5 years OT 1.5 if more than 5 years OT 2.0. Imagine the performance impact: upon each time record job information would need to be read and this costs performance.
But when you assign a different time recording profile with the OT 2.0 as a pay component instead of 1.5 all works fine. Retro-calculation as well when the employee edits a time record before his 5th anniversary date ;-).
But just to inform you: for your business use case you don´t have to apply the above mentioned approach I described in the blog. You can use the time off in lieu functionality of the time sheet / time valuation. Please refer to the time sheet implementation guide to get more information on this. That´s much more easier than the above mentioned way to use working time for a vacation accrual. Time off in lieu can be calculated / posted without the integration center approach.
Then your first question:
Not quite sure I understood correctly what you mean. You are mentioning log in / log out, so I assume you mean Clock in / clock out. This is in general not yet possible at all in EC Time Sheet. We are currently working on this and this is a topic for 2019 releases. Currently an employee needs to enter start / end time (or duration only) in the time sheet - or you upload a record with start / end time (or duration only) via our import services into the time sheet.
When an employee gets a reminder notification he can open the time sheet and record retro-activly an attendance record. Time valuation performs a retro-calculation then.
Hope this was helpful.
Regards
Volker
Yep, what I meant in the first one was the clock in and clock out. This is super useful Sir! Thank you so much for taking the time to explain your answers in detail!! 🙂
Thanks for the feedback.
Volker
Hello Volker,
Thanks for this blog.
I tried to implement this but I have in collector only weekly results. I have collector set monthly and I see correct dates but number of days in collector is only on weekly basis. Did you tested this and worked ok for you?
Thanks a lot..
Jan
Hi Jan,
would always be helpful when you give more details. Where do you "see" the collectors on a weekly basis?
In the time admin workbench? Yes, we show there a monthly collector with each time sheets (weekly) contribution. The weekly periods appear there, but the collector has got the overall value of the month. This is done for more transparency and analytical reasons for the time admin that he can see which time sheet period did contribute what to the overall monthly value.
When you display the collector in the time sheet UI we show there the overall monthly sum of the collector. Cause an employee is more interested in the overall time collector balance.
Regards
Volker
Hello Volker,
I think reason is negative time recording. Collectors are not working for negative time recording?
Thanks
Jan
Hi,
collectors work for negative time recording as well.
Volker
Hi Volker,
thanks for quick response. Yes I see only week collector value in time sheet UI for EE with negative time recording but for EE with positive time recording I see overall monthly value.
In admin workbench for positive I see correct values but for negative time recording I see no values.
Dont you know why.
Thanks
Jan
Cause maybe you don´t have the time valuation rules for the collectors incorporated into your time recording profiles for negative time recorders?
Even though accrual Base calculation object was filled via Integration but accrual rule set on Time account type didnot trigger and calculated the accrual.
Time collector filled - check , Accrual Base object - check.
In Accrual Calculation Account Type Base, records are generated with to be processed status .
Scenario : Daily accrual based on attendance marked in time sheet at rate of .08
Realized
the automated standard job pulls in & proccesses the accrual .
Now , stuck with time collector Issue :
If employee regularizes the attendance and gets declined but still time collector captures that data irrespective of workflow status .. . How to control that ? Is that automatically take care of ??
Hi Ishmit,
By any chance, were you able to send across just the approved time sheet records to the accrual calculation base object?
Best Regards,
Aarti.
Hi Aarti
I had exactly the same question and eventually found the answer in KBA 2684414 - https://launchpad.support.sap.com/#/notes/2684414
It states:
Hope this helps others who face the same.
That said, this is a great blog and was very helpful. Thanks Volker.
Regards
Doug
Hi Doug,
I'm coming back to this again after a couple of years for a different client and the KBA link you have provided has helped clarify this query I ended up having again! Thank you.
Best Regards,
Aarti.
Hi Volker,
Hope you are doing fine and thanks for blogs; it helps us in utilizing the system well :).
I have a question or rather need assistance. I intend to use actual time booked under Additional hours maintained by part-timers to accrue leave entitlement. I have followed the steps you have mentioned above; however, in integration, I get an error and I do not see why this is happening.
The only difference in my set up is that I am accruing hours and not counting them.
Time Collector
Errors
Preview
Due to this error, I am unable to schedule the job. Would you know what the error is and how can I correct it?
Regards
Sanjay
Hello Sanjay,
you made a configuation error: you have on the left and right side a collector choosen. However, you need to choose on the left side your collector and on the right side the "accrual calculation base object" as described above. This object is read in the accrual run automatically.
Regards
Volker
Hi Volker-thank you for detailing out this procedure. It is very helpful.
I've been trying to understand if this can work in a similar manner for sending time sheet hours for short-term attendance time types over to absence time types. The scenario I'm working on starts with SAP CATS recording actual hours against Absence Types, which in turn will be sent over to EC Time Sheets via an integration. From there I'm wondering if the requested Time Off balance can be updated with the actual recorded from Time Sheets.
For example, if an employee requested (forecasted) Vacation for 5 days (40 hours) in Time Off, but the actual recorded in Time Sheets was 4 days (32 hours), can the time collector be used to update the balance for the Vacation Time Account Type?
Thank you,
Sualeh
Hello Sualeh,
I don´t fully understand the scenario.
So, you have got EC Time Sheet, EC Time Off and CATS?
What kind of data is recorded where?
You record an short term absence in CATS (why in CATS and not in EC Time off?) and you want to sent this record to the EC Time Sheet (why EC Time Sheet and not directly into absence time type from time off?).
When you import a full day absence record into time off and an employee requests in the same week a 5 days vacation this ends up either in a collision check or in a split and delimit of the requesting entry.
Regards
Volker
Hi Volker-
Thank you for the reply.
Correct. Actual hours are recorded in CATS because that system has already been established as the source of record for employee hours and tied with the finance system. Our intent is to allow employees to forecast (request) time off in EC Time Off, but have the actual hours feed into EC Time Sheets to visually see how many hours an employee took on each day against an absence type.
We are hoping to then leverage the actual hours to update the forecasted time off request along with the balances against that time account. We want balances to be tracked in EC Time Off only. Have you seen this done before?
I understand that the absence record can be loaded directly into Time Off, but the collision check isn’t working when loading a Vacation absence against an existing Vacation absence.
Thank you,
Sualeh
Wow, the scenario is not yet clear to me.
In Cats you record absences. That don´t deduct from a time account. Then you load this absence to EC Time Off where the time account deduction shall be done. And you use EC Time Sheet to visualize the absences.
Did I get this correct?
No. I haven´t see this before and it is a bit tricky, isn´t it? What does an employee do when in CATS the vacation is recorded (no time account deduction here) then transferred to EC Time and runs into an error cause the time account balance is not sufficient? Who informs the employee? He needs to edit the vacation record in CATS.
And collision check works in EC Time even when importing an absence (otherwise it would produce messy results). The collision check in your example - absence type gets recorded overlapping the same type - results in an error. You can configure a "split and delimit" - but this works only with different time type. Like: an illness type delimits automatically an existing overlapping vacation.
But this is it. There aren´t that sophisticated configuration options than in the nice SAP ERP Table T582s.
Regards
Volker
Hi Volker-thank you for reply.
Correct. Employees are allowed to have a negative balance in their time accounts in EC for up to 1 accrual year’s balance and there currently isn't a plane to present a system error on a sufficient balance. Employees will be informed by the talent team, external of the system, when this occurs. Being that CATS was already in place and live, our only option is to record time entries there. Short term time off balances aren’t tracked in CATS and thus we are hoping to leverage EC time off, since employees will also be accessing SF for other modules.
In regards to the collision check, I meant to state that I do understand the limitation of it’s capability that an identical Time Type (example Vacation) can’t be imported onto an existing one. Thank you for reaffirming.
At this point, the most viable solutions looks to be to transform the time entries leaving CATS into an upload file for decrementing balances in EC Time Off directly and skipping EC Time Sheets. Only limitation is that we won’t be able to graphically see day-to-day hours of what was requested.
Thank you for your insight.
Very much appreciated,
Sualeh
Well, you could use the External time data Odata API to load attendance times into the time sheet. But I would not do this only for the sake of visulazing the recorded hours per day / week.
Absences can be imported via file upload.
Hi Volker,
I hope you don't mind me asking a time-sheet related question here. In our time sheet build we use attendance time types, on-call time types and allowances. We need to send this data to our payroll provider, which we do in Advanced Analytics.
However, it seems like we have to create two separate reports as allowances are kept in a separate table to the other time types.
Do you know if there is a way around this? It's all time sheet data, so I'm surprised it can't be picked up in the same report.
Thanks for your time.
Ashley
Did you check the time valuation results? All data should be in there. This is how we replicate data to EC Payroll / SAP onprem Payroll and allowances are a time valution result, too.
Regards
Volker
Hi Volker,
Hope you are doing good. Good to have you around.
When I am importing actual hours from 3rd party in Actual calculation base object for my Sick leave accrual calculation , then how I should use my accrual rule for sick leave to read the actual hours stored in that object ?
Can you send me an example of the accrual rule where we utilized the actual calculation base object . Please explain me the details here .
Thanks
Avik
Hello Avik,
there is a chapter in the EC Time Off Implementation guide on "Accruals on Actuals in days or hours" that explain the scenario.
And in the "rules and concept" guide you find a rules example in the "Accruals on recorded times" chapter.
Hope this helps.
Regards
Volker
Thanks Volker,
Though I have some doubt here which I want to clear here.
Let me know if my understanding is correct here-
When uploading the attendance data from 3 part in EC , I should use "Accrual Calculation Base" object with exact External Code as mentioned in the guide with Date(daily) and Actual Quantity and user . Correct?
What is the significance of Quantity 1 to Quantity 5 here? what I should use here while uploading the data from 3rd party?
And "Accrual Calculation base parameter" object will be created automatically by the system to support/supply the actual hours/days to the accrual rule if my associated Time account type is having "Accruals Based On - Recorded Times" selected. If it correct?
Means based on the Time Account type's frequency, "Accrual calculation Base Parameter" will cumulate the daily actual times from the "Accrual Calculation base" object and supply it to the rule for calculation.
Please correct me and explain.
Thanks..
Avik
With quantity 1-5 you can fill different time accounts for example. If you have got only one time account, just use one quantity.
And the rest should be: yes.
But most learning effects are when you start to try this out in the system 😉
Regards
Volker
Hi Rouf,
Very good bolg
when we are trying to replicate this solution in our demo system we are not finding Accruals on reported times in Manage Time Off calendar. Pls suggest us if there is any upgrade needed to see this scenario in Time off calendar.
Thanks and Regards,
Parthu.
Hi Parthu,
no upgrade needed. This feature exists since approx. 2 years - it was used for external time management systems to send the hours worked into the acruals calculation based object so that time off could accrual based on recorded hours in a 3rd party system.
Regards
Volker
Hi Rouf,
Thanks for the response, in that case why I am not able to see the “Accruals on reported times" in the system, do I need to activate anything to see it in the Time Off Calendar?
Thanks and regards,
Parthu
Hi Rouf,
I hope you doing well and back in central europe. I have a question for which I hope to get a response soon.
Our client has timesheet employees for whom absence entitlement needs to be calculated based on numbers of hours they work. We have used 'Accrual base parameter' for it and updating it via integration. This is used for annual, personal and long service leave.
They also have another entitlement which is based on different working hours. RDO entitlement is based on RDO hours they have worked in the week. Since there is only one Accrual Base Parameter; if we use the same solution I believe it is conflict and there is only one accrual base parameter to be used in Accrual rule.
Is my understanding correct and/or is there any other solution to meet the requirement.
Regards
Sanjay
Hello Sanjay,
no, there are several accrual base quantities. I think 5 different quantities.
Hence you can use a different quantity field for the RDO hours.
Regards
Volker
Hey Volker,
For our client we need 8 Accruals that are interfaced with "Accrual Calculation base” object but tere are only 5 quantities.
Is there something foreseen in the near futher to have more then 5?
Or is there an alternative for this?
Thanks a lot,
Steven
Hello Volker,
Thanks for this blog.
baldeb
Hello Volker,
We are implementing Duration based time sheet for a client.
We have a requirement as below.
Employee is allowed to claim 40 hours of overtime every month, anything worked more than 40 hours needs to be applied in the next month.
Please let us know if this can be handled in EC Timesheet.
Thanks,
Vidhya T.R
Hi Volker,
Could you please kindly tell me, can the following request realize?
The quota of “Time-In-Lieu (Time Type)” is generated from the application from time sheet, and effective period for each over-time record converted to Time-In-Lieu quota is 12 months.
For Instance, John applied for 5 hours Over-time on 01/01/2019 and it was approved, then the Time-In-Lieu quota is automatically added 5 hours. This 5 hours quota expires on 01/01/2020. Now he has 8 hours Time-In-Lieu quota in all, 3 for previous applied and 5 for this time. When he applies for Time-In-Lieu, he can see from the Time-In-Lieu Time Type, there are two records converted form Over-Time with different expirations.
Hi Volker,
We would like to get your expert advice on the below requirement.
Employee can get Bank Time account value based upon Bank Time type recorded in Time Sheet. And Employee can get maximum only one weekly hours (say 8*5 = 40 hours) into Bank Time Account Type over a Year.
We have configured the Time Type Group with Bank Time Hours and in the Time Valuation we are getting details under the Time Type Group (RECBANKTM).
Now my question is can we able to use Integration Center to pass this Time Type Group Value to Bank Time Account Type and also can we handle that Maximum Hours as well.
And Bank Time Account Type value reached to maximum 40 hours (based upon the employee WSR details of weekly hours) then in the Time Sheet would not be accept the Bank Time Type Entry.
Time Valuation Trace details
Regards,
Sankarsan
Hello Sankarsan,
sorry, saw this question only now. Probably too late now.
I don´t really understand what you want to do with the banked hours in the INtegration center.
Second: you can limit the hours in the time account for example weekly, monthly or yearly. Check our new feature "periodical time account update" - I think this is what you need. It does not really provide a daily check against for example 40 hours, but a periodical check.
Best regards
Volker
Volker Ruof
Hello Volker,
Many thanks for the blog. In the 2nd scenario (standard behavior of time off in lieu); normally we have TOIL as Permanent Account and balances are posted based on Timesheet Entries.
Is it possible to configure this TOIL as recurring account with account validity : 01.01 - 31.12 ; but with booking validity : +3 months (i.e. 01.03 of next year)?
Will the system automatically post balances from January timesheet in the new account?
Or how can we achieve it?
Regards,
Mohit
Hello Mohit,
yes, I think this should be possible. But I always used permanent accounts, so, would be good to get your feedback here.
But one question: why? What is your intention setting this up as recurring accounts?
Do you want to have a kind of cut-over or forfeit of hours from the previous year at end of march?
Maybe our new function for permanent time accounts helps a bit: you can run automated periodical time account handling for permanent time accounts in a way that for example end of year, each 3 months or whatever a job runs that cuts the time account balance at a defined threshold. We provide an own UI for this that administrators can see what this process has done and they even can do corrections if for example for an employee 10 hours have been cut, but this employee has a special permission and you can correct this to only 5 hours cut.
Best regards
Volker
Hello Volker,
Your understanding is correct. The hours accumulated in TOIL in last year(2020) should be forfeited at end of March 2021.
Yes, with the automatic time account handling(new feature), this job will run on 31st March. But it will forfeit the balance as of 31st March 2021. (instead of only that balance till 31.12.2020). Probably we can handle via rule to check the balance as of 31.12. and forfeit that only.
But another issue is , I should not be able to apply leave(TOIL) for April 2021 in January 2021 with balance of last year. So, the automatic job will forfeit the balance on 31st March. So before that I can use the balance of 2020 to apply leave for future dates. To restrict this, more rules would have to be created.
This functionality is automatically provided by Recurring accounts using Booking period . But I am not sure if it would work in association with timesheets. 🙂
Regards,
Mohit Somani
Hi all,
thank you for the detailed information. I have implemented the szenario according the blog. The accrual calculation base has been created via integration job for test user. But the accrual run via Manage Time Off Calenders doesn't work means neither the account nor the accrual is created.
The idea is to collect the weekly time collectors for home office days/ hours recorded via time sheet inin time account type on a yearly basis.
What I have realized is that no Accrual Calculation Account Type Base has been created for the relevant user but I don't know whether it should be created by the integration center run as well
and what's the reason why?
I understood that acounts for normal accruals (absences) are created once the related time type ispart of the time profile of the relevant user. But here we are talking about attendancies they are partof time profiles but there is no connection to Time Account Type.
BR
Dirk
Hello Dirk,
Hope this helps.
Volker
Hi Volker,
many thanks for the prompt reply. Please have a look at my Time account type settings and the assigned business rule.
Maybe you can identify the issue.
Many thanks in advance.
BR
Dirk
Hi Volker
It is possible to have different types of collectors in the same integration and for these to be added into one, since the accrual calculation base object only allows one per entry in the intagration, that is, I have the specific scenario where two types of time can be registered in the same sheet, the integration receives the two collectors, suppose one with 420 and another with 300, but it only sends the 420 object to the accrual calculation base object, which is the first one that is reported in the time sheet, also try to create independent integrations but when calculating the last day of the week the system only accumulates for the time collector of 420.
it is possible to have an integration that adds the values of the collectors and publishes it in the accrual calculation base object
Hello John,
what kind of process do you want to support? Is it really an accrual process - where the accrual calculation engine is needed? The Accrual calculation based object has got 5 different number fields that you can use. So, I guess it should be possible to have different collectors fed different number fields in the accrual calculation base object.
But if you want to cover for example a use case where you want to feed different Time off in lieu accounts, cause you want tc collect work on Sunday compensation in a different time account than work on public holiday, then better use this approach - cause you don´t need the Accrual base object not at all for this process.
The accrual base object is only needed when you have processes like in Singapoore for example, where the vacation accrual of an employee is calculated based on his recorded working hours. This value is used in a daily accrual in the accrual calculation. But if you just want to transfer time off in hours to more than 1 TOIL Account, then please use the above mentioned approach.
Best regards
Volker
Hi Volker Ruof,
I was able to configure everything and I can see the Accrual Calculation Base that was created for the user after running the integration center. But cant find out if my Accruals On Actuals rule is working fine.
I think is all set as described above but isn't working. Can I trace the rule? How can I troubleshooting this?
Thanks
Hello Renan,
since this is a "normal" accrual scenario you can simulate the accrual and even trace the accrual rule in the normal ways. Please check the time offf implemenation guide for simulation and trace possibilities for accrual calendar runs.
Best regards
Volker
Hey Volker,
first, thank you for this great explanation. Now I must deal with a problem that I thought is a really commend one but it sems like there is no standard function available.
My goal is it to round the recorded timestamp. For example, if an employee recorded a start time 07:13 AM the system must round it up to the next 5 minutes. Result should be 07:15. I try to add an on-safe rule in combination with a lookup table, but I can´t get any results.
Is there a standard function that I don´t know or have you a Tipp for me how to manage that issue?
Best Retards
Matthias Schimon
Hello Matthias,
I assume you want to round only the first and last stamps? Or any time stamp?
There are workaround ways to do a rounding of any time record for example. This works via look-up tables and save rules.
And there are workarounds to round the first / last event only via time valuation. But unfortunately lots of time valuations are needed for this and it is rather complicated and I would not recommend this. Cause for this scenario we plan a standard solution in H2 release with tolerance times that you define in the day model workschedule. But as mentioned - this would only solve the scenario where you want to "round" clock ins / outs around the start / end of the planned working time. Like for exam you define a tolerance time of 07:50 - 08:10 (and start of planned time is 08:00) and you want to move any time event in that period to 08:00. This is envisioned for the H2 release.
So most important question: all time events shall be rounded or only the first / last one?
But if it is all time events your approach with save rules and lookup table is good.
And the save rule needs to be on the External Time Data.Start Time / End time.
And you need lots of entries in your lookup table if you want to round any event to the next 15minutes ;-).
We plan more advanced rounding capabilities as well - but one step after the other ;-). Focus in the H2 release is on the grace periods.
Hope this helps.
Volker
Hello Volker,
my in my actual case I must round the first and the last time event of the day. The External Time Data is a good hint. Up to now I try to use the Time Sheet Entry. I’m sure that is one of my Mistakes.
I create a huge look up table about 288 lines because I must round to the next 5 (five) minutes.
But there is a big Mystery for me. My Integration to create an Accrual Calculation Base works very well but now I must deal with a second time collector and a second Accrual Calculation Base. The Goal is to post times in serval Time Account Types.
The Big Question is: How is the Accrual Calculation Account Type Base define? The Time Account Type is coming without any definition. I want to understand and define the Time Account Type field at the Accrual Calculation Account Type Base.
Matthias
Hi Matthias,
can you describe your use case a bit more in detail? Is it for example that you want to post work on sunday into time account 1, normal overtime into time account 2, overtime on public holidays into time account 3?
Something like this? Then please don´t use the described approach. The approach above is meant to be used only for accruals. So, you have an input like hours worked and the accruals calculation engine uses this to create daily vacation accruals.
If you "just" want to post evaluated times like overtime into multiple time accounts, then please use this approach:
https://blogs.sap.com/2021/04/30/employee-central-time-off-multiple-time-off-in-lieu-toil-solution/comment-page-1/#comment-610407
Best regards
Volker
Hi Gurus,
I have a scenario where in the client is using time sheet. Now accruals are to be done based on employees working days minus holidays, paid leaves etc. We tried adding multiple scenarios in the environment.
Results - Emp 1 - Working days 25.5 = Leave accrued =2
Emp 2 - Working days 25 = Leaves accrued =2
Emp 3 - Working days 20 + Leave accrued = 2
In the month of August we used multiple work schedules where Emp1 works 6 days a week, Emp2 works 5.5 days a week & Emo 3 works 5 days a week.
Surprisingly results were all the same.
Hi Volker,
AccrualCalculationBase: UPSERT failed for the row with key: AccrualCalculationBase/externalCode=sami.chalhoub@taqa.com.sa_2022-12-03. Reason: The external code contains illegal characters. Please don’t use special characters.. The row will not be processed for subsequent entities
.. because of this error, quota is not getting accumulated. is there a way we can instruct system / consider special character?
2) Also it give below warning -
AccrualCalculationBase: UPSERT failed for the row with key: AccrualCalculationBase/externalCode=31126_2023-01-07. Reason: The Accrual Calculation Base records between 01/01/2022 and 01/14/2023 all need to fall within the same 12-month period.;01/01/2022 cannot be earlier than 01/09/2022 (today minus a 12-month offset). Please enter another date or change the Accrual Calculation Base Offset in Time Management Configuration.. The row will not be processed for subsequent entities
is there a way we can stop above warnings? please let me know. Thanks.