Determination of First Clock In & Last Clock Out in Positive Time Evaluation
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:
- Find all the recorded clock ins for a shift from the time pairs formed in Table TIP from function P2011. Please note the word “recorded” which I have used. It means that I am trying to find earliest or latest recorded times from the time events that have actually got recorded at the time recording terminals.
- Out of the recorded clock ins, find the earliest recorded clock in and latest recorded clock in.
- Find all the recorded clock outs for the shift from the time pairs formed in Table TIP from function P2011.
- Out of this recorded clock outs, find the earliest recorded clock out and latest recorded clock out.
- Then compare the earliest recorded clock in with earliest recorded clock out. If the earliest recorded clock in is less than the earliest recorded clock out, then the earliest recorded clock in is the first clock in of the shift and should be called P10. If the earliest recorded clock in is greater than the earliest recorded clock out, then there is a missing clock in. Hence, the first clock in of the shift should be blank.
- Then compare the latest recorded clock out with the latest recorded clock in. If the latest recorded clock out is greater than the latest recorded clock in, then the latest recorded clock out is the last clock out of the shift and should be called P20. If the latest recorded clock out is less than the latest recorded clock in, then there is a missing clock out. Hence, the last clock out of the shift should be blank.
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.
- TPT_PAIRSTAT2 – Pair Formation: Status Table
- V_T705B – PDC Processing Statuses
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.
- Earliest Recorded Clock In – ZVB1
- Latest Recorded Clock In – ZVB2
- Earliest Recorded Clock Out – ZVB3
- Latest Recorded Clock Out – ZVB4
- First Clock In – ZVB5
- Last Clock Out – ZVB6
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:
- ZVB4 – Find Earliest Recorded Clock In and Latest Recorded Clock In
- ZVB5 – Find Earliest Recorded Clock Out and Latest Recorded Clock Out
- ZVB6 – Determine First Clock In
- ZVB7 – Determine Last Clock Out
- ZVB9 – Form Time Pair in TIP using First Clock In & Last Clock Out
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.
- The PCR checks if start time exists in time pair or not using OUTTPEXBTM. If start time doesn’t exist (N), the time pair is moved to output table using COLOP *. If all time pairs of the shift don’t have start time, then time typesZVB1 and ZVB2 aren’t created. Hence, the values of ZVB1 and ZVB2 are 0.
- If the start time exists (Y) in time pair, the value of time type ZVB1 (Earliest Recorded Clock In) is read using HRS=DZVB1. If it is the first time pair with start time and getting processed in the rule, the value of ZVB1 will be 0. If it is not the first time pair with start time, then there will be some value in time type ZVB1.
- After reading the value of time type ZVB1, it is compared with 0 using HRS?0. If the value of ZVB1 is not greater than 0, it is processed under * and the start time of the time pair is read using HRS=PBEG. The start time is added to time types ZVB1 (earliest recorded clock in) and ZVB2 (latest recorded clock in) and the time pair is moved to output table using COLOP *.
- Let us assume that the first time pair with start time had start time as 10:00:00. Hence, the value of ZVB1 and ZVB2 will be 10.0000. Now let us assume that the next time pair with start time has start time as 08:00:00. This time pair will get processed through Y (OUTTPEXBTM). The value of time type ZVB1 is read using HRS=DZVB1 (ZVB1 = 10.0000). This value is compared with 0 using HRS?0 and since the value of ZVB1 (10.0000) is greater than 0, the time pair gets processed under >. Then the start time of the time pair is read using HRS=PBEG (HRS = 08.0000) and it is compared with “earliest recorded clock in” time type ZVB1 (10.0000) using HRS?DZVB1. Since the value of HRS=PBEB (08.0000) is not greater than ZVB1 (10.0000), the start time of this time pair is the new “earliest recorded clock in” for this shift and gets processed under *. Hence, the start time (08.0000) of the current time pair is fed into daily time type ZVB1 after removing its old value 10.0000 using ADDDBZVB1Z and the time pair is moved to output table using COLOP *.
- Currently, the value of ZVB1 and ZVB2 are 08.0000 and 10.0000 respectively. Let us assume now that the next time pair with start time has start time as 15:00:00. This time pair will get processed through Y (OUTTPEXBTM). The value of time type ZVB1 is read using HRS=DZVB1 (ZVB1 = 08.0000). This value is compared with 0 using HRS?0 and since the value of ZVB1 (08.0000) is greater than 0, the time pair gets processed under >. Then the start time of the time pair is read using HRS=PBEG (HRS = 15.0000) and it is compared with “earliest recorded clock in” time type ZVB1 (08.0000) using HRS?DZVB1. Since the value of HRS=PBEG (15.0000) is greater than “earliest recorded clock in” time type ZVB1 (08.0000), the time pair gets processed under >. Then the value of HRS=PBEG (15.0000) is compared with “latest recorded clock in” time type ZVB2 (10.0000). Since the value of HRS=PBEB (15.0000) is greater than ZVB2 (10.0000), the start time of this time pair is the new “latest recorded clock in” for this shift and it gets processed under >. Hence, the start time (15.0000) of the current time pair is fed into daily time type ZVB2 after removing its old value 10.0000 using ADDDBZVB2Z and the time pair is moved to output table using COLOP *.
- Currently, the value of ZVB1 and ZVB2 are 08.0000 and 15.0000 respectively. Let us assume now that the next time pair with start time has start time as 13:00:00. This time pair will get processed through Y (OUTTPEXBTM). The value of time type ZVB1 is read using HRS=DZVB1 (ZVB1 = 08.0000). This value is compared with 0 using HRS?0 and since the value of ZVB1 (08.0000) is greater than 0, the time pair gets processed under >. Then the start time of the time pair is read using HRS=PBEG (HRS = 13.0000) and it is compared with “earliest recorded clock in” time type ZVB1 (08.0000) using HRS?DZVB1. Since the value of HRS=PBEG (13.0000) is greater than “earliest recorded clock in” time type ZVB1 (08.0000), the time pair gets processed under >. Then the value of HRS=PBEG (13.0000) is compared with “latest recorded clock in” time type ZVB2 (15.0000). Since the value of HRS=PBEB (13.0000) is not greater than ZVB2 (15.0000), the start time of this time pair is not the new “latest recorded clock in” for this shift and it gets processed under *. Hence, this time pair is moved into output table using COLOP *.
- Finally, the value of “earliest recorded clock in” time type ZVB1 and “latest recorded clock in” time type ZVB2 are 08.0000 and 15.0000 respectively.
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.
- The PCR checks if end time exists in time pair or not using OUTTPEXETM. If end time doesn’t exist (N), the time pair is moved to output table using COLOP *. If all time pairs of the shift don’t have end time, then time types ZVB3 and ZVB4 aren’t created. Hence, the values of ZVB3 and ZVB4 are 0.
- If the end time exists (Y) in time pair, the value of time type ZVB3 (Earliest Recorded Clock Out) is read using HRS=DZVB3. If it is the first time pair with end time and getting processed in the rule, the value of ZVB3 will be 0. If it is not the first time pair with end time, then there will be some value in time type ZVB3.
- After reading the value of time type ZVB3, it is compared with 0 using HRS?0. If the value of ZVB3 is not greater than 0, then the time pair gets processed under * and the end time of the time pair is read using HRS=PEND. The end time is added to time types ZVB3 (earliest recorded clock out) and ZVB4 (latest recorded clock out) and the time pair is moved to output table using COLOP *.
- Let us assume that the first time pair with end time had end time as 12:00:00. Hence, the value of ZVB3 and ZVB4 will be 12.0000. Now let us assume that the next time pair with end time has end time as 10:00:00. This time pair will get processed through Y (OUTTPEXETM). The value of time type ZVB3 is read using HRS=DZVB3 (ZVB3 = 12.0000). This value is compared with 0 using HRS?0 and since the value of ZVB3 (12.0000) is greater than 0, the time pair gets processed under >. Then the end time of the time pair is read using HRS=PEND (HRS = 10.0000) and it is compared with “earliest recorded clock out” time type ZVB3 (12.0000) using HRS?DZVB3. Since the value of HRS=PEND (10.0000) is not greater than ZVB3 (12.0000), the end time of this time pair is the new “earliest recorded clock out” for this shift and it gets processed under *. Hence, the end time (10.0000) of the current time pair is fed into daily time type ZVB3 after removing its old value 12.0000 using ADDDBZVB3Z and the time pair is moved to output table using COLOP *.
- Currently, the value of ZVB3 and ZVB4 are 10.0000 and 12.0000 respectively. Let us assume now that the next time pair with end time has end time as 18:00:00. This time pair will get processed through Y (OUTTPEXETM). The value of time type ZVB3 is read using HRS=DZVB3 (ZVB3 = 10.0000). This value is compared with 0 using HRS?0 and since the value of ZVB3 (10.0000) is greater than 0, the time pair gets processed under >. Then the end time of the time pair is read using HRS=PEND (HRS = 18.0000) and it is compared with “earliest recorded clock out” time type ZVB3 (10.0000) using HRS?DZVB3. Since the value of HRS=PEND (18.0000) is greater than “earliest recorded clock out” time type ZVB3 (10.0000), the time pair gets processed under >. Then the value of HRS=PEND (18.0000) is compared with “latest recorded clock out” time type ZVB4 (12.0000). Since the value of HRS=PEND (18.0000) is greater than ZVB4 (12.0000), the end time of this time pair is the new “latest recorded clock out” for this shift and the time pair is processed under *. Hence, the end time (18.0000) of the current time pair is fed into daily time type ZVB4 after removing its old value 12.0000 using ADDDBZVB4Z and the time pair is moved to output table using COLOP *.
- Currently, the value of ZVB3 and ZVB4 are 10.0000 and 18.0000 respectively. Let us assume now that the next time pair with end time has end time as 16:00:00. This time pair will get processed through Y (OUTTPEXETM). The value of time type ZVB3 is read using HRS=DZVB3 (ZVB1 = 10.0000). This value is compared with 0 using HRS?0 and since the value of ZVB3 (10.0000) is greater than 0, the time pair gets processed under >. Then the start time of the time pair is read using HRS=PEND (HRS = 16.0000) and it is compared with “earliest recorded clock out” time type ZVB3 (10.0000) using HRS?DZVB3. Since the value of HRS=PEND (16.0000) is greater than “earliest recorded clock out” time type ZVB3 (10.0000), the time pair gets processed under >. Then the value of HRS=PEND (16.0000) is compared with “latest recorded clock out” time type ZVB4 (18.0000). Since the value of HRS=PEND (16.0000) is less than ZVB4 (18.0000), the end time of this time pair is not the new “latest recorded clock out” for this shift and the time pair gets processed under <. Hence, this time pair is moved into output table using COLOP *.
- Finally, the value of “earliest recorded clock out” time type ZVB3 and “latest recorded clock out” time type ZVB4 are 10.0000 and 18.0000 respectively.
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.
- Scenario 1: “Earliest Recorded Clock In” Time Type ZVB1 not created and “Earliest Recorded Clock Out” Time Type ZVB3 has value 10.0000 – The PCR ZVB6 reads the value of “earliest recorded clock in” time type ZVB1 (blank) using HRS=DZVB1 and then subtracts the value of “earliest recorded clock out” time type ZVB3 (10.0000) using HRS-DZVB3. The result is compared with 0 using HRS?0 and since this is not greater than 0, it gets processed under *. The value of “earliest recorded clock in” time type ZVB1 is read using HRS=DZVB1 and is fed into “first clock in” time type ZVB5 using ADDDBZVB5Z. The value of ZVB5 is 0.0000 implying that the “first clock in” is missing.
- Scenario 2: “Earliest Recorded Clock In” Time Type ZVB1 has value 08.0000 and “Earliest Recorded Clock Out” Time Type ZVB3 has value 10.0000 – The PCR ZVB6 reads the value of “earliest recorded clock in” time type ZVB1 (08.0000) using HRS=DZVB1 and then subtracts the value of “earliest recorded clock out” time type ZVB3 (10.0000) using HRS-DZVB3. The result is compared with 0 using HRS?0 and since this is not greater than 0, it gets processed under *. The value of “earliest recorded clock in” time type ZVB1 (08.0000) is read using HRS=DZVB1 and is fed into “first clock in” time type ZVB5 using ADDDBZVB5Z. Hence, the value of ZVB5 is 08.0000.
- Scenario 3: “Earliest Recorded Clock In” Time Type ZVB1 has value 12.0000 and “Earliest Recorded Clock Out” Time Type ZVB3 has value 10.0000 – The PCR ZVB6 reads the value of “earliest recorded clock in” time type ZVB1 (12.0000) using HRS=DZVB1 and then subtracts the value of “earliest recorded clock out” time type ZVB3 (10.0000) using HRS-DZVB3. The result is compared with 0 using HRS?0 and since this is greater than 0, it gets processed under >. The result is compared with “earliest recorded clock in” time type ZVB1 (12.0000) using operation HRS?DZVB1 and since the result is less than the value of ZVB1, it gets processed under <. Using HRS=0.00, the value is set to 0 and then fed into “first clock in” time type ZVB5 using ADDDBZVB5Z. Hence, the value of ZVB5 is 0.0000 implying that the “first clock in” is missing.
- Scenario 4: “Earliest Recorded Clock In” Time Type ZVB1 has value 08.0000 and “Earliest Recorded Clock Out” Time Type ZVB3 has value 0.0000 – The PCR ZVB6 reads the value of “earliest recorded clock in” time type ZVB1 (08.0000) using HRS=DZVB1 and then subtracts the value of “earliest recorded clock out” time type ZVB3 (0.0000) using HRS-DZVB3. The result is compared with 0 using HRS?0 and since this is greater than 0, it gets processed under >. The result is compared with “earliest recorded clock in” time type ZVB1 (08.0000) using operation HRS?DZVB1 and since the result is equal to the value of ZVB1, it gets processed under =. The value of “earliest recorded clock in” time type ZVB1 (08.0000) is read using HRS=DZVB1 and then fed into “first clock in” time type ZVB5 using ADDDBZVB5Z. Hence, the value of ZVB5 is 08.0000.
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.
- Scenario 1: “Latest Recorded Clock Out” Time Type ZVB4 not created and “Latest Recorded Clock In” Time Type ZVB2 has value 12.0000 – The PCR ZVB7 reads the value of “latest recorded clock out” time type ZVB4 (blank) using HRS=DZVB4 and then subtracts the value of “latest recorded clock in” time type ZVB2 (12.0000) using HRS-DZVB2. The result is compared with 0 using HRS?0 and since this is not greater than 0, it gets processed under *. Using HRS=0.00, the value is set to 0 and then fed into “last clock out” time type ZVB6 using ADDDBZVB6Z. Hence, the value of ZVB6 is 0.0000 implying that the “last clock out” is missing.
- Scenario 2: “Latest Recorded Clock Out” Time Type ZVB4 has value 18.0000 and “Latest Recorded Clock In” Time Type ZVB2 has value 12.0000 – The PCR ZVB7 reads the value of “latest recorded clock out” time type ZVB4 (18.0000) using HRS=DZVB4 and then subtracts the value of “latest recorded clock in” time type ZVB2 (12.0000) using HRS-DZVB2. The result is compared with 0 using HRS?0 and since this is greater than 0, it gets processed under >. The value of “latest recorded clock out” time type ZVB4 (18.0000) is read using HRS=DZVB4 and then fed into “last clock out” time type ZVB6 using ADDDBZVB6Z. Hence, the value of ZVB6 is 18.0000.
- Scenario 3: “Latest Recorded Clock Out” Time Type ZVB4 has value 14.0000 and “Latest Recorded Clock In” Time Type ZVB2 has value 16.0000 – The PCR ZVB7 reads the value of “latest recorded clock out” time type ZVB4 (14.0000) using HRS=DZVB4 and then subtracts the value of “latest recorded clock in” time type ZVB2 (16.0000) using HRS-DZVB2. The result is compared with 0 using HRS?0 and since this is not greater than 0, it gets processed under *. Using HRS=0.00, the value is set to 0 and then fed into “last clock out” time type ZVB6 using ADDDBZVB6Z. Hence, the value of ZVB6 is 0.0000 implying that the “last clock out” is missing.
- Scenario 4: “Latest Recorded Clock Out” Time Type ZVB4 has value 18.0000 and “Latest Recorded Clock In” Time Type ZVB2 not created – The PCR ZVB7 reads the value of “latest recorded clock out” time type ZVB4 (18.0000) using HRS=DZVB4 and then subtracts the value of “latest recorded clock in” time type ZVB2 (0.0000) using HRS-DZVB2. The result is compared with 0 using HRS?0 and since this is greater than 0, it gets processed under >. The value of “latest recorded clock out” time type ZVB4 (18.0000) is read using HRS=DZVB4 and then fed into “last clock out” time type ZVB6 using ADDDBZVB6Z. Hence, the value of ZVB6 is 18.0000.
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:
- The start time of the time pair is deleted using FILLPB-
- The start of record type (P10) is deleted using FILLPF
- The no. of hours is reduced to 0.0000 using FILLPN
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:
- The end time of the time pair is deleted using FILLPE-
- The end of record type (P20) is deleted using FILLPG
- The status of the time pair is changed to 1 using FILLP11 implying that both start and end times are missing from the time pair
- The time pair is moved to output table for further processing using COLOP *.
- Hence, the time pair has both “From” time and “To” time as blank.
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:
- The start time of the time pair is deleted using FILLPB-
- The start of record type (P10) is deleted using FILLPF
- The no. of hours is reduced to 0.0000 using FILLPN
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 end time of the time pair is filled with value of “last clock out” time type ZVB6 (18.0000) using FILLPE.
- The end of record type (P20) is added to time pair using FILLPG
- The status of the time pair is changed to 2 using FILLP12 implying that clock in time is missing from time pair.
- The time pair is moved to output table for further processing using COLOP *.
- Hence, the time pair has “From” time and “To” time as blank and 18.0000 respectively.
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:
- The start time of the time pair is set from “first clock in” time type ZVB5 using FILLPB.
- The start of record type (P10) is set for time pair using FILLPFP10.
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:
- The end time of the time pair is deleted using FILLPE-
- The end of record type (P20) is deleted using FILLPG
- The no. of hours is reduced to 0.0000 using FILLPN
- The status of the time pair is changed to 3 using FILLP13 implying that clock out time is missing from time pair.
- The time pair is moved to output table for further processing using COLOP *.
- Hence, the time pair has “From” time and “To” time as 08.0000 and blank respectively.
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:
- The start time of the time pair is set from “first clock in” time type ZVB5 using FILLPB.
- The start of record type (P10) is set for time pair using FILLPFP10.
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 end time of the time pair is set from “last clock out” time type ZVB6 (18.0000) using FILLPE.
- The end of record type (P20) is set for time pair using FILLPGP20.
- The status of the time pair is changed to 0 using FILLP10 implying that the pair is error free with both start time and end time.
- The time pair is moved to output table for further processing using COLOP *.
- Hence, the time pair has “From” time and “To” time as 08.0000 and 18.0000 respectively.
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
Dear Vivek,
It's a great job! Thank you for sharing it.
Just a question. Why you have such a cases: "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."?
How they specify on devices a clock is in or out?
How employees record clock-in/out? Is there any button which employee use to specify clock-in/out and they use them in a mistake which you see such a records?
Regards,
Omid
Hi Omid,
The client has time recording terminals mounted on the wall.
They don't have turnstiles where the employee must clock in while entering the plant and must clock out while leaving the plant.
There are 2 terminals mounted on the wall. One is marked as "Clock In" and the next one as "Clock Out".
All the punch in recorded at terminal clock in will be considered as P10 and all punch in recorded at terminal clock out will be considered as P20.
Since the terminals are mounted on wall, hence, employee may miss on swipe in or swipe out while entering or leaving the premises.
As a result, the requirement was to build a solution which will be automatic and work in all scenarios except if first clock in or last clock out is missing.
Regards,
Vivek
Dear Vivek,
Thanks for your reply. Just some questions for my information.
Which brand of terminals the client has?
What is the clock-in/out records transfer interval from terminals into SAP?
Regards,
Omid
Hi,
The client is using Honeywell Prowatch as the time recording terminals and the client would like 2 transfer per shift. One during the middle of the shift and another 4 hours after the end of the shift.
Thanks and regards,
Vivek Barnwal
Dear Vivek,
Thanks for sharing this excellent document.
Regards
Ramesh
Thanks Ramesh.
You are welcome.
Regards,
Vivek
Good Work Vivek , Please keep on post further custom requirements in positive time management.
Thanks for sharing again!!!!!
Siva Prasad
Thanks so much Siva.
Regards
Vivek
Great work Vivek. It is a great piece of information for all who are looking to implement positive time management having similar scenarios.
Thanks Anand.
Regards,
Vivek
It's analyzed and narated very well, Thank you vivek for sharing such an good article.
Brs
DVD Raju
Thank you.
Regards,
Vivek
I would be good if you could kindly rate the document for the benefit of other users. It will help them to ascertain the usefulness of the document.
Thanks and regards,
Vivek Barnwal
Thanks Vivek with a good explanation...
Vijay
Thanks Vijay. Request you to please rate the document as it will be helpful for others during future reference.
Excellent Vivek.
Sri..
Thanks Sri
Dear Vivek,
Superub document... 🙂
Regards,
Vijay Kumar
An exhaustive and detailed approach, excellent doc. Good Job Vivek!
BR
Upen
Thanks Upendra.
Vivek - Good document. Are/Were you in Infosys? Had a colleague by the same name.
Pramod
Hi Pramod,
Yes, I am the same Vivek.
Regards,
Vivek
WOW! Excellent blog!!!! Seriously....great job!!!
I had to do something similar for a client LONG ago, so I know what all you had to go through. You have described and laid it out perfectly. This will be invaluable for those facing the same issue (and it is just a good read for others as well).
Thanks and KEEP BLOGGING! 🙂
Thanks so much Christopher....
Hi Vivek,
Really an excellent document.
Valuable information!!!! This will help Peers in the forum to understand the importance of PCR for Time Recording Machines..
If Iam Moderator of SAP, I would given 100 points for this document. It is more like a Project This information covers entire project of Time Management
Thanks again
Keep sharing!!! 🙂
Regards
Rajesh Kumar Burra
Thanks for your feedback Rajesh.
Regards,
Vivek
You may also go through this document.
http://scn.sap.com/docs/DOC-44521
Hi Vivek,
This is a brilliant work. Conceptually very clear so easy to understand the requirement and the logic written for it.
Please keep on posting such real time business scenario on positive time management which helps us immensely.
Thanks a lot for such an awesome blog & thanks for helping us to update our knowledge and strength in SAP.
Thanks &Regards,
Prashanti swain
Thanks for your feedback Prashanti.
Warm regards,
Vivek
You may also go through this document.
http://scn.sap.com/docs/DOC-44521
All I can do now is to Like each comment posted by you
Thanks a lot!!!
🙂 Thanks much
Thanks Vivek for your useful and so detailed document .
Excellent work Vivek
It will be more helpful if u can let us know how to integrate 3rd party data(Kronos) to system directly into portal on Clock-in/out but not via uploading the Template every time. any suggestions!!!!
Cheers 😉
Pradyp
You can do that with BAPIS
Sorry Pradyp, I didn't get your question about integrating 3rd party data to system direclty into portal on clock in/out.
Our client has installed Honeywell Prowatch Badge Readers and we have built custom inbound and outbound interfaces (SAP PI) to transfer data between SAP R/3 and Honeywell Pro-Watch.
Honeywell Prowatch is not a CC certified time recording system.
Warm regards,
Vivek
HI,
Really Helpful!!!
Great Job.
Thanks for sharing the same.
Best Regards,
Ketul Patel
Thanks Ketul.
Regards,
Vivek
Great job!
Thanks for sharing this excellent most detailed post.
Thank you Shai
Hi Vivek,
Awesomeeeeeeeeeeeeeee one , almost you given us all the parts of Positive Time Management.
Great work dear,
But would you help me to understand these standard tables.
Because currently i am working on positive time management where i dont get how these two tables have been configured on this
thanks
Sri
Hi Sriram,
I have given the explanation for these tables in the document. However, if you still need a detailed explanation, please refer to PK Agarwal's book on Time Management.
Thanks and regards,
Vivek Barnwal
Hi Vivek,
Thanks for your guidance. i have bought the book as soon as you said.its well explained.
thanks once again. i appreicate your great job.
Regards,
Sri
Thanks Sriram
Hi Vivek,
I'm doing a study on your "one stop shop" and I'm really appreciate you sharing knowledge.
I read this article, and I understand the business requirement is once there is a first clock in and a last clock out, other unmatched time data (no matter clock in or out) will be ignored. The hour that an employee worked would be counted using first clock in and last clock out. Am I right?
Here I have a question about real business requirement. How the most companies process leakage card situation? It must have lots of possibilities of missing clock in or clock out. Do companies like giving error hints and stop evaluation once there's missing time data, or do they like ignoring it as long as there is a first clock in and a last clock out?
Is it possible to have a requirement like this?
08:00 clock in
10:00 clock out
14:00 clock out
15:00 clock in
16:00 clock out
The requirement is ignoring 14:00 clock out but calulate hours using all other matched data (08:00-10:00 and 15:00-16:00)?
I only want to know some real possibilities in business requirement since I havn't done any real one yet 🙂
Thank you very much!!
Hi,
It all depends on client requirements. But I am surprised a client will have a requirement to calculate hours only using completed time pairs. If there is a clock in missing, it means that the employee was in the plant and that should be corrected to arrive at the correct hours employee has worked.
In my current client, they would like every missing time stamp to be pointed out so that they can ask their employees to update them. So we are building a solution to let the time evaluation fail if there is a missing time stamp.
Thanks and regards,
Vivek Barnwal
Hi Vivek,
Thank you for you quick reply!
It's quite clear and useful.
Thank you!!
Hi,
I did some tests of the pairing mechanism.
Two short insights of my checks:
1. It seems that TPT_PAIRSTAT2 contents cannot really be modified.
Surprisingly, TPT_PAIRSTAT2 isn't being used at all. All the logic/values are hard-coded in report RPTIME00 subroutine DET_NEXT_COGOS.
2. In alternative to customizing table V_T705B, you may use user-exit: Enhancement HRPTIM05 FM EXIT_SAPLRPPD_001 for the same purpose (in employee/date level).
FYI,
Shai
Thanks Shai for sharing this input. I am sure it will be useful for all.
Vivek,
This document is really amazing, amazing!. I studied him very much, but not being an expert in TIME and only one support, I got some questions .... I also wrote on the forum ....
Here I am on the client, there marking there is no Input and Output, however, he takes the mark the next day for the previous day and often creates lack used for the next day (even if there P10 and P20) and then the employee is deducted on your payroll. Here we also used the Honeywell.
Can you understand my question? For these two tables:
TPT_PAIRSTAT2 V_T705B and I can configure the system to understand that even if the employee has an entry and has no output, it will not be with payroll deduction?
I appreciate attention ....
Thanks:
Paula
Apologies Paula, I didn't understand your question.
Can you please rephrase it with an example? That will make things more clear.
Regards,
Vivek Barnwal
Vivek,
First, the problem I have is that the marking <'re assuming for the previous day
And in TIP creates these values ... 34, 36 ... 38 .... that does not reflect the IT2011
It was best to understand?
The employee is being deducted from payroll!
SM30: TPT_PAIRSTAT2
And
SM30: V_T705B
And I can not configure not to receive the mark of the previous day.
Thank you for you attention.
Regards,
Paula
Hi Paula,
This is standard SAP functionality in case of night shift or if the employee doesn't clock out in a day shift.
I had reported same issue to SAP and this is the standard functionality as per SAP. We can't do anything about it. You will have to update the missing time stamp for the first day.
Please refer the below thread.
Pair Formation Issue in Positive Time Management with Time Events
I hope this helps.
Kindly log any question in future in a separate thread so that other SAP HCM consultants in SCN network can view your question and also provide their inputs.
Also, I would appreciate if you kindly rate this document quality for the benefit of SCN users.
Thanks and regards,
Vivek Barnwal
Hi Vivek!
Thank you again.
My question is that before we had a setup that did not receive the previous day in the marking of IT2011.
The day was unmarked in IT2011 peerless and thus, had the warning message to inform the missing pair. And now, it's so .... assuming the following day to the previous day!
So I was confused and did not already have here the Expert Advisor and many problems in the payroll of employees.
SAP considers time events of current day and next day to form time pair.
Let us say that the shift timing are 7:00 - 15:00 on 02-Jan and 03-Jan. The employee clocks in at 7:00 am on 02-Jan. He forgot to clock out on 02-Jan and the time evaluation will point out that employee didn't clock out. This error should be fixed.
The employee came to office on 03-Jan and forgot to clock in on 03-Jan. He clocked out at 15:00 on 03-Jan.
The system during time evaluation run for 02-Jan will see a clock in at 7 am on 02-Jan and a clock at 3 pm on 03-Jan. It will form a time pair for 02-Jan saying that the employee was at work for 32 hours and will report an error that the employee is not at work on 03-Jan.
SAP advised that this is the standard behavior and time administrator should go and get the record corrected.
I hope this clarifies.
Thanks and regards,
Vivek Barnwal
Hi Vivek,
Could you please respond to the below mentioned thread:
http://scn.sap.com/thread/3585358
Thanks,
Gopal
Hi Vivek,
Excellent, awesome, brilliant document prepared by you. Hats off to your patience also for this document.
Regards,
Bhagyashree
Thank you Bhagyashree.
You can go through other time management documents from the link below:
One Stop Shop of my Knowledge Artifacts in SAP HCM
Regards,
Vivek
Hello Vivek ,
These document is very gud . I did all the above steps its working fine for me , but on weekdays its calculate the p10 and p20 for next day . I am not able to control these I feel its because of c11 .
Can you please help me to come out .
I didn't get your question about it not working on weekday. It is working fine for me for all possible scenarios.
Please share your screenshots where it is not working.
Thanks and regards,
Vivek Barnwal
Good one
Thanks Surya...
Regards,
Vivek
Again another great Document Vivek...I must say...I am dying to work with you now.... 😉
Thanks Bhagyashree...
Hello Vivek
This is a great Document and has complete set of info.
I can rate this 25 out of 10.
Reg
Zen
That is kind of you to say so Zen. Kindly rate the document by providing your rating at the end of the document.
Regards,
Vivek
Thanks for a great document.
Thanks Dheeraj.
Regards,
Vivek
Thanks Vivek for keeping it simple and to the point. Appreciate your efforts!
Thanks Tom. Glad you liked it.
Hi Vivek,
Your document was great.
I am implementing positive time management and at present i am entering the clock in and clock-out in IT-2011 manually for testing and when i run PT60 using TM00 schema it was not showing any errors but data in 'ZL' it was showing as no entries.
And to cross check i have executed 'PC00_M40_CALC' but the payroll was caluclated based on no. of days( negative tm).
I am new to TM concept please help me out.
Thanks,
Saikrishna.
Please log a new query in a thread where SCN members can respond to your query.
Thanks and regards,
Vivek Barnwal
Hi,
I have also tried and same issue no errors but ZL table is not getting Updated. Pls give your solution what you tried in this.
Dear Vivek,
Your sharing is great.
But have you tried operation TIPOS? I think this operation can also get first pair/last pair.
Best Regards,
Alina
Hi Alina,
I haven't tried operation TIPOS.
Can this operation meet all the requirements mentioned in this article? If yes, please write a document and share it for the benefit of HCM Community.
Regards,
Vivek
Great!
thnx, Fred
Once Again I referred this article and excellent documented and well detailed.
With the help of this entire document and little change in one PCR (ZVB5) I have achieved below scenario.
Requirement: Client have machines in which it can not identify whether it is Clock In or Clock out. Vendor provided one software in which based on Shift it will be identified.
Client is not ready to change machine or able to provide raw punches with Clock In or Clock out.
Solution:
1. Considered all time events as P01 - Clock in/Clock Out and upload time events as P01.
2. Modify PCR ZVB5 as per below in addition to PCR Explained Above.
3. Rest all is same as well explained in this document.
Once again many thanks to Mr. Vivek Barnwal.
Best Regards,
Ketul
Hello Ketul and Vivek
In my Client is also same approach they are not having 2 Machine for punch in and punch out , only one machine is there which is for both CICO, they also want to map Clock in and out in P01, please let me know only above PCR i can follow to configure my requirement or after along with above PCR rest PCR also i have to follow ??
Please help me i am waiting for your respond
Regarda
Anurag
Hi Vivek,
Excellent Document !!!
One question though; time events are as below:
P10 - 00:00:00
P10 - 04:00:00
P20 - 08:20:00
and the TIP looks like this
00:00:00 04:00:00 P10 P10
04:00:00 08:20:00 P10 P20
In this scenario, at the first line iteration of PCR ZVB4, the value of ZVB1 (Earliest recorded Clock-in) and ZVB2 (latest recorded clock-in) is 00,00. However, at the second Iteration, the values for both the time types ZVB1 & 2 are changing to 04,00, causing loss of 4 hours.
By this means, the error will continue in time type ZVB5 determination too..
Kindly correct my understanding if i have interpreted this incorrect !!!
Regards
Kumarpal
Hi Kumarpal,
This solution has one limitation where the first clock in falls at 00:00. However, given my client requirements, such a scenario won't ever occur.
To incorporate the given scenario, we would need to pass value in time type as 0.0010 for 00:00.
Thanks and regards,
Vivek Barnwal
Thanks Vivek.
The way we handle this in our scenario is, during posting process of time events to TEVEN,
This solution is suggested via SAP NOTE: 336994.
Regards
Kumarpal
Hi Vivek Barnal,
Excellent document which was easily understandable Thanks for sharing with us.
Looking forward for some more documents from you.
Thanks.
Hello Vivek,
Very nice document, i must say!!! keep it up..
I have one question also... Raised it on SDN.
TM04 Schema | SCN
Thanks
Sonu
Hi Vivek
Nice document as always from you.
However, one small doubt! What happens if the employee clocks in 12:00am (midnight)? The start time will be zero. And will the PCR determine that there is no clock in?
br, JG
This solution has one limitation where the first clock in falls at 00:00. However, given my client requirements, such a scenario won't ever occur.
To incorporate the given scenario, we would need to pass value in time type as 0.0010 for 00:00.
If the employee is on night shift, 00:00 will be treated as 24.00000.
Thanks and regards,
Vivek Barnwal
One possible solution would be:
a)Configure time types
ZMNS Midnight start.
ZMNE Midnight end
b)When the start time = 00:00, change it to 00:01; and add 1 to time type ZMNS.
Later when this t/t ZMNS can be checked for 1 and the start time can be changed back to 00:00.
b)Similarly for end time = 00:00, change it to 00:01 and add 1 to t/t ZMNE and check similarly later. ..
Yes a possible option. End time 0:00 will imply as 24.0000 because the start time will be before that.
Hello sir (Vivek Barnwal )
my question are
I am total confused please help Thank you
sir
This is the great document ever
Hi vivek.
Vivek Barnwal
I have tried as per your Document really ts good and error free.Thanks for this valuable document. But problem is how to integrate it with payroll. Here ZL table is not getting updated even if i done live run.
Pls do needfull.
Regards
Vignesh
Hi Experts,
I have scenario for flex time,
The scenario is employee has a flex time work schedule. The employee working hours should be 8 hours and 1 hour unpaid break. If an employee works more than 8 hours (Based on P10 and P20) then the OT should be calculated.
Scenario 1 : Clock In P10- 8:00, Clock Out P20- 17:00 so totally 9 Hours - 1 hour Unpaid break in this case there should not be OT .
Scenario 2: Clock In P10- 8:00, Clock Out P20- 18:00 so totally 10 Hours - 1 Unpaid break in this case there should be 1 hour of OT
Scenario 3: Clock In P10- 18:00, Clock Out P20- 04:00 (Next Day) so totally 10 Hours - 1 Unpaid break in this case there should be 1 hour of OT
OT on normal working days should 1.5%
OT on week end days should be 2.25%
OT on public holidays should be 2.5%
In T550A table
i have configured in Flex time as
Planned working time 00:00 till 24:00
Normal Working time 8:00 till 17:00
Break schedule 12:00 till 13:00
Begin Tolerance 00:00 till 10:00
End Tolerance 17:00 till 16:45
And the percentage i have captured in T512w_b- Valuation table against the wage type
Please help how to captured the OT in PCR.
Please find the below link
https://answers.sap.com/questions/13221960/over-time-in-flex-time-work-schedule.html