Client Situation
Our client requirement was to implement SAP HR Positive Time Management solution to record and evaluate the actual times of their blue collar workers. The client was installing time recording terminals which were not SAP CC1 certified. Only Clock In (Time Event Type P10) and Clock Out (Time Event Type P20) were required to be recorded.
The factory/plant had four production shops. Each production shop had two time recording terminals mounted on the wall - one for clock in and another for clock out. These time recording terminals didn't have any unique way to specify whether a time punched at time recording terminal is "clock in" or "clock out". Hence, there was a board mounted with the sign "Clock In" above "Clock In Time Recording Terminal" and with the sign "Clock Out" above "Clock Out Time Recording Terminal". Some employees had access to all production shops and some had access to few of them only. An employee could work in multiple production shops in the same shift. Each time an employee entered into a production shop, it was expected that he clocked in at the "Clock In Time Recording Terminal" while entering into the production shop and clocked out at the "Clock Out Time Recording Terminal" while leaving the production shop.
There were no turnstiles at the entrance of production shops and hence, there was a high chance that employees may forget to clock in or clock out while entering or leaving the production shops. Hence, we could have scenarios where an employee has a clock in data once and clock out data multiple times for the same shift.
For evaluation purposes, client wanted us to consider the first clock in and the last clock out since it was difficult to enforce employees to clock in while entering and clock out while leaving the production shop in absence of a turnstile. If the first clock in was missing, then it should be reported as a missing clock in. Also, if the last clock out was missing, then it should be reported as a missing clock out.
The time recording system would send a .txt file with all the time events (P10 & P20) data recorded for a shift for all employees in that shift in a predefined format to SAP R/3. These time events would be uploaded in IT2011 (Table TEVEN).
Hence, if the time events were recorded as shown in the table below, the first clock in will be blank and the last clock out will be 18:00:00.
Date | P10 | P20 |
03-Jan-2012 | - | 14:00:00 |
03-Jan-2012 | 14:15:00 | 18:00:00 |
There was no requirement to record break times and employees could clock in/clock out multiples times for the same shift. The break time would be considered from the daily work schedule.
Failed Solution Approach
For quite some time, this requirement was giving me sleepless nights. There were various approaches which I was trying out but none of them gave the desired results.
One such approach tried by me was to use operation VARST to read the first time pair (VARSTFIRST) and then use operation HRS=PBEG to capture the no. of hours and enter it into a time type.
Then use operation VARST to read the last time pair (VARSTLAST) and use operation HRS=PEND to capture the no. of hours and enter it into another time type.
Using the time types, I would modify the start time and end time using operation FILLP for the first time pair and ignore the remaining time pairs.
On the face of it, this solution looked good. However, it had inherent shortcomings.
Please refer the below screenshot for time events in IT2011 to understand the shortcomings. The employee recorded a clock in at 08:00:00 and then clock outs at 10:30:00, 14:00:00 and 18:00:00 on 03-Jan-12.
When the time evaluation is run, the time pairs formed get sorted as shown in the screenshot below:
SAP has sorted all the time pairs first by “From” and then by “To” in Table TIP. Hence, the PBEG of first time pair comes out to be blank and the PEND of the last time pair comes out to be 10.5000. However, the real time scenario demands that the first clock in should be 08.0000 and the last clock out should be 18.0000. Hence, this solution approach failed.
Solution Logic
I realized that I was not having clarity of thought on the logic to develop this solution and hence, the various attempts resulted in failure. Finally, I thought to myself that if I have to give this requirement to an ABAPer, what would be the requirement I would give to develop a program to find the first clock in and last clock out. Also, if the first clock in or last clock out was missing, the system would report that.
After some thinking, I came up with the below logic for ABAPer for determining the first clock in and last clock out:
Let us now test this logic to the time events in our failed solution approach. Below table shows the time pairs formed in Table TIP from function P2011.
Earliest Recorded Clock In = 08.0000
Latest Recorded Clock In = 08.0000
Earliest Recorded Clock Out = 10.5000
Latest Recorded Clock Out = 18.0000
We see that the “earliest recorded clock in” (08.0000) is less than the “earliest recorded clock out” (10.5000) and hence, the “earliest recorded clock in” is the first clock in of the shift. This is correct.
The “latest recorded clock out” (18.0000) is greater than the “latest recorded clock in” (08.0000) and hence, the “latest recorded clock out” is the last clock out of the shift. This is correct too.
Hence, the above solution logic proved correct and I built custom PCRs and time types to fulfill the requirement based on this logic.
Solution Design
There are two key tables which we would need to maintain to build this solution.
Table TPT_PAIRSTAT2 determines how time pairs are formed in Table TIP.
Below is a partial screenshot of the Pair Formation Status Table.
From State: At any time, an employee has a state. This is the state in which the employee is in before the time event happens.
Time Event Type: The field shows the time event recorded when the employee is in a given state. It will change the state of the employee from “From state” to “To State”.
Unique Time Event Type: Time Event Type P01 can be used to record both clock in/clock out. If the “From state” of employee is absent before clock in and the “Time Event Type” is P01, then it means that the employee has clocked in. In such a case, the value of “Unique time event type” will be P10. This interpretation is defined in this field. Where no unique interpretation is required, the value of time event type is same as unique time event type. As shown in the screenshot above, the value of both time event type and unique time event type are P10 for “From state” – Absent before Clock In because no unique interpretation is needed.
To State: This is the state at which employee reaches from “From State” once the time event type is recorded.
Continue: This field is used for interim postings. Let us say that there is an interim posting between clock out and clock in and we would like to have two complete pairs – one from clock out to interim posting and another from interim posting to clock in. The first two events form the first time pair and the third event ends the new time pair taking the end event of previous time pair as the start event of the new time pair.
Closed: Time pairs are formed by a starting time event and an ending time event. However, if a time event is missing, then the pair won’t get formed or if there are multiple time events, incorrect time pairs may be formed. To avoid any errors, this check box should be checked for scenarios where the time event type is the ending time event and there is a missing starting time event type. This implies that the time event should create a new closed time pair only with “To” time and the “From” time will be blank. An example of this scenario is where clock in is missing and clock out is recorded.
Close: This field is meant to close an open time pair if it exists. If the employee is at work and a time event is recorded and this field is checked, then the pair should be closed. Fields Close and Closed are mutually exclusive. Both of them can’t be maintained at the same time for the same states and time event type.
New: This field means that a new time pair should be started.
Customer Adjustment: This field is used to specify PDC Processing Status and its reaction maintained in Table V_T705B.
Error: If the pair formation is not error free, it gives an error message in time evaluation run corresponding to the error message number maintained here.
Pair Formation Status: This field gives the status of the time pair formed – whether it is error free or not or clock in is missing or clock out is missing etc.
Let us now understand the PDC Processing Statuses Table V_T705B.
This table specifies the actions to be taken in situations where time pairs can’t be formed because the time events data don’t make sense.
PSGrp: This is Grouping of Personnel Subareas for Time Recording for which the same time types, time transfer specifications, access control groups, and message types are defined.
PDC Processing Status: This field displays the PDC Processing Status which defines the behavior to be taken into account during time pair formation.
Processing Status Text: This field displays the description of the PDC Processing Status.
Start Date: This field displays the start date from which the PDC Processing Status is valid.
End Date: This field displays the end date till which the PDC Processing Status is valid.
Reaction: The return code in field reaction will specify the reactions to be taken for PDC Processing Status.
Let us now study the values relevant for our scenarios from Pair Formation Status Table and the relevant values (C02 & C11) from PDC Processing Statuses Table.
TPT_PAIRSTAT2 Screenshot A – This shows the values in the table relevant for our scenarios.
V_T705B Screenshot B – The highlighted rows in the table show the values relevant for our scenarios.
Let us refer to the 2nd and 6th rows in Table TPT_PAIRSTAT2 Screenshot A. In both cases, employee was not at work and there was a clock out recorded. The system has to create a time pair with the clock out time event because the field “Closed” is checked. The “Customer adjustment” field has PDC Processing Status as C02 and the error message 21 (Clock in Missing) will get generated. The reaction field in Table V_T705B Screenshot B for PDC Processing Status C02 should be left blank to allow open time pair creation with only clock out time in Table TIP from function P2011. The time pair will have “From” field blank and “To” field with clock out time.
The other possible reaction value for PDC Processing Status C02 is 1. If 1 is maintained, then it doesn’t allow even creation of open time pair with just clock out data.
Below are the examples of system behavior with reaction as blank and as 1 for PDC Processing Status C02.
PDC Processing Status Scenario 1: Reaction indicator is blank for PDC Processing Status C02.
V_T705B
IT2011
P2011 – Open Pair Type gets created with clock out data and clock in is missing.
Time Evaluation Result – The time evaluation fails with error that clock in is missing.
PDC Processing Status Scenario 2: Reaction indicator is 1 for PDC Processing Status C02.
V_T705B
IT2011
Time Evaluation Result – The time evaluation fails at PCR TD20 which points out that time pair is not error free and has clock in missing. It doesn’t allow the system to reach function P2011 which creates open time pair with clock out time. Hence, this option is ruled out.
Let us refer to the 3rd row in Table TPT_PAIRSTAT2 Screenshot A. The employee was at work and a clock in was recorded. The field “Close” is checked and hence, it will close the open pair. Also, the field “New” is checked and hence, it will start the creation of a new time pair. The PDC Processing Status in field “Customer Adjustment” is C11. The reaction indicator for PDC Processing Status C11 is 1. If the reaction is 1, the system will end ongoing time pair with the current clock in time and also start a new time pair with the same clock in time. If the reaction for PDC Processing Status is blank, the system will give an error that clock in is missing.
PDC Processing Status Scenario 3: Reaction indicator is 1 for PDC Processing Status C11.
V_T705B
IT2011 – Employee is at work (Clock In 08:00:00) and clocks in again (14:00:00). It means that there is a missing clock out between two clock ins.
P2011 – There wasn’t any clock out at 14.0000. However, the system closes the existing open pair with the clock in time and starts a new time pair with the same clock in time. This is due to PDC Processing Status C11 and its return code as 1.
Time Evaluation Result – The time evaluation run is successful.
PDC Processing Status Scenario 4: Reaction indicator is blank for PDC Processing Status C11.
V_T705B
IT2011 – Employee is at work (Clock In 08:00:00) and clocks in again (14:00:00). It means that there is a missing clock out between two clock ins.
Time Evaluation Result – The time evaluation fails at PCR TD20 and generates error during pair formation. It doesn’t allow system to reach function P2011 for processing. Hence, this option is ruled out.
After maintaining Pair Formation Status Table - TPT_PAIRSTAT2 and PDC Processing Statuses Table - V_T705B, the next step is to create time types. Below are the daily time types which are needed.
Go to TCode SM30 > Table V_T555A.
ZVB1 – Earliest Recorded Clock In
ZVB2 – Latest Recorded Clock In
ZVB3 – Earliest Recorded Clock Out
ZVB4 – Latest Recorded Clock Out
ZVB5 – First Clock In
ZVB6 – Last Clock Out
After creating the six daily time types, I created five PCRs as mentioned below:
Let us now go inside each PCR to understand its functionality.
PCR ZVB4 – The objective of PCR ZVB4 is to find the “earliest recorded clock in” and “latest recorded clock in” in a shift and feed the values in daily time types ZVB1 (earliest recorded clock in) and ZVB2 (latest recorded clock in).
If no clock in has been recorded, then the daily time types ZVB1 and ZVB2 won’t get generated. If only one clock in has been recorded, then both ZVB1 and ZVB2 will have the same value.
Below is a screenshot of PCR ZVB4.
Let us see how time pairs in TIP table get processed through PCR ZVB4.
PCR ZVB5 – The objective of PCR ZVB5 is to find the “earliest recorded clock out” and “latest recorded clock out” in a shift and feed the values into daily time types ZVB3 (earliest recorded clock out) and ZVB4 (latest recorded clock out).
If no clock out has been recorded, then the daily time types ZVB3 and ZVB4 won’t get generated. If only one clock out has been recorded, then both ZVB3 and ZVB4 will have the same value.
Below is a screenshot of PCR ZVB5.
Let us see how time pairs in TIP table get processed through PCR ZVB5.
PCR ZVB6 – The objective of PCR ZVB6 is to find the “first clock in” by comparing “earliest clock in” time type ZVB1 with “earliest clock out” time type ZVB3. If the value of ZVB1 is less than ZVB3, then ZVB1 is the “first clock in” and its value should be fed in time type ZVB5 – First Clock In.
If the value of ZVB1 is more than ZVB3, then there is a “missing clock in”. The “missing clock in” is the “first clock in” and hence, the value of ZVB5 will be 0.0000.
If ZVB1 was not created due to “missing clock in”, then the value of ZVB5 will be 0.0000 implying that there is a “missing clock in”.
Below is a screenshot of PCR ZVB6.
PCR ZVB7 – The objective of PCR ZVB7 is to find the “last clock out” by comparing “latest clock out” time type ZVB4 with “latest clock in” time type ZVB2. If the value of ZVB4 is greater than ZVB2, then ZVB4 is the “last clock out” and its value should be fed in time type ZVB6 – Last Clock Out.
If the value of ZVB4 is less than ZVB2, then there is a “missing clock out”. The “missing clock out” is the “last clock out” and hence, the value of ZVB6 will be 0.0000.
If ZVB4 was not created due to “missing clock out”, then the value of ZVB6 will be 0.0000 implying that there is a “missing clock out”.
Below is a screenshot of PCR ZVB7.
By now, we have identified the “first clock in” and “last clock out” of a shift. We also have the solution logic in place to identify if the “first clock in” or “last clock out” of any shift is missing or not.
PCR ZVB9 - The next step is to create a time pair using the “first clock in” and “last clock out” that we have determined and process only this time pair for further evaluation. Any other time pair if present gets eliminated from further processing.
Below is the screenshot of PCR ZVB9.
The PCR ZVB9 uses VARSTFIRST to read the first time pair. If it is the first time pair, it gets processed under Y. Any other time pair gets stopped at N and doesn’t move to output table. In this way, we are ensuring that only one time pair will move to output table for further processing.
The first time pair will be modified with the “first clock in” and “last clock out” data and will be moved to output for further processing.
Below are the four possible scenarios that may happen.
Scenario 1: Both “First Clock In” (ZVB5) and “Last Clock Out” (ZVB6) have value as 0.0000 – The first time pair moves for processing under Y. The value of “first clock in” time type ZVB5 (0.0000) is read using HRS=DZVB5 and then compared with 0 using HRS?0. Since the result is not greater than 0, the processing happens under *. Below things happen for the first time pair:
Then the value of the “last clock out” time type ZVB6 (0.0000) is read using HRS=DZVB6 and then compared with 0 using HRS?0. Since the result is not greater than 0, the processing happens under *. Below things happen for the first time pair:
Scenario 2: “First Clock In” (ZVB5) and “Last Clock Out” (ZVB6) have value as 0.0000 and 18.0000 respectively – The first time pair moves for processing under Y. The value of “first clock in” time type ZVB5 (0.0000) is read using HRS=DZVB5 and then compared with 0 using HRS?0. Since the result is not greater than 0, the processing happens under *. Below things happen for the first time pair:
Then the value of the “last clock out” time type ZVB6 (18.0000) is read using HRS=DZVB6 and then compared with 0 using HRS?0. Since the result is greater than 0, the processing happens under >. Below things happen for the first time pair:
Scenario 3: “First Clock In” (ZVB5) and “Last Clock Out” (ZVB6) have value as 08.0000 and 0.0000 respectively – The first time pair moves for processing under Y. The value of “first clock in” time type ZVB5 (08.0000) is read using HRS=DZVB5 and then compared with 0 using HRS?0. Since the result is greater than 0, the processing happens under >. Below things happen for the first time pair:
Then the value of the “last clock out” time type ZVB6 (0.0000) is read using HRS=DZVB6 and then compared with 0 using HRS?0. Since the result is not greater than 0, the processing happens under *. Below things happen for the first time pair:
Scenario 4: “First Clock In” (ZVB5) and “Last Clock Out” (ZVB6) have value as 08.0000 and 18.0000 – The first time pair moves for processing under Y. The value of “first clock in” time type ZVB5 (08.0000) is read using HRS=DZVB5 and then compared with 0 using HRS?0. Since the result is greater than 0, the processing happens under >. Below things happen for the first time pair:
Then the value of the “last clock out” time type ZVB6 (18.0000) is read using HRS=DZVB6 and then compared with 0 using HRS?0. Since the result is greater than 0, the processing happens under >. Below things happen for the first time pair:
The next step is to include these PCRs ZVB4, ZVB5, ZVB6, ZVB7 and ZVB9 in positive time management schema.
A custom schema ZTCN is created by copying from standard time schema TM00 – Time Evaluation with Personnel Time Events.
Below is a screenshot of the custom time schema ZTCN.
The PCRs ZVB4, ZVB5, ZVB6, ZVB7 and ZVB9 are included in time schema ZTCN as per the sequence shown in the above screenshot.
PCRs ZVB4, ZVB5 and ZVB9 are being processed by function PTIP because TIP table is being processed in these PCRs. Par 2 is GEN because it is called for all time types.
PCRs ZVB6 and ZVB7 are being processed by function ACTIO because TIP table is not being processed in these PCRs.
I have included function PRINT after PCRs ZVB4 and ZVB5 to print table TES to display the value of time types ZVB1, ZVB2, ZVB3 and ZVB4 which get generated in these PCRs.
In the same way, I have included function PRINT after PCRs ZVB6 and ZVB7 to print table TES to display the value of time types ZVB5 and ZVB6 which get generated in these PCRs.
I tested around 22 different scenarios for this solution and all the scenarios passed with the desired result.
Please refer the below screenshots for the results.
I will now pick up some scenarios from the 22 scenarios that I tested and show how the time events got processed in system.
Testing Scenario 1:
IT2011
P2011
Table TES
Final Pair Formed
Time Evaluation Result – It fails since last clock out is missing.
Testing Scenario 2:
IT2011
P2011
Table TES
Final Pair Formed
Time Evaluation Result – It fails since first clock in is missing.
Testing Scenario 3:
IT2011
P2011
Table TES
Final Pair Formation
Time Evaluation Result – It fails since last clock out is missing
Testing Scenario 4:
IT2011
P2011
Table TES
Final Pair Formation
Time Evaluation Result – It is successful.
Here I come to the end of this knowledge artifact. Thank you for your patience for going through this document. I hope this knowledge artifact has been beneficial for you.
Warm regards,
Vivek Barnwal
**************************************************************************************************
You can also refer to other knowledge artifacts created by me at the below link:
One Stop Shop of my Knowledge Artifacts in SAP HCM
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
6 | |
2 | |
2 | |
2 | |
2 | |
2 | |
2 | |
1 | |
1 | |
1 |