Rounding Issue in SAP Time Management
Working in SAP I’m sure that we can all agree that one thing always remains true, which is there is always something new to learn. I truly hope that this blog helps those who are perhaps facing the same issue.
The Requirement:
I received a requirement from my client to create a seniority based quota accrual method for vacation time, which would need to round up or down to the nearest whole hour. The vacation entitlement was to be prorated based on a pre-defined formula which was specified by the client on the 1st of the month following 6 months from the last hire date. Sounds pretty simple, right?
The formula:
Example: (I will reference this example throughout this blog post)
- Employee is eligible in August
- Base entitlement based on seniority is 80 hours.
- Entitlement = 80/12 * 5 = 33.3333 = 33 hours
The Setup/Configuration:
Typically this would be set up as follows
- The base entitlement amounts are seniority based in configuration for the various years of service.
- The selection rules use a time type as a multiplier to trigger quota accrual
- The formula specified by the client is put in the PCR to correctly prorate the base entitlement by setting the correct value in the multiplier utilized by the selection rules.
- The formula for the time type was set up as follows:
- HRS=1
- HRS/12
- HRS*5
- ADDDB9SAV
- Using the example above this gives our multiplier a value of 1/12 * 5 = .4165
- .4165 X 80 = 33.32 You would think this would work, however in SAP it doesn’t. Instead I kept getting 33.6 (without rounding) which my rounding rule rounded up to 34. I’m sure you can all relate that for any client this simply won’t be acceptable, its an entire hour off 😥
Below is my multiplier
The issue:
After debugging the QUOTA function I realized that the time type that is used as a multiplier in your selection rule does not come from the TES table as one would imagine. Instead it comes from ZES! For all you techies I have identified the specific place in the code that the quota calculation takes place below. If you look at the variable GEN_ZES-ANZHL you will see the cause of the rounding issue in sap. Instead of multiplying the base entitlement amount (mul_lvnum) by .4165 from the TES table, it is instead rounding up the value to .42 which is used in the ZES table.
I took a look back at the values in time evaluation and behold, it surely is coming from ZES.
Now to figure out how we can accurately prorate and round the quota EVERY TIME….
The Workaround
To get around this rounding issue we must explicitly define the entitlement for each seniority group in the PCR itself. This means that first you must determine the employee’s years of seniority using the HRS=YSAY[insert infotype 0041 date] operation. Then we can group the entitlement amounts into separate ESG groupings in the PCR, determine the current month and calculate the entitlement using the specified formula.
As far as base entitlement configuration is concerned, you can simply use a base entitlement amount of 1 and will only need 1 base entitlement rule (like below). So its less configuration work, but more PCR work which isn’t a terrible trade-off.
The Result:
By determining the entire accrual amount through a PCR your calculation is much more accurate. As you can see below the value in TES accurate enough to mitigate the impact of any rounding that takes place when the value moves to ZES.
Value in TES
Value in ZES
Quota accrual after rounding rule: Voila, it works!
Thoughts:
My initial thoughts on this is why would SAP choose to use a less accurate value from ZES instead of the more accurate value which comes from TES? It seems a bit redundant considering you can specify a rounding rule. Perhaps in the future the data element utilized in ZES could be changed or the calculation itself in the QUOTA function could be modified? I’d be interested to see what others think on this issue.
Mr. Kory Thomas,
After doing the change as shown in the presentation. We should use QUOTA function directly to change the digits of copied programme. bcoz i think this is connected to ZKQ table and other things Standard HR reports right?
I wanted to know what will be the impact on the other things if we do like this.
Thanks,
Aruna.
Hi Aruna,
First I'd like to thank you for reading my blog post. Secondly, to answer your question there will be no impact to your reporting with the solution that I've outlined in this post. The QUOTA function is still utilized for quota accrual, we simply change the way the quota gets calculated.
I hope this answers your question, and if you have any additional questions feel free to ask.
Thanks,
Kory
But Kory,
Our ABAPer is saying for QUOTA function debugging we don't have access key. How to get the access process. is from SAP or from internal.
or could we copy QUOTA function and use in place of QUOTA function.
Regards,
Aruna.
Aruna,
As far as debugging is concerned that would be access to get internally. I was able to debug by putting an external breakpoint in the program and running time evaluation to trigger it.
As far as using a custom QUOTA function or using an enhancement spot to alter any of the calculations I can't say for certain what the downstream impact would be.
Thanks,
Kory
Kory,
Ours is Negative Time Management. in our Quota function there is no TES table so only ZES table we could see.
just have a look:
Its already 2 digits showing i've not done any thing.
In such a case how to change this.
Regards,
Aruna.
Aruna,
That is precisely my point, the value is coming from ZES and has therefore already been rounded. This is the cause of the innacuracy of the quota calculation. I'm not sure how you would change this without having some sort of downstream impact since its not exactly clear to me why SAP chose to use the value from ZES rather than TES or why they chose to use 2 decimal places for values in ZES instead of 4.
This is why in my example the quota amount is calculated in the PCR and passed to TES, so the value is much more accurate once it is rounded to 2 decimal places. It is more accurate to round the result rather than part of the formula (e.g the multiplier in TES).
Thanks,
Kory