1. By detail object code
 
 
 
 

2. Department input without Budget Office/OVPR 
 
 
 
 

3. Separate expense account for specific project
 
 
 
 

4. History of accounts by year
 
 
 
 

B. Projections:

1. Revenue and when expected
 
 
 
 

2. Short-term and long-term
 
 
 
 
 
 
 
 

C. Encumbrances/Obligations

1. Period of coverage/life cycle
 
 
 
 

2. Timely information (with browse)
 
 
 
 

3. Salaries, benefits and overhead
 
 
 
 

D. Accounting Transactions:

1. More detailed object codes
 
 
 
 

2. More detailed transaction codes
 
 

3. Timely information
 
 

4. User input description with transaction
 
 
 

5. Label expenses to a project group
 

6. Define expense to a category
 
 

7. Identify transactions by PI
 
 
 
 

8. More information on internal charges and jvs
 
 

9. More text description
 
 
 

10. Break/group transactions to give more detail

E.  Report:

1. User-defined attributes

F.  Grants/Projects Management

1. Cost (allocation) recovery functions (project, not grant)
 

2. Cost sharing by grant, PI, dept, match acct/trans

G.  Other

1. Email alert with parameter ie. Due date, bal. etc.

4. Length of account code is too long

Recommend support of detail line item budgeting by fiscal year and project-to-date.
 
 
 

Intention of Committee to support independent budgeting by users within current policy & guidelines.
 
 
 

The project module and/or user defined fields allow for separate reporting by project.
 
 
 
 

It is our understanding that new systems support history by year. We also need project-to-date reporting capability.
 
 
 
 

Link into gift system for gift pledges. User input budget by month for other types of expected revenues.
 
 

Budget module (Peoplesoft) allows for future years.
 
 
 
 
 
 
 
 
 

Will PS purchasing module allow effective dates? Send HR budget (= encumbrance) to GL with dates.
 
 

Use purchasing module for ALL purchases – both internal and external. Create estimated commitments.
 
 

See F.7. Send HR budget (= encumbrance) to GL. Use allocation tables to calculate FB & OH.
 
 
 
 
 

Create more detailed object codes, if appropriate. User defined fields. Pre-defined central codes with additional characters for dept use.
 

User defined fields. Use trees for grouping/reporting.
 

Secured access to subsystem data
 
 

User defined fields may accomplish some of this. System also allows a great deal of space for free form text with certain input.
 

User Projects module to track these expenses. 
 

Use trees to roll up expenses into categories. User defined fields.
 

Create multiple projects and/or user defined fields. HR employee code appears to be best way to identify grant personnel.
 
 

Secured access to electronic forms.
 
 
 

PeopleSoft has large areas available for text or journals and certain other input forms.
 
 

Use trees for grouping/reporting. Secured access to subsystems for detail.
 
 

Recommend through implementation that we link and do as much drill down as possible to subsystems for info.
 
 

Recommendation that the cash system be looked at for possible modification (have each non-student entry stand alone in G/L and not be rolled together into lump sum or have each cash transmittal stand alone).
 
 

The Chart of Accounts Committee has recommended a user defined chart field plus additional user defined fields as appropriate.
 

Training investment of time in the reporting tools along with the tree capability of the system should accomplish this.
 
 

Printed reports on demand. Standard queries are expected to provide monthly reports with no paper distribution. Detail can be manipulated beyond standard query to meet user needs.
 
 
 
 

All data should be available for at least 10 years and queries will facilitate comparisons.
 
 

Use project chart field and/or user defined chart field attached to transactions (before and after processing).
 
 

Use of trees or project definitions as appropriate.
 
 
 

See E.2. response.
 
 
 

Provided by Peoplesoft – should be built in non PS applications using PS link tools
 
 
 
 

Detail object codes. Use of Trees. User defined fields.
 

Tag transaction with project ID. Use of project ID to link reporting. Time & labor reporting. Transaction level.
 

Object code equivalent-build to meet central and common use. User defined fields.
 
 

Use projects, user defined field and/or sub-accounts.
 

PS-HR will have history on individual. Grad student-carry through detail to GL.
 
 

Extracts to data warehouse for reporting. Improved interface between systems. Secured access to subsystems.
 
 
 

Tables for rates – calc IDC/FB for future periods. How to disencumber correctly?
 
 

The Committee endorses the use of automated notices to account administrators and will pass suggestions on to implementation committee.
 
 
 

Peoplesoft generally supports large descriptions in more places than current system and effort should be made to give individual users access.
 
 

Build security tree as detailed as desired. In addition, a user with higher level of access can generate report and send to other users as needed.
 
 

The Committee concurs that the current set of accounts requires excess input due to length. It is expected the new code structure will require fewer digits to be input, although overall field lengths will actually increase. Optional user fields may add some input, but should result in better data.
 
 

Many of the rules for journal vouchers involve account code rules, i.e., revenue accounts must use a revenue object code, expense accounts must use an expense object code, etc. This should be alleviated with the new account code structure in which the object defines revenue and expense. Other rules such as authorization and retention may need to remain in any system implemented. In short, the added flexibility is user friendly and should reduce the number of edit checks (rules).
 
 
 

This is often dependent on sponsor guidelines. OVPR will review procedures with users. (Some accounts run 10 years and more).
 
 

Reports should have a standard query format for all users. Can be run by any begin/end date series (e.g., month-quarter) and then printed if so desired.
 

It appears that all this data will be retained. Line number may be in HR rather than GL, but some similar delineator is anticipated.
 

Account structure is designed with this in mind. The use of tress should accomplish this goal.
 
 

Standard query with email notice to users; user may print by choice.
 
 

The use of standard journals in an on-line mode is inherent to all systems under consideration.
 
 

Consider some form of scannable back-up. Secured access to electronic forms already processed.