hr pre project plan nov 2009

8/7/2019 HR Pre Project Plan Nov 2009

1/88

Kuali HR Payroll System Pre-Project Plan

Prepared for:

Kuali HR Payroll Strategic Group

November 2009


2/88


1

TableofContents

1. DocumentInformationandRevisionHistory....................................................................................................... 2

2. ExecutiveSummary .............................................................................................................................................. 3

3. FunctionalOverview&BusinessRequirements .................................................................................................. 6

3.1 FunctionalOverview ....................................................................................................................... ............ 6

3.2 PositionManagement ..................................................................................................................... ............ 7

3.3 Organization/DepartmentData................................................................................................................ 10

3.4 HRActions/JobActions ............................................................................................................................. 11

3.5 Timekeeping .................................................................................................................... .......................... 15

3.6 BenefitsAdministration ............................................................................................................................ 22

3.7 PayrollProcessing ..................................................................................................................................... 27

3.8 FinancialProcessing .................................................................................................................................. 34

4. TechnicalArchitecture,Requirements&Estimates........................................................................................... 39

4.1 KualiRiceTechnicalArchitectureOverview ............................................................................................. 39

4.2 AccessSecurityRequirements.................................................................................................................. 43

4.3 AssumptionsforTechnicalRequirements&Estimates............................................................................ 44

4.4 PositionManagementTechnicalRequirements&Estimates................................................................... 44

4.5 Organization&DepartmentDataTechnicalRequirements&Estimates................................................. 45

4.6 HRActions/JobActionsTechnicalRequirements&Estimates................................................................. 46

4.7 TimekeepingTechnicalRequirements&Estimates.................................................................................. 48

4.8 Benefits

Administration

Organization

&

Department

Data

Technical

Requirements

&

Estimates.......... 514.9 PayrollProcessingTechnicalRequirements&Estimates ......................................................................... 56

4.10 FinancialProcessingTechnicalRequirements&Estimates ...................................................................... 64

5.PhaseITimeline&Resources................................................................................................................................. 65

5.1 Timeline....................................................................................................................... .............................. 65

5.2 Phase1.0Functional&TechnicalResources............................................................................................ 67

5.3 Roles&Responsibilities ............................................................................................................................ 70

6. RiskManagement ............................................................................................................................................... 73

Appendix1PayrollProcessing(EarningsCodes,EmployeeSelfService,PayrollVoucher,Interfaces).................. 75

............................................................. 78

............................................................................................................................... ... 80 ................................................................................. 81

Appendix5PlanningProjectStatement(PreProject) ............................................................................................ 82


3/88


4/88


3

The Kuali Foundation has created a model for community source development and delivery of administrativesystems designed BY and FOR higher education. Already delivered in October 2009 are a fully functionalFinancial System, the proposal and budget development module of a Research Administration system, and aset of middleware and application development tools called Kuali Rice. Also underway is a Kuali Studentsystem, with an initial phase to be delivered in spring 2010. Other systems are in incubation. Numerousschools have expressed a desire to be able to swap out all three of the major administrative systems and sothere is a need for an enterprise-wide HR/Payroll system.In the case of the latter, many vended systems dont provide functionality specific to higher education, andmany home-grown systems are increasingly unsustainable. Expectations are growing for updated andeffective systems that are more usable for end users, that are more flexible for administrative, regulatory andpolicy changes, and that provide the necessary functionality that is required by higher education.

Since Fall 2008, some institutions have been exploring the idea of a Kuali HR/Payroll project. This report isthe outcome of those discussions. It identifies functional business requirements, a technical architecture,and resources and a timeline for a proposed Phase 1. That Phase 1 includes: Payroll & Financialprocessing, Position Management and Person Data, Organizational Structure, Job Actions/HR Actionsincluding Employment Records and Appointments, Timekeeping, and Benefits Administration for PayrollProcessing. Later phases will include other robust modules for a fully comprehensive HR/Payroll system.

Like other Kuali projects, this project will involve partners pooling their resources to deliver the system.Those partners will guide and oversee the priorities, outcomes, and deliverables. As in other projects,implementation of the application will be faster and less expensive for the partner schools since they willhave gained an understanding and knowledge about the application being implemented.

Other benefits of this model for HR/Payroll are:

The ability to leverage the Kuali Foundation organization and community.

The ability to reuse Kuali technology infrastructure (Kuali Rice).

A set of best practices that reflects the wisdom of crowds model of functional design.

A sustainable model for having continuous but non-disruptive upgrades and enhancementscontributed by the community or commercial affiliates.

Control of destiny in design/development/delivery by the community. Shared resources which spread the cost of the development, instead of universities duplicating efforts

with home-grown or vended systems.


5/88


4

The recommended timeline and required resources are shown below.

JanQ1

JanQ1

Apr

Q2

Oct

Q4

July

Q3

Deployment

Apr

Q2

July

Q3

Oct

Q4

JanQ1

Apr

Q2


6/88


5

Resources required (resource breakdown by module can be found in Section 5.2)

Project Resources# of

Resources

Project Manager 1

ConfigurationAdministrator 1

Writer (UserDocumentation) 1

Module Resources*# of

Resources

Lead Subject MatterExpert 10

Business Analyst 13

DevelopmentManager 2.3

Developers 30

* Recommend every institution to devote 30% SME time per module to contribute to development of the application.Knowledge about the application in turn will help in their institutions implementation.

The proven track record of community source projects and increased need for a robust and mature HR

Payroll application makes it a right time to consider if there is enough interest and resources available to form

a Kuali HR Payroll project.


7/88


6

3.1 FunctionalOverview


8/88


7

3.2 PositionManagementThe purpose of this document is to define the essential requirements for establishing, tracking and controlling

positions distributed throughout the organization. Position Management is practiced at several participatinguniversities, and others have position management elements within existing applications; consequently thisfunctionality will be developed for use as an optional module.

The primary objective of Position Management is to provide a method to track, manage and report on currentand historical position data. Examples include:

1. Create and track position data and history.2. Process employee appointments by position.3. View incumbent, position, and budget histories.4. Vacate and/or eliminate positions.5. Track and report on budgeted positions.6. Track and report on location of positions.

7. Access trending data on position classifications, locations and histories.8. Enable position control for certain types of positions.

3.2.1 ScopeIncluded in Phase 1 Scope

Key data fields required for creating, controlling and managing budgeted and non-budgeted positions.

Attributes associated with Position Descriptions

Additional supporting attributes

Assumptions

Position Management will be built for use as an optional module.

Functionality to create, modify and eliminate positions is assumed. Workflow routing and hierarchy will be built independent of Kuali HR/Payroll, likely in KOM.

Process Flow

Departmental

UserInitiates

Request

New/Modify

Request

Routesfor

Required

Approvals

Request

Routesfor

FinalApproval

Request

Approved/

PositionID

assigned


9/88


8

3.2.2 Business RequirementsThe requirements listed are consistent with the information in the eDocs Create Position document fromIndiana University and have been expanded to include additional data elements.

Basic Position Management Data1. Position Number

a. This number stays with the position from initiation throughout lifecycle2. Effective and End Date3. College/Division/ORU4. Position Type

a. Academicb. Staffc. Studentd. Other (e.g., without salary)

5. Budgeted Position

a. Yes/no6. Status of Positiona. Active/Inactive

Position Data7. Title Code8. Payroll Title9. Organizational Reporting Relationship (Reports to)

Position Location10. Department (drop down menu)11. Location (drop down menu)

Job Group Data12. Job Group

13. Job Family14. Appointment Typea. Careerb. Contractc. Academicd. Per diem (Health Care/Seasonal)e. Temporary

15. Appointment % (Fulltime/Variable)16. Salary Range17. Salary Grade18. Overtime Eligible (FLSA)19. Union/Bargaining Unit20. Employee Relations Code (Manager Confidential, Manager Not Confidential, Supervisor, Supervisor-

Confidential, All other, Confidential, Out of State)21. Pay schedule (monthly/hourly/annual)22. Work Period23. Special Position Conditions

a. Background Checki. Required/Not Required

b. Conflict of Interest Designated Officiali. Required/Not Required


10/88


9

c. Medical Surveillancei. Required/Not Required

d. Pre-placement Medical Exam

i. Required/Not RequiredDetailed Position Description24. Employee First Name25. Employee Last Name26. Employee ID27. Payroll Title28. Payroll Title Code29. Job Group30. Overtime Eligible (FLSA)31. Bargaining Unit32. Representation33. Salary Grade

34. Salary Amount35. Position Number36. Department (Home Unit)37. Home Account # (Home Unit)38. Position39. Supervisor Name40. Supervisor Payroll Title41. Supervisor Phone Number42. Job Summary43. Campus Job Scope44. Department Specific Job Scope45. Positions Supervised

46. Essential Responsibilities47. Physical Demands48. Work Environment49. Qualifications

a. Minimumb. Preferred

Service Accrual50. Ability to track service according to university policy. For example, university policy may allow for

employees to receive credit for service related to multiple employment periods. An employee mywork for a department for 10 years, leave the university for a year and then return to a new positionfor 2 years. Policy may allow the employee to receive credit for 12 years of service even though they

are not consecutive. Additionally, an employee who is on an extended leave of absence may not becredited for they time they are on leave. The system should allow for the calculation of universityservice relative to the policies defined for the organization.

51. Service calculations should be rules based using historical employee transactions to determine theemployees service.

52. University service credit is used to determine: time off accrual rates, eligibility for higher time offaccrual rates, and terminal pay limits. It is also used as a factor in determining recipients of servicerecognition programs.


11/88


10

53. The ability track and convert casual (employees hired < 50% time) employees to career status if theyhave worked more than 1000 hours within a set period. This also makes them eligible for Benefits.

3.3 Organization/DepartmentDataThis document defines the essential requirements for defining the department and organization data relativeto hierarchy. This informs communication strategies, workflow/routing, authorization, application record levelsecurity, supervisory relationships and more.

The primary objective of Department/Organization Data is to provide a structure to support a variety ofbusiness functions, manage reporting, communication, workflow and routing, tracking, access andauthorization, via organizational and supervisorial hierarchy. Examples include but are not limited to:

1. Reporting

2. Workflow/routing

3. Authorization and security4. Supervisory Relationships

5. Organizational Models

6. Communication strategies


Department and Organization Data include data related to specific department attributes and thelocation of department within an organizational hierarchy.

Supervisorial hierarchy includes specific supervisory reporting relationships.Assumptions

Department/Organization Data will be built independent of Kuali HR/Payroll, likely in KOM.

3.3.2 Business RequirementsThe organizational structure of higher education is based upon a hierarchy of departments. As an example,the Botany Dept falls under the Biology Dept which falls under the Arts and Sciences Dept which rolls upunder the a Campus Dept which is under a University College. Each level of the hierarchy may be referredto by a different name such as "Campus", "Responsibility Center", "Department" and Unit, etc. It is withinthis nested structure that budget, Human Resources, Payroll and other business and academic functions andtransactions are processed.

The business requirements for a robust Department/Organization function include:6. The functionality to roll up to the highest organizational level and to roll down to the lowest

organizational level.6. An unlimited number of levels within the organizational structure.6. The functionality to provide many levels of reporting6. Application record level security6. Workflow and approval routing for documents.6. History of additions, deletions, transfers


12/88


11

Common data elements for all levels within the hierarchy include:Department, Unit, Division, College Level

1. ID codes that link nested groups (e.g., 02 = College Code, 0210= Division code, 0220 = Department

Code)2. Effective Date3. Status4. Description of Department, Division, College, etc.5. Location (Campus, County, State)6. Address7. Key Department Positions (Department Manager, Medical Director, etc.)8. Reporting relationships

3.3.3 Functional Evaluation of re-usable componentsThe Kuali Financial System (KFS) organization document and hierarchy is recommended for reuse for theKuali HR Payroll department data. The documents have been built in the Kuali Rice framework and should

be fully reusable. Currently the organization document is part of KFS and it is recommended that theorganization document be abstracted out to Kuali Rice if possible to the proposed Kuali OrganizationManagement (KOM) module.

3.4 HRActions/JobActionseDocs are electronic documents that provide departmental users a friendly interface to conduct day-to-dayhuman resource business activities. These documents serve as templates to facilitate complex data entryinto the database and enforce policy & accuracy by providing filtered valid values. eDocs eliminate paperforms and serve as an archive of the business activities. eDocs were developed using the Kuali Riceframework. When coupled with Kuali Workflow, eDocs can be routed thru multiple stops before thetransaction is finalized to the database. These stops are based on pre-defined rules that can be set up at

varying levels of complexity.

Primary objectives of eDocs include:1. Act as front end to human resources management system for distributed users.2. Provide users with a user-friendly interface with which to process personnel transactions.3. Facilitate ease of upgrading Kuali HR Payroll database. Changes made to the central system are not

visible to most eDoc users. This means that each change does not require extensive re-training fordepartmental users.

4. Ensure proper approval process.5. Enforce compliance with business rules.6. Provide historical data of personnel transactions.7. Enable reporting against eDoc transactions.


Only current functionality is included in scope.

Modification of eDocs to work with Kuali HR Payroll system.

Import student system data into Kuali HR Payroll system.Excluded from Phase 1 Scope

Any enhancements to existing functionality. These would require detailed functional requirements.


13/88


12

Reporting against eDoc transactions.

Self Service functionality, this will be part of the HR Module in Phase 2.

Tracking of Training and Credentials should be included in Phase 2.

Faculty Records should be included in Phase 2. EVS Information should be included in Phase 2.

Competency Management

Performance ManagementAssumptions

It is assumed that Kuali eDocs will leverage a workflow engine to support administrative transactions.The Indiana University eDoc functionality currently uses the Kuali Rice workflow engine. Thesedocuments will be archived, accessible and searchable by users.

The eDoc will have the ability to pre-fill values from the database.

The database has a set of maintenance tables that the eDoc references.

If desired, individual schools will be responsible for integrating their student data into the Kuali HRPayroll system.

Process Flow

Departmental

UserInitiates

eDoc

DocumentRoutes

forOptional

Approvals/

Acknowledgements

Document

Routesfor

Required

Approvals

Document

RoutesforFinal

Approval

Transaction

Savedto

Database


14/88


13

3.4.2 Business RequirementsOur business requirements include the ability to process the following personnel transactions using routableelectronic documents. Items with asterisks may not be required if Kuali HR Payroll system does not include

functionality. New business processes will be required to replace current functionality that is not included inKuali HR Payroll.

Person eDocsThese documents collect: name, personal data (SSN, gender, etc), address, phone and I-9 data.

1. Add New Person eDocCreates a person in the database so that they can be hired into a job

2. Maintain Person eDocModifies personal information

3. Should support program administered by Department of Homeland Security to verify US workeligibility.

i. Detailed documentations can be found at:

http://www.uscis.gov/files/nativedocuments/E-Verify_Manual.pdfii. Need ability to track E-Verify information including historical information.4. Under biographic & demographic data add oath date, patent date and probation end date

Personnel Transaction eDocsThese documents collect: position data, funding, timekeeping assignments and earnings data.

5. Hire Transaction eDocsa. Hire Employee eDoc

i. Hire an employee, including into a contract pay assignment.ii. Applies to non-benefits eligible academic appointees. I.e. Graduate Assistants.

6. Position Change eDocsa. Transfer Employee eDoc

i. Used when an employee is moving from one position to another.b. Promote Employee eDoci. Used to promote an employee to a higher ranking position.

c. Demote Employee eDoci. Used when an employee moves to a lesser ranking position than there current one.

7. Leave Transaction eDocsa. Leave of Absence eDocb. Return to Duties eDoc

i. To return an employee to work status after a leave of absence or short work break.c. Suspend Employee eDocd. Short Work Break eDoc

i. Break Initiated by Department. I.e. Closes for summer.8. Terminate Transaction eDocs

a. Terminate Employee eDoc9. Maintain Job eDocs

a. Renew contract eDoc *i. Renew contract for employees hired into contract pay assignments.

b. Maintain Job Data eDoci. Used to maintain job data specific attributes.

c. Maintain Pay Rate eDocd. Maintain Funding eDoc


15/88


14

i. Modify funding for position.e. Maintain TIME Assignment eDoc

i. Creates TIME assignment for timekeeping system user.

ii. Modifies TIME assignment.iii. Assumes usage of Kuali TIME system.10. Administrative Post eDoc

a. Assigns academic titles to all faculty.b. Not tied to job.

Mass Transaction eDocs11. Mass Terminate Employees eDoc12. Mass Maintain Pay Rate eDoc13. Mass Renew Contract eDoc *

Position eDocs

These documents collect: position data, work location, classification information and specificinformation (work period, budgeted position)14. Create Position

a. Creates new position in database.15. Maintain Position

a. Modifies attributes of position.

Additional Pay eDocsThese documents collect: employee information, additional pay position, reason, dates, amounts andfunding.

16. Create Additional Pay eDoca. Creates additional or supplemental payment in addition to base pay.

17. Maintain Additional Pay eDoc18. Create Summer Pay eDoca. Creates temporary summer assignment and pay.

19. Hire for Additional Pay eDoca. Enables payment outside of regular pay cycles. I.e. To reimburse affiliate for ongoing cell

phone usage on behalf of University.

Screenshots of the edocuments from Indiana Universitys job action/hr actions system can be found athttps://test.kuali.org/confluence/download/attachments/190808214/Kuali+e-Doc+Requirements+9+08.28.09.doc?version=1

3.4.3 Functional Evaluation of re-usable componentsIndiana University HR actions/Job Actions edocuments are recommended to be used as the baseline forKuali HR Payroll project. It is fully expected that new attributes will be added to the edocuments and severalof the documents might also be merged on the user interface.

The edocuments should be made use of during analysis as a baseline system and will help reduce theamount of functional analysis time.


16/88


15

3.5 TimekeepingKuali Timekeeping (KT) will provide a system to record hours worked, hours in pay status, and absent time in

an easy-to-use, always accessible, web-based interface. KT will handle multiple jobs, pay types, and paycycles based on the employee's active appointments with the university. KT will calculate all special rates ofpay such as overtime, shift differential, premium, and holiday pay.

The primary objectives of the timekeeping system are:

Elimination of paper-based, departmental, or outsourced systems

Appropriate approval routing based on appointment type and labor distribution

Consistent application of University policy as well as state and federal labor laws

Auditability

3.5.1 ScopeIncluded in Scopea) Access: System is accessible 24/7/365

b) Authentication: Users must authenticate to access timesheets or system components.

c) Authorization: Role-based authorization to timesheets and system components.

d) Approval Routing: Timesheets, rules, and maintenance table entries can be configured to route forapproval.

e) Audit Capabilities: System will track all data changes made on a timesheet.

f) Pay Cycles: System must handle monthly, semi-monthly, biweekly, and weekly pay.

g) Pay Types: Employees may be paid on an hourly or flat-rate basis and may receive dollar-based paysuch as tips.

h) Employment Data: system will integrate with employment transaction system for real-time data.

i) Time Recording: Time can be recorded via clock in/out or manual time entry.

j) Regular Pay: system will determine appropriate regular pay earnings.

k) Overtime: System will calculate all overtime pay.

l) Shift Differential and Premium Pay: System will apply shift and/or premium pay based on systemrules.

m) Holiday Pay: System will auto-populate holiday pay based on system rules.

n) Override Capability: System will allow administrative override of all business rules.o) Notifications: System will allow configuration email/workflow notifications.

Excluded from Scopea) Work Schedules: System will allow work schedules to be developed per employee.

b) Pay Corrections: System will allow corrections to erroneous pay.


17/88


16

c) External Timekeeping Feeds: System will allow approvals and confirmation of other timekeepingsystem feeds.

d) Reporting: System will provide every report imaginable.

e) Exempt Time-Off Recording: System will allow time-off only recording (no recording of hours worked)for FLSA exempt employees.

f) Vacation and Sick Leave Accruals: System will calculate accruals for multiple types of leaves.

g) Time-Off Requests: System will provide a mechanism for future time-off requests and approval.

AssumptionsKT will leverage KIM authentication/authorization and Kuali Workflow for approvals (as well as somenotification and audit requirements). KT will interface with KHR for employment data and feed into KualiPayroll.

Process FlowHR transaction >> KT picks up eligibility >> Timesheet Created >> Work Recorded (employee) >> ApprovalRouting >> Payroll Feed

3.5.2 Business RequirementsTime System1. Access

a) KT will be available 24/7/365 to any computer with an internet connection. This is important to keepin mind when considering the use of other databases for source data (such as HR employmentrecords). These other databases usually have the luxury of being down for maintenance outside of

regular business hours so there will need to be some caching/duplication of dependent data.b) KT will be accessible for time recording from mobile devicesc) KT will allow clock ins/outs from a voice-prompt phone system

2. Authenticationa) Users must authenticate through the schools authentication scheme.b) KT will not create separate user accounts or store any passwords

3. Authorizationa) Role-based authorization will be configured through maintenance screens

b) Roles will be hierarchical and based on the Department/Organization structure in KHRP as well asWork Areas defined in the KT system. So if a given user has View-Only rights at a ResponsibilityCenter level and four Departments roll up to that RC then the user has view-only rights in all four ofthose departments (all Work Areas).

c) Roles (the labels of which should be configurable per university):

i. Employee: has access to her own timesheet. Editing rights when in Workflow Action List only.

ii. View-Only: has ability to open timesheet from Workflow. No editing or approval rights. Canbe set at the Department or Work Area levels.


18/88


17

iii. Reviewer: has timesheet editing rights but will not be in the approval chain. Can be set at theDepartment or Work Area levels.

iv. Supervisor: has editing rights and will be the first routing stop. Set at the Work Area level.

v. TIME Processor: has timesheet editing rights and will be the final route stop beforetransferring data to the KHRP Payroll system. Set at the Work Area level OR Departmentlevel.

vi. TIME Manager: has timesheet editing rights but is not in the approval chain. This role wouldtypically be the lowest role with access to system rules and maintenance tables.

vii. TIME Administrator: another delineation that is similar to TIME Manager. This allowsdistribution of central-office type access to select users and is useful on multi-campusinstitutions. For instance, any departmental TIME Manager may have access to the LunchDeduction Rule but only a TIME Administrator on that campus could change a ShiftDifferential Rule.

viii. TIME System Manager: Edit access to all system features. Typically only a few users wouldhave this access. Typically set at the top level department in the org chart.

NOTE: Users may be in more than one role so access is limited on two planes: Departmentalorg structure and KT Role. So if you are a TIME Manager in department A but only aSupervisor in a Work Area for department B, you would NOT have TIME Manager-level rightsin department B.

d) Work Areas may be based on KFS account data and allow pass through approval to account data.For instance, a Work Area may associate one or more accounts and specify that Supervisor Role =Account.Account_Mgr. Any time recorded against that account would route to the account managerto satisfy Supervisor Approval.

e) Roles can be assigned to individuals or Workflow Workgroups.

4. Approval Routinga) Timesheets have a minimum of three approvals:

i. Employee: will also be the document Initiator in Workflow

ii. Supervisor: Workflow Approver

iii. TIME Processor: Workflow Final Approver

NOTE: it is possible for the employee to be an approver.

b) Rule-based optional approval will be available (similar to HR eDocs) based on the org structure, jobdata, and timesheet data. For instance, you only want to route to a workgroup if the job has a non-exempt status and the earning FMLA is used in the business school.

c) Timesheets can be returned to the previous route level for corrections.

d) The system will allow auto-approval of all timesheets at a given route level. For instance, it is notnecessary for employees to submit their timesheets a batch approval job will run when the payperiod ends. Another example would be a batch Supervisor approval that would auto-approve anytimesheets that supervisors have not approved so that TIME Processors have a chance to approvethe document.


19/88


18

5. Audit Capabilitiesa) System will record the employees IP address for any clock actions

b) Any additions, deletions, or edits to time blocks will record the users id, time of edit, and original

values

c) All approval auditing will automatically be captured in Workflow

d) Rule and maintenance tables will capture a user id and a timestamp for each addition to the table.Entries will have an Effective Date, Effective Sequence, and Active/Inactive flag so that no entry willneed to be deleted.

Timesheet6. Pay Cycles

a) System will be configurable to allow one or more of the following pay cycles:

i. Weekly

ii. Biweekly

iii. Semi-Monthly

iv. Monthly

b) Employees will have only one timesheet per pay cycle but may have concurrent timesheets in otherpay cycles.

7. Pay Typesa) Hourly rate: user records hours worked (or in pay status)

b) Piece-rate or flat-rate: user records an integer quantity

c) Tips or dollar-based: user records actual dollar valueNOTE: type of pay should be controlled by some value on the earning being used

8. Employment Data/Eligibilitya) Use of a KT Work Area on an HR eDocs Labor Distribution section will trigger eligibility for a

timesheet in a given pay cycle.

b) Removal of the Work Area or termination of the job will end eligibility for that job or assignment andtime recording will no longer be allowed.

9. Time Collection Methods

a) Clock Actions: Employees take an action in the system whenever they start or stop work.i. The clock in/out times are set by the central server

ii. Time zones must be handled between user location and central server time

iii. System will automatically correct the hours calculation for time that begins, ends, or spansDaylight Savings Time cutovers

b) Manual Entry: Employees enter the data at any time that the timesheet is available for editing.

i. Employees record hours worked by entering begin and end times


20/88


19

ii. Employees record hours in pay status by entering an hours value

iii. Employees record type and quantity of piece-rate work

iv. Employees record dollar value for tips and other wages

c) It is possible to record time from any of these methods on the same timesheet.

10. Calculated and System-Generated Entries (based on system rules)

a) Overtime, including double-overtime

b) Shift Differential

c) Premium Pay

d) Lunch Deductions

e) Holiday

f) All entries generated by the system should:i. identify which rule was applied (Rule Id)

ii. be associated with the original timeblock (Timeblock Id)

iii. allow deletion of the entry (system may recreate same entry on save)

iv. allow administrative override (an example would be a shift differential timeblock that thesystem created for 3 hours of some shift earning. An administrator could set the hours to 0and click override to stop the shift payment. If the timesheet tried to reapply the shift logic itwould find this row for the same Rule Id and know it should not apply it again)

Maintenance Tables10. Department Maintenance

a) Purpose: Allows entry of department-level roles like the TIME Manager.

b) Features: Since roles will traverse the org hierarchy it is not necessary to have each role at everydepartment. One TIME Manager in a large Responsibility Center could administer many departmentsthat roll up to that RC.

11. Work Area Maintenancea) Purpose: Used primarily to define approval routing under a given Supervisor. Also will drive some

basic rules like time collection method and overtime preference (paid or compensatory time).

b) Features: Any new work area added will need to be verified for mandatory route stops (Supervisorand TIME Processor). Will also provide a way to add assignments to all users in that work area byproviding a valid Account and alternate routing (if needed) per account. This would, for example,

allow easy addition of new TIME assignments to a group of research assistants when new grantmoney was received. Any work logged under that assignment is paid from that account withouthaving to change the employees labor distribution in the HR system.

12. Earnings Maintenancea) Purpose: To control the display of valid earnings for a particular group of employees. For instance,

employees who are not eligible for Vacation accruals should never have that earning as a choicewhen recording time.


21/88


20

b) Features: This table will also control the display of available earnings per role so that you can excludeearnings from the employee list that need administrative approval. Would also allow for departmentsto add/remove earnings as applicable to their specific department (for instance a special shift rate

earning that only applies to maintenance employees).

13. Earnings Groupsa) Purpose: To create groups of earnings to be used by system rules. Some examples would be

defining regular pay for meeting a jobs standard hours (FTE) to be made up of Regular Work Hoursplus Vacation, Sick, etc. or defining a group of earnings that should display a warning message whenused (such as FMLA).

b) Features: Pulls available earnings from KHRP Payroll system.

Rules14. Weekly Overtime Rule

a) Purpose: Provide logic for automatic conversion to overtime (or comp time) when hours workedexceeds some threshold such as 40 for regular overtime.

b) Features: Will allow multiple rules to be applied to the same timesheet to accommodated double andtriple overtime. Uses Earnings Groups to determine what hours count towards regular hours.

15. Daily Overtime Rulea) Purpose: To provide overtime pay when policy or law demands overtime compensation on a daily

basis. As an example, some union workers may get overtime whenever they exceed the scheduled8-hour day.

b) Features: Rule can be set up down to the Work Area level so that only one group in a departmentmay be eligible or you can use wildcards to make it apply to a broader group (including everyone).

16. Rounding Rulea) Purpose: Set rounding factor for clock punches.

b) Features: Allow different rounding rules for different employee types.

17. Lunch Deduction Rulea) Purpose: Allow for specified lunch deduction from applicable shift without having the employee clock

in and out for lunch.

b) Features: Rule can be set up down to the employee record or wild-carded for larger groups.

18. Shift Differential Rulea) Purpose: Applies specified shift earnings for applicable hours worked within a specified time range.

b) Features: Rule can be set up down to the Work Area level. Rule can also be used for Premium pay.

19. Holiday Rulea) Purpose: Allow for entry of calendar dates and associated Holiday earn code.

b) Features: Rule can be used for standard Holiday earnings (single entry) or can be entered as tworules on the same date if your school uses separate accrued and taken earnings. Can be set to be


22/88


21

a factor of FTE. In other words, a rule set up to apply 8 hours of Holiday would only apply 4 hours toa 0.5 FTE job record.

20. Notification Rule

a) Purpose: Allow for entry of a Java logic class, optional parameters, and valid system roles for email orworkflow notifications. The developers would need to write code for and expose certain logic classesfor use in this rule. For instance, a MissedClockOutLogic class might be exposed that takes an hoursvalue as input. You could then set up a rule to notify the TIME Supervisor if the last clock action wasa clock in and it was more than 24 hours hold. If in time you find that 24 hours is too long, yousimply update the rule 12 hours without any coding changes. This would allow individual schools theability to create complex, but self-contained, notification logics for their school.

b) Features: Exposes typically hard-coded logic and validation via defined user inputs.

The pre-project working group reviewed Indiana Universitys TIME (Timekeeping Information ManagementEnvironment) system. System overview and documentation can be found at:

https://uisapp2.iu.edu/confluence-prd/display/TIME/Home

3.5.3 Functional Evaluation of re-usable components (Timekeeping System)Indiana University Timekeeping system is recommended to be used as the baseline for Kuali HR Payrollproject. It is fully expected that new attributes might be added to the edocuments or other changesrequested in the system.

The edocuments should be made use of during analysis as a baseline system and will help reduce theamount of functional analysis time.

3.5.4 Functional Evaluation of re-usable components (ePTO)

The pre-project team saw a demonstration of Indiana University's e-PTO system which is a web-basedapplication for the recording and approval of time-off for professional (exempt) employees.

The system has a good visual with drill down capability and looks relatively easy to learn for the end-user.The system was built on the Kuali framework and leverages Kuali workflow.

Some of the functionality covered includes:

Recording time-off taken as well as time-off planned in future months

View balance information for PTO, sick and holiday balances for current and future months

View correction detail in cases where usage or balance information has been corrected by a supervisoror administrator (the system allows for changes by supervisor or administrator after employee

submission).

Functionality for supervisor includes:

Approve/disapprove monthly time-off records submitted

Correct previously approved time-off usage records (corrections are logged and viewable by employee)

View monthly records of recorded time-off for all employees on a single page

View individual employee detailed usage and balance information (current and future)


23/88


22

Information on e-PTO can be found at http://www.indiana.edu/~uhrs/hrms/ePTO/index.html

The pre-project team recommends considering e-PTO as a baseline during the analysis phase but thefollowing areas need further consideration (possible enhancements):

Integrate e-PTO with payroll and timekeeping components

Consider a design where the system works for both exempt and non-exempt employees including faculty.

3.6 BenefitsAdministrationThis section outlines the requirements for creating a Benefits Administration component for the KualiHR/Payroll module. This Benefits component focuses specifically on Benefits functions that affect Payroll:Employee benefits enrollment, deductions, and billing.

Benefits enrollment composes a big part of Benefits Administration.

Regular Enrollment is active throughout the year allowing employees to change only those plans that are notrestricted to an annual enrollment. Regular enrollment must also allow full Benefits enrollment availability toqualified new hires and to employees with special circumstances and major life changes that affect benefits.

Open Enrollment is enabled only during the Benefits Open Enrollment period when employees mayadd/cancel/change any of their Benefits plans to become effective for the following year. The system must beset up with the following years plans, rates, and dates while retaining the current years data.

The primary objectives are:

The Benefits component shall remain highly customizable to accommodate each universitys differentrequirements; business rules are not hard-coded.

The component shall be flexible enough to accommodate different and multiple benefits packages, rates,

rules, etc.

The component shall accommodate multiple Benefits plans, rates, eligibility, etc. and determineemployees benefits package based on various criteria established by custom business rules (e.g., Unioncontracts, time worked, pay rate, Job, salary, etc.).

The component shall be table-driven; not hard-coded. All benefits details (plans, rates, etc.) are to be setup in tables.

The component will allow for and follow appropriate business rules for different deduction frequencies(every pay, only first 2 BW pays in the month, etc.) and different deduction timing (deduct for the samemonth as effective coverage, deduct 1 month prior to effective coverage, etc.).

The component must maintain a historical account of all data and transactions.

The component will account for and retain a history of not only employee deductions but also anyemployer contributions made on behalf of the employee for his/her benefits plans.

The component must allow deduction data feeds from other systems/depts. before payroll is processed.


24/88


23

3.6.1 ScopeIncluded in Phase I Scope

Benefits Administration for Payroll: Benefits business rules; table setup for plans, rates, deduction, etc.

Benefits Enrollment: Both regular and open enrollment, and available both by employee self-service andBenefits personnel entries

Benefits billing & accounting: deduction adjustments, etc.:

Automated retro benefit deduction functionality as well positive input and manual overrides.

Prorated benefits deductions based on custom business rules (coverage/deduction begin & end dates, ormonth start & end, etc.)

Leave business rules and accrual

Vendor files and/or interfaces

Calculate Tax-Deferred Annuity (TDA) applicable IRS limits and warnings when an employee is close toreaching a limit. The system will utilize end dates, deduction limits, and decreasing limits to stopdeductions automatically upon reaching a limit.

Cloneable Tables: The component will allow the ability to duplicate existing tables, either by selection orby its entirety, to create a new set of tables that are independently modifiable.

Record & track dependent & beneficiary people data

Record & track employer contributions

Batching processing to update multiple records

Employee benefits status screens

All Federal and State required reports.

Excluded from Phase I Scope (for Phase II)

Provide health education tracking for wellness programs (health incentive programs)

FMLA Billing to be covered in Benefits Phase II; tracking & reporting is part of HR component.

Comprehensive COBRA tracking module.

Employee Fee Remission - Module that tracks the eligibility and usage of an institutional subsidy towardtuition costs associated with attending a classes

Option to provide OSHA recordkeeping

Workers Compensation, private disability insurance plans, etc.

Excluded from Scope

Leave requests, approval, and tracking (part of Timekeeping)

Voluntary Employee deductions that are not related to Benefits

Employee Benefits Statement, either online from Employee Self-Service and/or annual printed hard copy


25/88


24

Assumptions

Kuali Rice & Workflow must be in place for transaction routing and approvals.

Employee demographics, job, employee type, pay, etc. components must exist to determine eligibility andthe payroll component must exist to calculate deductions.

A centralized dependents/beneficiary data store should exist to provide efficient dependent data changesand to record dependent benefits coverage eligibility.

An external Employee Self-Service system may be used to capture enrollment data.

There will exist some kind of security to guard privacy, authentication to control access, and backupsystem for disaster recovery, either as a part of Kuali or local system. This must include encryption for allsensitive fields (SSN, DOB, etc.)


26/88


25

Process Flow

Thisisanoverviewdiagramo

fBenefitsEnrollment,whatdataaffectsenrollment,andh

owenrollmentaffectsotherdata.


27/88


26

3.6.2 Business RequirementsBenefits EnrollmentAccess is to be provided to the indicated user groups for each of the following business functions:

1. Benefits Enrollment (Regular): Add/Cancel/Change Benefits Administration Employee Self-Service Vendor Other

2. Open Enrollment (Open): Add/Cancel/Change Benefits Administration Employee Self-Service Vendor Other

3. Dependent Data Benefits Administration Employee Self-Service Vendor

System Requirements4. Enrollment ActionsThe system must take into account the following factors in managing enrollment actions:

Job Personnel Employee

Retiree (both Medical & Retirement benefits) Union Faculty Records/Actions Student/CWSP Other (Local)

5.Eligibility & Coverage ConsiderationsThe system must consider the following factors in determining benefits eligibility and coverage for both theemployee and the employees dependents:

Eligibility date (after waiting period) Coverage Start & End Dates

Dependents: birth date (age), relationship, certified date (proof of eligibility) The employee is covered by another insurance The employee is a dependent Retiree Benefits

6.Benefits Vendor CommunicationThe system must be able to generate for vendors and process from vendors the following files:

Eligibility Files


28/88


27

Payment Files

7. Tables

The system must be table-driven; benefits details should not be hard-coded. The following items are to be setup in tables:

Benefits Enrollments Benefits Eligibility Benefits Plans Benefits Rates: Current, Future, Open Enrollment, Dependent Rates on Pay Rate

Other8. Required Features (Phase I)The system must incorporate the following features:

History Benefits Billing (COBRA, Unpaid employees on Leave, real-time retiree billing etc.)

o Make retroactive benefit adjustments and refunds

Dependent Datao Perform automatic, date-driven messaging; for example, create correspondence relating to

eligibility based on ages of employees and dependents Leave Accrual & Eligibility

9. Considered Functions (Phase II)Additional functions that could be incorporated at a later Phase:

Other non-mandated reporting COBRA - Module used to track and administer employees and dependents who are eligible for COBRA.

Billing is part of Phase I; more complex event-driven tracking & eligibility module to be built in Phase II.

3.7 PayrollProcessingThis section describes the requirements necessary for the payroll processing component of the KualiHR/Payroll module. Payroll Processing includes the collection of pay data from HR actions (eDocs) and/orpay data from time and attendance systems used throughout the university. Through the use of a Pay Calcengine, Net Pay is calculated. Also, Payroll Processing will produce output/files needed to transfer directdeposits to employee bank accounts, pay taxes as appropriate, and pay vendors as needed.

Pay Calculation:

Collect Gross Pay data from multiple pay types

Collect Employee-Payroll information (W4)

Collect deductions and garnishments from multiple sources

Prioritize the deductions and garnishments

Calculate Net Pay


29/88


28

Output:

Direct deposit or paychecks to employees

Payments to vendors (benefit plans, retirement plans)

Federal, State, Local taxes Periodic Reporting and Payments

End of year Reporting W2, 1042, 1099R

The primary objectives include:

Accurate and Timely payment of net compensation to employees

Accurate and Timely payment to vendors and taxing authorities

Required Reporting for federal, state and local taxing authorities

Web-based system based on Kuali standards and Kuali methodologies

Consistent application of University policy as well as state and federal labor laws Auditability

3.7.1 ScopeIncluded in Scope

Authentication: Users must authenticate through the schools authentication scheme to access the KualiHR/Payroll system.

Authorization: Users must be authorized to use the system

1. Roles will be hierarchical and based on the Department/Organization structure in Kuali HRPayroll.

2. Roles (the labels of which should be configurable per university):

1. View-Only: No editing or approval rights. Can be set at the Department or Work Arealevels.

2. Payroll/Central Office Some functions are available only to Payroll/Central Officeusers

3. Roles can be assigned to individuals or Workflow Workgroups.

Audit Capabilities: System will track all data changes. Any additions, deletions, or edits to data will berecorded using the user id, time of edit, and original values.

External Timekeeping Feeds: System will support feeds from other timekeeping systems, including KualiTimekeeping as well as other Time and Attendance systems (i.e., Kronos).

Pay Cycles: System must handle monthly, semi-monthly, biweekly, weekly, and on demand pay cycles.

Pay Types: System must support multiple pay types: monthly, biweekly, bimonthly, semi-monthly,hourly, and contract pay (specified length - X months worked paid over 12 months 9/12, 10/12, 11/12).

Employment Data: System will integrate with employment transaction system for real-time data.

Regular Pay: System will determine appropriate regular pay earnings.

Override Capability: System will allow administrative override of all business rules.


30/88


29

Notifications: System will allow configuration email/workflow notifications.

Excluded from Scope Employee Self Service is not included in Phase 1 scope. See Appendix for Employee Self Service

business requirements.

Reporting: System will provide only required reporting for federal, state and local taxes. Other Reportingis the responsibility of each implementing school.

Assumptions

The Payroll Processing component will leverage KIM authentication/authorization and Kuali Workflow forapprovals (as well as some notification and audit requirements).

Kuali HR/Payroll will not create separate user accounts or store any passwords

Some functions will be available only to Payroll/Central Office users. Interfaces to other systems (student, effort reporting, etc) are campus specific. Interfaces to other

systems will be the responsibility of each partner institution.

Payroll component will be integrated with HR components and with Kuali Financial System

Process FlowSee section 3.1 Functional Overview

3.7.2 Business RequirementsPayroll Processing1. Integrated system with Human Resource forms (actions) must be able to capture appropriate

monthly/biweekly/bimonthly salary2. Time sheet(s) must be able to process all requirements from T/A (OT, Shift Diff, holiday, meals, etc)

a. Workflow with approvals for all:

i. Biweekly

ii. Non-exempt (overtime eligible/FLSA)

iii. Flat/contractual payments no hours

3. Pay by Earnings Code (retirement eligible vs. non eligible)

See Appendix 4.1 for Examples of Earnings Codes

4. Effective dates to be used for many items (W4, Direct Deposit, Misc Deductions)

5. Option to terminate pay line/sheet (incorrect payments)

6. Ability to review paycheck data prior to compute/confirmation of payroll process.

7. Allow adjustments/one time deduction (Addition, Refund or Override) for retroactive benefits,garnishments and taxes.

8. Pre/post tax deductions

9. Ability to capture time more than once per pay period (by individual, group (appt. type) or all)So that we

can capture missed time prior to running payroll this allows for time to be captured after the deadline

but before payroll would run

10. Integrated with HR and financial systems (Associated with Time and Attendance system)


31/88


30

11. Payments charged to various accounts

a. Pay by Object code, sub class & work order number/job

Example of Kuali Account Structure:

Chart 2 charactersAccount 7 characters

Org 4 characters

Sub-account 5 characters

Object Code 4 characters

Sub-Object 3 characters

Project 10 characters

12. Pay vouchers must be on-line (electronic)

b. Approvable on line by department

c. Electronic repository for the method of storing and release to unit

13. YTD (CY & FY) totals earnings/supplements/deductions/taxes must be available to Payroll14. International fellowships need to be taxable ability to enter as flat tax or use tables which can then be

updated as needed with tax changes IU uses an Earnings Code

15. Federal Work Study fiscal year/semester/summer limits, splitting of costs on percentage basis, caps on

Work Study payments, limit by job record and earnings period, maintain control tables by campus and work-

study type, funding splits, and post-processing detail.

a. Financial Aid

b. Reporting

16. Adjustments to employee record need to be available Master file adjustments to correct any out of

balance accumulators. Must have reports that identify any out of balance accumulators (State, FICA, Medi,

local)

17. Accept Uploads/input from Kuali Timekeeping system or other Time & Attendance system createtimesheet for routing via Workflow ---

a. Must be flexible enough to capture time and associated data elements from multiple

systems (i.e. Kronos, Kuali TK)

18. Ability to process payroll advance outside system and then capture re-payment on the next payroll

through misc. deduction

19. Multiple Direct Deposit allowed

a. Distributed by amount, percentage or remaining balance (if amount is specified)

b. The system should support the ACH interface as well as an interface to an employee-self-

service application for employees to select direct deposit with their banking information.

System should support ACH direct deposit of other monies, e.g., credit union savingsdeductions and 403(b) investments to Fidelity. Partners use different methods of

processing funds to vendors we need an application that will allow a direct link to payroll

data to process certain vendor payments directly from the payroll data

c. Bank file (NACHA compliant) system must be set-up to validate all bank routing

numbers and show error if bank number is not on file (Thompson Bank file or similar

service)

20. Audit trail all data changes should be auditable by Access Id, Time & Date stamp and what was


32/88


31

Changed (add, delete, change)

21. Pay adjustments These requirements should be discussed with the technical group We will need to

get an estimate on what it would take to use this requirement but we would also need to ensure that a

manual application exists for partners who wish not to implement (some partners will opt to calculate

manually)

a. Departments need the ability to enter pay adjustments relative to past payrolls

i. Corrections to incorrect rates

ii. Missed timesheets

iii. Incorrect hours reported etc.

iv. Job action (i.e., retroactive promotion)

v. System should calculate retroactive adjustment amount owed/owes

b. Pay adjustments require approval before processing

c. System should handle off cycle payroll processing

vi. On-line/manual/on-demand payroll processing (including direct deposit)vii. Either batched and paid on designated frequency or next available payroll (monthly,

biweekly etc) or paid on demand w/ the appropriate approval/flag

d. All actions Must identify funding sources

22. Additional Pay

a. UC has two types

Faculty Summer Salary - Benefits which are supplemental monies paid by the University and

posted to the participant's Defined Contribution Plan. Based on Description of Service for

payments. Activity is tracked via GTN numbers, reporting, and inclusion in expense distribution

Senior Management Supplement - supplemental monies paid by the University and posted to

participant's DCP plan. An eligibility indicator is maintained on the Employee Database. Activity is

tracked via GTN numbers, reporting, and inclusion in expense distribution.

b. PSU has two types

Supplemental I 36 week contract and employed temporarily (summer session)

Supplemental II additional services provided during the same weeks of service as the primary

contract (standing & Fixed Term I)

c. Support various forms of payments (i.e., allowances, awards, supplementals) effective-dated

with individualized funding.

One-time

Recurring non-regular wage

23. Query Functionality within Payroll System (Based on Users Access)

24. Interface with student/enrollment services to determineb. student FICA exemption

c. Graduate enrollment

d. NRA FICA exemption

25. Interface with financial aid for work-study processing.


33/88


32

Taxes and Tax TablesWithholding for multiple State/Local tax26. Table set-up for federal, state, local etc (LST)

i. Support collection of employee tax withholding information for Federal, State, andLocal withholding

a. Follow standard Federal and State formats and rules

b. Ability to customize Local withholding per state requirements

ii. Include rates for Federal income tax, Social Security, State, Medicare, and

Unemployment tax (including other Federally mandated employer and employee

tax)

iii. Accommodate special tax (W4, WH4) data collection

a. NRA tax-treaties (1042-S)

b. Out-of-state and/or multiple state employees

c. Different Work/home states

d. Expatriates

e. Earned Income Credit (EIC)

f. Lock-in letters

g. Tracking of received/expiration dates

h. Custom W4

iv. Ability to setup graduated and flat rates based on

a. Specify for Federal, State, and Local tax tables

b. Tax status (Single, Married)

27. Tax Reporting - Required Federal/State/Local Reporting1. W2/1042s/1099R Reporting Create Reports and Output Files

Deductions and Deduction ManagementGeneral and Miscellaneous Deductions

28. Taxable Benefits Eff. Dt. driven (Cell phone, meals (automate entry into system))

29. Deductions Eff. Dt. driven (parking fees, United Way contributions, traffic fines, library fines, union

dues, etc..)

i. Deductions can be on-going (General) or one-time (Miscellaneous)

ii. Flat, Percentage or goal amount driven

iii. Code sets table of all current deduction typesiv. Priority set-up driven (what comes out first)

v. Frequency first, second or taken on all payroll periods

vi. Ability to suspend or close w/ a balance

30. Ability to load mass deduction (one-time or general) from a spreadsheet

31. Ability to assess one-time taxes based on input from a spreadsheet

32. Base Benefit Limits built - need to ensure TDA, Retirement limits are built into Calc so that an individual

cannot exceed annual limits


34/88


33

Garnishments

33. Federal/State rules regarding collection

i. Eff. Date driven garnishment set-up and control tablesii. Disposable earnings and exemption calculation formulas (max, minimum wage

&/or percentage of earnings) by garnishment type (i.e. tax levies vs. child supports)

iii. Rules for the different federal and state definitions

iv. Ability to establish specifics for each garnishment by employee

1. Status (Active, Suspended, Complete, etc.)

2. Issuing authority

3. Documentation references (court order #)

4. Payee

5. Deduction Schedule

6. Start/stop date7. Priority

8. Deduction amounts by flat amount or percentage

9. Limit amounts and balances

10. Processing Fees

11. Notes

12. Current deductions that are allowable

13. Tax exemptions for tax levies

14. Current vs. Arrears designation

v. Ability to suspend or close specific garn w/a balance

vi. Ability to process more than one garnishment per employee and apply the

appropriate proration rules.vii. Ability to designate which earnings are subject to garnishments.

viii. Balance Adjustment functionality for corrections not going through a payroll.

ix. Ability to process one-time overrides/additions/refunds

x. Create EFT to vendor system to make payment for child support.

Pay Calculation34. Pay Calc

a. Deduction priority list

b. Should calculate pay from gross to net process must handle regular recurring pay as

well as non standard additional pay and tax appropriately

i. Support Overtime, shift differential, on call etc.c. Accommodate general & base benefits as well as garnishments

i. Limits

ii. Goal amounts

iii. Federal/State rules & regulations must apply


35/88


34

d. Multiple pay frequencies monthly, biweekly, bimonthly, 10 over 12 months, 9 over 12

months, contracts, etc. manual payroll (off cycle companion to a regular payroll). Note:

USC has 2 different biweekly pay cycles.

e. Compliant with FLSA rulesf. Support the combining of earnings from multiple jobs into a single check for an employee

Multiple jobs would be identifiable on the pay advice

g. Support tracking of all earnings and deductions for purposes of reporting to tax agencies

(W2 processing)

h. Supports creation of checks or direct deposit on demand (off cycle) for immediate

payments

i. Ability to gross-up wages and taxes - ability to automatically have the system gross up

payments

j. Create Output files to support printing of physical checks and direct deposit advices

k. Create Output files to support creation of positive pay files for transfer to bankinginstitutions

l. Creation of ACH output files for transfer to banking institutions, incl new restrictions on

International Banks

m. Vendor files must be created after compute/confirmation

n. System should support final check processing with routing and approval.

35. Required Federal/State/Local Reportinga. W2/1042s/1099R Reporting

b. Printing

c. file layoutd. Federal mandated reports

3.8 FinancialProcessingThis section describes the requirements necessary for the payroll labor distribution and encumbrancesmodules of the Kuali HR/Payroll system.

Payroll Labor Distribution can be defined as the process by which payroll expenses are charged to individualaccounts for posting to financial systems. More specifically, Payroll Labor Distribution will:

Stage actual employee earnings on a payroll by payroll basis to accounts designated in theemployees job record.

Provide for the ability to override accounts designated on the employee job records on a payroll bypayroll basis.

Utilize the Kuali Financial System chart and org structure (accounting string).

Utilize the Kuali Financial System method(s) for determining fringe benefit rates.


36/88


35

Allow for certain accounts to not accept fringe charges and default charges to a central account (partof Kuali Financial System)

Provide a journal posting file in the format required by the Kuali Financial System.

Accommodate the tracking and limiting of employee earnings against accounts with established limitssuch as work study.

Assign default funding accounts for work study earnings based on predefined percentages for thetype of work study until limits are reached

Additionally, Payroll Labor Distribution will provide for the creation of journal entry files in the Kuali FinancialSystem format for payroll taxes and deductions.

Payroll Encumbrances is defined as the monetary commitment to future charges against a designatedaccount for a stated period of time, usually the fiscal year. The Payroll Encumbrance module will computethe university salary and benefit commitment through a time period designated by the user and create journalentry files for posting in the format supported by the Kuali Financial System. More specifically, the PayrollEncumbrance module will:

Compute salary commitments based on current and future job transactions.

Include all salary components including contracts and additional pay sources.

Compute benefit commitments using Kuali Financial System methods.

Include only salaried and biweekly non hourly staff

The primary objectives are:

To provide detailed salary and benefit expenses by account for the purposes of managing andreporting labor expenses within the financial system.

To provide a means by which appropriate individuals may make changes to standard funding sourceson a per payroll basis.

To accurately forecast payroll and benefit expense commitments for the fiscal year.

To provide a summary of payroll deduction and tax expenses for posting to the general ledger

3.8.1 Scope

Included in Scope The calculation of payroll expenses based on employee job funding.

The calculation of payroll encumbrances based on current and future job records and employee jobfunding.

A method by which appropriate users can change funding sources on a per payroll basis.

Generation of payroll expense and encumbrance journal entry files in the format required by the KualiFinancial System.


37/88


36

Flexibility to allow institutions to generate files for financial systems other than the Kuali FinancialSystem.

Support for and integration with the chart and org structure (accounting string) within the KualiFinancial System.

Support for and integration with the fringe benefit calculation method(s) provided by the KualiFinancial System.

Audit reports for the purposes of reconciling data between payroll and the financial systems.

Audit capabilities with respect to adhoc funding changes from employees job funding.

Summary reporting of expenses for each payroll by account for account managers to review.

The tracking of expenses against limits such as work study.

Splitting of funding to default accounts for work study based on the type of work study up to limitdefined for the employee.

Excluded from Scope

The ability to change funding sources after journal entries that have been posted to the financialsystem. This should be done within the financial system.

General reporting outside of what has been specified as in scope above.

The creation of chart and org structure as well as the establishment of benefit distribution methods. Itis assumed that we will use these functions from the Kuali Financial System.

Assumptions

All security and authorization will be handled via Kuali Identity Management.

The use of the Kuali Financial System Chart module for establishing and validating the chart and org

structure within the Payroll Labor Distribution and Encumbrance module. To use of the Kuali Financial System Labor distribution module for the purposes of using benefit

allocation method(s)

Notes: How do we handle charging expenses to when the timing of effort and actual expenditures do notmatch. For example, paying employees over 12 months for work performed over 10 months. How do weproperly expense labor during the 2 months when the employee is not actually working.


38/88


37

Process Flow

Kuali Financial System

Chart Module

- Chart Org Structure

Labor Distribution Module

- Benefit Distribution Method(s)

Kuali Payroll Module

Payroll Records

- Paycheck Earnings

- Paycheck Taxes- Paycheck Deductions

Kuali HR Module

Job Records

- Employee Funding

- Current and Future Transactions

- Compensation Information

Additional Compensation

- Additional Comp Rate

- Additional Comp Funding Source

Kuali Payroll Labor Distribution and

Encumbrances

Ledgers

- General Ledger

- Labor Ledger

- Calculation of payroll expenses based on employee job funding.

-Calculation of payroll encumbrances based on current and future

job records and employee job funding.

- Change funding sources on a per payroll basis.

- Payroll expense and encumbrance journal entry files in the

format required by the Kuali Financial System.Audit reports for the purposes of reconciling data between

payroll and the financial systems.

Tracking of expenses against limits such as work study.


39/88


38

3.8.2 Business Requirements1. Payroll Labor Distribution - Labor Expenses

Batch job to merge payroll expenses to employee job funding

o Allocates expenses based on percentages or flat amounts

o Validates all accounting string components to make sure they are still valid

o Applies pooled fringe rates based on method(s) defined in KFS

o Generates A2 (prior period) entries for posting to labor ledger based on the period for whichearnings were earned.

o Assigns continuation / clearing accounts for accounts that are no longer active within KFS

o Updates accumulated balances against accounts where limits are tracked such as work study

o Assigns default federal accounts for work study earnings based on the type of work study andvalidation against employee limits.

o

Generates output journal entry poster file Setup tables to manage work study types and federal account distribution and limits

Setup tables to manage employee work study limits (may already be in HR document)

Summary reporting of expenses for each payroll by account for account managers to review.

Audit report for reconciliation against data posted to labor ledger

2. Payroll Labor Distribution - Taxes and Deductions

Setup tables to manage default accounts by tax type

Setup tables to manage default accounts by deduction code

Batch job to generate summary journal entries for posting to the general ledgero Valdiate all accounting string components to make sure they are still valid

o Summarize data by account and transaction type being posted

o Generates output journal entry poster file

3. Payroll Encumbrances

Batch job to generate labor ledger journal entries for payroll encumbrances

o Accepts as input start and end dates for computing payroll encumbrance

o Evaluates current and future job transactions to determine appropriate compensation rates,

job status and funding sources.o Considers all compensation types (Regular Pay, Additional Pay, Contracts etc.)

o Considers only Salaried and Biweekly non hourly employees

o Validates accounting string components to ensure that they are still valid

o Assigns continuation / clearing accounts for accounts that are no longer active within KFS

o Generates output journal entry poster file

o Applies pooled fringe rates based on method(s) defined in KFS


40/88


39

o Computes the difference between current and prior run for posting to labor ledger

Audit report for reconciliation against data posted to labor ledger

4.1 KualiRiceTechnicalArchitectureOverview(source: http://rice.kuali.org/rice)

Kuali HR Payroll application will be built on the Kuali Rice architecture. Kuali Rice provides a consistentdevelopment framework and common middleware layer for Kuali Foundation based applications to leverage.Rice is built with Service Oriented Architecture (SOA) concepts in mind.

Kuali Rice is made up of the components KNS (Kuali Nervous System), KEW (Kuali Enterprise Workflow),

KSB (Kuali Service Bus), KEN (Kuali Enterprise Notification), KIM (Kuali Identity Management)

Kuali Rice provides the following advantages to Kuali and non-Kuali applications:


41/88


40

By using the Rice framework, application and service developers can use a common developmentparadigm to promote rapid development that isolates many of the complications inherent to standardJ2EE development.

The Rice framework provides a level of infrastructure abstraction allowing application and servicedevelopers to focus on solving business problems rather than wrestling with the technology used to

enable those solutions. Rice ensures a consistent model for development which allows for the breakdown of monolithic

applications into smaller application modules and services that can easily talk to one another.

Kuali Nervous System (KNS)The Kuali Nervous System (KNS) is a software development framework aimed at allowing developers toquickly build web-based business applications. KNS provides:

Provides reusable code, shared services, integration layer, and a development strategy

Provides a common look and feel through screen drawing framework A document (business process) centric model with workflow as a core concept

KNS features include: Data Dictionary - Provides single location to define fields Transactional documents - Data entry that models business process Maintenance documents - Basic CRUD operations for support tables Inquires - Standard way to drill down into info Lookups - Standard search infrastructure Pluggable business rules Implement business rules in a self-contained Java class Configurable System Parameters - Register constants in the system, and control their values at run time

without having to change any code behind the scenes.

Kuali Enterprise Workflow (KEW)Kuali Enterprise Workflow facilitates routing and approval of business processes throughout an organization.KEW provides re-usable routing rule creation which defines how business processes should be routed,provides hooks for client applications to handle workflow lifecycle events of business processes as well asroute log functionality for auditing and other purposes. End users interact with central workflow GUIs for allclient applications.

KEW features include: Document search and route log - Allows users to search for documents (business process transactions)

and see an audit trail of what has happened to the document during its life cycle.

Action List - One place to go to find all documents that you must take action on. Displays a list of eachuser's pending items which require his/her attention, such as documents which are awaiting approval.

Content based routing - Routing decisions can be made based on XML document content. eDocLite - eDocLite allows quick document building and integration with workflow using XML-based

technologies and tools. Routing rules - Provides a mechanism for defining routing rules which govern which entities are

responsible for participating in the workflow transaction.


42/88


41

Notes and attachments - Notes and Attachments can be attached to documents using KEW's notes andattachments services.

Kuali Service Bus (KSB)Kuali Service Bus (KSB) is a simple service bus geared towards easy service integration in an SOAarchitecture.

KSB provides:

A common registry of services Lists all services on the bus and how they can be connected Through simple Spring configuration, Java based services can be exported from a rice enabled

application, which is then ready to be consumed by another application

A common resource loading layer that provides access to services (bus or local) Services can be local to the application, in which case the bus is short circuited Services can be remote, in which case the bus is leveraged to ascertain the service endpoint

Kuali Enterprise Notification (KEN)Kuali Enterprise Notification (KEN) acts as a broker for all university business related communications byallowing end-users and other systems to push informative messages to the campus community in a secureand consistent manner. KEW provides a secure and controlled environment for notifying the users andeliminates sifting through email.KEN features include:

Audit trail just as in KEW


43/88


42

Single list for all notifications - Works with the action list to provide a single place for all university relatedcommunications Workflow items come from KEW and non-workflow items from KEN.

Kuali Identity Management (KIM)Kuali Identity Management (KIM) provides central identity and access management services. It also providesmanagement features for Identity, Groups, Roles, Permissions, and their relationships with each other. Allintegration with KIM is through a simple and consistent service API (Java or Web Services).The KIM services are architected in such a way to allow for the reference implementations to be swapped outfor custom implementations that integrate with other 3rd party Identity and Access Management solutions.

KIM includes: Identity - KIM identity concepts include principals and entities. An entity is a person or system which

exists within KIM. A principal represents an entity that can authenticate into an application. These arecollectively referred to as a Person which can be created and maintained using GUI screens provided byKIM.


44/88


43

Groups - Groups consist of one or more principals or other groups. KIM provides services and GUIscreens for querying and maintaining groups and their membership.

Permissions - Permissions are the ability to perform actions. KIM provides services for performing

authorization checks against these permissions. Permissions are always granted to roles, never directlyto principals or groups.

Responsibilities - Like permissions, responsibilities are granted to roles. They define what responsibilitiesmembers of that role have, such as approving certain documents. Responsibilities are how KIMintegrates with the KEW workflow engine.

Roles - Permissions and responsibilities are granted to roles. Principals, groups and other roles areassigned as members of a role.

Additional Kuali HR Payroll Rice requirements Kuali Organization Management (KOM) The KFS organization hierarchy should be abstracted out to

Rice. This could potentially be the proposed KOM component in Rice.

4.2 AccessSecurityRequirementsThe following functionality is delivered by Kuali Identity Management (KIM)-Roles

1. Ability to create a role/profile for individuals or groups2. Ability to create a role/profile which defines the user's access and workgroup membership3. Ability to assign one or more roles/profiles to a user

Auditing1. Ability to allow access to e-docs after organizational changes(departments moving from one branch of

the org structure to another or individuals moving from one org to another)2. Ability to track effective dates for access

Security Management1. Ability to inactivate or suspend a user's access or to remove all access2. Pluggable architecture into an existing enterprise access management system external to Kuali3. Central office approvals / high level rights granting to folks such as Helpdesk so they can grant rights

down the hierarchy. Related to how to do the initial bootstrap of the highest level of authority in thedelegation chain

The following functionality has been listed as requirement and will need to be configured for HR Payroll.Permissions

1. Ability to restrict access on organization (Timekeeping and Payroll Processing have listed the abilityto authorize access to information based on organization). Need ability to cross organizations.

2. Ability to mask fields for restricted attributes like SSN, bank info


45/88


44

4.3 AssumptionsforTechnicalRequirements&Estimates

Estimate Assumptions

HR system (HR Setup, Position Mgmt, HR Transaction Setup, Person / Bio Demo) will be based on

the Integral data model.

The Integral data model will cover 50% of our functional requirements. Additional time will be added

to the estimate to accommodate HR functionality not covered by the existing Integral data model.

Individual page / process estimates include time for technical analysis, screen design, coding, testing

and creating automated test scripts.

Setup / control table estimates based on complexity are as follows Low = 80 hrs, Medium = 160 hrs,

High = 240.

Workflow document estimates based on complexity are as follows Low =

hr pre project plan nov 2009

Documents