- SAP Managed Tags
Averaging in SAP Payroll
Introduction
SAP Payroll consultants are sometimes faced with a requirement where the rate of payment for a certain wage type needs to be an average rate of a sum of some other rates over a certain number of previous periods.
Real-life examples in Australia include:
- “Where, prior to the taking of leave, an employee was paid a uniform allowance other than at the weekly rate, the rate to be paid during absence on leave will be the average of the allowance paid during the 4 weeks immediately preceding the taking of leave.” From https://awards.fairwork.gov.au/MA000027.html
- “Part-time Employee – the Employee’s contracted hours, save that where the part-time Employee’s ordinary hours fluctuate because the Employee works additional ordinary shifts (but excluding a permanent variation) an average of the Employee’s ordinary hours over: A. the preceding 12 months; or B. the Employee’s period of service where the Employee has less than 12 months service; will apply where this is more favourable to the Employee” from https://vahpa.asn.au/wp-content/uploads/2023/01/AHP-Vic-Public-Sector-Single-Interest-Employers-EA-2...
Analysis
In the interest of fully implementing such complex legislative requirements, we are faced with the following options:
- Manually calculate the average outside the system and input it in payroll, thus simplifying the calculation
- Create a custom function/operation to calculate the average of a set of wage types, which gives more flexibility in ABAP but increases the complexity
- Leverage standard SAP functionality to average wage types and show the end user a full log of what’s happening under the hood
Option 3 is the cleanest way to do it but there are very few examples. Options 1 and 2 are mostly favoured and in the interest of time, projects go live before anyone investigates further. SAP Payroll has the standard AVERA function which does this heavy work very cleanly and you can read Technical Process of Average Processing (New) as a reference guide when implementing it.
Payroll -> Payroll: Australia -> Time and Payment/Deduction Wage Type Valuation -> Averages (New) has all the configuration nodes to enable this, although these tables are available in almost every SAP Payroll country’s configuration node.
Figure 0 SPRO Node for Averages (New)
Step-by-Step T51AV* Configuration
Let’s take an example of averaging step-by-step. Suppose the requirement is for payroll to calculate the average of overtime/penalty amounts and hours over the past 6 weeks.
1. V_T51AV_2W Primary wage type to Average Bases
Assign the “to-be-averaged” or "seed" wage type to an "average base" /2XX wage type in V_T51AV_2W.
Figure 1 Seed Wage type to Average Base
V_T51AV_2P has options to prorate based on TASOLL, TKSOLL or TSSOLL but we won’t be needing that here.
The next is a critical sequence of 8 steps culminating in “Calculation Rules for Averages”.
Figure 2 SPRO Subactivities
2. V_T51AV_R Relevance Rules
Create a custom relevance rule for your case in V_T51AV_R. All payroll periods are relevant. There are options to exclude relevance of some periods based on rehiring, partial overlaps, etc.
Figure 2.1 Relevance Rules
3. V_T51AV_ROC Exclude Offcycle Reasons
If you want to exclude from averaging for example, a set of penalties paid as part of a one-off offcycle bonus payment, then this can be configured in V_T51AV_ROC.
Figure 3 Exclude Offcycle Reasons
4. V_T51AV_C Adjustment Rules
To cater for scenarios where payscale increases can increase the value of the underlying “to-be-averaged” wage type, use V_T51AV_C.
5. V_T51AV_B Cumulation Rules
Configure a new entry in V_T51AV_B cumulating the number and the amount fields and specifying a factoring specification F to ensure that penalties are prorated as per calendar days if only part of a payroll period is to be averaged.
Figure 4 Cumulation Rules
6. PCR Q018 or a custom-copy of it
AVERA allows call of a custom PCR (copied from standard Aus PCR Q018) to finally divide the total by the number of average periods
Figure 5 Standard Calculation PCR
For this requirement, we create a custom PCR to store the number of average periods taken into account into a variable.
Figure 6 Custom Copy of PCR Q018
7. V_T51AV_E Linkage of PCR
We link this custom PCR to a newly configured Final Processing Rule in V_T51AV_E.
Figure 7 Linkage of PCR
8. V_T51AV_W Comparison Rules
If there is a requirement to compare this averaged value to another wage type within that period, then this can be configured within V_T51AV_W. This is useful in cases where the legislation requires the higher of two rates to be paid, or if the customer simply wants to intervene and provide a higher rate.
9. V_T51AV_A Calculation Rule for Averages
We tie it all together in V_T51AV_A and provide 6 calendar weeks as the time period to average (3 fortnightly payroll periods).
Figure 8 Calculation Rule
The custom rule specified in V_T51AV_E always places the average in the rate field of a resultant /1XX wage type linked with the V_T51AV_A rule in table V_T51AV_P.
AVERA does not get activated if we attempt to place a custom wage type instead of a /1XX wage type, so this may be a standard limitation.
Hence, in this example, a /199 wage type needs to be created to hold the final average rate.
10. V_T51AV_P Average Bases to Output Wage Type
As you can see below, the resultant wage type and the average rule have now been linked.
Figure 9 Average Base to Output WT
Payroll Testing
We are now ready to run payroll and look at the result.
Figure 10 Payroll Periods
Drilling down into AVERA function in the payroll log, we get the following picture.
Figure 11 Averaging Time Slices
Remember, we specified in V_T51AV_A that we are using weeks as the time unit. To determine what is the last day of a week, we also incorporate a change in Feature LDAYW, that makes Wednesday the last day of a week, which is in line with the payroll period last date.
Figure 12 Feature LDAYW
Understanding the calculation
If you look at the underlying Infotype 2010 records that actually averaged out, you can see that they have the same number of hours. In reality, these wage types may originate from Infotype 2002 (Time evaluation in ECP / On-premise SAP Payroll) or from Infotype 14/15 or even be a basic pay allowance.
Our scenario here is an EC Payroll example which gets these entries into Infotype 2010 from EC Timesheet / SF Time Tracking / External Time system
Figure 13 Infotype 2010 Wage Type Records
Figure 14 How the constituent wage types look in Payroll
These Infotype 2010 wage types are cumulated to a notional wage type in a PCR as shown below. Our requirement here was to aggregate all penalty/overtime payments and average them to form a rate over 6 weeks.
Figure 15 Aggregating the Seed Wage Type
The idea is to preferably place this custom PCR in the payroll schema immediately after the individual wage types get calculated, otherwise they may get written to RT or thrown away later.
I have placed this custom collating PCR just before X023 does an RT storage.
Figure 15.1 Subschema XAL9 or QAL9
The initial seed wage type and the final output wage type, in this case, 9901 and /199 need to be notional, i.e. not adding to net pay and not taxable.
The final /1XX wage type also needs to be available in the IT, otherwise AVERA will not pick it up. Hence, I have just created it with a dummy value in the following PCR.
Figure 16 Output wage type with a dummy value
This also means that after I have the final average rate in /199, I need to copy it to another wage type and throw /199 away in another PCR towards the end of my schema.
Going back to the payroll log and function AVERA, Rule Z018 takes the average value and places it into the rate field of /199. I have also inserted some more logic to get the number of payroll periods traversed into a separate variable.
Figure 17 Custom PCR writing to Output WT
The final average rate sits pretty in my output wage type in the IT as shown below.
The amount is still that dummy value added before.
Figure 18 Output WT with Average Rate
Conclusion
It is possible to meet averaging requirements entirely with payroll functional configuration. This saves the efforts of ABAP developers and helps focus their attention to more complex custom developments.
| User | Count |
|---|---|
| 12 | |
| 7 | |
| 5 | |
| 4 | |
| 3 | |
| 2 | |
| 2 | |
| 2 | |
| 2 | |
| 2 |
