PT120 CT120 Database Schema Essentials: Training Manual
PT120 CT120 Database Schema Essentials: Training Manual
Training Manual
WorkForce Time and Attendance
LEGAL NOTICES
Copyright © 2018
WorkForce Software, LLC
All Rights Reserved.
WorkForce Software
38705 Seven Mile Road
Livonia, MI 48152
United States
workforcesoftware.com
[email protected]
+1 877 493 6723
Copyright and trade secret laws protect the information in this manual. Access to this material is provided only under license or
as part of an evaluation of the WorkForce Software, LLC solution specifically authorized by WorkForce Software, LLC. In no
other case are you permitted access to this information. Nor are you permitted to disclose this information to any third party. If
you have been provided this manual under any other circumstances, you must contact WorkForce Software, LLC at +1 877 493
6723 to arrange to have this material returned immediately.
This document was last updated on January 4, 2019.
Version 17.3
Table of Contents
Table of Contents .................................................................................................................................... 5
Formats & Conventions ......................................................................................................................... 10
How to Contact Us............................................................................................................................. 11
Database Schema .................................................................................................................................. 12
1. Database Structure ........................................................................................................................ 13
Overall Database Structure ............................................................................................................ 13
Using the Data Dictionary .............................................................................................................. 15
Standard Data Model ..................................................................................................................... 16
Structured Query Language ........................................................................................................... 18
Relational Databases...................................................................................................................... 19
How to Use the Relationship Graphs: ............................................................................................. 19
Audit Table Structure ..................................................................................................................... 21
2. Employee and Assignment Tables and Views ................................................................................. 22
Effective Dating Methodology........................................................................................................ 23
Employee to Assignment Relationship ........................................................................................... 28
Employee and Assignment Table and View Relationships ............................................................... 31
Tables and Views Related to Employees......................................................................................... 32
Tables and Views Related to Assignment ....................................................................................... 36
Lesson 2 Exercises.......................................................................................................................... 41
Lesson 2 Review............................................................................................................................. 42
3. Pay Period Tables........................................................................................................................... 43
Pay Period Versioning .................................................................................................................... 44
Tables Related to Pay Period.......................................................................................................... 47
Lesson 3 Exercises.......................................................................................................................... 50
Lesson 3 Review............................................................................................................................. 51
4. Timesheet Tables and Views .......................................................................................................... 52
Amended Timesheets .................................................................................................................... 53
EPV, Calc EPV and Last EPV ............................................................................................................ 56
Course Information
Course Purpose: This course is an introduction to Database Schema. This course does
not cover all the tables in the database. This course provides a
foundation to database schema and builds upon that foundational
knowledge.
Duration: 3 virtual sessions, 4 hours in length
Target Audience: Existing WorkForce users, employees and partners who are
responsible for creating new customized reports or modifying existing
WorkForce reports.
Prerequisites: Experience with Microsoft SQL query-writing or Oracle SQL query-
writing, Microsoft Access databases or other experience with
database architecture and relationships.
WorkForce uses DB Visualizer. Students can use any query tool that
they are familiar with. The free version of DB Visualizer does not
include IntelliSense.
System Information: WorkForce Time & Attendance version 18.2 is used.
Practice
Let’s Practice:
Using the information provided in this lesson, please complete Exercise X-X
(Lesson # - Exercise #).
Example
For Example:
A relative example of use or method can be displayed here.
Notes
Notes:
Special notes related to the topic.
Tips
Best Practices Tips:
Information about best practices when using your software.
Italic Text: Any text in Italics indicates a reference to another topic, lesson, or guide.
Bold Blue Text: Any text that is Bold & Blue details the steps to open an WorkForce screen.
How to Contact Us
Phone Support North America: +1 877 493 6723
Customer Support Portal:
o WorkForce Suite: https://workforcesoftware.force.com/customers/login
o WorkForce Forecasting and Scheduling: http://support.workplacesystems.com/
Website: http://workforcesoftware.com
Database Schema
This module includes the following key sections:
1. Database Structure
2. Employee and Assignment Tables
3. Pay Period Tables
4. Timesheet Tables and Views
5. Accrual Management Tables
6. Schedule Table and View
7. Data Collection Devices Tables
8. Helpful System Tables and View Index
Note:
For a refresher/introduction into SQL writing basics please review Appendix A.
1. Database Structure
This lesson includes the following key sections:
• Overall Database Structure
• Using the Data Dictionary
• Standard Data Model
• Audit Table Structure
There are no primary key and foreign key constraints defined in the database to
maintain scalability. The primary key constraint is implemented through unique
indexes and foreign key constraints are managed by the application. The primary
key and foreign key relationships will be defined in the lessons that follow.
Every table and Standard Data Model view in the database has the following system columns:
Every policy table in the database has the following system columns:
The landing page of the Data Dictionary lists all the tables and Standard Data Model views in alphabetical order.
After selecting the table or view name, each available column displays.
A library of standard fields is available with templates and you can define your own fields to be
used in configuration. A data element policy is used to create a named user defined field. For
example, “Project” can be defined as an LD field on an employee record. System generated
documentation is available for all named fields defined in an implementation and is accessible
from the WorkForce Software Documentation page.
The landing page of the Standard Data Model API lists the aliases in alphabetical order and can be filtered.
Relational Databases
A relational database management system is a one that is based on a relational model. Most popular
commercial and open source databases use this methodology. A relational database presents the data
to the user as “relations,” most commonly as a collection of tables and within those tables are columns
and rows of data.
A relational database also strives to achieve “normalization of data.” Normalization is a systematic way
of ensuring that a database structure is suitable for general purpose querying and is free of undesirable
characteristics that could lead to loss of data integrity.
One of the ways normalization might be achieved is by implementing primary keys. A primary key is a
single unique identifier for data in a table. For example, the EMPLOYEE column in the
EMPLOYEE_MASTER table in WT&A is a primary key that represents an employee that has been
imported into the database. In other tables, when EMPLOYEE is an existing column (such as in the
EMPLOYEE table), it is a foreign key, meaning that it is a referential constraint between the two tables.
In essence, because the key exists in both tables, it can be used as a means of connecting them to gather
information. The relationship has the following graphical representation:
EMPLOYEE_
MASTER Legend
1 to 1 or Many
1 to 0, 1 or Many
EMPLOYEE
1 or Many to 0, 1 or Many
1 or Many to 1 or Many
EMPLOYEE
The description of key fields for the tables/views, are in subsequent tables listed beneath each graph for
each section. A complete list of just the relationship graphs is also available in Appendix C for
convenience.
The AUDIT_OPERATION table contains a row which corresponds to each record in an audit
table. This table contains the foreign key TRANSACTION_ID which links to the AUDIT_MASTER
table. The AUDIT_MASTER table stores information related to the “who” and “when” of each
audit record.
Not every table is automatically set up to be audited. There is a list of automatically audited
tables and if you wish for any table to be added or removed from that audit list or create a new
list for auditing it can be done in the Policy Editor under All Policies > Policy Records > Setup >
Audit Tables. Please refer to the WorkForce Time and Attendance Installation and
Administration Guide for more information.
These values change whenever an attribute of the record changes either during an import or by
manual update through the application. The previous record is not deleted; rather a new record
with new effective dates is created. An example of a change that would incur a new record
might be a name change:
In this example, a new record was created when Betty Allen changed her name on 05/01/2009
and the old record was given a new end effective date. There should never be an overlap or a
gap between the END_EFF_DT on the old record and the EFF_DT on the new record.
Assignment Status
Assignment record status fields:
Types of termination:
Soft termination
o Employee has left the position.
o Timesheet remains active for system-defined period.
o Allows administrators to make retroactive changes as needed (for example, to correct
leave balances) without having to rehire the employee.
Hard termination
o Occurs after system-specified period of time (for example, 90 days).
o Handled via a schedule script
o No further retroactive changes allowed.
Any date or date/time column can be placed between eff_dt and end_eff_dt in
order to obtain one record per employee or assignment. The most common uses
just happen to all have the same column name.
Notes:
Adding “+1” after the end_eff_dt is necessary whenever comparing a date with a
timestamp to the effective dates, such as when using getdate() or sysdate.
Notice above that the “+1” is included when comparing getdate() and sysdate, but
it is not necessary when comparing {?CURRENT_DATE_SQL} or work_dt
Single Assignment
• This is the most common employee-to-assignment relationship. In a single assignment
configuration, each employee has only one assignment. This means that for every
EMPLOYEE, one and only one ASGNMT exists.
• The assignment changes over time as the employee’s job or employment status changes.
Multiple Assignments
• Each employee has one assignment per job they perform (“component”), plus an
additional “aggregate” assignment.
• Aggregate plus one or more components can be active at a given time.
• New assignments are created and terminated as the employee takes on different
positions.
• Timesheet calculations (for example, overtime premiums) encompass time worked on
all assignments.
• Typical use case: a school may employee a person as a bus driver and a cafeteria worker
concurrently. A multiple assignment configuration may be necessary if the employee
works for one employer, but two different managers. A classic example of this might be
a university student who works at several places on campus:
Student
Split Assignments
• An employee may have more than one assignment.
• Only one assignment is active at any given time. Assignments do not overlap.
• Assignment splits when employee moves from one job to another where some aspect of
one job is not compatible with the other (for example, from a policy profile with a
Monday-Sunday pay period to one with a Sunday-Saturday pay period).
For More Information: See Understanding Multiple Assignments: Key Concepts in the Policy
Configuration Guide.
In this example, the Student is only receiving one paycheck from the Employer, but has three different
managers who need to review and approve their timesheets. The student would be given three different
ASGNMT keys in the application, one for each timesheet/manager combination. Those ASGNMT keys
would relate to an AGGREGATE_ASGNMT which would figure in the calculations of the entire paycheck.
EMPLOYEE_ EMPLOYEE_
PHOTO_ID
MASTER PHOTO
EMPLOYEE
EMPLOYEE
EMPLOYEE
ASGNMT_
MASTER
ASGNMT
ASGNMT
ASGNMT
ASGNMT_GR
P_
DETAIL
ASGNMT_GRP
ASGNMT_GR
P
EMPLOYEE_PHOTO
A transactional table which stores photos for employees.
EMPLOYEE
If the WorkForce Time and Attendance application uses a “multiple assignment” configuration,
then it is most likely that these attributes will be stored at the assignment level instead of the
employee level. In many cases, whether a column is populated with data depends on the type
of employee import used and the information passed to WorkForce Time and Attendance
through that import, e.g., SuccessFactors.
* A set of columns only available in the Employee view when Compatibility Mode is enabled for
backward compatibility with configurations created prior to the introduction of the Standard
Data Model.
ASGNMT
This view includes all assignment level information. In many cases, whether a column is
populated with data depends on the type of employee import used and the information passed
to WorkForce Time and Attendance through that import, e.g., SuccessFactors.
There are many of the same columns in EMPLOYEE and ASGNMT. This section
highlights the different columns that can be found in ASGNMT followed by the
common columns. Employee attributes are usually included in one view or the
other, not in both, depending on the type of configuration.
* A set of columns only available in the view when Compatibility Mode is enabled for backward
compatibility with configurations created prior to the introduction of the Standard Data Model.
ASGNMT_GRP_DETAIL
This table defines which assignments are in which assignment groups. An assignment can
belong to more than one assignment group.
ASGNMT_GRP
A view of the definition table for each of the assignment groups in the application.
Lesson 2 Exercises
Let’s Practice
Exercise 1: Query Writing – Employee Contact Information
Design a query that will return the following information for all employees:
• Employee ID
• Employee Name (First & Last)
• Employee Address
• Employee City
• Employee State
• Employee Postal Code
• Employee Phone Number
• Employee Email Address
Let’s Practice
Exercise 2: Query Writing – Assignment Group Detail
Design a query that will return the following columns to display a list
of all assignment groups and their members:
• Assignment Group Description
• Assignment Description (multiple assignment configurations only)
• Employee ID
• Employee Name (First & Last)
Lesson 2 Review
1. What is the primary function of the EMPLOYEE_MASTER table?
2. What is the default EFF_DT and END_EFF_DT assigned to each employee record that uses effective
dating?
5. True or False: If Manager A is signed into the application, they automatically have access to approve
timesheets for Manager B.
Sequence of Events
1. Pay Period is Created VERSION_NUMBER = 0
2. Pay Period is Closed VERSION_NUMBER = 1
3. Pay Period is Re-Opened1 VERSION_NUMBER = 0
4. Pay Period is Re-Closed VERSION_NUMBER = 2
5. Pay Period is Re-Opened1 VERSION_NUMBER = 0
6. Pay Period is Re-Closed VERSION_NUMBER = 3
1
When the Pay Period is re-opened, a new EMPLOYEE_PERIOD_VERSION key is generated for the same
EMPLOYEE_PERIOD and the PRIOR_EMP_PERIOD_VERSION is populated with the old
EMPLOYEE_PERIOD_VERSION. The original EMPLOYEE_PERIOD_VERSION for an EMPLOYEE_PERIOD will always
have a VERSION_NUMBER = 1 when it is closed.
EMPLOYEE
EMPLOYEE
V_ASGNMT_
PERIODS
EMPLOYEE_PERIOD_VERSION
SCHEDULE_
BANK_OUTP
TIME_SHEET_ TIME_SHEET_ GENERATION SCHEDULE_
UT_
DETAIL OUTPUT _ DETAIL
SUMMARY
DTL
Relationships to EMPLOYEE_PERIOD_VERSION key.
It is important to query data based on this key because amendments are possible for each pay
period.
ASGNMT_
EMPLOYEE EMPLOYEE ASGNMT ASGNMT
MASTER
EMPLOYEE ASGNMT
EMPLOYEE_
PERIODS
EMPLOYEE_PERIOD
EMPLOYEE_
PERIOD_
VERSIONS
Using the Prior EPV, if it is NULL it's original, if it is not NULL, then we know it is an amended EP.
"and ep.pp_end between e.eff_dt and e.end_eff_dt" – This statement is using ep.pp_end to get the
employee that is effective on that date.
ep.PP_END Cost Center
2/4/2012 123
5/5/2012 456
12/5/2012 456
EMPLOYEE_PERIOD_VERSIONS
To track the versions of each EMPLOYEE_PERIOD.
COLUMN NAME DESCRIPTION
CALC_CHANGE_SET A foreign key representing the calculated set
of pay period data.
EMPLOYEE_PERIOD A foreign key representing the
employee/assignment /pay period
combination.
EMPLOYEE_PERIOD_VERSION The primary key associated with the version
of the EMPLOYEE_PERIOD.
PRIOR_EMP_PERIOD_VERSION A foreign key representing the prior
EMPLOYEE_PERIOD_VERSION in relation to
an amended pay period.
VERSION_NUMBER The version of the pay period.
EMPLOYEE_PERIOD_VERSIONS table.
View: V_ASGNMT_PERIODS
A comprehensive view of the major primary keys and columns found in the following tables:
• ASGNMT_MASTER
• ASGNMT
• EMPLOYEE_PERIODS
• EMPLOYEE_PERIOD_VERSIONS
• ASGNMT
• ASGNMT_TYPE
• ASSIGNMENT_DESCRIPTION
• CALC_CHANGE_SET
• CURRENT_PERIOD_BEGIN
• CURRENT_PERIOD_END
• DESCRIPTION (for backward compatibility)
• EMPLOYEE
• EMPLOYEE_PERIOD
• EMPLOYEE_PERIOD_VERSION
• POLICY_PROFILE
• PP_BEGIN
• PP_END
• PRIOR_EMP_PERIOD_VERSION
• VERSION_NUMBER
The view V_ASGNMT_PERIODS is often a good starting point for a SQL statement
involving the employee_period_version relationship.
Lesson 3 Exercises
Let’s Practice
Exercise 1: Query Writing – Pay Periods per Employee
Design a query that will return the following columns:
• Employee ID
• Employee Name (First & Last)
• Assignment Description (multiple assignment configurations only)
• Pay Period Begin
• Pay Period End
Let’s Practice
Exercise 2: Query Writing – Finding Amended Pay Periods
Design a query that will identify employees that have an amended pay period
returning the following columns:
• Employee ID
• Employee Name (First & Last)
• Assignment Description (multiple assignment configurations only)
• Pay Period End
• Version Number
Lesson 3 Review
1. What is the key to “unlocking” most transactional tables in the database?
a) EMPLOYEE
b) EMPLOYEE_PERIOD_VERSION
c) EMPLOYEE_PERIOD
d) ASGNMT
2. What is the name of the view that can be used as a starting point for most SQL statements involving
transactional tables?
3. True or False: Each EMPLOYEE_PERIOD has one and only one EMPLOYEE_PERIOD_VERSION.
4. What will be the VERSION_NUMBER of a pay period that has been amended 3 times?
a) 1
b) 2
c) 3
d) 4
5. True or False: In a single-assignment environment, there is one record for each employee for each
pay period in the EMPLOYEE_PERIODS table. What about in a multiple-assignment environment?
Amended Timesheets
Amended Timesheets feature allows employees and/or managers to correct erroneous prior
timesheet information. When a timesheet is amended, the original version is not deleted and
replaced with a new version, as illustrated in Pay Period Versioning.
Once a timesheet has been locked, calculated and closed, no further changes can be made to it.
Instead, when an amendment occurs, a new version of the timesheet is created, and edits are
made to that version.
Any data entered on an amended timesheet is not handled until the new version is approved by
the manager. This lesson will show the end to end process of an amended timesheet.
The Scenario
1. The employee originally entered 9 Regular hours in Week 1, in this scenario hours over 8
are reclassified as Overtime.
2. The employee changes those 9 Regular hours to 8 Vacation hours.
3. The employee only has 20 hours of available Vacation at start of Week 1.
After the Amendment is approved, TSO table will show new records where the Regular and
Overtime hours are "reversed" from Week 1 and Vacation with 8 hours is "newly" added. Then
the new hours are all recalculated.
This causes a ripple effect into Week 2, which previously used 16 hours of the 20 available
Vacation Hours. So, after the amendment changes from Week 1, only 4 Vacation hours are
available for Jun 12th causing the remaining 4 hours requested to be reclassified as “Unpaid.”
Finally, notice that the CALC_CHANGE_SET “1000000003” was assigned to the previous record
changes; this means they will get processed as part of Week 3’s payroll period processing even
though those records are not part of the current pay period.
When using the employee periods table calc_emp_period_version column to join to the
employee_period_version column, the results will be limited to:
1. The initial version for the pay period, if there are no amendments for the pay period
2. If an amendment(s) exists for the pay period:
a. The most recently approved amendment
b. The prior version for the pay period, if the amendment has not been approved
Pay Now
When using the employee periods table last_emp_period_version column to join to the
employee_period_version column, the results will be limited to only the most recently created
version for the pay period.
To explore the first of these two join options, for the following sample pay period, an employee
has amended his or her timesheet changing “out” time for 3/31/2009. This change is
highlighted in yellow. This amendment has not been approved or processed. As such, note the
version number is 0 and not 2. The differences in the results based on the join column used can
be observed.
A sample pay period with one processed original version and an open unapproved amendment
The following results are from TIME_SHEET_DETAIL using the employee_period_version join.
Note the results include both the original and the amended version of the employee time.
v_asgnmt_periods.employee_period_version = time_sheet_detail.employee_period_version
The following results are from TIME_SHEET_DETAIL using calc_emp_period_version (Calc EPV)
as the join. In this instance, the results include only the original version of the employee time
(version 1) since the amendment has not been approved. Until the amendment is approved,
the calc_emp_period_version column will contain the employee_period_version key
corresponding to the previous version.
employee_periods.calc_emp_period_version = time_sheet_detail.employee_period_version
As the amended version, version 0 was not yet approved, the following are the results from
TIME_SHEET_DETAIL using last_emp_period_version (Last EPV) as the join. In this instance, the
results include only the most recently created version of the employee time (version 0).
employee_periods.last_emp_period_version = time_sheet_detail.employee_period_version
EPV = EMPLOYEE_PERIOD_VERSION
CEPV = CALC_EMP_PERIOD_VERSION
LEPV = LAST_EMP_PERIOD_VERSION
ASGNMT_
EMPLOYEE EMPLOYEE
MASTER
V_ASGNMT_ EMPLOYEE_
PERIODS PERIODS
LINE_APPRO TIME_SHEET_
DETAIL_RECORD_ID
VAL_EVENT DETAIL
DETAIL_RECORD
EPV
_ID = DETAIL_ID
TIME_SHEET_
DETAIL_MAT
CH_VAL
APP_USER
MATCH_POLICY
MATCH_VALUE
ROUTING_TA
BLE
APPROVER_ID
APP_USER
EPV = EMPLOYEE_PERIOD_VERSION
APPROVAL_EVENT
The who, what, and when of each approval that occurs in the application.
TIME_SHEET_DETAIL
The employee entered time slices on a timesheet. This view shows exactly what the employee
entered and no calculations are done.
TIME_SHEET_DETAIL_SPLIT
The calculated time slices using configuration rules based on the records in
TIME_SHEET_DETAIL.
TIME_SHEET_OUTPUT
The final calculation destination for timesheet values, containing the information that is used to
calculate pay checks or exports to external systems.
CALC_CHANGE_SET
Identifier for the calculated set of pay period data. The CALC_CHANGE_SET key is not generated
until after the lock or the lock and calculate job has been run during pay period processing. It
enables the application to identify all records that should be processed as part of the pay
period, including records from amended timesheets that may have a different pay period end
date.
ROUTING_TABLE
The definition of the routing information used to determine which lines to display to the user.
TIME_SHEET_DETAIL_MATCH_VAL
Ties the TIME_SHEET_DETAIL and ROUTING_TABLE information together for line access.
Records only exist for open or amended timesheets.
OFF_CYCLE_EXPORT_BATCH
Off-cycle export details including the type of payroll export used.
COLUMN NAME DESCRIPTION
ADP_EXPORT Set if the export type = ‘ADP_EXPORT’
ASGNMT_GRP A foreign key representing a single assignment group in the
database.
BATCH_STATUS The status of the export batch.
CHOICE_ID: OFF_CYCLE_BATCH_STATUS
CLOSED_DT The date when the export batch was closed.
COMMENTS Comments about the export batch.
CREATION_DT The date the export batch was created.
DESCRIPTION The description of the export batch.
EXPORT_TYPE The type of export used to pay the export batch.
CHOICE_ID: OFF_CYCLE_EXPORT_TYPE
GENERIC_EXPORT_POLICY Set if the export type = ‘GENERIC_EXPORT’
OFF_CYCLE_BATCH_ID The primary key associated with the export batch.
ORACLE_EXPORT_POLICY Set if the export type = ‘ORACLE_PAYROLL_EXPORT’
OFF_CYCLE_EXPORT_BATCH table
WFS_SYS_CURRENCY_INFO
A definition table of information for all supported currencies in the application.
EXCEPTION_CODE
A definition table for all possible exceptions that can occur in the application.
Lesson 4 Exercises
Let’s Practice
Exercise 1: Query Writing – Employee Timesheet Information
Design a query that will return the following columns:
• Employee ID
• Employee Name (First & Last)
• Assignment Description (multiple assignment configurations only)
• Work Date
• Start Time
• End Time
• Pay Code Description
• Hours
• Pay
Let’s Practice
Exercise 2: Query Writing – Employee Timesheet Exceptions
Design a query that will return the following columns:
• Employee ID
• Employee Name (First & Last)
• Assignment Description (multiple assignment configurations only)
• Exception Date
• Exception Code
• Exception Message
Lesson 4 Review
1. True or False: The CALC_CHANGE_SET key is created before the calculate job is run.
3. What view would you query against to find exactly what the employee entered on their
timesheet?
6. True or False: The APPROVAL_EVENT table only holds information pertaining to the
approval of timesheets.
EMPLOYEE
EMPLOYEE
ASGNMT_
MASTER
EMPLOYEE ASGNMT
BANK_
BANK_
OUTPUT_
OUTPUT
SUMMARY
CEPV =
CALC_EMP_PERIOD_VERSION
EPV = EMPLOYEE_PERIOD_VERSION
ASGNMT_
EMPLOYEE EMPLOYEE
MASTER
EMPLOYEE
EMPLOYEE
TIME_OFF_
REQUEST ASGNMT
TIME_OFF_REQUEST TIME_OFF_REQUEST
TIME_OFF_ TIME_OFF_
REQUEST_ REQUEST_
DETAIL EVENT
TIME_OFF_REQUEST TIME_OFF_REQUEST
TIME_SHEET_ SCHEDULE_
DETAIL DETAIL
BANK_OUTPUT
A transactional table which stores all details about activity which affects bank balances. The
actual balance is not stored in this table, only the detailed activity.
BANK_OUTPUT_SUMMARY
A transactional table which stores all details about bank balances. One row is inserted into this
table at the beginning of each pay period to keep track of the balance. Additional rows are
inserted if there is any activity during the period.
employee_periods ep
and bos.work_dt = (
select max(bos2.work_dt)
TIME_OFF_REQUEST_DETAIL
A transactional table which stores detailed information about a time off request. The
information generated in this table is moved to the appropriate schedule and/or timesheet
tables/views once a time off request is approved.
TIME_OFF_REQUEST_EVENT
A transactional table which tracks the status changes of a time off request.
Lesson 5 Exercises
Let’s Practice
Exercise 1: Query Writing – Employee Accrual Activity
Design a query that will return the following columns:
• Employee ID
• Employee Name (First & Last)
• Assignment Description (multiple assignment configurations only)
• Bank Description
• Activity Date
• Accrued Hours
• Used Hours
Let’s Practice
Exercise 2: Query Writing – Employee Time Off Requests
Design a query that will return the following columns:
• Employee ID
• Employee Name (First & Last)
• Assignment Description (multiple assignment configurations only)
• Work Date
• Pay Code
• Hours
Lesson 5 Review
1. What is the difference between BANK_OUTPUT and BANK_OUTPUT_SUMMARY?
2. True or False: The BANK_OUTPUT_SUMMARY table has a row for every day in the pay
period.
3. What column from TIME_OFF_REQUEST stores when the request was made?
a) START_DATE
b) END_DATE
c) SYSTEM_TIMESTAMP
d) REQUEST_MADE_AT
e) It is not stored in this table
This section references WorkForce Time and Attendance Scheduling. This section does not
cover aspects of WorkForce Forecasting and Scheduling or Advanced Scheduler.
Schedule Cycle
• A collection of schedule templates that represent a period of time.
• The cycle can be assigned to an employee and be utilized to generate the employee’s
schedule for the length of the cycle.
EMPLOYEE
EMPLOYEE
ASGNMT_
MASTER
EMPLOYEE ASGNMT
Calc EPV =
CALC_EMP_PERIOD_VERSION
EMPLOYEE_ EPV = EMPLOYEE_PERIOD_VERSION
PERIODS
Calc EPV Calc EPV
= EPV = EPV
SCHEDULE_
SCHEDULE_
GENERATION EPV
DETAIL
_DTL
SCHEDULE_
GENERATED_FROM_TEMPLATE
CYCLE
= SCHEDULE_TEMPLATE
= ID
SCHEDULE_ SCHEDULE_
TEMPLATE CYCLE
SCHEDULE_TEMPLATE ID
SCHEDULE_ SCHEDULE_
HOURS_FORMULA
TEMPLATE_ FORMULA CYCLE_
= FORMULA
DETAIL DETAIL
SCHEDULE_TEMPLATE_DETAIL
A definition table which details each of the schedule templates that have been defined in the
Policy Editor.
FORMULA
A table of user defined formulas.
SCHEDULE_CYCLE
A definition table of all schedule cycles that have been defined in the Policy Editor.
SCHEDULE_CYCLE_DETAIL
A definition table which details each of the schedule cycles that have been defined in the Policy
Editor.
SCHEDULE_GENERATION_DTL
A transactional table which stores high-level information related to an employee’s schedule for
each pay period.
SCHEDULE_GENERATION_DTL table
SCHEDULE_DETAIL
A view of the transactional table which stores all detailed records about an employee’s
schedule.
Lesson 6 Exercises
Let’s Practice
Exercise 1: Query Writing – Employee Schedule Information
Design a query that will return the following columns:
• Employee ID
• Employee Name (First & Last)
• Assignment Description (multiple assignment configurations only)
• Scheduled Work Date
• Scheduled Start Time
• Scheduled End Time
• Scheduled Pay Code Description
• Scheduled Hours
Let’s Practice
Exercise 2: Query Writing – Schedule Template Usage
Design a query that will return the following columns:
• Pay Period End
• Schedule Template Description
• Count of Employees using Schedule Template
Lesson 6 Review
1. What is the difference between a schedule template and a schedule cycle?
2. True or False: Querying the SCHEDULE_TEMPLATE_DETAIL table will give you employee specific
schedule information.
3. How can you tell which template in a schedule cycle the employee is currently in?
4. Where can you view the details of a schedule template or schedule cycle other than the database
table?
WorkForce T&A 1000, 2000, 2100, 2200, 3000, 4000, 5000 & WorkForce T&A
Hand Recognition Terminal
WorkForce T&A 1000 Terminal WorkForce T&A 2000 Terminal WorkForce T&A 2100 Severe Duty
Terminal
• Before version 15.x, there used to be a scheduled job run every x minutes to import swipe
data. Upon release 15.x and higher, a web service runs and imports swipe data real time.
Badge updates still require a scripted job to be run. Badge Update - HR system has badge
update where there is an interface (used to be a strip query) now under run job will update
the badge table.
• Information about the devices themselves is not stored in the WorkForce T&A database,
only in the terminal controller device. Some terminal information is recorded to the
transaction and may be optionally written to TIME_SHEET_DETAIL in the same manner as
labor distribution data.
• Employee badge information is stored in the BADGE table and badges are grouped together
in the BADGE_GROUP table. The BADGE table contains a list of active badge records to be
distribute to the terminal controller.
Notes:
As of version 18.3, the swipe table is included in the Clean Table policy. Records in
the table are kept for 366 days by default
BADGE
A transactional table which stores information relating each employee to a specific badge.
BADGE_GROUP
A transactional table which aggregates badges into groups which can then be assigned to
specific data collection devices.
BIOMETRIC_TEMPLATE
Fingerprint devices.
Lesson 7 Exercises
Let’s Practice
Exercise 1: Query Writing – Employee Swipes
Design a query that will return the following columns:
• Employee ID
• Employee Name (First & Last)
• Assignment Description (multiple assignment configurations only)
• Employee Badge Number
• Swipe Type
• Swipe Date/Time
Notes:
Some employees may not have a Badge number. What SQL query writing method
can you use to ensure this query returns data, even if there is no badge ID?
Let’s Practice
Exercise 2: Query Writing – Comparing Swipes to Timesheet Entries
Design a query that will return the following columns for “in” swipes only:
• Employee ID
• Employee Name (First & Last)
• Assignment Description (multiple assignment configurations only)
• Swipe Type
• Swipe Date/Time
• Timesheet Date/Time
Lesson 7 Review
7. True or False: The exact time from SWIPE is transferred to the timesheet.
APP_USER_RIGHT
A definition table which defines which roles each application user can utilize in the application.
RIGHT_GRP
All the roles available in the application.
RIGHT_GRP_DETAIL
A definition table which defines all the elements of each role.
LOGIN_HISTORY
A transactional table tracking each login to the application.
select *
from TIME_SHEET_DETAIL
The WorkForce T&A database allows for the creation of a “set” of policy items which in turn
allows the end-user to avoid hard-coding of values into SQL statements. This is a good idea
because the business requirements might often change and these changes can easily be
maintained in the Policy Editor instead of each SQL statement that might be associated with the
requirement.
6. In the policy tree, navigate to All Policies > Policy Sets > Pay Codes > Pay Code.
7. Right click pay code and select Add New Pay Code Policy Set.
9. From the left table, select a policy for the set, and then click the Move to button. The
selected policy appears in the table on the right. Repeat this step for each policy you want
to include in this set.
11. The new policy set now appears in the policy tree.
• Once the policy set exists, it can be referenced in an SQL statement instead of using
hard-coded values.
select *
where PAY_CODE in (
select RECORD_KEY
RULE_SET_DETAIL rsd
By using this method, the policy set can be changed multiple times without having to update
the SQL statement.
RULE_SET_DETAIL
A definition table containing the components of each policy set that has been created in the
Policy Editor.
V_RULE_SET_DETAIL
A view containing the components of each policy set that has been created in the Policy Editor,
but also contains the ‘END_EFF_DT’ value from the corresponding RULE_SET record.
V_PAY_CODE_SET_DETAIL
This view exposes membership in Pay Code policy sets. It must be used instead of
RULE_SET_DETAIL or V_RULE_SET_DETAIL if the “Pay Code Collection” feature (available from
version 18.1 onwards) is configured. The recommended best practice for all new queries is to
use this view.
Example use, querying all TIME_SHEET_OUTPUT records whose pay code belongs to the
‘NEW_PAY_CODE_SET'’ pay code set:
select *
where PAY_CODE in (
select RECORD_KEY
In order to display the text conversion of this value in an SQL statement, you must perform a
join to the CHOICE_DETAILS table. Using the example from above, the SQL statement would be
changed in the following way:
CHOICE_DETAILS cd
The same results, but with the text description instead of the system constant
The correct CHOICE_ID to use in the SQL statement can be found by using the Data Dictionary,
which is discussed in Lesson 2.
CHOICES
A definition table containing all the possible constant values sets in the application.
CHOICE_DETAILS
A definition table containing the components of each of the constant value sets.
WF_ADD_HOUR
Adds hours to any date
Syntax: WF_ADD_HOUR(DATE,INT)
select WF_ADD_HOUR(WFS_DATE.WFS_DATE, 3)
from WFS_DATE
WF_TO_DATE
Converts values to date type
Syntax: WF_TO_DATE(INT,INT,INT)
select WF_TO_DATE(2009,1,1)
from SYSTEM_SETUP
WFS_STRIP_TIMESTAMP
Converts a datetime value to a date value
Syntax: WFS_STRIP_TIMESTAMP(DATETIME)
select WFS_STRIP_TIMESTAMP(LAST_LOGIN_DTTM)
from APP_USER
WF_DTTM_WITH_DST_TO_NUMBER
Converts a datetime value based on whether it occurred in the DST repeated hour to a number for
datetime comparisons
from TIME_SHEET_OUTPUT
Result: 11511010103000
WF_DST_FALLBACK_NUMBER_TO_DTTM
Converts the number computed by WF_DTTM_WITH_DST_TO_NUMBER to the corresponding
datetime
from TIME_SHEET_OUTPUT
WF_GET_DST_FALLBACK
Converts the number computed by WF_DTTM_WITH_DST_TO_NUMBER to the value of the DST
flag passed to WF_DST_FALLBACK_DTTM_TO_NUMBER
from TIME_SHEET_OUTPUT
Result: 'T'
In addition to the custom date database functions above, there are two additional custom
database functions which can be utilized to assist in query writing.
WF_NVARCHAR_TO_LONG
Converts nvarchar type to number type
select WF_NVARCHAR_TO_LONG(DISPLAY_EMPLOYEE)
from EMPLOYEE
Result: 1000001
WF_LONG_TO_NVARCHAR
Converts number type to nvarchar type
Syntax: WF_LONG_TO_NVARCHAR(INT)
select WF_LONG_TO_NVARCHAR(OTHER_NUMBER1)
from EMPLOYEE
Result: '10'
1. Create a new constant type parameter in the Policy Editor for the database function call. Below is an example for
the wf_dttm_with_dst_to_number function call:
The Constant Value of the parameter should contain the full SQL text for the function call, e.g.,
2. Create a corresponding parameter in the custom Crystal Report using the Database Expert:
Parameter Name: CC_WF_DTTM_WITH_DST_TO_NUMBER_VALUE
Prompting Text: Convert DST to Number
Value Type: String
Default Value: 1
3. Replace the function call in the report query with the new parameter (be careful to leave the alias for the column,
e.g., num_start_dttm):
4. When running the query in Crystal Reports, enter the following values for the parameters related to the function
call:
DBSCHEMA_PREFIX_VALUE: leave this parameter value blank:
These customizations will permit the report to be run in Crystal Reports (without the function call) as well as permit
the function call to execute when the report is run in Workforce Time.
Lesson 8 Exercises
Let’s Practice
Exercise 1: Query Writing – Login History
Design a query that will return the following columns:
• Employee ID
• Employee Name (First & Last)
• Employee Login ID
• Login Date/Time
We must login as a user who is also an employee in order to see results in this
query.
Let’s Practice
Exercise 2: Query Writing – Using a Policy Set
Design a query that will return the following columns where the exception code is
limited to a specific policy set:
• Employee ID
• Employee Name (First & Last)
• Assignment Description (multiple assignment configurations only)
• Exception Code
• Exception Date
Let’s Practice
Exercise 3: Query Writing – Displaying the Text Value for a System
Constant
Design a query using the TIME_OFF_REQUEST table which will display the text value
for STATUS instead of the numeric value:
• Employee ID
• Employee Name (First & Last)
• Assignment Description (multiple assignment configurations only)
• Start Date of Time Off
• End Date of Time Off
• Status of Request
Lesson 8 Review
1. What is the difference between an application user and an employee?
2. In which of these tables would you find the details of a policy set?
a) RULE_SET
b) CHOICE_DETAILS
c) RULE_SET_DETAIL
d) CHOICES
e) APPROVAL_EVENT
SQL Commands
SELECT/FROM
Used to obtain data from a single table or multiple tables in a database.
Syntax: SELECT {column_name}, {column_name}, {column_name}
FROM {table_name}
WT&A: SELECT display_employee, first_name, last_name
FROM employee
When multiple columns are listed in the SELECT clause, they should be
delimited with a comma (,). If the desired result is all columns from a
table, then SELECT * FROM {table_name} may be used instead of listing
each column individually.
DISTINCT
Used to obtain distinct data from a single table or multiple tables in a database.
Syntax: SELECT DISTINCT {column_name}
FROM {table_name}
WT&A: SELECT DISTINCT display_employee
FROM employee
WHERE/AND/OR
Used to conditionally obtain data from a single table or multiple tables in a database. After the
first, each condition needs to be preceded by either an ‘AND’ or an ‘OR’ keyword to identify
how they are to be evaluated.
Syntax: SELECT {column_name}, {column_name}, {column_name}
FROM {table_name}
WHERE {condition}
AND {condition}
AND ({condition} OR {condition})
WT&A: SELECT display_employee, first_name, last_name
FROM employee
WHERE status_code1 = 'A'
AND end_eff_dt = '3000-12-31'
AND (last_name = 'Brown' or first_name = 'John')
IN/BETWEEN/LIKE/%
Used to conditionally obtain data from a single table or multiple tables in a database.
Syntax: SELECT {column_name}, {column_name}, {column_name}
FROM {table_name}
WHERE {column_name} IN ({value1},{value2},{value3})
AND {column_name} BETWEEN {value1} and {value2}
AND {column_name} LIKE {value%}
WT&A: SELECT display_employee, first_name, last_name, status_date1
FROM employee
WHERE last_name IN ('Smith','Brown','White')
AND status_date1 BETWEEN '2007-05-01' and '2007-05-31'
AND first_name LIKE '%bet%'
NOT
Used to conditionally obtain data where the evaluated condition is false.
Syntax: SELECT {column_name}, {column_name}, {column_name}
FROM {table_name}
WHERE {column_name} NOT IN ({value1},{value2},{value3})
WT&A: SELECT display_employee, first_name, last_name, status_date1
FROM employee
WHERE last_name NOT IN ('Smith','Brown','White')
ORDER BY
Used to order the results of a select statement
Syntax: SELECT {column_name}, {column_name}, {column_name}
FROM {table_name}
ORDER BY {column_name}
WT&A: SELECT display_employee, first_name, last_name
FROM employee
ORDER BY last_name
To order by multiple columns, list the columns in the desired order, with
each column delimited by a comma (,).
AVG/COUNT/MIN/MAX/SUM
Mathematical aggregate functions that can be used to obtain calculations on data.
Syntax: SELECT AVG({column_name})
FROM {table_name}
SELECT COUNT({column_name})
FROM {table_name}
SELECT MIN({column_name})
FROM {table_name}
SELECT MAX({column_name})
FROM {table_name}
SELECT SUM({column_name})
FROM {table_name}
WT&A: SELECT AVG(hours)
FROM time_sheet_detail
SELECT COUNT(employee)
FROM employee
SELECT MIN(display_employee)
FROM employee
SELECT MAX(display_employee)
FROM employee
SELECT SUM(hours)
FROM time_sheet_detail
UPPER/LOWER
Used to convert data in a column to either upper or lower case.
Syntax: SELECT UPPER({column_name}), LOWER({column_name})
FROM {table_name}
WT&A: SELECT UPPER(last_name), LOWER(first_name)
FROM employee
GROUP BY
Used to aggregate mathematical functions by certain data elements.
Syntax: SELECT {column_name}, SUM({column_name})
FROM {table_name}
GROUP BY {column_name}
HAVING
Used to limit the results of an aggregate statement.
Syntax: SELECT {column_name}, SUM({column_name})
FROM {table_name}
GROUP BY {column_name}
HAVING SUM({column_name}) > {value}
WT&A: SELECT display_employee, SUM(pay)
FROM time_sheet_output
GROUP BY display_employee
HAVING SUM(pay) > 100000
UPDATE
Used to update values in a table. This command should be used with caution.
Syntax: UPDATE {table_name}
SET {column_name} = {new_value}
WHERE {condition}
WT&A: UPDATE employee
SET other_string25 = 'OPERATIONS'
WHERE ld1 = 760
INSERT INTO
Used to insert entire rows into a table. This command should be used with extreme caution.
Syntax: INSERT INTO {table_name} ({column_1},{column_2},…)
VALUES ({value1},{value2},…)
DELETE
Used to delete entire rows from a table. This command should be used with extreme caution.
Syntax: DELETE FROM {table_name}
WHERE {column_name} = {value}
SQL Operators
The following table of operators can be used when writing an SQL statement:
Table 1: SQL operators
Operator Definition
= Sets values equal to each other.
> Finds values greater than the condition.
>= Finds values greater than or equal to the condition.
< Finds values less than the condition.
<= Finds values less than or equal to the condition.
<> Finds values not equal to each other.
!= Finds values not equal to each other.
IS NULL Finds all values that are null. (NOTE: a blank value is not the same as a NULL value.)
IS NOT NULL Finds all values that are not null. (NOTE: a blank value is not the same as a NULL
value.)
+ Adds values together. In SQL Server, also used as a concatenation operator.
/ Divides values.
* Multiplies values.
- Subtracts values from each other.
|| In Oracle, used as a concatenation operator.
INNER JOIN
An inner join connects multiple tables via common columns that exist in all the tables. In an
inner join, the values in the common columns are usually equal to each other.
Syntax: SELECT {table_name1}.{column_name}, {table_name2}.{column_name}
FROM {table_name1}, {table_name2}
WHERE {table_name1}.{column_name} = {table_name2}.{column_name}
WT&A: SELECT employee.display_employee, app_user.email_address
FROM employee, app_user
WHERE employee.employee = app_user.employee
When multiple tables are listed in the FROM clause, they should be
delimited with a comma (,). When a table column of the same name
exists in multiple tables in an SQL statement, the column name must be
prefaced by the specific table name, i.e., {table_name}.{column_name}
CARTESIAN PRODUCT
A Cartesian product is the result of a direct multiplication of data by not specifying a join
between two tables. This is most often a mistake and can result in a “run-away” query that
does not perform well. However, it may be necessary to purposely create a Cartesian product
for certain results.
Syntax: SELECT {table_name1}.{column_name}, {table_name2}.{column_name}
FROM {table_name1}, {table_name2}
WT&A: SELECT wfs_date.wfs_date, employee.display_employee
FROM wfs_date, employee
The results of this query will create a result where every possible value of combinations is
created. For example, the WFS_DATE table always has 402,131 rows. If the EMPLOYEE table
had 100 rows, it will mean that this query will result in 40,213,100 rows because each value will
need to have a combination since no join is specified.
ACT_CASE_ASSIGNMENT
A transactional table containing the absence case assignments.
ACT_CASE_DOCUMENT
A transactional table of documents and document related details pertaining to absence cases.
The actual document content is encrypted and cannot be displayed in reports.
ACT_HISTORY_EVENT_TYPE
A definition table of all history event types in the application.
ACT_WORKFLOW_EVENT_TYPE
A definition table of all workflow event types in the application.
ACT_CASE_HISTORY_EVENT
A transactional table which contains the history events related to absence cases.
ACT_CASE_WORKFLOW_EVENT
A transactional table which contains the workflow events related to absence cases.
ACT_REASON
A definition table of the distributed reasons for which an employee can take leave.
ACT_REASON_OVERRIDE
A definition table of the customer reason overrides for non-regulated sections of a reason.
ACT_LEAVE_TYPE
A definition table of the available distributed leave types. A leave type corresponds to a law or
statute.
ACT_CUSTOMER_LEAVE_POLICY
A definition table of the customer defined leave types that are not federal or state regulated,
i.e., not distributed Leave Types.
LEAVE_BALANCE
A transactional table which contains the leave type balances for each employee.
LEAVE_ELIGIBILITY
A transactional table which contains the evaluated result of the leave types in an absence case.
LEAVE_ELIGIBILITY_OVERRIDE_DTL
A transactional table which contains the effective dated detail records of the evaluated or
overridden result of the leave types in an absence case.
ACT_CUSTOMER_CONFIGURATION
A definition table of customer specific absence compliance configuration information.
ACT_CASE
ACT_CASE
LEAVE_
ELIGIBILITY
LEAVE_
ACT_CASE_
ACT_CASE_ ACT_CASE_ ACT_CASE_ LEAVE_BALANC LEAVE_ ELIGIBILITY_
WORKFLOW_ TRIGGERING_
ASSIGNMENT HISTORY_EVENT DOCUMENT E ELIGIBILITY OVERRIDE_
EVENT EVENT DTL
= ACT_CASE_
WORKFLOW_
ACT_HISTORY_EVENT_TYPE ACT_LEAVE_TYPE
EVENT
APP_USER ACT_CUSTOMER_
EMPLOYEE_PERIOD_VERSION = LEAVE_POLICY
ACT_WORKFLOW_EVENT_TYPE CALC_EMP_PERIOD_VERSION
ACT_
ACT_HISTORY_ EMPLOYEE_ ACT_LEAVE_ ACT_CUSTOMER
APP_USER WORKFLOW_
EVENT_TYPE PERIODS TYPE _LEAVE_POLICY
EVENT_TYPE
TA_BANK = BANK
BANK
EMPLOYEE_ EMPLOYEE_
PHOTO_ID
MASTER PHOTO
EMPLOYEE
EMPLOYEE
EMPLOYEE
ASGNMT_
MASTER
ASGNMT
ASGNMT
ASGNMT
ASGNMT_GR
P_
DETAIL
ASGNMT_GRP
ASGNMT_GR
P
EMPLOYEE
EMPLOYEE
V_ASGNMT_
PERIODS
EMPLOYEE_PERIOD_VERSION
SCHEDULE_
BANK_OUTP
TIME_SHEET_ TIME_SHEET_ GENERATION SCHEDULE_
UT_
DETAIL OUTPUT _ DETAIL
SUMMARY
DTL
Relationships to EMPLOYEE_PERIOD_VERSION key.
ASGNMT_
EMPLOYEE EMPLOYEE ASGNMT ASGNMT
MASTER
EMPLOYEE ASGNMT
EMPLOYEE_
PERIODS
EMPLOYEE_PERIOD
EMPLOYEE_
PERIOD_
VERSIONS
ASGNMT_
EMPLOYEE EMPLOYEE
When using the MASTER
EMPLOYEE_PERIODS table,
the join will be either:
EMPLOYEE EMPLOYEE ASGNMT
CALC_EMP_PERIOD_VERSION
=
EMPLOYEE_PERIOD_VERSION V_ASGNMT_ EMPLOYEE_ Calc EPV
OR
PERIODS PERIODS
or
Calc EPV or Last
LAST_EMP_PERIOD_VERSION EPV
=
EMPLOYEE_PERIOD_VERSION
EPV EPV
EPV EPV
DETAIL_
RECORD_ID
TIME_SHEET_ = PARENT_ID TIME_SHEET_ TIME_SHEET_ TIME_SHEET_
DETAIL DETAIL_SPLIT OUTPUT TIME_SHEET
EXCEPTION
WFS_SYS_ CALC_
Any LD Table CURRENCY_ PAY_CODE CHANGE_ APPROVAL_ EXCEPTION_
INFO SET EVENT CODE
LD1 CALC_CHANGE_SET
EMPLOYEE
EPV = EMPLOYEE_PERIOD_VERSION
LEPV = LAST_EMP_PERIOD_VERSION
ASGNMT_
EMPLOYEE EMPLOYEE
MASTER
V_ASGNMT_ EMPLOYEE_
PERIODS PERIODS
LINE_APPRO TIME_SHEET_
DETAIL_RECORD_ID
VAL_EVENT DETAIL
DETAIL_RECORD
EPV
_ID = DETAIL_ID
TIME_SHEET_
DETAIL_MAT
CH_VAL
APP_USER
MATCH_POLICY
MATCH_VALUE
ROUTING_TA
BLE
APPROVER_ID
APP_USER
EPV = EMPLOYEE_PERIOD_VERSION
EMPLOYEE
EMPLOYEE
ASGNMT_
MASTER
EMPLOYEE ASGNMT
BANK_
BANK_
OUTPUT_
OUTPUT
SUMMARY
CEPV =
CALC_EMP_PERIOD_VERSION
EPV = EMPLOYEE_PERIOD_VERSION
ASGNMT_
EMPLOYEE EMPLOYEE
MASTER
EMPLOYEE
EMPLOYEE
TIME_OFF_
REQUEST ASGNMT
TIME_OFF_REQUEST TIME_OFF_REQUEST
TIME_OFF_ TIME_OFF_
REQUEST_ REQUEST_
DETAIL EVENT
TIME_OFF_REQUEST TIME_OFF_REQUEST
TIME_SHEET_ SCHEDULE_
DETAIL DETAIL
EMPLOYEE
EMPLOYEE
ASGNMT_
MASTER
EMPLOYEE ASGNMT
Calc EPV =
CALC_EMP_PERIOD_VERSION
EMPLOYEE_ EPV = EMPLOYEE_PERIOD_VERSION
PERIODS
Calc EPV Calc EPV
= EPV = EPV
SCHEDULE_
SCHEDULE_
GENERATION EPV
DETAIL
_DTL
SCHEDULE_
GENERATED_FROM_TEMPLATE
CYCLE
= SCHEDULE_TEMPLATE
= ID
SCHEDULE_ SCHEDULE_
TEMPLATE CYCLE
SCHEDULE_TEMPLATE ID
SCHEDULE_ SCHEDULE_
HOURS_FORMULA
TEMPLATE_ FORMULA CYCLE_
= FORMULA
DETAIL DETAIL
BIOMETRIC_
TEMPLATE
SWIPE_
PHOTO
IN_SWIPE_ID =SWIPE_ID
IN_SWIPE_PHOTO_ID = OR APP_USER
SWIPE_PHOTO_ID OUT_SWIPE_ID = SWIPE_ID
OR
OUT_SWIPE_PHOTO_ID = EMPLOYEE
SWIPE_PHOTO_ID
ID_FIELD = ASGNMT
EMPLOYEE APP_USER
ASGNMT EMPLOYEE BADGE
ASGNMT BADGE_GROUP
ASGNMT_ BADGE_
MASTER GROUP