University of Colorado

Chart of Accounts and General Ledger

Conversion Strategy and Process

一月 9, 2018

Chart of Accounts/GL Conversion Strategy and Process

Table of Contents

INTRODUCTION...... 1

CONVERSION PRINCIPLES SUMMARY...... 3

LOAD BUDGETS...... 5

BACKGROUND...... 5 LOAD ENCUMBRANCES...... 7

BACKGROUND...... 7 LOAD ACTUALS...... 9

OVERVIEW...... 9 TECHNICAL ENVIRONMENT DEFINITION...... 9 CHARTFIELD COMBINATIONS VALUES...... 9 PERIOD VALUES...... 9 LOAD OPENING BALANCES PROCESSING SEQUENCE...... 10 LOAD FISCAL YEAR 2000 BUDGETS, ENCUMBRANCES, AND ACTUALS OVERVIEW...... 13

FRS ACCOUNT BALANCES...... 15

BACKGROUND...... 15 SL accounts that map one-to-one to GL account...... 15 GL accounts that do not have SL accounts...... 16 Many SL accounts that map to one GL account...... 16 MONITOR NEW FRS ACCOUNTS AND ATTRIBUTE CHANGES...... 17

BACKGROUND...... 17 MONITOR PROCESS...... 17 PREPARE ‘FRS-TO-PEOPLESOFT TRANSLATION’ TABLE...... 21

‘FRS-TO-PEOPLESOFT TRANSLATION’ TABLE DEFINITION...... 21 FIELD...... 21 DESCRIPTION...... 21 UTILIZATION OF THE ‘FRS-TO-PEOPLESOFT TRANSLATION’ TABLE...... 21 POPULATION OF ‘FRS-TO-PEOPLESOFT TRANSLATION’ TABLES...... 22 PUBLICATION OF ‘FRS-TO-PEOPLESOFT TRANSLATION’ TABLES...... 22 ASSIGNING CHARTFIELD VALUES...... 23 Fund...... 23 Organization...... 23 Program...... 23 Project/Grant...... 24 Sub-Class...... 24 Account ChartField...... 24 FRS ACCOUNT CREATE PROCESS DURING FINANCE/HR IMPLEMENTATION INTERIM PERIOD...... 25

BACKGROUND...... 25 RULES FOR ASSIGNING CHARTFIELD VALUES...... 27

BACKGROUND...... 27 FUND CHARTFIELD...... 27 ORGANIZATION CHARTFIELD...... 29 PROGRAM CHARTFIELD...... 30

Page i June 10, 1999 D:\Docs\2017-07-20\01d63f387f1a3875d6c415b94cc6b8ec.doc Chart of Accounts/GL Conversion Strategy and Process

Table of Contents

PROJECT/GRANT CHARTFIELD...... 30 ACCOUNT CHARTFIELD...... 30 Issues Addressed Related to the Account ChartField...... 30 How Cash is Handled in PeopleSoft...... 30 User Options Object Codes...... 30 Exceptions...... 30 One FRS Object Code Category Mapping to Multiple Account ChartField Categories...... 30 SUB-CLASSIFICATION CHARTFIELD...... 30 DATA CONVERSION OVERVIEW...... 30 MATCHING FRS CONTROL/OBJECT CODES TO PEOPLESOFT ACCOUNT CHARTFIELD VALUES...... 30 SPEEDTYPE TABLE...... 30

Page ii June 10, 1999 D:\Docs\2017-07-20\01d63f387f1a3875d6c415b94cc6b8ec.doc Chart of Accounts/GL Conversion Strategy and Process

Introduction

Introduction This document outlines the strategy A.S.P. will follow to convert and load legacy financial systems information (i.e.: FRS, SEBS, HSC budget system) into PeopleSoft’s General Ledger module. The document addresses the following areas:  conversion principles summary  load Budget journals  load Encumbrances  load Actuals opening balances  monitor new FRS Account and attribute change process  process to create FRS Accounts during Finance/HR Implementation interim period  rules to assign values for non-defaulting ChartFields  data conversion overview  matching FRS Control/Cbject codes to Peoplesoft Account Chartfield values  SpeedType table

June 10, 1999 D:\Docs\2017-07-20\01d63f387f1a3875d6c415b94cc6b8ec.doc Chart of Accounts/GL Conversion Strategy and Process

Introduction

Page intentionally left blank

Conversion Principles Summary

Conversion Principles Summary The four campuses and system administration were charged with the task of determining which FRS Accounts should be converted to PeopleSoft ChartField combinations.

For conversion purposes, FRS Accounts were looked at in three major groups:  GL Accounts without any associated SL Accounts  SL Accounts that map one-to-one to one GL Account  Many SL Accounts that map to one GL Account

Based on campus analysis, all FRS Accounts were assigned one of three conversion status categories:

 Convert the Account will become a PeopleSoft ChartField combination  Not-Convert the Account will be deleted in FRS and not be converted into PeopleSoft  Combined the GL Account will be combined with its SL Accounts and converted to a PeopleSoft ChartField combination Note: This only applies to GL Account that map one-to-one to a single SL Account

For details, refer to the ‘Conversion Principles’ document on the A.S.P. web site.

Conversion Principles Summary

Load Budgets

Load budgets Background For fiscal year 2000, University departmental base budgets (excluding HSC) will be entered into the legacy system SEBS (Single Entry Budget System). Budget transactions from SEBS will be loaded into the fiscal year 2000 FRS system using existing interface jobs.

HSC departmental budgets and Sponsored Programs budgets for all campuses will be loaded into the FRS. The Transaction Generator job (FYAE) will create fiscal year 2000 budget transactions using fiscal year 1999 budget balances for continuing HSC departmental budgets and continuing Sponsored Programs FRS Accounts. These fiscal year 2000 budget transactions will be loaded into fiscal year 2000 FRS.

An interim interface job (JFDA) will:  extract budget transactions from fiscal year 2000 FRS  convert the FRS Account number to the corresponding PeopleSoft ChartField combination value  reformat the transactions to the layout of PeopleSoft budget journals  create a data file of the budget journals

These journals will then be imported into PeopleSoft, using the Budget Journal Load process, edited, and posted to the Budget ledgers. In a separate process, individual budget salary details from SEBS will be loaded to the Personnel Budget table (a CU developed table). This table stores budget salary details by position.

This interim process will be operational from July 1st through November 30th 1999, as the PeopleSoft Payroll module is scheduled for implementation December 1st 1999. At that time, SEBS, Health Sciences Center’s Budget system, and FRS will be scheduled for decommission. Future budget transactions will be generated and processed from within the PeopleSoft General Ledger and Payroll modules.

Load Budgets

Load Encumbrances

Load Encumbrances Background Encumbrances will be loaded into fiscal year 2000, using fiscal year 1999 balances that exist in FRS and the FRS Transaction Generator job (FYAE). As part of the FRS-to-PeopleSoft conversion process, FRS encumbrance transactions will be converted and posted into the PeopleSoft General Ledger module.

Starting July 1st 1999 the following Payroll generated transactions will be loaded into fiscal year 2000 FRS:  encumbrance transactions  encumbrance re-establishment transactions  encumbrance liquidated transactions established via journal entries

Also starting July 1st 1999, encumbrances liquidated by encumbrance modification transactions or journal entries will continue to be loaded from the legacy Cullinet system (A/P system) into FRS fiscal year 2000 using existing interface jobs.

An interim interface job (JFDA) will:  extract the transactions identified above from fiscal year 2000 FRS  convert the FRS Account number to the corresponding PeopleSoft ChartField combination values  reformat the transactions to the layout of PeopleSoft encumbrance journals  create a data file of the encumbrance journals Note: This process summarizes Payroll encumbrances into a single journal that have the same ChartField combination value.

These journals will then be imported into PeopleSoft, processed by PeopleSoft’s Journal Load, edited, budget checked, and posted to the Actuals ledgers. In a separate process, individual salary and benefits encumbrance detail will be stored in the Encumbrance Detail table (a CU developed table). The detail in this CU specific table will not be summarized.

This interim process will be operational from July 1999 through November 1999 month-end, as the PeopleSoft Payroll module is scheduled to be implemented December 1st 1999. At that time, the legacy Payroll system, Cullinet, and FRS will be scheduled for decommission. Future encumbrance transactions will be generated and processed from within the PeopleSoft General Ledger, Purchasing, A/P, and Payroll modules.

Load Encumbrances

Load Actuals

Load Actuals Overview Following the 4th year-end close of fiscal year 1999 FRS (the week of July 26th 1999) and the roll- forward to fiscal year 2000 FRS, all fiscal year 2000 FRS opening balances will loaded into the PeopleSoft General Ledger.

Technical Environment Definition The following is a representation of PeopleSoft’s Actuals ledger table. Note: For illustration purposes, not all of the Actuals Ledger table fields are listed below:

ChartField combinations values Periods t t t r i s g d d m n n r a s n

n 0 1 2 3 4 5 6 7 8 9 10 11 12 998 999 C a a u e

a u O r r U l o

s Y F g

c G C s c t / i o - c s t t r e b c s A e i g P u t e n j d i S a s o t u r u S B P B

ChartField combinations values In the above table, the ‘ChartField Combination Values’ columns store the ChartField values that make up combinations.

Period values  Period 0 Stores each ChartField combination’s opening balance for a given fiscal year. ChartField combinations with:  Balance Sheet Accounts ChartField values (Asset, Liability, and Fund Balance account types) will have opening balances that have been carried forward from FRS fiscal year 1999 closing balances.  Income Statement Accounts ChartField values (Revenue and Expense account types) will have zero opening balances. Exception ChartField combinations that have Project/Grant ChartField values (identifying Capital Construction and Sponsored Programs activities) will have opening balances carried forward from fiscal year 1999 closing balances.

 Period 1 through 12 Stores the net balance of activity for each accounting Period.

 Period 998 Stores adjustments made following a fiscal year’s closing balances.

Load Actuals

 Period 999 Stores the fiscal year’s closing balances of Assets, Liabilities, and Fund Balance (Balances of Revenue and Expenses have been rolled into Fund Balance). Exception: Revenue and Expenses of ChartField combinations that have Project/Grant ChartField values (identifying Capital Construction and Sponsored Programs activities) will not be zeroed out.

Load Opening Balances Processing Sequence

1. Load FRS fiscal year 2000 opening balances into PeopleSoft fiscal year 1999 (Period 12) 1a) Following the 4th year-end close of fiscal year 1999 FRS (the week of July 26th 1999) and the roll-forward to fiscal year 2000 FRS, a conversion batch process will be run that will examine each FRS account in fiscal year 2000.

FRS Accounts that the campuses have marked for conversion will be converted to the corresponding ChartField combination. The ChartField combination and the balance amount will be formatted into PeopleSoft Actuals journal entries. These journals will then be edited, budget checked, and posted to PeopleSoft’s Actuals ledger for fiscal year 1999, Period 12.

1b) PeopleSoft’s Year-End-Close batch process will then be run, and PeopleSoft’s fiscal year 1999, Period 12 balances will be rolled-forward to fiscal year 2000, Period 0.

 Balance Sheet accounts (Asset, Liability, and Fund Balance account types) will have the fiscal year 2000 opening balances that have been carried forward from fiscal year 1999 closing balances.  Income Statement accounts (Revenue and Expense account types) will have zero opening balances. Exception – ChartField combinations that have Project/Grant ChartField values (identifying Capital Construction and Sponsored Programs activities) will have fiscal year 2000 opening balances carried forward from fiscal year 1999 closing balances.

2. Reconciliation Process 2a) FRS Control/Object code categories Balances of FRS Control/Object code categories (i.e.: Cash and Investments, Student Tuition, Postal Costs) will be compared to the balances in PeopleSoft. The current report ‘AD043’ will be used to determine the balances of FRS Control/Object code categories. Exceptions will be reported.

2b) FRS to PeopleSoft Comparisons A table containing current FRS ten-digit accounts, new PeopleSoft ChartField combination values and the converted balances will be created in PeopleSoft. Query/Reports will be designed to summarize and compare data from the warehouse source to the PeopleSoft target.

Note: The Reconciliation process will be run following the update to fiscal year 2000 Period 0 with FRS adjustments to closing balances for 1999 fiscal year.

3. Adjustments Applied to Fiscal Year 1999 must be Applied Manually

Load Actuals

3a) Any adjustments or ‘on-top’ entries made to FRS closing balances fiscal year 1999, must also be manually applied to PeopleSoft fiscal year 1999, Period 998.

Adjustment transactions must be manually translated to the corresponding PeopleSoft ChartField combinations. The translated ChartField combinations must be manually entered into PeopleSoft, using the appropriate online panels. These transactions must then be edited, budget checked, and posted to the PeopleSoft Actuals Ledger for fiscal year 1999.

PeopleSoft’s Year-End-Close batch process will then be re-run. Refer to step 1 for details.

Note: The activities in this step must be repeated each time that adjustments are applied to the closing balances of FRS fiscal year 1999.

Note: The reconciliation process must also be re-run.

Load Actuals

Load Fiscal Year 2000 Budgets, Encumbrances, and Actuals Overview Load Fiscal Year 2000 Budgets, Encumbrances, and Actuals Overview PeopleSoft Fiscal Year 1999 Fiscal Year 2000 July 1, 1998 to June 30, 1999 July 1, 1999 to June 30, 2000 ------Accounting Periods------Accounting Periods------0 1 thru 11 12 998 999 0 1 thru 11 12 998 999 Account (3) (1b) Types (1a) Adjustments PeopleSoft Year-End Close process Opening balances from to closing balances in fiscal accumulates balances from Period 1 thru FRS fiscal year 2000 year 1999 FRS will be Period 12 + Period 998 (year-end adjustments), inserted into PeopleSoft manually entered into and stores them in Period 999, booking net fiscal year 1999 Period PeopleSoft the System income to Fund Balance; revenue and 12, representing Controller Office expenses are cleared. Note: Revenue and fiscal year 1999 net expenses of ChartField combinations that have activity. Projects ChartFields will not be cleared by PeopleSoft's Year-End Close process. Assets $ $ $ $ Liabilities $ $ $ $ Fund Balance $ $ $ $ (1b) PeopleSoft's Year-End Close Revenues $ $ $ $ process uses fiscal year Expenditures $ $ $ $ 1999 Period 999 balances as fiscal year 2000 opening balances, and stores them into Period 0. (2) (1a) Reconcilliation process Revenue and expenses for Projects will be run following ChartField values such as Capital PeopleSoft's For details on (1a), (1b), Construction and Sponsored Year-End Close process (2a), (2b), and (3), refer to Programs, will be loaded with 'Load Opening Balances Project-To-Date net values. Processing Sequence'.

Load Fiscal Year 2000 Budgets, Encumbrances, and Actuals Overview

FRS Account Balances

FRS Account Balances Background

As you know, the assignment of account balances (revenues, expenditures, and cash) to an FRS Account depends on the ledger (GL or SL) the account is associated. FRS provides for a hard-coded mapping of SL Accounts to GL Accounts. With this design, the University of Colorado has been able to book across different fund groups:  revenues to one group of SL accounts  expenses to another group of SL accounts  cash to assigned GL accounts (processed ‘behind-the-scenes’)

The University has established a process where all cash balances occurred only at the GL level and departments never see a cash balance in the General fund. However, cash balances are seen by departments using Auxiliary funds, as there is a one-to-one mapping between SL and GL accounts. Additionally, FRS had memo accounts banks within the system, which were used for reconciliation to the real bank accounts.

ChartField Combination Balances

PeopleSoft process cash balances differently than FRS. PeopleSoft’s design requires that all entries made into the system be ‘four-line’ entries, thus requiring users to enter cash journal entries for all transactions.

Because of this, A.S.P. determined that there are only two viable alternatives for handling cash in PeopleSoft. The first is to change the manner in which the University processes cash and adopts the ‘four-line’ journal entry method, as indicated by PeopleSoft. However, as the training required to make this transition is beyond the scope of A.S.P., this method was deemed unsatisfactory.

The second alternative is to develop a ‘behind-the-scenes’ process to generate cash journal entries. A.S.P. explored this further and a method was developed that effectively auto-generates an offset to cash during PeopleSoft’s ‘Journal Posting’ process. Because of the complexities involved in running a ‘behind-the-scenes’ cash process in PeopleSoft, A.S.P. chose to ‘charge’ cash to the same Fund/Org/Program-or-Project combination that generated the original journal entry line.

The University controllers have requested that revenues, expenditures, and cash continue to be ‘charged’ in PeopleSoft the same way as in FRS. To enable the University staff to access their data in this format, A.S.P. has analyzed several alternatives and has made recommendations. For more details, please refer to the ‘CASH’ document published on the A.S.P. web site (Chart of Accounts).

To ensure the conversion of FRS Account balances integrate correctly with the recommended approach as outlined in the above ‘CASH’ document, the following outlines the rules that will be used during conversion:

SL accounts that map one-to-one to GL account As FRS GL and SL accounts have the same balances, the FRS SL account will be converted but GL account will not. For details, refer to ‘Conversion Principles’ document published

on the A.S.P. web site (Chart of Accounts). In the PeopleSoft G/L, cash will be stored with the ChartField combination that represents the SL account.

GL accounts that do not have SL accounts Those FRS GL accounts that have been marked as ‘Keep’ will be converted to a corresponding ChartField combination. For details, refer to ‘Conversion Principles’ document published on the A.S.P. web site (Chart of Accounts).

Many SL accounts that map to one GL account Both the SL and GL accounts will be converted to a corresponding ChartField combination. For details, refer to ‘Conversion Principles’ document published on the A.S.P. web site (Chart of Accounts).

In PeopleSoft, cash will initially be stored with the ChartField combination that represents the SL account. Several methods are available to apply cash to different ChartField combinations. For details, please refer to the ‘CASH’ document published on the A.S.P. web site (Chart of Accounts).

Monitor New FRS Accounts and Attribute Changes MONITOR NEW FRS ACCOUNTS AND ATTRIBUTE CHANGES Background A table of FRS Accounts and related attributes was created in June 1998, to facilitates analysis of FRS Accounts for the purpose of converting to new PeopleSoft ChartFields. Additional fields were added to the table to identify analysis results, conversion rules, and ChartField values. Also, targeted PeopleSoft fields were added. When attributes change in FRS or when an FRS Account has new activity, the conversion analysis must be performed. The following steps highlight the process of monitoring changes in FRS.

Monitor Process 1. A backup table is created of the analysis table, ‘COA_ALL_PROJECT_PROGRAM_ACCTS’. This will be done on a regular basis to facilitate recovery if the process doesn’t work as planned and also provides for comparison reporting by month.

FRS/PS Attribute and Analysis Table Create monthly Monthly backup of All_Project_Program_Accts backup All_Project_Program_Accts

2. From the analysis table ‘COA_ALL_PROJECT_PROGRAM_ACCTS’ and the sources of current information in FRS, an interim table is created containing old attributes, ‘Old_and_New_Attributes’. The source of current attribute information is the Central Information Warehouse account tables for the prior month. The source to determine if an account has new activity is the FRS mainframe.

FRS Attribute Table: Warehouse - GL and SL Activity Table All_Project_Program_Accts Account Prior Month Tables (Original Source is FRS mainfraim)

Select FRS attributes from Select All_Project_ Select attributes downloaded Program_Acct from Warehouse activity table information from FRS

Old and New Attribute Table to be used for comparisons

Monitor New FRS Accounts and Attribute Changes 3a Analysis is performed on the ‘Old_and_New_Attribute’ table to determine the attributes that were changed. If there is a change, a row is entered into the table, ‘Attribute Changes’, containing the account number and values of the new attribute. Also, these rows are appended to a cumulative attribute change table to track all changes since June 1998.

Note: One the FRS attributes being checked is the ‘Delete Flag’ attribute which is updated in FRS when accounts are no longer to be used. All FRS Accounts with a ‘Delete Flag’ attribute will not be converted.

Compare old attributes to new attributes. Create Old and New Attribute tables with rows of Attribute changes for the month Table accounts with attributes that have changed.

3b The analysis table, ‘COA_ALL_PROJECT_PROGRAM_ACCTS’ is updated with the new attributes. Conversion analysis must be performed for changes in:  Activity code (assigning K, S, C, D, or N)  Reporting Structure code (assigning the FRS Account to an Organization)  Amendment 1 code (assigning a Fund group value)

Update with new Attribute changes for the FRS/PS Attribute table: FRS attribute month All_Project_Program_Accts values

Monitor New FRS Accounts and Attribute Changes 4a To identify FRS Accounts have been added during the previous period, a comparison is made between the Central Information Warehouse account tables for the prior month and the analysis table, ‘COA_ALL_PROJECT_PROGRAM_ACCTS’. If an FRS Account exists in FRS but does not exist in the analysis table, a row is entered into a new table, ‘New FRS Accounts’. This row contains the account number and it’s associated FRS attributes. Also, these rows are appended to a cumulative new FRS Account table to track all additions since June 1998

FRS/PS Attribute table: All_Project_Program_Accts

Compare FRS accounts to FRS/PS Attribute table accounts. If accounts New FRS accounts for the exist in FRS that are not month in FRS/PS Attribute table, then create tables with rows for new accounts.

Warehouse - GL and SL Cumulative file of new FRS Account Prior Month Tables accounts since June 1998

4b. An analysis is performed on the ‘New FRS Accounts’ table rows that evaluates the:  Activity code (assigning K, S, C, D, or N)  Reporting Structure code (assigning the FRS Account to an Organization)  Amendment 1 code (assigning a Fund group value). Then, the analysis table, ‘COA_ALL_PROJECT_PROGRAM_ACCTS’ is updated with the new FRS Accounts.

New FRS accounts for the Update with new FRS/PS Attribute table: month FRS accounts All_Project_Program_Accts

Monitor New FRS Accounts and Attribute Changes

Prepare ‘FRS-to-PeopleSoft Translation’ Table

Prepare ‘FRS-to-PeopleSoft Translation’ Table ‘FRS-to-PeopleSoft Translation’ Table Definition The translation table is the cross-reference between FRS Account values and corresponding PeopleSoft ChartField combinations. The table consists of the following fields:

FRS Conversion Speed Fund Fund Org Org Program Pgm Pgm Project Proj Proj Sub-Class Sub- Sub- Account Status Type Number Desc Number Desc Number Desc Long Number Desc Long Number Class Class Number Desc Long

Field Description FRS Account Number FRS Account value Conversion Status Indicates if FRS Account was converted. If not, reasons are summarized. SpeedType SpeedType value Fund Number Fund group value Fund Desc Fund group description Org Number Organization value Org Desc Organization description Program Number Program value Program Desc Program short description Program Long Program long description Project Number Project/Grant value Project Desc Project/Grant short description Project Long Project/Grant long description Sub-Class Number Sub-Class value Sub-Class Desc Sub-Class short description Sub-Class Long Sub-Class long description

All fields in this table will be populated for FRS Accounts, irrespective of the conversion status. For FRS Accounts marked as ‘Not Convert’, only the FRS Account Number and Conversion Status fields will be populated.

Utilization of the ‘FRS-to-PeopleSoft Translation’ table This table will be used:  to search for specific FRS Accounts and view their conversion status as well as the corresponding PeopleSoft ChartField combination values  as the source to populate the ‘SpeedType’ table  in the process to convert FRS Accounts to PeopleSoft ChartField combinations

Population of ‘FRS-to-PeopleSoft Translation’ tables The ‘FRS-to-PeopleSoft Translation’ tables values will be populated from an Oracle table ‘COA_COA_ALL_PROJECT_PROGRAM_ACCTS’, that was established June 1998. This table has been used to facilitate analysis of FRS Accounts for the purpose of converting to PeopleSoft ChartField combination values.

The ‘COA_COA_ALL_PROJECT_PROGRAM_ACCTS’ table was populated with all FRS Accounts and contains the related attributes of each FRS Account. On a regular basis, this table is update with attribute changes, account activity changes, and new FRS Accounts. For more details, refer to the section ‘MONITOR NEW FRS ACCOUNTS AND ATTRIBUTE CHANGES‘, 17. Additional fields were added to the ‘COA_COA_ALL_PROJECT_PROGRAM_ACCTS’ table to identify analysis results, conversion rules, and values.

The ‘COA_COA_ALL_PROJECT_PROGRAM_ACCTS’ table has also been used as the source for the ‘SpeedType’ table. This table contains the translated ChartField combination value for unique combinations of FRS and Control/Object codes.

Publication of ‘FRS-to-PeopleSoft Translation’ tables For easy of use, values from the ‘COA_COA_ALL_PROJECT_PROGRAM_ACCTS’ table were extracted and stored on MS Excel spreadsheets (segregated by campus) that have been published on the A.S.P. web site (Chart of Accounts – Translation Tables).

The University’s IRM group has also contributed to the conversion effort by developing a search facility that is available on the A.S.P. web site, that enables you to enter an FRS account number and responds with the translated PeopleSoft ChartField combination. This search facility references the ‘SpeedType’ table as the source of information. Refer to the A.S.P. web site (Chart of Accounts – Account Translation Search).

Assigning ChartField Values Various methods were used to analyze FRS Accounts. The following outlines the processes that were used to assign values to each ChartField for FRS Accounts that will be converted.

Fund This ChartField corresponds to the Fund group designation and Amendment 1 attribute.

Fund values were assigned to FRS Accounts on the ‘COA_ALL_PROJECT_PROGRAM_ACCTS’ table based the FRS Account number value and Amendment 1 designation. For further details, refer to the section ‘Rules to Assign Values – Fund ChartField’, on 27.

Organization This ChartField is equivalent to the FRS Reporting Structure Code.

A.S.P. created organization charts for all campuses. The corresponding Reporting Structure Code was associated with each organization in the new chart. University Budget Officers and Controllers reviewed and where applicable, updated the organization charts.

Using the organization charts as the source, a table was created, ‘Org Values’, containing the new organizations and the corresponding Reporting Structure Codes. Some organizations on the ‘Org Values’ table had many associated Reporting Structure Codes.

Organization values were assigned to FRS Accounts on the ‘COA_ALL_PROJECT_PROGRAM_ACCTS’ table by linking the Reporting Structure Codes of the ‘Org Values’ and ‘COA_ALL_PROJECT_PROGRAM_ACCTS’ tables. For further details, refer to the section ‘Rules to Assign Values – Organization ChartField’, 29.

Program This ChartField is equivalent to FRS Accounts that represent activities tracked on a budget year basis.

Based on the distribution of funds as well as functional and reporting requirements, FRS Accounts associated with the following funds will be identified via the Program ChartField: Agency fund, Restricted Gift fund (excluding State or Federal Financial Aid grants), Auxiliary fund, Invested in Plant fund, Endowment fund, Retirement of Indebtedness Plant fund, Unrestricted General fund, and Unexpended Plant fund - Renewal & Replacement.

Each FRS Account within these funds was individually analyzed to identify if the FRS Account represented an activity or an FRS Object code, used for budgeting purposes. For FRS Accounts representing activities, new Program numbers were assigned.

All Program ChartField values were assigned sequentially, beginning with a value of ‘10000’.

Project/Grant This ChartField is equivalent to FRS Accounts that represent activities that can cross multiple budget years, funds, and organizations.

Based on the distribution of funds as well as functional and reporting requirements, FRS Accounts associated with the following funds will be identified via the Project/Grant ChartField: Unexpended Plant fund – Capital Construction, Restricted Sponsored fund, Loan fund, and Restricted Gift fund (only State or Federal Financial Aid grants).

All FRS information regarding this group of FRS Accounts will be assigned Project/Grant ChartField values, without any analysis.

To facilitate integration with the SPINS system, current FRS Account numbers will be assigned as the Project/Grant ChartField values.

Sub-Class There is no FRS equivalent.

The Sub-Class ChartField is used to capture ‘Department-defined’ needs. The use of this field is optional for departments. As there is no Sub-Class equivalent in FRS, A.S.P. anticipates the majority of values will be defined following the July 1st, 1999 implementation of PeopleSoft.

All Sub-Class ChartField values will be assigned sequentially.

Account ChartField The Account ChartField is equivalent to FRS Control and Object codes.

The University Controllers developed the Account ChartField translation table containing FRS Control and Object codes and the corresponding PeopleSoft ChartField values. For details of the conversion of FRS Control and Object codes, refer to the A.S.P. web site (Chart of Accounts – ChartField Value Tables – Matching FRS Control/Object Code Values to PeopleSoft Accounts).

Account ChartField values are not required for the ‘FRS-to-PeopleSoft Translation’ table, as this table does not hold the natural classification of the dollar balances associated with each ChartField combination. However, these values were critical to the creation and maintenance of the ‘SpeedType’ table.

FRS Account Create Process during Finance/HR Implementation Interim Period FRS Account Create process during Finance/HR Implementation Interim Period Background On July 1st,1999 the PeopleSoft General Ledger, Accounts Payable, and Purchasing modules will go into production, becoming the University’s financial system of record. The PeopleSoft Human Resources, Payroll and Benefits modules will go into production on November 1st, 1999.

During the four-month interim, the University will continue to utilize the legacy HR, payroll, and benefits systems. These systems will not be updated to comply with the new Chart of Accounts format and therefore, require that FRS still be in place to accept financial transactions generated from these systems. For this interim period, these transactions will be extracted from FRS, converted and loaded into PeopleSoft’s General Ledger module.

Following the July 1 implementation of the financial modules, new ChartField combinations will be established (e.g.: new Sponsored Programs, activities). Because these new combinations may be used to pay for salaries/benefits, they must be established in FRS.

Following July 1, 1999, FRS Accounts will be established via two methods: 1. Information and attributes referring to new Sponsored Programs are entered into SPINS.

 Interfaces will extract this data and transactions will be created to load to the PeopleSoft system and the FRS system.

SPINS (Sponsored Programs information and attributes is entered)

SPINS - FRS SPINS - PeopleSoft interface interface (existing) (new)

FRS PeopleSoft

FRS Account Create Process during Finance/HR Implementation Interim Period 2. All new ChartFields and ChartField combinations that do not originate from the SPINS system will be established in FRS by a new PeopleSoft to FRS interface. a) following the establishment of ChartField combination values in the Budget ledger, these combinations will be added to the Alias table b) at that point, an FRS Account number will be assigned using the current method of assigning FRS Account number; this number will then be entered in the Alias table c) the FRS-Load interface will then:  search the Alias table for new ChartField combinations  extract the associated FRS Account number and the associated attributes (the minimum required information) associated with the new ChartField combinations  format the information into transactions FRS expects  create a file for FRS d) an existing FRS batch job will load the new FRS Account numbers

PeopleSoft Alias table (ChartField Combinations PeopleSoft - FRS New interface with corresponding (new) FRS Accounts FRS Account numbers)

FRS batch load job (existing)

Rules for Assigning ChartField Values FUND ChartField Rules for Assigning ChartField Values Background Because the translation from FRS to PeopleSoft process could not be fully automated, several manual processes were developed to facilitate the assignment of ChartField values. The following outlines the rules specific to each ChartField that were used when assigning values.

FUND ChartField This ChartField contains values that broadly classify funding sources (fund groups), as defined by NACUBO.

Funds groups are segregated for the purpose of conducting specific activities or attaining certain objectives in accordance with special regulations, restrictions, or limitations. They help to define the requirements for receiving and spending money.

The Amendment 1 designation is captured as part of the fund group value.

The following table outlines the range of FRS Account numbers that were assigned to Fund group values in PeopleSoft.

Amendment 1 Fund FRS Account Range Designation/Code Num Fund Description C-0-1XXXX, C-1-XXXXX, and 2-2-XXXXX Non-Exempt N 10 Unrestricted General fund – Long Bill Appropriated & Tuition C-0-1XXXX, C-1-XXXXX, and 2-2-XXXXX Exempt E 11 Unrestricted General fund – ICR C-0-2XXXX, C-3-XXXXX Exempt P* 20 Auxiliary fund – Enterprises C-0-2XXXX, C-3-XXXXX Exempt I & X 28 Auxiliary fund – ISU C-0-2XXXX, C-3-XXXXX Non-Exempt S 29 Auxiliary fund – Non-Enterprises C-0-3XXXX(shouldn't be any1) and C-5-3XXXX Exempt E 30 Restricted Sponsored fund – Federal, State & Private Sponsors C-0-3XXXX(shouldn't be any1) and C-5-3XXXX Non-Exempt N 31 Restricted Sponsored fund – Local Government Sponsors C-0-4XXXX(shouldn't be any1) and C-6-4XXXX Exempt E 34 Restricted Gift Fund C-0-5XXXX Exempt E 50 Loan Fund – Federal, State & Private Funded

1 The comment ‘shouldn’t be any’ refers to the situation where the is a one to one mapping of a GL account to a SL account. In this case, the GL account would not be converted and therefore, there shouldn’t be any of these accounts.

Rules for Assigning ChartField Values FUND ChartField Amendment 1 Fund FRS Account Range Designation/Code Num Fund Description C-0-5XXXX Non-Exempt N 51 Loan Fund – Local Government Funded C-0-6XXXX Exempt E 60 Endowment Fund C-0-70000 thru (1)(3)(4)(5)-0-72999, (2)-0-75999, Exempt E 71 Unexpended Plant fund – Capital Construction C-7-70000 thru (1)(3)(4)(5)-7-72999, and (2)-7-75999 (1)(3)(4)(5)-0-73000 thru (1)(3)(4)(5)-0-75999 and (1) Exempt E 72 Unexpended Plant fund – Renewal and Replacement (3)(4)(5)-7-73000 thru (1)(3)(4)(5)-7-75999 C-0-76XXX and 2-7-76XXX Exempt E 73 Retirement of Indebtedness Plant fund C-0-77000 thru C-0-79999 Exempt E 74 Invested in Plant fund C-0-70000 thru (1)(3)(4)(5)-0-72999, (2)-0-75999, Non-Exempt N 75 Unexpended Plant fund – Capital Construction C-7-70000 thru (1)(3)(4)(5)-7-72999, and (2)-7-75999 (1)(3)(4)(5)-0-73000 thru (1)(3)(4)(5)-0-75999 and (1) Non-Exempt N 76 Unexpended Plant fund – Renewal and Replacement (3)(4)(5)-7-73000 thru (1)(3)(4)(5)-7-75999 C-0-76XXX and 2-7-76XXX Non-Exempt N 77 Retirement of Indebtedness Plant fund C-0-8XXXX and C-8-XXXXX Exempt E 80 Agency Fund

Rules for Assigning Values ORGANIZATION ChartField

ORGANIZATION ChartField The Organization ChartField is defined by the following four guidelines:

 A uniquely identified responsibility unit with employees and;  A unit that has been established under the authority of and consistent with the Board of Regents Policy on Delegation of Authority and;  A single budgetary unit and,  A unit within the structure of the University organization chart.

The process to assign an FRS Account to a new PeopleSoft organization is as follows:

1. Create initial version organization charts for all campuses based on organization charts gathered during the ‘Process and Organization Redesign’ phase of the A.S.P. project held in 1997. Additional sources of information included the Reporting Structure Codes of each campus as well as general knowledge about campus operations.

These organization charts represent the financial reporting structure of each organization within each campus. These organization charts do not depict the organizational hierarchy within the University.

The new organization charts are designed in a structure that is similar to PeopleSoft’s Trees. Therefore, several levels of nodes were built into the design and the new PeopleSoft Organizations were placed at the appropriate level. In addition, each organization was assigned a corresponding Reporting Structure Code and, where applicable, a corresponding department number from the current Human Resources system.

2. The Controllers and Budget Officers of each campus were asked to review the new organization charts as well as make any adjustments, including discussing the new organization chart with departments and defining additional Organizations that represent how departments want to break-out their operations.

3. Following the completion of the Controllers and Budget Officers review, the A.S.P. team updated the Reporting Structure Code associated with each Organization.

4. Using the organization charts as the source, a table was created, ‘Org Values’, containing the new organizations and the corresponding Reporting Structure Codes. Some new organizations had many corresponding Reporting Structure Codes.

5. Organization values were assigned to FRS Accounts on the ‘COA_ALL_PROJECT_PROGRAM_ACCTS’ table by linking the Reporting Structure Codes of the ‘Org Values’ and ‘COA_ALL_PROJECT_PROGRAM_ACCTS’ tables. In addition, FRS Accounts with Reporting Structure Codes that were not defined in the new organization charts, were assigned ‘?’ as their organization. A report was produced listing these Reporting Structure Codes.

6. The Controllers and Budget Officers of each campus then received a file containing the new organization, FRS Account number, account description, responsible person, and phone number. In addition, they received the updated organization charts as well as the report listing the Reporting Structure Codes that had been assigned ‘?’ Organization.

Rules for Assigning Values ORGANIZATION ChartField

The Controllers and Budget Officers were requested to:  verify that each FRS Account had been correctly assign to the appropriate Organization  assign all ‘?’ FRS Accounts to appropriate Organizations  reassign FRS Accounts to the new organizations of departments that broke-out their current departmental structure into multiple organizations

7. The changes provided by the Controllers and Budget Officers was applied to the ‘COA_ALL_PROJECT_PROGRAM_ACCTS’.

8. On a regular basis, a process that identifies new FRS Accounts and monitors attributes changes will be run (refer to MONITOR NEW FRS ACCOUNTS AND ATTRIBUTE CHANGES PROCESS, 17). New FRS Accounts, or accounts that become active, have a change in Reporting Structure Code, or Amendment 1 code will go through steps 4 though 6.

Rules for Assigning Values PROGRAM ChartField

PROGRAM ChartField The Program ChartField provides a means of tracking financial activity on a budget year basis and is used by one and/or multiple organizations.

As a result of analysis as well as consultation with the campus community, FRS Accounts associated to the following funds will be tracked using the Program ChartField:

 Agency fund  Unexpended Plant fund - Renewal & Replacement  Auxiliary fund  Restricted Gift fund (excluding State or Federal Financial Aid grants)  Endowment fund  Retirement of Indebtedness Plant fund  Invested in Plant fund  Unrestricted General fund

As you know, FRS Accounts are established throughout the fiscal year. A.S.P. team members manually analyzed the FRS Accounts that make up the above group. The analysis identified that some FRS Accounts were established for a variety of purposes including:  pooling of salaries, benefits  tracking of specific expenditures  separating revenues and expediters into separate FRS Accounts  separating an activity into separate FRS Accounts to correctly identify the source of funding

Rules for Assigning Values PROGRAM ChartField

Rules for Assigning Values PROJECT/GRANT ChartField

PROJECT/GRANT ChartField The Project/Grant ChartField provides a means of tracking financial activity that can cross multiple budget years, funds, and organizations, for activities over a limited time-span. The Project/Grant ChartField can also be broken-down into specific phases, segments and activities.

Project the top (first or highest) level at which you can budget and record project activity Segment the second (from the top) project level at which you can budget and record project activity Phase the third (from the top) project level at which you can budget and record project activity Activity the lowest budgeting and reporting level for a project

As a result of analysis as well as consultation with the campus community, FRS Accounts associated to the following funds will be tracked using the Project/Grant ChartField:

 Unexpended Plant  Restricted Gift fund (State and Federal Financial Aid grants inclusive) fund - Capital Construction  Loan fund  Restricted Sponsored fund

The current FRS numbers will be used as the new Project/Grant ChartField values. This will ensure integration with the SPINS system.

Note: Both PeopleSoft’s ‘Grants’ and the ‘Projects’ modules link to the General Ledger module via the Project/Grant ChartField.

Rules for Assigning Values PROJECT/GRANT ChartField

Rules for Assigning Values ACCOUNT ChartField

ACCOUNT ChartField The account ChartField is used to capture the natural classification of a transaction as an Asset, Liability, Fund Balance, Revenue, or Expenditure.

The University Controllers and A.S.P. have worked together to establish the detail values for this ChartField. Where there is a one-to-one match, an existing FRS Object code will be associated with a new Account ChartField value.

FRS PeopleSoft Control/Object Code New Account ChartField values Salaries and Wages (400000 - 419999) 400000 – 402499 (Faculty) 150 400100 – Faculty Regular PT Payroll (Budget Pool) 151 400100 – Faculty Regular PT Payroll 400200 – Faculty Temporary FT Payroll 400300 – Faculty Temporary PT Payroll 400400 – Post Doctorates 400500 – Graduate Students 415 400600 – Faculty Terminat Annual Leave 416 400700 – Faculty Terminat Sick Leave

Because Account ChartField values were defined with purpose to provide more detail and flexibility, not all Account ChartField values will have corresponding FRS Control and Object codes. However, for each FRS Control and Object code, there will be a corresponding Account ChartField value.

For details of the conversion of FRS Control and Object codes, refer to the A.S.P. web site (Chart of Accounts – ChartField Value Tables – Matching FRS Control/Object Code Values to PeopleSoft Accounts).

The mapping of FRS Control and Object codes to PeopleSoft Account ChartField values allows for:  Data conversion FRS closing balances to PeopleSoft opening balances  Reporting accuracy opening balances in the appropriate Account ChartField values  Transfer of budgets from FRS to PeopleSoft

Issues Addressed Related to the Account ChartField

During the analysis of FRS Account codes, the following issues were identified and resolved as follows:

How Cash is Handled in PeopleSoft

 SL accounts that map one-to-one to GL account The SL account will be converted but GL account will not, as the SL account has the same balances. For details, refer to the ‘CASH’ document published on the A.S.P. web site (Chart of Accounts). In PeopleSoft, cash is stored with the ChartField combination that represents the SL account.

Rules for Assigning Values ACCOUNT ChartField  Many SL accounts that map to one GL account Both the SL and GL accounts will be converted. For details, refer to ‘Conversion Principles’ document published on the A.S.P. web site (Chart of Accounts).

In PeopleSoft, cash will initially be stored with the ChartField combination that represents the SL account. Several methods are available to apply cash to different ChartField combinations. For details, please refer to the ‘CASH’ document published on the A.S.P. web site (Chart of Accounts).

User Options Object Codes How will FRS Object Codes value defined as User Option be converted?

The University Controllers have determined that User Option Object Code will assigned to ‘general PeopleSoft Account ChartField values’ and identified the Account ChartField values to be assigned for each ‘User Option’ code.

Exceptions Due to the numerous departmental uses of User Option codes, not all codes can be handled with the above rule. The following outlines how exceptions will be handled:

 User Option Object codes with blank descriptions A Sub-Class ChartField value will not be created for this User Option Object code. The balance will be applied to the ChartField combination that corresponds to the Object Code associated with the User Option value.

 User Option Object codes used in Sponsored Programs The Sponsored Programs group use User Options to identify exempt and non-exempt status. The Sponsored Programs Group, represented by Janie Ferro, will review the use of the User Option Object codes within the Sponsored Programs group.

Based on the results of this analysis, the Sponsored Programs Group will define a translation path for each Sponsored Program Account that will assign User Options balances to specified PeopleSoft Account ChartField values. This translation path will then be used in the FRS-to-PeopleSoft conversion batch process.

One FRS Object Code Category Mapping to Multiple Account ChartField Categories

When developing comparing the FRS Control and Object codes to the new Account ChartField values, it was discovered that some categories/grouping of Control and Object codes had been broken-out into several categories. This was done to provide expense and revenue categories that offer more detail and flexibility as well as greater easy of use.

Example: FRS PeopleSoft Professional Benefits Budget Pool Faculty Benefits Budget Pool Unclassified Staff Benefits Budget Pool)

Budge Pool Office Supplies Budget Pool Telecommunications Budget Pool Postal Supplies Budget Pool

The University Controllers determined that balances associated with these Object/Control codes will be assigned to a single PeopleSoft Account value. Following the July 1, 1999 implementation, manual adjustments will be made to move the appropriate balances to the other Account ChartField values:

Rules for Assigning Values SUB-CLASSIFICATION ChartField

SUB-CLASSIFICATION ChartField The Sub-Classification ChartField is used to capture ‘Department-defined’ needs. The use of this field is optional for departments. As there is no Sub-Classification equivalent in FRS, A.S.P. anticipates the majority of values will be defined following the July 1st, 1999 implementation of PeopleSoft.

Rules for Assigning Values SUB-CLASSIFICATION ChartField

Data Conversion Overview

Data Conversion Overview For an overview of the data conversion process, including the tables that will be converted, refer to the ‘Data Conversion Overview document published on the A.S.P. web site (Chart of Accounts – Other Important Documents).

Data Conversion Overview

Matching FRS Control/Object Codes to PeopleSoft Account ChartField Values

Matching FRS Control/Object Codes to PeopleSoft Account ChartField Values For details of the conversion of FRS Control and Object codes, refer to the A.S.P. web site (Chart of Accounts – ChartField Value Tables – Matching FRS Control/Object Code Values to PeopleSoft Accounts).

Matching FRS Control/Object Codes to PeopleSoft Account ChartField Values

SpeedType Table

SpeedType Table The University’s IRM group has also contributed to the conversion effort by developing a search facility that is available on the A.S.P. web site, that enables you to enter an FRS account number and responds with the translated PeopleSoft ChartField combination. This search facility references the ‘SpeedType’ table as the source of information.

Refer to the A.S.P. web site (Chart of Accounts – Account Translation Search).

June 10, 1999 D:\Docs\2017-07-20\01d63f387f1a3875d6c415b94cc6b8ec.doc