In application version 6.6 the People Filter logic was revised. Additionally, while the change affects all of the filters, the most notable change can be seen when using the Roster Scheduled limits On-Duty, and Off-Duty. The method in which the application checks for person staffing records on the Roster using Scheduled > Off-Duty or On-Duty limits now returns all staffing records for a person first, and if needed merges work codes to determine total hours of working times in order to fully factor and determine a person’s working status.
Application Revision 1: Prior to version 6.6 the application queried each person and their roster record from the top down once. If the person was on the Roster more than once they would fail the second query because the application processed the top record only. The new logic returns all roster records first then runs the filter query for each person.
For example, suppose Charles is working Shift 1 and Shift 2, prior to the expanded logic Charles would fail the query for Shift 2, because the application would scan from the top down, see Charles on Shift 1 and ask, are you on Shift 2? False, Charles at that moment from the top down is on Shift 1 and the search would end. The people filter now returns all records for Charles first, Shift 1 and Shift 2, allowing him to pass both filter limits.
Application Revision 2 and 3: An extension of revision 1, where all roster records are now returned for the person before applying the filter limit can be seen when evaluating the working status of a person who has multiple records on the Roster. Prior to version 6.6 the application scanned the first record and determined whether or not the person passed or failed the On-Duty or Off-Duty criteria without considering any additional records.
For example, to be considered off-duty the person was simply put, not on the Roster at all or the person had a non-working code for the entire period being evaluated. Again, if a person had multiple records depending on the location and or duration of the first staffing record the person would pass or fail. The application now sorts and merges staffing records according to work code type and properties, and the duration of the work code or work codes relative to the vacancy times are evaluated in order to determine a person’s working status.
The target date means the date the staffing record shows on the Roster. When evaluating the Target Date there is no period; there is no time to evaluate only a date - and that date is precisely what the application will evaluate.
For example, suppose you run the people filter rule, Who is On-Duty for the Entire Period. Translation, Is the person on-duty during the vacancy’s datetime period? The vacancy to be filled runs from 12 PM - 4 PM. Charles is working overtime on that same day from 3 PM - 6 PM. Using this example, the rule returns TRUE because Charles is on-duty during that timeperiod.
When evaluating the target date, the application asks, Is there a working record on the roster for Charles, regardless of datetime? Simple but complicated...
The simple part of this concept is that if the staffing record does not appear on the roster then it is simply not there for the application to pull. The complicated part of evaluating the target date derives from negative or positive advanced shift configurations, used for example to show a shift on today’s calendar date that started the previous evening and crosses over the next day. Additionally, it is possible to have staffing records show on roster date with a different date association. These are edge cases, but nevertheless affect the interpretation of the Target Date’s expected results, so when things get blurry go to the Roster on that day, if the record is visible on the Roster the application sees it on that day otherwise it does not.
To simplify, the Target Date concept, think of the Roster as a bucket that captures records. The target date of a record is the date that record entered the bucket, the initial point of entry. Ask, which bucket is the record inside of? That’s your target date for that record.
When using the Target Date, the application evaluates people on the Roster for that date. The application tests as follows, TRUE means Pass, FALSE means Fail. For example, you are "On Duty on Target Date" if you have any Working or Regular Duty type records (literally).
For example, suppose you have a working type record AND a non- working type record on the roster:
| Work Code Type | Work Code Type | Outcome | Description |
|---|---|---|---|
| Working | Regular Duty | Pass | Person passes ON-DUTY filter because they have two working type records. |
| Working | Working | Pass | Person passes ON-DUTY filter because they have two working type records. |
| None | None | Fail | Person fails ON-DUTY filter because they don’t have any records indicating that they are working. |
| Non-Working | None | Fail | Person fails ON-DUTY filter because they have a non-working code. |
| Working | Non-Working | Pass | Person passes ON-DUTY filter because they are working on that Roster date. This person also passes the off-duty rule because they have a non-working code as well. |
| Work Code Type | Work Code Type | Outcome | Description |
|---|---|---|---|
| Working | Regular Duty | Fail | Person fails OFF-DUTY filter because they have two working type records. |
| Working | Working | Fail | Person fails OFF-DUTY filter because they have two working type records. |
| None | None | Pass | Person passes OFF-DUTY filter because they don’t have any records indicating that they are working. |
| Non-Working | None | Pass | Person passes OFF-DUTY filter because they have a non-working code. |
| Working | Non-Working | Pass | Person passes OFF-DUTY filter because they have a non-working code on that Roster date. This person also passes the on-duty rule because they have a working code as well. |
| Use Case | On-Duty | Off-Duty | On Roster |
|---|---|---|---|
| Person does not appear on the Roster. | Fail | Pass | Fail |
| Person has a regular duty type work code. | Pass | Fail | Pass |
| Person has a non-working type work code. | Fail | Pass | Pass |
| *Person has a non-working type work code with But Still Available. | Fail | Pass | Fail |
| *Person has a working type work code with But Still Available. | Fail | Pass | Fail |
| Person has a non-working Charge work code and a Regular Duty unchecked record. | Pass | Fail | Pass |
| Person has a non-working Charge work code on their day off. | Fail | Pass | Fail |
| Person has a working Charge work code and a Regular Duty unchecked record. | Pass | Fail | Pass |
| Person has a working Charge work code on their day off. | Fail | Pass | Fail |
| Person has a non-working Hidden work code and a Regular Duty unchecked record. | Pass | Fail | Pass |
| Person has a non-working Hidden work code on their day off. | Fail | Pass | Fail |
| Person has a working Hidden work code and a Regular Duty unchecked record. | Pass | Fail | Fail |
| Person has a working Hidden work code on their day off. | Fail | Pass | Fail |
*BUT STILL AVAILABLE Logic
In the application’s code in the context of the People Filter, the work code property ‘But Still Available’ does not mean ‘Still Available’, it means ‘Ignore this Record’ - this record does not exist.