Note that this summary does not represent the total list of requirements, but is presented to give an overall view of the required core functionality.

1. Transaction Management
   1. Division and department users need a mechanism to internally track all financial transactions in a single place on a single form, which can either be manually entered or added based on system-to-system integrations, where possible.
   2. These transactions include the need to enter an account for items relating to Payment Requests, Scholarship/Fellowship, Travel, CORE Facilities, Electronic Billing, UIT, Shipping Charges, USHOP, Pcard, General Stores, Journal Entries, EPR, Sub Contracts, Campus Orders, Supply Centers, and any other department-specific transaction identified.
   3. Transactions need the ability to be tagged/classified in departmentally-configured ways in order to facilitate individual reporting needs at the sub-activity level and across activities.
   4. The initiator of the transaction fills out required fields, sees the system automatically total the transaction, categorizes transactions, selects chartfields, labs by PI Name according to the individual security. 
2. Flexible Approvals
   1. The system should allow for department-specific transaction approval routings including scientific, business, financial, and other approvals as deemed by each organization. These approvals include adding ad-hoc approvers, allowing the approvers to set email preferences, setup pooled-approval roles.
   2. Approvers need to see in-line with the request the activity or project budget, cash balance, encumbrances, and pending items in order to make financial decisions that the transaction has sufficient funds.
   3. The financial approver should also have the ability to split transactions across multiple chartfields, or combining several requests into a single vendor order.
3. P-Card Reallocation
   1. This system shall function similarly to the way that Sienna and the SOM Dean’s Office Transaction system already function where data is downloaded from PeopleSoft daily and uploaded for reallocation use. Today this is done manually, but an integration would be preferred.
   2. The system automatically matches its transactions with those in the JPMorgan download and creates the reallocation file based on the transaction’s chartfield and pre-defined matching criteria, which is uploaded back into PeopleSoft. 
   3. Some manually processing is also needed in the cases where the vendor splits a single transaction into multiple and the system will note which lines on a transaction are still outstanding.
4. Reconciliation
   1. The system will show the funding history of charges, who reconciled, when and what amounts are remaining (committed) vs. expended.
   2. The reconciliation view of an activity or project will show all transactions from the system for a specific time period in one part of the screen and all data that has cleared the General Ledger for the same time period. The system will auto-match the different types of transactions based on defined match criteria.
   3. The reconciliation process will indicate “cleared” transactions within the system.
   4. Users are able to manually match, un-match, save and return to the reconciliation process later and/or enter new transactions in order to fully reconcile.
5. Integrations
   1. Much of the data that the system will need to integrate with is presumably already flowing to the EDW managed by Cheri Hunter. We will need data, to be further refined to specific elements, from the following systems for reconciliation purposes: Telcom, Interest, umarket, Scholarship payments (tuition), journal entries, Cores, Travel, payroll actuals, payroll encumbrances, EPM, JPMorgan, EDR/ePAR, Traineeship Payments, ePR, Grants & Contracts (sponsor payments and budget), clinical incentive pay, Postive Pay, and possibly others as additional phases of the project roll out.
6. Configuration
   1. Departments need the ability to configure information about chartfield defaults, grants, nicknames for grants (used for searching and display in system), allowables/unallowables by grant (IACUC, IRB, Others), GFA by project (can this be imported?), Tolerance for Variance in purchase price by Org (% and or amount), Units (sub-orgs, custom labs, real orgids), Approval routings (roles by units, by grant/activity, business approvers, finance approvers, ad hoc approvers, individual email opt-out, list of pcards/buyers.
   2. The concept of Funds Control is an essential element where the department can de-activate a project or activity that is overspent (or nearly) so that users initiating a transaction can’t select those chartfields from the beginning.
7. Budget & Forecasting
   1. The system will show a budgeting and forecasting view of activities and projects to allow users to add forecasted amounts by account by month, and then when the next month’s actuals are loaded, replace the forecasts with the actuals once the month passes.
   2. The system will show payroll information by name, and allow users the option of adding in un-named people as future pre-encumbrances.
   3. The forecasted data will be saved for future use. 
8. Reporting
   1. This requirement is still being defined, however, will include transactional reports and reconciliation reports, PI reports, department leadership reports et al.
   2. Reporting will include standard reports and allow for interactive, ad hoc reporting.
9. Security
10. 1. Department users need to grant roles to users in my department such that they only see their activities, projects, and pcard activity. These roles also need to let departments give permission to those who will be doing Pcard reallocation, reconciliation and configure department workflows and activity/project/pcard/organization data. Some of the roles include dept administrator, PI/responsible person, purchaser, receiving, requester, business approver, financial approver, reconciler …(more)