Обработка данных посещений

В этом параграфе говорится о внутренней архитектуре системы. Здесь описывается алгоритм выполнения системных операций. Это может оказаться полезным при выявлении неисправностей, поскольку позволяет глубже понять механизм работы системы.

Основная задача этого параграфа - описание правил обработки данных о посещениях работы пользователей карт для построения отчетов.

Сюда относится:

- Обнаружение владельцев карт, у которых есть активные карты/бейджи для выбранного диапазона дат.

- Обнаружение активной смены для каждого владельца карты.

- Обнаружение записи смены, которая необходима для обработки данных о посещениях.

- Обнаружение событий посещения владельца карты и нахождение отсутствующих событий.

- Подсчет рабочего времени, перерывов/обеденных перерывов и сверхурочного времени.

Во время обработки данных карты AggreGate требуется определить, является ли та или иная карта активной или нет.

Немного терминологии:

Дата начала означает дату начала Вашего запроса. Если Вы хотите получить отчет о посещаемости за период с 1/янв/2009 по 1/фев/2009, а тогда 1/янв/2009 будет датой начала (а 1/фев/2009 является, соответственно, датой окончания). А теперь поговорим о том, как система понимает, какие карты/бейджи следует включить в этот запрос:

• Она получает данные карты/бейджа от контекста определенного владельца карты (которые содержат таблицы данных со всеми зарегистрированными картами/бейджами).

• Теперь она собирает все те записи из таблицы карт/бейджей, у которых стоит флаг Активно.

• Она получает значение даты активации для каждой записи и отбрасывает запись, если дата окончания раньше даты активации (это означает, что запрашивается период времени, в который карта еще не была активной).

• Затем AggreGate считывает значение даты деактивации для бейджа. Оно может быть нулевым. Если нет, и дата дезактивации оказывается раньше даты начала, система не принимает эту запись (поскольку это означает, что карта/бейдж уже были деактивированы датой начала).  

• Любая запись, прошедшая эти проверки успешно, является aктивной картой для данного пользователя карты и включается в отчет.

AggreGate находит активную смену для данного владельца карты, когда проверяет настройки Периодической смены для определенного владельца карты. Если они не определены, он переходит выше в Иерархию организации и проверяет регулярную смену для отдела или подразделения. Если ни одно из них не определено, AggreGate берет смену, определенную для всей организации. Последующая обработка данных включает обработку данных по временным ограничениям и политике учета внеурочного времени, заданной для данной смены.

На этом этапе процесса у нас есть полный список карт/бейджей, информация о которых необходима, а также диапазон дат (см. выше Дата начала и Дата окончания).

• AggreGate осуществляет поиск по базе данных всех событий, находящихся между датой начала и датой окончания с заданным ID карты/бейджа.

• AggreGate сортирует все события согласно их отметки времени, от самой ранней до самой поздней.

• Для каждого владельца карты по данному рабочему дню AggreGate проверяет, является ли первым событием IN (событием входа). Если первое событие IN отсутствует, т.е. первое событие - OUT(событие выхода), система добавляет событие IN согласно следующей логике:

- Если событие OUT относится к периоду до начала смены: AggreGate добавляет событие IN с отметкой времени как раз до начала события OUT.

- Если событие OUT относится к периоду после начала смены: AggreGate добавляет событие IN в начале смены (т.е. Времени Отчета).

• AggreGate проверяет последнее событие владельца карты за тот день для того, чтобы убедиться, что это событие OUT (событие выхода). Если последнее событие за тот рабочий день - IN (событие входа) (это означает, что событие OUT отсутствует), AggreGate добавляет событие OUT согласно следующей логике:

- Если событие IN относится к периоду до окончания смены: AggreGate добавляет событие OUT в то же время, когда смена заканчивается (т.е. Время окончания работы).

- Если событие IN относится к периоду после конца смены: AggreGate добавляет событие OUT с отметкой времени как раз после события IN.

• AggreGate проверяет итоговое множество событий для того, чтобы удостовериться, что нет двух событий IN или OUT, следующих друг за другом.

Обратите внимание: правила в пунктах 3 и 4 действительны для любых двух последовательных событий IN или OUT. Т.е. если AggreGate обнаруживает  два примыкающих друг к другу события IN, в этом случае применяется правило 4; если он обнаруживает два примыкающих друг к другу события OUT,  применяется правило 3.

Обнаружение дневных правил для данной пары событий

Теперь у AggreGate есть нормализированная пара событий для обработки. Каждая пара событий IN/OUT отмечает период времени, который сотрудник провел на рабочем месте. Этот период может как входить в границы заданной смены, так и находиться вне этих границ.

AggreGate также знает, к какой смене привязан тот или иной сотрудник. Поэтому теперь ей нужно определить, какие правила существуют для определенного дня,  к которому относится пара событий.

для недельной смены

Для недельной смены алгоритм очень простой.

• Когда произошло событие?

• Дата определена как исключение? Если да, принимает ее правила. Если нет, двигается дальше и определяет...

• В какой день недели произошло событие?  

• Теперь мы знаем правила для переработки и ожидаемый график для этой даты (поскольку недельная смена определяет правило для каждого дня недели).

для обычной смены

Обычные смены всегда цикличны, поэтому определить, на какой день недели цикла выпадает пара событий, оказывается несколько сложнее. Давайте рассмотрим пример этой ситуации.

• Допустим, у нас трехдневная периодическая смена, дата начала которой 21 июля 2009.

• Пара событий, с которыми мы работаем, приходится на 17 октября 2009.

• Определена ли эта дата как исключение? Если да, принимаем ее правила. Если нет, двигаемся дальше.

• AggreGate подсчитывает разницу между датой начала и датой события. Это составляет 88 дней.

• Теперь AggreGate делит разницу дней (88) на количество дней в смене (3) и подсчитывает остаток. В этом случае он составляет 1.

• Теперь AggreGate берет остаток и прибавляет его к 1 потому, что если число ряда для первого дня смены 1, а не 0 (поэтому, если остаток равен 0, например,  правильный день - это день 1 смены). В нашем случае, результат будет 2. Таким образом, применяются правила для второго дня трехдневного цикла.

Подсчет рабочего времени и переработки

• Если время входит в рамки графика для определенного дня смены, оно считается нормальным рабочим временем. Это самый простой вариант.

• Когда время выходит за границы графика дня, AggreGate использует комплекс алгоритмов для того, чтобы решить, считать это время как переработку, обычное рабочее время или сбросить его. Существует несколько возможных случаев:

- Сотрудник находился на рабочем месте до начала смены.

- Сотрудник находился на рабочем месте во время обеденного перерыва.

- Сотрудник продолжал работать после окончания смены.

- Сотрудник находился на рабочем месте в официально нерабочий день.

3. У каждого из этих случаев есть соответствующая опция в свойствах смены. Если эта опция включена, AggreGate проверяет длительность переработки.

4. Теперь AggreGate подсчитывает общую длительность сверхурочного времени и проверяет, превышает ли она Минимальное время переработки. Если она меньше, чем Минимальное время переработки, переработке будет присвоено нулевое значение.

5. Теперь система суммирует все время по рабочему графику с переработкой и сравнивает результат с назначенной длительностью смены. Любое время, превышающее назначенное время для смены теперь считается переработкой - только то время, которое превышает итоговое рабочее время относительно итоговой длительности смены. Следовательно, задержка на рабочем месте на 30 минут " покрывает" 30-минутное опоздание и не учитывается как переработка.

пример

Допустим, у сотрудника Джоя рабочий график с 9:00 до 17:00. Джои опаздывает на работу в понедельник, приходит в 9:05. Он продолжает работать до 17:25, чтобы наверстать пропущенное время. В этом случае, Джои не присваивается сверхурочное время потому, что итоговая длительность его рабочего дня все равно составляет 8 часов.

У вас может появиться проблематичный сценарий: допустим, Вы устанавливаете Минимальное время переработки в 30 минут (не очень хорошая идея). В этом случае, если Джои приходит на работу в 9:25 и остается там до 17:25, система не будет считать эти 25 минут, потому что это меньше Минимального времени переработки. Это выглядело было так, что Джои просто пропустил 25 минут рабочего времени и не восполнил его (ему не оплатили те 25 минут, которые он провел после рабочего дня). Поэтому не следует устанавливать Минимальное время переработки больше 5 минут (или Минимальное время переработки на очень короткий промежуток времени).

Подсчет перерывов

Чтобы подсчитать время перерыва, AggreGate собирает все последовательности событий OUT-IN, укладывающиеся в рамки заданной смены. Он суммирует эти периоды, чтобы получить общее число всех перерывов.

Некоторые отчеты специально отражают время перерыва на обед (потому что время, когда сотрудник делает перерыв на обед устанавливается в свойствах Смены). Чтобы определить, какая пара событий OUT-IN в рамках смены обозначает перерыв на обед, AggreGate рассматривает значение настройки Обед рабочей смены:

• Все пары событий вход-выход рассматриваются как перерывы.

1. Если есть событие OUT между Часом начала обеда и Часом конца обеда, AggreGate принимает это на начало перерыва на обед (и следующее за ним событие  IN, как окончание перерыва на обед).  

2. Если такого события нет, AggreGate примет последнее событие OUT, которое предшествует часу обеда.

Если сотрудник решает пропустить обед и пообедать позднее (после того, как час обеда уже закончился) AggreGate посчитает это период перерывом, но не отметит в отчетах как "обеденный перерыв".

Взяв за занчение Продолжительности обеда N минут, первые N минут прерываний в работе в течение дня будут рассматриваться как обеденное время, остальные - условное время перерыва.

Суммируется время всех перерывов на обед с итоговым временем перерывов. Это означает, итоговое время перерывов за определенный день будет всегда включать время, потраченное на обеденный перерыв.

Если Вы не устанавливаете в свойствах смены Переработку в обеденный перерыв, сотрудники не смогут работать во время обеденного перерыва. Они могли бы остаться на рабочих местах и продолжить работу, но система не посчитает затраченное время рабочим или переработкой. Поэтому, если Джои решает поработать с 13:00-14:00 (в установленное обеденное время), а затем решит сделать перерыв с 14:30-15:30, система вычтет из его рабочего дня два часа: обеденное время (потому, что система не разрешала работать во время обеденного времени) и тот перерыв, который он решил сделать самостоятельно. Поэтому так важно настроить систему правильно!