This page (revision-5) was last changed on 26-Nov-2021 10:22 by JEscott

This page was created on 26-Nov-2021 10:22 by JMyers

Only authorized users are allowed to rename pages.

Only authorized users are allowed to delete pages.

Page revision history

Version Date Modified Size Author Changes ... Change note
5 26-Nov-2021 10:22 1 KB JEscott to previous
4 26-Nov-2021 10:22 3 KB JEscott to previous | to last
3 26-Nov-2021 10:22 4 KB JMyers to previous | to last
2 26-Nov-2021 10:22 4 KB JMyers to previous | to last
1 26-Nov-2021 10:22 4 KB JMyers to last

Page References

Incoming links Outgoing links

Version management

Difference between version and

At line 3 changed one line
The concept of time rules is similar to that of User Calculations; however time rules are more powerful and more audible than UserCalcs. They have access to transactional data by date and by start/end times where as a UserCalc can only look at what is stored in a pay component at a pay line by pay line basis.
The concept of time rules is similar to that of User Calculations; however time rules are more powerful and more audible than user calcs. They have access to transactional data by date and by start/end times where as a user calc can only look at what is stored in a pay component at a pay line by pay line basis.
At line 7 changed one line
Time rules are audible; a user can see when the time rules were applied, what the original transaction was and what the end results are after the time rule has been fired.
Time Rules are audible; a user can see when the time rules were applied, what the original transaction was and what the end results are after the time rule has been fired.
At line 18 changed one line
Time rules can be setup in a simplistic or complex manner. The more complex the time rule is the more difficult it will be to troubleshoot the time rule. They must be set up with care and with the following considerations in mind:
Time Rules can be setup in a simplistic or complex manner. The more complex the time rule is the more difficult it will be to troubleshoot the time rule. They must be set up with care and with the following considerations in mind:
At line 24 added 12 lines
!!Basic Configurations of a Time Rule
*Frequency
**Describes how and when the time rule is used by the system
**Existing frequencies are:
***Never - used by the system or other time rules
****Used to default in values into a Time Sheet when the Time Sheet is generated
***Every - called by the time rule engine after changes are saved to a time sheet
****Entry
****Shift
****Day
****Week
****Period
At line 37 added 2 lines
*Band
**Used as a threshold, for example used to hold a minimum number of hours before the employee qualifies for Overtime.
At line 40 added 4 lines
*Value
**May be used as a variable or fixed amount
**The context in which this column is used may change depending on the time rule type
***For example, for the time rule Daily Top Up, the column name for Value changes to Max Top Up Hrs since it holds the number of hours to top up to. The time rule, OT Consecutive, uses the Value to hold the number of consecutive days worked.
At line 27 changed 3 lines
----
![Notes|Edit:Internal.TIME_RULES_OVERVIEW]
[{InsertPage page='Internal.TIME_RULES_OVERVIEW' default='Click to create a new notes page'}]
*Day Of Week
Allows for filtering of Daily and Never time rules
Allows for definition of first day of week for weekly time rules
From/To times
Allows for filtering of Daily and Never time rules
Time Code/Premium
Most time rules use these to put the qualifying time into them
Some time rules use them as a filter
Action
Tells the Time Rule Engine how to apply to the time rule
Add or Replace
Targeted Time Code Sets
Determines what types of time (set of time codes) should qualify for the rule
Replaces the use of the toggles for the time codes listed on the Time Code tab in IDWR
Disabled
Can be used to help debug time rules
Trace
Controls the level of messaging that the server logs in the OC4J default log file
6-Internal Level is more than enough
IMST server trace might also need to be switched on for added tracing
Banding Time Rules
Rules of the same type can be combined to complement one another
Must share the same targeted/apply to time code set, start/end times and day of the week
Only rules that use the band as a threshold can support this
Most commonly used for OT DAILY and OT WEEKLY
For example: OT DAILY is banded twice; first band is for 8 hours where the employee would receive OT 1.5 for hours worked after 8 hr reg time, the second band is for 12 hours where the employee would receive OT 2.0 for hours worked after 12 hrs reg time.
Advanced Configurations of a Time Rule
The following list of optional configurations allows the administrator to make a time rule more powerful and advanced.
Apply Time Code Sets
Usually a subset of the Targeted Time Code Set
Most commonly used in Daily or Weekly time rules
For example: Vacation time may contribute as hours towards OT WEEKLY but may not be paid out as Overtime. The OT WEEKLY would 'target' the vacation hours in the Target Time Code Set, but would exclude the vacation time code from its Apply Time Code Set
Can Be Waived
Allows the user to flag that a time rule should not be applied
Allows the user to turn on a currently disable time rule
Time Rule Sequence
Used when the default ordering is not getting the desired results
Used to change the order of time rules within the same frequency
Most common when layering the same time code types
Specifying the Cycle
Standard cycle is every Entry > Shift > Day > Week > Period
The default cycle is 5
May be used to change the order of time rules of different frequencies.
For example, override the cycle of OT Weekly to be 1 so that it will come before OT Daily