sharon27 (10/2/2013)
Hi wolfkillj thank you for helping me find solution to my problem.i tried your script and it was ok, but i found something wrong. I tried to add 1 log for Rebecca which is same day of 2013-9-21 23:10:00.
this what i got
001Alvin 2013-09-21 06:30:00.0002013-09-21 17:50:00.000
002Rebecca2013-09-21 22:10:00.0002013-09-21 23:10:00.000
002Rebecca2013-09-21 23:10:00.0002013-09-22 07:30:00.000
which should be like this.
001Alvin 2013-09-21 06:30:00.0002013-09-21 17:50:00.000
002Rebecca2013-09-21 22:10:00.0002013-09-22 07:30:00.000
meaning no matter how many times they punch the reader still need to get the first in and the last out of the employee.
thanks.
Hi Sharon27,
I'm a little confused now about how your data works. Is it true that an "IN" punch always happens on Reader 1 and an "OUT" punch always happens on Reader 2? Which reader did Rebecca punch at 2013-09-21 23:10:00? And how does it work if an employee makes three punches - IN, IN, and OUT (or IN, OUT, and OUT)? How do you match an IN to an OUT to define a shift worked in such cases?
It seems to get much harder to define the beginning and end of a shift this way - you'd have to say that the beginning of a shift is the first IN following an OUT and the end of that shift is the last OUT preceding an IN (or the last OUT when there isn't a subsequent IN) or something like that. So if you had this series of punches, you'd break up the shifts as shown:
IN --- Shift starts ---
OUT --- Shift ends ---
IN --- Shift starts ---
IN
OUT --- Shift ends ---
IN --- Shift starts ---
OUT
OUT --- Shift ends ---
IN --- Shift starts ---
OUT --- Shift ends ---
You can't determine whether an IN punch actually marks the beginning of a shift without verifying that the preceding punch was an OUT, and you can't determine that an OUT punch actually marks the end of a shift without verifying that the next punch is an IN (or nonexistent).
Is this how your system actually works?
Jason Wolfkill