On the face of it, rounding of overtime hours in time evaluation seems to be a simple requirement that can be easily achieved. However, there are two different ways by which overtime wage types can be generated in time evaluation. The two methods are mentioned below:
1. Overtime Hours generated in time wage type through PCR
2. Overtime Hours generated in time wage type through T510S table
For the former, before adding the no. of hours to the overtime wage type, we can use operation ROUND to round off the overtime hours. Below is a sample screenshot of the same.
The overtime hours calculated through time types are first rounded off and then added to the overtime wage type.
However, in the 2nd scenario, the overtime wage types get generated based on overtime rules defined in Table T510S table and then the hours in overtime wage type needs to be rounded off.
This is where the challenge lies. How to round off hours already present in the wage type in time evaluation?
Our client requirement was to generate overtime based on certain rules and parameters. We were successfully able to define these rules and parameters in Table T510S and overtime wage types were getting generated successfully as per the client’s requirements.
The client had additional requirement to round off overtime hours generated in the wage type. Any value between 0 and < 0.5 should get rounded off to 0 and any value between 0.5 and < 1.0 should get rounded off to 1.0 and this should be rolling over.
So how do we achieve this?
As earlier mentioned, operation ROUND works with time pairs and time types but not with hours in time wage types.
I researched through time functions and operations to find a way to round off the overtime hours in time wage types generated via Table T510S. Finally, I was able to find a function PZL and an operation OUTZL which helped me build this solution.
PZL function provides a personnel calculation rule (Par 1) with wage types for processing based on the identifier (Par 3) and deletes these wage types from DZL or ZL table. If we want the wage types to remain in DZL or ZL table after processing, we will have to use operation ADDZL to transfer the wage types back to DZL or ZL Table.
A time wage type can have three possible identifiers:
- S – Planned Work
- M – Overtime
- A – Absence
In our scenario, the wage types will have identifier M.
OUTZL operation will help us to query the overtime wage type for rounding off. It will be used to query wage type M806 (overtime wage type generated in our scenario) from Table DZL and then the hours of the wage type will be rounded off and added back to the Table DZL.
We will use the standard rounding rule 01 in Table V_T559R for rounding requirement as shown in the screenshot below:
We will also create a PCR ZAD6 for reading the no. of hours in overtime wage type and rounding off as per the rounding rules. Below is the screenshot for the same.
PCR ZAD6 reads the wage type from Table DZL using operation OUTZL WGT. If the wage type is anything other than M806, it is added back to Table DZL.
If the wage type is M806, the hours of the wage type are read using operation HRS=ENUM, then rounded off using operation ROUNDHR01 and finally added back to Table DZL using ADDZLMM806.
Function PZL is used to process PCR ZAD6 and it deletes the wage type from Table DZL after reading it. The wage type with rounded off hours are again added back to Table DZL after the PCR processing.
The function PZL and PCR ZAD6 are finally placed in the time schema as shown below:
The solution design and build is finally complete and hence, let us now test it.
01-Sep-13 is an off day.
We have created the overtime hours in IT2002 for the employee using attendance type 0801.
The employee has worked for 3 hour and 10 mins of overtime on 01-Sep-13. However, after rounding off, he should be paid only 3 hours of overtime and not 3.17 hours of overtime.
The time evaluation is run for 01-Sep-13. Let me show you the processing for the given date.
Table T510S Processing
Below is the processing of PCR ZAD6 by function PZL. The hours get rounded off from 3.1667 to 3.0000.
Let us now view Table ZL.
Here, I come to the end of this knowledge artifact. I hope this has been useful for you. Thanks for your patience to go through this.
Please feel free to give feedback on this document so that I can improvise on future publications.
Thanks and regards,
You can also refer to other knowledge artifacts created by me at the below link: