Remote Attendance Welfare System
As noted in the introductory to RAWS, there are at least 4 levels at which you may instantiate a shift to be monitored by the RAWS queues processes. Therefore it's quite reasonable that the logic to manage the flexibility and various options might be complicated. This document walks through the programming logic used to manage the shifts onto the queues.
Top of Page
The Logic Flow
The first check to qualify a shift is to confirm whether the company the operator has signed into has time and attendance (T&A) selected at the company control level. If T&A is not set at the company level, no further processing takes place, and the shift does not appear on the RAWS queue. This check is completed only once the scheduling code has been confirmed to be monitored through RAWS. (i.e RAWS does not monitor sick leave scheduling codes (though you could)).
The logic structure is looking for overides at the following levels. It starts at the lowest level and works its way upwards, stopping only when a configuration setting is found.
* Any processing at all only happens if the company control record has T&A set to Active
IF r_Company<Cmp_TNA_Active> THEN
* 1st place we look is to see if THIS shift has overrides. This is the lowest level where you may configure an
* overide for RAWS. At every level, the control test is IF <OVERRIDE_SETTINGS> designated by the code
* commencing with the term"CASE", otherwise the logic ignores
anything else that may be ticked.
If the logic stops at a particular level, the level itself is check whether the TNA is active at this level,
therefore you must both override and select T&A Active at the level where you wish to establish RAWS
RetVal<TNA_Active$> = r_Rtc<RTIM_TNA_Active>
RetVal<TNA_Welfare_Checks_Active$> = r_Rtc<RTIM_TNA_Welfare_Checks_Active>
* Nothing on the shift we're looking at, so pop upwards, 2nd level is the Client Std Schedule definition
RetVal<TNA_Active$> = r_Std_Sched<CSS_TNA_Active$>
RetVal<TNA_Welfare_Checks_Active$> = r_Std_Sched<CSS_TNA_Welfare_Checks_Active$>
* Nothing at actual shift level, nothing at Client Std Schedule. 3rd level is the Client control record.
Does this client have settings?
RetVal<TNA_Active$> = r_Site<Cc_TNA_Active>
RetVal<TNA_Welfare_Checks_Active$> = r_Site<Cc_TNA_Welfare_Checks_Active>
* Nothing at actual shift level, nothing at Client Std Schedule, Client control record. We pop one level to
the clients, master (if client has master) Note, that this pops only 1 level above client where the shift is set.
RetVal<TNA_Active$> = r_MClient<Cc_TNA_Active>
RetVal<TNA_Welfare_Checks_Active$> = r_MClient<Cc_TNA_Welfare_Checks_Active>
* Nothing is set anywhere, we're about to default at the company level. We've established that there's
something at the company level by virute of getting past the 1st IF in this logic.
RetVal<TNA_Active$> = r_Company<Cmp_TNA_Active>
RetVal<TNA_Welfare_Checks_Active$> = r_Company<Cmp_TNA_Welfare_Checks_Active>
* We've struck out, so just return a .NULL. This shift will not appear on the RAWS monitor queues
* One final check is to verify just in case the setup has no value of the Welfare Check interval, we'll default to
every 1 hour (3600 seconds). If there's a welfare start time & and a welfare end time, and the welfare interval
is not set then, default it
The control logic walks its way through each of the layers of configuration looking for an override to the RAWS processing. If none are found at the various lower levels the configuration settings as defined for the overal company processing are used as the default.
RAWS - Add Client
RAWS - Configuration
RAWS - Launch Process
RAWS - Monitor Queues
RAWS - Monitor Queue Hierarchy
RAWS - Overview
Top of Page