SCN-SAP.com: March 2015

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.

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.

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.

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.

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.

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

The PCR ZAR2 will be modified as shown below:

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.

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.

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

V_T551A

V_T508A

Generation of Work Schedules

V_T551C

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

V_T555A

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

V_T511K

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.

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.

The rounding rule 92 is defined as shown below:

V_T559R

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

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: