Requirements Timesheet

8/10/2019 Requirements Timesheet

1/42

Requirements Documentfor

TimeSheet

Version 1.0

Prepared by Marina Arseniev !esar "rito #$aine Peters

%R&!ampus Temporary Services and Ad!om Services

10&'(&'00(


2/42

SoftwareRequirements Specification for Timesheets Page ii

Table of Contents

Table of Contents...........................................................................................................................ii

Revision History............................................................................................................................iii

Approval History..........................................................................................................................iii1. Introduction..............................................................................................................................1

1.1 Purpose...........................................................................................................................................11.2 Intended Audience and Reading Suggestions.................................................................................11.3 Product Scope.................................................................................................................................11.4 References..................................................................................................................................... .2

2. Overall Description..................................................................................................................22.1 Product Perspective...................................................................................................................... ..22.2 Product Functions........................................................................................................................... 22.3 User Classes and Characteristics............................................................................................ ........22.4 Operating Environment......................................................................................................... .........32.5 Design and Implementation Constraints.........................................................................................32.6 User Documentation.......................................................................................................................32.7 Assumptions and Dependencies............................................................................................ .........4

3. External Interface Requirements...........................................................................................43.1 User Interfaces................................................................................................................................43.2 Hardware Interfaces........................................................................................................................43.3 Software Interfaces......................................................................................................................... 43.4 Communications Interfaces............................................................................................................ 4

4. System Features.......................................................................................................................54.1 System Feature 1............................................................................................................................ 54.2 System Feature 2 (and so on)........................................................................................................13

5. Other Nonfunctional Requirements.....................................................................................215.1 Performance Requirements...........................................................................................................215.2 Safety Requirements.....................................................................................................................215.3 Security Requirements..................................................................................................................215.4 Software Quality Attributes..........................................................................................................225.5 Business Rules..............................................................................................................................22

6. Other Requirements..............................................................................................................25

Appendix A: Glossary..................................................................................................................25

Appendix B: Analysis Models.....................................................................................................25

Appendix C: To Be Determined List..........................................................................................37


3/42

SoftwareRequirements Specification for Timesheets Page iii

Revision History

Name Date Reason For Changes Version

Clock In/OutTimesheet

12/23/03 Shift Differential employees must enter time in away that can be corrected, traced, and queried.

R1.0

Approval History

Version Reviewed By Reviewer Title Date

R1.0 Elaine Peters Employment Manager 1/23/2004


4/42

SoftwareRequirements Specification for TimeSheet

1. Introduction

1.1 Purpose

Develop a web-based Time Sheet Entry application allowing employees to self-enter hours for

payroll. Optionally, allow employees to enter hours against tracking numbers such as job numbers

or project information. Depending on departmental policy, supervisors or payroll processors must

be able to easily approve hours, make corrections, view historical information, and create

appropriate reports. System must allow end-users to import or export data to external systems at UC

Irvine such as General Ledger (GL) Uploads/Billing, Payroll/Personnel (PPS), MicroMan, and MS

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 byHuman Resources ampus Temporary !mployment Services "T!S# and Adom staff$ Although thefirst implementation will rely on Adom technical infrastructure, the application will be designed tobe portable to other infrastructures$

1.2 Intended Audience and Reading Suggestions

This document is intended for Human Resources T!S Staff and Adom developers and pro%ectleaders to review$

1.3 Product Scope

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 paymentspaychecks !ince Timesheet software is of interest to multiple business units on campus, including

"TE! and Ad"om, the intent of this pro#ect is to create a fle$ible system, that can be

customi%ed in multiple locations. &n general the product scope focuses on streamlining time and attendance recording. &t

will validate hours and such however, the focus is not on strict enforcement but on theappropriate warnings, clearly indicated prior to approval. Too many details, such asmultiple appointments in multiple appointment type categories, complicate rigidenforcement rules for this application to implement. The human approval process will berequired to manage the more complicated employee timesheet profile constraints.

1


5/42


1.4 References

"orresponding links or documents'. (ro#ect (roposal). (ro#ect "harter document.*. !+A( "hannel development guidelines (ower(oint presentation.. "TE! -unctional Requirements document.. Ad"om /0& standards.

2. Overall Description

2.1 Product Perspective

This timesheet application will be a plug1in to the "TE! system that is being upgraded from-o$(ro to web technologies and integrated with 2uickTemp. As such, "TE! staff describe therequirements and interfaces in the "TE! 0pgrade Requirements document and 2uicktempEnhancement Requirements 3ocument.

2.2 Product Functions

Timesheet 3ata Entry by !elf Timesheet 3ata Entry by (ayroll processor Timesheet approvalre#ectioncorrection with comments by (ayroll processor or Timesheet

!upervisor

4ob(ro#ect "ost Tracking 5eaveTime 6ff Tracking +otifications 7i.e. 8iring 9anager for "TE!, +otification of "TE! staff of hours near ',

notification of Employee that timesheet is due; Reporting 7including historical; !ystem Administration 7 including setup of employee profile for e$emptnon1e$empt,

monthlybi1monthly timesheet, copy of e$isting employee profile, #ob tracking, etc.; &mport of 9icro9an 7Ad"om; (ro#ect, (hase, Activity, and Task numbers for tracking hours.

All recharge hours will be retrieved from the Timesheet database and not 9icro9an. 6verTime approval by !upervisor 9anual ((! 0pdate Report, including Time Reduction Report Automatic feed to ((!

with data file 7(hase &&


6/42


2.4 Operating Environment

The software will be implemented as a set of 4ava 4!( pages running under ApacheTomcat on a

!olaris !un-ire > hardware. !ybase will be used as a database backend.

2.5 Design and Implementation Constraints

This application will need to interface with the "TE! application as well as be usedtogether with pro#ect management in Ad"om. "TE! requirements must be well1understood before the Time!heet application can be started.

The types of employees that will be doing self1time entry vary in profile and configurationof template profiles can only be done after detailed analysis of the payroll requirements.

Although the application will use A?@! technical infrastructure such as !A9!

Authori%ation, 3rala Borkflow, !+A( (ortal, and 53A( 3irectory !ervices, the technologywill be designed to be replaceable by local solutions for portability. This requirement willnot be implemented in (hase & though.

The interface to ((! will be manual in phase '. 8owever, phase ) will automate aTime!heet upload to ((!. "onsequently, the design of the Time!heet must take intoaccount requirements of the ((! upload.

Time Entry accrual validation will use the 0" &rvine 3ata Barehouse links to the ((!system. This feature will need to be optional since not all environments support suchinterfaces.

9icroman is the pro#ect management tool in use in Ad"om !ervices. All (ro#ect, (hase,

Activity, and Task numbers and resources 7people; assigned are created and maintainedin 9icro9an.

9aintaining supervisor information for Time!heet approval is a challenge in ourenvironment since this information is currently not stored. A sharable supervisor table willneed to be created since there are other applications that currently need on the supervisorinformation 7ie 2uickRec;.

2.6 User Documentation

The following manuals will be created: 0ser 9anual Administrator 9anual (rogrammer 9anual

3


7/42


2.7 Assumptions and Dependencies

&f this application will be used in Ad"om, the process by which time management is done willneed to be altered. Team 5eaders currently use 9icro9an to manage pro#ects and reportrechargeable hours. The pro#ect numbers and task numbers, together with assignedresources, are all tracked in 9icroman and the current paper Time !heet is generated from9icroman. To replace this form with a web form, we must be able to e$port numbers andresources from 9icroman and update the time spent on a task by the appropriate resources.

Although a general e$port of pro#ect tasks, resources, and hours will be provided, Ad"om willnot import the hours back into 9icroman. All recharge hours will be retrieved from theTime!heet database. The window between the e$port of tasks and assigned resources andimport will be enough that if changes are made in 9icroman, discrepancies with theTime!heet will occur. This situation will need to be addressed in detail and possible processchanges implemented to make this pro#ect a success.

3. External Interface Requirements

3.1 User Interfaces

A separate document e$ists that defines the employee, supervisor, payroll processor, andadministrator user interfaces. All reports are also identified.

3.2 Hardware Interfaces

+one. &n the future, (alm (ilot interfacing may be required.

3.3 Software Interfaces

&icro&an or other such Pro%ect &anagement Tool$

SNAP

'(Net()*Password*+ebAuth authentication

SA&S authoriation

)rala +or-flow

)ata +arehouse "for validation of vacation and sic- leave accruals, accounts*funds, %ob titles#

.)AP directory services

Sybase database

Apache +eb Server

Tomcat Servlet Runner

4


8/42


3.4 Communications Interfaces

All notifications will be done via email and Beb -orms where necessary.

4. System Features

Sequence of events:1. Helpdesk sets up Departmental Timesheet DSA in SAMS.2. Departmental Timesheet DSA configures departmental Timesheet defaults, employees, and

supervisors. Users are set up by pulling data from PPS and CTES outside Agency.a. Set up default profile, time off (vacation or sick leave accrual query) for each userb. Set up roles and access privilegesc. Set up job numbers via CTES or projects via MicroMand. Assign users to projects via CTESe. Set billing rates or markup/recharge rates

3. Employee self-enters time4. Supervisor or timesheet processor approves or rejects timesheet.5. Payroll Processor updates PPS (manually until phase 2 where there will be an automatic

upload to PPS via an FTP file).6. Although not the scope of this application, if billing of time is required, a GL billing or

recharge interface can be implemented.7. Generate reports.

4.1 System Feature Profile set up for employee who will fill time sheet.

The system must allow an administrator to set up the profile with the following requirements: REQ4.1.1 Employee profile can be copied from existing employee or a default template

REQ4.1.2 Employee may be bi-monthly or monthly pay. Timesheet may need to be filledout every week, every 2 weeks, or monthly depending on departmental requirements. Aprofile must allow a person to be set up for Bi-Weekly or Weekly timesheets. Default forCTES employees is bi-weekly. A monthly profile, allowing a person to enter 4 weeks oftime before submitting a timesheet will not be a requirement at this time.

REQ4.1.3 Employee information will be pulled in from DWH where necessary. Onlycampus_id and history will be stored locally. Based on the appointment type and otherfactors, the employee will or will not be allowed to work over time. See Business Rulesbelow.

REQ4.1.4 A profile yes/no flag should indicate whether a person is allowed to enterovertime (over 40 hours per week) or not. Another profile flag should indicate whetherSupervisor Approval is required prior to taking overtime or Not.

REQ4.1.5 Employee profile must be configured to allow exceeding the accrual amounts

on specific periods throughout the year. For example, campus floaters are not allowed towork during the Christmas break but are allowed to take non-accrued vacation hours inadvance. Medical Center employees may be required to work over Christmas break. Wemust allow block-off periods where say, between December 23 rdand January 2nd, employeesare allowed to exceed accrual vacation hours. Warning would be issued only. All othertimes of the year this activity would be disallowed.

REQ4.1.6 Profile flag to indicate whether a person is allowed to work weekends. REQ4.1.7 Profile flag whether a person must obtain approval before taking vacation

(future release).

5


9/42


REQ4.1.8 Profile flag whether a person is allowed to work holidays. REQ4.1.9 Profile flag to indicate when the timesheet is due. REQ4.1.10 List of job numbers, project/task numbers, or tracking ids the person can log

hours against. REQ4.1.11 Active/Inactive flag indicating whether a person can use TimeSheet. REQ4.1.12 Contact information

REQ4.1.13 Normal scheduled number of hours per week. REQ4.1.15 Profile flag to indicate whether sick leave is allowed. REQ4.1.16 - Days of week timesheet begins and ends (period dates). REQ4.1.17 Set Supervisor of employee (in LDAP database using GUI.)

6


10/42

SoftwareRequirements Specification for TimeSheet 7


11/42


4.2 System Feature - Employee Self-entry of time

4.2.1 The self-entry time entry for bi-weekly employees will be done via SNAP withfollowing GUIs:

8


12/42


Weekly employees who need to account for overtime but no shift will use the following screen:

9


13/42


Employees who must account for overtime or shift differential will use the followingtimesheet, indicating the clock inout time:

Time is entered in ' minute intervals, on the quarter hour. =alidate occurs to helpemployees enter their time in correct intervals.

1


14/42


"TE! Agency Employees, not being normal employees, will have their time entered by the"TE! personnel into the following timesheet:

An e$ample of clock inout time entry screen that may be implemented in a future phase,as required is:

1


15/42


4.2.1.1 Description and Priority

The timesheet is presented to the user to fill out prior to the timesheet submittal

deadline via a !+A( window. (riority C 8igh.

4.2.2 Stimulus/Response Sequences

6nce the user clicks D!ave @ut 3o +ot !ubmit for Approval, the user submits thetimesheet as in progress. They can work on it until the deadline for submittal. 6ncesubmitted for approval, the employee can no longer change the timesheet. Thesupervisor must review and approve or re#ect the time sheet. &f the timesheet isre#ected, the employee will be allowed to edit the timesheet again if configured toallow self1correction. &f the manager makes any changes to the timesheet and theapproves it, the employee will be notified in email.

The user has access to all reviewed timesheets 7approved and re#ected; via areport.

4.2.3 Functional Requirements

RE2.).': &f the 3isplayAccruals flag is set to Fes in the employee profile, thetimesheet will display accruals on the top right hand corner 7and use 4avascript tovalidate time entry against accruals.; 9edical "enter -loaters may work during the"hristmas break and can not take accruals in advance. 9ain "ampus employeescan take advance accruals however, a warning must be issued. The #ob location

and fund code will determine if accruals can be e$ceeded during special times ofthe year, as configured by the Timesheet Administrator.

RE2.).): The user will automatically have the (eriod date set and the calendar willbe displayed with the holidayGs filled in per formula in:http://www.accounting.uci.edu/payroll/Holidaypay.htm

RE2.).*: 6nly #ob tracking ids that the user is allowed to track hours on will bedisplayed and the employee can select which #ob to log hours against.

RE2.).: D!ave but do not !ubmit for Approval will be a button that the employeecan click to save the timesheet before completion.

RE2.).: D!ubmit for Approval will be a button that, once clicked, submits thetimesheet to the supervisor or payroll processor. 6nce clicked, the timesheet canno longer be edited by the employee. An error message will be displayed to theuser if they have not completed filling in their timesheet with the percent hours thatper ((! normal work hours 7for e$ample, a person at H time should work )

hours per week. total IC ) would produce an error message;. The user can theneither override and submit or correct the timesheet.

RE2.).J: The timesheet, if re#ected, will re1appear in the !+A( window if Dselfcorrection in the profile is allowed. The employee will be notified in email to editand resubmit the timesheet. &n the email, a 0R5 will point to the e$act timesheetthat must be corrected.

RE2.).


16/42


supervisor or payroll processor will fill it in. All locked timesheets will be clearlyidentified for the employee, along with a phone number to call or appropriate ne$taction to take.

RE2.).>: The employee will be able to view all timesheets, re#ected andapproved, with all #ournal and comments unless separated from the campus.

RE2.).': Accruals as of the timesheet submission and approval will be stored forhistorical reporting and viewing.

RE2.).'': &t must be easy for the employee to mark multiple days for vacationinstead of individually marking each day taken for vacation. !tart date and enddate and number of hours each day as a user interface to enter vacation isrequired.

RE2.).'': The employee can pull up a previous timesheet as a template for thenew timesheet 7a copy;.

RE2.).'): (ayroll (rocessor or TimeKeeper will see all. RE2.).'*: -uture timesheet hours for pro#ecting vacation, etc be handled at this

time by providing the employee with a drop down of future timesheet periods. RE2.).': 6vertime must be pre1approved. &f approved, it will be displayed on

the timesheet along with the appropriate data entry option, listing the trackingLid7#ob; that the overtime was approved for, which startend dates, and how manyhours. @y default, no option for entering overtime is on a timesheet. &f anemployee works over the normally scheduled hours, as set by their profile or ((!,and they have approved overtime, they must be presented with a question ofwhether they want to log overtime or not. &f the answer is no, they will be returnedto the timesheet to continue to edit it. &f the answer is yes, they will then beprompted whether they want to take the overtime hours as payed overtime or ascomp time. The 6vertime Request and !tatus forms are displayed below.

3


17/42



18/42


RE2.).' The timesheet title, message, and contact information must beconfigurable.

RE2.).'J 1 A link to the ((! (ay (eriod and (ay !chedules must e$ist from thetimesheet.

RE2.).'< A profile flag should indicate whether to display a calendar for the useror not..

RE2.).'> =alidation of hours against normal schedule will be profile dependent.&f the profile indicates =alidate8oursCFes, then a +ormalBeeklyBork8ours wouldhave to be filled in or ((! hours used for validation and the user would have to 6Ka warning dialog bo$ that the hours on the timesheet do not match the normal workweek hours.

RE2.).'M 1 All hours must be in increments of . .), . or .


19/42


The link to employee detail timesheet on this screen will allow the CTES Timesheet manager toalter an employees timesheet. Notification will go out to the employee in this event, with

comments, documenting what changes were made.

RE2 .*.': 6nce entered into a system and uploaded to ((!, the timesheet data may notbe altered in any way. Any changes to historical hours must be credited and debitedrather than updated. 6nly the TimeKeeper 7(ayroll (rocessor; can edit a closed

timesheet. ((! must be manually synchroni%ed with the Timesheet database by first,entering the creditdebit into the Time!heet application, then updating ((! as necessary.The timesheet that must be edited can be found using a 2uickTemp screen e$ample as:

6


20/42


The result brings up a list of timesheets, alphabeti%ed by employee names, sorted on payperiod dates.

7


21/42


&ndividual timesheets can then be edited. Any hours changed get reflected in the system by aback out of the original hours and new records added for the same work date, with the correcthours and hour types.

REQ 4.3.2: Summary approval of the timesheet will be the default. In otherwords, asopposed to each individual set of hours recorded against a job number or hour type being

approved, the entire timesheet will either be approved or rejected. REQ4.3.3 - If an error occurs and the Approver or Timekeeper must make changes, she/hewill click on Timesheet Period and change the timesheet that was originally submitted.She/he will be required to add comments. A notification will go out to the employeeindicating all changes.

REQ4.3.4 The approval listing must allow the Timekeeper or Approver to view the jobassignment details, employee details and profile, and time sheet details, notes, and history.

8


22/42


4.4 System Feature - Administration

REQ4.4.1 Role assignment via SAMS Helpdesk assigns Timesheet Administratorfor a Financial Organizational Hierarchy (Department, Sub Division, Division, orOrganization.)

REQ4.4.2 Departmental Timesheet Administrator sets the follow functions in SAMSfor their department:

1. Timesheet Reviewer2. Timesheet Approver, Rejector3. Timesheet Modifier (can correct timesheets).

Typically, a department will assign a person to one or more of the following roles:

TimeKeeper(Payroll Processor usually) reviews for correctness, tracksattendance, hours. Enters time into PPS for paycheck in phase 1 for all approvedtimesheets. Reviews and submits FTP file for PPS upload in phase 2. Exports or

imports data from external systems, such as MicroMan.SAMS Function: Timesheet Reviewer Supervisor can review, approve, or reject a timesheet. May be allowed to edit

timesheets if access to do so is allowed. For CTES, the supervisor can onlyreview a timesheet and approve overtime and gets an electronic copy of thetimesheet once it is approved by the CTES processor.

SAMS Function: Timesheet Reviewer (for CTES)SAMS Function: Timesheet Approver/Rejector (for AdCom)SAMS Function: Timesheet Modifier (for AdCom)

TimeSheet Approver can approve or reject timesheet.SAMS Function: Timesheet Approver/Rejector

TimeSheet Modifier

SAMS Function: Timesheet Modifier (for AdCom)

Employee enters timesheet. Supervisor is set in LDAP.No SAMS function required

Sub-Administrator manages required fields.SAMS Function: Timesheet Administrator

sets up expense reporting by setting up the job numbers an employee isallowed to log time against. Set up any required imports for these trackingids. Specifies which jobs are billable using configuration flag Yes or No.

sets up defaults, employee profiles, holidays, payrate/recharge rates. data Export and Import mappings and formats, Excel Downloads. required reports defines access control.

9


23/42


4.5 System Feature Reports

The following reports must be generated from timesheet application:

10


24/42



25/42


REQ4.5.1 TimeSheet Status Summary REQ4.5.2 Statistical Report REQ4.5.3 - Report that allows the payroll processor to quickly update PPS manually,

until upload automated. All updated records must be checked by the payroll processor to

flag which records have been updated in EDB/PPS. It will look like:

12


26/42


REQ4.5.4 Attendance report listing summary and detail. REQ4.5.5 Ad Hoc reporting with Excel Download REQ4.5.6 Approved Reports, Rejected Reports

REQ4.5.7 Billable hours for recharges on projects.

4.6 System Feature Supervisor Functions

REQ4.6.1 Approve Overtime Hours REQ4.6.2 Review Timesheet REQ4.6.3 - Review Historical Timesheet Details REQ4.6.4 Review Invoices/Billing

4.7 System Feature Notifications

REQ4.7.1 See CTES Upgrade Requirement 4.8 System Feature-Notifications for CTESspecific notification requirements.

5. Other Nonfunctional Requirements

5.1 Performance Requirements

All transactions 7not reports; must return within ) seconds of a submit event. Reports must bewithin * seconds of a submit event.

5.2 Safety Requirements

NA

5.3 Security Requirements

All timesheet entry will be done only after the user has successfully authenticated.

8ome addresses, etc will not be stored in any database. +o social security numbers are needed.Timesheet is considered private data and only accessible via an access controlled list.

13


27/42


5.4 Software Quality Attributes

The Timesheet application must be very intuitive and useable without training.

5.5 Business Rules

5.5.1 Business Rules: General

o A timesheet administrator will set up appropriate employee profileso A timesheet administrator will set up the appropriate #ob tracking numbers an employee

can log time against 7"TE! functionality added to 2uickTemp;o &f the 3isplayAccruals flag is set to yes in the employee profile, =acation and !ick

5eave Accruals will be displayed on the timesheet. They are accrued per calculation in

http:www.accounting.uci.eduo 3B8((! query will return the official record on vacation, sick leave, and hour

accruals for display and validation. The D5eave Accrual "ode from 3B8 indicatesthe accrual rates.

o 8oliday pay is paid based on the number of hours worked in a given holiday month.An employee normally earns > hours holiday for every '*J hours of work. Thetimesheet application should retrieve from the 3B8 the accrued hours of work.8oliday hours are displayed by default on holiday days. 8oliday hours are calculateddepending upon the hours the employee works seehttp://www.accounting.uci.edu/payroll/Holidaypay.htm(er 0niversity policies, forbiweekly employees, if a holiday falls in a @' period, the holiday hours are accrued inthe @) period immediately following the holiday periodN if the holiday falls in a @)period, the holiday hours are accrued in the same @) period.

o 8oliday hour accruals are not available in ((!. They must be calculated.o The application will validate hours with basic checks for:

8ours over ) hours in a single day +o more than hours sick leave, vacation per week. 8ours under or over H as reflected in ((! will generate an errorwarning that

either the timesheet is incomplete or requires overtime approval. +o hours over the accrued vacation and sick leave per 3B8 query. 3isallow hours logged against holidays per profile, if unauthori%ed. All hours must be categori%ed 7not left blank; and, if required, assigned to #ob

tracking identifiers

o A floater employee must be notified of benefits eligibility after they have attained the

9id1level requirements: 'H hours full time for M days or H hours full time for Jmonths. @y default, all floaters are at "ore @enefits 73ental, life, only;. All limitedemployees have 9id 5evel benefits by default. "TE! hires only floaters as of thistime.

o 6nly the supervisor or payroll processor can view, approve, re#ect, or edit a timesheeton behalf of an employee.

o An employee must be able to log hours only against #ob tracking numbers that they areallowed to work on.

o +o hours can be logged against #ob tracking numbers that are considered closed.

14
http://www.accounting.uci.edu/payroll/Holidaypay.htmhttp://www.accounting.uci.edu/payroll/Holidaypay.htm


28/42


o An employee can work on a timesheet until they decide to submit it for approval. 6ncesubmitted for approval, the employee can not alter the timesheet.

o The supervisor or payroll processor must approve or re#ect the timesheet. &f re#ected,comments must be provided.

o &f the supervisor or payroll processor must edit the timesheet, a #ournal must becreated and they must identify the edits.

o 6nce submitted to ((!, all changes to hours must be in the form of creditdebit on anew payroll transaction.o An employee must be notified immediately if the timesheet is re#ected and reason for

re#ection. The status on the timesheet must be reset to Din progress to allow theemployee to edit it.

o The employee is notified to turn their timesheet in ') hours in advance of the deadline7 or any other admin configurable number of hours;

o &f late, if the configuration for Auto!ubmitCFes, the timesheet automatically issubmitted for the payroll processor or supervisor to fill in. The employee will not beable to edit the timesheet for that pay period anymore. &f the Auto!ubmit configurationis +o, the timesheet will remain unsubmitted 7and unpayed;.

o The employee, payroll processor, and supervisor can all see historical records of theiremployees. &f they are removed from their role, they must no longer have access to

the data.o Employee must always report the total number of hours worked in each pay period

7and how many hours worked each day;. That is, hours can not be banked in onemonth and reported on in a future monthOs timesheet.

o The work week is usually defined as beginning 9onday morning at ')am and endingon !unday at ') midnight.

o 6vertime 76nly applies to non1e$empt; 6vertime is defined as working more than forty hours during the work week and

is usually paid at time and one half. &f vacation is taken, that time can not becounted towards over time.

6vertime must be pre1approved by a supervisor. This feature will beimplemented at a later stage in the development of this application if thedeadline is difficult to meet.

-or holidays, non1e$empt staff will only get paid overtime pay 7time and a half;if they are PrequiredP to work on the holiday, get supervisor approval, and workover hours, not counting holiday, vacation, or leave hours.

6vertime formula: Time over hours paid as time and half 6T( 7no sick leave,vacation or holiday during that week; &f during a week where employee workedthe holiday, pay them hours regularN > hours 6vertime !tandard 76T!;.6vertime (remium 76T(; is anytime over > hours per week.

5.5.2 Business Rules: CTES Temporary Employees

o @y default, all "TE! employees are D-loaters, not 5imited. As such they donot have 9id15evel @enefits 7dental for e$ample;. They are D"ore @enefitseligible only.

o 6nly the Timekeeper in "TE! can approve the timesheet. The !upervisor ofthe employee will review the timesheet after it is approved.

o 6nly the !upervisor of the employee can approve overtime hours.o =acation is in ((! and paid out to the employees as they use it and at the time

of separation.o =acation and sick leave can only be accrued after a @) "ycle.

15


29/42


o !ick leave and holiday is recharged to a department so all such hours must belogged against a trackingLid 7#ob number for "TE!;.

o =acation is payed from a "TE! accountfund.o 4ury duty is not paid to floaters.o 8oliday

The system must split the holiday hours between the #obs if an

employee works in ) departments. -or e$ample, if the ratio is halftime. 8oliday 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.4uly , 4anuary 'st, etc.

8oliday accruals are not available in ((!.o "TE!Timesheet will +6T need to store !!+Q.o -95A will be an option for "TE! leave in (hase ). +eed to calculate hours

worked within a ') month calendar year, across all appointments by doing a3B8 (ayrollEarningsE$pense query. +on1e$empt employees 7employeeseligible fo premium overtime; are eligible if they have worked a total of at least') months and for at least ',) hours, including overtime hours for scheduledemployes, during the ') months prior to the start of the leave.

o 8ours in a particular assignment, on a #ob title code with a particular bargainingunit must be tracked.

The system must notify the payroll processor if a floater employee hasworked ) months for "TE! 6R is approaching ') hours in specific

#ob titlesbargaining unit since past ' hours, a temporary employeeautomatically becomes permanent. -or D5imited employees, the rule is' hours of work automatically transfers them to "areer status.9ultiple email messages will be sent.

11111 Added +ovember ', )* by Barren 5iang 111111o -or employees with concurrent multiple assignments, the employee may not

enter overtime for that pay period.o &f an employee takes leave on a certain day, no overtime is allowed for that day.o 8ours that are actually worked on an 0niversity holiday are considered to be

6T!, but in the event that more than hours in the week are worked,

5.5.3 PPS Profile Specific Business Rules for TimeEntry

@ased on : Employee !tatus 7Active, !eparated, on 5eave, etc;

!tudent !tatus 7indicating a student and type; Appointment Type "ode 7"areer, -loater, "asual, "ontractor, etc; -5!A -lag 7E$empt+on E$empt; indicates if the employee is can take overtime. This

is a derived field in ((! and is based on the titleLcode so is accurate as long as thetitleLcode is accurately entered and maintained for the employee by the departmentalpayroll processor.

Appointment Representation "ode 7"overed +ot "overed by 0nion which is anattribute of the Title"odeTitle 0nit "ode;.

(ercent1-ullTime indicates the normal scheduled hours per week for validation. (ayrate indicates the normal pay for the employee

16


30/42


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

Problem: Multiple appointment types per individual. Must also save all state informationat timesheet entry time for future referral and audits.

1. Student ) indicated by #mp$oyee Status fie$d

A student employee can not work more than 'M. hours per week during the academicyear. A student can not e$ceed *M. hours per week during the summer. &f a student needs

to e$ceed that amount from time to time, prior approval from supervisor must bereceived.

9ust turn in timesheet weekly. +on1E$empt 1 by -5!A -lag

'. *$oater +!T#S, The 9ain "ampus "TE! temporary employee will be shown accrued vacation on the

timesheet however, will not be able to take e$cess e$cept at specific periods during theyear, configurable by the Timekeeper 7Admin; "hristmas break is one such period.

9edical "enter employees work through the "hristmas break and so do not have theoption to take accruals in advance.

9ust turn in timesheet weekly. +o Auto!ubmit allowed for "TE! employee timesheets. They will +6T get paid if they

do not submit a timesheet. +on1E$empt by -5!A -lag

(. -imited +on E$empt by -5!A -lag

. !asua$&Restricted +on E$empt by -5!A -lag

/. !areer&Reu$ar

. !ontractor2. Partia$ 3ear&!areer4. Per Diem5. Academic

17


31/42


6. Other Requirements

Appendix A: Glossary

@i19onthly9onthly @' @) E$empt +onE$empt Temporary Employee

Appendix B: Analysis Models

3ata 9odel

5imitations and constraints: A person can have only one timesheet profile at any one time,regardless of the appointment type or #obs they are employed at. The reasoning is that it wouldbe difficult for an employee to manage multiple timesheets. -or e$ample, if vacation hours andsuch are to be validated, it is difficult to do across multiple timesheets.

18


32/42


qtLtimesheetLdetail

P6 timesheet7detai$7id

*61 timesheet7id

-K* trackingLid

date78or9ed

hours

*6' hour7type7id

-K, overtimeLtypeLid

laborLtype

billableLflag

billedLflag

billedLdate

invoicedLflaginvoicedLdate

((!LupdatedLflag

((!LupdatedLdate

glLupdateLlock

invoiceLupdateLflag

ppsLupdateLlock

created7by

created7date

updatedLby

updatedLdate

qtLtimesheetLdetailL#ournal

P6 :ourna$7detai$7id

*61 timesheet7detai$7id

*6' :ourna$7type7id

notes

created7bycreated7date

qtLhourLtypes

P6 hour7type7id

hourLtypeLdescription

qtLemployeeLtimesheet

P6 campus7id

P6 effective7date

-K' timesheetLprofileLid

currentLflag

qtLtimesheet

P6 timesheet7id

*61 campus7id

period7start7dateperiod7end7date

*6' timesheet7status7id

approvedLby

approvedLdate

reviewedLby

reviewedLdate

created7by

created7date

updatedLby

updatedLdate

-K' effectiveLdate

qtLtracking

P6 trac9in07id

trac9in07description

trac9in07$eve$71

trackingLlevelL'Ldesc

trackingLlevelL)

trackingLlevelL)Ldesc

trackingLlevelL*

trackingLlevelL*Ldesc

trackingLlevelL,

trackingLlevelL,Ldesc

trackingLlevelL.

trackingLlevelL.Ldesc

created7by

created7date

updatedLby

updatedLdate

qtLtimesheetL#ournal

P6 :ourna$7id

*61 timesheet7id

state

notes

created7by

created7date

qtL#ournalLtype

P6 :ourna$7type7id

:ourna$7type7description

qtLovertimeLtype

P6 overtime7type7id

overtime7type7description

qtLtimesheetLstatus

P6 timesheet7status7id

timesheetLstatusLdescription

qtLovertimeLapproval

P6 ot7approva$7detai$7id

campusLid

startLdate

endLdate

-K' trackingLid

hours

hour7type7id

overtimeLtypeLid

created7by

created7date

updatedLby

updatedLdateapprovedLby

approvedLdate

qtLtimesheetLprofile

P6 timesheet7profi$e7id

see pa0e '

qtLclockLinLout

P6 c$oc97in7out7id

clockLin

lunchLstart

lunchLend

clockLout

campus7id

date78or9ed

19


33/42



34/42


qtLprofileLallowedLhourLtypes

P6*61 timesheet7profi$e7id

P6 hour7type7id

activeLflag

effectiveLstartLdate

effectiveLendLdate

qtLtimesheetLprofile

P6*61*6. timesheet7profi$e7id

profileLname

profileLdescription

commentsdisplayLtitle

displayLmessage

footerLmessage

helpLmessage

-K) timeLentryLchoiceLid

-K* timesheetLtypeLid

clockLinLoutLflag

periodLstartLdayLofLweek

periodLendLdayLofLweek

deadlineLday

deadlineLreminderLhours

lockLlateLtimesheetLflag

lateLautoLsubmitLflag

dailyLhourLlimitdailyLhourLlimitLlabel

validateLhoursLflag

weekendLtimeLallowedLflag

holidayLtimeLallowedLflag

overtimeLallowedLflag

approvalLfrequency

approvalLtype

approvalLquery

displayLaccrualsLflag

accrualLquery

trackingLidLtypeLlevel'Llabel

trackingLidLtypeLlevel)Llabel

trackingLidLtypeLlevel*Llabel

trackingLidLtypeLlevel,LlabeltrackingLidLtypeLlevel.Llabel

displayLemptyLtrackingLlines

displayLpayLscheduleLlinkLflag

payLscheduleL0R5

smtpLserver

returnLemailLaddress

rdbmLconnectionLpropertiesLfile

qtLaccrualLvalidationLe$clusion

P6 accrua$7va$idation7e;c$usion7id

accrua$7va$idation7e;c$usion7start7date

accrua$7va$idation7e;c$usion7end7date

comments

qtLprofileLaccrualLvalidationLe$clusion


*61 accrua$7va$idation7e;c$usion7id

activeLflag

effectiveLstartLdate

effectiveLendLdate

qtLtimeLentryLchoice

P6 time7entry7choice7id

timeLentryLchoiceLname

timeLentryLchoiceLdescription

qtLtimesheetLtype

P6 timesheet7type7id

timesheet7type7name

qtLtimesheetLquestion


*61 question7id

question

answerLformatLtype

qtLquestionLanswerLtype

P6 question7id

answerLchoice

defaultLflag

qtLemployeeLschedule

P6 campus7id

normalLhoursLperLweek

effectiveLbeginLdate

effectiveLendLdate

currentLflag

21


35/42


2tLtimesheet A timesheet is entered into the qtLtimesheet table with the periodLstartLdate and

periodLendLdate indicating the dates for which the worked time is recorded. "ampusLid identifies the employee logging the hours. The qtLtimesheet table can have one more more time detail records, stored in

qtLtimesheetLdetail. The timesheetLstatusLid indicates the status of the timesheet. TimesheetLstatusLid can

be one of D6pen, D!ubmitted for Approval, D6pen1Re#ected, DApproved, D5ate Auto!ubmitted for Approval, and D"losed. &t is the current state of the timesheet, as reflectedin the qtLtimesheetL#ournal.state column.

o 6pen means the timesheet is in a state that the employee can add time to it.o

D!ubmitted for Approval means that the timesheet can no longer be changed bythe employee, only the supervisor or payroll processor.o D6pen1Re#ected indicates that the timesheet can again be edited by the employee.o DApproved means the payroll processor or supervisor have approved the

timesheet hours and the timesheet is ready for any bill or invoice processing.o D5ate Auto !ubmitted for Approval indicates the timesheet is delinquent and

submitted automatically by the system.o D"losed state should be set once the timesheet invoicing or billing is completed.

The qtLtimesheetL#ournal table stores every state change on the timesheet with anyassociated notes. &t is used for logging changes.

6nce approved, the approvedLby and approvedLdate are entered into this table.ApprovedLby is the campusLid of the approver. The timesheet can no longer be changedby anyone. 6nly credits and debits can be applied to make changes.

2tLtimesheetL #ournal The qtLtimesheetL #ournal is the table that stores all state information changes about the

timesheet. A +ote is required for any timesheet change. The state can be one of any TimesheetLstatusLids it is a history of all events on a

timesheet for auditing purposes.

2tLtimesheetLdetail

3ateLworked indicates the day the hours were worked. 8ours are defaulted to >. 8ourLtypeLid is defaulted to Regular hours. "an be =acation, !ick 5eave, and so on, as

allowed in the profile. The trackingLid identifies the #ob or pro#ect tracking information via a link table. 6vertimeLtypeLid indicates that if the employee worked overtime, how they would prefer

to take the hours comp time or with pay. 5aborLtype indicates can be one of DRegular, D!hift, or D/raveyard. @illableLflag indicates whether this time should be billed. 3efaultC+o. "an be one of +o

or Fes.

22


36/42


@illedLflag indicates that if the billableLflag CFes, meaning the time should be billed, thatthis record has been correctly billed. &t is set to +o by default. 6nce the timesheet isapproved, any required billing can start. 6nce the billing cycle is started, the flag shouldbe set to D&nL(rogress meaning the record can no longer be updated. The timesheet canbe altered only while the billedLflagC+o. Bhen the billing cycle is run, the billedLflag mustbe set to Fes. 6nce it is set to Fes and a change needs to be made, a credit and debit

must occur for billing. 6nly the timekeeper has the authority to create this kind oftransaction. ((! and Timesheet database must manually be synchroni%ed. The billingLflag can be set to D&n (rogress and DFes only if the

qtLtimesheet.timesheetLstatusLidCApproved. @illedLdate is the date when the payroll transaction is billed. &nvoicedLflag and &nvoicedLdate indicates that the invoices have been sent to the

department. ((!LupdatedLby, ((!LupdatedLdate indicates that the hours have been loaded into

((! 7manual in phase', automatic file upload in future phase;. "reatedLby is the campusLid by default. "reatedLdate is the date the record was created in the database. 0pdatedLby is the campusLid of who last touched the record. 0pdatedLdate is the date the record was last updated.

/lLupdateLlock indicates that the gl upload is in progress so the record must not bealtered.

&nvoiceLupdateLlock indicates that email is being sent to department so the record mustnot be altered.

(psLupdateLlock indicates that the ((! 0pdate is in progress so the record must not bealtered. The processor will click a button to indicate that the records can be altered.

+6TE: "hanges to this detail can be made any time before the monthend processingstarts. 6nce the processing starts, this record must be locked from all changes. 6ncecompleted, the record is unlocked and free to be altered however, 6+5F via ) newrecords, one backing out the previous record and a new one creating a new record. Thismust be done both for the ledger and the ((! 0pdate functionality to stay in sync.

2tLtimesheetLdetailL#ournal The qtLtimesheetLdetailL#ournal is the table that stores all state information changes

about the timecard detail. A +ote is required for any timesheet change. &f approval of each hour in timesheetLdetail is required, the #ournalLtypeLid can be set to

Approved, Re#ected, and so on, to reflect the lowest level of granularity of tracking hours.This id can be of the same type as timesheetLstatusLid in qtLtimesheet.

2tLemployeeLtimesheet The qtLemployeeLtimesheet 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 currentLflagCFes.The effectiveLdate indicates the date at which point the profile was used by the timesheetapplication.

2tLtracking The qtLtracking table links the timesheet trackingLid with the billing, #ob ticket, or pro#ect

management system. &f hours need to be categori%ed by pro#ects, tasks, or #ob numbers,this table is used to allow the employee to log hours against them.

23


37/42


2tLovertimeLapproval 6vertime must be approved via the qtLovertimeLapproval table. 6vertime can be worked

only between the startLdate and endLdate that has been approved for a specifictrackingLid that is identified by the qtLtracking table.

2tLclockLinLout 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 forthe day. This table will not be implemented within the scope of the current application butserves as a placeholder for future requirements if lunch tracking is required in a timesheet.

2tLhourLtypes The qtLhourLtypes table lists the categories of hours an employee can log time against.

=alid values are:o Administrativeo !upervisiono Trainingo Admin 0se 6nlyo =acationo !ick Timeo -amily !ick 5eaveo "omp Time Takeno "omp Time Earnedo 6ver Timeo 5eave Bithout (ayo 4ury 3utyo 8olidayo 3eath 5eaveo 9ilitary 5eaveo =oting Time 8ours

2tLovertimeLtype This table stores the overtime types. &t can be one of:

o Regularo "all1@acko 5ess than ) hour noticeo 6n1"all

2tLtimesheetLprofile The qtLtimesheetLprofile table stores basic information that defines a timesheet for an

employee or group of employees. (rofileLname is what is displayed on the choicelist of profile selections when choosing aprofile for a new employee and a template is desired or a copy of a pre1e$isting employeeprofile. 3efault Timesheet indicates a template that is widely used. D"TE! @i1weeklyTimesheet is an e$ample name.

(rofileLdescription is a short description of the timesheet. &t could beTimesheet that is the default for the installation or something like D"TE! @i1weeklyTimesheet used by 0" &rvine 8uman Resources Temporary Employees.

3isplayLtitle indicates what the label should be at the top of the

24


38/42


Timesheet form. E$ample: D0"& "ampus Temporary Employment !ervices @i1BeeklyTime !heet

3isplayLmessage indicates any message to display after the title. &t can be multiple lines.E$ample: PTime!heets must be submitted every other 9onday 1 by +oon. @ased on the0"& @i1Beekly (ay !chedule. (lease click on !ave BorkG to continue working on yourtimesheet. "lick on O!ubmit for ApprovalO once completed.P

-ooterLmessage indicates te$t to display at the bottom of the timesheet. E$ample:D(lease call 7MM; >)1> for assistance. 8elpLmessage indicates the message to display in case the system has an error and must

generate an error message to the user. TimeLentryLchoiceLid can be one of 9anual-ill work hours or E$ception6nly reporting.

9anual-ill hours means that a user must e$plicitely enter the number of hours theyworked each day. +o defaults are provided. E$ception6nly work hours would auto fillscheduled hours per day and assume there is no vacation, sick leave, or other leave. &twill be up to the user to record vacation, sick, and other leave. The default is 9anual-ill.

TimesheetLtypeLid indicates whether the timesheet must be filled out weekly, twice permonth or monthly. 0sually, one or two checks are generated per month depending onwhether the employee is is set up as bi1weekly or monthly in ((!. The valid values areD9onthly, D@i1Beekly, or DBeekly. The default is @i1Beekly.

"lockLinLoutLflag indicates whether the timesheet should be displayed with the "lock1&nTime, 5unch !tart Time, 5unch End Time, and "lock 6ut time. @reaks are not handled.This configuration is used primarily by employees whose unions require us to track lunchleave and break leave. The default is +o.

Although (ay(eriod@egine3ate and (ay(eriodEnd3ate are defined in a ((! table the3ay of week for the dates are defined by periodLstartLdayLofLweek andperiodLendLdayLofLweek for display of the Timesheet form. (eriod!tart3ay6fBeekidentifies the day of week for which the timesheet should be started. 9ost timesheetsstart on !unday at midnight and End on !aturday at '':M pm 7< days;. This is the firstday displayed on the Timesheet week. (eriod!tart3ay6fBeekC!unday(eriodEnd3ay6fBeek identifies the day of week for which the timesheet should beended. 9ost timesheets end on !aturday at '':M pm 7< days;. -or weekly timesheets,this is the first !aturday. -or @i1Beekly timesheets, it is the second !aturday after the(eriod!tart3ay6fBeek This is the last day displayed on the Timesheet week. The default(eriodEnd3ay6fBeek is !aturday.

3eadlineLday and deadlineLreminderLhours 1 3epending on whether the timesheet isBeekly, @i1Beekly, or 9onthly,the 3eadlineLday and 3eadlineReminderLhours will beeffective every week, every two weeks, or every month respectively.

3eadlineLday defines the deadline day of week and time in dayofweek:88:99 format.dayofweek must be one of: 9onday Tuesday Bednesday Thursday -riday !aturday!unday. 0se military time for afternoon. -or e$ample -riday afternoon at pm would be-riday:'J:. 3epending on whether the employee is weekly, bi1weekly, or monthly, areminder will be set accordingly, per 3eadlineReminderLhours hours.3eadlineLdayC9onday:'':M. 3eadlineReminderLhours defines the number of hoursbefore the deadline to send a reminder to employee to fill in timesheet.


39/42


validateLhoursLflag indicates whether the system should validate the hours against thenormal work hours as specified by the ((! system or by the !cheduled8ours if they havebeen set up in the qtLemployeeLschedule table. The default value is +o.

weekendLtimeLallowedLflag indicates whether the employee is allowed to log time overthe weekend, regardless of supervisor approval. The default is +o.

holidayLtimeLallowed indicates whether the employee is allowed to log time over the

holidays, regardless of supervisor approval. The default is Fes. 6vertimeLallowedLflag indicates whether approval must be granted before overtime can

be logged in the timesheet. The default is +o. Approval 8andling is defined by the combination of approvalLfrequency, approvalLtype,

and approvalLquery. ApprovalLfrequency defines whether approvals are done on a weekly basis, bi1weekly

basis, or monthly. The default is @i1Beekly. @ased on this value, a timesheet consisting of' week, ) weeks, or monthly must be submitted at this frequency by the employee. &nother words, regardless of when the employee clicks on the P!ubmit for ApprovalP button,the approval will only be done with the frequency indicated by approvalLfrequencyC@iBeekly

ApprovalLtype must be set to "entral if it should go to a central Timesheet approver andprocessor or !upervisor if the supervisor is supposed to approve the time sheet.

ApprovalLtypeC!upervisor or "entral ApprovalLquery indicates which #ava class to use to find out who should approve the time

sheet. ApprovalLqueryCedu.uci.adcom.employee.getTimesheetApprover. 3isplayLaccrualsLflag, if Fes, indicates that the accruals should be queried using

Accrual2uery class set in Accrual2uery below and displayed on the time sheet for theuser to view. Accruals will be validated against this number and a warning will be issued ifthey are e$ceeded. &f +o, this field will not be displayed. @y default,displayLaccrualsLflag C+o

AccrualLquery defines the #ava class file to use for the accrual query. !hould be set onlyby programmers. @y default, AccrualLqueryCedu.uci.adcom.employee.getAccruals

The trackingLidLtypeLlevelnLlabel indicates what label to use on the timesheet if timelogging against a #ob number, pro#ect or task is required. Fou are allowed up to levels. ATracking&3Type5evel can be configured for a single level of work tracked, such as4obL+umber. This type is used by "TE! and -acilities. Tracking&dType5evel with multiplelevels allows tracking by multiple levels of work, such as (ro#ect +umber, (hase, Activity,and Task. &n this case, the user will have a timesheet drawn that allows them to enterhours against any tracking levels. The label on the tracking id will be display on the userOsscreen as a choice. !et to a name such as 4ob+umber, 4ob "ode, or anything else.

3isplayLemptyLtrackingLlines should be set to a number of lines to add to the timesheetfor entry of #ob tracking numbers that may not have appeared in the drop down lists. &f setto or commented out, no e$tra lines will appear on the timesheet. Ad"om has * e$tralines in the 9icroman output. @y default, it should be .

3isplayLpayLscheduleLlinkLflag indicates whether to display a link to the bi1weekly @', @)cycles and pay check schedule.

(ayLscheduleL0R5 indicates the 0R5 the pay schedule is at.

!mtpLserver indicates the email server to use and should be configured by theprogrammer. 3efault is Apollo.adcom.uci.edu ReturnLemail address indicate the address to use in case email fails to be delivered. RdbmLconnectionLpropertiesLfile should be set by the system programmer to be the file

for database #dbc connectivity.

2tLaccrualLvalidationLe$clusion This table lists accrual validation e$clusion start and end date to bypass validation during

special times, such as the "hristmas+ew Fears holiday break period. 3uring this period,

26


40/42


employees can take future accruals by policy. A timesheet profile can be linked to multiplee$clusion periods and the activeLflag and effectiveLstart and effectiveLend dates indicatethe appropriate time periods.

This table indicates the dates that are e$cluded from validation of accruals, meaning anemployee can take accruals that have not yet been earned. This is done specifically for9A&+ 0"& "ampus employees who are allowed to take "hristmas period accruals in

advance since the university is closed during that period.

2tLprofileLallowedLhourLtypes This table indicates the types of hours a user can log time against. -or e$ample, it could

be that an employee is only allowed to take holidays, but not vacation hours. The table2tLhourLtypes defines all valid hour types that can be configured.

2tLtimeLentryLchoice This table stores valid values for the types of time sheet entry. &t has two types

E$ception6nly or 9anual-ill, as e$plained earlier.

2tLtimesheetLtype

This table stores the * timesheet types an employee can be configured for: 9onthly, @i1Beekly, or Beekly. The number of weeks filled in at a time and approved as a set are thedependent criteria for making the correct choice of timesheet type.

2tLemployeeLschedule &ndicates the normal work hours an employee is e$pected to work per week. This number

is used to validate the timesheet and flag an suspicion of an incomplete timesheet for theemployee to review. 9anual override of the warning should be implemented thisvalidation is not absolute.

2tLtimesheetLquestion and qtLquestionLanswerLtype These tables allow questions to be configured on the timesheet. 2uestion and related properties allows the timesheet to be configured with some

questions for the employee to answer. Fou can have multiple questions and questionchoices. The only answerLformatLtype supported at this time is Radio@utton. Ane$ample of the "TE! requirement is commented out below. 2uestionCAssignmentEndedS AnswerLformatLtypeCRadio@utton. 2uestionAnswer"hoicesCFes or +odefaultLflag indicates whether this answer is the default or not.

Timesheet *$o8

Requirements Timesheet

Documents

Transcript of Requirements Timesheet