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.