Date Dependent PCR Processing in Time Evaluation

Introduction

One of the things that fascinated me when I started working in time management was Date Dependent PCR Processing in Time Evaluation.

Over a period of time, I realized that there are two possible ways (there may be more ways also) to achieve date dependent PCR processing in time evaluation. In this knowledge artifact, I will explain both the methods and the scenarios in which these methods can be used.  

Method 1: Based on Payroll Parameter Constant

Let us refer to the PCR ZAR1 shown in the below screenshot. When this PCR gets processed in time evaluation, it sets a value of 0.5 hours using operation HRS=0.5 and then adds 0.5 hours to daily time type ZAR1 using operation ADDDBZAR1.

1.JPG
Let us assume that this PCR has been getting processed in time evaluation ever since time evaluation go live (let’s say year 2012). Now, your client comes up with a requirement that effective 01-Jan-14, the no. of hours to be added to time type ZAR1 should be increased from 0.5 to 1.

We can’t change HRS=0.5 to HRS=1.0 directly because if there is a retro time evaluation before 01-Jan-14, the time type value will get changed from 0.5 to 1.0 for dates prior to 01-Jan-14. This will be incorrect.

To bring in the date dependent functionality, we will create a custom constant in Table V_T511K. Let us create a custom constant ZCONS in Table V_T511K as shown below.

2.jpg

We will keep the value of the constant as 0.00 from 01.01.1900 till 31.12.2013 and 1.00 from 01.01.2014 till 31.12.9999.

Let us now modify our PCR ZAR1 as shown below.

3.jpg
When this PCR gets processed now, it sets the value of the constant ZCONS from Table V_T511K in operation HRS based on the date for which time evaluation is happening.

Let us say that the time evaluation run is happening for 31-Dec-13. The value of constant ZCONS is 0.0 on 31-Dec-13. The hours in operation HRS (0.0) is compared with 0 using HRS?0. Since the comparison value is equal to 0, the PCR gets processed under = and the no. of hours are again set to 0.5 using HRS=0.5. Then these hours (0.5) are added to time type ZAR1.

When the time evaluation run is happening for 01-Jan-14, the value of constant is 1.0 on 31-Dec-13. The hours in operation HRS (1.0) is compared with 0 using HRS?0. Since the comparison value is not equal to 0, the PCR gets processed under * and the no. of hours are set to 1.0 using HRS=1.0. Then these hours (1.0) are added to time type ZAR1.

Let us assume that the client comes back saying that from 01-Feb-2014, they would like to add 1.5 hours to time type ZAR1. We can again modify the constant and PCR as shown below to achieve this requirement.

4.jpg
8.jpg

This method of date dependent PCR processing is recommended in the below scenarios:

  • The changes impact a group of employees and not just one employee.
  • Using one constant, you can build a no. of validations for time dependent processing.

Let us move now to the second method of date dependent PCR processing.


Method 2: Based on Date Specification

Let us refer to the PCR ZAR2 shown in the below screenshot. When this PCR gets processed in time evaluation, it sets a value of 0.5 hours using operation HRS=0.5 and then adds 0.5 hours to daily time type ZAR2 using operation ADDDBZAR2.

5.jpg

Let us assume that this PCR has been getting processed in time evaluation ever since time evaluation go live (let’s say year 2012). Now, your client comes up with a requirement that effective 01-Jan-14, the no. of hours to be added to time type ZAR1 should be increased from 0.5 to 1 because the employee is completing his TE anniversary.

To bring in the date dependent functionality, we will use a date type in date specification infotype as shown below:

6.jpg

The PCR ZAR2 will be modified as shown below:

7.jpg

The operation HRS=YDAAD5 refers to date specification and finds the difference between date of time evaluation and date mentioned in date type D5. On 31-Dec-13, the difference will be less than 0 and hence, the PCR will get processed under <. The no. of hours are set to 0.5 using HRS=0.5. Then these hours (0.5) are added to time type ZAR2.

On 01-Jan-14, the difference will be equal to 0 and hence, the PCR will get processed under *. The no. of hours are set to 1.0 using HRS=1.0. Then these hours (1.0) are added to time type ZAR2.

By now, you would have guessed that this method of date dependent PCR processing in time evaluation is employee specific. Also, you can build only one check using one date type. If you want a different processing from 01-Feb-2014 in the same PCR ZAR2, you will require another date type in this method.

Below is a comparison of the two methods of date dependent PCR processing in time evaluation:

Comparison: Date Dependent PCR Processing in Time Evaluation
Constant Method
Date Type Method
Recommended for a group of employees.
Recommended for employee specific processing.
One constant can be used for multiple date checks in PCR processing.
One date type can be used for only one date check in PCR processing.

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

Thank you for your patience to go through this document. I hope this has been beneficial for you.

Calculation of Holiday Overtime during Planned Working Time

Introduction

Overtime is defined as work done outside the planned working hours. What if your client gives you a requirement where any work done in the last 2 planned working hours will be treated as Overtime during the Ramadan Period? This is contrary to the basic definition of overtime and is called Ramadan Overtime.




Client Situation

Client was implementing positive time management. Any work done in the plant in the last 2 planned working hours will be treated as Ramadan Overtime. 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. Ramadan overtime is not applicable for OFF days (planned working hours = 0) or on public holidays if the employee is eligible for public holiday.

Let us assume that the employee is on shift WSR with morning shift from 06:00 – 14:00, afternoon shift from 14:00 – 22:00 and night shift from 22:00 – 06:00 and is also eligible for public holiday. Hence, if the employee works at plant between 12:00 – 14:00 in morning shift, he will be paid Ramadan Overtime at R1 rate. If he works at plant between 20:00 – 22:00 in afternoon shift, he will be paid Ramadan Overtime at R1 rate for work done between 20:00 – 21:00 and at R2 rate for work done between 21:00 – 22:00. If he works at plant between 04:00 – 06:00 in night shift, he will be paid Ramadan Overtime at R2 rate. This also implies that only data from IT2011 will be used towards Ramadan Overtime. Any attendance captured in IT2002 during the last 2 planned working hours will not contribute towards Ramadan Overtime.

Also, the overtime hours would need to be rounded off as per the below logic:

  • 0 min till < 15 min to be rounded off to 0 min
  • 15 min till < 45 min to be rounded off to 30 min
  • 45 min till 60 min to be rounded off to 60 min




Solution Design

Before going through the solution design, let me give you a pictorial depiction of what will constitute Ramadan Overtime with regards to afternoon shift. The afternoon shift is from 14:00 – 22:00.

1.jpg
 
The above diagram depicts period for R1 and R2 rate Ramadan Overtime during an afternoon shift of 14:00 – 22:00. The orange color lines represent various continuous time pairs. For time pairs which are overlapping across R1 and R2 rates timings, we would need to write a PCR to split the timings to arrive at Ramadan Overtime Hours with R1 and R2 rates.

We will need to create a WSR for Ramadan Overtime and ensure that this WSR is maintained in IT0007 for the Ramadan Period. Below are the configuration done for Ramadan WSR.


V_T550A

2.jpg


V_T551A

3.jpg


V_T508A

4.jpg


Generation of Work Schedules

5.jpg


6.jpg


V_T551C

7.jpg


We will require the below daily time types for storing Ramadan Overtime hours R1 and R2.

V_T555A

8.jpg


  9.jpg


10.jpg

We will create 2 constants in Table V_T511K to define the timings where R1 changes into R2 and vice versa.

V_T511K

11.jpg

In the above table, we have maintained the value of ZAR12 as 21.00 because overtime rate changes from R1 to R2 at 21:00 hours in afternoon shift. For night shift, we have maintained the value of ZNR12 as 30.00 because overtime rate changes from R2 to R1 at 30:00 hours in night shift. In SAP, 6:00 hours on current date is 30:00 hours for previous day shift.

Below is the PCR which has been written to read overtime work done during the last 2 planned workings hours of the shift. This is a very big PCR and hence, I will give you an overview of its design.

12.jpg
13.jpg
17.jpg
18.jpg
19.jpg
20.jpg
21.jpg
22.jpg
23.jpg


We are basically trying to check each time pair in the last 2 planned working hours of the shift to see if it falls in the R1 or R2 time zone and accordingly, add these hours to daily time types ZRR1 or ZRR2.

We first determine the personnel subarea and process this PCR only personnel subarea 0001. Then we determine the pair type and process the PCR for pair types 1 only. Pair type 1 means that the data is coming from IT2011. Then we determine the work schedule rule and process the PCR for Ramadan Work Schedule S0001-01 only. Then we try to find out if planned working hours are greater than 0 or not. If the planned working hours are 0, we move the time pairs to output table. If the planned working hours are greater than 0, we read the shift end time and subtract 2 from it to determine the time 2 hours before shift end time. This time is stored in daily time type ZET2.

We then process time pairs belonging to Time Id 02 and 03 only and then check if the day is a public holiday or not. If the day is a public holiday, we check if the day type is blank (employee not eligible for public holiday) or not. If the day type is blank, we process it further for Ramadan Overtime and all hours will be R2 overtime hours because the day is a public holiday. If the day is not a public holiday, we determine the daily work schedule and based on each daily work schedule, we process it further to determine Ramadan Overtime.

In case of morning shift, all Ramadan Overtime hours will be R1 hours because overtime done between 6 am and 9 pm will be R1 hours. In case of afternoon shift, Ramadan Overtime hours may get split between R1 and R2. In case of night shift, Ramadan Overtime hours will be R2 hours only in the current scenario.

Each time pair is checked against the last 2 planned working hours of the day to see if it overlaps with that or not. If it overlaps with that, we also check if the timings fall within 6am – 9pm or 9pm – 6am to determine R1 or R2 overtime hours. These overtime hours are cumulated in time types ZRR1 (for R1 hours) and ZRR2 (for R2 hours).

We need to create another PCR to round off the hours cumulated in time types ZRR1 and ZRR2 and then add them to their respective overtime wage types.
 
24.jpg
25.jpg

The rounding rule 92 is defined as shown below:

V_T559R

26.jpg


The two PCRs are placed in the positive time schema ZPT1 as shown below:

27.jpg

Ensure that the PCRs are placed after function TIMTP because the function will be responsible for splitting time pairs, assignment of Time Ids and assignment of time types to time pair.

Also, ensure that the parameters for function P2001 and P2002 in the schema are blank as shown below:

28.jpg

With the solution design in place, let us proceed to testing.





Solution Testing

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

IT0001

29.jpg



IT0007 – Ramadan Period is for the month of Aug’13 and hence, Ramadan WSR is assigned for that period.

30.jpg



Work Schedule

31.jpg

32.jpg

33.jpg

34.jpg



Let us capture time events in IT2011 for the given dates and it should result in Ramadan Overtime as shown below:
35.jpg

 
IT2011

36.jpg

37.jpg


38.jpg


PT60 – Time Evaluation Run

39.jpg



Time Evaluation runs successfully.

40.jpg




TCode PT_BAL00 – Time Types ZRR1 & ZRR2

41.jpg



Report Output

42.jpg




TCode PT_BAL00 – Ramadan Overtime Wage Types

43.jpg



Report Output

44.jpg

Here, I come to the end of this knowledge artifact. I hope this document has been beneficial for you.