Requirements Timesheet

Requirements Document
for
TimeSheet
Version 1.0
Prepared by Marina Arseniev, Cesar Brito, Elaine Peters
HR/Campus Temporary Services and AdCom Services
10/23/2003
SoftwareRequirementsSpecificationforTimesheets
Pageii
TableofContents
TableofContents...........................................................................................................................ii
RevisionHistory............................................................................................................................iii
ApprovalHistory..........................................................................................................................iii
1. Introduction..............................................................................................................................1
1.1
1.2
1.3
1.4
Purpose...........................................................................................................................................1
IntendedAudienceandReadingSuggestions.................................................................................1
ProductScope.................................................................................................................................1
References......................................................................................................................................2
2.1
2.2
2.3
2.4
2.5
2.6
2.7
ProductPerspective........................................................................................................................2
ProductFunctions...........................................................................................................................2
UserClassesandCharacteristics....................................................................................................2
OperatingEnvironment..................................................................................................................3
DesignandImplementationConstraints.........................................................................................3
UserDocumentation.......................................................................................................................3
AssumptionsandDependencies.....................................................................................................4
3.1
3.2
3.3
3.4
UserInterfaces................................................................................................................................4
HardwareInterfaces........................................................................................................................4
SoftwareInterfaces.........................................................................................................................4
CommunicationsInterfaces............................................................................................................4
2. OverallDescription..................................................................................................................2
3. ExternalInterfaceRequirements...........................................................................................4
4. SystemFeatures.......................................................................................................................5
4.1 SystemFeature1............................................................................................................................5
4.2 SystemFeature2(andsoon)........................................................................................................13
5. OtherNonfunctionalRequirements.....................................................................................21
5.1
5.2
5.3
5.4
5.5
PerformanceRequirements...........................................................................................................21
SafetyRequirements.....................................................................................................................21
SecurityRequirements..................................................................................................................21
SoftwareQualityAttributes..........................................................................................................22
BusinessRules..............................................................................................................................22
6. OtherRequirements..............................................................................................................25
AppendixA:Glossary..................................................................................................................25
AppendixB:AnalysisModels.....................................................................................................25
AppendixC:ToBeDeterminedList..........................................................................................37
SoftwareRequirementsSpecificationforTimesheets
Pageiii
RevisionHistory
Name
Date
ReasonForChanges
Version
ClockIn/Out
Timesheet
12/23/03
ShiftDifferentialemployeesmustentertimeina
waythatcanbecorrected,traced,andqueried.
R1.0
ApprovalHistory
Version
ReviewedBy
ReviewerTitle
Date
R1.0
ElainePeters
EmploymentManager
1/23/2004
SoftwareRequirementsSpecificationforTimeSheet
1.
Introduction
1.1
Purpose
DevelopawebbasedTimeSheetEntryapplicationallowingemployeestoselfenterhoursfor
payroll.Optionally,allowemployeestoenterhoursagainsttrackingnumberssuchasjobnumbers
orprojectinformation.Dependingondepartmentalpolicy,supervisorsorpayrollprocessorsmust
beabletoeasilyapprovehours,makecorrections,viewhistoricalinformation,andcreate
appropriatereports.SystemmustallowenduserstoimportorexportdatatoexternalsystemsatUC
IrvinesuchasGeneralLedger(GL)Uploads/Billing,Payroll/Personnel(PPS),MicroMan,andMS
Project.
Being such a strategically important functionality to multiple units on campus, the Timesheet
application will be designed for general campus use via SNAP however, implemented only for use by
Human Resources Campus Temporary Employment Services (CTES) and AdCom staff. Although the
first implementation will rely on AdCom technical infrastructure, the application will be designed to
be portable to other infrastructures.
1.2
IntendedAudienceandReadingSuggestions
This document is intended for Human Resources CTES Staff and AdCom developers and project
leaders to review.
1.3
ProductScope
The purpose of this product is to:

Reduce operational costs
Eliminate much of the dual data entry for timesheet management by allowing employees
to enter their own timesheet.
Allow quick editing and approval, reducing and simplifying the time cycle of processing a
timesheet
Records will be stored electronically, making it easier to review historical timesheets.
Ensure accuracy
Ensure timely payments/paychecks
Since Timesheet software is of interest to multiple business units on campus, including
CTES and AdCom, the intent of this project is to create a flexible system, that can be
customized in multiple locations.
In general the product scope focuses on streamlining time and attendance recording. It
will validate hours and such however, the focus is not on strict enforcement but on the
appropriate warnings, clearly indicated prior to approval. Too many details, such as
multiple appointments in multiple appointment type categories, complicate rigid
enforcement rules for this application to implement. The human approval process will be
required to manage the more complicated employee timesheet profile constraints.
1.4
References
Corresponding links or documents

1. Project Proposal
2. Project Charter document.
3. SNAP Channel development guidelines PowerPoint presentation.
4. CTES Functional Requirements document.
5. AdCom GUI standards.
2.
OverallDescription
2.1
ProductPerspective
This timesheet application will be a plug-in to the CTES system that is being upgraded from
FoxPro to web technologies and integrated with QuickTemp. As such, CTES staff describe the
requirements and interfaces in the CTES Upgrade Requirements document and Quicktemp
Enhancement Requirements Document.
2.2
ProductFunctions
2.3
Timesheet Data Entry by Self

Timesheet Data Entry by Payroll processor
Timesheet approval/rejection/correction with comments by Payroll processor or Timesheet
Supervisor
Job/Project Cost Tracking
Leave/Time Off Tracking
Notifications (i.e. Hiring Manager for CTES, Notification of CTES staff of hours near 1500,
notification of Employee that timesheet is due)
Reporting (including historical)
System Administration ( including setup of employee profile for exempt/non-exempt,
monthly/bi-monthly timesheet, copy of existing employee profile, job tracking, etc.)
Import of MicroMan (AdCom) Project, Phase, Activity, and Task numbers for tracking hours.
All recharge hours will be retrieved from the Timesheet database and not MicroMan.
OverTime approval by Supervisor
Manual PPS Update Report, including Time Reduction Report / Automatic feed to PPS
with data file (Phase II 7/2004 functionality ).
Manual adjustments of incorrect timesheets
Vacation time approval by Supervisor (future phase)
UserClassesandCharacteristics
Employees will self-enter work hours and time off hours. Supervisors or TimeSheet processors
will review timesheets and approve or reject them. Administrators of the system will configure the
appropriate style timesheet for each employee using templates.
2.4
OperatingEnvironment
The software will be implemented as a set of Java JSP pages running under Apache/Tomcat on a
Solaris SunFire 4800 hardware. Sybase will be used as a database backend.
2.5
2.6
DesignandImplementationConstraints
This application will need to interface with the CTES application as well as be used
together with project management in AdCom. CTES requirements must be wellunderstood before the TimeSheet application can be started.
The types of employees that will be doing self-time entry vary in profile and configuration
of template profiles can only be done after detailed analysis of the payroll requirements.
Although the application will use A&BS technical infrastructure such as SAMS
Authorization, Drala Workflow, SNAP Portal, and LDAP Directory Services, the technology
will be designed to be replaceable by local solutions for portability. This requirement will
not be implemented in Phase I though.
The interface to PPS will be manual in phase 1. However, phase 2 will automate a
TimeSheet upload to PPS. Consequently, the design of the TimeSheet must take into
account requirements of the PPS upload.
Time Entry accrual validation will use the UC Irvine Data Warehouse links to the PPS
system. This feature will need to be optional since not all environments support such
interfaces.
Microman is the project management tool in use in AdCom Services. All Project, Phase,
Activity, and Task numbers and resources (people) assigned are created and maintained
in MicroMan.
Maintaining supervisor information for TimeSheet approval is a challenge in our

environment since this information is currently not stored. A sharable supervisor table will
need to be created since there are other applications that currently need on the supervisor
information (ie QuickRec).
UserDocumentation
The following manuals will be created:

User Manual
Administrator Manual
Programmer Manual
2.7
AssumptionsandDependencies
If this application will be used in AdCom, the process by which time management is done will
need to be altered. Team Leaders currently use MicroMan to manage projects and report
rechargeable hours. The project numbers and task numbers, together with assigned
resources, are all tracked in Microman and the current paper Time Sheet is generated from
Microman. To replace this form with a web form, we must be able to export numbers and
resources from Microman and update the time spent on a task by the appropriate resources.
Although a general export of project tasks, resources, and hours will be provided, AdCom will
not import the hours back into Microman. All recharge hours will be retrieved from the
TimeSheet database. The window between the export of tasks and assigned resources and
import will be enough that if changes are made in Microman, discrepancies with the
TimeSheet will occur. This situation will need to be addressed in detail and possible process
changes implemented to make this project a success.
3.
ExternalInterfaceRequirements
3.1
UserInterfaces
A separate document exists that defines the employee, supervisor, payroll processor, and
administrator user interfaces. All reports are also identified.
3.2
HardwareInterfaces
None. In the future, Palm Pilot interfacing may be required.
3.3
SoftwareInterfaces
MicroMan or other such Project Management Tool.
SNAP
UCINetID/Password/WebAuth authentication
SAMS authorization
Drala Workflow
Data Warehouse (for validation of vacation and sick leave accruals, accounts/funds, job titles)
LDAP directory services
Sybase database
Apache Web Server
Tomcat Servlet Runner
3.4
CommunicationsInterfaces
All notifications will be done via email and Web Forms where necessary.
4.
SystemFeatures
Sequenceofevents:
1. HelpdesksetsupDepartmentalTimesheetDSAinSAMS.
2. DepartmentalTimesheetDSAconfiguresdepartmentalTimesheetdefaults,employees,and
supervisors.UsersaresetupbypullingdatafromPPSandCTESoutsideAgency.
a. Setupdefaultprofile,timeoff(vacationorsickleaveaccrualquery)foreachuser
b. Setuprolesandaccessprivileges
c. SetupjobnumbersviaCTESorprojectsviaMicroMan
d. AssignuserstoprojectsviaCTES
e. Setbillingratesormarkup/rechargerates
3. Employeeselfenterstime
4. Supervisorortimesheetprocessorapprovesorrejectstimesheet.
5. PayrollProcessorupdatesPPS(manuallyuntilphase2wheretherewillbeanautomatic
uploadtoPPSviaanFTPfile).
6. Althoughnotthescopeofthisapplication,ifbillingoftimeisrequired,aGLbillingor
rechargeinterfacecanbeimplemented.
7. Generatereports.
4.1
SystemFeatureProfilesetupforemployeewhowillfilltimesheet.
Thesystemmustallowanadministratortosetuptheprofilewiththefollowingrequirements:
REQ4.1.1Employeeprofilecanbecopiedfromexistingemployeeoradefaulttemplate
REQ4.1.2Employeemaybebimonthlyormonthlypay.Timesheetmayneedtobefilled
outeveryweek,every2weeks,ormonthlydependingondepartmentalrequirements.A
profilemustallowapersontobesetupforBiWeeklyorWeeklytimesheets.Defaultfor
CTESemployeesisbiweekly.Amonthlyprofile,allowingapersontoenter4weeksof
timebeforesubmittingatimesheetwillnotbearequirementatthistime.
REQ4.1.3EmployeeinformationwillbepulledinfromDWHwherenecessary.Only
campus_idandhistorywillbestoredlocally.Basedontheappointmenttypeandother
factors,theemployeewillorwillnotbeallowedtoworkovertime.SeeBusinessRules
below.
REQ4.1.4Aprofileyes/noflagshouldindicatewhetherapersonisallowedtoenter
overtime(over40hoursperweek)ornot.Anotherprofileflagshouldindicatewhether
SupervisorApprovalisrequiredpriortotakingovertimeorNot.
REQ4.1.5Employeeprofilemustbeconfiguredtoallowexceedingtheaccrualamounts
onspecificperiodsthroughouttheyear.Forexample,campusfloatersarenotallowedto
workduringtheChristmasbreakbutareallowedtotakenonaccruedvacationhoursin
advance.MedicalCenteremployeesmayberequiredtoworkoverChristmasbreak.We
mustallowblockoffperiodswheresay,betweenDecember23rdandJanuary2nd,employees
areallowedtoexceedaccrualvacationhours.Warningwouldbeissuedonly.Allother
timesoftheyearthisactivitywouldbedisallowed.
REQ4.1.6Profileflagtoindicatewhetherapersonisallowedtoworkweekends.
REQ4.1.7Profileflagwhetherapersonmustobtainapprovalbeforetakingvacation
(futurerelease).
REQ4.1.8Profileflagwhetherapersonisallowedtoworkholidays.
REQ4.1.9Profileflagtoindicatewhenthetimesheetisdue.
REQ4.1.10Listofjobnumbers,project/tasknumbers,ortrackingidsthepersoncanlog
hoursagainst.
REQ4.1.11Active/InactiveflagindicatingwhetherapersoncanuseTimeSheet.
REQ4.1.12Contactinformation
REQ4.1.13Normalschedulednumberofhoursperweek.
REQ4.1.15Profileflagtoindicatewhethersickleaveisallowed.
REQ4.1.16Daysofweektimesheetbeginsandends(perioddates).
REQ4.1.17SetSupervisorofemployee(inLDAPdatabaseusingGUI.)
4.2
SystemFeatureEmployeeSelfentryoftime
4.2.1 TheselfentrytimeentryforbiweeklyemployeeswillbedoneviaSNAPwith
followingGUIs:
Weeklyemployeeswhoneedtoaccountforovertimebutnoshiftwillusethefollowingscreen:
Employees who must account for overtime or shift differential will use the following
timesheet, indicating the clock in/out time:
Time is entered in 15 minute intervals, on the quarter hour. Validate occurs to help
employees enter their time in correct intervals.
CTES Agency Employees, not being normal employees, will have their time entered by the
CTES personnel into the following timesheet:
An example of clock in/out time entry screen that may be implemented in a future phase,
as required is:
4.2.1.1 DescriptionandPriority
The timesheet is presented to the user to fill out prior to the timesheet submittal
deadline via a SNAP window. Priority = High.
4.2.2
Stimulus/ResponseSequences
Once the user clicks Save But Do Not Submit for Approval, the user submits the
timesheet as in progress. They can work on it until the deadline for submittal. Once
submitted for approval, the employee can no longer change the timesheet. The
supervisor must review and approve or reject the time sheet. If the timesheet is
rejected, the employee will be allowed to edit the timesheet again if configured to
allow self-correction. If the manager makes any changes to the timesheet and the
approves it, the employee will be notified in email.
The user has access to all reviewed timesheets (approved and rejected) via a
report.
4.2.3
FunctionalRequirements
REQ4.2.1: If the DisplayAccruals flag is set to Yes in the employee profile, the
timesheet will display accruals on the top right hand corner (and use Javascript to
validate time entry against accruals.) Medical Center Floaters may work during the
Christmas break and can not take accruals in advance. Main Campus employees
can take advance accruals however, a warning must be issued. The job location
and fund code will determine if accruals can be exceeded during special times of
the year, as configured by the Timesheet Administrator.
REQ4.2.2: The user will automatically have the Period date set and the calendar will
be displayed with the holidays filled in per formula in:
http://www.accounting.uci.edu/payroll/Holidaypay.htm
REQ4.2.3: Only job tracking ids that the user is allowed to track hours on will be
displayed and the employee can select which job to log hours against.
REQ4.2.4: Save but do not Submit for Approval will be a button that the employee
can click to save the timesheet before completion.
REQ4.2.5: Submit for Approval will be a button that, once clicked, submits the
timesheet to the supervisor or payroll processor. Once clicked, the timesheet can
no longer be edited by the employee. An error message will be displayed to the
user if they have not completed filling in their timesheet with the percent hours that
per PPS normal work hours (for example, a person at 50% time should work 20
hours per week. total != 20 would produce an error message). The user can then
either override and submit or correct the timesheet.
REQ4.2.6: The timesheet, if rejected, will re-appear in the SNAP window if self
correction in the profile is allowed. The employee will be notified in email to edit
and resubmit the timesheet. In the email, a URL will point to the exact timesheet
that must be corrected.
REQ4.2.7: Handling of late timesheets will be configuration dependent. For CTES,
employees will not be paid until their timesheet is submitted. If late, their timesheet
is locked and they must call CTES to have it unlocked. For AdCom, if the timesheet
is late, it will automatically be submitted for approval and if necessary, the
supervisor or payroll processor will fill it in. All locked timesheets will be clearly
identified for the employee, along with a phone number to call or appropriate next
action to take.
REQ4.2.8: The employee will be able to view all timesheets, rejected and
approved, with all journal and comments unless separated from the campus.
REQ4.2.10: Accruals as of the timesheet submission and approval will be stored for
historical reporting and viewing.
REQ4.2.11: It must be easy for the employee to mark multiple days for vacation
instead of individually marking each day taken for vacation. Start date and end
date and number of hours each day as a user interface to enter vacation is
required.
REQ4.2.11: The employee can pull up a previous timesheet as a template for the
new timesheet (a copy).
REQ4.2.12: Payroll Processor or TimeKeeper will see all.
REQ4.2.13: Future timesheet hours for projecting vacation, etc be handled at this
time by providing the employee with a drop down of future timesheet periods.
REQ4.2.14: Overtime must be pre-approved. If approved, it will be displayed on
the timesheet along with the appropriate data entry option, listing the tracking_id
(job) that the overtime was approved for, which start/end dates, and how many
hours. By default, no option for entering overtime is on a timesheet. If an
employee works over the normally scheduled hours, as set by their profile or PPS,
and they have approved overtime, they must be presented with a question of
whether they want to log overtime or not. If the answer is no, they will be returned
to the timesheet to continue to edit it. If the answer is yes, they will then be
prompted whether they want to take the overtime hours as payed overtime or as
comp time. The Overtime Request and Status forms are displayed below.
4.3
REQ4.2.15 The timesheet title, message, and contact information must be

configurable.
REQ4.2.16 - A link to the PPS Pay Period and Pay Schedules must exist from the
timesheet.
REQ4.2.17 A profile flag should indicate whether to display a calendar for the user
or not..
REQ4.2.18 Validation of hours against normal schedule will be profile dependent.

If the profile indicates ValidateHours=Yes, then a NormalWeeklyWorkHours would
have to be filled in or PPS hours used for validation and the user would have to OK
a warning dialog box that the hours on the timesheet do not match the normal work
week hours.
REQ4.2.19 - All hours must be in increments of .00 .25, .5 or .75. An error

message must indicate if the hours are outside of the acceptable increment.
REQ4.2.20 - Comments will only show up when they exist.
SystemFeatureManagerApproval/Reject/EditofTimesheet
Thetimesheetwillbeapprovedbyasupervisororpayrollprocessorwiththefollowinginterface
example:
ThelinktoemployeedetailtimesheetonthisscreenwillallowtheCTESTimesheetmanagerto
alteranemployeestimesheet.Notificationwillgoouttotheemployeeinthisevent,with
comments,documentingwhatchangesweremade.
REQ 4.3.1: Once entered into a system and uploaded to PPS, the timesheet data may not
be altered in any way. Any changes to historical hours must be credited and debited
rather than updated. Only the TimeKeeper (Payroll Processor) can edit a closed
timesheet. PPS must be manually synchronized with the Timesheet database by first,
entering the credit/debit into the TimeSheet application, then updating PPS as necessary.
The timesheet that must be edited can be found using a QuickTemp screen example as:
The result brings up a list of timesheets, alphabetized by employee names, sorted on pay
period dates.
Individual timesheets can then be edited. Any hours changed get reflected in the system by a
back out of the original hours and new records added for the same work date, with the correct
hours and hour types.
REQ4.3.2:Summaryapprovalofthetimesheetwillbethedefault.Inotherwords,as
opposedtoeachindividualsetofhoursrecordedagainstajobnumberorhourtypebeing
approved,theentiretimesheetwilleitherbeapprovedorrejected.
REQ4.3.3IfanerroroccursandtheApproverorTimekeepermustmakechanges,she/he
willclickonTimesheetPeriodandchangethetimesheetthatwasoriginallysubmitted.
She/hewillberequiredtoaddcomments.Anotificationwillgoouttotheemployee
indicatingallchanges.
REQ4.3.4TheapprovallistingmustallowtheTimekeeperorApprovertoviewthejob
assignmentdetails,employeedetailsandprofile,andtimesheetdetails,notes,andhistory.
4.4
SystemFeatureAdministration
REQ4.4.1RoleassignmentviaSAMSHelpdeskassignsTimesheetAdministrator
foraFinancialOrganizationalHierarchy(Department,SubDivision,Division,or
Organization.)
REQ4.4.2DepartmentalTimesheetAdministratorsetsthefollowfunctionsinSAMS
fortheirdepartment:
1. TimesheetReviewer
2. TimesheetApprover,Rejector
3. TimesheetModifier(cancorrecttimesheets).
Typically,adepartmentwillassignapersontooneormoreofthefollowingroles:
TimeKeeper(PayrollProcessorusually)reviewsforcorrectness,tracks
attendance,hours.EnterstimeintoPPSforpaycheckinphase1forallapproved
timesheets.ReviewsandsubmitsFTPfileforPPSuploadinphase2.Exportsor
importsdatafromexternalsystems,suchasMicroMan.
SAMSFunction:TimesheetReviewer
Supervisorcanreview,approve,orrejectatimesheet.Maybeallowedtoedit
timesheetsifaccesstodosoisallowed.ForCTES,thesupervisorcanonly
reviewatimesheetandapproveovertimeandgetsanelectroniccopyofthe
timesheetonceitisapprovedbytheCTESprocessor.
SAMSFunction:TimesheetReviewer(forCTES)
SAMSFunction:TimesheetApprover/Rejector(forAdCom)
SAMSFunction:TimesheetModifier(forAdCom)
TimeSheetApprovercanapproveorrejecttimesheet.
SAMSFunction:TimesheetApprover/Rejector
TimeSheetModifier
SAMSFunction:TimesheetModifier(forAdCom)
Employeeenterstimesheet.SupervisorissetinLDAP.
NoSAMSfunctionrequired
SubAdministratormanagesrequiredfields.
SAMSFunction:TimesheetAdministrator
setsupexpensereportingbysettingupthejobnumbersanemployeeis
allowedtologtimeagainst.Setupanyrequiredimportsforthesetracking
ids.SpecifieswhichjobsarebillableusingconfigurationflagYesorNo.
setsupdefaults,employeeprofiles,holidays,payrate/rechargerates.
dataExportandImportmappingsandformats,ExcelDownloads.
requiredreports
definesaccesscontrol.
4.5
SystemFeatureReports
Thefollowingreportsmustbegeneratedfromtimesheetapplication:
10
11
12
REQ4.5.1TimeSheetStatusSummary
REQ4.5.2StatisticalReport
REQ4.5.3ReportthatallowsthepayrollprocessortoquicklyupdatePPSmanually,
untiluploadautomated.Allupdatedrecordsmustbecheckedbythepayrollprocessorto
flagwhichrecordshavebeenupdatedinEDB/PPS.Itwilllooklike:
4.6
13
REQ4.5.4Attendancereportlistingsummaryanddetail.
REQ4.5.5AdHocreportingwithExcelDownload
REQ4.5.6ApprovedReports,RejectedReports
REQ4.5.7Billablehoursforrechargesonprojects.
SystemFeatureSupervisorFunctions
4.7
REQ4.6.1ApproveOvertimeHours
REQ4.6.2ReviewTimesheet
REQ4.6.3ReviewHistoricalTimesheetDetails
REQ4.6.4ReviewInvoices/Billing
SystemFeatureNotifications
REQ4.7.1SeeCTESUpgradeRequirement4.8SystemFeatureNotificationsforCTES
specificnotificationrequirements.
5.
OtherNonfunctionalRequirements
5.1
PerformanceRequirements
All transactions (not reports) must return within 2 seconds of a submit event. Reports must be
within 30 seconds of a submit event.
5.2
SafetyRequirements
NA
5.3
SecurityRequirements
All timesheet entry will be done only after the user has successfully authenticated.
Home addresses, etc will not be stored in any database. No social security numbers are needed.
Timesheet is considered private data and only accessible via an access controlled list.
5.4
14
SoftwareQualityAttributes
The Timesheet application must be very intuitive and useable without training.
5.5
BusinessRules
5.5.1
BusinessRules:General
o
o
o
o
o
A timesheet administrator will set up appropriate employee profiles

A timesheet administrator will set up the appropriate job tracking numbers an employee
can log time against (CTES functionality added to QuickTemp)
If the DisplayAccruals flag is set to yes in the employee profile, Vacation and Sick
Leave Accruals will be displayed on the timesheet. They are accrued per calculation in
http://www.accounting.uci.edu/
DWH/PPS query will return the official record on vacation, sick leave, and hour
accruals for display and validation. The Leave Accrual Code from DWH indicates
the accrual rates.
Holiday pay is paid based on the number of hours worked in a given holiday month.
An employee normally earns 8 hours holiday for every 136 hours of work. The
timesheet application should retrieve from the DWH the accrued hours of work.
Holiday hours are displayed by default on holiday days. Holiday hours are calculated
depending upon the hours the employee works see
http://www.accounting.uci.edu/payroll/Holidaypay.htm Per University policies, for
biweekly employees, if a holiday falls in a B1 period, the holiday hours are accrued in
the B2 period immediately following the holiday period; if the holiday falls in a B2
period, the holiday hours are accrued in the same B2 period.
o
o
Holiday hour accruals are not available in PPS. They must be calculated.
The application will validate hours with basic checks for:
Hours over 24 hours in a single day
No more than 40 hours sick leave, vacation per week.
Hours under or over % as reflected in PPS will generate an error/warning that
either the timesheet is incomplete or requires overtime approval.
No hours over the accrued vacation and sick leave per DWH query.
Disallow hours logged against holidays per profile, if unauthorized.
All hours must be categorized (not left blank) and, if required, assigned to job
tracking identifiers
A floater employee must be notified of benefits eligibility after they have attained the
Mid-level requirements: 100% hours full time for 90 days or 50% hours full time for 6
months. By default, all floaters are at Core Benefits (Dental, life, only). All limited
employees have Mid Level benefits by default. CTES hires only floaters as of this
time.
Only the supervisor or payroll processor can view, approve, reject, or edit a timesheet
on behalf of an employee.
An employee must be able to log hours only against job tracking numbers that they are
allowed to work on.
No hours can be logged against job tracking numbers that are considered closed.
o
o
o
o
o
o
o
o
o
o
o
o
o
o
5.5.2
15
An employee can work on a timesheet until they decide to submit it for approval. Once
submitted for approval, the employee can not alter the timesheet.
The supervisor or payroll processor must approve or reject the timesheet. If rejected,
comments must be provided.
If the supervisor or payroll processor must edit the timesheet, a journal must be
created and they must identify the edits.
Once submitted to PPS, all changes to hours must be in the form of credit/debit on a
new payroll transaction.
An employee must be notified immediately if the timesheet is rejected and reason for
rejection. The status on the timesheet must be reset to in progress to allow the
employee to edit it.
The employee is notified to turn their timesheet in 12 hours in advance of the deadline
( or any other admin configurable number of hours)
If late, if the configuration for AutoSubmit=Yes, the timesheet automatically is
submitted for the payroll processor or supervisor to fill in. The employee will not be
able to edit the timesheet for that pay period anymore. If the AutoSubmit configuration
is No, the timesheet will remain unsubmitted (and unpayed).
The employee, payroll processor, and supervisor can all see historical records of their
employees. If they are removed from their role, they must no longer have access to
the data.
Employee must always report the total number of hours worked in each pay period
(and how many hours worked each day). That is, hours can not be banked in one
month and reported on in a future month's timesheet.
The work week is usually defined as beginning Monday morning at 12am and ending
on Sunday at 12 midnight.
Overtime (Only applies to non-exempt)
Overtime is defined as working more than forty hours during the work week and
is usually paid at time and one half. If vacation is taken, that time can not be
counted towards over time.
Overtime must be pre-approved by a supervisor. This feature will be
implemented at a later stage in the development of this application if the
deadline is difficult to meet.
For holidays, non-exempt staff will only get paid overtime pay (time and a half)
if they are "required" to work on the holiday, get supervisor approval, and work
over 40 hours, not counting holiday, vacation, or leave hours.
Overtime formula: Time over 40 hours paid as time and half OTP (no sick leave,
vacation or holiday during that week) If during a week where employee worked
the holiday, pay them 40 hours regular; 8 hours Overtime Standard (OTS).
Overtime Premium (OTP) is anytime over 48 hours per week.
BusinessRules:CTESTemporaryEmployees
o
o
o
o
o
By default, all CTES employees are Floaters, not Limited. As such they do
not have Mid-Level Benefits (dental for example). They are Core Benefits
eligible only.
Only the Timekeeper in CTES can approve the timesheet. The Supervisor of
the employee will review the timesheet after it is approved.
Only the Supervisor of the employee can approve overtime hours.
Vacation is in PPS and paid out to the employees as they use it and at the time
of separation.
Vacation and sick leave can only be accrued after a B2 Cycle.
16
Sick leave and holiday is recharged to a department so all such hours must be
logged against a tracking_id (job number for CTES).
o Vacation is payed from a CTES account/fund.
o Jury duty is not paid to floaters.
o Holiday
The system must split the holiday hours between the jobs if an
employee works in 2 departments. For example, 50/50 if the ratio is half
time.
Holiday is calculated after the hours for the month have been submitted,
even though a holiday could occur at the beginning of the month, i.e.
July 4, January 1st, etc.
Holiday accruals are not available in PPS.
o CTES/Timesheet will NOT need to store SSN#.
o FMLA will be an option for CTES leave in Phase 2. Need to calculate hours
worked within a 12 month calendar year, across all appointments by doing a
DWH Payroll/Earnings/Expense query. Non-exempt employees (employees
eligible fo premium overtime) are eligible if they have worked a total of at least
12 months and for at least 1,250 hours, including overtime hours for scheduled
employes, during the 12 months prior to the start of the leave.
o Hours in a particular assignment, on a job title code with a particular bargaining
unit must be tracked.
The system must notify the payroll processor if a floater employee has
worked 24 months for CTES OR is approaching 1200 hours in specific
job titles/bargaining unit since past 1500 hours, a temporary employee
automatically becomes permanent. For Limited employees, the rule is
1000 hours of work automatically transfers them to Career status.
Multiple email messages will be sent.
----- Added November 14, 2003 by Warren Liang -----o For employees with concurrent multiple assignments, the employee may not
enter overtime for that pay period.
o If an employee takes leave on a certain day, no overtime is allowed for that day.
o Hours that are actually worked on an University holiday are considered to be
OTS, but in the event that more than 40 hours in the week are worked,
o
5.5.3
PPSProfileSpecificBusinessRulesforTimeEntry
Based
on :
Employee Status (Active, Separated, on Leave, etc)
Student Status (indicating a student and type)
Appointment Type Code (Career, Floater, Casual, Contractor, etc)
FLSA Flag (Exempt/Non Exempt) indicates if the employee is can take overtime. This
is a derived field in PPS and is based on the title_code so is accurate as long as the
title_code is accurately entered and maintained for the employee by the departmental
payroll processor.
Appointment Representation Code (Covered/ Not Covered by Union which is an
attribute of the TitleCode/Title Unit Code).
Percent-FullTime indicates the normal scheduled hours per week for validation.
Payrate indicates the normal pay for the employee
17
Rate_code indicates whether the payrate is hourly or a monthly salary.
Problem: Multiple appointment types per individual. Must also save all state information
at timesheet entry time for future referral and audits.
1. Student indicated by Employee Status field
A student employee can not work more than 19.5 hours per week during the academic
year.
A student can not exceed 39.5 hours per week during the summer. If a student needs
to exceed that amount from time to time, prior approval from supervisor must be
received.
Must turn in timesheet weekly.
Non-Exempt - by FLSA Flag
2. Floater (CTES)
The Main Campus CTES temporary employee will be shown accrued vacation on the
timesheet however, will not be able to take excess except at specific periods during the
year, configurable by the Timekeeper (Admin) Christmas break is one such period.
Medical Center employees work through the Christmas break and so do not have the
option to take accruals in advance.
Must turn in timesheet weekly.
No AutoSubmit allowed for CTES employee timesheets. They will NOT get paid if they
do not submit a timesheet.
Non-Exempt by FLSA Flag
3. Limited
Non Exempt by FLSA Flag
4. Casual/Restricted
Non Exempt by FLSA Flag
5. Career/Regular
6.
7.
8.
9.
Contractor
Partial Year/Career
Per Diem
Academic
6.
OtherRequirements
AppendixA:Glossary
Bi-Monthly/Monthly
B1
B2
Exempt
NonExempt
Temporary Employee
AppendixB:AnalysisModels
Data Model
Limitations and constraints: A person can have only one timesheet profile at any one time,
regardless of the appointment type or jobs they are employed at. The reasoning is that it would
be difficult for an employee to manage multiple timesheets. For example, if vacation hours and
such are to be validated, it is difficult to do across multiple timesheets.
18
qt_timesheet_profile
PK
qt_overtime_type
timesheet_profile_id
PK
see page 2
PK
PK
campus_id
effective_date
FK1
current_flag
PK
journal_detail_id
overtime_type_description
FK1
FK2
timesheet_detail_id
journal_type_id
notes
created_by
created_date
PK
timesheet_id
FK1
campus_id
period_start_date
period_end_date
timesheet_status_id
approved_by
approved_date
reviewed_by
reviewed_date
created_by
created_date
updated_by
updated_date
effective_date
FK1
qt_timesheet_detail
PK
timesheet_detail_id
FK1
FK3
timesheet_id
tracking_id
date_worked
hours
hour_type_id
overtime_type_id
labor_type
billable_flag
billed_flag
billed_date
invoiced_flag
invoiced_date
PPS_updated_flag
PPS_updated_date
gl_update_lock
invoice_update_flag
pps_update_lock
created_by
created_date
updated_by
updated_date
FK2
FK4
qt_timesheet
qt_timesheet_detail_journal
overtime_type_id
qt_employee_timesheet
FK2
19
qt_journal_type
PK
journal_type_id
journal_type_description
qt_clock_in_out
PK
clock_in_out_id
clock_in
lunch_start
lunch_end
clock_out
campus_id
date_worked
qt_hour_types
PK
hour_type_id
qt_overtime_approval
hour_type_description
PK
qt_timesheet_journal
PK
journal_id
FK1
timesheet_id
state
notes
created_by
created_date
qt_timesheet_status
PK
timesheet_status_id
timesheet_status_description
qt_tracking
PK
tracking_id
tracking_description
tracking_level_1
tracking_level_1_desc
tracking_level_2
tracking_level_3
tracking_level_4
tracking_level_5
created_by
created_date
updated_by
updated_date
FK1
ot_approval_detail_id
campus_id
start_date
end_date
tracking_id
hours
hour_type_id
overtime_type_id
created_by
created_date
updated_by
updated_date
approved_by
approved_date
20
qt_profile_allowed_hour_types
qt_timesheet_profile
PK,FK1
PK
PK,FK1,FK4 timesheet_profile_id
FK2
FK3
21
profile_name
profile_description
comments
display_title
display_message
footer_message
help_message
time_entry_choice_id
timesheet_type_id
clock_in_out_flag
period_start_day_of_week
period_end_day_of_week
deadline_day
deadline_reminder_hours
lock_late_timesheet_flag
late_auto_submit_flag
daily_hour_limit
daily_hour_limit_label
validate_hours_flag
weekend_time_allowed_flag
holiday_time_allowed_flag
overtime_allowed_flag
approval_frequency
approval_type
approval_query
display_accruals_flag
accrual_query
tracking_id_type_level1_label
display_empty_tracking_lines
display_pay_schedule_link_flag
pay_schedule_URL
smtp_server
return_email_address
rdbm_connection_properties_file
hour_type_id
active_flag
effective_start_date
effective_end_date
qt_accrual_validation_exclusion
PK
accrual_validation_exclusion_id
accrual_validation_exclusion_start_date
accrual_validation_exclusion_end_date
comments
qt_profile_accrual_validation_exclusion
PK
FK1
accrual_validation_exclusion_id
active_flag
effective_start_date
effective_end_date
qt_time_entry_choice
PK
time_entry_choice_id
time_entry_choice_name
time_entry_choice_description
qt_timesheet_type
PK
timesheet_type_name
qt_employee_schedule
PK
timesheet_type_id
campus_id
normal_hours_per_week
effective_begin_date
effective_end_date
current_flag
qt_timesheet_question
PK
FK1
question_id
question
answer_format_type
qt_question_answer_type
PK
question_id
answer_choice
default_flag
22
Qt_timesheet
A timesheet is entered into the qt_timesheet table with the period_start_date and
period_end_date indicating the dates for which the worked time is recorded.
Campus_id identifies the employee logging the hours.
The qt_timesheet table can have one more more time detail records, stored in
qt_timesheet_detail.
The timesheet_status_id indicates the status of the timesheet. Timesheet_status_id can
be one of Open, Submitted for Approval, Open-Rejected, Approved, Late Auto
Submitted for Approval, and Closed. It is the current state of the timesheet, as reflected
in the qt_timesheet_journal.state column.
o Open means the timesheet is in a state that the employee can add time to it.
o Submitted for Approval means that the timesheet can no longer be changed by
the employee, only the supervisor or payroll processor.
o Open-Rejected indicates that the timesheet can again be edited by the employee.
o Approved means the payroll processor or supervisor have approved the
timesheet hours and the timesheet is ready for any bill or invoice processing.
o Late Auto Submitted for Approval indicates the timesheet is delinquent and
submitted automatically by the system.
o Closed state should be set once the timesheet invoicing or billing is completed.
The qt_timesheet_journal table stores every state change on the timesheet with any
associated notes. It is used for logging changes.
Once approved, the approved_by and approved_date are entered into this table.
Approved_by is the campus_id of the approver. The timesheet can no longer be changed
by anyone. Only credits and debits can be applied to make changes.
Qt_timesheet_ journal
The qt_timesheet_ journal is the table that stores all state information changes about the
timesheet.
A Note is required for any timesheet change.
The state can be one of any Timesheet_status_ids it is a history of all events on a
timesheet for auditing purposes.
Qt_timesheet_detail
Date_worked indicates the day the hours were worked.

Hours are defaulted to 8.
Hour_type_id is defaulted to Regular hours. Can be Vacation, Sick Leave, and so on, as
allowed in the profile.
The tracking_id identifies the job or project tracking information via a link table.
Overtime_type_id indicates that if the employee worked overtime, how they would prefer
to take the hours comp time or with pay.
Labor_type indicates can be one of Regular, Shift, or Graveyard.
Billable_flag indicates whether this time should be billed. Default=No. Can be one of No
or Yes.
23
Billed_flag indicates that if the billable_flag =Yes, meaning the time should be billed, that
this record has been correctly billed. It is set to No by default. Once the timesheet is
approved, any required billing can start. Once the billing cycle is started, the flag should
be set to In_Progress meaning the record can no longer be updated. The timesheet can
be altered only while the billed_flag=No. When the billing cycle is run, the billed_flag must
be set to Yes. Once it is set to Yes and a change needs to be made, a credit and debit
must occur for billing. Only the timekeeper has the authority to create this kind of
transaction. PPS and Timesheet database must manually be synchronized.
The billing_flag can be set to In Progress and Yes only if the
qt_timesheet.timesheet_status_id=Approved.
Billed_date is the date when the payroll transaction is billed.
Invoiced_flag and Invoiced_date indicates that the invoices have been sent to the
department.
PPS_updated_by, PPS_updated_date indicates that the hours have been loaded into
PPS (manual in phase1, automatic file upload in future phase).
Created_by is the campus_id by default.
Created_date is the date the record was created in the database.
Updated_by is the campus_id of who last touched the record.
Updated_date is the date the record was last updated.
Gl_update_lock indicates that the gl upload is in progress so the record must not be
altered.
Invoice_update_lock indicates that email is being sent to department so the record must
not be altered.
Pps_update_lock indicates that the PPS Update is in progress so the record must not be
altered. The processor will click a button to indicate that the records can be altered.
NOTE: Changes to this detail can be made any time before the monthend processing
starts. Once the processing starts, this record must be locked from all changes. Once
completed, the record is unlocked and free to be altered however, ONLY via 2 new
records, one backing out the previous record and a new one creating a new record. This
must be done both for the ledger and the PPS Update functionality to stay in sync.
Qt_timesheet_detail_journal
The qt_timesheet_detail_journal is the table that stores all state information changes
about the timecard detail.
A Note is required for any timesheet change.
If approval of each hour in timesheet_detail is required, the journal_type_id can be set to
Approved, Rejected, and so on, to reflect the lowest level of granularity of tracking hours.
This id can be of the same type as timesheet_status_id in qt_timesheet.
Qt_employee_timesheet
The qt_employee_timesheet table binds an employee to a profile. The profile is used to
display the appropriate timesheet for an employee to use. An employee may have multiple
profiles across time and the most current, active profile is flagged by current_flag=Yes.
The effective_date indicates the date at which point the profile was used by the timesheet
application.
Qt_tracking
The qt_tracking table links the timesheet tracking_id with the billing, job ticket, or project
management system. If hours need to be categorized by projects, tasks, or job numbers,
this table is used to allow the employee to log hours against them.
24
Qt_overtime_approval
Overtime must be approved via the qt_overtime_approval table. Overtime can be worked
only between the start_date and end_date that has been approved for a specific
tracking_id that is identified by the qt_tracking table.
Qt_clock_in_out
This table is designed for timesheets where an employee must clock in when they get to
work, when the leave for lunch, when they come back from lunch, and when they leave for
the day. This table will not be implemented within the scope of the current application but
serves as a placeholder for future requirements if lunch tracking is required in a timesheet.
Qt_hour_types
The qt_hour_types table lists the categories of hours an employee can log time against.
Valid values are:
o Administrative
o Supervision
o Training
o Admin Use Only
o Vacation
o Sick Time
o Family Sick Leave
o Comp Time Taken
o Comp Time Earned
o Over Time
o Leave Without Pay
o Jury Duty
o Holiday
o Death Leave
o Military Leave
o Voting Time Hours
Qt_overtime_type
This table stores the overtime types. It can be one of:
o Regular
o Call-Back
o Less than 24 hour notice
o On-Call
Qt_timesheet_profile
The qt_timesheet_profile table stores basic information that defines a timesheet for an
employee or group of employees.
Profile_name is what is displayed on the choicelist of profile selections when choosing a
profile for a new employee and a template is desired or a copy of a pre-existing employee
profile. Default Timesheet indicates a template that is widely used. CTES Bi-weekly
Timesheet is an example name.
Profile_description is a short description of the timesheet. It could be
Timesheet that is the default for the installation or something like CTES Bi-weekly
Timesheet used by UC Irvine Human Resources Temporary Employees.
Display_title indicates what the label should be at the top of the
25
Timesheet form. Example: UCI Campus Temporary Employment Services Bi-Weekly

Time Sheet
Display_message indicates any message to display after the title. It can be multiple lines.
Example: "TimeSheets must be submitted every other Monday - by Noon. Based on the
UCI Bi-Weekly Pay Schedule. Please click on Save Work to continue working on your
timesheet. Click on 'Submit for Approval' once completed."
Footer_message indicates text to display at the bottom of the timesheet. Example:
Please call (949) 824-8500 for assistance.
Help_message indicates the message to display in case the system has an error and must
generate an error message to the user.
Time_entry_choice_id can be one of ManualFill work hours or ExceptionOnly reporting.
ManualFill hours means that a user must explicitely enter the number of hours they
worked each day. No defaults are provided. ExceptionOnly work hours would auto fill
scheduled hours per day and assume there is no vacation, sick leave, or other leave. It
will be up to the user to record vacation, sick, and other leave. The default is ManualFill.
Timesheet_type_id indicates whether the timesheet must be filled out weekly, twice per
month or monthly. Usually, one or two checks are generated per month depending on
whether the employee is is set up as bi-weekly or monthly in PPS. The valid values are
Monthly, Bi-Weekly, or Weekly. The default is Bi-Weekly.
Clock_in_out_flag indicates whether the timesheet should be displayed with the Clock-In
Time, Lunch Start Time, Lunch End Time, and Clock Out time. Breaks are not handled.
This configuration is used primarily by employees whose unions require us to track lunch
leave and break leave. The default is No.
Although PayPeriodBegineDate and PayPeriodEndDate are defined in a PPS table the
Day of week for the dates are defined by period_start_day_of_week and
period_end_day_of_week for display of the Timesheet form. PeriodStartDayOfWeek
identifies the day of week for which the timesheet should be started. Most timesheets
start on Sunday at midnight and End on Saturday at 11:59 pm (7 days). This is the first
day displayed on the Timesheet week. PeriodStartDayOfWeek=Sunday
PeriodEndDayOfWeek identifies the day of week for which the timesheet should be
ended. Most timesheets end on Saturday at 11:59 pm (7 days). For weekly timesheets,
this is the first Saturday. For Bi-Weekly timesheets, it is the second Saturday after the
PeriodStartDayOfWeek This is the last day displayed on the Timesheet week. The default
PeriodEndDayOfWeek is Saturday.
Deadline_day and deadline_reminder_hours - Depending on whether the timesheet is
Weekly, Bi-Weekly, or Monthly,the Deadline_day and DeadlineReminder_hours will be
effective every week, every two weeks, or every month respectively.
Deadline_day defines the deadline day of week and time in dayofweek:HH:MM format.
dayofweek must be one of: Monday Tuesday Wednesday Thursday Friday Saturday
Sunday. Use military time for afternoon. For example Friday afternoon at 4 pm would be
Friday:16:00. Depending on whether the employee is weekly, bi-weekly, or monthly, a
reminder will be set accordingly, per DeadlineReminder_hours hours.
Deadline_day=Monday:11:59. DeadlineReminder_hours defines the number of hours
before the deadline to send a reminder to employee to fill in timesheet. 75 hours indicates
to send the reminder at 9 am Friday morning if the Deadline_day is set to Monday:11:59
(am). The default deadline_reminder_hours=75.
After the deadline_day, the timesheet will be locked from any edits by the employee if
lock_late_timesheet_flag is Yes. If No, no locks are placed and the employee can
continue entering time. The default is Yes.
The daily_hour_limit restricts daily time entry. A value of 0 indicates no limits.
daily_hour_limit_lable is the display name. This value applies to all forms of hours vacation, sick, work...Daily_hour_limit_label=Maximum limit of hours entered per day is
Daily_hour_limit=24
26
validate_hours_flag indicates whether the system should validate the hours against the
normal work hours as specified by the PPS system or by the ScheduledHours if they have
been set up in the qt_employee_schedule table. The default value is No.
weekend_time_allowed_flag indicates whether the employee is allowed to log time over
the weekend, regardless of supervisor approval. The default is No.
holiday_time_allowed indicates whether the employee is allowed to log time over the
holidays, regardless of supervisor approval. The default is Yes.
Overtime_allowed_flag indicates whether approval must be granted before overtime can
be logged in the timesheet. The default is No.
Approval Handling is defined by the combination of approval_frequency, approval_type,
and approval_query.
Approval_frequency defines whether approvals are done on a weekly basis, bi-weekly
basis, or monthly. The default is Bi-Weekly. Based on this value, a timesheet consisting of
1 week, 2 weeks, or monthly must be submitted at this frequency by the employee. In
other words, regardless of when the employee clicks on the "Submit for Approval" button,
the approval will only be done with the frequency indicated by approval_frequency
=BiWeekly
Approval_type must be set to Central if it should go to a central Timesheet approver and
processor or Supervisor if the supervisor is supposed to approve the time sheet.
Approval_type=Supervisor or Central
Approval_query indicates which java class to use to find out who should approve the time
sheet. Approval_query=edu.uci.adcom.employee.getTimesheetApprover.
Display_accruals_flag, if Yes, indicates that the accruals should be queried using
AccrualQuery class set in AccrualQuery below and displayed on the time sheet for the
user to view. Accruals will be validated against this number and a warning will be issued if
they are exceeded. If No, this field will not be displayed. By default,
display_accruals_flag =No
Accrual_query defines the java class file to use for the accrual query. Should be set only
by programmers. By default, Accrual_query=edu.uci.adcom.employee.getAccruals
The tracking_id_type_leveln_label indicates what label to use on the timesheet if time
logging against a job number, project or task is required. You are allowed up to 5 levels. A
TrackingIDTypeLevel can be configured for a single level of work tracked, such as
Job_Number. This type is used by CTES and Facilities. TrackingIdTypeLevel with multiple
levels allows tracking by multiple levels of work, such as Project Number, Phase, Activity,
and Task. In this case, the user will have a timesheet drawn that allows them to enter
hours against any tracking levels. The label on the tracking id will be display on the user's
screen as a choice. Set to a name such as JobNumber, Job Code, or anything else.
Display_empty_tracking_lines should be set to a number of lines to add to the timesheet
for entry of job tracking numbers that may not have appeared in the drop down lists. If set
to 0 or commented out, no extra lines will appear on the timesheet. AdCom has 3 extra
lines in the Microman output. By default, it should be 0.
Display_pay_schedule_link_flag indicates whether to display a link to the bi-weekly B1, B2
cycles and pay check schedule.
Pay_schedule_URL indicates the URL the pay schedule is at.
Smtp_server indicates the email server to use and should be configured by the
programmer. Default is Apollo.adcom.uci.edu
Return_email address indicate the address to use in case email fails to be delivered.
Rdbm_connection_properties_file should be set by the system programmer to be the file
for database jdbc connectivity.
Qt_accrual_validation_exclusion
This table lists accrual validation exclusion start and end date to bypass validation during
special times, such as the Christmas/New Years holiday break period. During this period,
27
employees can take future accruals by policy. A timesheet profile can be linked to multiple
exclusion periods and the active_flag and effective_start and effective_end dates indicate
the appropriate time periods.
This table indicates the dates that are excluded from validation of accruals, meaning an
employee can take accruals that have not yet been earned. This is done specifically for
MAIN UCI Campus employees who are allowed to take Christmas period accruals in
advance since the university is closed during that period.
Qt_profile_allowed_hour_types
This table indicates the types of hours a user can log time against. For example, it could
be that an employee is only allowed to take holidays, but not vacation hours. The table
Qt_hour_types defines all valid hour types that can be configured.
Qt_time_entry_choice
This table stores valid values for the types of time sheet entry. It has two types
ExceptionOnly or ManualFill, as explained earlier.
Qt_timesheet_type
This table stores the 3 timesheet types an employee can be configured for: Monthly, BiWeekly, or Weekly. The number of weeks filled in at a time and approved as a set are the
dependent criteria for making the correct choice of timesheet type.
Qt_employee_schedule
Indicates the normal work hours an employee is expected to work per week. This number
is used to validate the timesheet and flag an suspicion of an incomplete timesheet for the
employee to review. Manual override of the warning should be implemented this
validation is not absolute.
Qt_timesheet_question and qt_question_answer_type
These tables allow questions to be configured on the timesheet.
Question and related properties allows the timesheet to be configured with some
questions for the employee to answer. You can have multiple questions and question
choices. The only answer_format_type supported at this time is RadioButton. An
example of the CTES requirement is commented out below. Question=Assignment
Ended? Answer_format_type=RadioButton. QuestionAnswerChoices=Yes or No
default_flag indicates whether this answer is the default or not.
Timesheet Flow:
State1: timesheet_status_id=Open in qt_timesheet table. Billing_flag is set to No in
qt_timesheet_detail table for all detail hours.
State2: timesheet_status_id=Submitted for Approval or Late-Auto Submitted for Approval in
qt_timesheet implies that timesheet is ready for approval. Employee can no longer edit it.
State3: timesheet_status_id=Rejected or Approved in qt_timesheet. If Approved, the
approved_by and approved_date are set in the table.
State4: timesheet_status_id=Approved and qt_timesheet_detail.tracking_id refers to a project
or job that may require billing. If billing is required and billing_flag=No, start billing cycle by setting
billing_flag=In Progress.
State5: timesheet_status_id=Closed, billing_flag=Yes on all detail when billing cycle is

completed.
28
29
AppendixC:ToBeDeterminedList
It is unclear what the legal requirements are to make the timesheet official. For example,
there are numerous compliances: FMLA, FLSA, HIPAA,California Wage Law. What are
the legal reporting requirements that may not be met since paper has been transformed
into electronic storage? Is PPS or Timesheet the official master of record? Answer: PPS.

Requirements Timesheet

Transféré par

Informations du document

Description originale:

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Requirements Timesheet

Transféré par

Droits d'auteur :

Formats disponibles

Requirements Document

Prepared by Marina Arseniev, Cesar Brito, Elaine Peters

HR/Campus Temporary Services and AdCom Services

The purpose of this product is to:

Corresponding links or documents

Timesheet Data Entry by Self

Maintaining supervisor information for TimeSheet approval is a challenge in our

The following manuals will be created:

None. In the future, Palm Pilot interfacing may be required.

MicroMan or other such Project Management Tool.

LDAP directory services

Apache Web Server

Tomcat Servlet Runner

REQ4.2.15 The timesheet title, message, and contact information must be

REQ4.2.18 Validation of hours against normal schedule will be profile dependent.

REQ4.2.19 - All hours must be in increments of .00 .25, .5 or .75. An error

REQ4.2.20 - Comments will only show up when they exist.

A timesheet administrator will set up appropriate employee profiles

Rate_code indicates whether the payrate is hourly or a monthly salary.

Date_worked indicates the day the hours were worked.

Timesheet form. Example: UCI Campus Temporary Employment Services Bi-Weekly

State5: timesheet_status_id=Closed, billing_flag=Yes on all detail when billing cycle is

Vous aimerez peut-être aussi