chart structure people soft

7/29/2019 Chart Structure People Soft

1/22

Office of Finance and Treasury Chart of Accounts Design Final Report

Page 1 of22 Princeton University Confidential

Chart of Accounts Design

Chart Structure Definition

April 2012


2/22



Contents

Document Purpose ................................................................................................................................. 3

Audience ................................................................................................................................................. 3

Overview ...................................................................................................................................................... 3

Chart Structure Definition ......................................................................................................................... 3

The New Chart String ......................................................................................................................... 5

Chartfield Definitions: ............................................................................................................................ 6

Business Unit .......................................................................................................................................... 6

Account .................................................................................................................................................. 7

Fund ........................................................................................................................................................ 8

DeptID .................................................................................................................................................. 10

Program ................................................................................................................................................ 10

Project ........................................................................................................................................................ 11

Site ........................................................................................................................................................ 12

Function ................................................................................................................................................ 13

Chartfield to Chartfield Relationships .................................................................................................... 14

Attributes ................................................................................................................................................... 15

Option 1 and 2 Fields ................................................................................................................................ 16

Trees ........................................................................................................................................................... 16

Financial Information Model ................................................................................................................... 18

Terminology................................................................................................... Error! Bookmark not defined.

Chartfield Ownership and Maintenance ................................................................................................ 21

Appendix: .................................................................................................................................................. 22

Chartfields: ........................................................................................................................................... 22

Tree Drafts: ........................................................................................................................................... 22

Financial Dimensions Matrix: .............................................................................................................. 22

OARP Model: ....................................................................................................................................... 22


3/22



Document Purpose

This document is intended to provide a summary of the new chart of accounts (COA) structure developedfrom July 2011 through April 2012. This document includes detailed definitions of each chartfield,examples, and additional chartfield related concepts such as attributes and trees.

Audience

The intended audience for this document are those who have been actively engaged in the chart ofaccounts design project, including the project working group and especially those individuals (functionaland technical) who will be responsible for planning, designing and implementing the PeopleSoft 9.xFinancials and any integrated systems which require the new chart structure.

Overview

Princeton Universitys Office of Finance & Treasury has undertaken a comprehensive redesign of its sixty

year old chart of accounts structure. This redesign required feedback from multiple departments acrosscampus to ensure the project team successfully captured and met the needs of the entire organization. The

ultimate measure of success of this project will be the improvements in the quality of the data and reportsavailable for financial and business decisions.

This document captures the chart structure definition. Examples of each chartfield are provided in thisdocument to give insight into what each of the chartfields represents and the relationships between themin the chart structure. Lists of representative values and draft hierarchy structures developed to date have

been provided in the appendix. A full listing of the values tested to date is included in the proof ofconcept document. Please note, during system implementation, the representative values will continue to

be developed into complete value sets and hierarchies to support the production environment.

Chart Structure Definition

The chart of accounts structure refers to the coding used to capture financial transactions. It is composedof a string of chartfields used to record the Universitys financial transactions. Princetons new chart ofaccounts structure was designed to meet its functional requirements and to resolve issues associated withthe current structure. Each chartfield has been clearly defined in order to use each chartfield consistently.

A representative set of values has been defined and reviewed for practical use during the proof of concept(POC). The actual value sets and numbering structure will be established during the system design phasein conjunction with the data conversion effort. The recommended size was established for each chartfieldin order to allow for future growth, which is a limitation in the current state. Below are the agreed uponchartfields, their definitions and uses for recording financial transactions.

Historical Context

The current chart of accounts is Project/Grant-centric, in that most financial transactions utilize theProject/Grant as the primary chartfield for recording activity. The Project/Grant field is used for a largevariety of departmental accounting needs and over time has incorporated concepts that are typically heldin other chartfields. For example, the Project/Grant field embeds both Account and DeptID information.

As a result, Princetons reporting flexibility is very limited.


4/22



Mapping Old to New Chartfields

To adopt the best practices of COA design and systems implementation, the logic held in the

Project/Grant field today will be unpacked and placed into separate chartfields. This will minimize thecustomizations required for systems implementation and improve the reporting capability from

PeopleSoft and the Information Warehouse.

The mapping of the old and new COA is illustrated below:

Currentstructural issues and future state solutions:

Natural accounts (expenses, revenues, assets and liabilities) can be found in both the Account andProject/Grant chartfields. In the future state, all of this information will be maintained in theAccount chartfield.

The department originating the service charge (e.g. print shop) and the reporting departmentreceiving the charge are coded together in a single transaction. In the future state, the DeptID

primarily represents the reporting department. The originating department information (usually

the internal revenue earned) will be captured on a separate transaction line.

Fund is currently coded as part of the Project/Grant chartfield and also redundantly derived intothe Fund chartfield. In the future, it will be captured in detail in the Fund chartfield. Note:

Sponsored research will use high level Fund codes and capture detail in the Project.

Groupings of transactions or what is being done are captured in the Project/Grant field. In thefuture, the what is being done will be split between the Project and Program fields. Projectswill be used primarily for sponsored research and capital project activities. Others, like seminars

and conferences will become Programs.

Building and Function are carried as attributes on Project/Grant. To improve flexibility inreporting, they will each become chartfields (Site and Function, respectively).

PeopleSoft

Delivered

ChartFields

Dept IDAccount AffiliateProjectBU FundFund

AffiliateSiteProgram

Business

UnitAttributes

Building

ChartField Dimensions (GL)

FundOriginating

DepartmentAccount

14 15

_ _

4 5 6

_ _ _

1 2 3

OriginatingDepartment

FundRptgDept

Account

Project/Grant

Project or Grant

_ _ _

7 8 9 10 11 12 13

_ _ _ _ _ _ _

Alt Account

Fund

Function

Function


5/22



The New Chart String

The chart string is the set of chartfields that represents how a financial transaction is coded. It iscomposed of the combination of all chartfields coded for a transaction, though not every chartfields willnecessarily be filled for each transaction.

In the past, the question has been to which Project/Grant do I post the entry? In the future, the questionwill be to which chart string do I post the entry?

The first thing most users notice about the new chart string is the length. However, some fields are neverfilled in by the end users (Affiliate, Fund Affiliate and Alt Accountto the right). Rather those are

populated as part of PeopleSoft delivered processing and will not be detailed in this document. Other

fields will only be used by certain audiences. Site, for example, will be used primarily by Facilities andFunction will be coded according to clearly defined rules (to be developed during implementation).

Only the Business Unit, Account and Fund chartfields are required for all transactions. The DeptID willbe required for all academic and administrative transactions, but the decision as to whether DeptIDs will

be required for all balance sheet transactions has not been finalized. Program and Project are optionalfields (note: they are required for certain transactions). Business processes and accounting policy will

determine when the Program and Project fields will be required.

Business Unit Account Fund DeptID Program Project Function Site Affiliate Fund Affiliate Alt Account

-5 -5 -5 -5 -5 -8 -2 -6 -5 -5 -5

PU XXXXX XXXXX XXXXX XXXXX XXXXXXXX XX XXXXXX XXXXX XXXXX XXXXX

FAC XXXXX XXXXX XXXXX XXXXX XXXXXXXX XX XXXXXX XXXXX XXXXX XXXXX

FIC XXXXX XXXXX XXXXX XXXXX XXXXXXXX XX XXXXXX XXXXX XXXXX XXXXX

SEEGR XXXXX XXXXX XXXXX XXXXX XXXXXXXX XX XXXXXX XXXXX XXXXX XXXXX


6/22



Chartfield Definitions:

Quick Reference Guide

# / Style CHARTFIELD SHORT DESCRIPTION PURPOSE

5 Alpha Business Unit Legal EntityWho is legally responsible for this

transaction?

5 Numeric Account Natural Account How is this classified?

5 Alpha/

NumericFund Fund Source How is this being funded?

5 Numeric DeptID Responsible Unit Who is responsible for the transaction?

5 Alpha/

NumericProgram On-going Activity What is being done?

8 Numeric ProjectIDGrant or Project (defined time

limit)What is being done and by when?

6 Numeric SiteCampus Building / Off

Campus SiteWhere is the cost incurred?

2 Numeric Function Functional Categorization Why are we doing this?

Required

Conditional

Automated

Required fields must always have a value.

Conditional fields are populated based on business situation and rules.

Automated fields will not be populated by users. They will be populated

by programs or interfaces.

Business Unit

The Business Unit has additional functionality apart from the other chartfields. It is a basic component inPeopleSoft financial applications and is included here along with the other chartfields. Business Unit isdefined as the legal entity for all financial transactions. (Note: The Business Units other capabilities arerelated to running PeopleSoft processes and reports).

This chartfield answers the question: Who is legally responsible for this transaction?

Business Unit is required on all transactions. Note: there is an option that allows setting a defaultfor the most frequently used Business Unit by the end user.

Business Unit consists of up to five alpha-numeric characters. Short Description: Legal Entity. Business Unit will be a balancing field. Balancingrefers to the process of creating financial

data that is maintained as if it were in a separate set of books. For example, in a journal entry thetotal dollar amount debited and credited net to zero, the journal is considered balanced. InPeopleSoft, additional fields can be identified for balancing purposes. During implementation,the decision of which chartfields require a balanced set of transactions will be re-confirmed.PeopleSoft delivered functionality provides a mechanism to auto produce balancing chartfield

lines in the system.


7/22



Examples: Princeton University, Forrestal Agricultural Center, Forrestal Investment Corp and SeegerFund

Below is the current listing ofPrinceton Universitys Business Units and groupings:

Level_1 Level_2 Level_3

All Business Units

Princeton University Consolidated

Princeton University

Forrestal Agriculture Center

Forrestal Investment Corp

Seeger Fund

Unconsolidated Business Units

External Agencies

Founding FathersRECAP

Account

The Account chartfield is defined as the classification of the nature of financial transactions (assets,liabilities, net assets, revenues or expenses).

This chartfield answers the question: How is this classified for accounting?

Account is required on all transactions. Account values consist of five numeric characters following a classic numbering convention:

o 1xxxx = Assetso 2xxxx = Liabilitieso 3xxxx = Net Assetso 4xxxx = Revenueo 5xxxx / 6xxxx / 7xxxx = Expenseso 9xxxx = Statistical accounts

Short Description: Natural Account. Account is not a balancing field.

Examples: Expense accounts such as Materials and Supplies, Travel, etc.

The level of granularity of the Account chartfield is still being refined. For example, some accounts willincrease granularity such as materials and supplies by breaking out office supplies, lab supplies, medicalsupplies, etc. Other accounts that currently exist in Project/Grant will be consolidated together such as


8/22



bond receivable with the detail moving over to the Fund chartfield. Note: All balance sheet accounts thatare currently booked as a Project/Grant or are recorded outside of the General Ledger will become

Accounts in the new chart structure.

Princeton Universitys Accounts will be grouped as follows:

Level_1 Level_2 Level_3 Level_4

All Accounts

Balance Sheet

Income Statement

Revenue

Tuition and Fees

Govt Contracts

Private Gifts Contracts

Sales Auxiliary

Other SourcesInvestment Earnings

Net Assets Released

Internal Revenue

Funds Allocation

Expenses

Statistics

Fund

The Fund chartfield is defined as the primary structural unit of accounting used to track the source offunding.

This chartfield answers the question: How is this being funded?

Fund is required on all transactions. Fund values consist of one alpha character followed by four numeric characters. Short Description: Fund Source. Fund is a balancing chartfield.

Examples: General discretionary funds, restricted gifts, endowment income, grants, etc.

Fund accounting classifies Funds for accounting and reporting purposes in accordance with regulatory

requirements or limitations imposed by donors, parties outside of Princeton University, or the Board ofTrustees. Funds will have defined restriction levels and carry forward (inception to date) balances.

The level of granularity will record each funding source as a unique identifier, except for sponsored

research and capital projects.


9/22



For sponsored research and capital projects a specific project is indicated by the Project chartfield, ratherthan the funding source. The funding for capital projects will be captured in the Fund chartfield (e.g.

Bond 200x, Major Maintenance) and then transferred to the Capital Plant Fund.

Princeton Universitys Funds will be grouped as follows (for all levels see appendix):

Level_1 Level_2 Level_3 Level_4 Level_5

All Funds

Fund Categories

General & Other Central Funds

Designated

Non Designated

Non Operating

Restricted Gifts

Unallocated Gifts

Planned Gifts

Restricted Departmental Gifts

Plant Gifts

Endowment (Primary Pool)

True

Quasi

Plant Fund

Capital Projects

Other Invested

Secondary Pool

ITIP - Invested

External TrustOther Invested Sub

Grants & Contracts

Government

Federal

State

Local

International

Non Government

Foundation

Corp

Student Loan

University Debt

Agency

Student Organizations


10/22



DeptID

The DeptID chartfield is defined as the lowest level of the organization that is responsible for revenue &expense recording for all ledgers.

This chartfield answers the question: Who is responsible for the transaction?

DeptID is required on all revenue and expense transactions (balance sheet pendingimplementation design).

DeptID values consist of five numeric characters. Short Description: Responsible Unit. DeptID is not a balancing chartfield.

Examples: WWS Center for Intl Security Studies, UHS Inpatient Services, etc.

The level of granularity of DeptID will be expanded from the current state. Departments, such asFacilities will have several new DeptID values added to reflect the operational management structure.

Some DeptID values may be created for reporting purposes only (to be determined duringimplementation).

Note: Requiring a department on all balance sheet lines is under consideration.

To date, four different groupings for DeptID have been identified for development: PRICOM, BudgetOffice, VP Region and Cabinet. Below an example grouping for Princeton Universitys DeptIDs.

Level_1 Level_2 Level_3 Level_4 Level_5 Level_6 Level_7

All Departments

Princeton Departments

Academic Departments

General Academic Departments

Woodrow Wilson School

WWS Administration

Business & Facilities Office

Office of Grad Career Svc Alum

Computing Services Office

Office of Public & External Af

Financial & Grants Mgmt Office

Office of Graduate Admissions

Undergraduate Program Office

Dean's Office

Graduate Program Office

WWS Centers and Programs

Bendheim Thoman CRCW

Ctr for Arts, Cultural Policy

Ctr for Intnl Security StudiesCtr for Study of Democratic Pol

China and the World Program

Education Research Section

Program

The Program chartfield is defined as ongoing activities owned and managed by one or more departments.These activities typically span Funds and Accounts, and do not have specified beginning and end dates.


11/22



This chartfield answers the question: What is being done?

Program is conditional, may or may not be required on transactions. Program values consist of one alpha character followed by four numeric characters. Short Description: On-going Activity. Program is not a balancing chartfield.

Examples: Seminars, conferences, faculty recruiting, etc.

Three distinct uses of Program have been identified:

Department specific: Only one department will sponsor and be financially responsible for theProgram.

Inter-departmental: Two or more departments will share responsibility for sponsorship and allinvolved departments will be financially responsible for the Program.

Faculty specific: Used to track balances controlled by a faculty member who has responsibilityfor the balance.

Princeton Universitys Programs will be grouped as follows:

Level_1 Level_2

All Programs

Interdepartmental Programs

Department Programs

Faculty

Project

The Project chartfield is defined as collection of detailed transactional information related to grants, non-grant sponsored research, capital and other initiatives with specific beginning and end dates.

This chartfield answers the question: What is being done and by when?

Project is conditional, may or may not be required on transactions. Project values consist of eight numeric characters. Short Description: Grants or Project (with specified start and end dates). Project is not a balancing chartfield.

Examples: Activities with beginning and end dates such as sponsored awards and capital projects. Notethese are often owned or managed by one department.

Level of detail: Each sponsored award and capital project will receive a unique Project ID. All revenuesand expenditures incurred will be recorded to that one unique ID. A Project may have more than one PI(Principal Investigator) or manager.


12/22



Princeton Universitys Projects will be grouped as follows:

Level_1 Level_2

All Projects

Capital Projects

Grants

OIT

Other

Site

The Site chartfield tracks buildings and properties that have a need to capture income and expenses (i.e.property or building where the revenue is generated and costs incurred and / or being performed). The

Sites will be rolled up to represent geographic areas.

This chartfield answers the question: Where is the revenue generated, or the cost incurred?

Site is conditional and will primarily be used on selected Facilities transactions. Site values consist of six numeric characters. Proposed Short Description: CampusBuilding / Off Campus Site

Examples: Jadwin Hall, Brown Hall, etc.

This field will be managed in coordination with Facilities and will mirror the Site usage in the Archibussystem. Note: This chartfield is intended to capture income and expense information at an aggregate level.Archibus and other PeopleSoft applications (Asset Management and Real Estate) handle more granularrequirements like rental income generated from leases.

Princeton Universitys Site tree will be further developed during implementation, the draft tree appears

below:


13/22



Level_1 Level_2 Level_3 Level_4 Level_5

All Sites

Princeton University

Americas

USA

Main Campus

Non-Main Campus

Residential

Forrestal

Function

The Function chartfield is defined as the identifier for transactional reporting that requires functionalcategorization for NACUBO (e.g., general administration and institutional support) and A21 reporting.Consideration has also been given to using the Function chartfield to capture teaching budget information.If this is adopted, teaching budget specific reports can be generated using this chartfield.

This chartfield answers the question: Why are we doing this?

Function is under consideration for auto-population such that end users would not code this field. Function values consist of two numeric characters. Proposed Short Description: Functional Categorization.

Examples: Instruction, Research, Academic support, etc.

Function supports the NACUBO and A21 categorizations and reporting

Princeton Universitys Functions will be grouped as follows:


14/22



Level_1 Level_2

All Functions

Instruction (Teaching Budget)

Instruction all Other (Non Teaching Budget)

Dept ResearchOrganized Research

Other Institutional Activities

Academic Support

Department Administration

Library

Student Services

Institutional Support (G&A)

Scholarships and Fellowships

Auxiliaries

Independent Operations

Chartfield to Chartfield Relationships

The project team spent considerable amounts of time discussing chartfield to chartfield relationships.When discussing the relationships between the chartfields, they fall into one of two categories: validation

and granularity.

Validation: PeopleSoft delivers combination checking functionality which uses rules to define thechartfield to chartfield validation relationships. These rules then produce combinations of chartfieldvalues that are either allowed or disallowed (whichever is more concise), thus protecting the integrity ofthe financial data. During implementation, these relationships will be further defined.

Granularity: During the drafting of representative values, as the level of granularity was established,chartfield to chartfield relationships were also discussed to address where the most granular level ofinformation needed to be captured. The following were discussed as part of this effort:

Account - Fund: Account represents assets, liabilities, net assets, revenues and expenditures. The Fundrepresents funding sources. Conceptually the two overlap in the area of Assets and Liabilities:

Decision: The Fund will capture the granular level of information (having more values) and theAccount will be summary in nature for the following:

o AssetsInvestments (such as Primary Pool)o LiabilityDebt, Bonds, Commercial Paper, etc.

Account - Fund: Account and Fund also must work together when addressing Fund purpose and userestrictions. The setup of the restrictions and transaction recording should use a consistent methodology

to ensure proper Fund restriction reporting. The following options have been identified:


15/22



o The Fund may carry attributes to capture the purpose restriction status (scholarships,departmental uses, etc.).

o Individual Accounts may be used to indicate the net asset class accounting restriction (forexample, Perm Restricted Revenue, Unrestricted Revenue and Temp Restricted Revenue

instead of one account called Revenue).

Note: The Funds may be organized in a tree structure such that type of restriction is indicated bythe hierarchy. This solution is optimal for PeopleSoft functionality.

DepartmentProgram: As noted in the definition, Program is for use by departments to track specific

activities for reporting purposes. Some departments will have unique requirements and therefore, mayuse Program for different types of activities than others. For example, many academic departments have

ongoing lecture series they may want to track as Programs. The Art Museum may want to also useProgram to track exhibits. Athletics may determine they will track sports teams as separate Departmentsand then use Program to capture actives such as recruiting for each team.

FundProgram (for Faculty): A key requirement is the ability to record and report various Fundbalances for a given faculty member. The combination of Fund and Program will be used to separate and

report on non-sponsored Project balances by using a specific Program number for each faculty member. Atypical faculty member in the sciences controls five to ten different Fund balances (corporate gifts, central

startup funds, departmental funds, research rebates, etc.) that will be easily identified by the combinationof Fund and Program.

FundProject (for Capital Projects): A Capital Plant Fund will be used in combination with Projectand the Fund Affiliate field to track various sources of funding for each capital project. The Capital Plantfund may include a variety of funding sources, each of which will be identified by the Fund Affiliate

field.

FundProject (for Sponsored Research): A high level Fund in combination with a Project for eachgrant or other sponsored research initiative will be used to track the source of funding for a particular

effort. Faculty responsibilities (including acting as the PI) for these Projects will be set up as part of theProject creation / maintenance process.

FundDepartment: Fund can be used to track the source of funding for a particular department(DeptID).

FundProgram/ Project: Fund can be used to track the source of funding for a particular Program /

Project.

AccountOther chartfields: Account is summary in nature. As Account is used to capture the natural

account category, the other chartfields then provide further detail regarding the information. Forexample, royalty income may be recorded by multiple departments.

Attributes

In the current state, Princeton has a custom chartfield maintenance panel for each chartfield. Each panelcontains several custom fields which are commonly referred to as attributes. Most of these attributeswere created primarily for reporting purposes. During the chart of accounts design effort, these attributes

were reviewed to identify the possible need for an additional chartfield.


16/22



Some of these custom fields may become PeopleSoft attributes (newer functionality) in the future state,but most will likely be replaced with PeopleSoft 9.x delivered configurable functionality. For example,

many of the attributes on Project/Grant (e.g., start and end dates) today are delivered fields in thePeopleSoft Project Costing application.

Other attributes may still be required. For example, the Fund chartfield has the level of restriction

identified as an attribute. There are four related fields to capture the status on the principal and payout forendowments. These fields will likely continue to be attributes in the future state. For a complete list of

the attributes for the chartfields see the Financial Dimensions document in the appendix.

Option 1 and 2 Fields

In the current state, there are two other Princeton custom fields: Option1 and Option2. These fields

are free text fields and do not represent the consistent definition required of a chartfield. Further, thesefields do not have a limited set of values for coding and their data is not carried on the financial

transactions across the financial systems (AP, PO and GL). Rather, these fields are used for specializedreporting purposes by the end user community. Because they are free text, there are no clearly definedsets of values and as a result the reporting on these fields cannot be standardized. The open nature of the

field information forces the creation of custom reporting, filtering and sorting solutions for each differenttype of information being sought by each department. In some cases other chart fields will eliminate the

need for use of option 1 and option 2 in the future state.

During implementation, the need for these fields and their use will be evaluated. Where possible, theadditional information captured in the option 1 and 2 fields will be captured in the system configuration.

If there is still a remaining need, additional solutions will be considered (customizations, sub-system datacapture, etc.).

Trees

Trees in PeopleSoft General Ledger are used to organize and maintain the chartfield values. Trees add an

intuitive, visual layer to show where the detail items in the chart of accounts fit into the big picture. Treescan be designed, either in detail or summary, from the top down using the simple, graphical PeopleToolsTree Manager.

Trees are used across all of the PeopleSoft fields to facilitate:

Consolidations: PeopleSoft delivered consolation processing uses trees to create sets ofchartfield values that can then be attached to a consolidation rule. The consolidation rules thendrive the processing and production of journals.

Reporting: PeopleSoft reporting tools (nVision, query) use the tree structure to isolate sets ofchartfield values for selection (or exclusion) when creating reporting output.

Allocations: The PeopleSoft allocation tool uses rules to automate production of journal entries.These rules again, use the tree structures to select specific chartfield value sets for processing.

Chartfield Combination Editing: Combination editing defines the allowable relationshipbetween chartfields. Trees are used to select chartfield value sets that for inclusion or exclusionfrom these rules.

Closing Rules: PeopleSoft close processing allows you to selectively process certain chartfieldvalue sets (identified using trees) for rollover at the end of the year.


17/22



Special Features:

Trees are effective dated: When chartfield values are added they are effective dated in thesystem. By effective dating the trees, a snapshot is created of the hierarchical structure at a point

in time. This allows reports to be run using historical hierarchies (if required).

Trees can be flattened: PeopleSoft tree functionality can also be leveraged by other reportingtools such as Hyperion and the Information Warehouse. The trees are flattened into a file thatcan then be uploaded into various reporting mechanisms.

Different trees can be used for different reporting needs: For example, there can be moresummarized aggregations of Accounts used for central reporting purposes; more disaggregatedtree structures for departmental purposes. There might be different income/expense views foracademic departments than for administrative departments.

Tree Terminology:

LevelsSections of the tree used to organize nodes. NodesSummarization of detailed values such as Account types, groups, etc. Detailed ValuesAccount numbers, departments, etc.

Recommendations:

Centralized maintenance of trees. Integration of tree maintenance with other generalized chartfield maintenance. End user community awareness of trees and tree structures. By allowing the end user community

to access and view trees, they are better able to articulate when they have reporting requirementsand other chartfield maintenance requests.


18/22



Example Tree for Princeton Accounts.

Financial Information Model

As part of the process of determining what should be identified as the chartfields in the new COAstructure, we reviewed and evaluated other components of financial information. While this document

provides insight into the COA structure chartfields, the remaining fields that we reviewed are contained in

the Financial Dimension Matrix (see appendix).

The financial information model tells us the future state flow of financial information across multiplesystems using the new chart structure. There are two types of information that travel across applications:1) Core financial information (identified by the chart of accounts structure) and 2) Additional applicationunique information that does not travel into the General Ledger. Note the application unique information

can be accessed via reports from PeopleSoft or from the Information Warehouse (assuming this data isloaded into the Information Warehouse).

Node = group of detailed

values or other nodes

Detail Value = Account

number in this example


19/22



Financial and Operational Data Capture

Operational

EachApplicationhasUn

iqueData

Financial

Transaction

s

Core ChartFields:

Acct-Fund-Dept-Program-Project-Site

AP/ PO

Unique Data:

Vendor

Location

Etc...

Core CF Data

Assets

Unique Data:

Asset #

Asset

Category

Etc...

Core CF Data

Unique Data:

Jrnl

Description

GL

Core CF Data Core CF Data

Unique Data:

Employee ID

Department

HR

Notes: Core Financial data flows across the applications

(and sub-systems). Each application has unique data that is sent to the

Information Warehouse and can be used forreporting.

Implementation of each application will integratecurrent attributes/ financial dimensions into theUnique Data where appropriate.

Project Costing

Core CF Data

Unique Data:

Project Status

Project Mgr/ PI

Project Type

Core CF Data

Contracts

Unique Data

Agency

Etc...

Unique Data

Status

Etc.

AR

Core CF Data

Core CF Data

Billing

Unique Data

Payment

Status

Etc.

Core CF Data

Grants

Unique Data:

Awards

Proposals

Core chartfields: The chart of accounts design addressed the core chartfields; Account, Fund, Department,Program, Project and Site. The financial transaction data captured in feeder-systems, such as Accounts

Payable and HR, send this data into the General Ledger

Attributes: During the chart of accounts design, additional fields of information captured in the GeneralLedger today (referred to as attributes) have been listed in a financial dimensions matrix for implementation

follow up. These fields capture additional characteristics of the chartfield and are largely used for reporting.While many of these attributes may no longer be required because of improved PeopleSoft functionality,

others will continue to be kept as attributes on chartfield values in the future. The matrix covers definitions,current state information and recommended options for the futuresee appendix for complete list.


20/22


21/22



Chartfield Ownership and Maintenance

As part of the transition from the chart of accounts design to an implementation, continued effort is

required to develop the chartfield values. For each of the chartfields, the following matrix has beencreated to identify the resources responsible for creating the initial value sets, hierarchies and uses in

preparation for loading the values into the new system (typically occurs during the implementation system

build efforts). During the implementation, continued effort will be required to verify the values identifiedand to possibly add more values for additional requirements identified.

This ownership matrix is subject to change based on implementation roles and responsibilities.

Chartfield Value Development OARP

Code Label Definition/ Role

O Owner Resource responsible to create the chartfield values.

A Approver Resource that is accountable for the decisions made.

R Reviewer Resources that provide formal feedback.

P Participant Participates in workshop meetings with Owners to establish chartfield values.

Chartfield Owner Participant (re questors) Reviewe r ApproverAccount Controller's Office Departments Working Group Controller

Fund Budget Office

Controller, Asset Administration,

Development

Director, Asset

Admin Controller

Department Budget Office

Departments, Human Resources,

DOF Budget Director Controller

Program

Director, Financial

Reporting Departments Budget Director Controller

Project Controller

Grants SRA ORPA SRA Director Controller

Capital Capital Budget Asset Administration, Facilities

Director, Asset

Admin Controller

OIT TBD OIT

Director, OIT

Projects Office Controller

Site Controller's Office

Facilties, OIT, University Services,

Athletics

Director, Facilities

Finance Controller

Function Controller's Office Budget Budget Director Controller


22/22


Appendix:

Chartfields:

Representative Values, please see the appendix for the Proof of Concept Summary document.

Tree Drafts:

POC Trees

Financial Dimensions Matrix:

Financial DimensionMatrix

OARP Model:

OARP CF ValueDevelopment

chart structure people soft

Documents