Financial Administration

Timelines | Flowcharts | Scope | Project Assumptions | Business Units and Set IDs
Chartfield w/ Definitions | Legacy Class Code/ SFS Account Code Conversions

Project Scope:
The financial system encompasses the implementation of the PeopleSoft Financial modules for general ledger, accounts payable, purchasing, and asset management. To help guide decision making during the implementation process, to maintain focus and stay on schedule, and to help ensure success, the following constraints and limitations are used to define the project scope:

  • The system design will be limited to accommodating current processes within the delivered software. No new processes or interfaces will be designed into the system except where a legal or regulatory requirement is unmet by the system as delivered. The business processes will be re-engineered to work with the system rather than modifying the system to work with current business processes. Compelling business need including cost and benefit must be identified for any change to be incorporated into the code as originally delivered.
  • Conversion of historical data to the new system will be kept to a minimum. Some factors to consider when determining whether to convert historical data are: 1) cost of converting historical data, 2) time constraints on the conversion process, 3) real frequency of required access, 4) level of complexity in the conversion process, 5) significance of historical data in decision making, and; 6) alternatives to access the historical data if not converted.
  • To conserve resources, parallel processing will not be performed during implementation or production. Comparing results is often impossible with dramatically different systems.
  • When possible, adoption of existing design from other sources is preferred over developing a new design. For example, the balance sheet design could be based on the Department of Administration's balance sheet, which meets Generally Accepted Accounting Principles.
  • Staff responsible for the data residing on the system will control security access to the new system. Staff who have a valid interest in the data will be granted the appropriate access privileges.

The constraints and limitations will apply to all decision making by the project team members during the implementation of the system.

Project Assumptions:
The general Assumptions used for Phase I of the Shared Financial System project of the University of Wisconsin System included the following:

  • PeopleSoft (Shared Financial System) General Ledger (GL), Accounts Payable (AP) and Purchasing (PO) Financials modules will be implemented using a phased approach across the University of Wisconsin System (UWS).
  • UW-Whitewater and UW-Platteville will implement PeopleSoft GL, AP and PO by July 1, 1999.
  • UW-Milwaukee will implement PeopleSoft AP and PO by July 1, 1999.
  • UW-Colleges will implement PeopleSoft PO by July 1, 1999.
  • The addition of the Platteville, Milwaukee, and Colleges to the pilot group will not materially affect the scope document prepared for Whitewater.
  • The Project Coordination Team will seek to streamline and improve business processes, by using PeopleSoft functionality rather than customizing the system. This would reduce reliance on information technology specialist.
  • The Project Coordination Team, Resource Team and all end users will get the necessary training in a timely manner as identified in the project plan.
  • UW-System Administration will hire a strong project manager to manage the implementation of PeopleSoft.
  • DoIT programming resources will be limited to supporting the implementation at UW-Whitewater, UW-Platteville, and UWPC during Phase I of the project.
  • All institutions will use a single, common production database.
  • The Shared Financial System will be installed at DoIT and available to each institution as defined in the project plan.
  • It is an institutional responsibility to provide an adequate workstation to each user before deployment of the Shared Financial System.
  • PeopleSoft Financials Public Sector version 6 will be upgraded to version 7 by September 30, 1998.
  • UWS has contracted with Cambridge Technology Partners to assist with the project implementation.
  • Any issues will be resolved in a timely manner at the lowest possible level in order to ensure the success of the project.
  • The Project Coordination Team will develop and execute a plan for end-user training.

Business Units and Set IDs
All of the modules in the SFS are built around the concept of Business Units and Set IDs. However, to understand these structures, you need to be familiar with the two types of tables that the SFS uses to store information.

Transaction tables store detail information about day to day business activity.
Examples are:

  • Purchase order entries
  • Payments
  • Receipts
  • Budget entries

Control tables store information that defines the accounting structure and processing rules. Examples are:

  • Chartfields
  • Calendars

Business Units are an integral part of the SFS. Each Business Unit represents an organizational or a reporting entity. Transaction data is stored in the system by Business Unit. In other words, when you enter a transaction into the system, you must associate the amount of that transaction with a specific business unit. There is one Business Unit per campus for General Ledger. In most cases, there will be only one Business Unit per campus for Accounts Payable and Purchase Order also, however, a campus may make a decision to establish more than one business unit for those modules. The naming convention being adopted for SFS is UW + the 3 character institution abbreviation. The Business Units for the 16 campuses are listed below:

  • UWADM - UW System Administration
  • UWCOL - Colleges
  • UWEAU - Eau Claire
  • UWEXT - Extension
  • UWGBY - Green Bay
  • UWLAC - LaCrosse
  • UWMIL - Milwaukee
  • UWMSN - Madison
  • UWOSH - Oshkosh
  • UWPKS - Parkside
  • UWPLT - Platteville
  • UWRVF - River Falls
  • UWSTP - Stevens Point
  • UWSTO - Stout
  • UWSUP - Superior
  • UWWTW - Whitewater

SetIDs are also integral to the SFS. They identify the set of tables that define your accounting structure and rules, such as the chart of accounts and accounting calendar tables. In many cases, the SetID will be the same as the Business Unit. However, it is more efficient to set up some tables centrally and have all campuses access them. For example, we will have one set of account numbers (formerly known as class codes or object classes) for all of the campuses. The account number table is assigned a SetID of SHARE which allows all campuses to access it without needing to duplicate the data.

The following diagram illustrates how UW System Administration and UW Milwaukee can share access to the fund number table, but can retain their own organization codes (formerly UDDS codes).

business units and table sets

SFS Charfield Mapping:
The backbone of the general ledger is the chart of accounts-the fields and values that provide a common language for identifying your business transactions. The components that make up the chart of accounts and provide it with an overall structure in Peoplesoft are called chartfields. Specific chartfields will be available for an institution to meet its own needs; and other chartfields will be shared to meet overall budget, financial reporting, and statutory requirements.

The following chartfield map identifies each Peoplesoft chartfield and its corresponding chart-of-account element in the current UWPC general ledger system. In addition, it specifies the institution responsible for maintaining the chartfield for it's particular needs.

PeopleSoft Chartfields UWPC Responsibility
Budget Year arrow.gif Fiscal Year UW-System Administration
Fund arrow.gif Fund UW-System Administration
Program arrow.gif Activity UW-System Administration
Organization arrow.gif UDDS Institution
Account arrow.gif Object Class UW-System Administration
Project/Grant arrow.gif Account Institution
Subclass arrow.gif None Institution

Chartfield Definitions:

Budget Year - Budget year is the same as fiscal year and is carried on each detail transaction to identify it to a particular fiscal year.

Fund - The fund structure in the shared financial system will be the same as the current fund or appropriation structure in the UWPC general ledger. Each fund needs to be in balance in a double entry accounting system.

Program - Program chartfield will replace the current activity code in the UWPC general ledger.

Organization - The organization chartfield will replace the DDS code in the Shared Financial System. The chartfield will be maintained by the institution and used to meet local needs. When combined with other chartfields, it forms the basis for organization budgets that track expenditures and revenues.

Account - The account chartfield will replace the object class code in the Shared Financial System. Each account is assigned a type according to its reporting function of assets, liabilities, equity, revenue, and expenditures.

Project/Grant - Project/grant chartfield captures and controls project or grant information. This chartfield will be maintained by the institution and used to meet local needs.

Subclass - The sub classification chartfield lets you define in greater detail the revenue and expenditures recorded in the account chartfield. This chartfield will be maintained by the institution and used to meet local needs.