Attendance Data Processing

This topic is more of a "system internals" topic. It describes how the system figures things out, algorithmically. This is useful for troubleshooting and getting an insight for how it works -- not necessarily for day-to-day use.

The main job is this section is describing the rules of processing cardholder's attendance data for building reports.

It includes:

- Finding cardholder's that have active cards/badges for the specified date range

- Finding which shift is active for every cardholder

- Finding a shift entry to be used for attendance data processing

- Finding cardholder's attendance events and fixing missing events

- Finally, calculating work time, lunch/break time, and overtime

How Iotellect Decides if a Card Is Active

When processing card data, Iotellect needs to figure out whether to treat a certain card/badge as active or not.

First, some terminology:

Start date below means the start date for a given query. If you're trying to produce an attendance report for the period between 1/Jan/2009 and 1/Feb/2009, then 1/Jan/2009 would be the start date (and 1/Feb/2009 is called end date below). Now, how the system figures out what cards/badges to include in this query:

  • It gets the card/badges variable of a certain cardholder context (which contains a data table with all registered cards/badges)
  • It now collects all records from the card/badges table for which enabled is true
  • It gets the activation date property of each record, and throws out this record if the end date is earlier than the activation date (meaning, the query is for a period of time in which the card was not yet active)
  • Next, Iotellect reads the deactivation date property for the badge. This can be null. If it's not, and is also earlier than the start date, the system throws out this record (because this would mean that the card/badge has already been deactivated by the start date).
  • Any record which made it this far with all checks valid is an active card for this cardholder for the purposes of this report.

    • Finding the Active Shift

    Iotellect now finds the active shift for the given cardholder. It does this by checking the Custom Shift setting of the cardholder. If this is undefined, it moves up the organizational hierarchy, checking for a custom shift for the department or division. If none of these are defined, Iotellect takes the shift defined for the whole organization.  Further processing is based on the time limits and overtime policies defined for this shift.

    Finding Relevant Attendance Events and Normalizing Event Sequence

    At this point of the process, we have a complete list of cards/badges we need information for, and a range of dates (Start date and End date above).

  • Iotellect now searches the database for all events between the start and the end date with the card/badge IDs specified.
  • It now sorts all of the events according to their timestamp, earliest to latest.
  • For each cardholder on a given workday, it checks to see if the first event is IN. If the first IN event is missing, meaning, the first event is OUT, the system adds an IN event according to the following logic:

    • - If the OUT event is from before the shift started: Iotellect adds an IN event with a timestamp just before that OUT event.

    - If the OUT event is from after the shift started: Iotellect adds an IN event at the beginning of the shift (i.e. Report Time).

  • Iotellect now checks the last event for the cardholder for that day, to verify that it is an OUT event. If the last event for that workday is IN (meaning, the OUT is missing), Iotellect adds an OUT event according to the following logic:

    • - If the IN event is from before the shift ended: Iotellect adds an OUT event at the time the shift ends (i.e. Knock Off Time).

    - If the IN event is from after the shift ended: Iotellect adds an OUT event with a timestamp just after that IN event.

  • Iotellect now verifies the resulting event set, to ensure that there are no two IN or two OUT events one after the other.

    • Note: The rules in points 3 and 4 are valid for any two IN or OUT events in sequence. Meaning: If Iotellect finds two contiguous IN events, it applies rule 4; if it finds two contiguous OUT events, it applies rule 3.

    Finding Day Rules for a Given Event Pair

    Iotellect now has a normalized event pair it has to process. Each pair of IN/OUT events marks a period of time which the cardholder spend at work. This period may fall within the bounds of a scheduled shift, or outside such a shift.

    It also knows what shift the employee is assigned to. So it now has to figure out what are the rules for the specific day in which the event pair occurred.

    For a Weekly Shift

    For a weekly shift, the algorithm is very simple.

  • What date did the events occur on?
  • Is that date defined as an exception? If so, take its rules. If not, move on and figure out...
  • What day of the week was it?
  • Bang -- that's it. We now know what are the overtime rules and expected schedule for that date (because the weekly shift defines a rule for every day of the week).

    • For a Regular Shift

    Regular shifts are cyclic in nature, and so determining what day of the cycle an event pair falls on is a bit trickier. Let's use an example for this.

  • Let's say we have a three-day regular shift, with a start date of 21 July 2009.
  • The event pair we're working with occurred on 17 October 2009.
  • Is that date defined as an exception? If so, take its rules. If not, move on.
  • Iotellect calculates the difference between the start date and the event date. It is 88 days.
  • Iotellect now divides the difference in days (88) by the number of days in the shift (3) and calculates the remainder. In this case, it is 1.
  • Iotellect now takes the remainder and adds it to 1 because the row number for first day of the shift is 1 and not 0 (so if the remainder is 0, for example, the correct day is day 1 of the shift). In our case, the result would be 2. Therefore, the rules for the second day of the three-day cycle apply.

    • Calculating Time Worked and Any Overtime

  • If the time is within schedule bounds for that day of the shift, it is counted as normal working time. This is the simplest option.
  • When the time is outside of the schedule for the day, Iotellect employs a complex algorithm to decide whether to count it as overtime, regular time, or discard it. There are several possible use cases here:

    • - The worker spent some time working before the shift started.

    - The worker spent some time working during the time allotted for their lunch break.

    - The worker kept on working after the shift ended.

    - The worker came in on a day which is their day off.

    3. Each of these use cases has a corresponding option in Shift properties. If this option is enabled, Iotellect checks how long the overtime is.

    4. Iotellect now calculates how long the entire duration of overtime is, and checks if it is greater than the Minimum Overtime Extent setting. If it is lesser than Minimum Overtime Extent, it will be set to 0.

    5. The system now calculates the sum of all of the scheduled time with the overtime, and compares the result with the allotted duration of the shift. Any time above the allotted time for the shift is now counted as overtime -- again, only time which brings the total working time over the total length of the shift. So arriving 30 minutes late and staying 30 minutes late to make up for it does not qualify one for overtime.

    A Concrete Example

    Let's say Joe Employee is supposed to work from 9:00 till 17:00. Joe comes in late one Monday, say, at 9:05. He keeps on working until 17:25 to make up for the lost time. In this case, Joe doesn't get any overtime (because the total length of his workday is still 8 hours).

    But you can have a problematic scenario, too: Let's say you set Minimum Overtime Extent to something like 30 minutes (not a good idea). In this case, if Joe comes in at 9:25 and stays till 17:25, the system will not count those 25 minutes because they are less than the Minimum Overtime Extent! It would seem as though Joe simply lost 25 minutes of work and could not care less (and he would not be paid for the 25 minutes he stayed -- not even normal rates). So make sure not to set Minimum Overtime Extent to more than 5 minutes or so (or Maximum Overtime Extent to a very short period).

    Calculating Breaks

    To calculate break time, Iotellect compiles all OUT-IN event sequences within the bounds of a given shift. It adds those periods up into a total of all breaks taken.

    Some reports display the time taken for the Lunch Break specifically (because the time when the employee should take the break is configurable in Shift properties). To figure out what pair of OUT-IN events within the shift denote the lunch break, Iotellect considers value of Lunch setting of employee's shift:

    None

    • All pairs of OUT-IN events are considered as breaks.

    Fixed

    1. If there is an OUT event between the Lunch Begin Hour and the Lunch End Hour, Iotellect would take this as the beginning of the lunch break (and the IN event following it, as the end of the lunch break).

    2. If there is no such event, Iotellect would take the last OUT event which precedes the lunch hour.

    If an employee decides to skip their lunch hour and take a lunch break later (starting after the lunch hour is already over), Iotellect would count this as a break, but it would not show up as a "lunch break" in the reports.

    Flexible

    Assuming the value of Lunch Duration is N minutes, the first N minutes of work interruptions during the day will be considered as lunch time, and all the rest is deemed break time.

    Lunch and Break Time Processing

    Lunch hour times are counted together with total break times. Meaning, the total break time for a given day would always include the time spend at lunch break.

    If you do not set Overtime During Lunch in your shift properties, employees will not be able to work during lunch. They might stay at their workstations and work, but the system would not count it as worktime. So if Joe Employee decides to work from 13:00-14:00 (his regular lunch time) and then take his own break from 14:30-15:30, the system would deduct two hours from his workday: The lunch time (because he was not allowed to work overtime during that period of time) and the break he actually did take. So make sure you configure this correctly!

    Was this page helpful?