Finance and Human Resources

Demonstration Scripts

Oracle

PeopleSoft

SAP

1. Introduction
1.1 Overview
1.2 Demonstration Guidelines
1.2.1 Demonstration Site
1.2.2 Demonstration Software
1.3 Demonstration Scoring
1.4 Demonstration Organizational Structure
1.4.1 Organization Chart
2. Infrastructure Demonstration Scripts
2.1 Cross Module Topics
2.1.1 Security
2.1.2 Workflow
3. Finance Demonstration Script
3.1 General Ledger
3.1.1 General Features

March 22-25, 1999

April 6-9, 1999

April 26-29, 1999

3.1.2 Chart of Accounts

3.1.3 Create a New Object Code
3.1.4 General Ledger Loan Funds
3.1.5 Journal Entry Processing
3.1.5 Fiscal Year-End and Period-End Processing
3.1.7 Automatically Generated Transactions
3.1.8 University-wide Financial Inquiries and Analysis
3.1.9 Departmental Financial Inquiries and Analysis
3.1.10 Uploading Transactions from Auxiliary Sources
3.2 Grant Management
3.2.1 Pre-award system
3.2.2 Cost-type invoicing
3.2.3 Fixed price / payment schedule invoicing
3.2.4 Performance invoicing
3.2.5 Invoicing prompting system
3.2.6 Electronic capabilities
3.2.7 Accounts receivable
3.2.8 Backup documentation
3.2.9 F&A Costs and F&A Cost-Sharing
3.2.10 Direct cost sharing
3.2.11 Effort certification
3.2.12 Closeout
3.3 Fixed Assets
3.3.1 Acquisition
3.3.2 Integration
3.3.3 Customization
3.3.4 Reporting

3.4 Accounts Receivable (Non-Student) and Collections

3.4.1 Creating an Account
3.4.2 Posting Charges
3.4.3 Sending Statements
3.4.4 Process Customer Information and Inquiry
3.4.5 Receive and Post Payments
3.4.6 Account Adjustments and Refunds
3.4.7 Credit and Collections
3.4.8 Reporting and Aging
3.5 Cash Management
3.5.1 Daily Cash Management
3.5.2 Cash Receipt Processing
3.6 Procurement
3.6.1 Internal Purchasing
3.6.2 Small Purchases - Less Than $1,000
3.6.3 Biddable Purchases
3.6.4 Change Orders
3.6.5 Blanket Order Processing
3.6.6 Assisted Buying Procurement System
3.6.7 Procurement Cards
3.6.8 Personal and Professional Contracts
3.6.9 Vendor Relations
3.6.10 Commodity Codes
3.6.11 Receipt matching
3.6.12 Delivery Instructions
3.7 Accounts Payable
3.7.1 Voucher Processing

3.7.2 Manual Check Processing

3.7.3 Payment Processing
3.7.4 Travel Reimbursements
4. Budget Demonstration Script (4 hours)
4.1 Salary Budget Development
4.1.1 Establish a Base Salary Budget
4.1.2 Adjustments to Base Salary Budget
4.1.3 Staff Benefits Budget
4.1.4 Salary Budget Reports
4.2 Budget Development
4.3 What-if Scenarios
4.4 Budget Review and Approval
4.5 Budget Implementation
4.6 Budget Revisions
4.7 Budget Controls
5. Human Resources/Payroll Demonstration Script
5.1 Human Resource Processes
5.1.1 Position Tracking and Control
5.1.2 Applicant Processing
5.1.3 Recruitment and Hiring
5.1.4 Employment and Employee Data Maintenance
5.1.5 Benefits Administration
5.1.6 Compensation Management
5.1.7 Non-Resident Alien Processing
5.1.8 Deductions
5.2 Payroll Processes
5.2.1 Time and Attendance Reporting

5.2.2 Payroll Cycles

5.2.3 Payroll Processing and Check/Advice Production
5.2.4 Deduction Remittance
5.3 Miscellaneous Items
5.3.1 Encumbrances
5.3.2 Termination of Employment
5.3.3 Reporting
5.3.4 Federal Tax Reporting
5.3.5 System Integration
5.4 Employee Development and Training
5.4.1 Performance Management
5.4.2 Training
5.4.3 Career Development
6. Reporting and Technical Demonstration Scripts
6.1 Reporting and Technical Issues Script
6.1.1 Imaging
6.1.2 Ad Hoc Reporting
6.1.3 Import / Export Data
6.1.4 Web-based Transactions
6.1.5 Help Features
6.1.6 System Tools
6.1.7 Warehousing and Decision Support
7. Glossary of Terms
8. Attachments
8.1 Attachment A Primary Object Code Reference
8.2 Attachment B T.H.E.C. Expenditure Object Reference
8.3 Attachment C Detail Object Code Reference

8.4 Attachment D Budget Category Code Reference

8.5 Attachment E Ledger Activity Code Reference
8.6 Attachment F TCRS Defined Benefit Formula
8.7 Attachment G Employee Death Benefits Formula

1. Introduction
1.1 Overview
The University of Tennessee is in the process of evaluating integrated software solutions that provide finance,
human resources, and budgeting capabilities. As part of the process, the University has translated key functional
requirements into demonstration scripts that will be used as part of the basis for evaluating a vendors ability to
meet the Universitys needs.
Your company is invited to provide a scripted demonstration in Knoxville of the capabilities of your package to
University representatives from all campuses and the Request for Proposal (RFP) evaluation team. Each
demonstration is expected to last four days.
Day One:
Security/Workflow
General Ledger
Grant Management
Fixed Assets
Accounts Receivable
Cash Management
Evening One:
Fund Accounting*
Day Two:
Procurement
Accounts Payable
Budget (Operating and Salary)
Position Tracking
Day Three:
Human Resources
Applicant Processing
Recruitment/Hiring
Employment/Data Maintenance
Compensation
Benefits Management
Payroll
Training and Career Development
Day Four:

Continuation of prior day issues

Imaging
Web Processing
System Architecture
Warehousing
* Fund Accounting will be a general discussion session regarding GASB/FASB compliance. There is not a script
for this session.
Any questions or clarifications concerning the scripted demonstrations should be directed to both:
Neal Wormsley
Associate Treasurer
301 Andy Holt Tower
Knoxville, TN 37996
Cellular Phone: (423) 599-4298
Office Phone: (423) 974-2302
e-mail: nwormsley@utk.edu
-andMike McNeil
University-Wide Computing Services
102 Andy Holt Tower
Knoxville, TN 37996
Office Phone: (423) 974-3051
e-mail: mmcneil@utk.edu
1.2 Demonstration Guidelines
To facilitate scoring, it is important that the demonstrations follow the scripts included in this document. Based
on the limited time for the demonstrations and the number of script items, vendors must manage their time
carefully. The Universitys expectation is that the vendors will complete the demonstration scripts, in their
entirety in accordance with the outline on the previous page. During the presentation, the vendor should
stipulate any steps that their software cannot perform, and then resume with the next step.
The vendor should make reasonable judgments about the level of detail to include, and by what process to
proceed, while covering each script. The University expects that each script item will be individually addressed,
with the vendor identifying the item. The vendor should also make every effort to demonstrate items in the same
order in which they appear in this script. Any changes to the order of the script should be indicated. During the
presentation, a designated person from the Universitys staff will work with the vendor to keep the discussion
moving and cover the items in the allotted time. If the demonstration is not completed in a specific functional
area (i.e. General Ledger, Benefits, etc.) during the allotted time, the vendor may be asked to move on to the
next topic area.
The University expects each vendor to provide a demonstration of an integrated solution. This means if certain
transactions affect information in another module or trigger another transaction elsewhere in the system, you
should show the impact or effect these particular transactions have on any other component of your system.
1.2.1 Demonstration Site
The demonstrations will be held in Knoxville at a location identified by the University. The University will
provide a telephone connection. If other resources are needed, they should be requested by the vendor in
advance.
1.2.2 Demonstration Software

The software used in the demonstration must be the same as that included in the response to the Universitys
RFP. If certain requirements described in these scripts are provided by third-party software as part of your bid
(e.g. imaging, security), you are expected to demonstrate the third party product and so indicate during the
demonstration. Only products included in your bid should be used in the demonstration. There should be no
modifications made to the software or the databases for the demonstration. Any user defined fields, user exit
code, or other changes to the base product should be identified during the demonstration and provided in writing
at the beginning of the demonstration.
1.3 Demonstration Scoring
The RFP evaluation team will score the vendors demonstrations. The criteria used for the scoring will include,
but not be limited to, the following:

ease of use of the software

number of screens/key strokes involved in each script

performance of the system

flow and simplicity of performing the function

ability of the system to handle the Universitys current business processes

how well the system meets the Universitys perceived future needs

flexibility, tailorability, and extensibility of the system

ease of backup and modification during processing

adherence to the script

1.4 Demonstration Organizational Structure

In order to provide a common foundation for the demonstration script evaluation process, the University is
requesting vendors use the following organizational structure to better demonstrate the extent to which their
software is integrated between the finance, human resources, and budget modules. Each software vendor will be
expected to initialize their software packages to reflect the organizational structure using these data and
nomenclature.
1.4.1 Organization Chart
For demonstration purposes, we have developed a sample organizational chart. This structure is used in the
examples in the scripts, and all references to the offices or people in the chart are italicized. The vendor can set
up this organizational structure in advance to be used in the demonstration. When presenting the demonstration,
each software vendor should reflect the following organizational structure:

* HR/AA Human Resources and Affirmative Action

** The structure depicted here does not imply either a current or future organizational plan for The University of
Tennessee.

2. Infrastructure Demonstration Scripts

The following section contains the demonstration scripts that address infrastructure issues; specifically, security
and workflow.
2.1 Cross Module Topics
2.1.1 Security
The University requires a system that provides authorized access to users while minimizing the risk of
inappropriate inquiry or entry of data. It is anticipated that security to support this requirement will be provided
as part of the vendor software in a manner that integrates across all modules in the system. It is further
anticipated that the security solution will not require multiple logons and passwords except where desired for an
additional layer of security.
In addition to security access to the system and transactions, it is the desire of the University that the security
system be able to restrict access to data based on field values. For example, a person should be able to view his
or her own data, but not data for anyone else. Field value security should also apply to other data fields such as
account number, department, college, campus and others. For example, a department head should be able to
process data for all accounts assigned to his/her department while being restricted for access to the data of other
departments.
The management of security is of great concern to the University. It is our desire that the security system offers
central controls while offering the opportunity to distribute maintenance functions where appropriate. For
example, the University is interested in distributing security management for a campus to representatives on that
campus while restricting their authority to grant access to that campus data.
As a buyer, Dr. Susan Smith in the Math Department initiates purchases but does not make vendor payment
decisions. Her profile should be set up with a buyer group profile, but with no access to payment processing
capabilities. In addition, Dr. Smith is only a buyer for specific products in the Math Department. She should
only have access to information related to her department and the products she is responsible for buying.
2.1.1.1 Demonstrate the ability to access all system modules through a single sign-on.
2.1.1.2 Demonstrate the ability to establish a security group profile for buyers.
2.1.1.3 Demonstrate the ability to restrict access based on user-defined security; i.e., by the position of the user,
by organization structure, by cost center/responsibility center.
2.1.1.4 Demonstrate the ability to restrict access at the field, screen and menu level, and to restrict access based
on a date range.
2.1.1.5 Show how security can be set-up to provide a user with read-only access to a specific field on the screen.
2.1.1.6 Show how security can limit or deny a user the ability to view restricted data.
2.1.1.7 Show how security can limit or deny update authority to a record.
2.1.1.8 Demonstrate how field level security works across all systems.
The Dr. Susan Smith is going on vacation for a week.
2.1.1.9 Show how a user can delegate security privileges to another employee for a specified time period.

2.1.1.10 Show a list of users added to security in the last two months along with who added them.
2.1.1.11 Show a list of everyone who has authority to add accounts payable information.
2.1.1.12 Demonstrate how the system maintains an audit trail for transactions initiated by the employee with
delegated authority.
The University needs to create and maintain personal identification numbers.
2.1.1.13 Demonstrate how to create and assign unique Personal Information Numbers (PIN) to employees that
can be used with WEB or other generic remote access to transactions and show how an employee can change
their PIN.
2.1.1.14 Demonstrate how a security administrator can product a list of PINs.
2.1.2 Workflow
The University requires the ability to electronically route and approve documents and transactions.
The Central IT Department is asked to create the workflow for an electronic form. The form is to be initiated by
Dr. Susan Smith, approved by her department head and dean, forwarded to the Campus East HR/AA office for
informational purposes ("FYI copy"), and approved by Academic Vice Chancellor East. All approval routings
are based on originating department, with notification of the completion of this process back to the originator
following approval.
2.1.2.1 Demonstrate how to set up the workflow to electronically route a form to appropriate (professor,
department head, dean, "FYI copy" office, vice chancellor).
2.1.2.2 Demonstrate how the department head can complete or change information on the form before
delivering it for approval to the next level. Include the conditional routing based upon originating department
and/or document attribute such as dollar amount.
2.1.2.3 Show how the originator can add an additional approval office or "FYI" office when they initiate the
form.
2.1.2.4 Show how a reviewer is notified that a form is available to be reviewed.
The Academic Vice Chancellor East receives the form and determines there is not enough information to
approve the transaction.
2.1.2.5 Show how an approver can reject a transaction and send the form back to the originator requesting
additional information items.
2.1.2.6 Show various options for authenticating the approver when the document is being approved.
2.1.2.7 Demonstrate how the originator can update the form with the requested information and resubmit.
2.1.2.8 Show how the originator can track the status and progress of the transaction and receive notification
upon completion of the transaction.
2.1.2.9 Show how any person in the workflow can designate a proxy for their part of the workflow for a
specified period of time.
2.1.2.10 Show how a form can be automatically approved or denied after no action is taken for a given time
limit.

3. Finance Demonstration Script

The following is general information relating to the Business and Finance areas of the University. These general
assumptions should be used when placing the individual demonstration scripts into a context, unless otherwise
specifically noted in the script.
The Universitys fiscal year begins on July 1 and ends on June 30.
The University of Tennessee is a public university and, as such, is considered a State agency. All revenue and
expenditure activity (transactions) is recorded in the financial accounting system.
The major sources of University funds are:

state appropriation

student tuition

grants and contracts of all types (research, training, service, etc.)

federal appropriation

local appropriation

gifts

endowment income

sales and services of education activities

sales and services of auxiliary enterprises

sales and services of hospitals

All payments (payroll, supplies, equipment, etc.) regardless of fund source, are paid from a University bank
account. All revenue is deposited to a local depository and then swept daily into a cash concentration account.
3.1 General Ledger
The University operates under fund accounting principles for public higher education. Each "fund" in the system
must be self-balancing, meaning that the system must produce a consolidated Balance Sheet and statement of
operations. The system should also be able to produce a Balance Sheet and statement of operations for each
campus/unit.
The University must produce accrual basis financial statements in support of GASB regulations for June 30, its
fiscal year-end, by August 15 (1 1/2 months later). Various adjusting and accrual entries are made to the system
during the period July 1 to August 15 in order to transform the balances into statements acceptable to the audit
staff. At the same time, regular processing for the new fiscal year (beginning July 1) must commence in early
July.
In addition, the University must be capable of supporting other fiscal calendars, such as the federal fiscal year of
October 1 through September 30.

The General Ledger application must record the results of accounting transactions and accurately report the
fiscal status of the accounts, departments, colleges/divisions, campuses/entities, and the University as a whole.
The General Ledger is composed of expenditure, revenue and balance sheet account records and accurately
records all fiscal activity for each account with summarization at multiple and alternate organization levels of
the Chart of Accounts. These may be program codes, subprogram codes, names of faculty, grant numbers,
funding sources, etc. General Ledger information must be fully integrated within the Universitys budget
process. This allows the system to accept final adopted budget amounts to be used for monitoring and reviewing
financial activity.
3.1.1 General Features
The University would prefer an account number structure that is short, meaningful, and has some sight
recognition. There should be at least 100 attributes associated with each account number. The account number
must be large enough to accommodate up to 100,000 fund balances per campus/unit.
The complexity of the accounting system and the Chart of Accounts should be hidden from end users. The
interface and screens presented to users should be simple and intuitive. On-line help screens should be provided.
Account creation, consolidation, and close out should all occur quickly and easily for all types of accounts
(including grants and contracts). For example, initiation of account creation and close out for certain accounts
should be automated at the department level.
The Chart of Accounts should support the ability to assign unique user-created and defined attributes to
accounts, orders, and revenue and expense transactions in order to support departmental accounting and
management information needs.
3.1.2 Chart of Accounts
Establish and modify accounts and sub-accounts.
3.1.2.1 Demonstrate setting up accounts and their attributes.
The College of Arts and Sciences establishes a new department entitled Computer Science. There are two
professors in the department, Dr Bob Byte and Dr. Mary Bit. They need to be able to track their expenditures
separately. In addition to the regular instructional duties, this department also runs a lab.

Create the new department.

Establish the general departmental account with the following attributes:

Account Name:
Account Type:
Fund:
Function:
Campus/Unit
College:
Department

Computer Science
Expense
Educational and General; Current Unrestricted
Research
Campus East
Arts and Sciences
Computer Science

Show all the available account attributes.

Establish sub-accounts under the departmental account for each professor.

Establish the lab account with the following attributes:

Account Name:
Account Type:

Computer Science
Expense

Fund:
Function:
Campus/Unit
College:
Department

Educational and General; Current Unrestricted

Research
Campus East
Arts and Sciences
Computer Science

Process two transactions for both the general account and the lab account.

Process two transactions for each of the sub-accounts.

Demonstrate how the sub-accounts roll up to the account level.

Run a query to report expenditures by function; save the query for later use.

Run a query to list all of the transactions for each professor.

Access each sub-account balance and show the impact of the transactions.

3.1.2.2 Demonstrate the effect on transactions when account attributes are changed.
The departmental expense account was set up erroneously under the research expenditure function and must be
changed to reflect that it is an instructional account.

Change the function of the general account to instruction.

Run the query to report expenditures by function again; demonstrate where the charges from the
general account are reported.

After the new department has been in place for some time, the campus decides to re-organize and moves the
department from the College of Arts and Sciences to the College of Engineering, effective with the new fiscal
year.

Move the department and the departmental account to the College of Engineering; show how
expenditures roll up to the College of Arts and Sciences in the old fiscal year and to the College of
Engineering in the new fiscal year.

Move the transactions to the College of Engineering/instruction or demonstrate that they are moved as
the account is moved.

Show how the system tracks changes to the Chart of Accounts over time (e.g., reorganizations,
reclassifications, restrictions, etc.) and restates the financial reports.

3.1.2.3 Establish accounts for a multidisciplinary research project.

The Electrical Engineering Department (from the College of Engineering) and the Math Department (from the
College of Arts and Sciences) are participating in a joint research project sponsored by a federal agency.
Dr. Susan Smith will request the accounts and the Controllers Office will approve it. The agency does not allow
travel expenditures on this award. $50,000 is allocated to Susan Smith in the Math Department, and $20,000 is
allocated to Doug Dow in the Electrical Engineering Department. The University has agreed to cost share 50%
of Facilities and Administrative costs (F&A).

Establish the accounts with the following attributes:

Account Name:
Account Type:
Fund:
Function:
Campus/unit:
Sponsoring Agency:
F&A Calculation Method:
F&A Rate:
F&A Cost Sharing Rate:
Invoicing Type:
Invoicing Frequency:
CODA Code:
PI #1: Doug Dow

DOE Research Project #1

Expense
Educational and General; Current Restricted
Research
Campus East
US Department of Energy
Modified Total Direct Costs
43 %
50%
Cost-reimbursable
Monthly
81.049

College:

Engineering

Department:
PI #2: Susan Smith
College:
Department:

Electrical Engineering
Arts and Sciences
Math

Indicate whether there is a process for uploading account attributes and budget information from an
independent proposal.

Show the structure of account relationships, the fund balance and various subsidiaries that are required
or optional.

Establish spending control limits for the overall award amount and to prohibit travel.

The Controllers Office approves/activates the account.

Notify the principal investigators and department heads that the account has been activated.

After the accounts are set up, it is realized that the accounts should have been set up as off-campus accounts but
they were set up as on-campus accounts. This change results in an F&A rate change.

The Controllers Office modifies the accounts to be off-campus. Change the F&A rate from the oncampus rate of 43% to the off-campus rate of 23%.

The Controllers Office approves the modification.

Process two transactions for each account, and show the F&A and F&A cost sharing.

Create a report to show the accounts as a single project to the federal agency.

Close the accounts to prevent posting by anyone other than the Controller's Office.

Demonstrate what happens when a background (batch) process attempts to post to that closed account.

Show how the closing process identifies and resolves references or dependencies to the account in
other modules.

The following year, the two departments collaborate on a similar project from the same agency. At this time, the
federal government mandates the tracking of federal projects by federal financial account identification number.

Establish new accounts for each department by copying attributes from the original accounts.

Create a new account attribute entitled 'Federal Account Identification'. The value for this attribute on
these accounts should be 89-0224-0-1-271.

3.1.2.4 Establish accounts for a gift. Explain what distinguishes it from the research restricted account, above.

Establish a gift main account in the Computer Science Department, called Computer Science Support
Fund, with the following attributes:
Account Name:
Account Type:
Fund:
Function:
Campus/Unit
College:
Department

Computer Science Support Fund

Restricted Expense
Educational and General; Current Unrestricted
Academic Support
Campus East
Engineering
Computer Science

Set up two sub-accounts under the gift account.

Process two transactions for each sub-account.

Access each sub-account balance and show the impact of the transactions.

3.1.3 Create a New Object Code

3.1.3.1 Demonstrate adding a new object code into a structure like the one used by The University of Tennessee.

Demonstrate adding a new primary object code (Attachment A Primary Object Code Reference) with
a cross-reference to the comparable T.H.E.C. (Tennessee Higher Education Commission) object code
(Attachment B T.H.E.C. Expenditure Object Reference) and the budget category code (Attachment D
Budget Category Code Reference).

Demonstrate adding a new detail object code as a breakout of the above code (Attachment C Detail
Object Code Reference).

Demonstrate how someone would enter a transaction with an additional user assigned sub-code.

3.1.4 General Ledger Loan Funds

Loan accounts require detailed account and student information to comply with Federal requirements. Currently,
transfer vouchers to record advances/payments to students are entered through several legacy student account
systems soon to be replaced by Banner. Loan repayments (principal and interest) are recorded on daily summary
cash receipts (no detail student information) for entry into the General Ledger. Principal and interest
cancellations (approximately 30 types to date) are recorded on journal/transfer vouchers for entry into the
General Ledger. Summaries of types of loan activities should be obtainable through the General Ledger.

Currently, the General Ledger also maintains certain asset accounts that identify the assets of various loans as
"matching". These matching accounts identify the portion of a loan fund that the university has used to fund its
share of a federally sponsored loan program. The system should allow for the creation of such "special" or
"nontraditional" assets, liabilities, etc. which can arise in the loan funds.
3.1.4.1 Demonstrate the creation of such a new type of account.
3.1.4.2 Demonstrate the ability to produce a breakdown of loans receivable through the General Ledger for each
loan fund using sub accounts or other breakout coding as follows:

funds advanced to students

loan principal collected

loan principal assigned to and accepted by the U.S

loan principal cancelled (approximately 30 types to date)

3.1.4.3 Demonstrate the ability to produce a breakdown of loan balance through the General Ledger for each
loan fund using sub accounts or other breakout coding as follows:

income:

o interest income
o other income

expenditures

o administrative cost allowance

o collection costs

cancellations:

o principal (approximately 30 types)

o interest (approximately 30 types)

other costs

transfers in/out

3.1.4.4 Demonstrate the ability to add a new asset type, "Matching Account", and record a 10% match entry for
a federal loan program that is provided by a private loan fund. Display the ability to capture statistical
information such as the percent of match and perform calculations with this statistical information.
3.1.4.5 Demonstrate the ability of the system to display a loan funds current and prior month end cash balances.
3.1.4.6 Demonstrate the ability to provide reporting by individual loan fund or by various summary levels.

(See also the section on Journal Entry Processing, Transfer Vouchers for a specialized entry script for loan
cancellations.)
3.1.5 Journal Entry Processing
Transfer Vouchers
Departments may originate general ledger adjustments, currently referred to as Transfer Vouchers (TVs)
between all University accounts, including Grants and Contracts. TVs require varying levels of approval,
depending on the nature of the adjustment being requested. Entries meeting University-defined business rules
may post once all involved departments and other necessary parties have properly approved the TV.
3.1.5.1 Demonstrate the preparation of an entry to correct a disbursement that was charged to the unrestricted
Computer Science general account but should have been posted to the restricted Computer Science Support
Fund account.

Demonstrate how the department enters the account numbers, object codes, amounts (debit/credit) and
descriptions.

Show how the system requires each of these elements to record an entry.

Demonstrate defaults and prompts that can be used to help the preparers.

Show how the process verifies that an account exists and is open for posting. Demonstrate the system
displaying the account name for operator verification. Show help that is available for looking up
accounts.

Demonstrate what happens when an invalid account number is entered.

Show the process that checks for availability of funds.

Show how a recorded transaction (needing to be corrected) may be selected from the General Ledger
on-line so that account, code, amount and description information are accurately obtained from the
ledger.

Show how multiple lines of entry can be handled on the same TV.

Show the effect of this change on both accounts as well as on the fund balance(s) and on cash.

3.1.5.2 Demonstrate edits and warnings for University-defined business rules and how easily edits and warnings
can be modified as rules change.
3.1.5.3 Prepare another transfer where the Math Department is recovering from the Electrical Engineering
Department costs associated with a shared copier. Demonstrate the approval process.

Show the transfer process as seen from the Math Department (the preparing department).

Show the transfer process as seen from the Electrical Engineering Department (the approving
department).

Demonstrate the ability to require the Academic Vice Chancellor East to approve the transfer where
some extraordinary circumstance occurs such as the transfer value being over $1000 or the object code
was one that requires additional approval.

Show how the disapproval is handled.

Show how an approval results in an entry posted to the ledger accounts.

3.1.5.4 Demonstrate a specialized entry screen to process entries that are recurring, such as student loan
cancellations in which cancellation types may vary among 30 Federal cancellations in use to date. (See the
section on General Ledger Loan Funds for a more detailed description on the loan function.)

Display access/menu screens to select such a specialized transfer (or journal) entry.

Demonstrate the selection of the type of cancellation and how the system would translate this selection
into the proper accounts, sub accounts and system coding to be used in this transaction.

Demonstrate prompts to enter standard elements, such as loan principal and interest.

Demonstrate how the system would require certain elements, such as a social security number, for each
entry.

Demonstrate the ability to limit access to sensitive information, such as social security numbers.

Demonstrate how this entry information could also be made available for use in a separate subsidiary
system maintained by the loan department.

Journal Vouchers
The Controllers Office sometimes needs to make adjusting entries to accounts; for example, corrections to
object codes, closing entries, etc. These transactions are called Journal Vouchers (JVs). These transactions are
initiated by and approved within the Controllers Office, without going through the normal approval routings for
these accounts.
3.1.5.5 Demonstrate how these adjusting entries would be entered, and how the approval process would be
bypassed when transferring $10,000 from a Campus East account to a Campus West account to fund a new
equipment purchase.
3.1.5.6 Show how the departments affected would be notified of the transaction.
3.1.5.7 The biweekly pay cycle does not always coincide with the month-end. Show how the partial payroll can
be accrued in one month and then reversed during the following month.
3.1.6 Fiscal Year-End and Period-End Processing
3.1.6.1 Demonstrate the opening and closing of general ledger transaction posting periods.

Demonstrate how to open a posting period for all transaction types.

Demonstrate how to open a posting period for a restricted set of transaction types.

Demonstrate how to close a posting period for all transaction types.

Demonstrate how to close a posting period for a restricted set of transaction types.

Demonstrate what happens when an attempt is made to use a closed period.

Demonstrate how to close a posting period for a given fund group.

Demonstrate how to prevent departmental users from entering additional transactions to a given posting
period while allowing the Controllers Office to continue to enter adjusting entries to the same posting
period.

3.1.6.2 Demonstrate the ability to post into two fiscal years at the same time.

Enter and post a transaction to the next fiscal year.

Enter and post a transaction to the current year.

Demonstrate reporting or querying the correct balances on both fiscal periods.

3.1.7 Automatically Generated Transactions

3.1.7.1 Demonstrate a process that can be used to detect transactions having specified criteria and automatically
generate supplementary transactions.

Define the criteria used to generate a budget increase equal to the charge with an offsetting budget
decrease to an alternate account within the same budget entity (for specifics, see the section on Budget
Revisions).

Create the process and enter criteria to detect a social security charge to an unrestricted general fund
account and create a budget increase equal to the charge.

Activate the process, if not already active.

Enter a transaction meeting the criteria and post.

Display the posted activity online showing both the original and two supplementary transactions.

Stipulate any limitations or loopholes of the process.

3.1.7.2 Demonstrate how the system automatically relieves antecedent transactions.

Demonstrate how an encumbrance relieves a pre-encumbrance or projection/speculation transaction.

Demonstrate how an expense relieves an encumbrance.

Disclose any transactions where the system does not provide automatic relief.

3.1.7.3 Demonstrate the capability to post a summarized entry by account and object rather than detail by
recipient for a specified kind of check (student aid/fee refunds).

Display a report of checks issued to several recipients charged to the same account and object code for
the same day.

Demonstrate the process that summarizes the activity into one transaction per account, object and day.

Post the summarized activity.

Display the ledger view of that transaction.

3.1.8 University-wide Financial Inquiries and Analysis

3.1.8.1 Demonstrate the ability to access a general ledger expense account balance from a high-level overview
to a detail perspective. Demonstrate the ability to drill down to detail support (for examples of object codes and
higher-level summaries, see Attachment A Primary Object Code Reference, Attachment B T.H.E.C.
Expenditure Object Reference, Attachment C Detail Object Code Reference, and Attachment D Budget
Category Code Reference).

Access account balances summarized by salaries, operating, and equipment showing fiscal year
amounts for budget, pre-encumbrance, encumbrance, expense and free balance.

Access account balances representing primary object code classifications showing fiscal year amounts
for budget, pre-encumbrance, encumbrance, expense and free balance.

Access account balances representing detail object code classifications showing fiscal year amounts for
budget, pre-encumbrance, encumbrance, expense and free balance.

Access a restricted account balance representing detail object code classifications showing cumulative
(sum of all years) amounts for budget, pre-encumbrance, encumbrance, expense and free balance.

For a given detail object code, display balances representing user code breakout of detail object codes
showing fiscal year amounts for budget, pre-encumbrance, encumbrance, expense and free balance.

For a given detail object code, drill down to the transaction activity which comprises the fiscal year
balance.

For a given transaction drill over to the native form presentation of the originating subsystem.

3.1.8.2 Browse a list of ledger account and posting status for a given university department with access to
attribute detail and history. Use the organizational chart provided in section 1.4.1 for the following example:

Browse a list of campuses and select a campus.

Browse a list of colleges within the selected campus and select a college.

Browse a list of departments within the selected college and select a department.

Browse a list of accounts within the selected department.

Display the account names and posting validity statuses on the browse list.

Demonstrate a capability of scrolling (left to right) to view other columns (data elements) associated
with the accounts currently being viewed.

Demonstrate that certain columns (data elements) designated as sensitive (such as social security
number) can be restricted and made inaccessible to the browsing function.

Reorder the sequence of columns for the rows of accounts being viewed.

Select a grant or contract account from the list to access a form presentation of descriptive information
about the account including grant or contract terms and ledger posting and reporting attributes.
(Descriptive text for attribute codes should be included).

Drill down to the history of account attribute changes.

Demonstrate how a list of transaction approvers can be viewed for the selected account.

Demonstrate how each step could be performed independently of the preceding step (direct
navigation).

Show how the Agricultural Experiment Station can choose either the Universitys fiscal year-to-date or
the Federal fiscal year-to-date balances from one query to the next.

3.1.8.3 Demonstrate the ability to access a general ledger balance sheet account balance from a high level
overview to a detail perspective.

Access account balances summarized by beginning balance, additions, deductions, and ending balance
for both the current and preceding fiscal year.

Access account balances summarized by ledger activity code for both the current fiscal year and the
cumulative sum of all fiscal years (see Attachment E Ledger Activity Code Reference for examples
of ledger activity codes).

3.1.9 Departmental Financial Inquiries and Analysis

3.1.9.1 Demonstrate the ability of departmental users to designate "reporting groups" which are a collection of
accounts and/or sub-accounts. This demonstration should assume that the demonstration above regarding "subaccounts" has already occurred. (If you cannot demonstrate sub-accounts, stipulate so and demonstrate at the
account level.)

Establish the report group id Group1 for the group named Report Group 1 to be identified with the
Computer Science Department.

Add sub-account 1 of the Computer Science Support Fund account and sub-account 1 of the Computer
Science account to Group1.

Display a report of detail object code balances for Group1 reporting group.

Display a report of activity for Group1 reporting group.

Establish the report group id Group2 for the group named Report Group 2 to be identified with the
Computer Science Department.

Add sub-account 1 and sub-account 2 of the Computer Science Support Fund account to Group2.

Display a report of detail object code balances for Group2 reporting group.

Display a report of activity for Group2 reporting group.

3.1.9.2 Demonstrate the ability to anticipate future transactions by allowing the entry of unofficial transactions
(projections/speculations) from which a projected available balance can be calculated for an account or subaccount.

Demonstrate how to enter a projection against a sub-account for a single occurrence and then post.
(Note: if you cannot demonstrate sub-accounts, stipulate so and demonstrate at the account level)

Access the sub-account balances at the detail object code level and display the column to which this
unofficial obligation posted.

Demonstrate how to enter a date driven multiple month projection, then post.

Access the account balances at the detail object code and display the column to which this unofficial
obligation posted.

3.1.9.3 Demonstrate the ability to annotate objects in the financial systems.

Demonstrate how to annotate an expense transaction.

Demonstrate how to annotate a primary expense object code balance.

Demonstrate the ability to annotate a "projection/speculation" transaction.

3.1.10 Uploading Transactions from Auxiliary Sources

3.1.10.1 Demonstrate how transactions can be uploaded from another system for editing and posting.

Connect to the batch upload facility.

Indicate the format of the file to be uploaded (text, Excel, etc.).

Initiate the file transfer.

Select the posting period in which to post the batch.

Show what controls (record counts, sums, etc.) are used to insure transmission accuracy.

View the contents of the uploaded batch.

Initiate the validation edit of the batch if not automatic.

View the status of the edited batch (number of errors).

Show how to purge a batch resulting from a faulty transmission.

Show how to correct transactions with errors.

Show where transactions are labeled with an originating subsystem id.

Show where the id of the upload operator is stored.

Show how to schedule the batch for deferred posting.

Show how to submit the batch for electronic authorization.

Stipulate any limitations imposed by the upload facility (record limits, transaction types, additional hardware,
software, or port requirements, special operator privileges, etc.)
3.2 Grant Management
The grants and contracts system should be integrated with other financial management information to provide
automatic control and updating of revenues, expenses, encumbrances, assets, and effort funded by sponsored
projects.
External agencies providing funding for sponsored projects must be invoiced and/or provided financial reports
in accordance with government, sponsor, or University rules. Facilities and Administrative (F&A) costs are an
integral cost component of sponsored projects. Many sponsors require the University to cost share part of the
project expenditures. The funds are then collected through an accounts receivable system and the project is
closed. Periodic faculty effort certification provides primary support for salary charges or cost sharing reported
on a sponsored project.
The financial requirements for reporting, cost sharing, and account closing under each sponsored project may be
standard or unique in frequency, methodology, and format; therefore, flexibility is important. Due to the volume
of projects, electronic methods for initiating, monitoring, and prompting accounting actions is highly desirable.
3.2.1 Pre-award system
3.2.1.1 Show that the grant and contract accounting system can be operated independently of any pre-award
system that may be bundled with it.
3.2.2 Cost-type invoicing
3.2.2.1 Demonstrate the ability to automatically produce an invoice from expenditures made during the month.
3.2.2.2 Demonstrate how to create a monthly cost reimbursement invoice within a variety of agency-standard
and user-defined invoicing formats/templates.
3.2.2.3 Demonstrate the systems ability to handle multiple invoicing time periods (e.g. monthly, quarterly, userdefined).
3.2.2.4 Show method for assigning, changing, and controlling invoice numbers used.
3.2.3 Fixed price / payment schedule invoicing
3.2.3.1 Demonstrate the method to automatically produce invoices for a project which requires the following
invoicing terms:

invoice 1 on September 30, 1999 for $5,000

invoice 2 on December 12, 1999 for $7,500

invoice 3 on June 30, 2000 for $12,000

3.2.4 Performance invoicing

3.2.4.1 Demonstrate the method to produce performance invoices based on parameters provided. For example, a
clinical trials contract for a pharmaceutical company allows a fee of $5,000 per patient enrolled, up to a total of
twenty patients. The first month, the University wants to produce an invoice for six patients.
3.2.5 Invoicing prompting system
3.2.5.1 Demonstrate an automatic monthly and on-demand listing of invoices due within the next thirty, sixty,
ninety days, based on dates or time intervals specified in the award document.
3.2.5.2 Demonstrate an automatic monthly and on-demand listing of accounts that need to be invoiced based on
activity.
3.2.6 Electronic capabilities
3.2.6.1 Demonstrate the ability to produce all grant and contract documents (invoices, reports, backup
documents) in "draft" status. For example, invoices can be automatically generated, grouped by any account
attribute, and routed for various approvals and modifications before posting. Also, notification copies can be
automatically sent internally to other users.
3.2.6.2 Demonstrate that the grant and contract system is fully integrated with the General Ledger and Chart of
Accounts. If the system is not fully integrated, how often does the system receive updates?
3.2.6.3 Demonstrate the method for electronic approval of invoices internally before being sent to a sponsor.
3.2.6.4 Discuss the capabilities for electronic commerce with sponsors.
3.2.7 Accounts receivable
3.2.7.1 Demonstrate the production of an aging report sorted by any account attribute.
3.2.7.2 Demonstrate the production of an aging report with user-specified age categories.
3.2.7.3 Demonstrate automatic production of collection letters at specified age limits.
3.2.7.4 Describe the ability to match receipts with related receivables.
3.2.7.5 Demonstrate the ability to produce a statement of account which shows invoicing and payment activity.
3.2.7.6 Demonstrate any other collection assistance, such as areas for collection progress notes.
3.2.8 Backup documentation
3.2.8.1 Demonstrate how to produce sponsor-required backup documentation, including:

salary expense by person

fringe benefit expense by person and by benefit category (e.g. retirement)

fee waivers by student

travel expenditures by person, by trip, and/or by type (e.g. lodging, food)

3.2.9 F&A Costs and F&A Cost-Sharing

3.2.9.1 Dr. Susan Smith wants to know the cumulative F&A and F&A cost sharing on her project since its
inception two years ago through today (which is mid-month). Demonstrate the F&A and F&A cost sharing
calculation frequency, real-time query, and posting to the General Ledger and to the individual sponsored
project.
3.2.9.2 Demonstrate how F&A and F&A cost sharing is included with the related direct cost as an encumbrance
or pre-encumbrance.
3.2.10 Direct cost sharing
3.2.10.1 Demonstrate alternative, automated methods available for tracking and accumulating cost sharing
information on an award requiring that 15% of Professor Susan Smiths salary (estimated at $5,000) is cost
shared. Two departments, Math and Computer Science, want to contribute $1,000 and $4,000, respectively.
Based on actual expenditures at the end of the project, 15% of her salary equals $6,200. Are any automated
adjustment options available?
3.2.10.2 The Computer Science Departments bookkeeper wants to check how much cost sharing has been
charged to the departmental account three months into the project. For direct cost sharing, demonstrate the
frequency, real-time query, and posting to the General Ledger and to individual sponsored projects.
3.2.11 Effort certification
3.2.11.1 Create an automatic effort certification form for Professor Susan Smith and Professor Doug Dow with
some fields automatically populated with payroll information.
3.2.11.2 The University has committed to cost share 15% of Professor Smiths salary on a project. Demonstrate
planned effort cost sharing and any links between the effort certification system and the grant and contract
system.
3.2.11.3 Professor Dow planned to work 50% on instruction and 50% on his NIH project. This is how his
payroll was charged. He actually worked 40% on instruction, 50% on his NIH project, and 10% on a colleagues
NSF project. Demonstrate how the effort form and variance report are produced, based on this information.
3.2.12 Closeout
3.2.12.1 Demonstrate any electronic methods available that would prompt Principal Investigators, bookkeepers,
and Grant & Contract accountants to initiate and/or complete various closeout procedures and required reports/
forms.
3.3 Fixed Assets
3.3.1 Acquisition
3.3.1.1 Demonstrate how an asset is added, removed (archived), and deleted from the system. Demonstrate how
there can be differences in the data entry screens used by the Controllers Office and those used by the
departments.

Demonstrate the addition of an asset that has been constructed using various vendors over multiple
accounting periods.

Demonstrate the addition of components to an asset.

Demonstrate the addition of an asset that is paid for in progress payments over multiple accounting
periods.

Demonstrate the addition of an asset acquired by capital lease.

3.3.1.2 Demonstrate how an asset is transferred to another department.

3.3.1.3 Demonstrate the free text area ("notes") assigned to each asset.
3.3.1.4 Keeping track of multiple funding sources for equipment purchases is very important to the University. A
single piece of equipment is frequently funded from more than one type of account. Because of State and
Federal reporting requirements, it is sometimes necessary for the University to break down the amounts spent on
a single piece of equipment by funding source. Demonstrate that the system can record multiple sources of
funding and amounts for a single fixed asset.
3.3.1.5 Demonstrate how all-relevant cost information is transferred to the fixed asset system from accounts
payable when an invoice containing asset information is paid.
3.3.1.6 Demonstrate how depreciation is calculated and recorded.
3.3.1.7 Demonstrate how the system allows assets to be upgraded.
3.3.2 Integration
The fixed asset system should be integrated with all financial applications so that the user can query across all
financial applications concurrently. The system should include financial reporting and a variety of ad hoc
reports.
3.3.2.1 Demonstrate how the different modules record the following cross-reference information:

purchase order number from purchasing in fixed assets and accounts payable

check number from accounts payable in fixed assets

asset number from fixed assets in accounts payable and purchasing

3.3.2.2 Demonstrate how the system can retrieve information from more than one integrated system into a single
worksheet based on a common denominator such as general ledger number.
3.3.2.3 Demonstrate how the user can query across all financial applications and send the results directly to a
spreadsheet.
3.3.3 Customization
3.3.3.1 Demonstrate how on-line entry screens can be customized and user defined fields added.
3.3.4 Reporting
3.3.4.1 Demonstrate the reporting function:

Demonstrate how year-end financial reports are generated.

Demonstrate a variety of ad hoc reports:

o Vehicles for a particular budget entity

o All assets for a particular department that are not tagged
o All asset acquisitions funded with Grant and Contract funds
3.4 Accounts Receivable (Non-Student) and Collections
An Accounts Receivable (A/R) application is required to collect for amounts owed to the University by all
outside parties. Parties that may owe monies include students, sponsors of grant and contract activities,
employees, vendors, internal departments, and alumni.
3.4.1 Creating an Account
3.4.1.1 Demonstrate how to attach a receivable to an employee, student, internal department, vendor, alumni, or
any other person or entity with a relationship with the University.
3.4.1.2 Demonstrate how to set up a customer account and describe the set up options, such as:

customer type (e.g., employees, students, vendors, and other customers)

billing preferences

invoice formats

addressing and "guarantor" features (retrieve from related data bases, where possible)

invoice delivery attributes (e.g., e-mail or e-forms for internal customers; U.S. mail for external
customers)

credit status

revenue account

3.4.2 Posting Charges

Auxiliaries has sent a bill to an employee. The employee has not paid so Auxiliaries wishes to submit this
accounts receivable to A/R for collection.
3.4.2.1 Show how Auxiliaries posts this charge to the employees account.
3.4.3 Sending Statements
3.4.3.1 Demonstrate the ability to generate multiple formats of invoices on a schedule and on demand, with tearoff remittance advice, OCR coding for scanning and lock-box activities. Also show how each department can
modify the invoice format and the billing cycle to meet their individual needs
3.4.3.2 Demonstrate the ability to maintain memo data and to print user-defined messages on statements.
3.4.4 Process Customer Information and Inquiry

3.4.4.1 Demonstrate the ability to display, on-line, a customers account name and address, collections status,
overall payment history, credit rating, and units doing business with said customer including contact name and
phone number, as well as other user defined information. In addition, demonstrate the ability to drill down from
summary information into transaction details.
3.4.5 Receive and Post Payments
3.4.5.1 Demonstrate how to post a payment (full and partial).
3.4.6 Account Adjustments and Refunds
3.4.6.1 Demonstrate the systems ability to use pre-defined reason codes (i.e. debit/credit memos, contract
adjustment, returns, etc.) for making adjustments to the original invoice amounts.
3.4.6.2 Show how cash refunds can automatically be generated to the Accounts Payable system for payment in
instances where duplicate payments or overpayments are received.
3.4.6.3 Show how refunds and credit balances can be applied to other charges for the same customer.
3.4.7 Credit and Collections
3.4.7.1 Demonstrate the ability of each department using the billing and collection system to separately establish
delinquency guidelines that will be maintained and managed in an automated fashion by the billing and
collections system.
3.4.7.2 Demonstrate the capability to put a customer in a "hold" status due to credit/collection issues and,
following payment of said amounts, how the customers history is footnoted for past credit/collection issues.
3.4.7.3 Demonstrate how the system can automatically or manually assess interest charges, receivable
management charges and other late payment fees, either on a fixed fee or percentage basis, based upon age,
revenue type, submitting unit, dollar amount, etc. Show how these charges may be overridden on a charge by
charge basis.
3.4.8 Reporting and Aging
The System Vice President requires monthly-generated reports to maintain the integrity of A/R balances and to
report to the governing body of the University.
3.4.8.1 Demonstrate the ability of the system to allow user-defined aging categories based upon revenue type.
3.4.8.2 Demonstrate the ability to maintain memo data at an invoice or customer level and be able to import a
group of student names into one memo or create an attachment with the list of names.
3.5 Cash Management
3.5.1 Daily Cash Management
3.5.1.1 Demonstrate the reconciliation capabilities by the system using on-line processing with multiple bank
accounts against General Ledger, Accounts Receivable and Accounts Payable activities.
3.5.2 Cash Receipt Processing
3.5.1.1 Demonstrate a generic cash receipt that can be used by multiple departments.
3.5.1.2 Show any tools available to help prepare a deposit.

3.6 Procurement
Overview of the Procurement Process
The procurement process should provide a user-friendly shopping, ordering, receiving and payment process.
This process should enable end users to make an informed buying decision, efficiently place an order, record
necessary information accurately in the system, acknowledge receipt of goods and services, and authorize
payment. The Purchasing Department, however defined, should provide more consultative services, develop
better information and tools, and support a variety of methods for acquisition and payment. Purchasing,
receiving and payment processes should leverage available technology and advances in electronic commerce.
There should be no distinction in the system between external vendors and internal vendors. All internal services
(e.g., facilities services, printing services, parking and transportation services, telephone and
telecommunications services, etc.) and interdepartmental transfers of goods and services should be accessed and
paid for through the same procurement system through which users procure goods and services from external
sources.
Purchasing Department: For the purpose of this demonstration the Purchasing Department provides the
following services:

advice and professional consultation to all authorized university purchasers

vendor information and analysis

pre-shopping and negotiation of contracts

identification of contract vendors based on cost, quality, and service

information to support local vendors, identification and tracking of purchases made from disadvantaged
vendors

in conjunction with vendors, maintenance of the shopping areas of the system

support for innovations that leverage trends in the banking industry, such as debit cards

formal invitation for Request for Quotations (RFQ) and Request for Proposal (RFP) services

resolution of problems with vendors

Types of Purchases - For the purposes of this demonstration script, there will be five different types of
purchases, which are defined below:

Internal - Purchases of goods or services which one university department makes directly from another
university department. Examples include purchases from Printing Services, University Bookstore, and
Facilities Management.

Small Purchases, Less than $1,000 Procurement that occurs directly from an end user to a vendor,
with limited assistance from Purchasing. End users may shop, order, receive, and authorize payment
without assistance from Purchasing. These purchases will be less than a specific dollar limit identified
in University policies and procedures (currently $1,000). Examples are:

o Purchases made for goods or services less than $1,000

o Purchases made using petty cash as the payment process

o Purchases requiring payment in advance

o Reimbursements for expenses incurred by employees, such as dues, the purchase of books and
other materials, telephone bills, etc.

Biddable Purchases - Purchases that an end user records on a purchase requisition and sends to
Purchasing, in cases where the amount of the purchase exceeds the specific dollar limit for small dollar
purchases or for any restricted commodities. Purchasing or individuals acting on behalf of the
Purchasing Department seek competitive quotes, issue formal invitation for bids or requests for
proposals, or negotiate sole sources and contracts. Purchasing or other designated individuals issue the
purchase order to the vendor.

Procurement Card - Purchases of less than $1,000 can be purchased independent of the normal
purchasing procedures with a department procurement card.

Personal and Professional Contracts Purchases initiated through contracts into which the University
enters for personal and professional goods and services independent of the normal purchasing process.

Preferably, the procurement process should be one module, not several, within the integrated system. Whenever
non-personnel expenses are to be incurred, all departmental employees should go to one place in the system.
From this one place, they should then be able to engage in internal, small purchases, and biddable purchase
assisted shopping, ordering, receiving, and payment activities. The integrated system should guide them into and
through the correct avenues for all of their procurement work.
Shopping - Research:
End users should have easy access to on-line shopping services in a real-time environment. Helpful navigation
tools and easy to use screens should facilitate shopping. Systems features should include:

up-to-date electronic catalogues

information on merchandise, including current prices, should also include enhanced product
descriptions and information on lead times for ordering, availability, and delivery options

listings of available surplus property owned either by the University or other state agencies should be
available

listings of recommended items with negotiated prices, terms and conditions (include base as well as
enhanced or deluxe models)

maximum access for end users and control over the purchasing process in the area of "small purchase"
procurement (governed by published institutional guidelines)

"smart" questions or ticklers may be generated by the system (for example, "when purchasing this type
of item, it is a good idea to think about")

an option to bypass the shopping/research phase and go straight to the ordering phase

flexible search options should include keywords, i.e. product name, product code, company name

downloading of search information in text or worksheet format should be available

navigation to the worldwide web from a purchasing session

incorporation of University and State contracts for goods and services in the system, without re-keying
of data, and accessible by end users

Ordering:
Selection of an item by an end user during the shopping/research phase should initiate the order process and
distribution of charges. Features of the ordering process should include:

assistance with object code selection by providing "English" descriptions for the various expenditure
codes

system warnings for errors such as invalid account number or object code

routing of orders to the appropriate approval authorities

ability for departments to check budgets and to encumber purchases as an option, not a requirement

ability to distribute costs (i.e., split-fund) to the correct accounts and object codes for all purchases,
including those made using procurement cards

ability to correct the distribution of costs between the time an order is placed and the time it is released
for payment to the vendor

availability of information on the status of an order

automatic liquidation of encumbrance amounts with actual amounts

ability to order through various electronic media, i.e. EDI, FAX, other

Delivery, Receipt, and Payment:

During the Delivery, Receipt, and Payment phases, the following capabilities are desirable:

For standard items, delivery should be made to a departmental default address. For unique delivery
needs, vendors should follow delivery addresses specified by the end user.

Payment of all invoices below a certain dollar threshold should be made through "negative
confirmation," in which receiving documentation is not required. Above a certain dollar threshold,
positive confirmation, or actual receiving documents, will be required. In either case, end users should
be provided with easy access to electronic invoice information. Also, end users should have the ability
to record and pay for partial shipments.

The university will leverage advances in technology and electronic commerce to facilitate timely and
easy payment. Specific features should include:

o centralized payment process

o payment through Electronic Data Interchange (EDI) or Electronic Funds Transfer (EFT),
where possible

o electronic invoices from vendors, where possible

o ability to scan and attach an imaged documents for payment purposes and departmental access

o electronic process to distribute procurement card charges to proper account before posting to
the General Ledger

o ability to support demand payments

o ability to transfer funds between departments
3.6.1 Internal Purchasing
The University has a number of auxiliary departments (Auxiliaries) that provide a wide variety of services to the
university community. Most services can be purchased from these departments, by University policy. Dr. Susan
Smith in the Math Department would like to have someone install built-in shelving in her office. She begins the
procurement process by shopping for this shelving service in the procurement section of the new integrated
system.
3.6.1.1 Show how Dr. Smith shops for this service and how an order would be placed. The order will include the
following information on the shelving specifications:

the quality of the shelving (3 grades are offered)

the room number and building number for Dr. Smith

the name of the contact person

their e-mail address

their phone number

a written description of what is desired by the purchaser

the two account number/object code combinations that are to be charged for this work

3.6.1.2 After going to the room to install the shelves and talking with Dr. Smith, Auxiliaries determines that a
change must be made to the order. Show how Auxiliaries notifies the Math Department of this change. Show
how the Math Department approves the change.
Professor Doug Dow is performing experiments in Electrical Engineering Department. He was given a modest
budget for this and has the authority to charge to a common account in the department. Dr. Dow is allowed to
order, but all his orders must first be approved by department head before they are submitted as firm orders. Dr.
Dow needs parts that are stocked in Engineering Stores, the central engineering inventory at the University.
3.6.1.3 There are many items in the on-line inventory in Engineering Stores. Demonstrate how Dr. Dow can find
the desired item and electronically submit the request to the department head for approval. Also show how the
department head electronically submits the request to Engineering Stores for order fulfillment.
3.6.2 Small Purchases - Less Than $1,000
A large number of purchases are less than $1,000 and do not require a purchase order. Good examples are bills
received for dues and subscriptions, or conference registration fees. Hopefully, in the future most of these will
be paid using a procurement card. However, there will always be those vendors who do not participate in the
procurement card process (e.g., small or foreign companies, etc.).
System Payroll has received an invoice for a subscription for John Brown. The cost is $200.

3.6.2.1 Show how this transaction is entered, including the required tracking information (such as name of
faculty member, program and subprogram code, etc.), and then split-funded between three account numbers
either on a dollar amount basis or a percent of total basis.
A speaker from another university presents a seminar at the University. A check for the $900 honorarium is
processed. The speaker is a U.S. citizen and a one-time vendor of the University. The seminar was held on April
29, but the voucher was not processed until May 1.
3.6.2.2 Enter the transaction to pay for this honorarium. Demonstrate how the speakers social security number
can be updated when it is discovered that it was incorrectly entered when the payment was generated.
3.6.2.3 Explain the processing of a Form 1099 at the close of the calendar year for the honorarium, excluding
the travel expenses. How does the system report this information to the IRS, using what media?
A foreign professor gave a lecture at the same seminar and received a $200 honorarium payment by check. The
professor is not a U.S. citizen, is a one-time vendor of the university, and incurred $467 for travel expenses. The
travel expenses are paid on the same check as the honorarium.
3.6.2.4 Demonstrate how taxes can be withheld from a payment of this type to a non-resident alien. Explain how
the payee is notified of this.
3.6.2.5 Explain the processing of a Form 1042S (Non-resident Alien reporting form) at the close of the calendar
year.
3.6.2.6 Demonstrate how the system will prevent duplicate payments for the same charge.
The Math Department purchases 20 practice tests from Math International, a vendor already on the University's
vendor data base. The department ordered the tests on December 30, 1998. The department received an invoice
in the amount of $875 on January 6, 1999 and physically received the tests on January 7, 1999. The amount is to
be paid within 30 days with a 3% discount.
Vendor

Corporate Address
Payment Address

Math International
123 Math Way
Math City, TN 37777
Math International
P.O. Box 666
Math City, TN 37701

3.6.2.7 Demonstrate how the department enters the information to purchase and pay for the tests, including the
following:

accessing and selecting a commodity code

completing all non-dollar required fields

acknowledging receipt of the tests

entering the amount to be paid

entering the date to be paid

recording the 3% discount

submitting the payment to work flow and electronic approval

approval of the payment by the Math Department and forwarding to the Dean of Arts and Sciences

forwarding of the approved payment to check writing/payment

posting of transaction to the General Ledger

displaying of the payment by the department prior to and after it has been posted to the General Ledger

3.6.3 Biddable Purchases

This is defined as procurement that occurs with assistance from Purchasing; either because the use of central
procurement services is mandated by policy or because the end user, on a voluntary basis, desires assistance
from Purchasing on a procurement matter that otherwise could be completed independently. Examples are
Requests for Proposals (RFPs), Requests for Quotations (RFQs), purchase orders, contracts, and amendments to
each.
Dr. Doug Dow in the Electrical Engineering Department wants to purchase two microscopes totaling $50,000
from his research account. The new scopes will ultimately be purchased from a vendor who has never before
done business with the University. The procurement section of Purchasing will assist with the purchase since the
marketplace for microscopes changes very rapidly and it is wise to always shop around for the best quality and
price.
3.6.3.1 Demonstrate how, with the least amount of effort, this item can be requisitioned and approved,
transmitted to Purchasing where the purchase order is prepared and sent to the vendor, and how the item will be
recorded as received.
3.6.3.2 Demonstrate how Dr. Dow can enter a list of recommended suppliers onto the requisition.
3.6.3.3 Show how Dr. Dow can indicate an acceptable or suggested price range for the microscopes on the
electronic requisition.
3.6.3.4 Computer Science will be paying for 23% (or a fixed amount) of the total purchase price. Show how
they can be informed that the requisition is being sent to procurement and how they can assign their accounts to
be charged and inform Electrical Engineering of this designation.
3.6.3.5 Based upon the object code, dollar amount and/or commodity code, the integrated system immediately
recognizes that this equipment must be added to the fixed asset inventory of the University. Show how it
prompts the person completing the requisition screen in Electrical Engineering to add building number, room
number, and two additional codes residing in the system.
3.6.3.6 Show how the purchase requisition will be sent to the person in Purchasing who is responsible for
assisting with the purchase of scientific equipment. Show how a purchasing manager can assign commodity or
buyer codes to the requisition, so that the requisition is sent to the correct buyer.
3.6.3.7 Show how the system will provide the buyer with a list of vendors who sell microscopes.
The University uses two primary methods for procuring goods and services: Request for Quotations (RFQ) and
Request for Proposals (RFP). RFQs are generally used to purchase those goods and services that are well
defined and where price is the determining factor. RFPs are used when the goods and services are less defined
or where factors other than price, such as the quality of the goods and services or contractual provisions, are the
determining factors and must be negotiated.
3.6.3.8 Show any tools provided to assist the buyer in his/her survey of the marketplace.

3.6.3.9 Demonstrate the creation of an RFQ or RFP. Show how conditions, such as payment terms, contractual
obligations, and hold harmless clauses, are incorporated into the bid process and its documents.
3.6.3.10 Discuss alternative methods of sending the RFQ or RFP to vendors.
3.6.3.11 Show how to collect information received from vendors in response to the RFQ or RFP.
3.6.3.12 Demonstrate the ability to create and print a bid tabulation worksheet, by vendor, which includes prices
by items with appropriate discounts shown.
3.6.3.13 Demonstrate the ability to allow the entry of multiple bids submitted by a bidder on the tabulation
spread sheet and calculate discounts.
3.6.3.14 Demonstrate the ability to maintain bid response statistics on all bidders.
3.6.3.15 Demonstrate trade-ins, special discounts, other than standard terms, and schedule of payments. If a
trade-in is a part of an order, demonstrate how the amount of the trade-in is deducted.
3.6.3.16 When the successful vendor is identified, show how the requisition is converted into a purchase order
which includes all funding, delivery and other user-defined attribute information.
3.6.3.17 Discuss how the purchase order could be sent via EDI, fax, electronic mail or other electronic
transmission to a vendor.
Dr. Dow has submitted a relatively simple requisition. In other cases, it will be desired that the requisition be
funded by many accounts and it will be desired that each line of a purchase requisition can be funded separately
from all other lines, on either a dollar amount or percent of total basis.
3.6.3.18 Demonstrate how the system would take the requisition for the two microscopes and use it as the basis
to prepare a new requisition two months after payment has been made for the initial order of two microscopes.
One of the new microscopes will be paid for by the Computer Science and Math Departments; the other by the
Engineering Department and Engineering Stores.
3.6.3.19 Demonstrate various "word processing" capabilities available for creating the purchase requisitions,
such as:

macros for standard text

use of pre-established templates (Include templates of documents that could be incorporated as

attachments to the requisition or prepared as separate documents (i.e. personal service contracts, license
agreements, etc). Show any capability to assign unique document numbers to these file documents.)

automated scrolling of screens

OCR scanning of documents

3.6.3.20 It is likely that other University departments will want to purchase microscopes from the same vendor
at the same time. Demonstrate how the requisitions from various schools/departments can be consolidated or
"stacked" on one purchase order per vendor and how this would be handled at a university-wide level without
losing any of the detailed information that is important to each school.
3.6.4 Change Orders
The purchase order for the microscopes is sent to the appropriate vendor. Dr. Dow decides that three, instead of
two, microscopes are needed. He has the funds available for this.

3.6.4.1 Show how the change order process works. Start with Dr. Dows decision to buy an extra microscope:

show how he gets approval for the additional purchase

show how all this information is transmitted to the buyer

show how the buyer expands the original order to the vendor to accommodate the new need

show the impact on the encumbrance field in the accounting system

3.6.5 Blanket Order Processing

The Electrical Engineering Department frequently orders gas cylinders from the same vendor. As a result,
Purchasing suggests that a Blanket Purchase Order (BPO) be established with a vendor.
3.6.5.1 Demonstrate the set-up of a BPO with a maximum transaction limit of $1,000. Show how to differentiate
between an BPO that represents a firm commitment to buy a specified amount over a period of time versus an
BPO that represents a target amount (that may or may not be reached) to be purchased over time.
3.6.5.2 Demonstrate how the order would account for demurrage credits or charges.
3.6.5.3 Show how the blanket purchase order can be renewed.
3.6.5.4 Show how a blanket purchase order to purchase specific items and a maintenance contract can be
included in a purchase order.
3.6.5.5 Show how to purchase or lease capital equipment and blanket purchase of supplies on a single purchase
order.
3.6.6 Assisted Buying Procurement System
3.6.6.1 Demonstrate the ability of a buyer to specify acceptable ranges for price and quantity.
3.6.6.2 Show how the system will calculate a discount for a line item. Show gross prices, discount percent or
dollar, net unit price, extension of net unit price.
3.6.6.3 Demonstrate the ability of a buyer to override certain fields in the bid/purchase order document.
3.6.6.4 Show how tolerances can be set to allow small discrepancies in purchase order quantities and/or amount
and invoice amount to be paid, without correcting the purchase order.
3.6.7 Procurement Cards
Dr. Bob Byte purchases nuts and bolts for Computer Science from an approved procurement card vendor using
a procurement card. Dr. Byte calls the vendor, gives the appropriate information, and the material is shipped and
received within 24 hours.
It is important that Computer Science is able to track these charges by expenditure category, by faculty member,
by account number and object code. In addition, Computer Science must be able to change accounting codes
before and after charges are posted to the General Ledger.
3.6.7.1 Demonstrate how a user can place an order on-line using a procurement card as a method of payment.

3.6.7.2 After the goods have been ordered, Dr. Byte wants to change the account number and object code to be
charged. Show how this is done.
3.6.7.2 After the goods have been received, but before the vendor is paid, show how the account number and
object code and other transaction attributes can be changed.
3.6.7.3 Show how the account number and object code and other attributes can be changed after the charge has
already appeared on Computer Sciences accounting statement for the month.
3.6.7.4 Demonstrate how a procurement card can be used to pay for goods after they are received regardless of
method of ordering.
3.6.8 Personal and Professional Contracts
The University enters into numerous contracts independent of the Purchasing Department with individuals and
non-individuals for the purchase of goods and services. These contracts may also reflect services that the
University provides to a third party for which the University receives compensation for those services.
The University enters into a contract with Software Implementation Success (SIS) to assist in the
implementation of financial and human resource software purchased from a third party. Specific information
about the company and conditions of the contract are as follows:
Contracted with:
Federal ID Number:
Address:
Maximum Amount of the Contract:
Contract Period:

Software Implementation Success

62-999999
P.O. Box 999E
Knoxville, TN 37991
$75,000
April 1, 1999

From:
December 31, 2001
To:

Purpose of the Contract:

To assist in the implementation of financial and

human resource software purchased from a third
party. Travel and other expenses will be in
accordance with the University's normal polices
and guidelines.

3.6.8.1 Demonstrate how the information above is entered by the department into the contract and how a unique
tracking number is assigned to the transaction.
3.6.8.2 Demonstrate, at the time of entry, how the University's vendor data base is checked to determine if
Software Implementation Success is already on the vendor file. For the demonstration, the company should
already be on the vendor data base.
3.6.8.3 Demonstrate how the originating department approves the contract and forwards it to the next office in
the approval process.
3.6.8.4 The contract amount, $75,000, exceeds the amount for which a contract can be approved at the
campus/unit level. Demonstrate how the approval route can be expanded to include the System Vice President.
3.6.8.5 Demonstrate how the work flow/electronic approval process reflects when the information about a
contract was entered into the system, who entered the information, when it left that area of responsibility, and
who approved the transaction. That same functionality and information must be available at each step in the
approval process.

3.6.8.6 Demonstrate how the $75,000 was pre-encumbered at the point of entry, changed to an encumbrance
once the contract was finally approved by the campus/unit business office and the encumbrance was released
once payment had been made.
3.6.8.7 Demonstrate how the payment(s) against the contract can be linked to the contract and both the contract
information and payment(s) presented in a real time basis.
3.6.8.8 The University maintains an electronic image of a standard contract on a web site. Show how a
department might access that document, complete the required information, and electronically route the
transaction through the work flow/electronic approval system.
3.6.9 Vendor Relations
Vendor Master File
3.6.9.1 Demonstrate how a vendor is setup in the system and show the information being entered and tracked for
a vendor, such as:

minority status

federal identification number

remit-to addresses

vendor-specific payment terms

vendor performance data

elimination of multiple listings for same vendor

3.6.9.2 Demonstrate how Purchasing can put a vendor on hold and notify individuals who have purchased from
the vendor in the past of this action.
3.6.9.3 Demonstrate how frequent purchasers are listed in the vendor history and how Purchasing is informed of
this action, automatically.
Vendor Reporting and Performance
3.6.9.4 Demonstrate the ability to drill down through the vendor history to specific invoices or line items.
3.6.9.5 Demonstrate flexible search capabilities by vendor name and number, purchase order number, project,
object codes, check number, department, account number, invoice number, date and other parameters residing in
the system.
Product Catalog Set-up and Maintenance
The Purchasing Office manages an in-house catalog of office supplies frequently purchased by department
users. We would like to make this catalog available to users in an on-line format.
3.6.9.6 Demonstrate an on-line catalog, including the ability to load scanned images of products.
3.6.9.7 Demonstrate the ability to automatically go to the Internet to retrieve a vendor catalog and update the
Universitys procurement data base with new prices, and also notify the buyers that prices have been updated.

Vendor Maintenance of Catalogs

3.6.9.8 Demonstrate the ability to allow vendors to add/change their catalog prices, if approved in advance by
the University, but restrict the vendors from seeing other vendors prices.
3.6.9.9 Demonstrate how a vendors catalog is accessed by University departments and integrated with the
Universitys purchasing system.
3.6.10 Commodity Codes
The University wishes to adopt a commodity code structure that identifies classes of goods and services by
utilizing an industry standard code structure. Examples include SIC, HDS, and UPC.
3.6.10.1 Demonstrate the ability to support a commodity code structure and periodic updates.
3.6.10.2 Demonstrate the ability to cross-reference different commodity code grouping systems.
3.6.10.3 Demonstrate the ability to include both products and services in any commodity code structure.
3.6.10.4 Demonstrate the ability to generate statistics about the usage of each commodity.
3.6.10.5 Demonstrate the ability to allow entry of an item when an appropriate commodity code is not available.
3.6.11 Receipt matching
3.6.11.1 Demonstrate two-way and three-way matching: 1) receipt acknowledgment and Purchase Order; and 2)
receipt acknowledgment, Purchase Order, and invoice.
3.6.11.2 Demonstrate how an invoice amount that is different from the purchase order amount is handled by the
system and demonstrate the capability to have a user-defined tolerance level for the difference.
3.6.12 Delivery Instructions
3.6.12.1 Demonstrate the ability to accommodate detailed delivery instructions, including internal delivery
information and multiple delivery points either on or off campus.
3.7 Accounts Payable
The Accounts Payable function must provide for the payment of invoices related to purchase orders, purchases
less than $1,000, procurement cards, contracts issued outside of the Purchasing department, petty cash, and
reimbursement for travel-related expenses. The processes for initiating a purchase and subsequent activities
(receipt of goods or services, receipt and approval of an invoice, etc.) should be a function of every department.
3.7.1 Voucher Processing
3.7.1.1 Demonstrate the ability to spread discounts across multiple account numbers and object codes used on
one invoice.
3.7.1.2 Demonstrate the ability to change the terms on one invoice to 2%-10 days if these are better than the
original terms offered on the invoice.
3.7.1.3 Demonstrate the ability to generate a payment immediately instead of waiting until 30 days have passed.
3.7.1.4 Demonstrate the ability to enter a request for payment immediately to be paid on a future due date.

3.7.1.5 Demonstrate how vendor credits are applied to future charges.

After they have approved payment, the Math Department finds that the pages are stuck together on 10 of the 20
tests they ordered.
3.7.1.6 Demonstrate the ability for the payment to be held.
3.7.1.7 Demonstrate the ability to split the invoice to allow payment only of the portion of the invoice not in
dispute.
3.7.1.8 Demonstrate the ability to capture and monitor retainage from invoices if the bid allows it, and ability to
monitor and release the retainage upon completion of the contract terms.
3.7.1.9 Demonstrate the ability to include deductions (i.e. freight, taxes).
3.7.1.10 Demonstrate the ability to include additional charges for freight and taxes.
3.7.2 Manual Check Processing
Penny Pincher from the System Budget Office is hosting a lunch at a local restaurant. She is willing to pay for
the meal, but needs to be reimbursed immediately afterwards. She brings the receipt to System Budget Office.
3.7.2.1 Show how the department enters all of the required information to generate the payment, including the
accounts and object codes being charged, and have it printed on a network printer.
3.7.3 Payment Processing
3.7.3.1 Demonstrate the ability to close a purchase order upon payment of the final invoice (order complete,
detail complete) with the ability to reopen.
3.7.3.2 Demonstrate the ability to cancel and reissue checks, including any reversing entries.
3.7.3.3 Demonstrate the ability to cancel a check and reissue it to a different vendor, including any reversing
entries.
3.7.3.4 Demonstrate the ability to cancel a check and reissue to include only selected invoices.
3.7.3.5 Demonstrate the ability to include all invoices to a vendor in a single check.
3.7.3.6 Demonstrate the ability to select invoices to be included in a payment to a vendor.
3.7.3.7 Show how the vendor who received the order can communicate delivery dates and other important
information to the ordering department in an electronic fashion.
3.7.4 Travel Reimbursements
Reimbursement to employees, guests, or other individuals who may be associated with the University who incur
travel related expenses are reimbursed in accordance with predetermined per-diems and guidelines. There are
different per-diem rates for lodging and meals within and outside the State of Tennessee. Additionally, there are
three different reimbursement rates for selected groups within the University. At some time in the future the
University may adopt the federal per-diems.
The University does not maintain an in-house travel agency, but utilizes a designated agency for the purchase of
airline tickets for employees located within the Knoxville area. It is anticipated that each University location
will identify a designated agency that will provide that same service. Employees who have access to a
designated travel agency must use that agency or have their reimbursement for an airline ticket reduced by a

fixed percentage. The system must be able to identify individuals who must use the designated agency and be
capable of reducing the reimbursement for an airline ticket by the percentage so specified.
Bill Rogers in Campus East HR/AA wishes to travel to Chicago to attend a week long conference on the latest
in integrated software for higher education. The trip will be paid for from the departmental operating account.
3.7.4.1 Create an authorization for travel that identifies the dates, location, lodging and rate, and reason for the
travel. That authorization should be processed through work flow/electronic approval from the originating
department to final approval.
3.7.4.2 Pay a third party for a registration fee prior to the start of the trip. This payment should then be reflected
as a prepayment on Bill Rogers request for reimbursement.
3.7.4.3 Show how Bill Rogers can request a travel advance of $500.
3.7.4.4 Show how all estimated trip expenses can be encumbered to include the name of the staff member, the
account number and object code, and sent for approval to the Finance Vice Chancellor East.
Upon returning from Chicago, Bill Rogers wants to submit all of the trip expenses for reimbursement. The
expenses total $2,500, including an airline ticket, lodging for two nights, taxi fare, prepaid registration fee, car
rental, and telephone calls.
The module must be able to help Mr. Rogers by containing the latest per diem and mileage rates allowed by the
University and Federal per diems.
3.7.4.5 Demonstrate how Mr. Rogers enters all of the information into a travel reimbursement module. He will
be allowed to indicate his name and enter all expenses and all accounts to be charged. This will help him do an
annual report of "all travel from all sources for all staff" for the department head.
3.7.4.6 Show how Mr. Rogers travel advance is automatically deducted from the reimbursement authorized
without him having to receive the money first.
3.7.4.7 Show how the remainder of the money, $2,000, is deposited to Mr. Rogers bank account and how he is
notified of this event.
Mr. Rogers has yet to submit a voucher for a prior trip to New York that occurred a month ago; the travel
advance for that trip is now past due.
3.7.4.8 Show how the amount can be deducted from Mr. Rogers paycheck after he has not responded to two
separate messages on this subject.
3.7.4.9 Demonstrate a query reporting all travel expenses for all staff, broken down by job classification.

4. Budget Demonstration Script (4 hours)

The campuses and units comprising the University involve staff at all levels in the on-going budget process.
While the depth of involvement varies by campus/unit, the Universitys budget system must provide the
flexibility to assign responsibilities to create, review, and monitor budgets to appropriate levels identified by
each campus/unit. Typical users of the budget system include:

fiscal technicians & clerks

fiscal administrators

department & division managers

principal investigators & research administrators

chief business officer at each campus/unit

vice presidents & chancellors

Controllers Office

System Budget Office

Board of Trustees

Preparation and Submission

Budgets need to be created at different levels and individual budgets need to be aggregated at different levels
(i.e., roll up data to see a bigger picture). Regardless of who prepares the initial budget, departments should have
the ability to:

create budget models and what-if scenarios

use smart templates as an aid in creating the budget; for example, automatically calculate indirect costs
and fringe benefits

budget by person, unit, or project, as applicable

budget down to different levels of detail for different accounts

maintain different fiscal year budgets concurrently, and process transactions against either

monitor sources and uses of dollars

Review and Approval

The budget review process needs to be flexible in order to allow varying review and approval paths. Approvals
will be required by the campus/units according to a pre-described process. Once budgets are approved at the
campus/unit level, they are transmitted to the System Budget Office for final approval and incorporation into a
single Budget Document for approval by the Board of Trustees. The status of the budget approvals should be
tracked.
Those reviewing the budget should have the ability to:

easily identify deviations to non-standard budgeting or violations of set budgetary guidelines which
may vary from year to year

review and approve a budget at different levels of detail, or in aggregate

Implementation
Budget activation should require a minimal amount of intervention, assuming all appropriate reviews and
approvals have occurred. Features include the ability to:

activate a new budget while the current budget is active

activate a new budget at whatever level of detail created by the department

activate a budget based on user selected attributes, i.e., event driven

electronically post budget data to other systems, such as Payroll and the General Ledger

Budget Revisions
Campus/units should have the ability to amend budgets for accounts within their purview to reflect anticipated
revenues and expenditures after the establishment of the original budget. This will include the ability to:

enter budget revisions on-line for a departments own accounts

process temporary and permanent revisions

access detail to assist departments in generating custom management reports

review and approve budget revisions through a predefined approval path

4.1 Salary Budget Development

The salary budget provides all the information needed to support the salary and benefit expenditures, by account
number, contained in the proposed budget. The following events are typical examples of transactions to be
addressed in the scripted demonstrations for a budget period from July 1, 1999 through June 30, 2000, unless
otherwise noted.
4.1.1 Establish a Base Salary Budget
4.1.1.1 Show how a department is provided a salary budget, including both filled and unfilled positions, that will
serve as the beginning step in the budget process. Both salary and detailed benefit information should be
provided. This will become the Base Salary Budget.
4.1.2 Adjustments to Base Salary Budget
Show how the following adjustments can be accomplished once the Base Salary Budget has been established for
each account. Note that adjustments are not final until approved by the last approving budget authority (the
System Vice President).
4.1.2.1 Show how a vacant regular, full-time, twelve-month position with full benefits is added to the system.
4.1.2.2 Show how ten (10) vacant positions, all having the same characteristics, can be added to the system
without having to add each position individually.
4.1.2.3 Show how a position pool account can be created to allow budgeting of a lump sum amount to fund
summer school salaries for the Math Department. Position numbers should not be assigned to the pool.
4.1.2.4 Assume the Electrical Engineering Department wants to create a pool account that includes funding for
three student positions at 50% time each. These positions do not need a position number, but they do need to be
included in the position count. Demonstrate how this can occur.

4.1.2.5 Show how a currently filled position known to become vacant in December 1999 is entered in the
Budget System. The position will remain a vacant authorized position for the remaining six months of the
proposed budget with a reduced budgeted amount.
4.1.2.6 Show how the position held by Susan Smith is transferred from the Math Department to the Electrical
Engineering Department with no change in the person, salary, job title, etc. The department to which the
individual is transferring is in a different college and this follows a different approval path.
4.1.2.7 Repeat the same scenario in 4.1.2.6, but Susan Smiths position will transfer from the Electrical
Engineering Department to the West Station.
4.1.2.8 Show how a new position is budgeted that has multiple funding sources, one of which is a restricted
account that is tied to a three-year grant that begins July 1, 1999.
4.1.2.9 Show how a $200 per month increase effective September 1, 1999 for John Brown (System Payroll) is
included in the Salary Budget. Mr. Browns salary for July and August will be at his current salary level.
4.1.3 Staff Benefits Budget
Staff benefits associated with both filled and unfilled positions should be included in the development of the
Salary Budget.
4.1.3.1 Demonstrate how salary benefits are calculated and included in the Salary Budget System.
4.1.3.2 Show how a default benefit package (FICA, retirement, family group insurance coverage, for example)
can be established in the system for vacant authorized positions.
4.1.3.3 Show how staff benefits are calculated on position pool accounts.
4.1.4 Salary Budget Reports
Information contained in the Salary Budget System is disseminated in various ways for both internal and
external users. The scripted demonstration should show how reports are produced for the following purposes.
4.1.4.1 Show the various ways by which information concerning Mary Bit can be obtained through the system.
4.1.4.2 Produce a report that shows the budgeted salaries for all positions in the Computer Science Department.
4.1.4.3 Produce a report that shows both salary and benefits by type of benefit (FICA, retirement, group
insurance, for example) by employee for each department. A grand total for the department should be included
in the report.
4.1.4.4 Produce a report that contains summary information only for the Computer Science Department.
4.1.4.5 Produce a report that shows the authorized position count for the East Campus by department by position
type (faculty, administrative, clerical/support, student) with a grand total for the campus.
4.2 Budget Development
The budget development process needs begin with a single account number and have the ability to roll up
accounts by department level, college level, dean level, functional level, campus/unit level, and the total
University. AWhat if@ scenarios are needed at all budgeting levels. Staff must have flexibility within given
parameters to develop, review and monitor budgets on a continuous basis. Using the background information
presented below, the following events are possible occurrences to be addressed in the vendor demonstrations to
determine how the proposed software supports the budget development process.

BACKGROUND INFORMATION - Unrestricted E&G Budget

99
nal
et

FY 99
One-Time
Revision

$100,000

26,000

30,000

5,000

3,000

$164,000

Object
Code

West Campus
West Station

FY 99
Original
Budget

11

Faculty Salary

$125,000

12

Clerical Salary

20,000

FY 99
One-Time
Revisions

FY 99
Permanent
Revisions

(50,000)

FY 99 Budget
At Beginning
of FY 00
Budget
Preparation

$75,000

20,000

13

Staff Benefits

35,000

31

Travel

4,000

39

Supplies

3,000

3,000

35

Communication

7,000

7,000

61

Equipment

Totals

(10,000)

25,000

(1,000)

5,000

$194,000

$4,000

3,000

5,000

($60,000)

$138,000

4.2.1 The FY 99 beginning budget adjusted for all permanent revisions will serve as the starting point for the
development of the FY 00 Budget (Abase control amount@). Show how this is accomplished using the
information provided in the above example.
4.2.2 The salary and benefits cost used in the final budget recommendation will come from the Salary Budget
System that has been used to project the FY 00 personnel cost by authorized position. Show how this
information is incorporated in the recommended budget for the Computer Science Department.
4.2.3 A report is needed to show the difference between the salary amounts contained in the FY 00 base budget
and the Salary Budget System by account number. Show how this is accomplished.
4.3 What-if Scenarios
Once the Base Budget has been established, departments should be able to prepare multiple budgets for
consideration. One of these working budgets will be submitted to the Dean for approval. The following
independent examples should be included in the software demonstration along with any other budget
development functionality provided by the proposed software:
4.3.1 The East Campus Vice Chancellor for Finance has notified departments that travel reimbursement rates are
going to increase by 2%. Consequently, all travel budgets included in the FY 00 Base Budget (the initial starting
point) will be increased by 2%. This change will become a permanent adjustment that will establish a new base
control amount for each account.

Show how this adjustment is accomplished when the Vice Chancellor for Finance knows of this rate
change and can adjust the Base Budget before departments begin the FY 00 budget process.

Show how departments are advised of their base control amount and how it is incorporated into the FY
00 budget preparation process if the change occurs after departments have begun to work on their
budget recommendation.

4.3.2 The Computer Science Department has been given a 2% increase ($200) in its operating budget, (Original
Budget and permanent revisions only; does not include increases on salary or benefit amounts), to cover
inflationary costs. Show how the department can:

allocate funding by increasing each non-salary object code by 2%

allocate funding by allocating specific dollar amounts to individually chosen object codes

4.3.3 The West Station decides it wants to build its budget at the detail object code level, although the budget
submitted by the department will be based on the primary object code level. The budget will be submitted
through the approval process based on the primary object code. Show how this can be accomplished.
4.3.4 The East Campus Vice Chancellor for Finance has decided to have departments develop two different
budget recommendations - - the first is based on a fee increase of 4% and the second is based on a fee increase
of 5%.

The Computer Science Department will have $2,000 more in funding available under the 4% fee
increase $3,000 under the 5% fee increase. Show how multiple budget scenarios can be developed and
maintained by a department pending further instructions from the East Campus Vice Chancellor for
Finance advising which budget should be submitted as the recommended budget. Departments may
have more than one scenario developed for each of these budget levels.

The Computer Science Department wants to attach comments to each of the developed scenarios to
describe what changes are included in each scenario. Show how this is accomplished.

4.3.5 The computer services cost (object code 38) for the Computer Science Department is being charged to a
central account and, therefore, no computing cost should be budgeted in this department. Demonstrate how this
control can be incorporated in the budget development process.
4.3.6 A new object code, 40 - Printing, will be added at the beginning of FY 00. Show how departments will
incorporate this new object code as they plan their FY 00 recommended budget.
4.4 Budget Review and Approval
The approval process requires the Dean to approve the budget for each department reporting to him/her. Once
the budgets are approved by the Dean, the budgets are then forwarded to the appropriate Vice Chancellor for
approval. After the Vice Chancellor approves the budgets, the recommended budgets are sent to the Vice
Chancellor for Finance for final campus/unit approval. After the campus/unit has concluded its work, the
campus/unit recommended budget is sent to the System Budget Office for final approval and inclusion in the
Budget Document that will be submitted to the Board of Trustees for approval.
4.4.1 Demonstrate the ability for management to review, change, request revisions and approve the budget online.
4.4.2 Demonstrate the capability to maintain various budget versions or document changes that may be made as
the budget moves through multiple approval steps to final adoption. Include in the demonstration an example of
how a comment field or other such messaging system is used to identify changes made during the approval
process.
4.4.3 Describe the "roll-up" of multiple budgets to a consolidated budget both before and after approval.
4.5 Budget Implementation
After budgets have been reviewed and approved, they are posted to the General Ledger.

4.5.1 Demonstrate how budget data are used to update and post to other systems, such as Payroll and the
General Ledger, without having to re-enter the data (e.g., object code, budgets by account, employee
compensation, funding sources, pay cycles, percentage time worked).
4.5.2 The Electrical Engineering Department has received a grant from XYZ Corporation to fund a research
project. This grant will begin October 1, 1999. Available funding is $100,000 for FY 00, $250,000 for FY 01,
and $50,000 for FY 02. The funds should all be allocated to object code 11, Faculty Salaries. Show how this
budget will be established and how future budgets will be affected (will unspent funds automatically carry
forward into the next year or will a new budget need to be established annually).
4.5.3 The University receives grants that span multiple years. Demonstrate the ability to have designated
revenues and expenditures, tracked across fiscal years. Note these budgets may or may not start or stop
concurrent with a fiscal year. Discuss what notification is provided to the appropriate personnel that a budget
change has been implemented.
4.6 Budget Revisions
During the fiscal year, departments need the capability to make adjustments to their Original Budget. The
following situations are typical adjustments departments may need to make.
4.6.1 The Electrical Engineering Department has learned since the approval of their budget that an additional
$200,000 is needed to replace a piece of equipment. Additional gift revenues in a like amount will be available
to cover the anticipated expenditure increase. Prepare a budget revision to reflect this adjustment.
4.6.2 The Controllers Office is replacing their high-speed printer. Over the past two years, the University has
accumulated the $40,000 needed to purchase this equipment in Plant Funds. The purchase will be made from its
unrestricted account. This expenditure was not budgeted at the beginning of the year. A budget revision and any
associated accounting entries are needed to reflect this movement of funds. Show how this adjustment is
accomplished in both the budget and accounting systems.
4.6.3 The original budget (July 1) for the Dean of Ag Experiment Station was:

Salaries

$100,000

Benefits

25,000

Travel

3,000

Printing

15,000

Communications

TOTAL

Show how each of the following adjustments are accomplished:

7,000

$150,000

On September 12, a budget revision was submitted to increase the printing budget by $5,000 to fund a
new one-time publication. The source of funding will be from the fund balance. This revision should
not be a part of the continuing budget for the Dean of Ag Experiment Station when next years budget
is prepared.

On October 24, a budget revision is submitted to reduce Supplies by $1,000 and increase
Communications by $1,000. This will be an on-going adjustment that will be reflected in the
continuing budget.

On December 22, a budget revision is submitted to increase travel by $500 and decrease
Communications by $400. Show what happens when an unbalanced budget revision is requested for
processing.

On March 1, the University gives a 3.0 percent increase to all University departments. According to
Payroll records, the increased salary cost for the Office of the Dean of Ag Experiment Station is $3,000
and the total benefit cost is $700. Since the budget information is available from the Payroll Office,
show how a budget revision can be generated by the System Budget Office and charged to the Deans
accounts. The funding for the salary increase will come from the current fund balance.

4.6.4 The Dean of Ag Experiment Station has processed multiple budget revisions during the year. It is now
eleven months into the fiscal year and the West Campus Budget Office needs a detailed report of every
transaction impacting this account since the beginning of the year. Show how this is accomplished.
4.6.5 Demonstrate the ability to track the differences between original and revised budgets.
4.7 Budget Controls
Many of the Universitys funding sources have restrictions placed upon them. For example, sponsored research
funds are frequently restricted for travel and equipment purchases.
4.7.1 Demonstrate the ability to restrict expenditures by fund, account, primary object code, detail object code,
or any combination thereof.
4.7.2 The Computer Science Department has a contract from XYZ Corporation for $10,000 to conduct a
research project. The expenditures for this contract will be recorded in a restricted account. To comply with the
terms of the contract, expenditures in excess of $10,000 cannot be processed against this account. If an invoice
is presented against this account which would cause expenditures to exceed $10,000, then the invoice should be
processed against the unrestricted account for the Computer Science Department. Demonstrate how the system
would handle this control. Include notifications that could be sent to the Computer Science Department and the
Controllers Office when an invoice is paid against the unrestricted account.

5.

Human Resources/Payroll Demonstration Script

5.1 Human Resource Processes

5.1.1 Position Tracking and Control
When a department has a vacancy, it may be a new position, the same position as currently exists, or may be a
position where job responsibilities have changed. The department needs to be able to update the current
positions description or create a new position description. The administrator needs the ability to access
information on different job descriptions by entering key descriptive words to the system, which would then link
to job descriptions to select applicable job information and titles. The administrator needs the ability to prepare a
job description on-line. The administrator would log into the system to create a position posting form which
identifies the type of position, position number, start and end dates, job requirements and skills, account(s) from
which the employee will be paid and other relevant information. The system would automatically route the

posting/job description for approval based on information entered on the posting/job description. If the job is a
new position, the information would be routed to HR for an appropriate job title to be assigned.
After the manager completes all required fields on the screen, he/she has the option to automatically reflect
(encumber) the anticipated cost of salary and benefits for this position in his/her department=s budget through
an interface with the financial accounting system.
The position control function includes the following features:

position reporting including listing the status of employee positions (recruitment, hire, status changes,
attrition, reduction in force, filled, unfilled, etc.)

online indication of authorization, budget availability, commitment of dollars

generated updates to the salary budget system

The system should maintain, at a minimum, the following position fields:

Position Identifier
EEO Category
EEO Job Group
FLSA Code
Grade Level
Job Size Measure
Title Code
Designation
Category
Federal Appointment
Service Base Indicator
Tenure Track Indicator
Budgeted Full Time Equivalent
Budgeted Salary
Responsible Account
Fund Source
Salary Range
Link to Employee Record
Job Summary/Description
Job Required Qualifications
Job Desired Qualifications

unique key
2 digit code (01-07) as defined by the EEOC
4 digit identifier, defined by the University
Wage/hour status
2 digit code to group titles (01-99)
4 digit measure of the job size (points)
5 digit code for the title
R=regular, T=term/temp, S=Student
5=exempt, 4=nonexempt, 2=faculty, 1=student
yes/no
9 month, 12 month, or flex year
tenured, on track, or ineligible

account responsible for this position

account charged for this position
salary minimum, midpoint, maximum
associating position to the employee
text describing the position
coded data & free form text
coded data & free form text

Position Tracking and Control Demonstration Data

Steam-fitter: The Physical Plant needs a new Senior Steam-fitter position. The department initiates a request
for the new position that must be approved by the Chancellor East and the East Campus Vice Chancellor
Finance before reaching the System Budget Office for final approval. The position will be a regular, full-time,
non-exempt, biweekly position at grade level 9 (of 13) projected to paid at $10.00 per hour and eligible for full
University benefits. A steam-fitters position requires trade school or technical high school and 2-3 years
apprenticeship in steam-fitting.
Professor of Electrical Engineering: The Electrical Engineering Department needs an additional Associate
Professor. The department initiates a request for the new position that must be approved by the Chancellor East
and the East Campus Vice Chancellor Finance before reaching the System Budget Office for final approval. The
requested position will be a regular, full-time, faculty, monthly paid position projected to be paid at $60,000 per
year and eligible for full University benefits. Two different accounts within the Electrical Engineering
Department will fund the salary equally. One of the accounts is a grant account. Even though the teaching will
be only for the academic year (September through May) the salary will be paid over 12 months starting on

August 1. The position requires a PhD in Electrical Engineering, 3-5 years of University teaching experience,
and a record of publications and research.
Director of West Station: The West Campus has a vacancy for a position of Director of the West Station. The
position will be vacated by John Smith on June 1, 1999. The position is exempt, regular, full-time, paid monthly,
and budgeted at the annual rate of $50,000. The position is responsible to a single administrative account but
paid 75% from that same account and 25% from an East Campus account. The position requires a masters
degree in communications or a related field and a minimum of five years of media relations experience and
supervisory experience.
Student Employees: The Computer Science Department employs about 10 students to help with filing and
other office tasks. Each student will work about 20 hours a week and the rate of pay will vary with the length of
service of the student.
John Brown: The System Payroll Office has an existing regular full-time audit clerk position occupied by John
Brown. Due to a reorganization, this position will be transferred to the System Accounts Payable Office. The
individual filling this job will also transfer to the Accounts Payable Office with no change in pay or work
schedule.
Susan Smith: The Math Department has a full time professor (Dr. Susan Smith) who spends 40% of the time
teaching mathematics and 60% working on a restricted research grant. This individual is associated with two
positions: a math professor and a research professor. Her pay is split equally between the two positions.
5.1.1.1 Demonstrate how the above positions are created, authorized, maintained and changes tracked over time
at various organizational levels, including incumbent and funding information.
5.1.1.2 Demonstrate how to update a job description on-line including access to job titles and descriptions. For
example, a user should be able to enter attributes such as position type and job description keywords to generate
a potential list of titles and job descriptions. The change should be routed as appropriate for approval before
becoming effective.
5.1.1.3 Demonstrate how the system:

optionally verifies the funding availability (i.e. using data from the financial accounting system)

allows user, if desired, to automatically encumber salary and benefits for a specified period in the
financial accounting system, etc.

deactivates an open but unfilled position, including the impact on all affected databases such as the
encumbrance of funds in the General Ledger

5.1.1.4 Show how a user would specify a group or range of positions to review or print.
5.1.1.5 Show how multiple funding sources, expiration dates, and FTEs are handled.
5.1.1.6 Show the relationship between employees and positions.
5.1.1.7 Show how a position can be associated with a job size measure (4 digits) and a unique salary range
including minimum, maximum, and midpoint.
5.1.1.8 Demonstrate the approval process for creating positions.
5.1.2 Applicant Processing

An applicant enters resume/professional information into a central database via various media. The system
should provide help to users to accomplish this process, including informing the applicant of required
qualifications/skills for the positions.
The applicant could: 1) apply for a specific position(s) or request resume to be kept on file for appropriate
vacancies; 2) search the system for open job positions; 3) present appropriate application online, which includes
Affirmative Action/Diversity information; and 4) indicate preference for campus location. The system will
inform the applicant of the testing/search process involved for positions based on their indicated interests. In the
case where there are state required examination processes, the system will schedule, administer tests where
possible, score exams, and notify applicants of their exam scores electronically or by generating a standard
notification letter.
If applicant is a current employee, his/her information will be obtained from existing databases. The employee
also has the option of providing resume/professional information for processing.
5.1.2.1 Demonstrate the process for entering, storing and retrieving applicant data, discussing digitally imaged
documents and/or Optical Character Recognition (OCR). Describe the structure of the database in relation to
this information, and any relationships with other database tables.
5.1.2.2 Demonstrate the applicants ability to identify units of the institution to which the application must not
be distributed.
5.1.2.3 Show how an applicant performs on-line inquiries about the status of their application.
5.1.2.4 Demonstrate the ability to inquire about all open positions and positions closed in the last 3 months.
5.1.2.5 Demonstrate the ability for hiring officials to access the entire database of active applicants at any time
and run a "trial pool" of applicants using potential screening criteria.
5.1.2.6 Demonstrate the capability to generate standard letters and email at various points during the application
process that may include request for letters of reference, notification of test schedule and letters of offer and
acknowledgment.
5.1.2.7 Show how to extract and update employee information from existing internal employee history
databases for an applicant that is hired, but who was a former employee.
5.1.3 Recruitment and Hiring
Employees are usually hired into established, approved positions. Once a position exists a department needs
access to information which will help in identifying qualified applicants.
The system would match the open postings with qualified applicants in the database and route this list of
candidates automatically along with the applicants resumes and other appropriate documentation to the
administrator and/or other interested parties indicated on the posting. The system may notify applicants once
they are selected for consideration for a position. The system will have the capability to generate standard
reference check information, including educational background and diplomas, letters, phone, fax, email and
generate general contact lists. After the final selection is made, the administrator enters that selection which
triggers a routing of the appointment for electronic approval. Administrators must enter information on
candidates not selected and can enter general comments on any or all applicants. System would generate
standard rejection letters to candidates not selected.
After the applicant is selected, the system would provide a letter of offer template for modification and routing
for approval based on position and the user defined requirements. The system will know by position when to
create the letter, prior or post acceptance. System will generate notification to applicant if a pre-placement
physical/drug test is required and automatically notify relevant departments of this requirement. In addition, if
appropriate, the system will transmit the applicant's data to appropriate agency for criminal checks.

Also, managers would have the ability to perform ad-hoc searches on the applicant database. The system will
also provide data on underutilized categories both at department and position level.
Recruitment and Hiring Demonstration Data
Steam-fitter: The Physical Plant now completes a job requisition to fill the position of Senior Steam-fitter. This
requisition must be approved by the Chancellor East and the East Campus AA Office before it is sent to the East
Campus HR Office. After receiving the requisition, the position will be advertised in the local newspaper and on
the job vacancy list on the Universitys Website using a description associated with the open position. East
Campus HR will match the required (and desired) skills for the position to a list of current applications to
determine which applicants are qualified. Copies of qualifying applications are forwarded to the department for
review. New applications from individuals applying directly for that position will be forwarded to the
department if they meet the requirements of the position.
The Physical Plant conducts interviews with three applicants and decides to hire Penny Piper at a salary of $10
per hour. Notification of this decision, along with justification as to why she is the best applicant and why the
other two were rejected are forwarded to East Campus AA. The request to hire is approved by East Campus AA
and forwarded to East Campus HR. East Campus HR approves the salary and offers the job to Penny Piper,
contingent upon the successful completion of CDL, drug and alcohol screening, and a respirator exam. In
addition, Mrs. Piper is notified that upon successful completion of the above, she must provide proof that she is
eligible to work in the US based on criteria designated by the Immigration and Naturalization Service (I-9).
Professor of Electrical Engineering: The Electrical Engineering Department initiates a requisition to hire the
new Associate Professor. Additional requirements are that the applicant must have a concentration in electrical
engineering in both teaching and research. The requisition must be approved by the Dean of Engineering, the
Academic Vice Chancellor East, and East Campus AA. The position is to be advertised in Black Issues in
Higher Education and the Chronicle of Higher Education. The position must be held open for at least three
weeks.
The University receives 5 applications as follows:
Dr. Louis Bright (male, Caucasian), PhD from NC State in electrical engineering, three years teaching at MTSU,
published two books, currently assistant professor, received one NSF grant
Dr. Davis Douglas (male, African American), PhD from Mississippi in engineering, two years teaching at TSU,
one publication, currently assistant professor
Dr. Delores David (female, Caucasian, over 40), PhD from UTK in engineering, one year teaching as an
instructor at UTK, no publications
Mr. David Masters (male, Caucasian), MS degree in electrical engineering from UTK, two years teaching as a
GTA at UTK, two publications with major professor
Dr. Jane Rogers (female, Caucasian), PhD from Vanderbilt in physics with minor in engineering, four years
teaching experience as assistant professor at University of Memphis, one publication, limited research
The Electrical Engineering Department decides to interview Dr. Bright and Dr. Rogers and initiates a request to
interview along with a summary of all applicants and their qualifications to East Campus AA with a copy to the
dean. The East Campus AA Office approves the candidate pool and the Electrical Engineering Department
interviews the candidates. They decide to hire Dr. Bright and get the appropriate approval from the East Campus
AA Office, the Dean of Engineering, and the Academic Vice Chancellor East.
Director of West Station: The West Station initiates a requisition to fill the director position and adds a
requirement that knowledge of agricultural extension activities is preferred. Later they decide to initiate a
request to West Campus AA and the Dean of Ag Experiment Station to hire an internal staff member without
advertising; they wish to promote from within. The internal candidate is Ms. Mary Barnes, Assistant Director in
the department of communications (working for the director) who has been employed since January 1, 1992 as a

full time regular employee at a salary of $37,000. The request is approved and the department makes the job
offer at $45,000. Ms. Barnes accepts the offer.
5.1.3.1 Demonstrate the tools available to aid in the recruitment and hiring described in the above situations.
5.1.3.2 Demonstrate the ability to automatically post approved openings via several methods to several locations
including campus electronic bulletin boards, University's Internet home page, and state job service centers.
5.1.3.3 Show the process for matching applicant skills to position requirements/skills. Also show the ability to
screen applications to determine that selection requirements are met. This may include eliminating applicants
who do not meet education, license requirements or training criteria, current employees on probation or former
employees terminated for cause.
5.1.3.4 Demonstrate how the software rank-orders applicants on specific user defined criteria (e.g., years of
experience, examination scores, etc.) and how a hiring department is provided with the applications, resumes,
and other documentation for qualified candidates.
5.1.3.5 Demonstrate ability to permit electronic capturing of ad hoc comments (including reasons for selection
and non-selection) and an on-line transaction history to track who did what and when.
5.1.3.6 Demonstrate how all units with active applicants could be notified if one of their applicants was hired in
another position or withdrew from consideration.
5.1.3.7 Demonstrate the approval process for personnel requisitions and the hiring decision.
5.1.3.8 Discuss how the system could accommodate exceptions to the hiring process.
5.1.3.9 Demonstrate how any HR/AA office can approve salaries for newly hired employees.
5.1.4 Employment and Employee Data Maintenance
After final approval occurs and an applicant is hired, the system automatically changes status of applicant to
employee, which automatically transfers all applicant data to employee database. Once the employee is hired,
the system automatically assigns an employee number that the employee uses to access the system. The
employee may access the system to enter his/her personal data including address information, marital status,
taxes, I-9, ADA information, and bank deposit authorization. The system will automatically provide benefits
eligibility information based on the employee's position. Where required, this information will be routed to
appropriate insurance and benefit carriers and financial institutions.
Whenever an employee's personal data is modified, the employee and department are to receive a confirmation
of the change(s) showing the effective date. Also, if any documents require the employee's signature, the system
generates hardcopies for employee signature.
Initial Employment Demonstration Data
Penny Piper/Steam-fitter: Penny Piper reports to an orientation meeting given by the East Campus HR Office on
her first day of work. The East Campus HR Office requests documentation of Mrs. Pipers eligibility to work.
Mrs. Piper is a citizen and tax resident of Canada. She provides her I-94 (INS document) showing her
immigration status as ATN@, along with a Social Security card with the restriction "eligible to work with INS
authorization only". At the same time, Mrs. Piper requests that her compensation be excluded from federal
income tax withholding in accordance with a tax treaty between theU.S. and Canada. The department head has
authorized a salary of $10.00 per hour paid biweekly. Because this is a regular full-time position, full benefits
are available. East Campus HR creates an employment record containing (at least) the following information:
Name
Home Phone
Job Title

Name Prefix
Home County
Position #

Home Address
SSN
FTE

Date of Birth
Marital Status
Citizen Country
Hire Date
Office County
Leave Accrual Rate
Disability Type
FLSA Category

Race
Birth State
Immigration Status
Office Address
ADA Indicator
Licenseure
Veteran Type
FML Indicator

Status:
Designation:
Category:
Tenure Status:
Tenure Date:
Tenure Review Date:
Tenure College:
Educational Level:

Active, terminated, leave of absence

Regular, term, student
Exempt, nonexempt, faculty, student
Tenured, on-track, ineligible
Date tenure received
Date of next review
College granting tenure
Highest level of education

Prior Leave Balances:

Leave from other state agencies

Regular Service Date:

Longevity Date:
Annual Leave Date:
Regular Continuous Service Date:
Original Employment Date:
Disclosure Authorization:
Sick Leave Bank Indicator:
Flex year Percent:
Admin Area:

Date to calculate total regular service with the University

Date to calculate total eligible service
Date to calculate advancement of accrual
Date to calculate total regular continuous service
Date first employed by the University
Level of information to be released
Participation in sick leave bank - yes/no
FTE for flex year employees
Department administratively responsible for the employee

Gender
Birth Country
Date Entered Country
Office Phone
Emergency Contact
Certifications, registrations
EEO Category
Direct Deposit

Louis Bright/Professor of Electrical Engineering: On August 1, 1998 Dr. Louis Bright is employed by the
Electrical Engineering Department as an Associate Professor in a tenure track position (to be reviewed for
tenure 5 years from the date of hire). This department requests documentation of Dr. Brights eligibility to work.
He is aU.S. citizen. The data fields mentioned above are populated. Dr. Bright is paid $5,000 per month equally
funded from two accounts paid on a monthly basis. His appointment requires that he teach only during the
academic year but his pay will be spread out over an entire 12-month period starting on August 1. Because of
this special pay schedule, he is eligible for full benefits but there will be no annual or sick leave accrual or
reporting. Dr. Bright requests that his pay be direct deposited into the local bank with $500 per month going into
a savings account and the remainder into a checking account.
Mary Barnes/Director West Station: The West Station promotes Ms. Barnes as of January 1, 1999 with an
increase to $45,000. The salary will be paid by two departments, as indicated by the position. A notice is
initiated to West Campus AA reporting the promotion and the employees race, sex, age, veteran status, handicap
status, EEO category, EEO job group, and salary.
Students: The Computer Science Department decides to hire Buffy Smith as a student worker to help with
clerical work around the office. A minimum of 15 hours per week is required and will be paid biweekly. The
hourly rate is $6.00. Because this is a student position, no leave or other benefits are available. I-9 certification
is required. A check of the student data base should be effected to verify enrollment by Ms. Smith.
5.1.4.1 Demonstrate how an employee can be direct-hired without a posting and show the minimum data
required.
5.1.4.2 Show how to automatically transfers all applicant data to employee database after hiring as well as
prompts for the addition of information not captured at the application stage (salary rate, account codes, etc.). In
addition, show how the system permits updates to information that has changed since the application was first
entered.

5.1.4.3 Using the employment decisions above, demonstrate how to perform the following functionality:

applicant information transfer to the employee records

creating an employee record

scanned documents attached to employee records (I-9, application, etc.)

approval of salary

creation of ID cards or name badges

flexibility of the direct deposit system

flexibility of the payment schedule

types of edits available to insure consistency among data fields

position tracking handling an overlap of employees in the same position

employee records created without linking to a position (i.e. students)

appointments from multiple campuses for one person maintained

Employee Data Maintenance Demonstration Data

Penny Piper: Penny Piper gets a divorce and needs to change her name prefix to "Ms.", drop her ex-husband
from her life insurance coverage, change her W-4 to one less dependent, and change her retirement beneficiary
to her child.
Louis Bright: Assume for this section:

Dr. Bright requests the following changes:

a) change home address

b) change name
c) change social security number
d) cancel optional life insurance effective at the end of the month
e) increase in participation of 401(k) to $100 per month

The Electrical Engineering Department:

a) promotes Dr. Bright to full professor with a pay increase of $12,000 per year effective June 1,1999
b) renews a grant funding half of Dr. Brights salary but needs to charge all future money to this new grant
effective March 1, 1999 (There are 20 people paid from this grant.)

c) grants Dr. Bright tenure as of June 1, 1999 (A notice should be generated to the Electrical Engineering
Department and East Campus HR concerning the change in tenure.)
Mary Barnes: Mary Barnes has an illness and is placed on Family Medical Leave. She has one month of sick
leave accrued but expects to be gone for approximately two months. During the second month Ms. Barnes sends
a check to the University for her monthly medical insurance premium. At the end of the second month, Ms.
Barnes returns to work.
Bobby Heisman: Assume for this section:

Bobby Heisman works in the West Campus Budget Office as a budget clerk, regular, full-time, annual
salary of $48,000.

Mr. Heisman requests a flex year appointment where he will work full time for 10 months of the year
but spread his payments over 12 months.

The West Campus Budget Office agrees and sets the new salary as $40,000 per year.

5.1.4.4 Demonstrate how employee history is established, changed and maintained for paid and unpaid
appointments.
5.1.4.5 Demonstrate the ability to handle future-dated transactions and the process that will flag the transactions
as active after the effective date has passed.
5.1.4.6 Demonstrate the ability to:

provide an event driven approach to employee data changes

customize these event driven processes

create and maintain user defined fields

support these fields and field values during a software upgrade

5.1.4.7 Show the ability to maintain multiple:

values in data fields, including multiple appointments, with different end dates and multiple payment
distributions

date fields to administer benefit plans and legal requirements

addresses, including full international addresses

effective dates for all types of employee actions, milestones, and eligibility attainments for all types
and categories of employees

position titles for one employee

Discuss the limitations of each of the above points.

5.1.4.8 Demonstrate the ability to reverse incorrect entries before and after they are applied (e.g., terminated
employee in error, cancellation of hire, perform reversal on a specific date, entry suspend and resume

capabilities, and approved status) and retroactively, automatically adjust any compensation and deduction for the
period in error.
5.1.4.9 Demonstrate the ability to monitor the number of hours worked in a specified time period, generate
automatic email to departments, and notify employees through earnings statements, with alert warnings for:

students working more than 20 hours per week in the academic year

students and non-exempts working more than 40 hours of straight time in a week

5.1.5 Benefits Administration

The University offers health, dental, basic life, optional life, accidental death, retirement, tax deferred annuities
(TDAs), University matching 401(k), flexible spending accounts and other optional insurance such as long term
disability to active employees at the University and external agencies. The primary health plan is self-insured.
Eligibility for benefits is based on several factors such as job class, percent of time employed, salaried versus
wage, and other insurance plan criteria.
Every eligible employee has the option of selecting premium-only plans and flexible benefit spending accounts.
Retirement plans are determined by the employee eligibility. Plans are administered by different agencies within
and outside the University.
Once every year the University changes some or all of the benefits plans. This change is done for the next year,
while processing for this year continues.
Benefits Administration Demonstration Data
Penny Piper: Penny Piper elects to participate in the State Retirement System (a defined benefit plan, see
formula Attachment F TCRS Defined Benefit Formula), the HMO available in her work county for group
medical coverage, the optional Long Term Disability Plan #3, and the Dental Plan # 2. Ms. Piper has one child
who should be included under the medical coverage. Calculate a projected retirement benefit for Ms. Piper when
she has 361 months of creditable service, an average final compensation of $35,000 and accumulated sick leave
of 12.6 months. The calculation should use a social security integration level of $31,200
Louis Bright: Dr. Bright elects to participate in the State Optional Retirement Plan with participation in both
TIAA/CREF (75%) and VALIC (25%), the Blue Cross (basic) medical coverage, and the optional Term life
insurance coverage. Dr. Bright is single with no dependents. Dr. Bright also elects to participate in a tax deferred
annuity of $400 per month and the medical reimbursement plan for $50 per month. Calculate a projected
retirement benefit for Dr. Bright at age 63, with a 61 year-old beneficiary. He needs to see the choices in benefits
for either a single life annuity, two-thirds benefit to survivor, full benefit to survivor, and half benefit to second
annuitant. He has an accumulation of $325,000 in a fixed annuity earning an assumed 7%, $500,000 in a
variable annuity earning an assumed 9%.
Mary Barnes: Due to her promotion, Ms. Barnes elects to increase her tax deferred annuity from $50 to $100
per month. She also decides to begin contributing to the Alumni program at $10 per month. Ms. Barnes also
elects to participate in the West Campus sick leave bank requiring an initial contribution of 24 hours.
Bill Rogers: Bill Rogers has been with the University for 17 years, earns $65,000 per year, has $87,250 in prior
deferrals and contributions for a 403(b) plan. Compute the tax deferred limits for Mr. Rogers. Also, calculate the
maximum deferrals for his participation in a 401(k), 457, and 403(b), or any combination of the three.
Federal Employee #1: Calculate a retirement estimate for a federal civil service employee with 31 years of
service and age 62 and a high three years of $65,000.

Federal Employee #2: Calculate a retirement estimate for a federal employee with 31 years of service, age 62,
with $200,000 in the Thrift Savings Plan (high three years of $65,000) based on all the employee/employer
matches. Also calculate the amounts this individual could defer in the Thrift Savings Plan under each
employee/employer match.
5.1.5.1 Demonstrate how the following benefit plan information is established and maintained:

plan date and year per benefit

plan eligibility requirements

plan carrier

plan cost per employee / employer

plan cost per dependent

plan employee/employer contribution

plan hours worked

plan coverage level and type

tax treatment of employee paid premiums (reduction vs. deduction)

5.1.5.2 Demonstrate the ability to make a mass change to the benefit rates.
5.1.5.3 Demonstrate how the following employee information is established and maintained:

employee age

employee salary

derived benefits salary

employee plan eligibility date

employee initial set enrollment date

employee rolling enrollment date

employee declined date

employee prior notification date

spouse name

spouse gender

spouse SSN

spouse birth date

spouse benefit plan

spouse Primary Care Provider (PCP)

coverage start and end dates

premium start and end dates

benefits historical data

identification of department-paid employee benefits

date retired

third-party administrator supplied information

multiple iterations of the following:

o child(ren) name
o child(ren) birth date
o student Status
o incapacitated (Y/N)

multiple iterations of the following:

o beneficiary name for life insurance (multiple plans)

o beneficiary name for 403(b), 457, 401(k) plans
o beneficiary name for death benefits
o beneficiary detailed information (e.g. address, phone)
5.1.5.4 An employee's eligibility for benefits may change as the employee changes positions and/or status.
Demonstrate what would happen if an employee changes position so that he/she is eligible for a different benefit
plan (i.e. retirement, long term care, etc.).
5.1.5.5 If both spouses are University employees, they are eligible for reduced health insurance premiums.
Demonstrate how the separation of one spouse employee will automatically trigger the change in eligibility for
the other employee.
5.1.5.6 Demonstrate the automatic feed to payroll for benefit deductions (both employee and employer).

5.1.5.7 Demonstrate how the selection of a retroactive change in health coverage is reflected in the benefits
system.
5.1.5.8 Demonstrate how the retroactive change in health coverage plans is passed to payroll for a retroactive
change in health coverage premiums.
5.1.5.9 Demonstrate how employees can enroll or change benefit options electronically.
5.1.5.10 Show how benefits can be restricted to qualified employees.
5.1.5.11 Demonstrate what information is available to employees describing their current coverages.
5.1.5.12 Demonstrate how confirmation of enrollment or changes in enrollment are routed to the employee.
5.1.5.13 Demonstrate how employees access the Web to enroll during open enrollment, make a change and/or
view benefits at any time during the year.
5.1.5.14 Demonstrate how next year and this year changes are processed so they apply to the correct year.
5.1.5.15 Show how the following are established and maintained:

separate employee compensation accumulators for each benefit plan

separate employee hours of service accumulators for each benefit plan

TDA option

TDA type

MEA amount

SRA date

15-year date

5.1.5.16 Demonstrate the employees ability to "model" different retirement scenarios, including various
retirement dates, various beneficiary options, and various accumulations.
5.1.5.17 Demonstrate the employees ability to determine the effect of varying tax deferred amounts and
programs on net income as selected by the employee.
5.1.5.18 Demonstrate how to allow employees to update benefits and other required personnel forms applicable
to the employee. This should include providing descriptions of benefit plans and ability to print or email
required forms based on user definitions.
5.1.6 Compensation Management
The University compensation programs use two job evaluation plans. Job sizes are determined based on the
duties of the position. Pay ranges, however, are developed by grade level for non-exempt and by position for
exempt and faculty jobs. There are separate pay ranges for some campus/units as well as exceptional pay ranges
for certain types of jobs within a campus/unit.
5.1.6.1 Demonstrate how multiple pay plans and pay ranges can be implemented.

5.1.6.2 Demonstrate on-line how the system enables administrators from different campuses/units access to the
records of a single employee across campuses/units, make changes to the record (including changes of FTE,
dollars paid, etc.), and seek appropriate approvals for the changes.
5.1.6.3 Demonstrate how a 3% across-the-board increase for all non-student employees could be applied.
5.1.6.4 Demonstrate how the system checks an hourly salary rate against minimum wage requirements and
determines to reject the salary or accept and print a notice to that effect.
5.1.6.5 Verify that the pay rate is within the appropriate salary range for that position and generate notices if that
is not the case.
5.1.6.6 Demonstrate how to develop cost projections for a percentage increase in the salary schedule and/or an
increase in overall pay by a percentage rate, dollars per hour, fixed amount, or percentage by grade level.
5.1.6.7 Demonstrate how salary ranges are adjusted, and how campuses/units and job titles can have different
salary ranges.
5.1.6.8 Demonstrate how the system handles someone laterally transferring (same job title) from one campus to
another that uses a different set of pay ranges for that job.
5.1.7 Non-Resident Alien Processing
The University employs a variety of non-resident aliens including faculty, staff, students, and
fellowship/traineeship candidates (both degree and non-degree). Non-resident aliens are subject to special
taxation and reporting rules and may be subject to provisions of a tax treaty.
Payments issued by the University including tuition and fee waivers, fellowships and scholarships, paid through
financial aid or accounts payable are also subject to special taxation and reporting rules. The same applies to
independent contractor payments.
Regardless of the office issuing a payment to a non-resident, the system must track the individuals and
incorporate any payment information into the monthly and year-end non-resident alien tax reporting and
determination of residency status for tax purposes.
5.1.7.1 Describe how to handle the collection and monitoring of data for all non-US citizen students, employees
and other payees including the ability to maintain tax treaty tables, with effective dates for all tax code changes.
5.1.7.2 Describe the ability to recognize the dollar and time limitations of tax treaties when excluding income
from withholding.
5.1.7.3 Describe the ability to withhold required taxes from fellowship payments not required of like payments
to U.S. citizens.
5.1.7.4 Describe the ability to report payments to non-resident aliens using IRS Forms W-2 and 1042-S.
5.1.7.5 Demonstrate how the system maintains a history of visa documents and dates and notifies departments
upon expiration of documents.
5.1.8 Deductions
Deductions to an employee's pay can be established by departments (i.e. parking fees, employee debts) or by the
employee (i.e. charitable contributions such as the United Giving, credit unions, additional FIT withholding).
5.1.8.1 Demonstrate the creation and maintenance of deductions, including the following range of functionality:

unique taxation definitions (e.g. 403(b), flex spending accounts, health insurance)

flat-dollar amounts (e.g. parking & United Way)

deductions based as a percent of selected earnings types (LTD, retirement)

capability to establish a declining balance deduction and a specific amount each month that
automatically stops when the balance is zero (e.g. computer purchase, accounts receivables)

calculation of deductions based on specific earnings types

one-time deductions or one-time overrides to deductions

ability to define a provider for a specific deduction type for remittance

5.1.8.2 Demonstrate capabilities to establish start/stop dates for deductions (e.g. United Way, Flex), to establish
ceilings for deductions and have the system automatically stop the deduction when it is reached (e.g.
garnishments), and to set up a deduction with appropriate future effective dating (e.g. new health insurance plan
year).
5.1.8.3 Show how retroactive deductions to salary are handled including both additional deduction amounts and
refunds and show how employee balances and departmental ledgers are automatically adjusted
5.1.8.4 Demonstrate the system's flexibility for placing deductions in arrears or recycling, including:

"automatic" arrears for insufficient pay (reduced hours) or no pay

taking arrears amounts in next pay cycle, and the cancellation of arrears upon "catch-up"

ability to select which deductions are put into arrears and how those are handled for full, partial or no
arrears applicability

ability to send billing notices to employees who have not remitted premiums

5.1.8.5 Show how the system handles deductions that are prepaid.
5.1.8.6 Show how to handle garnishments, wage assignments, tax levies, or child support and be able to reprioritize the pre-determined deduction priorities:

prioritization of deductions

calculation of correct amount to "back into" required net pay

entry of limit or ceiling amounts

simultaneous multiple garnishments

effective date functionality

percentage of disposable income or net pay needs to be definable

retention of garnishment/wage assignment history

handling of administrative fees

5.2 Payroll Processes

A new payroll system will require the ability to enter and maintain payroll information from many departments
on multiple campuses. The system will be required to provide concurrent use of multiple pay periods.
The University offers a wide and diverse choice of payroll deductions. Individuals may hold multiple
appointments concurrently: faculty, non-exempt staff, student, or any combination thereof, which may require
different withholdings in the same or different pay cycles.
5.2.1 Time and Attendance Reporting
The current time entry and leave system is designed to process time worked and/or leaves taken for employees.
All time worked for non-exempt employees and overtime worked is reported on time sheets by day. These
reported hours worked are processed through payroll resulting in the production of paychecks for the
employees.
Leave taken by monthly paid employees is reported monthly and approved by the departments. This leave taken
is processed through the leave system resulting in the appropriation of leave accruals and leave balances.
Currently, the leave system handles in excess of ten different types of leaves.
5.2.1.1 Enter a non-exempt employee's work hours information on-line and real-time. Demonstrate the ability to
generate time automatically based on a work schedule. Include a review of the following functionality:

ability to handle varying schedules

on-line validation of leave balances

real-time updates to database

ability to sum all hours entered for an employee for overtime calculation regardless of the location of
entry

segregated components of pay (e.g. straight time vs. overtime)

multiple types of shift codes, each with an associated rate

ability to override account (labor) distribution of any special pay

ability to add special pay including earnings types, funding sources, hours, and dollars

multiple entry sites (i.e., primary timekeeper location and alternative or backup locations)

automatic indication of default hours (to reduce amount of entry if no deviation)

ability to distribute time among as many jobs, projects and departments as required

capacity to handle a time sheet on-line and be routed for appropriate approvals, notifying the person
when request is waiting for approval

acceptance time through interfacing with 3rd party collection systems (KRONOS)

ability for employee to electronically sign the time report

ability to route the time report to a supervisor who will also electronically approve the time report

validation of available amounts of sick and vacation time

ability to revert to other types of leaves when balances are not sufficient to cover time (i.e., if an
employee does not have sufficient sick leave, then it is automatically converted to comp then to annual)
and notify the employee of this reversion

5.2.1.2 Illustrate how leave balances are maintained based on time and/or status of the employee for the
following:

ability to maintain records of vacation, personal time, sick leave, military leave, educational leave, jury
duty, funeral leave and other paid leave used in accordance with University policies

automatically accrue leave earned based on a calculation algorithm reflecting the leave earning policies

ability to transfer leave balances to following year based on carry over rules

generation and sending of notices to employee regarding changes or other information

display of leave balances on the time entry screen

retroactive leave processing

leave reversion based on defined leave substitutions (e.g. no sick leave reverts to vacation)

leave with time restriction for use (personal day lost if not used)

leave with set maximum hour restriction per event

5.2.1.3 Demonstrate how to access and track hours worked. Briefly discuss how the rules for time reporting are
maintained.
5.2.1.4 Show how the system would handle changes to time reporting data for both normal entry and corrective
entries.
5.2.1.5 Demonstration the ability to define and handle multiple alternative work week schedules.
5.2.1.6 Show how Family and Medical Leave Act (FMLA) information is stored for multiple occurrences in a
year and how eligibility for FMLA is based on hours worked in the prior year.

5.2.1.7 Demonstrate how multiple types of leave can be tracked concurrently with FMLA.
5.2.2 Payroll Cycles
Monthly Payroll: The last working day of each month is the payday for monthly paid employees. These
employees are paid by exception: the scheduled amount is paid unless an adjustment is manually entered to add
to or subtract from this amount. The scheduled amount is automatically prorated as a ratio of the number of
week days (Monday - Friday) employed to the total number of week days in the month.
Assume for this section:

The University has hired Bill Smith as a new monthly employee effective January 10th, paid at a rate
of $1,000 per month. This non-exempt employee will accrue annual leave at 12 hours per month and
sick leave at 8 hours per month.

Mr. Smith worked 43 hours during his first week and must receive an overtime premium for three
hours.

Dr. Bright is to receive an additional $3000 for other services.

Dr. Bright purchased season football tickets and incurred $75.00 as a taxable fringe benefit.

Dr. Bright was paid $300 ($250 net of withholding and FICA) on January 3rd by a hand written check
due to a system failure during December. This $300 is compensation and must be included in W-2
reporting.

Dr. Bright participates in the medical reimbursement spending account program and has a
reimbursement due of $45.00.

Ms. Barnes worked a normal month.

5.2.2.1 Demonstrate the steps necessary to process a monthly payroll for January paying Dr. Bright, Mr. Smith,
and Ms. Barnes.
5.2.2.2 Demonstrate the system checks and balances available to insure the total amount to be paid is correct.
5.2.2.3 Demonstrate how fringe benefit values from external sources may be entered into the payroll process.
5.2.2.4 Demonstrate how the flex spending account reimbursements may be entered into the payroll process.
5.2.2.5 Show the leave accrual calculation based on the amount of service during the month.
5.2.2.6 Show the financial transactions generated as a result of this payroll including both accounts and object
codes.
5.2.2.7 Show the accumulation of "creditable service" for benefit purposes.
5.2.2.8 Demonstrate the entry and calculation of pay adjustment for overtime.
Biweekly Payroll: The biweekly work week ends on every other Sunday with payday following 9 days later on
Tuesday. These employees are paid by positive entry and the leave accruals are based on the time worked.
Assume for this section:

Penny Piper worked 38 hours (30 worked, 8 sick) in the first week and 48 hours (48 worked) in the
second week. These extra 8 hours were for working a second shift that entitles her to a 5% shift
differential.

Penny Piper received ten meals during the two-week period furnished by the University. The value of
these meals was $1 each for purposes of overtime calculation and was not considered taxable fringe
benefits.

Ms. Piper received five units of call pay (at $3 per unit) due to being on call during the first week.

Three additional hours that were inadvertently omitted from the prior pay period were reported for Ms.
Piper. Originally 40 hours were reported for that week.

Ms. Piper would like to "bank" four of her overtime hours for future use rather than be paid for them.
These hours should be inflated by the overtime rate (1.5) so that she has 6 hours available for future
use.

Buffy Smith worked 15 hours in the first week and 12 hours in the second week.

5.2.2.9 Demonstrate the steps necessary to produce a biweekly payroll paying Penny Piper and Buffy Smith.
5.2.2.10 Demonstrate the entry of time and leave by employee or departmental bookkeeper
5.2.2.11 Demonstrate the banking of overtime for future use
5.2.2.12 Demonstrate the treatment of retroactive hours reported, including tax withholding
Longevity Payroll: The University pays an annual longevity payment to each eligible employee during their
anniversary month. The payment equals $100 per year of eligible service.
Assume for this section:

Penny Pincher was hired on January 14, 1994 and is eligible for longevity. Ms. Pincher had prior
service with another state agency equaling 3 years. Ms. Pincher is due for a payment of $800 (8 years
@ $100) in January 1999.

5.2.2.13 Demonstrate the steps necessary to produce a longevity payroll for the month of January paying Penny
Pincher and Mary Barnes.
5.2.2.14 Federal Wage and Hour Regulations require the inclusion of employee bonuses when calculating wage
rates for overtime purposes. The University's longevity bonus is paid annually and therefore we must recompute
any overtime premium paid to non-exempt employees during the period covered by the bonus payment. Discuss
how to track the overtime hours paid to an employee and calculate this adjustment.
On-Demand Payroll: The University must generate "off-cycle" paychecks occasionally for various reasons.
The deductions applicable to the employees normal pay cycle should be considered.
Assume for this section:

Hours worked were erroneously omitted for Bill Smith during the last biweekly payroll. He should
have been paid for 80 hours (72 worked, 8 annual) at $9.00 per hour. The last biweekly was the second
biweekly of the month where parking and medical insurance would have been deducted.

5.2.2.15 Demonstrate the steps necessary to produce a payroll check for Mark Adams processing the appropriate
deductions.
5.2.2.16 Demonstrate the handing of deductions, accruals, etc attributable to the pay cycle missed.
5.2.2.17 Show how this payment is represented in the payroll history.
Weekly Payroll: The University generates fifty to one hundred paychecks each week for persons of short-term
employment. These employees do not go through the traditional recruitment or hiring process and are paid on an
"as worked" basis with no optional deductions or benefits.
Assume for this section:

Betty Short worked as an usher at our arena during several basketball games. She worked 3 hours on
Tuesday and 3 hours on Thursday.

Ms. Short is to be paid $6 per hour.

Ms. Short should not be considered an active employee of the University, is not eligible for any
benefits, and may not participate in direct deposit.

5.2.2.19 Demonstrate the steps necessary to produce a payroll for Betty Short.
Check Cancellations: Checks and advises are often returned by departments because employees may have
terminated or were otherwise paid incorrectly.
Assume for this section:

Dr. Bright was paid his scheduled pay in February. He actually went on leave of absence effective
February 1, and therefore was not due the payment. The department returned the direct deposit advice
to the payroll office with a note of explanation.

5.2.2.20 Cancel the February payment to Dr. Bright reversing all deductions and generating the appropriate
accounting entries.
5.2.2.21 Show the financial transactions generated as a result of this payroll including both accounts and object
codes.
5.2.2.22 Show the effect of a cancellation on benefits and deferral limitations.
Salary Transfer Vouchers: Some employees work on multiple projects during a pay period. Because the actual
time spent is not always known prior to processing the payroll, the appropriate charges (and benefits) must be
distributed to the correct accounts after the fact and related ledger entries generated to reflect this distribution.
Assume for this section:

Dr. Bright was paid his scheduled pay in January. Besides his teaching duties, he performed 4 hours of
work on an electrical engineering research contract and 6 hours of work on a math research contract.

5.2.2.23 Demonstrate how the Electrical Engineering Department may correctly charge the research accounts
for the wage expense and the related benefits.
5.2.3 Payroll Processing and Check/Advice Production

5.2.3.1 Demonstrate the interfacing with the General Ledger system to show:

the ability to charge the costs of an employees staff benefits to different general ledger accounts than
the cost of the employees pay

the ability to identify expense accounting (object) codes and distribution by earnings type

the ability to report on vacation liability for journal entries to the accounting system

the ability to retain the accounting data with the payroll history in order to prevent discrepancies
between payroll and accounting

support for the encumbrance and accrual processes (9-month employees paid over 12 months, crossing
a fiscal year)

5.2.3.2 Explain and demonstrate the payment generation process including:

validation of routing/transit numbers for new direct deposit requests

the ability to handle multiple direct deposit splits

customizable check/advice stubs that list detailed pay types, taxes, deductions, etc.

check/advice messages that can vary by employee type, campus/unit, employee classification, tax
status, etc.

check/advice stubs that can be printed for zero net payments

the ability to add any pay or benefit field to the earnings statements

payment advice that an be sent via letter, e-mail or posted to a web site

printing of one-time information messages on payment advice that can vary by employee type

5.2.4 Deduction Remittance

Funds deducted from employee paychecks must be remitted periodically. The remittance will be either a
disbursement to an outside entity or a journal voucher to credit a University account(s). Depending on the
deduction, the remittance may take place after each payroll or may be done at the end of a month.
Assume for this section:

Dr. Bright has:

o a contribution for the State Optional Retirement Plan equaling 10% of his pay eligible for
retirement

o basic family medical coverage (plus employer contribution)

o optional life insurance

o parking deduction for type 10 parking (18.00 per month)

o a computer deduction of $75.00 with a balance of $750.00
o a 401(k) reduction of $50 matched by the University up to $240 per fiscal year
o appropriate FICA and FIT withholding
o a garnishment of 10% of disposable income for a student loan

Dr. Bright was over deferred by $100 for 1998. The annuity company returned the funds to the
University.

5.2.4.1 Demonstrate how the system calculates and processes these deductions for the January monthly payroll.
Demonstrate how the prior year over deferral can be recognized and the University records corrected so that the
proper tax reporting may occur.
5.2.4.2 Show how funds are credited to University accounts based on attributes of the employee (for example,
campus parking).
5.2.4.3 Demonstrate the capabilities for remitting funds and creating detail reports/files (child support, annuities,
etc).
5.2.4.4 Demonstrate capability to interface to accounts payable for creation of third party checks or EFT
transmissions.
5.3 Miscellaneous Items
5.3.1 Encumbrances
Encumbrances for employee salaries are typically created at the beginning of the fiscal year and when new
employees are hired. The current values will change due to payments, changes in pay rates, and employee
terminations.
5.3.1.1 Discuss how to calculate encumbrances for salaries and what actions within the system effect those
values.
5.3.2 Termination of Employment
Termination of Employee Demonstration Data
Mary Barnes: Ms. Barnes resigns to take another position with Tennessee Tech. The termination is effective
February 28, 1999 with a reason of "Transfer to State Agency". Multiple campus offices including West Campus
HR, System Payroll, and various Auxiliaries need to be alerted to verify that Ms. Barnes does not owe any
money. Ms. Barnes final payment should not be made until this verification has occurred. Ms. Barnes and
Auxiliaries should also be notified that prior to her last day of work she should return any keys and parking
permits to those offices.
Auxiliaries respond that Ms. Barnes owes $200 as the balance of a computer purchase.
Bill Rogers: Dr. Rogers, a longtime administrator, passes away on March 15, 1999. His department processes
the termination and initiates the request for the benefits due upon death of an employee. Dr. Rogers earned
$60,000 per year and had 48 hours of annual leave and 300 hours of sick leave at the time of his death.

Additionally, the employees beneficiary is eligible for life insurance benefits and paid health insurance
premiums for six months.
The March monthly payroll should pay Dr. Rogers for the time between March 1, 1999 and March 15, 1999, as
well as the unused annual leave (see Attachment G Employee Death Benefits Formula).
5.3.2.1 Demonstrate how the debt owed by Ms. Barnes is transferred to System Payroll and deducted from her
final paycheck.
5.3.2.1 Demonstrate how the department could initiate the request for Dr. Rogers death benefit to be paid to his
estate or beneficiary. Identify all benefits due to the decedents family or estate.
5.3.2.2 Show what historical data is maintained for terminated employees.
5.3.2.3 Demonstrate the effect of a termination in the position tracking system.
5.3.3 Reporting
5.3.3.1 Generate a notice to the Physical Plant and East Campus HR six weeks after Penny Pipers hire date
stating that the probationary period will expire three months after her continuous service date.
5.3.3.2 Demonstrate the softwares end user query tool for ad hoc reporting.
5.3.3.3 Demonstrate the ability to report historical payment information.
5.3.3.4 Demonstrate the ability to report historical employment information.
5.3.3.5 Provide a list of all employees receiving tenure status between July 1, 1998 and June 30, 1999.
5.3.3.6 Generate a summary report of information about Mary Barnes. This should include Name, SSN,
Termination date and reason, current benefits, leave balances, longevity date, employment date(s), employment
history, FTE, and employment status.
5.3.3.7 Generate an EEO6 report with all current employees. Generate an EEO6 report with all applicants by
position applied for.
5.3.3.8 Generate a summary report of active employee headcount and FTE by category (exempt, nonexempt,
faculty) within campus (attribute of responsible area).
5.3.3.9 Produce a report of like job titles by campus, giving salary, longevity pay, total pay, and computing the
average rate of pay for that job title within each campus.
5.3.4 Federal Tax Reporting
The University must report annually to the Internal Revenue Service all payments for compensation,
independent services, and scholarships to non-resident aliens. Our current system combines all such payments
into a common file from which several different IRS forms are produced (W-2, 1099, 1042-S, etc).
5.3.4.1 Discuss how to store the information necessary to accomplish the various types of reporting required.
5.3.4.2 Discuss the method used to produce the various forms required for reporting.
5.3.4.3 Discuss the method used to produce the various electronic files required for reporting.
5.3.4.4 Discuss how changes to information may be recognized and forms reprinted.

5.3.4.5 Discuss how information from outside entities may be incorporated into the reporting process. Examples
of this include imputed income from employee life insurance policies and fee waivers granted by other state
schools to our employees.
5.3.5 System Integration
5.3.5.1 Demonstrate the ability to view a payroll charge (in summary) to a general ledger account. Drill down
from there to see the detail supporting that charge.
5.3.5.2 View a historical payment within the Payroll system. Demonstrate how a manager can drill up to see the
summary charge to a ledger account.
5.3.5.3 Demonstrate the systems flexibility in viewing all types of employee data including employment
history, payroll history, benefits history, etc.
5.4 Employee Development and Training
The system should support the ability to capture information to assist in the professional development of
employees. This includes the monthly notification and follow-up to department heads and HR offices of the
annual employee performance review, the specification of required training based on position, and recording of
training received.
5.4.1 Performance Management
5.4.1.1 Demonstrate how department heads are notified monthly of all employees who are due an annual
performance review, based either on an employees anniversary date or on a fixed annual cycle. Generate
follow-up notices if the review is not completed within three months from the notification.
5.4.1.2 Show how the system will allow a department head to enter a customized performance review on each
employee.
5.4.1.3 Describe how the system allows the entry of planned training activities for each employee based on the
annual performance review or at any other times of the year.
5.4.2 Training
5.4.2.1 Demonstrate how the system can establish generic training profiles by job classification, position
number or other attribute, such as department or duration in current position.
5.4.2.2 Show how a manager can define the training requirements of a position based on unique department
needs.
5.4.2.3 Given that an employee has a target date to complete certain training programs, show how the software
notifies an employee and the supervisor that the employee has or has not scheduled or completed required
training.
5.4.2.4 Show how an employees training and class work is recorded and tracked for the employee, for the
supervisor, and for departmental and University statistics.
5.4.2.5 Show how the Susan Smith in the Math Department can register for a class in Word that is offered by
Campus East HR. Verify that she is an active employee and her department has available funds in its budget.
5.4.3 Career Development
5.4.3.1 Show how the system documents the training classes and professional skills that are suggested and/or
required for a person to become qualified for a particular position or job classification.

5.4.3.2 Indicate how an employee, department head and/or HR can establish a career plan for an employee and
provide a process for status reporting as to the completion of the plan.
5.4.3.3 Demonstrate how the system identifies the personal skills needed by an employee; identify what classes
have been taken; and project further training requirements the employee should acquire based on the employees
chosen career path.

6. Reporting and Technical Demonstration Scripts

6.1 Reporting and Technical Issues Script
6.1.1 Imaging
An ultimate objective of the University is to minimize the handling and routing of paper-based information
associated with the operation of its administrative systems. For this reason, the University is seeking to
understand how vendors have embedded/integrated imaging applications into their administrative systems in
areas such as invoices, personnel actions, technical specifications, receiving, etc. The imaging capabilities
would include, but not be limited to automatic scanning, indexing and linking paper-based documents to specific
application transactions, workflow routings, screens, panels, or other document images.
6.1.1.1 Describe the capabilities for integrating images and imaging products with the various system processing
functions.
6.1.2 Ad Hoc Reporting
University staff desires the ability to generate reports on an "as-needed" basis representing a query not part of
the regular, "routine" reporting specifications. The University seeks solutions that allow the same query tools
and reporting software to be used across all modules of the system.
The Dean of Engineering wants to produce a report comparing budgeted dollars and actual expenditures from all
sources for all departments in the school. The report should contain the actual budget expenses from the
beginning of the fiscal year for each department showing expense code items and dollar amounts sorted by
expense code.
6.1.2.1 Demonstrate the ability to enter necessary selection criteria to create the report. Show how to view the
report, save the report for future reference, and save the inquiry for future rerun. Print the report at the local
printer and the printer in the Dean of Engineerings office.
6.1.2.2 Demonstrate formatting options for printing the resulting report or exporting to a word processing or
spreadsheet file.
6.1.2.3 Demonstrate how the report can be stored electronically and retrieved at a later date.
6.1.2.4 Demonstrate the ability to generate a report from a point-in-time data warehouse.
The Engineering Department decides this report is required on a regular basis and should be routed to a number
of different individuals.
6.1.2.5 Demonstrate the ability to send the report to a group of individuals over e-mail for review.
6.1.2.6 Show how to run the report in real-time or on a defined schedule (e.g. every two weeks) and be able to
stop or cancel the creation of the report if it becomes a runaway report consuming the processing capabilities of
the system and tying up all other processing.
6.1.2.7 Demonstrate how to define user security for each set of reports.

6.1.2.8 Create a bar chart showing total budget and actual expenditures for each department. Show the ability to
drill down from summary information to the detail.
6.1.2.9 Add a sticky note to a set of reports.
6.1.2.10 Modify the report distribution list to add a new recipient.
The Dean of Engineering wants the system to automatically send an e-mail notification that the reports have
been sent to each department for verification based upon parameters that have been previously defined.
6.1.2.11 Demonstrate how to set up rules for automatic notification for report distribution.
6.1.3 Import / Export Data
The University is committed to decreasing the cost and effort of acquiring, managing, maintaining, and
presenting administrative data while improving the timeliness of information it provides. A key strategy for
accomplishing these objectives is to replace its enterprise-wide applications with an integrated set of
applications that allow transactions to be entered once and be reflected in all appropriate modules in the system.
While this strategy should reduce the need for shadow applications in departments, some of these individually
maintained applications will likely be needed to supplement capabilities of the enterprise-wide applications. The
University, therefore, needs the ability to interface the new central applications with these departmentmaintained, supplemental applications.
The University will need to interface the new systems with existing systems and will want to use office products
to enter some data. Demonstrate or explain the ability to provide pre-designed application programming
interfaces (API's) that allow for bi-directional data links so that existing systems can utilize the new systems
information for validation and integrity. Examples would include the need to check for a valid fund or account
code and the need to validate a vendor or employee. Possible API's might provide the ability to call a program
that performs the validation and returns a response code. This facility should accept both interactive and batch
feeds of data that can be validated concurrent to the upload process.
6.1.3.1 Demonstrate the ability to produce a report that combines data from the enterprise-wide application with
data from a department's supplemental application.
6.1.3.2 Demonstrate how data from the enterprise-wide application can be downloaded to office automation
products for modification and analysis. How can this information then be uploaded to system files? What
security exists for this process?
6.1.3.3 Demonstrate the capability to import/export and cut/paste a journal entry to and from a spreadsheet
application.
6.1.4 Web-based Transactions
Due to the growth of the Internet, including the Web, the University is interested in understanding what
capabilities the software has for processing transactions over the Internet. In addition, the University is
interested in using Electronic Data Interchange (EDI) and Electronic Funds Transfer (EFT) to eliminate paperbased transactions with key suppliers (banks, benefits plans) and governmental agencies. These applications
could include remote data entry by university employees, customer access to University data and functions, and
supplier integration with purchasing.
Current Support Plans
6.1.4.1 Demonstrate the current capabilities and describe any plans for supporting Internet and Web
applications. Include plans and capabilities to provide secure Web-based transactions including authentication
and electronic signatures.

6.1.4.2 Show how data transfers (i.e., benefits plan enrollment changes, etc.) are currently supported via
electronic commerce, including the initiation of the transaction by the employee via the web through to updating
the plan provider.
6.1.5 Help Features
The University would like to put its policies and user documentation in the "help section" of the system.
Additionally, it needs to provide users with online access to context sensitive help information to facilitate
system use. Policies, user documentation and other help information should be accessible in the same manner
across all modules of the system.
6.1.5.1 Demonstrate the ability to set up policy help, user documentation and other help information. Show how
personnel can easily access these policies across UT. Show how the responsible units can maintain the
documentation.
6.1.5.2 Demonstrate how personnel can use the help feature to access information such as allowable values for a
given field. Show the error message and help information provided when a person enters incorrect data.
6.1.5.3 Show the commonality of help information access across all the modules of the system.
6.1.6 System Tools
The University must be able to easily modify business rules, screens and other data items to meet its business
needs without compromising system maintainability, to extend the functionality of the system to meet unique
needs, to manage the computing environment effectively and efficiently, and to both import and export system
data for legacy system integration, data warehousing and conversion purposes.
6.1.6.1 Briefly demonstrate the tools and technologies provided that enable the University to tailor the
functionality of the system to its business needs.
6.1.6.2 Briefly demonstrate the tools and technologies provided enabling the University to manage its
computing environment (system performance, job scheduling, change management, etc.).
6.1.6.3 Briefly demonstrate the tools and technologies provided that enable the University to import and export
system data for legacy system integration and warehousing.
6.1.7 Warehousing and Decision Support
The University intends to make finding data much easier in the future. Part of this effort is to provide drill-down
functionality to glean supporting data from the same or related applications. The University wants drill-down
options to show supporting details for summary data as well as supporting data in related application data
Additionally, the University intends to offer the ability to query data where needed to develop University
strategies and support the decision making process. The most likely method for supporting this function is the
development and maintenance of a Data Warehouse that contains point-in-time data on which decision can be
based. The University desires a simple to use query support tool that provides various easy to understand reports
in graph form along with the raw data in summarized form if requested.
Executive Management Information
The executives at the University want ready access to enterprise-wide information, with the ability to drill down
to individual transactions.
6.1.7.1 Discuss your concept of a data warehouse and the tools you provide to create, maintain, and access data.

6.1.7.2 Demonstrate an executive information system or data warehouse that is tailored to higher education
needs and that provides a "dashboard" of enterprise-wide (defined as a summarization of all university divisions,
schools, and campuses) indicators such as the following:

program profitability

research profitability

research achievements

administrative effectiveness

institutional development

space utilization

6.1.7.3 Demonstrate the ability to drill down from these general indicators into these areas of interest:

change in net assets

value of the Universitys endowment

value of all real property (land, buildings, and equipment)

cash invested

cash not invested (idle cash)

sponsored programs awards by sponsor and by school and/or department,

human resources information, separately and totaled, for faculty, classified, and wage employees, as
follows:

o headcount
o FTE
o dollars expended (last year, budget for this year, year to date, and projected for this year)

accounts receivables, inventories, and other accruals

6.1.8 System Architecture

The University desires to implement its systems on a current, state-of-the-art computing architecture that
performs efficiently and is cost effective, reliable, scalable and secure.
6.1.8.1 Show how the system is architected to specifically address flexibility, scalability, reliability, and
response time. Also, show how this architecture is universally accepted as a standard.

6.1.8.2 Show how the system makes efficient use of available network bandwidth when supporting a large
distributed user population.
6.1.8.3 Show how to install and maintain the client machines to effectively use the system. (This part can be
done off-line with the PC support personnel.)

7. Glossary of Terms
The following glossary is provided to aid the vendors in interpreting certain terms contained in these
demonstration scripts that may carry a meaning peculiar to The University of Tennessee.
Account An account is used to associate financial activity with a departmental or campus purpose. The nature
of the financial activity is recorded within an account using one of three types of classification codes specific to
the account type (expense, revenue, balance sheet). For example, the English Department would have its own
account to accumulate expenditures by classification codes for salaries, supplies, equipment, etc.
Account Group A set of account or sub-accounts designated by one identifying name. This may be used to
request reports, or for other purposes as appropriate. The accounts in the set may be of the same type (all
expense or all revenue for consolidation) or related revenue and expense accounts to produce an income
statement type report.
Account Number A number assigned by the University for recording and processing financial activity. This
may be unstructured or structured such that digits in certain positions have meaning; for example, a budget
entity.
Activity Code see Ledger Activity Code.
Auxiliary An entity that exists to furnish a service to students, faculty, or staff and changes a fee directly
related to although not necessarily equal to the cost of the service; managed as essentially self-supporting.
Balance Sheet Account An account that appears on the balance sheet as an asset, liability, or fund balance
account.
Base Budget Budget that is the starting point for developing the budget for the upcoming year.
Base Salary Budget Budget that represents the initial file from which the salary budget for the upcoming
fiscal year will be developed.
Blanket Purchase Order (BPO) A purchase order for a variable quantity of one or more items over a
specified period of time.
Budget Entity A term and associated value that is assigned to identify the campus/unit defined in this
glossary.
Campus/Unit There are a number campuses (i.e. UT Knoxville, UT Martin, UT Chattanooga) and units (i.e.
University-wide Administration, Institute of Public Service, Institute of Agriculture) that make up The
University of Tennessee. They are referred to as campuses/units.
Chart of Accounts A list of accounts in the General Ledger, systematically classified by title and number,
developed to be compatible with organizational structure and in agreement with financial reports to be
presented.
Continuous Service Date A constructed date used to reflect the amount of time an employee has been
continuously employed by the University.

Cost Sharing Those project costs that are not paid by the sponsor, in accordance with the individual grant or
contract terms. These costs must be separately recorded for reporting purposes.
Detail Object Code A University-defined code to classify in more detail the costs incurred by expense
accounts. The detail object code is a further breakout of the primary object codes. Currently, the level required
for recording all expenses.
Demurrage The time allowed to unload a container at no additional charge to the customer.
EFT (Electronic Funds Transfer) A method of paying employees and vendors for services and products
through the electronic banking system.
Employee Designation An employee attribute describing whether the employee is a regular, temporary, or
student employee.
Employee Category An attribute describing the employees primary employment, including faculty, staff
exempt, staff non-exempt, or student.
Encumbrance An anticipated expenditure evidenced by a contract or purchase order; a commitment.
Exempt Staff One of five employee categories identifying the employee as a staff person exempt from wage
and hour regulations.
F&A (Facilities and Administrative) Costs Charges to sponsored projects to recover costs not directly
allocable to the accomplishment of the specific purpose of the project or program, such as use of space,
equipment, utilities, and administrative staff.
F&A Cost Sharing The reduction of the F&A costs charged at the usual rate down to the amount agreed upon
in the grant or contract.
FTE (Full Time Equivalent) The amount of time an employee is scheduled to work measured as a percent.
Function The purpose for which resources are expended: includes instruction, research, public service,
academic support, student services, institutional support, operational maintenance of physical plant, and
scholarships and fellowships.
Fund A self-balancing separate entity with its own set of accounts, consisting of assets, liabilities, and fund
balance; for example, current restricted.
Fund Accounting A method segregating assets into categories according to restrictions placed on their use by
the funding source.
Fund Balance Value of the excess of assets over liabilities in any fund group or subgroup; may be equated to
commercial equity.
Funding Source The University ledger account to which part or all of an employees earnings are charged.
Grade Level A grouping of job titles used to define the minimum and maximum wages rates appropriate for
that group.
Job Class A code indicating the job title associated with the employee.
Journal Voucher Transfers, limited to use by the Controllers Office, for making adjusting entries to the
General Ledger. These transactions are used to make adjusting entries such as corrections to object codes,
closing entries, etc.

Ledger Activity Code Classification codes for transactions posted to a balance sheet account. They may be
required for fund balance accounts but optional for asset or liability accounts.
Loan Funds Resources available for loans to students.
Non-exempt Staff One of five employee categories identifying the employee as being subject to wage and
hour regulations.
Object Code A University-defined code used to classify costs incurred by expense accounts. There are three
levels of object codes: primary, detail, user.
One-time Revision A budget revision that is applicable only to the year for which it was written. This
revision will not be included when a base budget is established.
Original Budget Budget that has been approved by the Board of Trustees for implementation on July 1 (the
beginning of the University=s fiscal year).
Permanent Revision A budget revision that is an on-going adjustment and will be included in establishment
of a base budget.
Position Pool Account A single account that includes funding for: (1) multiple positions such as ten student
positions, or (2) a specific purpose such as summer school funding.
Post Controlled Account The process of making an account unavailable for posting but still active for
reporting purposes.
Pre-encumbrance The intention to expend resources recorded prior to completion of the approval process or
a binding purchase commitment.
Primary Object Code A University-defined code used to classify in detail the costs incurred by expense
accounts. Currently, the level at which we budget for all expense accounts, except Plant Funds.
Projection/Speculation Transaction Transactions entered to record anticipated economic events.
Request for Quotations (RFQ) The formal request sent to vendors asking for a quotation (price) for the
purchase of goods or services.
Request for Proposals (RFP) The formal request sent to vendors asking for a proposal (this may or may not
include pricing) for the purchase of goods or services.
Responsible Account The University ledger account to which an employee is administratively responsible.
Restricted Resources available for financing operation but limited by donor or other external agency for
specific purposes, programs, departments, or schools.
Retainage The amount withheld from a purchase until final acceptance or delivery of goods or services.
Revised Budget Budget that reflects all changes to the Original Budget.
Service Base Indicator A code indicating whether an employee works 12 months, 9 months, or on a flexible
schedule.
Spending Control An edit that will prevent a transaction from posting if the expenditures plus encumbrances
exceed the current budget. This edit should be flexible enough to occur either at the account level or at each
primary object code level.

Sub-account An optional subdivision of an account designated by a distributed user which is used for
management and reporting purposes.
Sub-account Group see Account Group.
TDA (Tax Deferred Annuity) An optional pre-tax payroll deduction.
T.H.E.C. (Tennessee Higher Education System In the State of Tennessee, there are two major higher
education systems: The University of Tennessee and The State Board of Regents. The Tennessee Higher
Education System (T.H.E.C.) is a coordinating board charged with proposing funding and academic programs to
the Governor and General Assembly for the two systems of higher education.
Transaction The recording of an economic event entered in a prescribed format into a ledger.
Transfer Voucher Transfers between accounts or departments to make adjustments to the General Ledger.
University The University of Tennessee, or UT.
User Object Code In the University's current scheme for identifying expenditures, departments are provided
an area in the object code field to further identify and break down their expenditures. These user object codes
are maintained solely for the benefit of departments and are controlled at the departmental level. The user object
code provided more detail than the primary and detail object codes.

8. Attachments
8.1 Attachment A Primary Object Code Reference
REFERENCE 153
SCSPROBJ
NAME:
NARRATIV:
COMMENTS:

UNIVERSITY PRIMARY OBJECT CODES

THIS IS A UNIVERSITY DEFINED CODE WHICH IS USED TO
CLASSIFY THE NATURE OF COSTS INCURRED.
THE CODE SCHEME CONSISTS OF:

A 2-DIGIT REPRESENTATION OF THE UNIVERSITY

PRIMARY OBJECT CODE.

A 6-DIGIT EFFECTIVE DATE.

AN 8-CHARACTER FIELD RESERVED FOR FUTURE USE

A 1-DIGIT REPRESENTATION OF THE UNIVERSITY

BUDGET CATEGORY (REFERENCE 158) ASSOCIATED
WITH THE CODE. SINCE THIS CATEGORY IS NOT
APPLICABLE TO PLANT FUNDS, IT WILL BE SET TO ZERO
FOR ALL PLANT FUNDS.

A 2-DIGIT T.H.E.C. EXPENDITURE OBJECT VALUE

(REFERENCE 156) ASSOCIATED WITH THE CODE. SINCE
THIS VALUE IS NOT APPLICABLE TO PLANT FUNDS, IT
WILL BE SET TO ZEROS FOR ALL PLANT FUNDS.

A 1-DIGIT SUMMARY LEVEL BUDGET CATEGORY

(REFERENCE 169) ASSOCIATED WITH THE CODE.

RSP USER:
FREQUNCY:
SOURCE:
REFER TO:
REFER BY:
USAGE:
REVISION:

CODE
11
12
13
14
15
16
17
18
19
21
22
23
31
32
33
34
35
36
37
38
39
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57

A 30-CHARACTER TRANSLATION FOR THE PRIMARY

OBJECT CODE.

A 10-CHARACTER SHORT TRANSLATION FOR PRIMARY

OBJECT CODE.

U.T. TREASURER'S OFFICE

STABLE, LITTLE OR NO CHANGE ANTICIPATED.
FISCAL POLICIES AND PROCEDURES # 3
156, 158, 169
157
FINANCIAL
DATE OF LAST UPDATE - 10/30/98

B/C
1
1
1
3
2
3
4
4
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5

THEC
11
12
12
14
12
13
13
14
33
21
21
21
22
31
23
24
25
26
27
28
28
29
29
32
33
91
46
92
48
34
35
35
35
35
35
35
35
35

SUM
1
1
1
1
1
1
1
1
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2

TEXT
ADMIN & PROFESSIONAL SALARIES
ACADEMIC SALARIES
GTA,GA,GRA SALARIES
STUDENT EMPLOYEES-SALARIED
SUMMER SCHOOL
CLERICAL & SUPPORTING-SALARIED
CLERICAL & SUPPORTING-HOURLY
STUDENT EMPLOYEES-HOURLY
NON WAGE & CONTRACTUAL PAY
STAFF BENEFITS - REQUIRED
STAFF BENEFITS - OPTIONAL
STAFF BENEFITS FUNCTIONAL DIST
TRAVEL
MOTOR VEHICLE OPERATIONS
PRINTING, DUPLICATING, BINDING
UTILITIES AND FUEL
COMMUNICATION
MAINTENANCE AND REPAIRS
PROF SERV & MEMBERSHIPS
COMPUTER SERVICES
SUPPLIES
RENTALS
INSURANCE, INTEREST & BAD DEBT
AWARDS
GRANTS AND SUBSIDIES
MANDATORY TRANSFERS
CONTRACTUAL & SPECIAL SERVICES
NON-MANDATORY TRANSFERS
SERVICE DEPARTMENT CREDITS
OTHER EXPENDITURES
STORES FOR RESALE
STORES FOR RESALE
STORES FOR RESALE
STORES FOR RESALE
STORES FOR RESALE
STORES FOR RESALE
STORES FOR RESALE
STORES FOR RESALE

58
59
60
61
62
63
64
65
71
72
73
74
81
82
83
91
92
93
94
95
96

5
5
6
6
6
6
6
5
6
6
6
6
5
5
5
0
0
0
0
0
0

35
35
36
36
36
36
36
33
72
72
41
36
33
33
34
00
00
00
00
00
00

2
2
2
3
2
3
3
2
3
3
3
3
2
2
2
4
4
4
4
4
4

STORES FOR RESALE

STORES FOR RESALE
MINOR EQUIPMENT (NON F&A)
EQUIPMENT
MINOR EQUIPMENT
LIBRARY ACQUISITIONS
LIVESTOCK
INDIRECT COST
LAND - CAPITAL OUTLAY
BUILDINGS - CAPITAL OUTLAY
IMPROVEMENTS OTHER THAN BLDGS
DEPRECIATION
SUBGRT & SUBCNT TO $25,000
SUBGRT & SUBCNT OVER $25,000
SALES TAX
LAND - PLANT FUNDS
BUILDINGS - PLANT FUNDS
EQUIPMENT - PLANT FUNDS
OTHER CAPITAL IMPROVEMENTS
NON-CAPITAL OUTLAY ITEMS
OTHER PLANT FUND EXPENDITURES

8.2 Attachment B T.H.E.C. Expenditure Object Reference

REFERENCE 156
SCSTHOBJ
NAME:
NARRATIV:

T.H.E.C. EXPENDITURE OBJECTS

THIS IS A TENNESSEE HIGHER EDUCATION COMMISSION
DEFINED VALUE WHICH IS RELATED TO A UNIVERSITY DEFINED
PRIMARY OBJECT CODE (REFERENCE 153).

COMMENTS:
THE CODE SCHEME CONSISTS OF:

RSP USER:
FREQUNCY:
SOURCE:
REFER BY:
USAGE:
REVISION:

A 2-DIGIT REPRESENTATION OF THE T.H.E.C.

EXPENDITURE OBJECT.

A 6-DIGIT EFFECTIVE DATE.

A 30-CHARACTER DESCRIPTION OF THE EXPENDITURE

OBJECT.

OFFICE OF THE VICE PRESIDENT FOR BUSINESS AND FINANCE

YEARLY ADDITIONS ANTICIPATED.
T.H.E.C. SUMMARY BUDGET REQUEST FORMS (NO NUMBER).
153
FINANCIAL
DATE OF LAST UPDATE - 10/21/80

CODE
11
12
13
14
21

TEXT
PROFESSIONAL
INSTRUCTIONAL
CLERICAL & SUPPORTING
STUDENT HELP
STAFF BENEFITS

22
23
24
25
26
27
28
29
31
32
33
34
35
36
41
46
48
72
91
92
95

TRAVEL
PRINTING, DUPLICATING, BINDING
UTILITIES & FUEL
COMMUNICATIONS
MAINTENANCE & REPAIRS
PROFESSIONAL SERVICES & DUES
SUPPLIES & MATERIALS
RENTALS & INSURANCE
MOTOR VEHICLE OPERATIONS
AWARDS & INDEMNITIES
GRANTS & SUBSIDIES
OTHER EXPENDITURES
STORES FOR RESALE
EQUIPMENT
SITE DEVELOPMENT & IMPROVEMENT
CONTRACTUAL & SPECIAL SERVICES
SERVICE DEPARTMENT CREDITS
BUILDINGS - CAPITAL OUTLAY
MANDATORY TRANSFERS
NON-MANDATORY TRANSFERS
CENTRAL ADMINISTRATION SUPPORT

8.3 Attachment C Detail Object Code Reference

REFERENCE 157
SCSDTOBJ
NAME:
NARRATIV:

UNIVERSITY DETAIL OBJECT CODES

THIS IS A UNIVERSITY DEFINED CODE USED TO CLASSIFY IN MORE
DETAIL THAN THE UNIVERSITY PRIMARY OBJECT CODE THE NATURE OF
COSTS INCURRED.

COMMENTS:

THE CODE SCHEME CONSISTS OF:

A 3-DIGIT REPRESENTATION OF THE UNIVERSITY DETAIL OBJECT

CODE. THE FIRST TWO DIGITS OF THIS CODE ARE THE SAME AS
THE UNIVERSITY PRIMARY OBJECT CODE (REFERENCE 153).

A 6-DIGIT EFFECTIVE DATE.

A 1-CHARACTER FIELD USED TO IDENTIFY DETAIL OBJECT CODES

WHICH ARE CLASSIFIED AS RECOVERIES. THIS CHARACTER IS -RIF THE FIELD IS A RECOVERY, OTHERWISE IT IS A SPACE.

A 30-CHARACTER DESCRIPTION OF THE DETAIL OBJECT CODE.

A 1-CHARACTER 'ENCUMBERANCE FLAG'. THE VALUE IS -EWHEN THE DETAIL OBJECT REFLECTS AN ENCUMBERANCE,
OTHERWISE IT IS A BLANK.

A 15-CHARACTER SHORT DESCRIPTION OF THE DETAIL OBJECT.

A 1-CHARACTER INDICATOR TO DESIGNATE THIS OBJECT CODE IS

VALID FOR A DEPARTMENT PROCUREMENT CARD.

RSP USER:
FREQUNCY:
SOURCE:
REFER TO:
USAGE:
REVISION:

A 1-CHARACTER FIELD RESERVED FOR FUTURE USE

U.T. TREASURER'S OFFICE

STABLE, LITTLE OR NO CHANGE ANTICIPATED.
FISCAL POLICIES AND PROCEDURES # 3
153
FINANCIAL, STUDENT
DATE OF LAST UPDATE - 12/21/98

CODE

REC

TEXT

ENC

PROC

11 - ADMIN & PROFESSIONAL SALARIES

111

SALARIES

112

EXTRA SERVICE

114

LONGEVITY PAY

115

PERSONAL SICK LEAVE PAY

119

SALARY RECOVERIES

N
N

12 - ACADEMIC SALARIES
121

ACADEMIC SALARIES

122

ACADEMIC EXTRA SERVICE

124

LONGEVITY PAY

125

PERSONAL SICK LEAVE PAY

129

ACADEMIC RECOVERIES

N
N

13 - GTA,GA,GRA SALARIES
131
139

GTA, GA, GRA SALARIES

R

GTA,GA,GRA RECOVERIES

N
N

14 - STUDENT EMPLOYEES-SALARIED
141

STUDENT SALARIES

142

STUDENT SALARIES-OVERTIME

STUDENT SALARIES-RECOVERIES

149

15 - SUMMER SCHOOL
151
159

SUMMER SCHOOL SALARIES

SUMMER SCHOOL RECOVERIES

16 - CLERICAL & SUPPORTING-SALARIED

161

SALARIES

162

OVERTIME

164

LONGEVITY PAY

165

PERSONAL SICK LEAVE PAY

169

SALARY RECOVERIES

N
N

17 - CLERICAL & SUPPORTING-HOURLY

171

WAGES-HOURLY

172

OVERTIME-HOURLY

174

LONGEVITY PAY

175

PERSONAL SICK LEAVE PAY

RECOVERIES-HOURLY

179

18 - STUDENT EMPLOYEES-HOURLY
181
189

STUDENT WAGES-HOURLY

STUDENT WAGES-HRLY-RECOVERIES

19 - NON WAGE & CONTRACTUAL PAY

192
OTHER NON WAGE PAYMENTS

193

EMPLOYEES MEAL AND LODGING

195

CONTRACTUAL PAY

NON WAGE RECOVERIES

199

21 - STAFF BENEFITS - REQUIRED

211

RETIREMENT CONTRIB-ORP/B

212

RETIREMENT CONTRIB-STATE

213

RETIREMENT CONTRIB-FEDERAL

214

SOCIAL SECURITY CONTRIBUTION

215

UNEMPLOYMENT COMPENSATION

216

WORKERS COMPENSATION

217

RETIREMENT CONTRIB-ORP/A

218

SOCIAL SECURITY CONTRIB-FLEX

22 - STAFF BENEFITS - OPTIONAL

221

GROUP INSURANCE

222

STAFF TUITIONS

223

DEATH BENEFIT-SICK LEAVE

224

401-K MATCHING

225

STAFF DEPENDENT TUITIONS

226

ACCRUED STAFF BENEFITS

23 - STAFF BENEFITS FUNCTIONAL DIST

231

STAFF BENEFITS FUNCTIONAL DIST

311

TRAVEL IN STATE

312

TRAVEL OUT OF STATE

313

MTR VEH OPER-TRAVEL IN STATE

314

MTR VEH OPER-TRAVEL OUT STATE

TRAVEL RECOVERIES

31 - TRAVEL

319

32 - MOTOR VEHICLE OPERATIONS

321
329

MTR VEH OPER-LOCAL & TRUCKS

MTR VEH OPER RECOVERIES

33 - PRINTING, DUPLICATING, BINDING

331

PRINTING

332

DUPLICATING

333

BINDING

334

PUBLICATIONS AND REPORTS

PRNT,DUP,BINDING RECOVERIES

339

34 - UTILITIES AND FUEL

341

FUEL OIL

342

COAL

343

ELECTRICITY

344

GAS

345

WATER

346

GASOLINE & DIESEL

347

OTHER UTILITIES & FUEL

348

SEWAGE AND GARBAGE

349

UTILITY RECOVERIES

35 - COMMUNICATION
351

POSTAGE

352

FREIGHT

353

TELEPHONE

354

TELEGRAMS

355

TELECOMMUNICATIONS

COMMUNICATIONS RECOVERIES

359

36 - MAINTENANCE AND REPAIRS

361

MAINTENANCE & REPAIRS

362
369

SPECIALLY APROV DEFERRED MAINT

MAINT & REPAIRS RECOVERIES

Y
Y

37 - PROF SERV & MEMBERSHIPS

372

PUBLICITY

373

SUBSCRIPTIONS

374

INSTIT MEMBERSHIP FEES & DUES

375

LEGAL & PROFESSIONAL FEES

PROFESSIONAL SERV RECOVERIES

379

38 - COMPUTER SERVICES
381

COMPUTER SVCS-INTERNAL TO UNIV

382
389

COMPUTER SVCS-EXTERNAL TO UNIV

COMPUTER SERVICE RECOVERIES

Y
N

391

OPERATING SUPPLIES

392

COMPUTER SOFTWARE

393

LABORATORY SUPPLIES

SUPPLY RECOVERIES

411

RENTALS-COPYING MACHINES

412

RENTALS-COMPUTER EQUIPMENT

413

RENTALS-REAL PROPERTY

414

RENTALS-OTHER EQUIPMENT

RENTAL RECOVERIES

39 - SUPPLIES

399

41 - RENTALS

419

42 - INSURANCE, INTEREST & BAD DEBT

421

INSURANCE

422

INTEREST-INSTAL/LEASE PURCHASE

423

INTEREST-PROMPT PAY ACT

424

AUTOMOBILE LOSS LIABILITY

425
426

WORKERS COMPENSATION LIABILITY

BAD DEBT EXPENSE

N
N

INSURANCE RECOVERIES

431

AWARDS-STUDENT AID & STIPENDS

432

AWARDS-FACULTY & OTHER

AWARDS RECOVERIES

429

43 - AWARDS

439

44 - GRANTS AND SUBSIDIES

441

STUDENT FEES

442

HOSPITALIZATIONS (GRANTS ONLY)

443

ALTERATIONS (GRANTS ONLY)

444

COST SHARING

445

SUBGRANTS AND SUBCONTRACTS

GRANTS & SUBSIDIES RECOVERIES

449

45 - MANDATORY TRANSFERS
451

INTEREST

452

DEBT RETIREMENT

46 - CONTRACTUAL & SPECIAL SERVICES

461

CASUAL LABOR

462
463
464

GROUP ARRANGED FOOD & LODGING

CULTURAL OR ENTERTAINMENT FEES
OTHER EDUC OR GOV AGENCIES

N
N
N

465

SPECIAL COMMERCIAL SERVICES

466

OTHER UNIVERSITY DEPARTMENTS

467

OTHER PERSONAL SERVICES

468

SEMINAR & CONF REGISTRA FEES

CONTRACTUAL SER RECOVERIES

469

47 - NON-MANDATORY TRANSFERS
471
479

NON-MANDATORY TRANSFERS

NON-MANDATORY TRANSFER-REC

48 - SERVICE DEPARTMENT CREDITS

481
489

SERVICE DEPARTMENT CREDITS

SERVICE DEPT CREDITS-RECOVERY

49 - OTHER EXPENDITURES
491
499

OTHER EXPENDITURES

OTHER RECOVERIES

50 - STORES FOR RESALE

501

STORES FOR RESALE 01

502

STORES FOR RESALE 02

503

STORES FOR RESALE 03

504

STORES FOR RESALE 04

505

STORES FOR RESALE 05

506

STORES FOR RESALE 06

507

STORES FOR RESALE 07

508

STORES FOR RESALE 08

STORES FOR RESALE 09-RECOVERY

509

51 - STORES FOR RESALE

511

STORES FOR RESALE 11

512

STORES FOR RESALE 12

513

STORES FOR RESALE 13

514

STORES FOR RESALE 14

515

STORES FOR RESALE 15

516

STORES FOR RESALE 16

517

STORES FOR RESALE 17

518

STORES FOR RESALE 18

STORES FOR RESALE 19-RECOVERY

519

52 - STORES FOR RESALE

521

STORES FOR RESALE 21

522

STORES FOR RESALE 22

523

STORES FOR RESALE 23

524

STORES FOR RESALE 24

525

STORES FOR RESALE 25

526

STORES FOR RESALE 26

527

STORES FOR RESALE 27

528

STORES FOR RESALE 28

STORES FOR RESALE 29-RECOVERY

529

53 - STORES FOR RESALE

531

STORES FOR RESALE 31

532

STORES FOR RESALE 32

533

STORES FOR RESALE 33

534

STORES FOR RESALE 34

535

STORES FOR RESALE 35

536

STORES FOR RESALE 36

537

STORES FOR RESALE 37

538

STORES FOR RESALE 38

STORES FOR RESALE 39-RECOVERY

539

54 - STORES FOR RESALE

541

STORES FOR RESALE 41

542

STORES FOR RESALE 42

543

STORES FOR RESALE 43

544

STORES FOR RESALE 44

545

STORES FOR RESALE 45

546

STORES FOR RESALE 46

547

STORES FOR RESALE 47

548

STORES FOR RESALE 48

STORES FOR RESALE 49-RECOVERY

549

55 - STORES FOR RESALE

551

STORES FOR RESALE 51

552

STORES FOR RESALE 52

553

STORES FOR RESALE 53

554

STORES FOR RESALE 54

555

STORES FOR RESALE 55

556

STORES FOR RESALE 56

557

STORES FOR RESALE 57

558

STORES FOR RESALE 58

STORES FOR RESALE 59-RECOVERY

559

56 - STORES FOR RESALE

561

STORES FOR RESALE 61

562

STORES FOR RESALE 62

563

STORES FOR RESALE 63

564

STORES FOR RESALE 64

565

STORES FOR RESALE 65

566

STORES FOR RESALE 66

567

STORES FOR RESALE 67

568

STORES FOR RESALE 68

STORES FOR RESALE 69-RECOVERY

569

57 - STORES FOR RESALE

571

STORES FOR RESALE 71

572

STORES FOR RESALE 72

573

STORES FOR RESALE 73

574

STORES FOR RESALE 74

575

STORES FOR RESALE 75

576

STORES FOR RESALE 76

577

STORES FOR RESALE 77

578

STORES FOR RESALE 78

STORES FOR RESALE 79-RECOVERY

579

58 - STORES FOR RESALE

581

STORES FOR RESALE 81

582

STORES FOR RESALE 83

583

STORES FOR RESALE 83

584

STORES FOR RESALE 84

585

STORES FOR RESALE 85

586

STORES FOR RESALE 86

587

STORES FOR RESALE 87

588

STORES FOR RESALE 88

STORES FOR RESALE 89-RECOVERY

589

59 - STORES FOR RESALE

591

STORES FOR RESALE 91

592

STORES FOR RESALE

593

STORES FOR RESALE

594

STORES FOR RESALE

595

STORES FOR RESALE

596

STORES FOR RESALE

597

STORES FOR RESALE

598

STORES FOR RESALE

STORES FOR RESALE-RECOVERY

599

60 - MINOR EQUIPMENT (NON F&A)

601

MINOR EQUIPMENT (NON F&A)

609

MINOR EQUIPMENT (NON F&A) RECO

611

FURNITURE & OFFICE EQUIPMENT

612

EDUC & SCIENTIFIC EQUIPMENT

613

MACHINERY

618

EQUIPMENT INSTALLMENT PURCHASE

EQUIPMENT RECOVERIES

61 - EQUIPMENT

619

62 - MINOR EQUIPMENT
621
629

MINOR EQUIPMENT (NON CAPITAL)

MINOR EQUIPMENT RECOVERIES

63 - LIBRARY ACQUISITIONS
631

LIBRARY ACQUISITIONS

632

LIBRARY BINDINGS

LIBRARY BOOK RECOVERIES

LIVESTOCK

LIVESTOCK RECOVERIES

639

64 - LIVESTOCK
641
649

65 - INDIRECT COST
651

FACILITIES & ADMIN COST

659
F&A RECOVERY
71 - LAND - CAPITAL OUTLAY
711

LAND-CAPITAL OUTLAY

72 - BUILDINGS - CAPITAL OUTLAY

721

BUILDINGS-CAPITAL OUTLAY

73 - IMPROVEMENTS OTHER THAN BLDGS

731

IMPROVEMENTS OTHER THAN BLDGS

DEPRECIATION EXPENSE

74 - DEPRECIATION
741

742

ALLOWANCE FOR DEPRECIATION

81 - SUBGRT & SUBCNT TO $25,000

811

SUBGRT & SUBCNT TO $25,000

82 - SUBGRT & SUBCNT OVER $25,000

821

SUBGRT & SUBCNT OVER $25,000

SALES TAX

83 - SALES TAX
831

91 - LAND - PLANT FUNDS

911

LAND-PLANT FUNDS

92 - BUILDINGS - PLANT FUNDS

921

CONSTRUCTION CONTRACT-PRIME

922

ARCHITECT FEES

923

ENGINEERING & INSPECTION FEES

924

SPECIAL CONTRACTUAL WORK

925

FIXED EQUIPMENT

926

MISC EXPENSE (ADV,INSUR,TAXES)

927

ALLOCATED COST PURCH PROPERTY

93 - EQUIPMENT - PLANT FUNDS

931

FURN & MOVEABLE EQUIP-TAGGED

932

FURN & MOVEABLE EQUIP-MINOR

94 - OTHER CAPITAL IMPROVEMENTS

941

OTHER CAPITAL IMPROVEMENTS

942

SOFTWARE

95 - NON-CAPITAL OUTLAY ITEMS

951

NON-CAPITAL OUTLAY ITEMS

96 - OTHER PLANT FUND EXPENDITURES

961

OTHER PLANT FUND EXPENDITURES

962

UNALLOCATED BUDGET

8.4 Attachment D Budget Category Code Reference

REFERENCE 158
SCSBGTCT
NAME:

UNIVERSITY BUDGET CATEGORIES

NARRATIV:
COMMENTS:

RSP USER:
FREQUNCY:
SOURCE:
USAGE:
REVISION:

THIS IS A CATEGORIZATION OF PRIMARY OBJECT CODES.

THE CODE SCHEME CONSISTS OF:

A 1-DIGIT REPRESENTATION OF THE UNIVERSITY

BUDGET CATEGORY.

A 6-DIGIT EFFECTIVE DATE FOR THE CODE.

A 30-CHARACTER TEXTUAL TRANSLATION FOR THE

CODE.

U.T. TREASURER'S OFFICE

STABLE, LITTLE OR NO CHANGE ANTICIPATED.
U.T. TREASURER'S OFFICE
FINANCIAL
DATE OF LAST UPDATE - 12/04/95

PROFESSIONAL SALARIES
SUMMER SCHOOL
NON-EXEMPT SALARIES
BIWEEKLY WAGES
OPERATING & MISCELLANEOUS
EQUIPMENT & CAPITAL OUTLAY
8.5 Attachment E Ledger Activity Code Reference
REFERENCE 171
SCSLGACT
NAME:
NARRATIV:
COMMENTS:

RSP USER:
FREQUNCY:
SOURCE:
USAGE:
REVISION:

LEDGER ACTIVITIES
THIS IS A UNIVERSITY CODE USED TO CLASSIFY THE TYPE OF
DEBIT OR CREDIT ACTIVITY OCCURRING ON A BALANCE
ACCOUNT.
THE CODE SCHEME CONSISTS OF:

A 3-DIGIT REPRESENTATION OF THE LEDGER ACTIVITY.

A 6-DIGIT EFFECTIVE DATE FOR THE CODE.

A 5-CHARACTER FIELD RESERVED FOR FUTURE USE

A 30-CHARACTER TEXTUAL TRANSLATION FOR THE

CODE.

U.T. TREASURER'S OFFICE

YEARLY CHANGE ANTICIPATED.
U.T. TREASURER'S OFFICE
FINANCIAL
DATE OF LAST UPDATE - 08/22/97

CODE
001
002
003
004
005
006
007
009
010
011
012
013
014
015
016
017
018
019
020
021
025
026
027
028
029
030
031
032
033
034
035
036
037
038

TEXT
ENDOW INCOME-UT ENDOWMENTS
ENDOW INCOME-OUTSIDE TRUSTEES
GIFTS,GRANTS&BEQUESTS-RECEIPTS
GIFTS,GRANTS&BEQUESTS-REFUNDS
INTEREST ON STUDENT NOTES REC
INCOME ON INVESTED FUNDS
GAINS (LOSSES) ON INVESTMENTS
PROGRAM INCOME
FACILITIES & ADMIN COST
TRANSFERS CURRENT GENERAL FDS
STATE APPROPRIATIONS
FEDERAL APPROPRIATIONS
AUTHORIZED BOND & NOTE ISSUES
AUXILIARY ENTERPRISE OPER
PRINCIPAL PAYMENTS
INTEREST PAYMENTS
PAYMENTS FROM TRUSTS
APPROPRIATIONS - PLANT FUNDS
INTEREST ON RESERVE FUNDS
TRANSFERS UNEXPENDED PLANT FDS
ACCOUNTS RECEIVABLE RECEIPTS
COST OF ADDRESS SEARCH
WRITE-OFF UNCOLLECTIBLE NOTES
LOANS CAN BY TEACH CR 15% N DI
LOANS CANCEL BY NURSING CR 15%
INSTIT COLLECTION EXPENSE
LOANS CANCEL BY NURSING CR 10%
LOANS CANCEL BY NURSING CR 20%
LOANS CANCEL BY BANKRUPTCY
LOANS CANCEL BY DEATH
COST OF LITIGATION
LOANS CANCEL BY MILITARY CR
LOANS CANCEL BY TEACHNG CR 10%
LOANS CAN BY TEACH CR 15% N DF

039

LOANS CANCEL BY TEACHNG CR 20%

040
041
042
043
044
045
046
047
048

LOANS CANCEL BY TEACHNG CR 30%

LOANS CANCEL BY DISABILITY
OTHER COLLECTION COSTS
INTEREST CANCELLATION CREDIT
INTEREST CANCELLATION DEBIT
FACILITIES & ADMIN COSTSHARING
LOANS ASSIGNED TO HEW
INTEREST RE-ASSUMED BANKRUPT
SPONSOR REIMBURSEMENTS

049

ALLOWANCE FOR DOUBTFUL ACCTS

050
051
052
053
054
055
056
057
058

CHARGES FOR ROUTINE EXPENSE

TRANSFERS CURRENT AUX FUNDS
TRANSFERS CURRENT HOSP FUNDS
TRANSFERS LOAN FUNDS
TRANSFERS ENDOWMENT FUNDS
TRANSFERS LIFE INCOME FUNDS
TRANSFERS INDEBTEDNESS FUNDS
TRANSFERS CURRENT RESTR E & G
TRANSFERS CURRENT RESTR AUX

059
060
061

TRANSFERS CURRENT RESTR HOSP

TRANSFERS AGENCY FUNDS
TRANSFERS RENEWAL-REPLACEMENT

062

LOANS CANCEL PEACE CORPS 15%

063
064
065
066
067
068
069
070
071
072
073
074
075
076
077
078

LOANS CANCEL PEACE CORPS 20%

LOANS CANCEL DOM VOL SERV 15%
LOANS CANCEL DOM VOL SERV 20%
PENALTY CHARGES
LATE CHARGES
LOANS CANCEL PERKINS TEACH 15%
LOANS CANCEL PERKINS TEACH 20%
LOANS CANCEL PERKINS TEACH 30%
LOANS CAN PERKINS LAW ENF 15%
LOANS CAN PERKINS LAW ENF 20%
LOANS CAN PERKINS LAW ENF 30%
LOANS CAN PERK TCH CER SUB 15%
LOANS CAN PERK TCH CER SUB 20%
LOANS CAN PERK TCH CER SUB 30%
LOANS CAN PERK CHILD FAM 15%
LOANS CAN PERK CHILD FAM 20%

079

LOANS CAN PERK CHILD FAM 30%

084

NURSE/MEDICAL TECHNICIAN 15%

085

NURSE/MEDICAL TECHNICIAN 20%

086
089
099

NURSE/MEDICAL TECHNICIAN 30%

COVER RESTRICTED EXPENSE
OTHER LEDGER ACTIVITIES

8.6 Attachment F TCRS Defined Benefit Formula

One and one-half percent (.015) times the Average Final Compensation, plus one-fourth of one percent (.0025)
of the Average Final Compensation in excess of the applicable social security integration level, multiplied by the
creditable service (including accrued sick leave). This will yield the regular maximum benefit. Beneficiary
options would be applied to the regular maximum.
Reduction in benefits equal to .004 per month will be applied for early retirements.
A disability factor of .9 is applied to the regular maximum benefit for disability retirement for employees under
age 60 or with less than 30 years of service. Additionally, if the disabled employee has less than 20 years of
service, service is projected to the full 20 years.
8.7 Attachment G Employee Death Benefits Formula
The estate of a deceased University employee who was employed in a regular full or part time position is
entitled to the deceased employees regular pay earned to date of death plus the value of any unused sick and/or
annual leave plus one calendar months pay, provided the deceased employee was in an active pay status at the
time of death.
Computations:
1) One Calendar Months Pay

2) Unused Sick Leave:

Hourly Rate * Unused Sick Leave Hours
Hourly Rate = Annual Salary/(2080*FTE)