The Timecard Check feature allows the system to check the timecard for hours exceptions when the employee or supervisor attempts to sign a day, week, or period. Hours exceptions include:
Underreported hours (reported hours are less than the scheduled hours)
Overreported hours (reported hours are more than the scheduled hours)
Hours posted on an unscheduled day
Unsigned timecards in previous pay periods
Transactions that are missing required codes (SCA/DBA, rework, etc.)
The hours exceptions are defined in a Timecard Check Ruleset, which is added to a Sign Policy.
The Timecard Check Ruleset is executed when an employee or supervisor signs the timecard. It will not be executed when the ATTENDANCE service signs a timecard. If any hours exceptions are found, a pop-up form will display listing these exceptions. If at least one of the hours exceptions is an Error, the timecard will not be signed. The error must be corrected before the user can sign the timecard again. If the hours exceptions are only Warnings, the timecard will be signed. The error/warning message is defined in the Timecard Check Rule.
The Timecard Check Ruleset in a person's Sign Policy will check for hours exceptions when a timecard is signed in the web timecard, Mobile Client, or Mobile Web Application.
When determining a person’s Scheduled Hours, the system will only consider the person’s Normal schedule, not any Optional schedules. The Timecard Check Ruleset will define which of these Scheduled Hours should be considered. These “qualified hours” can be paid, unpaid, or have a specific hours classification.
The Timecard Check Ruleset can be configured to check for hours exceptions on individual days, in a week, or in a pay period. For example, you may want a rule to check that the employee posted 80 hours in the pay period or you may want a rule to check that the employee posted 8 hours each day.
See Also:
Configuring the Timecard Check Feature
Using the Timecard Check Feature
Timecard Check for Missing Codes
To use this feature, you must define your Timecard Check Rulesets and assign them to the appropriate Sign Policies.
The Timecard Check rules determine which hours exceptions will be checked when the timecard is signed. You can create separate rulesets for employee and supervisor signings.
The Timecard Check Rules Operand topic explains the various operands that are used to make these rules. The ruleset shown below gives examples of some of these rules.
Example Ruleset (Employee TC Check)
Hours Overreported by Day
This rule executes only when the Sign Period button is clicked (as indicated by the Is Signing By operand). It checks each day in the period for overreported hours (reported hours that are greater than the scheduled hours). It looks at paid and unpaid hours with the R, O, D, A, and U hours classes. If this type of hours exception is found, an error displays and the timecard will not be signed.
The Set Error operand displays the text of the error message. See “Define the Error/Warning Message (Semantics)” below.
IF:
Is Signing By (Period)
And
Is Hours Overreported By Hours Class (All, Get Qualified Hours Classes
(R, O, D, A, U), Each Day)
THEN:
Set Error (Error, Overreported Hours by [%PERSON_NAME%] ([%PERSON_NUM%])
on [%POST_DATE%] - Scheduled Hours: [%SCHEDULED_HOURS%], Reported Hours:
[%REPORTED_HOURS%]., False)
Hours Underreported by Period
This rule is similar to Hours Overreported by Day except that it checks for underreported hours (reported hours that are less than the scheduled hours). It also checks the entire pay period instead of each day. If this type of hours exception is found, an error displays and the timecard will not be signed.
IF:
Is Signing By (Period)
And
Is Hours Underreported By Hours Class (All, Get Qualified Hours Classes
(R, O, D, A, U), Period)
THEN:
Set Error (Error, Underreported hours by [%PERSON_NAME%] ([%PERSON_NUM%])
from [%START_DATE%] to [%END_DATE%]. Scheduled Hours: [%SCHEDULED_HOURS%],
Reported Hours: [%REPORTED_HOURS%]., False)
Hours Posted on Unscheduled Day
This rule displays an error if the person has paid or unpaid hours on an unscheduled day. It also stores the error in the Error Log form.
IF:
Is Signing By (Period)
And
Is Hours Posted On Unscheduled Day (All)
THEN:
Set Error (Error, [%PERSON_NAME%] ([%PERSON_NUM%]) has posted hours on
an unscheduled day ([%POST_DATE%], [%REPORTED_HOURS%] hours)., True)
Is Unsigned Period in the Past
This rule checks the two pay periods prior to the one being signed for any unsigned days. If these periods are unsigned, a warning will be displayed. The timecard will be signed provided there are no other hours exceptions of type Error.
IF:
Is Signing By (Period)
And
Is Unsigned Timecard In Past (Period, Employee or Supervisor, 2)
THEN:
Set Error (Warning, [%PERSON_NAME%] ([%PERSON_NUM%]) has one or more unsigned
pay periods in the last 2 pay periods., False)
The Set Error operand is where you define the error or warning message that is displayed for the hours exception. You can specify the person, post date, type of hours, and other values in the error message using semantics. A full list of these semantics is included in the description of the Set Error operand.
For example, an error message that is displayed in the rule as:
Overreported hours by [%PERSON_NAME%] ([%PERSON_NUM%]) on [%POST_DATE%] - Scheduled Hours: [%SCHEDULED_HOURS%], Reported Hours: [%REPORTED_HOURS%].
Will appear to the user as:
Overreported hours by Joe Smith (1101) on 09/15/2015 - Scheduled Hours: 8.0, Reported Hours: 8.5.
After you define your Timecard Check Ruleset, you need to assign it to your Sign Policy.
A Sign Policy has an EMPLOYEE category and a SUPERVISOR category. You can assign different rulesets to each one if you want to execute different Timecard Check Rules when employees and supervisors sign timecards.
Click Main Menu > Configuration > Policies > Sign Policy.
Select the Sign Policy Name from the filter field at the top of the form.
Select a Sign Category and click Modify.
In the Sign Check Ruleset field, select the Timecard Check Ruleset you defined earlier and click Save.
When a supervisor or employee clicks the Sign Day, Sign Week, or Sign Period button in the timecard, the Sign Check Ruleset in the person’s Sign Policy is executed. If you have selected multiple employees in the Current Situation or Time Card Review form, each employee will be checked separately.
The Sign Check Ruleset will check the day, week, or pay period being signed for any hours exceptions.
If no exceptions are found, the timecards will be signed.
If any exceptions are found, the Time Card Check pop-up form appears.
This form identifies which employees have hours exceptions, whether the exception is an error or a warning; and a description of the hours exception. The Rule Name field identifies the rule that checked for this exception.
If at least one of the items is Violation Type ERROR, then the timecard will not be signed. The Is Signed column will display red X’s. You can correct these problems and try to sign the timecard again.
If the Time Card Check pop-up form only displays
items with the Violation Type WARNING, the timecard will
be signed. The Is Signed
column will display green checkmarks 
.
If the hours exception rule had Log Violation set to True in the Set Error operand, you will be able to view the error or warning on the Error Log form. On the Error Log form, the Time Card Check errors will display the Error Code 11682 and the Description column will display the actual error message.
You can control which columns appear in the Time Card Check pop-up form by configuring them in your Form Profile.
You can filter the records on this form by Employee and/or Violation Type. Use the Employee field to search for employees by their First Name, Last Name, Employee Number, or Login Name. For example, to find Person Number 1101 named Jane Doe who has Login Name JDOE001, you can enter 1101, Jane, Doe, or JDOE001 in the Employee field. You can also use the * or % wildcard symbol anywhere in your search value to represent unknown characters in a First Name, Last Name, Login Name, or Employee Number.
You can create Timecard Check Rules that check transactions for missing codes, such as SCA/DBA and Rework Codes. The rule can be used to prevent the timecard from being signed when such codes are missing.
There are two Timecard Check Rule operands that are designed to check for missing codes:
Is Any Missing Tx Map Value That Is Req
Is Transaction Map Value Missing
The Is Any Missing Tx Map Value That Is Req operand checks all the transactions in the day, week, or period that is being signed to see if any transactions require an SCA/DBA code. The operand’s parameters define the trans_action_map field that specifies whether an SCA/DBA code is required, and the trans_action_map field that holds the SCA/DBA code. SCA refers to the Service Contract Act and DBA refers to the Davis-Bacon Act – two federal laws that establish wage regulations for contractors.
This operand can be used as part of a rule that prevents timecards from being signed if an SCA/DBA code is missing.
The Is Any Missing Tx Map Value That Is Req operand has three parameters: Required Field, Required Value, and Custom Field. The Required Field and Required Value determine whether a value is required in the Custom Field.
Example:
IF Is Any Missing Tx Map Value
That Is Req (Flex Field 1, Y, Charge Element Value 3)
THEN Set Error (Error, [%PERSON_NAME%] ([%PERSON_NUM%]) has a transaction
that is missing the code SCADBA001 on the following date: [%POST_DATE%],
False)
This rule checks each transaction to see if the field called Flex Field 1 in the trans_action_map table has a value of Y, indicating that the transaction requires an SCA/DBA code. The operand also checks to see if there is a value in the Charge Element Value 3 field in the trans_action_map table, which is the field that has the SCA/DBA code. If the Charge Element Value 3 field is empty, and Flex Field 1 is set to Y, an error appears at signing.
The labor event will need to be configured so that the prompt indicating the code is required and the prompt with the SCA/DBA code both map to the correct fields in the trans_action_map table.
The Is Transaction Map Value Missing operand checks all the transactions in the day, week, or period that is being signed to see if any transactions have a missing trans_action_map value and that two other configured fields are set to specific values.
This operand can be used as part of a rule that prevents timecards from being signed if a code, such as a Rework Code, is missing from a transaction and there are other field values that indicate the code is required.
The Is Transaction Map Value Missing operand has six parameters that define where to check for the missing code and which charge_element_flex_field and trans_action_map fields need to have specific values:
Is Transaction Map Value Missing( Required Field, Field Containing Element Id, Charge Elem Flex Field, Trans Action Map Field, Charge Elem Flex Field Value To Test, Trans Action Map Field Value To Test, Include Zero Hour Transactions)
See Timecard Check Rules Operands and the example below for more information on these parameters.
The example below shows how the parameters in this operand are used in a rule to prevent timecards from being signed when a transaction for a charge element that is 100% complete has a missing Rework Code.
A company requires that charge elements with 100% completion must have a Rework Code. If a transaction has no Rework Code and has 100% completion, a Timecard Check rule will prevent the timecard from being signed.
When the supervisor signs Debbie Stone's timecard, the following error appears: Rework Code is missing for Debbie Stone 1101 posted on 03/29/2019: (event Work Order_RW, /F_ORDER_NUM/F_OPERATION_NUM/F_ACTIVITY_NUM, /3000/10/10.
The following Timecard Check rule generated the error:
IF Is Transaction Map Value
Missing (Flex Field 4, ORDER, Flex Field Value 5, Charge Element Value
5, 100, 100, False)
THEN Set Error (Error, Rework Code is missing for [%PERSON_NAME%] [%PERSON_NUM%]
posted on [%POST_DATE%]: (event [%EVENT_LABEL%], [%KEY_NAME%], [%KEY_VALUE%]).,
True)
Debbie's supervisor finds the Work Order_RW event on 03/29/2019 and modifies it.
The supervisor can see the Rework Code is missing because the prompt is blank.
The event has been configured so the Rework Code is mapped to Flex Field 4 (trans_action_map.flex4). The Is Transaction Map Value Missing operand is looking at Flex Field 4 (the first parameter in the rule – Required Field) to find the Rework Code.
The operand is also checking to see if the charge element to which the labor is being posted is fully complete. To do so, the operand uses the second parameter (the Field Containing Element Id parameter) to look up the transaction's charge_element_id in the charge_element_flex_field table. The Field Containing Element Id parameter tells the operand which ID field in the trans_action_data table will have the correct charge_element_id. In this case, the Field Containing Element Id parameter is set to ORDER, so the operand will look at the order_id field in the trans_action_data table. This order_id will be matched to a charge_element_id in the charge_element_flex_field table.
Once the record with the correct charge_element_id has been found in the charge_element_flex_field table, the third parameter (Charge Elem Flex Field parameter) indicates which Flex Field in the charge_element_flex_field table needs to be checked. In this example, the field to check is Flex Field Value 5 (charge_element_flex_field.flex_field_value5). This field will be checked for the value specified in the fifth parameter (the Charge Elem Flex Field Value To Test parameter).
Next the operand checks for the fourth parameter, Trans Action Map Field. This parameter is set to Charge Element Value 5, so the operand checks the trans_action_map.charge_element_value5 field for the transaction. This field will be checked for the value of the sixth parameter, Trans Action Map Field Value To Test (which is set to 100 in this example). The value of the event's Fully Complete prompt (100, in this example) is mapped to this field.
The Is Transaction Map Value Missing operand in this example is True because the transaction's Required Field (Flex Field 4) is missing the Rework Code; the charge element's Flex Field Value 5 is 100 (indicating 100% completion); and the transaction's Charge Element Value 5 is 100 (also indicating 100% completion). Once the operand is determined to be true, the error displays.
To resolve the error and sign the timecard, the supervisor in this example will have to modify the event, selecting an option for the Rework Code prompt. Once the event is no longer missing a Rework Code, the supervisor will be able to sign the timecard.