Introduction

This knowledge artifact is an attempt from my side to explain the functionality of Pre-approved Overtime in SAP HCM using IT2007 – Attendance Quotas Infotype. Pre-approved Overtime is a functionality of Positive Time Management where the employee takes a pre-approval to do overtime for certain timings. Only the work done within the approval timings are finally counted as approved overtime. Any overtime done outside the approval timings are counted as unapproved overtime.

It will also explain the scenario of overtime in case of night shifts. SAP does provide a standard functionality for Pre-Approved Overtime using IT2007. However, our client requirement was slightly different and hence, there was a need to customize this solution.

The standard solution requires employee to first complete the daily planned working hours first and then any work done after planned working hours, can go towards overtime calculation. However, in case of our client, the requirement was slightly different.

Client Situation

Client was implementing positive time management. Any work done outside planned working times and overlapping with the approval (available in IT2007) will constitute overtime hours. These hours should be added to the overtime wage type for processing in payroll. Also, the overtime work done between 9 pm – 6 am will be at R2 rate (Higher Rate) and the overtime work done between 6 am – 9 pm will be at R1 rate. Any overtime done on OFF day or Public Holiday will be at R2 rate.

Let us assume that the planned shift times are from 9:00 to 18:00. There is overtime approval from 18:00 to 20:00 from IT2007. The employee clocks in at 11:00 and clocks out at 21:00. In this case, client would like to report this as late in (since employee is 2 hours late to office) and would deduct the salary accordingly. The two hours overtime work done from 18:00 to 20:00 will be paid out at overtime rate R1 as approved overtime and the remaining one hour of overtime from 20:00 to 21:00 will be considered as unapproved overtime and will not be paid out. There won’t be any check to see if the employee has completed his planned working hours of 9 hours before overtime hours get counted.

Solution Design

Before I go to the solution design for the client, let me give you a brief idea about the standard solution provided by SAP.

Calculation of overtime as per standard Pre-approved Overtime functionality involves the below lines of code in standard time schema TM00.

The approval is stored in quota 01 and 02.

Function GOT is responsible for comparing the work done outside planned working hours with the approval from IT2007. If there is an overlap or match, the time pairs are made available for processing in PCR TO20 which further gets processed in PCR TO21.

The function compares the time pairs outside planned working hours in Table TIP with the overtime approvals of the current day/ next day from infotype 2007. The approved times are made available for processing in the PCRs TO20 and TO21 where the time pairs are flagged as overtime pairs.

PCR TO20 and PCR TO21 are responsible for determining that the planned working hours have been completed and any hours beyond the planned working hours should be treated towards overtime if there is a corresponding overtime approval from IT2007.

In our scenario, the requirement was slightly different. Any work done outside planned working times should be treated as overtime if there is a corresponding approval from IT2007.

Also, while I was designing the solution, I realized that Pre-approved overtime functionality is not working for night shifts. Please refer the below links in SCN where I had reported this issue in detail. Unfortunately, I didn’t get any response regarding this.

http://scn.sap.com/thread/3538215

Let us say that the planned night shift timings for an employee are from 03-Jan 22:00 to 04-Jan 6:00 next day. The employee clocks in at 03-Jan 22:00 and clocks out at 04-Jan 8:00 next day. The overtime approval is from 04-Jan 6:00 to 04-Jan 8:00. In such a case, overtime doesn’t get calculated by standard SAP if your schema looks like below.

In case of night shifts, the hours clocked on next day get reported as 24 + n hours where n is the time on the next day. Hence, 6:00 and 8:00 on next day are 30:00 and 32:00 hours for the night shift. However, IT2007 didn’t have any previous day indicator to indicate that the overtime approval from 6:00 to 8:00 on 04-Jan belongs to 03-Jan shift.

If you go through the SCN message logged by me, I was harping on getting a previous day indicator assigned to IT2007. I had even raised an oss message regarding the same with SAP. I had also thought of a workaround as a temporary stop gap arrangement but it wasn’t a great workaround. It was really stupid of me to think that SAP wouldn’t have taken care of this basic requirement while designing the solution.

I decided to do more research on this and finally, I was able to nail it. We should use TEX in parameter 3 for the attendance quota as shown in the screen shot below.

By using TEX with GOT, the interpretation is done slightly differently. Let me explain this to you in the below table.

I will use the above functionality to ensure that Pre-approved overtime functionality works for night shifts.

Let us first create custom version of PCRs TO20 and TO21. Below is the snapshot of the PCR ZO20. PCR ZO20 will process time pairs belonging to pair type 1 (data from IT2011) and pair type 3 (data from IT2002) to PCR ZO21. For any other pair type, the time pairs will be moved to Output Table TIP using COLOP*.

PCR ZO21 has been modified as below:

Any time pair with processing type A, K, P or S will be moved to Output Table TIP using COLOP*. Time Pairs with times outside the planned working hours will have processing type as blank. This time pair will get processed under * using operation GENOT C.

To ensure that overtime time pair has processing type blank till this point, we must keep the processing type value as blank for Pair Type 1 and Pair Type 3 for Time Id 01 in Table V_T555Z as shown below:

The PCR ZO20 is added in the custom positive time schema ZTAD as shown below. TEX will help us to calculate overtime during night shift by comparing the timings correctly as explained earlier. 23 is the attendance quota which has been configured. The lines 000670 and 000690 have been commented out as they will not be required.

Let me show you the configuration of attendance quota 23. Please ensure that we have selected the radio button – Deduction through time evaluation.

We also need to define the time types for approved and unapproved overtime related to attendance quota type 23. This is done in Table V_556P_B. All approved overtime will be record in time type 0040 and unapproved overtime will be recorded in time type 0411. Please refer the below screenshot.

Below screenshots show the configuration of Table V_T510S for overtime wage type generation. Overtime work done between 9 pm – 6 am will be at R2 rate (Higher Rate) and the overtime work done between 6 am – 9 pm will be at R1 rate. Any overtime done on OFF day or Public Holiday will be at R2 rate.

As per SAP, an employee can do overtime up to 48 hours continuously. Hence, any time N on next day in a continuous shift will be represented as 24 + N hours in SAP.

Let us understand the meaning of these fields:

• Time Wage Type Selection Rule Group – It is used to set specific regulations for time wage type selection according to an employee’s organizational assignment. Function MOD processes PCR MODT which uses operation MODIF to determine the time wage type selection rule group that the time evaluation driver should use to access the entries for an employee in Time Wage Type Selection table V_T510S. Basically, all the employees who need to be processed together as per organizational assignment for time wage type selection are grouped together. Operation MODIF is used to set groupings for table access. Operation MODIF W is used to set employee groupings for accessing the Time Wage Type Selection table. Please refer the below screenshot.

• Day Grouping – Function DAYMO is used to determine rules in Time Wage Type Selection Table V_T510S based on the day. It is used to set the day grouping for the time wage type selection from the Table V_T510S to a particular value. The value is set according to the type of day on which the table is accessed.  DAYMO must always be set before function GWT in day processing. This function must be defined in the schema so that rules get processed from Table V_T510 for wage type selection. Function DAYMO is used in conjunction with four parameters and they have the following meaning:

Func   DAYMO          Meaning

Par 1   01                Mon – Sat and not a public holiday

Par 2   02                Sun and not a public holiday

Par 3   02                Mon – Sat and public holiday

Par 4   02                Sun and public holiday

Hence, if the day is Thu and is not a public holiday, the day grouping will be 01 and this will be used as a parameter in Time Wage     Type Selection Table V_T510S for rule access. If the day is a public holiday, then the day grouping will be 02 for all the days.      Please refer the below screenshot.

• Sequential No. – It is used to differentiate between wage type rules with the same time wage type selection rule group and day grouping.

• Wage Type – This field specifies the wage type which will get generated for the particular rule in Table V_T510S if all the conditions are met.

• Start – This field specifies the start date of the time wage type selection rule.

• End – This field specifies the end date of the time wage type selection rule.

• Valid Processing Types – The processing type is formed during the time evaluation run and is particularly significant for the selection of time wage types. Wage types created from time pairs are processed by the payroll driver according to the processing type. The view Time Wage Type Selection Rule (V_T510S) is used to determine the processing type for time pairs so that the appropriate wage type is chosen.

• Weekdays – This denotes the weekday for which the given time wage type selection rule is valid. The numbers 1 – 7 stand for the days of the week: 1 Monday, 2 Tuesday, etc. If you want to allow the wage type to be generated for certain days of the week, put an ‘X’ under the appropriate numbers.

• PH Pre Day – This governs the admissibility condition for public holiday class for previous day. If you want to allow the wage type in question to be generated for certain public holiday classes on the previous day, put an ‘X’ under the appropriate public holiday classes.

• PH Cur Day – This governs the admissibility condition for public holiday class for current day. If you want to allow the wage type in question to be generated for certain public holiday classes on the current day, put an ‘X’ under the appropriate public holiday classes.

• PH Sub Day – This governs the admissibility condition for public holiday class for subsequent day. By putting an ‘X’ under the appropriate public holiday classes, you can determine which public holiday classes of the following day, generation of the appropriate wage type should be allowed for.

• Val. Class – This refers to the valuation class of the period work schedule. A valuation class from 0 to 9 is assigned to each period work schedule. If you want generation of the wage type in question to be permitted for period work schedules with these valuation classes, you can specify this by putting ‘X’ under the relevant valuation classes of the period work schedule. This refers to the value against PWS in table V_551C_B.

• DWS Class – This governs the permissibility condition for daily work schedule class. A daily work schedule class from 0 to 9 is assigned to each daily work schedule. Daily work schedule class 0 is used to denote a day off; the other values have no fixed meaning. If you want to allow the specified wage type to be generated for daily work schedules of a certain class, enter an ‘X’ under the relevant class.

• Day Type – This governs the admissibility condition for day types. In the monthly work schedule, each day is assigned a day type. Day type 0 means a workday; day type 1 means a day off/paid, none of the other specifications has a specific meaning. If you want to allow the wage type in question to be generated for specific day types of the monthly work schedule day, put an ‘X’ under the appropriate day types.

• Start Time – This indicates the start time of the interval for which wage type generation is permitted. If only part of a time pair lies within this interval, the wage type is only generated for the permitted part of the time pair. In other words, the time pair is split. Valid entries are 0:00 – 47:59 where 47:59 is 23:59 on the following day (for working days which span two calendar days).  If there is a day with pairs which do not specify clock times, the wage types for which the time interval is entered are not generated on that particular day.

• End Time – This indicates the end of the time interval for which wage type generation is allowed. If only part of the time pair is within this interval, the wage type is generated for the allowed part of the time pair only (time pair splitting). Valid entries are 0:00 – 47:59 where 47:59 is 23:59 on the following day (for working days which span two calendar days).  If there is a day with pairs which do not specify clock times, the wage types for which the time interval is entered are not generated on that particular day.

• Minimum Hours – By entering a number of hours (X) in this field, you can specify that the relevant wage type should only be generated if a particular processing type already contains X hours on the same day.

• Symbolic Specification of Minimum Hours – Like the field “Number of Hours: Minimum”, this field enables you to specify the minimum number of working hours allowed on the previous day so that a wage type is generated from a time pair. The difference is that a symbol is used to state the condition instead of hours and minutes. Current possible entries are the following:

• • • S – Planned working hours of the day according to the personal work schedule
    • T – Planned working hours of the day if employment percentage = 100% according to personal work schedule
    • U – Average working hours per day according to the work schedule rule

• Maximum Hours – By entering a certain number of hours in this field, you can specify that the wage type in question is only generated for the first X hours of a particular processing type each day.

• Symbolic Specification of Maximum Hours – Like the field “Number of Hours: Maximum”, this field enables you to specify the maximum number of working hours allowed on the previous day so that a wage type can be generated from a time pair. The difference is that a symbol is used to state the condition instead of hours and minutes. Current possible entries are the following:

• • • S – Planned working hours of the day according to the personal work schedule
    • T – Planned working hours of the day if employment percentage = 100% according to personal work schedule
    • U – Average working hours per day according to the work schedule rule

• Relevant Proc Types – This is where you specify which processing types are to be taken into account in the requirement of a maximum or minimum number of hours, in other words, which time pairs are to be counted for these hours. If you do not specify any processing types here, the system uses the processing type specified in the parameter 2 when function GWT is called up.

• Interval – With regard to the condition concerning a minimum or maximum number of hours, this enables you to determine whether time pairs are only taken into account if they are within the defined time interval. Below is the example:

• • • An employee’s time pair is from 14.00 to 24.00; the last two hours are overtime
    • Time interval for nightwork: 20.00 to 30.00 (06.00 on the following day)
    • Pertinent processing types: planned work and overtime
    • Number of hours: min. 2
      a) Count in interval only: X
      Effect: The wage type is generated from 22.00 to 24.00 because hours are taken into account as of 20.00. The condition regarding two minimum working hours must be met as of 20.00. It does not matter whether the two working hours are performed as planned work or overtime.
      b) Count in interval only: BLANK
      Effect: The wage type is generated from 20.00 to 24.00 because hours are counted as of 20.00. The condition regarding two minimum working hours is met because the employee’s time pair is from 14.00 to 24.00. In this example, the minimum hours can also be prior to the specified time interval. Once again, it does not matter whether the two hours are performed as planned work or overtime.

• Fixed Value – In this field, you can specify how many hours (number) should be valuated with this wage type if an employee’s time pair meets all other conditions, but overlaps with the “Time from…to” field. Below is an example:

• • • The employee’s time pair on Saturday is from 9:00 to 9:20.
    • The conditions for wage type generation correspond to Saturday work.
    • Time from 8:00 to 21:00
    • Fixed value for number 2
      Consequence: The wage type is generated for two hours, without taking account of the actual duration of the time pair worked. If an employee’s overtime exceeds the fixed value, a subsequent rule must be defined in which the fixed value is configured as minimum hours.

• Exit rule – Time wage type selection checks all stored rules for all TIP entries and selects the appropriate wage type if the conditions are met. By activating this field, you cause the system to leave processing of the current rule as soon as the wage type for a TIP entry is selected. The next rule continues time wage type selection.

• Stop Time Wage Type Selection – Time wage type selection checks all stored rules for all TIP entries and selects the appropriate wage type if the conditions are met. By activating this field, you specify that the system stops time wage type selection as soon as the wage type for a TIP entry is selected. The rules which follow are then no longer taken into consideration during time wage type selection.

We need to ensure that the planned working hours are same as maximum working hours in all the DWS of the given WSRs. This is required so that the overtime gets calculated correctly for the date if public holiday falls on a working day and the employee is eligible for the public holiday.

SAP creates one time pair with Time Id 02, Processing Type A and planned working hours and another time pair with Time Id 01 and Processing Type P with actual time worked in Table TIP for public holiday if the employee is working on public holiday that falls on working day and employee is eligible for this public holiday.

Function DEFTP refers first maximum working hours in Table TIP to check if that has been fulfilled or not. If maximum working hours are not present, then it refers to constant TGMAX in Table V_T511K. However, maximum working hours each day may vary and hence, we should maintain this value in DWS.

Function DEFTP will convert the processing type from A or P to S for time pairs till the maximum working hours. In the above case, the first line item in Table TIP will be with Time Id 02 and Processing Type A. The processing type A will be converted into S and since the maximum daily working hours have been met, it will remove the processing type P from time pair with Time Id 01. The time pair with Time Id 01 will get processed in by function GOT and will be assigned processing type M.

Let us assume that the maximum daily working hours were not maintained in DWS and constant TGMAX in Table V_T511K was set at 12 hours. Daily planned working hours on Public Holiday was 8 hours. Employee also worked overtime for 8 hours on this day. In this case, DEFTP will convert processing type of time pair with Time Id 02 from A to S (hours = 8). However, the maximum daily working hours is now determined by constant TGMAX (value = 12) and it is not met yet. Hence, DEFTP will split the second time pair with Time Id 01 and Processing Type P into time pairs – one time pair with Time Id 01, Processing Type S and 4 hours and another time pair with Time Id 01, Processing Type blank and 4 hours. The time pair with Time Id 01 and blank Processing Type will get processed in function GOT and will result in only 4 hours of overtime which is incorrect.

Below screenshots show the configuration done for daily maximum working time for the DWS to be used in our testing. The table is V_T550A.

<pstyle=”margin-right: 11.25pt;=”” text-align:=”” justify;”=””>

Let us now move to solution testing.

Solution Testing

Please refer below the screenshots related to key infotypes before we do the testing.

IT0000

IT0001

IT0007

Work Schedule

Please refer the below table based on which we will maintain overtime approvals in IT2007 and record Clock In/Out data in IT2011 and finally arrive at the approved overtime.

Shift Date	DWS	Shift Timings	OT Approval	Clock In/Out Data	Approved Overtime
01-Aug-13	N001	22:00 – 06:00	07:00 – 08:00 on 02-Aug-13	P10: 22:10:00; 01-Aug-13 P20: 09:00:00; 02-Aug-13	1 hr of R1
04-Aug-13	OFF	OFF	09:00 – 15:00 on 04-Aug-13	P10: 08:00:00 P20: 14:00:00 (both on 04-Aug-13)	5 hrs of R2
05-Aug-13	M001	06:00 – 14:00	18:00 – 22:00 on 05-Aug-13	P10: 06:10:00 P20: 23:00:00 (both on 05-Aug-13)	3 hrs of R1 and 1 hr of R2

IT2007

IT2011

Let us run the time evaluation till 05.08.2013 using TCode PT60.

The time evaluation runs successfully.

Let me take you through the processing log of function GOT and GWT for each date which will give a better idea about how things work.

Date: 01-Aug-13

Function GOT Processing

Function GWT Processing

02-Aug-13

Function GOT Processing

PCR ZO20 doesn’t get processed on 02-Aug-13 since there is no match between the time pairs and overtime approval timings.

04-Aug-13

Function GOT Processing

Function GWT Processing

05-Aug-13

Function GOT Processing

Function GWT Processing

Let us execute TCode PT_BAL00 to see a summarized view of the overtime wage types generated for the employee.

Here, I come to the end of this knowledge artifact.

It’s been a long document and hence, thanks for your patience to go through it. I got to learn a new functionality in time because of this requirement and I hope this has been beneficial for you too.

</pstyle=”margin-right:>