Introduction - This article relates to scenario where absence entitlement are calculated in external system but are used in Employee Central Time Off for employees to record absences.
Background - Migration to SuccessFactors from on-premise SAP HCM and non-SAP ecosystem is happening for last few years and this will continue to grow. At times multiple system are needed like Kronos as work-force management for rostering, capturing actual times worked by employee, award interpretation. Level of complexity involved in calculation of absence entitlement forces the decision to set up the accruals calculation in Payroll system or other external systems. This could be Employee Central Payroll or non SAP product.
In such instance when Employee Central Time Off is a source of absence records and absence entitlement calculation in external system; then the challenge is to update entitlements in Employee Central Time Accounts at regular frequency. This scenario is primarily used for salaried employee. This issue can be avoided if the accruals for salaried employee are in EC Time Off; but some time its not possible; example Large scale business; where the complexity of calculating accruals restricts it be set up in EC or companies who have employees that migrate from salaried to hourly employees and vice versa.
Content - SAP Payroll / Employee Central Payroll folks who are familiar with Infotype 2013 – quota correction can understand the ease of updating the entitlement with the current value and ignoring the previous entry. Note that previous entry does get deleted but it is Time Evaluation (PT60) identifies the delta between the overwrite value and existing value. Unlike quotas in ECP/SAP; there is option to overwrite the value in Employee Central in Time Account; but it can be increased or decreased. EC has a ledger based system for Time Account. It will accept the delta difference happily and post.
Note that absence recorded in EC which has Time Account linked to it (example Annual Leave, Sick leave) will reduce the entitlement. Absence replicated to ECP or other payroll system will reduce the quota also as the payroll system is master of accruals.
Issue- So to update the time accounts in EC there are possible options
- Update the delta for which
- Payroll system needs to calculates the delta of accruals/entitlement and interfaces to EC to update the time accounts.
- or the Interfaces calculates the to-date value and before updating the time accounts in EC.
With my 15 years of experience in on-premise SAP payroll and EC payroll for system to generate the delta difference needs a good amount of ABAP coding, custom tables which holds the previous period information to identify the delta. Last time I checked there is no SAP standard solution available now. I assume that will be not easy in other payroll systems also. Or if interface is to calculate the delta difference in EC before posting it will need a good amount of development.
Both above methods will increase the entitlement by posting a delta difference. Time Account will display the audit of delta increment and reduction by absences. Note I am not including payout in this case as it works in the same as absence of reducing the entitlement.
- The other option is to overwrite the original entitlement value in the time accounts every time accrual is calculated. Example at migration employee had a balance of 100 hours and every week employee earns 2.5 hours; then in this case the original record with 100 is updated to be 102.5, 105, 107.5, 110, 112.5…..you get the point.
I see this a big issue because every time original entitlement record is updated we lose the audit. There is another big issue; EC Time accounts are ledger based; it will have negative posting when absences are recorded that reduces the entitlement. Every time the original entitlement recorded is updated it will recalculate the balances for all the absence recorded. Imagine accruals are calculated and posted every week; each week balance after every absence taken will change. Few years down the line this will be so enormous amount of recalculation.
Also whenever there is a query from employee, manager....since there is no audit in EC admins will need access to payroll system to analyze the posting.
Solution - Curiosity stuck to identify a better solution which meets the following requirement
- Payroll system to calculate up to date entitlement and sends it to EC
- EC Time accounts are updated with delta difference i.e. increment.
- Between step 1 and step 3 somewhere delta is to be calculated.
Could not find any standard solution / interface which do the above. What if payroll supplied entitlement values is stored in EC and then a rule identifies the difference between current value and new suppose to be value. Use Accrual Calculation Base and Accrual rule can solve the issue.
Inspiration of this approach came from a blog post by Mr Volker Ruof’s.
Link to blog can be found here.
The following process flow is based on the accrual being calculated in ECP. Concept will be same for other payroll system; with differences in methods; terminology….
- Payroll calculates accrual ->
- Interface uses program - RPTQTA10 to get to date entitlement after time evaluation
- Interfaces (CPI) creates data in Accrual Calculation Base
- Accrual rule in EC calculates the delta value using the value from Accrual Calculation Base and Current Balance.
Configuration - Lets get into details
Accrual Calculation Base has User Id, Actual Quantity, 5 fields for quantity and with a date and external code. So I can use a single object to record multiple types of entitlement values per employee; per date. Lets assume accruals are on weekly basis and we have 4 types of entitlement. I have renamed labels of quantity 1 to quantity 4 according to the time accounts. If needed additional quantity fields can be created as a custom field in the objects.
Accrual Calculation Account Type Base – When data is created using Accrual Calculation Base object it creates data in ‘Accrual Calculation Account Type Base’ object. This is similar to Accrual Calculation Base but has few additional fields.
- Accrual Period ID – hold the date in YYYY-MM-DD format
- Account Type – Time Account Type. For each account it creates a record; so in this case for every one record in Accrual Calculation Base we will have 4 entries in Accrual Calculation Account Type Base. Note that configuration in Time Account Type is a reference here.
- Start Date – Start of accrual period. In this case it will be weekly as time account type configuration
- End Date – Same as start date; end of accrual period
- Status – standard i.e. To be processed, Processed, Error and Not Relevant
I have changed the label of quantity 1 to 4 to match with Accrual Calculation Base
Time Account Type – Here the config is similar with an exception that accruals are bases on Recorded Times. Frequency for the time account is weekly with week starting on a Monday (Frequency Start date)
For simulation accrual rule will be based on work schedule. Actual accrual will be based on recorded times; more on this is next.
Note that I have not updated any recruit rule and termination rule. There will be no recruit rule as the calculation is based in payroll system and termination payout will be performed in payroll system on termination.
Accrual Rule - Accrual is a simple rule which basically compare the To Date value from Accrual Calculation Base and current balance from time account. For each time account using the correct quantity field is important. In this case Annual Leave is Quantity 1, Personal Leave is Quantity 2, Long Service Leave is Quantity 3 and Sick leave is Quantity 4.
Time Type – Create a Time Type i.e. absence type. Associate Time Account Type to time type
Time Profile – Create a time profile and assign time types. Note that my solution has Time Recording Variant as Clock Times; but this can also be used for Duration.
Testing
Time Accounts - Once the time profiles are assigned to employee it will auto create the time accounts. (for time account on recorded times time accounts are always created automatically)
Accrual Calculation Base – I have created data in Accrual Calculation Base manually via Manage Data. This is part which will be created by interface from payroll. Note for reason like budget constrain or CPI resource availability data in Accrual Calculation Base can be created using import file. In this article I am loading a file via import and export data.
In my example; employee has 0 hours for Long Service Leave. In Australia, Long Service Leave entitlement is given when an employee completes certain years of service. These years of service can vary depending upon the state and industry
Accrual Calculation Account Type Base – data in this object gets created immediately once the data in Accrual Calculation Base is created. Record in this object is against each Time Account Type (Annual leave, Personal Leave, Long Service Leave, Sick Leave)
Initially the record will have a status as to be processed. Once the accrual job is processed status is updated to ‘Processed’ if is successful and Error if failure.
Note that there 2 fields for dates; i.e. start and end date; these are accordingly the accrual frequency. If the accrual frequency is daily then the start and end date will be same
Time Account Change Calendar – job to process the accrual rule will run daily automatically however if you wish to run manually it can be done via Manage Data. The only reason to manually to perform testing otherwise if processed on adhoc basis it can create inconsistency.
You can see the job details in Manage time off Calendar also; but unlike accrual on work schedule; accruals on record times cannot be reprocessed via Manage Time Off Calendar
Results – once the time accrual job has been processed it will update the time accounts as accrual.
File upload – an interface i.e. using Odata can be used to update Accrual Calculation Base; similarly a file can be uploaded using import and export data. Here is an example
Once the file is uploaded successfully it will create data in Accrual Calculation Base; which will create data in Accrual Calculation Account Type Base
Note - per file should 1 record per employee. If you have too many records uploaded it will be created as to be processed and a next batch run will process all of them. Which will lead to inconsistency.
And accrual job will calculate the delta difference and post as accrual.
Some observations as part of my discovery
- Timing is crucial.
- Accrual job will run early morning depending on location of data base
- Absence records can be created any time during the day which will change the balance entitlement.
- it is recommended that accrual calculation at the source data base (Payroll system) to be processed at the end of the day after absence records are created
- Update of Accrual Calculation Base should be after the accrual calculation and before EC Accrual job.
- Per job run there should not be more 1 record per employee a too many record will create inconsistency.
- Date used in Accrual Calculation Base should be less than accrual processing date. Example if EC accruals are processed on 4th April; date in Accrual Calculation base should be no later than 3rd April.
- Accrual will be processed at the end of accrual period. In Accrual Calculation Time Account Base there is start-date and end-date. Accruals will be generated at the end date. So accrual calculation base should be created at the end of the week if it is a weekly. If the accrual calculation in the payroll system is at the beginning of the week or mid week; then set frequency of time accounts daily. This will allow to post the data only when data in Accrual Calculation Base is created.
- To avoid any misuse of data; secure the object. In configure object definition set Accrual Calculation Base and Accrual Calculation Account Type Base objects to be secured under time management. Give access to necessary admin team only so that unnecessary data is not amended to avoid which could cause inconsistency.
Summary - Using a standard object to date entitlement can be stored in EC and EC Time off Accrual can calculate the accrual value using current value and up to date entitlement. This way payroll can continue to calculate entitlement and also EC can display the accrual value with audit report without any adverse effect.
Reference - Blog Post by Volker Rouf -
https://blogs.sap.com/2018/05/29/ec-time-tipps-and-hints-nr.-5-how-to-accrual-time-accounts-based-o...
Hope this was useful and let me know if you have any questions.