Chart of Accounts Design - PDF by uwm73918

VIEWS: 579 PAGES: 41

More Info
									STATE OF NEW YORK
Statewide Financial Systems Program




DRAFT - Chart of Accounts
and General Ledger Design

This document is to be considered a draft of the Chart of Accounts and
General Ledger design for CAS and NYFMS. Nothing included below should
be construed to be specifications.




                                                       Issue Date
                                                    January 28, 2009
DRAFT - Chart of Accounts and General Ledger Design




                                           Table of Contents
1.0           Executive Summary ............................................................................................1
2.0           Benefits of a Statewide Chart of Accounts .......................................................3
  2.1.        Current Environment .............................................................................................3
  2.2.        Vision for a Statewide COA ...................................................................................3
  2.3.        Establishment of Joint Project Team and Involvement of Stakeholders................4
  2.4.        Assumptions and Guiding Principles .....................................................................4
  2.5.        Benefits of the Statewide COA ..............................................................................5
3.0           Business Unit Approach.....................................................................................8
4.0           Setid Approach ..................................................................................................10
5.0           General Ledger Approach ................................................................................12
  5.1.        Ledgers ...............................................................................................................12
  5.2.        Commitment Control ...........................................................................................12
  5.3.        Combination Edits ...............................................................................................13
  5.4.        Interunit Transactions ..........................................................................................13
  5.5.        Calendars ............................................................................................................13
  5.6.        Data Access ........................................................................................................14
6.0           Chart of Accounts Design ................................................................................15
  6.1.        Department..........................................................................................................15
  6.2.        Program...............................................................................................................18
  6.3.        Fund/Subfund......................................................................................................20
  6.4.        Account ...............................................................................................................23
  6.5.        Project/Grant .......................................................................................................24
  6.6.        Budget Reference ...............................................................................................24
  6.7.        Chartfield 1 – Cost Accumulator..........................................................................24
  6.8.        Chartfield 2 and Chartfield 3................................................................................25
7.0           Chart of Accounts Governance........................................................................26
8.0           Next Steps ..........................................................................................................28
  8.1.        Valid Values ........................................................................................................28
  8.2.        Mapping...............................................................................................................28
  8.3.        Commitment Control ...........................................................................................28
  8.4.        Tree Development ...............................................................................................29
  8.5.        Combination Edit Rules .......................................................................................29
9.0           Additional Considerations for the Systems Integrator ..................................30
  9.1.        Setid ....................................................................................................................30
  9.2.        Commitment Control Design ...............................................................................30
  9.3.        Commitment Control Trees .................................................................................30
  9.4.        Chartfield Configurator ........................................................................................30
  9.5.        Known NYFMS Modifications ..............................................................................31
  9.6.        Project Accounting ..............................................................................................31
A.0           Key Decisions for Commitment Control .........................................................32


Version1.0                                                 Page ii                                                  1/28/09
DRAFT - Chart of Accounts and General Ledger Design



  A.1.        Control/Track .......................................................................................................32
  A.2.        Budget Keys ........................................................................................................32
  A.3.        Chartfield Rollups (Translations) .........................................................................32
  A.4.        Calendar..............................................................................................................33
  A.5.        Rulesets ..............................................................................................................33
  A.6.        Control Chartfield ................................................................................................34
  A.7.        Excluded Accounts ..............................................................................................34
  A.8.        Parent/Child Budgets ..........................................................................................34
B.0           Other Chartfields ...............................................................................................36
  B.1.        Project-related Chartfields ...................................................................................36
  B.2.        Affiliate Chartfields ..............................................................................................37
  B.3.        Other PeopleSoft Chartfields...............................................................................38




Version1.0                                                Page iii                                               1/28/09
DRAFT - Chart of Accounts and General Ledger Design




1.0 Executive Summary
The Chart of Accounts (COA) is the backbone of any financial system, as it sets the standards
for how State financial resources will be tracked, accounted for, and reported upon. As such,
the completion of an initial COA design for use in the new statewide financial system represents
a key milestone for the FOCAS and NYFMS Projects. Agency stakeholders have long stressed
the importance of COA design in determining whether the new statewide financial system will
meet their needs. Stakeholders seek both reliable statewide comparisons across agencies and
the ability to perform detailed analysis on smaller organizational components. Indeed, it is clear
that stakeholders will consider the delivery of improved financial data and analytics a key
measure of project success.
This report documents the initial design decisions reached, outlines anticipated benefits, and
explains how the COA will be implemented by the two projects. It must be emphasized that this
document presents only the preliminary concepts for the design and much further work is
required to finalize the design. Options for several design decisions are presented, which will
require further analysis and input from agencies, which will be solicited in individual agency
meetings over the next few months.
Highlights of the initial design concepts include:
•   Creation of lower levels of detail at which to capture financial data, which can then be rolled
    up to summary levels for reporting purposes;
•   Alignment of system Program codes with the definitions of programs within appropriation
    bills, to simplify the tracking of spending against legislative authorizations;
•   Use of the same, fully detailed COA in both CAS and NYFMS, to reduce the effort required
    to keep agency financial data in sync with the Comptroller’s official “book of record”;
•   Ability to drill down from aggregate data to detailed transactions;
•   Creation of separate ledgers -- or sets of “books” -- which will allow agencies to view data on
    the modified accrual basis they are most accustomed to, while also sharing the cash basis
    view more commonly used by the Division of the Budget and the Bureau of Accounting
    Operations of the Office of the State Comptroller;
•   Increased flexibility for agencies in setting spending controls;
•   Creation of new ability to track projects, even when they cross agencies, funds and
    programs;
•   Increased detail for reporting on agency revenues, such as dedicated fees and fines;
•   Dedication of coding fields specifically for agency use in meeting their own unique reporting
    needs;
•   Implementation of electronic budget certificates; and
•   Alignment of statewide reporting concepts used by OSC and DOB.
The creation of a new COA with sufficient levels of detail will deliver the desired improvement in
financial information within both CAS and NYFMS, while also providing standard definitions of
data upon which to base integration with other agency systems using financial data. By
maintaining those standard definitions, the quality of State financial data will improve and the




Version 1.0                                 Page 1 of 38                            1/28/09
DRAFT - Chart of Accounts and General Ledger Design



effort required to compile comparable data, or integrate or reconcile independent data sources
will be reduced.
As the design process proceeds, the project teams will consider how best to implement some of
the key features offered by the software. For example, the State must identify the approach for
establishing business units, which are fundamental to how business processes will be
performed, and how rules for transactions will be set. NYFMS plans to have approximately 68
business units (each representing an agency). However, the FOCAS and NYFMS teams are
still evaluating the benefits and risks of establishing one or multiple business units in CAS. This
decision impacts key areas including how the State will manage budgetary controls, how
statewide and agency financial data will be queried and reported, and how inter-agency
transactions will be accounted for. Once the State reaches a decision on business units, the
Project teams will move forward with refining the approach for other related COA design
concepts required by the software.
This report provides a discussion of upcoming design decisions and the next steps required to
complete the COA design. These include:
•   How the new COA will be maintained and who may make changes;
•   How agencies will use the COA to control their budget;
•   How agencies will begin mapping their current code structures to the new COA; and,
•   The efforts to be undertaken to define the new values (or codes) for the new COA.
The participation of more than 50 agency experts was key to reaching this milestone, and the
Project teams appreciate their contributions. Validation of this design with their agency
colleagues will be sought at a statewide meeting on February 6, 2009. In addition, as the
process continues to unfold, agency representatives will have further opportunities to comment
on the proposed design in one-on-one sessions with Project team members. Comments are
also welcome by writing to feedback@nyfms.state.ny.us.




Version 1.0                                Page 2 of 38                             1/28/09
DRAFT - Chart of Accounts and General Ledger Design




2.0 Benefits of a Statewide Chart of Accounts

2.1. Current Environment
The State’s current financial system environment is both highly complex and highly
decentralized. Agencies maintain a number of legacy systems to capture, report, and analyze
data for their own needs, while still more systems at the Office of the State Comptroller (OSC)
and at the Division of the Budget (DOB) perform statewide functions. Multiple COAs have been
established, with those in use in the statewide systems often differing substantially from those
used for agency specific systems. The current environment presents three key challenges.
•   Lack of Common Definitions: The practice of customizing each COA within each system
    significantly hampers the State’s ability to meet critical reporting and data analysis
    requirements – both statewide and within agencies. OSC’s Central Accounting System
    (CAS) COA has prescribed meaning to its data elements, but allows for further dissection by
    agencies, contributing to a dilution of meaningful data. For example, the ending digit of the
    current object code may be used by agencies to define agency-specific object detail, leading
    to one code being used in multiple ways across agencies. Agency COAs are not standard
    across, or in some cases internal to, the agencies. This lack of standardization impairs both
    agencies’ and the State’s ability to perform meaningful and reliable data analysis and
    reporting. Further, the use of highly customized COAs requires that agency staff receive
    significant training to be proficient and accurate – training that may be of limited use when
    an employee is promoted or transferred to another position.
•   Insufficient Detail in COA Structures: Current COA structures lack the depth desired and
    required by agencies for data entry, reporting, and analysis. Further, a common approach
    to defining programmatic and organization structures does not exist in the current
    environment. Agencies do not presently have a statewide coding structure available to them
    to define lower levels of organization detail, without the use of a cost center code. Program
    information is stored in a number of data elements, including the CAS program codes, cost
    centers, and agency-specific coding. As a result, agencies have turned to certain coding
    elements as workarounds to gather lower level information, such as specific revenue
    sources and expenditure data. These workaround elements - especially the widely used
    cost center codes - have thus lost unique meaning and cannot be used in a uniform manner
    for reporting and analysis, again leading to additional work to extract information.
•   Lack of a Common Platform to Integrate Data and Systems: The lack of a common COA
    means that State systems lack a common platform for integration. As a result, linking
    systems to exchange, match and compare data is difficult. In some cases it is simply not
    possible for data to be integrated at the granular or transactional level that would most
    benefit agencies. This leads to the necessity to perform additional, manual work to extract
    data from one source or system and compile it in another system, spreadsheet or database,
    at times requiring duplicate entry of the same data.

2.2. Vision for a Statewide COA
Providing agencies with improved analytic and reporting capabilities is a key benefit expected to
be realized through the development of a statewide financial system, and the creation of a
single COA for use statewide is recognized as a major step toward delivering that benefit. The



Version 1.0                               Page 3 of 38                            1/28/09
DRAFT - Chart of Accounts and General Ledger Design



statewide COA design must meet the needs of the State as a whole, from both control and
operation perspectives. To that end, the statewide COA must:
•   Improve ability to perform meaningful and accurate financial reporting and data analysis,
    while reducing the time and effort associated with this
•   Provide a greater level of detail of financial data
•   Comply with governance, regulatory, and other requirements, including applicable
    accounting standards
•   Improve accuracy and dependability of information
•   Promote transparency of information for stakeholders, including regulators, taxpayers, and
    auditors
•   Reduce reconciliation efforts between systems and across the State
•   Reduce data errors
•   Provide a more consistent, user-friendly environment, both for data entry and extraction
•   Provide a foundation for interfacing with systems outside of NYFMS and CAS

2.3. Establishment of Joint Project Team and Involvement of
     Stakeholders
The need to create a single statewide COA was one of the first goals established by the Joint
Governance Board which oversees the NYFMS and FOCAS projects. The Board, acting
through its subcabinet – the Joint Coordinating Committee (JCC) – established a COA Joint
Project Team (Joint Team) in mid-2008 and charged it with developing a statewide COA design
for use by both projects.
Recognizing the need for input from stakeholders, the Joint Team then assembled the Agency
COA Workgroup, comprised of agency subject matter experts (SMEs), to vet options and
recommendations for the statewide COA design. The feedback of this Workgroup, as well as
work done with each agency over the past two and a half years, served as significant inputs to
the design process. This Workgroup will continue to be involved through the implementation of
both instances of PeopleSoft, to ensure stakeholder needs are represented throughout the
entire system design and development process.

2.4. Assumptions and Guiding Principles
A number of assumptions and principles were established to guide the Joint Team and
Workgroup as options for the design of the statewide COA were considered. These
assumptions and guidelines were developed collaboratively, with the Joint Team seeking input
from agencies as well as the expert consultants engaged by the Projects. In addition, the Joint
Team reviewed and incorporated the best practices of other states and private entities.
Assumptions
•   One statewide COA will be shared between NYFMS and CAS, with the same COA
    (including level of detail) used in each of the two PeopleSoft instances.
•   Agencies will enter data to NYFMS in the future environment. Data will be transmitted to
    CAS through a middle layer of software.
•   Minimal changes will be made to legacy systems during the transition to NYFMS and CAS.


Version 1.0                               Page 4 of 38                            1/28/09
DRAFT - Chart of Accounts and General Ledger Design



•   The initial configuration of the statewide COA will take place in the CAS instance, with that
    instance acting as the master data for the statewide COA.
Guiding Principles
•   Minimize the number of chartfields needed, while still meeting the requirements of
    stakeholders.
•   Assign each chartfield one, and only one, meaning.
•   Generally make chartfields available for use by the entire State; limited agency-specific
    chartfields will be defined to meet agency-specific needs.
•   Minimize value intelligence in the code structure.
•   Allow for growth of the statewide COA.
•   Capture necessary reporting information at the transaction level and define chartfields to
    meet these needs.
•   Establish a governance policy for the statewide COA, for appropriate central and distributed
    establishment and maintenance of values.
•   Take advantage of delivered system functionality to satisfy requirements and minimize
    modifications to delivered functionality.

2.5. Benefits of the Statewide COA
A single statewide COA design offers significant benefits to the State, allowing for improved
business processes, transparency of information, and reliability of data and reporting
information. These benefits generally fall into three categories: improved information, reduction
in errors and reconciliation efforts, and reduction in work effort.

2.5.1. Improved Information
The statewide COA design will improve the State’s ability to collect data for reporting and
analysis. Giving common meaning to chartfields means that every agency will understand the
usage of each chartfield, use the same chartfields to enter common information, and capture the
same types of information. As a result, the State’s ability to easily extract information from the
systems to compile meaningful and accurate financial reports and analyses is increased. A
common approach to defining and collecting this data will improve budgetary and reporting
processes while reducing time and effort in collecting and analyzing this information. The
comparability of data also contributes to the transparency of financial information, providing
better reporting for the State as a whole, as well as for agency-specific stakeholders and
interested parties, including taxpayers.

2.5.2. Reduction in Errors and Reconciliation Efforts
Common meaning for chartfield values leads to a reduction in errors during data entry, as
agency personnel will have a better understanding of the meaning of each code and the type of
information that should be captured. Further, a single statewide COA leads to a reduction in
reconciliation, as information is entered and stored with the same values across NYFMS and
CAS. This also contributes to a reduction in errors, as less information will need to be
translated from one coding string to another. The statewide COA also provides the desired
common platform for interfacing with other systems, further reducing reconciliation efforts. This
environment additionally supports the desired improvement in data integrity.


Version 1.0                                Page 5 of 38                             1/28/09
DRAFT - Chart of Accounts and General Ledger Design



2.5.3. Reduction in Work Effort
Agencies currently spend a great deal of time, as noted above, on data entry and extraction,
due to the use of multiple systems and disparate COA structures. Use of a statewide COA in a
single environment allows agencies to shift focus to data analysis and the compilation of
meaningful reports. The statewide COA also promotes the use of common chartfields
specifically defined to meet agency and statewide needs, reducing the need for workarounds
and entry of the same data to multiple systems. The internal control environment will also
improve, as agency personnel are able to move from a manual environment, with reliance on
detective controls, to a more automated environment, where preventive controls can be
implemented. This again promotes data integrity and transparency, and the reliance on
information produced by the systems.
Definition of a statewide COA additionally means that State employees transferring between
agencies will not need to learn a new, agency- or system-specific COA. A common statewide
COA will thus reduce both the effort and cost associated with training, while promoting work-role
flexibility.

2.5.4. Specific Examples of Anticipated Improvements
Specific examples which achieve the three benefits outlined above include:
•   CAS Utilization of Fully Detailed COA: Under the current batch file process, multiple
    transactions are batched together for submission for process in CAS, and OSC acts on
    those transactions at aggregated levels of the COA. Therefore, the rejection or alteration of
    transactions by OSC results in significant effort to reconcile multiple agency systems using
    financial data to the OSC “book of record”. The use of the fully detailed statewide COA by
    CAS means that less effort will be required to reconcile NYFMS and any integrated agency
    systems to reflect the actions taken in CAS.
•   Drilldown: Currently significant effort is required to gain access to the details that comprise
    the aggregate data that many managers rely on in their daily work. The new system will
    allow “drilldown” capability that will allow users to access the detail information that lies
    behind a balance. The use of one set of roll-up tables (or “reporting trees”) will ensure that
    users can move easily between specific transactions and summary reports – and that the
    information presented is consistent in both CAS and in NYFMS.
•   Detailed Control and Reporting: Currently the level of detail at which an agency can
    control and report revenues and expenditures is limited. The proposed statewide COA
    provides significantly greater levels of detail for organizational, programmatic, and
    resource/funding concepts. With that greater detail will also come the ability to set spending
    controls flexibly so that – depending on how rules are set – transactions will be rejected
    (“hard controls”) or allowed to go forward while simultaneously generating warning
    notifications (“soft controls”). As greater detail is available, agencies will be better able to
    match revenue against expenditures, enhancing analytical capabilities, cost allocation
    capabilities, reporting capabilities (especially Federal reporting) and improving the
    information available to managers for making program decisions and allocating resources.
•   Simplified and Electronic Certificates: With the ability for agencies to place spending
    controls at a much greater level of detail, the practice of creating a complex network of
    segregations within budget certificates should end. The statewide COA structure will allow
    appropriations to be “released” across the fiscal year, with spending against those
    appropriations tracked and controlled within the structure of the statewide COA. Agency


Version 1.0                                 Page 6 of 38                             1/28/09
DRAFT - Chart of Accounts and General Ledger Design



    spending controls at a detailed level and DOB’s and OSC’s spending controls at higher level
    will be fully aligned for the first time.
•   Project Tracking: Currently, no capability exists to track projects (capital, technology, or
    other types) that cross agencies, funds, and or programs. A new Project chartfield will allow
    for both agency-specific and statewide project accounting, control, and reporting. This new
    functionality will be especially useful for reliable tracking and accumulation of budgets,
    revenues and funding sources, and expenditures for initiatives that cross agencies (e.g.
    World Trade Center).
•   Detailed Revenue Information: The statewide COA structure offers the ability to track and
    report fees, fines, or other revenues separately – and in much greater detail.
•   Conform to Statewide Financial Reporting Concepts: For years different approaches
    have existed between DOB and OSC for categorizing functional spending, reporting on
    State Funds, and reporting on Medicaid spending. The statewide COA provides the
    opportunity to adopt a single approach to these concepts for use in reporting to the
    Legislature and the public. Further, the statewide COA will provide the opportunity to
    summarize relevant data on a regional basis.




Version 1.0                               Page 7 of 38                            1/28/09
DRAFT - Chart of Accounts and General Ledger Design




3.0 Business Unit Approach
Business unit is the key to all financial transactions in the system and it is one of the fields
required before a transaction can be created. While not strictly a chartfield, the business unit is
a key field that controls the use of the COA chartfields as well as a wide variety of business
rules. PeopleSoft designed the General Ledger (GL) business unit concept to represent a legal
entity with its own self-balancing set of books. In the other modules, the business unit concept
can mean different things entirely, but each module business unit must relate to a single GL
business unit.
Two approaches are available for GL business unit configuration within PeopleSoft. The first is
to establish a single business unit within which all entities process transactions under the same
rules, with distinctions between agencies accomplished through the organization chartfield. The
second approach is to set up a business unit for each agency. In making a decision on the
approach to GL business unit configuration, consideration was given to the following:
•   Functionality – Best Fit to Requirements for both OSC and Agencies: A single business
    unit significantly reduces the overhead in maintaining business rules and other setup data;
    however, since most GL business rules are set at the business unit level, it means that all
    agencies must share the same rules. A single business unit also greatly simplifies the
    elimination of inter-fund and inter-agency transactions, which must be accomplished when
    consolidated financial reports are prepared and reporting on a statewide financial position is
    required – a key consideration for OSC. Alternatively, significant benefits would accrue to
    agencies with the use of multiple GL business units, and Oracle recommends the State
    utilize a multiple GL business unit approach in NYFMS, citing the following advantages:
    o The ability to have business rules specific to an agency, which co-exist with statewide
         business rules that must apply for all agencies.
    o Greater flexibility in how agencies control spending at a detailed level.
    o The ability to set security in a manner which ensures agencies do not use each others
         codes, and to use the delivered functionality of PeopleSoft to restrict access to data by
         business unit (rather than customize).
    o The ability to make agency-specific chartfields available only to those agencies for whom
         they were created, while statewide chartfields are still used in a consistent manner.
    o The ability to have balancing entries for cash generated by the system, rather than by
         users.
    o The ability to fully utilize the delivered functionality of accounts payable and accounts
         receivable to record inter-agency transactions.
•   Risk – Complexity of System Integration: Since one of the guiding principles of COA
    design is to reduce the need for reconciliation between systems, careful consideration was
    given to whether the two instances could use different approaches to configuring their GL
    business units. Based on the information provided, Oracle believes that using differing
    approaches to GL business units in the two instances may significantly heighten the risk to
    the overall financial system. Beginning with different configurations opens the possibility of
    divergence between the two instances, with a greater dependency on highly complex
    configuration and translations in the integration layer between the two systems. Oracle
    does not recommend using two differing approaches to configuring GL business units.



Version 1.0                                Page 8 of 38                              1/28/09
DRAFT - Chart of Accounts and General Ledger Design



    While not all of the processes and all the cases in which issues will arise as a result of
    differing systems can be listed, it is clear that a level of added complexity with regard to a
    need for integration mapping and reconciliation will be present. Areas such as coding of
    journals, processes for commitment control and procurement will be affected.
•   Performance – Impact of Use of Consolidation Module: In a multiple GL business unit
    environment, the State would be required to configure a consolidation structure to perform
    the inter-fund and inter-agency eliminations necessary to generate consolidated financial
    reports. It is estimated that the time required to access consolidated cash balances would
    be only seconds, as this does not require a formal consolidation process. Based on
    customer experiences, Oracle believes that the time required to perform a full consolidation
    of business units to allow generation of financial statement reports (either cash or GAAP) is
    estimated at one hour. While not a rigorous scientific study, this collection of customer
    experiences provides a trendline that suggests that the State’s experience will be similar.
•   Effort and Cost – Required Investment to Meet Both OSC and Agency Needs: The
    ability to construct a single GL and use it for both instances of PeopleSoft represents a
    potential savings to the State. It is estimated that by creating multiple GL business units in
    CAS and copying that configuration to NYFMS, the State could save approximately 4,000
    hours of effort in configuring the NYFMS instance, as offset by the additional effort of 2,300
    hours needed to create the required CAS instance with a consolidation module.
    Conversely, it is estimated that at least 2,800 additional hours of effort would be required to
    integrate an instance with a single GL business unit with an instance with multiple GL
    business units. The difference between the two approaches could provide significant
    savings and cost avoidance for the State. It should be noted however, that multiple GL
    business units require more maintenance on an ongoing basis, with the additional effort
    estimated at 75 hours per year for the State.
NYFMS has reached a decision to use multiple GL business units. There will be approximately
68 business units in the GL module, each representing an agency. Additional business units
will be established to facilitate consolidations and eliminations. Agencies will not be permitted to
create more business units on their own, as these must created centrally, and proliferation of
business units would eventually impact performance.
At this time, the State is evaluating the benefits and risks as to whether a single, statewide GL
business unit or multiple GL business units (representing agencies) will be configured in CAS.




Version 1.0                                 Page 9 of 38                             1/28/09
DRAFT - Chart of Accounts and General Ledger Design




4.0 Setid Approach
TableSet sharing (setid) is an identification code that represents a set of control table
information or TableSets. A TableSet is a group of tables (records) necessary to define an
organization’s structure and processing options. Setting up TableSet sharing enables sharing of
control table information and processing options among business units, and minimizes
redundant data and system maintenance tasks.
If much of the State’s control table data is the same from business unit to business unit,
TableSet sharing enables the State to share that information among business units instead of
having to enter the same data multiple times. For example, assume the State has ten business
units and they all use the same account codes. Instead of entering all of the accounts ten
times, the State could simply enter them once and set up TableSet sharing to enable all of the
State’s business units to access them. This is done by associating each record group to a setid
for each business unit. TableSet sharing also enables the State to deal with exceptions within
the State. The exceptions are those business rules and values that are decentralized and
defined at the agency level. For example, Chartfield 1 is designated to hold the agency cost
accumulator code. This too is easily accommodated through TableSet sharing by assigning the
agency setid for this chartfield.
Every control value, defined as static and definitional data elements, is keyed by setid. As a
result, every business unit in PeopleSoft points to a particular setid value for each record group
combination. The following is an example of the TableSet configuration for some of the
chartfields by business unit:



                                   Example Chartfields/Setid

        Business         Department          Account        Program            Cost
          Unit                                                              Accumulator

              OMR            OMR               Share          OMR               OMR

              DOT            DOT               Share          DOT               DOT

              DOH            DOH               Share          DOH               DOH

          DOCS              DOCS               Share         DOCS               DOCS



Each business unit will have an agency specific setid as well as a shared setid. The primary
reason for this is that certain chartfields will be established at the agency level for their own
purposes. The Joint Team determined that there would be little utility in having a shared list of
values for agency-specific chartfields when they could be used for widely varying purposes. An
example of this is the cost accumulator chartfield. Sharing a common list of valid values for an
agency-controlled chartfield implies a partial numbering scheme in order to distinguish each
agency’s values from the others. Finally, it is likely that other business rules such as



Version 1.0                                Page 10 of 38                            1/28/09
DRAFT - Chart of Accounts and General Ledger Design



combination editing and commitment control will be agency-specific, as well. A separate
agency-specific setid will allow the flexibility to establish those rules as necessary. At this time,
the definition of which configuration items will be associated with each setid has not been
finalized.
The FOCAS project will maintain a shared setid for all statewide chartfields and business rules.
In an effort to maintain consistency across the systems, NYFMS will likely retain this setid for
the same configuration items. This implies a certain degree of ranging and naming standards to
avoid inappropriate usage of chartfields across agencies. This effort will be addressed as the
valid values and configurations are defined for statewide items.




Version 1.0                                 Page 11 of 38                              1/28/09
DRAFT - Chart of Accounts and General Ledger Design




5.0 General Ledger Approach
A general ledger is defined as a set of posted balances that represents a set of books for a
business unit. In PeopleSoft, the general ledger is the sum of all configuration items required to
establish the GL business unit and to provide for the posting of financial balances.
An approach for general ledger functionality follows decisions for the GL business unit and setid
definitions. Based on a decision to have multiple GL business units and multiple setids, NYFMS
must create approximately 68 GLs on each of three bases of accounting. It assumed that GL
configurations from the FOCAS instance will be offered as the baseline configuration for
NYFMS, and the two instances will be kept synchronized.

5.1. Ledgers
There are four ledgers envisioned for the NYFMS and CAS implementations:
1. Actuals Ledger – Used to record all transactions on a modified accrual basis. This is the
   delivered basis of accounting and the Actuals ledger will be the default journal generator
   ledger.
2. Full Accrual Ledger – Records entries to recast certain asset and debt transactions into
   GASB 34 requirements. Full accrual financial statements are possible when the results from
   the Actuals ledger are combined with those in the Full Accrual ledger.
3. Cash Basis Ledger – This ledger will maintain a full set of financial results on a cash basis
   rather than either full accrual or modified accrual. A modification is specified in the FOCAS
   project to load the journal generator tables with revenue and expenditure transactions at the
   time of cash settlement. These transactions are journal generated to the Actuals ledger at
   the time of recognition. It is anticipated that this modification will be ported over to the
   NYFMS implementation.
4. Average Daily Balance Ledger – This ledger is used to maintain daily cash balances for
   funds and sub-funds. These balances may be subject to interest income from the central
   Treasury function, which is allocated based on average daily balances in these funds.

5.2. Commitment Control
Commitment control is a very complex set of rules intended to enable an entity to establish and
monitor legal and other spending restrictions. In the State environment, there may be many
layers to the commitment control setup to facilitate statewide control, agency operations, and
project/grant compliance. Each of these layers performs a specific function that may or may not
apply to the entire State. All of the commitment control rules are established by setid. In
multiple GL business units, there may be a different layers with common statewide layers
repeated for each GL business unit.
Although the detailed design for commitment control is not complete, the general structure is
known. At the statewide level, the highest budgetary control will be the appropriation budget,
with this legal authorization forming the ultimate basis for control on spending. However, in
certain cases agencies may be restricted from spending appropriations in their entirety, and
may also be restricted by the pace of the “release” of these appropriations. This standard



Version 1.0                               Page 12 of 38                             1/28/09
DRAFT - Chart of Accounts and General Ledger Design



functionality in PeopleSoft will replace the current Division of the Budget certificates of
allocation, or “budget certs”.
Within the statewide structure envisioned, an appropriation may have lower levels, e.g. a sub-
schedule in an appropriation bill, but those levels must align with enacted appropriation
structure. Revenue budgets – a concept similar to a target – may also be established.
Below the statewide budget structures outlined above, a second level of control will be
established by agencies. This second level will break the appropriation amounts into even
smaller operating budgets. The quantity and nature of these smaller operating budget
structures may incorporate agency-specific chartfields.
While the above controls will all operate on a modified accrual basis, a third budget structure
may be employed to enforce spending limits on a cash basis.
A discussion of key design elements to be considered in the development of the commitment
control approach can be found in Appendix A.

5.3. Combination Edits
Combination edits are rules in the system to prevent inappropriate combinations of chartfields
on transactions. For instance, there may be a business rule that a particular account value can
only be used with three funds. This rule can be configured in the system and will be enforced
on all transactions. Combination edit rules are configured by setid and are attached to a GL
business unit.
Combination editing will only be employed for mission-critical chartfield relationships. It is
anticipated that there will be sets of statewide and agency-specific combination edit rules. Each
agency business unit will thus employ both the statewide and agency-specific rules. Statewide
combination edits will be completed by FOCAS and will be used as a baseline for NYFMS.

5.4. Interunit Transactions
With approximately 68 business units representing State agencies, inter-agency processing is
be a key practice of the State and will be accommodated in the PeopleSoft system. The details
of this business process are not complete at this time. Available methods are GL journal entry,
delivered AP, AR, and Treasury functionality, or a custom solution. Whatever method is
employed, the system will keep track of the due to/from amounts and will track the affiliate
chartfield. The delivered eliminations and consolidation functionality will be employed for
statewide financial reporting.

5.5. Calendars
Calendars control transaction processing in PeopleSoft. The detail calendar defines the
accounting periods and facilitates the maintenance of open periods. At its simplest, a user can
only post a GL journal entry with a journal date that is between the minimum and maximum
open periods. The maintenance of calendaring is performed at the GL business unit level.
Although multiple GL business units will allow individual agencies to have varying open periods,
the state will employ the same open periods across all agencies.
A monthly calendar will be set up based on the State’s fiscal year. This calendar will contain a
single adjustment period. Monthly closing will be a function of maintaining open periods as



Version 1.0                                 Page 13 of 38                             1/28/09
DRAFT - Chart of Accounts and General Ledger Design



opposed to the delivered interim closing process. There will also be a calendar to establish
budget periods for commitment control purposes.

5.6. Data Access
A key issue for the State is the ability to access financial data on an agency basis as well as on
a statewide basis. Agency information is readily available using the delivered reports and
inquiries, all of which are keyed by business unit. Delivered inquiries provide drilldowns to the
activity and transactions that underlie a given balance. Statewide data will be available via
query and custom reporting without the need to perform consolidations or eliminations (these
functions are only necessary to produce financial statements). Additionally, the State is
considering modifications to the delivered online PeopleSoft inquiries to allow these to work on
a statewide level including the drilldown on balances.
All transactions will be copied from NYFMS to CAS. This will facilitate a statewide inquiry and
drilldown without modification, as the CAS business unit structure may differ from that of
NYFMS.




Version 1.0                                Page 14 of 38                            1/28/09
DRAFT - Chart of Accounts and General Ledger Design




6.0 Chart of Accounts Design
Efforts by the COA Joint Project Team, the Workgroup, and the NYFMS and FOCAS project
teams spanning three years form the basis for the statewide COA design recommended here.
The recommendations could not have been formulated absent the participation of hundreds of
agency representatives in over 60 agencies. These meetings allowed the teams to:
•   Gather information on the current state of agency financial management system COAs and
    the use of the current CAS COA
•   Conceptually map current COA data to options for the statewide COA design to determine
    which chartfields were needed and how they would be used
•   Begin defining hierarchical (tree) structures needed to meet reporting and data analysis
    requirements
At this time, it is known that nine PeopleSoft chartfields -- Department, Program, Fund/Subfund,
Account, Project, Budget Reference, and Chartfields 1, 2 and 3 -- will comprise the new
statewide COA. The following section provides information about the proposed definition for
each identified chartfield, intended length and naming standard, setid options for controlling the
chartfield, and examples, as appropriate, of related reporting trees, including definitions of the
tree nodes, or levels within the tree. See Appendix B for a list of the remaining PeopleSoft
chartfields.

6.1. Department
Definition: Represents the lowest level of detail in an agency’s organization structure, at which
a user will enter transaction information. The Department chartfield is required on all
transactions.
Length: 10 numeric characters
Naming Standard: The first character represents the branch of government (e.g. 1 =
Executive). The second and third characters represent the agency (e.g. 01 = Division of the
Budget). All other characters are auto-numbered. The naming standard may be revised once
valid values are developed.
Setid/Control: To be determined; two options are being considered:
•   Option 1: Establish and control at the statewide level; Department is governed by the
    “shared” (statewide) setid
•   Option 2: Establish and control at the agency level; Department is governed by agency-
    specific (business unit) setids
Reporting Tree: The approach to defining Department reporting trees is dependent on the
choice of options for Setid/Control, as this will determine whether statewide levels will be
present in the Department tree. Examples of reporting trees under both options are provided
below.
•   Option 1: Department is governed by “shared” (statewide) setid; one Department reporting
    tree for the State




Version 1.0                               Page 15 of 38                             1/28/09
DRAFT - Chart of Accounts and General Ledger Design




•   Option 2: Department is governed by agency-specific (business unit) setids; each agency
    (business unit) has a separate Department reporting tree. A separate, business unit tree will
    roll-up each agency/business unit to statewide levels (Constitutional Department, Branch,
    and Total State, or Levels 3, 2, and 1, depicted above).




Version 1.0                               Page 16 of 38                           1/28/09
DRAFT - Chart of Accounts and General Ledger Design




Definitions of Tree Nodes: Note that the levels detailed below assume that Option 1 is chosen.
If Option 2 is chosen, Levels 1, 2, and 3, below, will be in a separate tree that rolls-up business
units (agencies) for statewide reporting purposes. In this case, Level 4, below, is the top level in
agency-specific Department trees.
•   Level 1 – Total State: Required top-level in PeopleSoft for statewide summarization
    purposes; provides a total view of the State from an organization perspective.
•   Level 2 – Branch: Summarization level representing three branches of government in the
    State: Executive, Judicial, Legislative
•   Level 3 – Constitutional Department: Summarization level representing the twenty
    Constitutional Departments as per Article V of the State Constitution within the Executive
    branch, as well as the top level of other identified branches.
•   Level 4 – Total Agency: Represents entities defined in statute or by Executive Order for
    revenue, appropriation, or unique financial statement preparation. In most instances, this
    represents the “owner” of the transaction or accounting record.
•   Levels 5 through 11 – Agency Use: Represents additional organization detail needed for
    entities at Total Agency level, and satisfies, at a minimum, statewide requirements of control
    agencies.




Version 1.0                                Page 17 of 38                             1/28/09
DRAFT - Chart of Accounts and General Ledger Design




6.2. Program
Definition: Captures related activities that cross organizations and are directed towards the
accomplishment of a set of recognizable objectives. The State may establish program chartfield
values to track revenue and expenditures for, and apply budgetary control to, programs within
each business unit/agency. Program will be a key field in appropriation budget control. The
Program chartfield is required on all transactions.
Length: The length of the Program chartfield is dependent on the choice of options for
Setid/Control, as this will determine if it is necessary to extend the delivered length of the
chartfield from 5 characters to 6, to accommodate ranging the values for ease of use for system
users. Two options are being considered:
•   Option 1: 6 numeric characters (assumes that Program is governed by the “shared” setid)
•   Option 2: 5 numeric characters (assumes that Program is governed by agency-specific
    setids)
Naming Standard: Under Option 1, above, each agency is assigned a range of values specific
to the agency for Program. A naming standard for Option 2 has not been established. The
naming standards, in general, may be revised once the valid values are established.
Setid/Control: To be determined; two options are being considered:
•   Option 1: Establish and control at the statewide level; Program is governed by the “shared”
    (statewide) setid
•   Option 2: Establish and control at the agency level; Program is governed by agency-specific
    (business unit) setids
Reporting Trees: The approach to defining Program reporting trees is dependent on the choice
of options for Setid/Control, as this will determine whether statewide levels will be present in the
Program tree. Examples of reporting trees under both options are provided below.
•   Option 1: Program is governed by “shared” (statewide) setid; one Program reporting tree for
    the State




Version 1.0                                Page 18 of 38                             1/28/09
DRAFT - Chart of Accounts and General Ledger Design


                                               Total Programs          Level 1: Total Programs




    Office of Management                    Family & Children’s                            Maintenance &
           Services                              Services                             Improvement of Facilities        Level 2: Major Program
      (State Operations)                     (Local Assistance)                               (Capital)




                                                             Homeless            Alterations &         Alterations &
           Agency-                     Kinship Care
                                                             Veterans           Improvements          Improvements
         specific detail                Programs
                                                             Outreach            for health &           to prolong
                                                                                                                        Level 3: Program
                                                                                     safety              asset life

                                                              National
                                                            Coalition for
                                                             Homeless         Level 4: Sub-Program 1
                                                             Veterans



                                                             Agency-
                                                           specific detail
                                                                              Level 5: Sub-Program 2




•   Option 2: Program is governed by agency-specific (business unit) setids; each agency
    (business unit) has a separate Program reporting tree. A separate, business unit tree will
    roll-up each agency/business unit to statewide levels (Total Programs, or Level 1, depicted
    above).


                                                     Total Agency            Level 1: Total Programs: Agency Specific
                                                   Programs (DOCS)           (e.g. all DOCS Programs)




                           Administration                                    Support Services         Level 2: Major Program




        Payments: Attica              Budget & Finance        Board of Prisoners            Facility Direction
       (appropriation bills)          (agency-specific)       (appropriation bills)         (agency-specific)      Level 3: Program




Version 1.0                                               Page 19 of 38                                           1/28/09
DRAFT - Chart of Accounts and General Ledger Design




Definitions of Tree Nodes: Note that the levels detailed below assume that Option 1 is chosen.
If Option 2 is chosen, Level 1, below, will be in a separate tree that rolls-up business unit
(agency) Programs for statewide reporting purposes. In this case, Level 1 becomes the Total
Programs for the specific agency/business unit.
•   Level 1 – Total Programs: Required top-level in PeopleSoft for statewide summarization
    purposes; provides a total view of the State for all programs combined.
•   Level 2 – Major Program: Equates to appropriated Program in appropriation bill copy
    (Program denoted in capital letters). Program denotes a combination of activities designed
    to achieve specified goals and objectives.
•   Levels 3 through 5 – Program and Sub-Program Levels: Captures: a) detail beneath Major
    Program contained in appropriation bills and information prescribed for statewide needs, at
    a minimum; and b) agency lower-level program needs below the level of detail outlined in
    appropriation bills and prescribed for statewide needs. Agency detail must hierarchically
    roll-up to appropriation bill and statewide prescribed levels of detail.

6.3 . Fund/Subfund
Definition: Fund - A fiscal and accounting entity with a self-balancing set of accounts (real and
nominal) for recording cash and other financial resources, which are segregated for the purpose
of carrying on specific activities or meeting certain objectives in accordance with State law, as
well as, accommodating any special regulations, restrictions, or limitations prescribed by the
State or Federal governments. Subfund: A subdivision of Fund, allowing separate accounting of
Fund resources at a lower level of detail. Note that Fund and Subfund are captured in the same
chartfield. The Fund/Subfund chartfield is required on all transactions.
Length: 6 numeric characters (note that this will required the delivered length of the chartfield to
be changed from 5 characters)
Naming Standard: Fund values beginning with zero will be renumbered; all other values are
anticipated to remain the same. Subfund values will be completely renumbered following an
effort to “clean-up” current Subfund coding and usage. This naming standard may be revised
once the valid values are developed.
Setid/Control: To be determined; two options are being considered:
•   Option 1: Establish and control at the statewide level; Fund is governed by the “shared”
    (statewide) setid
•   Option 2: Establish and control at the agency level; Fund is governed by agency-specific
    (business unit) setids
Reporting Trees: The approach to defining Fund reporting trees is dependent on the choice of
options for Setid/Control, as this will determine whether statewide levels will be present in the
Fund tree. Examples of reporting trees under both options are provided below.
•   Option 1: Fund is governed by “shared” (statewide) setid; two Fund reporting trees
    for the State (to meet Cash and GAAP reporting requirements)




Version 1.0                                Page 20 of 38                             1/28/09
DRAFT - Chart of Accounts and General Ledger Design




                                               All Funds         Level 1: All Funds




              Proprietary                   Governmental                    Fiduciary     Level 2: Fund Group




                             General                                 Special Revenue    Level 3: Fund Type



                                                                     Dedicated Mass
                             General
                                                                     Transportation
                                                                                        Level 4: Fund




          State Operations             Local Assistance              Railroad Account   Level 5: Subfund




•   Option 2: Fund is governed by agency-specific (business unit) setids; each agency
    (business unit) has a separate Fund reporting tree. A separate, business unit tree will roll-
    up each agency/business unit to statewide levels (Total Funds, or Level 1, depicted above).




Version 1.0                                               Page 21 of 38                             1/28/09
DRAFT - Chart of Accounts and General Ledger Design




                                      All Agency Funds   Level 1: All Funds: Agency-Specific
                                            (DOT)        (e.g. DOT)



          Proprietary                  Governmental                  Fiduciary      Level 2: Fund Group




                        General                               Special Revenue    Level 3: Fund Type


                                                              Dedicated Mass
                        General                               Transportation
                                                                                 Level 4: Fund



          State Operations        Local Assistance            Railroad Account   Level 5: Subfund




Definitions of Tree Nodes: Note that the levels detailed below assume that Option 1 is chosen.
If Option 2 is chosen, Level 1, below, will be in a separate tree that rolls-up business unit
(agency) Funds for statewide reporting purposes. In this case, Level 1 becomes the Total
Funds for the specific agency/business unit.
•   Level 1 – All Funds: Required top level in PeopleSoft for statewide summarization purposes;
    provides a total view of the State for all Funds combined.
•   Level 2 – Fund Group: Summarization level representing three Fund Groups: Governmental,
    Proprietary and Fiduciary.
•   Level 3 – Fund Type: Summarization level representing funds of similar characteristics and
    purposes in accordance with Generally Accepted Accounting Principles (GAAP). State
    Finance Law mandates the use of seven Fund Types: General, Special Revenue, Debt
    Service, Capital Project, Enterprise, Fiduciary, and Internal Service.
•   Level 4 – Fund: A fiscal and accounting entity with a self-balancing set of accounts
    (real and nominal) for recording cash and other financial resources, which are
    segregated for the purpose of carrying on specific activities or meeting certain objectives in
    accordance with State Law, as well as, accommodating any special regulations, restrictions
    or limitations prescribed by the State or Federal Governments.
•   Level 5 – Subfund: A subdivision of Fund, allowing separate accounting of Fund resources
    at a lower level of detail.




Version 1.0                                          Page 22 of 38                               1/28/09
DRAFT - Chart of Accounts and General Ledger Design



6.4. Account
Definition: Identifies the type of resources acquired or disbursed and defines the purpose of a
transaction. The Account chartfield will be required on all transactions.
Length: 10 numeric characters
Naming Standard: The first two digits of the Account chartfield will have smart coding
imbedded, as this is the standard across accounting systems to provide visual cues to users.
This naming standard may be revised once the valid values are developed.
Setid/Control: Account will be governed by the “shared” (statewide) setid; values will be
established and controlled at the enterprise level.
Reporting Trees: There will be at least two statewide Account reporting trees: one each for
Cash and GAAP reporting requirements. An example of an Account reporting tree is provided
below:

                             Total Accounts   Level 1: Total Accounts




        Revenue                                     Expenditures          Level 2: Account Type




         Misc                                          Dept
                                                                         Level 3: Account
        Receipts                                     Operations




                             Personal                                           Non-Personal
                                                                                                   Level 4: Sub-Account 1
                             Service                                              Service




                                          Temp                     Supplies &
                   Regular                                                                     Equipment         Level 5: Sub-Account 2
                                         Service                    Materials




                                                       Office
                                                                                 IT Supplies         Level 6: Sub-Account 3
                                                      Supplies




                                          Pens                          Paper          Level 7: Sub-Account 4




Version 1.0                                        Page 23 of 38                                       1/28/09
DRAFT - Chart of Accounts and General Ledger Design



Definitions of Tree Nodes: All levels will be defined by the State.
•   Level 1 – Total Accounts: Required top level in PeopleSoft for statewide summarization
    purposes; provides a total view of the State for all Accounts combined.
•   Levels 2 through 4 – Account Type, Account, Sub-Account 1: Summarization Levels
    representing a grouping of account data elements that may correspond to financial plan
    categories.
•   Levels 5 through 7 – Sub-Accounts 2 through 4: Represents a further breakdown of the use
    of, and is hierarchically under, Account.

6.5. Project/Grant
Definition: Used to track particular initiatives that have a start and end date, specific
appropriation authority, and may cross fiscal years. Projects may be operational or capital in
nature. Note that, when the Project Costing and Grants modules are implemented, additional
Project chartfields (e.g. activity) will be defined and used. Information about these chartfields
can be found in Appendix B.
Length: 15 numeric characters
Naming Standard: Project codes must be unique across agencies; the State may auto-number
project codes to facilitate the timely creation of new codes. This naming standard may be
revised once the valid values are developed.
Setid/Control: Project is controlled by the Project Costing Business Unit when the Project
Accounting and Grants modules are implemented in NYFMS. If the modules are not in place,
Project chartfield will be controlled by agency-specific setids.
Reporting Trees: Reporting trees have not been identified for the Project chartfield at this time.
Key relationships within a Project are governed by the project-specific chartfields rather than by
trees. Project trees may be necessary if a user is grouping several projects.

6.6. Budget Reference
Definition: Used to identify the appropriation year.
Length: 4 numeric characters
Naming Standard: Budget Reference codes will be four-digit years.
Setid/Control: Budget Reference will be governed by the “shared” (statewide) setid and will be
established and controlled at the enterprise level.
Reporting Trees: None identified.

6.7. Chartfield 1 – Cost Accumulator
Definition: Tags transactions for cost accumulator purposes for agencies. Chartfield 1 will
ONLY be available for use for agency cost accumulator purposes.
Length: 10 alphanumeric characters
Naming Standard: A naming standard has not been defined at this time; however, it is
expected that agencies will retain their current cost accumulator codes.



Version 1.0                                Page 24 of 38                            1/28/09
DRAFT - Chart of Accounts and General Ledger Design



Setid/Control: Chartfield 1 will be governed by the agency-specific (business unit) setids and
will be established and controlled by agencies (business units).
Reporting Trees: No reporting trees have been identified at this time.

6.8. Chartfield 2 and Chartfield 3
Chartfields 2 and 3 are anticipated for use in the statewide COA; however, specific designations
for these chartfields have not yet been made. This information will be made available as it is
known. Any information carried in these chartfields will be distinct from that defined in the
chartfield outlined, above.




Version 1.0                              Page 25 of 38                            1/28/09
DRAFT - Chart of Accounts and General Ledger Design




7.0 Chart of Accounts Governance
Governance of the statewide COA is crucial to the long-term success of the implementation of
one statewide COA in both NYFMS and CAS. The best chartfield design can be easily undone
if the concepts are not properly established and maintained. If the statewide COA is allowed to
become inconsistent, the benefits of reliable data are lost, and significant effort will be required
to maintain comparable financial data.
Prior to tackling the issue of governance, it is helpful to understand the activities that comprise
chartfield maintenance. The typical business process begins with a request for a
new/changed/inactivated chartfield value. In the case of a new value, the request must be
evaluated to determine if the request is valid. For instance, an agency might request a new
department chartfield. The evaluation must first focus on whether the requested value really is
a department according to the definition of that chartfield. If not, a different chartfield must be
identified. Alternatively, it may be determined that the request is completely invalid.
Once the request is approved, then the new value, with a proper effective date, is created.
Following that, all trees related to the chartfield must be reviewed to ensure that the new value
is properly reflected. Then the combination edit rules must be reviewed to ensure that the new
value will work with the rules. Finally, commitment control budget definitions must be reviewed
to ensure that the new value will not circumvent budgetary controls at any level. The exact
steps for each of these activities will vary by chartfield. The point is to illustrate that chartfield
maintenance is not a trivial matter in terms of level-of-effort. The very quality of the State’s
financial accounting and budgetary controls depends on keeping the statewide COA clean and
maintaining the distinct concepts in their own fields.
In a simple environment, with a single setid, the governance of the statewide COA can be
maintained centrally with few issues. However, the State will use multiple setids, thus raising
questions about ownership and maintenance of the chartfield values.
Two options for chartfield governance should be considered: Central Control or Hybrid Control.
Central Control implies that all chartfield maintenance will be done at the State level. Hybrid
Control would grant the maintenance of agency-specific fields to the agencies.
Central Control has the natural advantage of maintaining a one-stop shop for all chartfield
maintenance. This provides an enterprise view of all chartfield maintenance activities and
provides better assurance that the concepts are being properly maintained. The downside to
this approach is the sheer level of effort – especially on the agency-specific chartfields.
Performing all of the steps for each request will take time. Without proper staffing for this
function, the service level could suffer and may expose the State to risks associated with the
inability to do business or to properly account for that business.
Hybrid Control is a way to share the workload. Under this approach, some or all of the agency-
specific chartfields are maintained by the agencies. The downside is the potential loss of
centralized oversight of these chartfields. New values can be added by the agencies, with the
risk that the values do not conform to the approved design. It is possible to do post-audit
reviews of new chartfields, but the effects of inappropriate chartfield maintenance may not be
completely reversible.
Both of the approaches outlined above represent ‘best practice’. Selection of an option
depends on the entity and its culture. It also depends on the relative risk to the organization.


Version 1.0                                 Page 26 of 38                               1/28/09
DRAFT - Chart of Accounts and General Ledger Design



There is significant change in the proposed statewide COA from the legacy systems, and there
will be a natural tendency to gravitate back toward the old codes. This risk is expected to be
especially high in the first years of an implementation. Central maintenance could mitigate this
risk, but raises the question of staff resource availability to maintain the chartfields and in what
organization they will reside.
Regardless of which approach is adopted, a single entity must be identified to maintain the
central chartfields. In most implementations, the core implementation team remains intact even
after go-live. This group is intimately familiar with the system and is mindful of the decisions
behind various functions. Members of the implementation team are uniquely qualified to
support the system and to apply upgrades and additional functionality over time. One of the
duties of this team could be to maintain the statewide COA.




Version 1.0                                 Page 27 of 38                             1/28/09
DRAFT - Chart of Accounts and General Ledger Design




8.0 Next Steps
As the statewide COA, GL business unit, and setid designs are almost complete, the Joint
Team is able to move forward with the implementation of the systems. This means that
business process flows and configuration tasks may be started. However, there are several
configuration items that are in the critical path for all of the modules and should be completed as
soon as possible.
The configuration tasks listed below will be completed by the State with significant input from
agencies. The Agency COA Workgroup will continue its involvement as valid statewide COA
values and trees are developed. Additionally, smaller workgroups with appropriate agency
participation will be utilized to work on specific design items, such as definition of valid values
for Chartfield 1 – cost accumulator. All design decisions will be subjected to appropriate review
by stakeholders prior to being implemented. It should also be noted that configuration decisions
are not static. They can be changed as business requirements change during the
implementation. Changes will also be subject to appropriate review and testing.

8.1. Valid Values
Following the approval of this design, the State can move forward with developing valid values.
This is a vital step and it is reasonable to expect that it will take a significant effort. Many of the
existing fields are being renumbered. During this process it is important to evaluate the values
and to determine whether existing values are still valid. This represents an opportunity to scrub
the existing values, which will pay even greater dividends at the time of conversion. The State
must develop an approach for developing the valid values and then produce those values as
soon as possible.

8.2. Mapping
In conjunction with the valid values, a mapping exercise will be necessary to crosswalk the old
values to the new values. This is another considerable effort that is necessary for interfaces
and for the bulk-load process. Ideally, one could perform this mapping on a field-by-field basis.
The result is that each old value maps to one new value. A given transaction line using old
codes could be converted to the new statewide COA by looking up each value and replacing it
with the new PeopleSoft value. This approach is not likely to work due to changes in the level of
detail and in some of the chartfield concepts. If this holds true, then the mapping must be done
on a codeline basis. An entire transaction line would be mapped to a complete PeopleSoft
transaction line. It is important to identify this mapping approach prior to developing valid
values. This will maximize the use of agency time during the value development stage.

8.3. Commitment Control
Finally, the State must begin work immediately on a detailed design for commitment control.
Further, a failure to have a robust design in hand prior to developing values for key chartfields
such as program (which is linked to appropriation bill copy) could result in an inability to realize
the desired benefits. The FOCAS project will establish statewide commitment control rules and
these rules will be used as a baseline for NYFMS. As the ability to implement financial controls
at a lower level of detail is a key benefit expected to result from the new system, NYFMS will
additionally establish agency-specific commitment control rules.


Version 1.0                                  Page 28 of 38                              1/28/09
DRAFT - Chart of Accounts and General Ledger Design



8.4. Tree Development
To the extent possible, trees should be created once the valid values have been established.
This task is most important for commitment control, as the budget structures cannot be
physically established until the related trees are completed. Trees for reporting purposes are
less time-sensitive but must be completed prior to the design of any reporting. The tree
development tasks outlined in this document encompass the chartfield trees only. Trees on
other fields or required for modules other than GL must be developed by the NYFMS system
integrator during the implementation.

8.5. Combination Edit Rules
The FOCAS project will establish statewide combination edit rules and these rules will be used
as a baseline for NYFMS. Agency-specific rules will need to be identified and evaluated to
determine whether combination edits are the proper tool. The rules that make the cut will be
configured and those that don’t will be enforced by other tools in the system such as speedtypes
and commitment control.




Version 1.0                               Page 29 of 38                           1/28/09
DRAFT - Chart of Accounts and General Ledger Design




9.0 Additional Considerations for the Systems Integrator
Much of the above is intended for a wide audience including agencies and the implementation
teams. However, there are a few items that apply more to the Systems Integrator (SI) for
estimating purposes. Please note that the many of these items are not firmly defined and are
included to provide a flavor for possible complexities in the implementation.

9.1. Setid
Significant effort is expected for tableset sharing. In a multiple business unit/setid environment,
great care must be exercised when assigning setids to record groups for each business unit.
Further, in the case of business rules that rely on other configuration items (e.g. combination
edits) record groups must also be tied to setids for each opposing setid. While much of this
work may be completed prior to the start of the SI implementation, an approach is still
necessary for maintaining the tableset control structure and making changes as necessary.
CAS will effectively be working with a single setid. This requires an approach from the NYFMS
project with respect to agency-specific record groups – especially chartfields. If a given
chartfield has an agency-specific setid, then care must be exercised in the valid values to
ensure that they can be passed to CAS seamlessly. This implies a form of ranging or naming
standard to ensure unique values. Alternatively, a mapping table or chartfield attribute may be
required to map to the statewide value for interface purposes.

9.2. Commitment Control Design
It is anticipated there will be a large number of commitment control budget definitions. Several
will be statewide as outlined above. The majority will be agency-specific. In an effort to
minimize future maintenance, a shared setid will probably be used for all commitment control
configurations. This is possible because budget definitions are activated only when attached to
a business unit and detail ledger. Therefore, all budget definitions can be maintained under a
single setid without requiring that all agencies be subject to all definitions.

9.3. Commitment Control Trees
The trees outlined in Section 6.0 are for financial reporting purposes. The structure of these
trees dictates that the nodes will be contained in the Tree Node table. There will be additional
trees for commitment control purposes. It is reasonable to expect these rollup trees for the
fund, account, department and program fields. Due to varying agency needs, there may be as
many commitment control trees per chartfield as there are business units.

9.4. Chartfield Configurator
PeopleSoft delivers the Chartfield Configurator that provides the ability to make specific
changes to the delivered chartfields. These changes include display length, label, size, and
name. The Configurator is also used to activate and inactivate chartfields. The State
anticipates using this functionality as follows:
•   Inactivate unused chartfields
•   Increase the field length of the Program and Fund chartfields


Version 1.0                                Page 30 of 38                             1/28/09
DRAFT - Chart of Accounts and General Ledger Design



•   Change the display length of chartfields when the delivered field size is greater than
    needed.
Consideration was given to relabeling the fields. However, relabeling does not change the
name of the underlying field in the tables. This creates a mismatch between the online screens
and the tables, potentially creating confusion during report and query development. The State
determined that adjusting to different field labels on the screens would be less problematic than
supporting users during query development.

9.5. Known NYFMS Modifications
The FOCAS and NYFMS projects have identified a number of customizations to the PeopleSoft
system in order to meet State requirements. Any modification that is deemed statewide will be
provided by the FOCAS project to NYFMS. However, there are two modifications unique to the
GL module of NYFMS that are known. They are required due to the multiple business unit
strategy:
1. Create a version of the delivered Ledger Inquiry that is not keyed by GL business unit. This
   new inquiry must also provide functioning drilldowns. The NYFMS team understands that
   this inquiry may drive the statewide chartfields toward a shared setid.
2. Create an umbrella transaction that provides for commitment control budget transfers across
   business units. This modification should not make any changes to the delivered budget
   journal/transfer structures.

9.6. Project Accounting
The FOCAS project is implementing the Project Costing (PC) module while NYFMS is not (in
the initial phase). This creates an issue with respect to the Project chartfield. CAS will expect
the additional project costing fields (PC Business Unit, Activity ID) on all project-related
transactions. The data for these fields will not be available in NYFMS because these fields are
only used in conjunction with the PC module. An approach must be developed that facilitates
the data integration between the two systems, allows for the future implementation of the PC
module in NYFMS, and does not adversely impact other system functionality.




Version 1.0                                Page 31 of 38                            1/28/09
DRAFT - Chart of Accounts and General Ledger Design




A.0 Key Decisions for Commitment Control
Commitment Control is a complex set of business rules that facilitate the management of
budgets and the activity against them. These rules are organized into budget definitions. There
may be many budget definitions in play for a given entity. The following items are the key
design elements that make up a given budget definition.

A.1. Control/Track
The control option determines how the budget definition will behave during budget checking.
Each budget structure established in PeopleSoft can be set to Control, Track, or Track with No
Budget. Control will stop any transaction that attempts to over-expend the available spending
authority. Track will warn the user of the over-expenditure but will allow the transaction to
continue. Track with No Budget is a special variety of Track. For Control and Track budgets,
commitment control must find a corresponding budget for the transaction being checked. If
such a row is not found, the transaction fails regardless of funds available. Track with No
Budget functions exactly like a Track budget except that it will allow a transaction to continue
even if no corresponding budget is found. The commitment control log and expenditure
balances are updated and the transaction is marked as ‘valid’.
It is important to note that the Control/Track decision is contained in a hierarchy. The highest
level is at the budget structure itself. Inside of the budget structure, control/track can be
overridden at the control chartfield level. Finally, control/track can be set at the individual
budget line. The lowest level setting will determine the commitment control behavior with
respect to control/track.

A.2. Budget Keys
The budget keys are the chartfields that make up a particular budget. For instance, an
appropriation budget may be a unique combination of program, fund, and account. An
operating budget, which is generally more detailed, may be composed of department, fund,
program, and account. The number of chartfields in the key implies the level of detail in the
budget. A side effect of budget key chartfields is that all chartfields in the budget key are
required on the detail transaction. This functions as a built-in, high-level combination-editing
rule.

A.3. Chartfield Rollups (Translations)
Once the budget key chartfields are selected, the agency must decide whether to roll any of
them up for budget checking purposes. The primary example utilizes the account chartfield.
Assume that there is a rollup on account where the lowest level has values for pencils, paper,
and paper clips. This is the level that is used on transactions. This level is far too detailed to
budget though. Assume then that these three values roll up to a value called office supplies.
Finally, the office supplies value rolls up to materials and supplies. These rollups are defined
using a tree hierarchy.
When setting up a budget that uses the account chartfield, the agency must determine what
level of the rollup to use. For high-level control budgets, the agency may select the materials
and supplies level. This provides control on spending without the burden of resolving a large



Version 1.0                                Page 32 of 38                              1/28/09
DRAFT - Chart of Accounts and General Ledger Design



number of budget check errors. For organizational management budgets, the agency may elect
to budget at the office supplies level. This provides meaningful budget-to-actuals comparisons
but, due to the tracking feature, will not prevent the overspending of this category. In all cases,
the detail values are entered on financial transactions.

A.4. Calendar
Budgets typically apply to a time period. This period could be monthly, annual, quarterly or any
other appropriate time span. The definition of this period is called the Budget Detail Calendar.
The calendar defines budget periods and explicitly states the start and end dates for each
period. If the budget is based on the State’s fiscal year, then one might define the budget
periods as ‘2008’, ‘2009’, and such. Each of these periods would begin on April 1 of the
relevant year and would end on March 31 of the following year.
When the calendar is attached to the budget definition, then all budgets for this definition will
require a value for budget period. Therefore, it is possible to have the same budget in the
system but for different years or periods.
The calendar is an optional field. If no calendar is specified, then the budget does not have a
fixed time period associated with it. This is typically used in projects and grants where the
timelines might exceed or vary significantly from the State fiscal year. This allows budgeting for
the project or grant on a life-to-date basis without artificially breaking the budget up into annual
time periods.

A.5. Rulesets
Budget keys, translations, and calendars are all defined on the same page and are closely
related. In smaller entities, a single combination of these settings can meet requirements within
a given budget definition. However, many entities have variations within a given budget
definition. A good example of this is the appropriation budget for the State. There are many
appropriations that can be defined as a combination of program, fund, account, and budget
period. But there are other programs that are appropriated at lower levels of detail such as local
assistance and capital projects. This implies that different sets of keys and translations are
necessary to describe the appropriations laid out in bill copy.
The definition of budget keys, chartfield rollups, and calendars is set by a structure called
ruleset. The budget key chartfields and the chartfield rollups can vary by ruleset within the
same budget structure. Building upon the scenarios described above, the appropriation budget
definition would need at least three rulesets – one for each different set of key chartfields. Now
the system needs to know which of the three different set of keys to apply to a given transaction.
The mechanism for this is the ruleset chartfield. The ruleset chartfield is defined at the budget
definition level. In the current example, the ruleset chartfield might be the program chartfield.
Each ruleset would then have a list of program values that belong to it.
When a detail transaction is created, the program chartfield on the transaction is evaluated.
The system figures out which ruleset contains that value. It then retrieves the keys, translations,
and calendar tied to that ruleset.
The important takeaway from this is that only one chartfield may be used to define rulesets.
Clearly, this must be very carefully decided as this setting can only be done for the budget
definition as a whole.



Version 1.0                                Page 33 of 38                              1/28/09
DRAFT - Chart of Accounts and General Ledger Design



Oracle recommends the fewest possible rulesets necessary to meet requirements, primarily to
reduce budget maintenance.

A.6. Control Chartfield
The control chartfield is the chartfield by which the budget is activated. Assume that all
expenditure transactions should be subject to the appropriation budget except for those in Fund
999. This means that the system has to evaluate the transaction to determine whether it should
check against the appropriation. The way that it does this is to look at the fund and then
determine if that fund is subject to appropriation control. The mechanism for this is the control
chartfield. Like the ruleset chartfield, the control chartfield is a single chartfield that the system
can look to determine whether it is subject to the budget definition.
To follow the scenario above, the control chartfield for the appropriation budget definition would
be fund. Then there would be a list of fund chartfield values that are subject to appropriation
checking. In this example, Fund 999 would not be in this list. Transactions with this fund value
would not be checked against the appropriation budget definition.
There is a secondary function of the control chartfield. Continuing with the above example,
each fund or range of funds listed, may have certain control settings that vary from the overall
budget definition. The settings that can vary are control option, tolerance, start date, end date,
and budget status. This means that on a fund-by-fund basis, these settings can be altered to
meet specific requirements for that fund while leaving these processing of other funds alone.
Again, great care must be taken when selecting the control chartfield as it applies to the entire
budget definition. It is likely that there will be conflicting requirements for this field and the
cost/benefit of each option must be evaluated.

A.7. Excluded Accounts
In budgeting, it is natural to assume that the subject is expenditures. However, the PeopleSoft
system can budget on any account type. A good example of a non-expenditure budget is the
revenue estimate. Revenue budgets set targets for various revenues and then track the
progress toward those targets. It is also possible to budget assets or other financial balances.
When defining a budget, one must list all of the account types that are not to be checked
against the budget definition. For expenditures, one would exclude revenue, asset, liability, and
equity accounts. The effect is that only transactions with expenditure accounts will check
against this budget definition.
There is a further, optional level of detail on this setup. There may be specific expenditure
accounts that you do not want to budget check such as depreciation expense. These accounts
can be listed with the effect that they are not checked against the budget.

A.8. Parent/Child Budgets
Budget structures can be tied to one another in parent/child relationships. A relevant example
might be the appropriation and segregation budget definitions. A parent/child relationship is
used when the child budget is very similar to the parent but breaks the parent budget into
smaller buckets by additional keys, lower levels of translation, smaller time periods, or differing
spending authority amounts. If these two budgets are tied together, then the sum of the




Version 1.0                                 Page 34 of 38                              1/28/09
DRAFT - Chart of Accounts and General Ledger Design



segregation budgets cannot exceed the related parent appropriation budget. Both budget’s
available balances are affected simultaneously by budget checked transactions.
Parent/child relationships can have many levels. It is possible to have a parent budget, a child
budget, and a child of the child.




Version 1.0                               Page 35 of 38                            1/28/09
DRAFT - Chart of Accounts and General Ledger Design




B.0 Other Chartfields
In developing the design for the statewide COA, the Joint Team considered all of the delivered
PeopleSoft chartfields. Chartfields not detailed for use in Section 6.0 of this document are
outlined below.

B.1. Project-related Chartfields
The first wave of the NYFMS implementation of PeopleSoft does not include rollout of the
Project Costing and Grants modules; these modules will be implemented during a future
implementation phase. The Joint Team, however, in designing the statewide COA, developed
recommendations for use of Project-related chartfields. This information is detailed below.
When NYFMS implements the Project Costing and Grants module, this is the intended usage of
these chartfields. A disposition for aligning the NYFMS and FOCAS instances of PeopleSoft
with respect to Project Costing and Grants modules, and how information originating in NYFMS
that requires project-related information in FOCAS will be generated in NYFMS, transmitted and
captured in FOCAS, and sent back to NYFMS prior to implementation of these modules, has not
been developed at this time.

    Chartfield          Definition           Length           Values         Required/Optional

Project ID         Collects all           15 – numeric    System-            Required for all
                   transactional                          generated in       Project-related
                   information for any                    sequential order   transactions
                   special, unique
                   event or endeavor
                   not tracked by
                   another chartfield

Project Costing    Represents State       5–           To be                 Required when
Business Unit      agencies               alphanumeric determined            Project ID is used

Activity           Identifies the         15 – numeric    To be              Required when
                   specific tasks that                    determined         Project ID is used
                   make up a Project

Resource Type      Used to identify the   5 – numeric     To be              Optional
                   purpose of the                         determined
                   transaction, the
                   origin of a
                   transaction, or the
                   resource for the
                   task




Version 1.0                               Page 36 of 38                           1/28/09
DRAFT - Chart of Accounts and General Ledger Design




    Chartfield            Definition           Length              Values         Required/Optional

Category            Used to track           5 – numeric      To be               Optional
                    resource detail; it                      determined
                    serves as a further
                    breakdown of
                    Resource Type

Subcategory         Used to further         5 – numeric      To be               Optional
                    define Category                          determined


B.2. Affiliate Chartfields
PeopleSoft affiliate chartfields, listed below, are used for creation of balancing entries for
interunit and intraunit transactions.

                              PeopleSoft
                                                     Proposed Usage (as
       Chartfield            Recommended                                              Length
                                                         applicable)
                                Usage

Fund Affiliate            Correlates                Same as PeopleSoft        3 – proposed
                          transactions between      recommended usage
                          Funds when using a
                          single intraunit
                          account

Affiliate                 Maps transactions         Affiliate is required     5 – proposed
                          between Business          under multiple GL
                          Units when using a        Business Units
                          single interunit
                          account




Version 1.0                                 Page 37 of 38                              1/28/09
DRAFT - Chart of Accounts and General Ledger Design




B.3. Other PeopleSoft Chartfields
The remaining delivered PeopleSoft chartfields are detailed below, with a description of the
recommended PeopleSoft usage. These chartfields are not recommended for State use at this
time.

      Chartfield                           PeopleSoft Recommended Usage

Operating Unit          Represents a subset of a Business Unit. It can be used to indicate a
                        location, such as a distribution warehouse or a sales center

Operating Unit          Correlates transactions between Operating Units when using a single
Affiliate               intraunit account

Alternate Account       Classifies the nature of a transaction for regulatory authority. Use it
                        for statutory accounting.

Product                 Captures additional information useful for profitability and cash flow
                        analysis by product sold or manufactured

Scenario                Identifies different budget iterations that use different assumptions

Book Code               Identifies subsets of ledger rows to segregate and maintain in the
                        same ledger various accounting, recording and reporting requirements

Adjustment Type         Defines Adjustment Type associated with varying accounting
                        treatments of prior periods adjustments

Statistics Code         Used to defined statistical data such as number of units in conjunction
                        with a dollar amount




Version 1.0                              Page 38 of 38                              1/28/09

								
To top