Approaches for Changing the Chart of Accounts: Eliminating ... · PDF fileApproaches for...

tel: 407.591.4950 | toll-free: 1.888.943.5363 | web: www.eprentise.com

Approaches for Changing

the Chart of Accounts:

Eliminating the Risks

an eprentise white paper

Approaches for Changing the Chart of Accounts: Eliminating the Risks

Copyright © 2014 eprentise, LLC. All rights reserved. www.eprentise.com |

© 2014 eprentise, LLC. All rights reserved.

eprentise® is a registered trademark of eprentise, LLC.

FlexField Express and FlexField are registered trademarks of Sage Implementations, LLC.

Oracle, Oracle Applications, and E-Business Suite are registered trademarks of Oracle Corporation.

All other company or product names are used for identification only and may be trademarks of their respective owners.

Author: Skip Straus

Published: August 19, 2010

www.eprentise.com



This paper is for decision makers who find the Chart of Accounts (COA) structure in Oracle E-Business

Suite is holding back their business, understand there are inherent risks in changing the COA, and will

nevertheless make the change if the risks can be eliminated. The COA defines how accounting

transactions, assets, and liabilities are processed and classified. The COA is the framework for financial

reporting and operational decision making.

The question is not whether the decision maker’s team can change the COA. They can. The prevalent

available options include a commercial product and scripts written by consultants. The decision is really a

question of the risks and the results.

Without going into the technical details of the COA within the E-Business Suite, this paper asserts that at

least one commercial product from an Oracle Partner can be used to change the COA with low risk, and

that competing approaches based on custom in-house developers or consulting services have

unacceptable risk, even if the costs appear lower.

COA and Accounting Flexfield in Oracle EBS

In the context of the Oracle E-Business Suite, it is customary to talk about the Accounting Flexfield, with

multiple segments, as the Chart of Accounts. In this paper, the COA refers to an individual Accounting

Flexfield, including all the segments. Each segment is constrained by an allowable set of values. A code

combination refers to the specific combination of segment values across the entire accounting flexfield.

Four Ways to Change COA

There are four primary approaches to changing the Chart of Accounts in Oracle E-Business Suite (EBS):

Start all over again by reimplementing Oracle EBS and migrating all the old EBS data. This is what

Oracle implicitly suggests.

Create a new Set Of Books (11i) or Ledger (R12) with a new COA and use the financial consolidation

function in Oracle to map one COA into another one for reporting. This is for converting General

Ledger (GL) balances only, and does not allow for the customary drill down from GL into the

subledgers of Fixed Assets, Payables, Receivables, or Inventories. It is a work around, in that you can

create financial and operational reports at the GL level using the new COA, but the subledgers use

the same fundamental COA within EBS.

Create custom software programs, SQL code, or “loader scripts” to make a specific change for a

specific chart of accounts to a new chart of accounts. This is what Oracle means when they write:

“Oracle STRONGLY RECOMMENDS that you never use SQL*Plus, Oracle Data Browser, database

triggers, or any other tool to modify Oracle Applications data unless otherwise instructed” and warns

that “Changing the existing flexfield structure after flexfield data has been created can cause serious

data inconsistencies.” In most cases the organization creates their own custom scripts or engages a

consulting firm to do so.

Use a commercial software product from an Oracle Partner that complements Oracle E-Business

Suite.



The methods entail radically different risks. This paper only discusses the third and fourth

approaches. Note there is a continuum where custom programs, SQL code, or scripts may be passed off

as commercial-grade software.

Changing The COA by Custom Programs or Scripts

This is usually a one-time project, for a single EBS customer, specific to a single EBS environment. There

may be a well-defined specific mapping scenario with a project deadline. There may be a single source

COA or set of COAs, and the objective is to map to a single target COA or set of COAs.

This approach relies on a developer/programmer writing SQL code that substitutes one new COA

segment value or one new code combination for an existing one. That programmer must also write code

that updates all records in the database where the code combinations are used.

Sometimes a consultant or programmer will characterize bespoke programs or scripts, possibly written for

a previous engagement, as a software product.

The first obvious symptom that custom code is being proposed is if the consultant can’t deliver the

software (scripts or code) without knowing in advance the current and new COA values, structures,

segments, code combinations, and the mappings from the current to new you would like to employ. A

second common symptom is an uncertain or variable price. A third is the absence of a clear statement of

specifications, what the software will and won’t do. The specifications usually have gaps, inaccuracies, or

misunderstandings about how the COA works in EBS and how the accounting and finance organization

uses the COA. There may be a services contract calling for the vendor to retain any intellectual property

that results from the COA change code or scripts. Finally, if the finance team decides to change the COA

structure or mapping after the first test run, there may be delays so the code or scripts can be tailored to

meet the new requirements.

Changing Accounting Flexfields with a Software Product

The software is designed to fill a well defined gap between Oracle’s EBS offering and many customers’

actual requirements, over an extended period and multiple EBS versions and releases. There is an

investment in a general purpose solution that allows for mapping any source COA to any target COA, or

sets.

A commercially available, “off the shelf” (COTS) software product performs according to specifications

“out of the box,” with “no assembly required.” A software product uses the same code for all customers

regardless of the mapping, the version of EBS, or the modules installed. Although customers are

sometimes unconcerned how a product is made and maintained, many know that successful software

product companies use a formal development process with controlled releases, release notes, and formal

testing in several different environments.

A general purpose product for changing the COA in Oracle offers a user interface oriented to accounting

and finance professionals, rather than SQL coders. The interface guides the users through the process of

changing the COA, and allows for variations. The product knows where and how to look within EBS to



discover the current structure, segments, values, and code combinations on its own. It provides many

different mapping options (such as by segments, values, or code combinations, one-to-one, many-to-one,

splitting a segment, or combining segments, and changing the length of segments). It allows the user to

define any mapping from any source to any target accounting flexfield, and then it executes the

transformation. The user can define the mapping, execute the transformation, and inspect and test the

results multiple times. There are built-in exception and error handling, audit trails, and full drill-down

capabilities from anywhere in EBS modules and reports. The most obvious indicators of commercial

software products are a published price list, user manuals, a software product license, and numerous

customers who have successfully used the same product in their production environment.

Changing an EBS Accounting Flexfield Involves More Than “Loading a Mapping Table”

There are reasons that Oracle does not provide a way for customers to change the accounting flexfield,

and why they warn customers not to do it. It is an extremely difficult process, and there is a risk of

violating the data integrity of your E-Business Suite and corrupting the database. As a result, using

custom scripts and software calls for a tremendous amount of faith in the knowledge of the in-house

developer or in the external consultants. Using commercial software also calls for faith in the vendor. You

hope they know enough to complete the task.

Table 1: Examination of Changing Chart of Accounts in EBS, Comparing Custom and Commercial

Approaches

General Characteristics

Requirement Custom Scripts

eprentise Packaged

Software

Development

Approach

Custom scripts are written

by a developer for a specific

mapping scenario.

FlexField software was written

as commercial software with

a standard development

methodology.

EBS Expertise

Developer does not change

charts of accounts for a

living – maybe has done it

once or twice for a

customer.

Specifically geared to E-

Business Suite modules with

built-in rules – significant

amount of R & D

incorporated into software

product.

Tested in Different

Environments

The environment in which

the developer has

previously tested (if any)

will not be the same as your

Tested in several commercial

environments with a range of

versions and EBS modules

with all types of



environment (different

versions, different modules

in E-Business Suite).

mappings. Strict testing

methodology including

white-box and black-box

testing with formal test

scripts, documented results,

and a full, structured

development lifecycle.

Commercial

Software

Development

Unknown development

standards and version

control.

Complete version control and

release notes. Each new

release has been tested with

a formal testing

methodology.

Flexibility to

Accommodate

Different and

Changing Mapping

Requirements.

Accounting and

finance business

decision makers may

revise the design of

the target COA or

the segment values

in the middle of the

project.

Code needs to change if

mapping changes.

No need to know the

mapping and no code

changes to try different

mapping models. Software

can change any source chart

of accounts to any target

chart of accounts, and can be

used by a business user.

Knowledge Requirements


eprentise Packaged

Software

Knowledge of Usage

of COA in All EBS

Tables

Developer must know ALL

the places in EBS where the

change needs to be

made. This varies by

version number (down to

the dot release – all are

different), the patch level,

which modules are installed,

whether it is a federal or

commercial customer,

Software has a list of tested

“rules” that are dynamically

applied as the environment

or mapping changes. This

changes all history, and

everywhere the CCID is used,

regardless of which EBS

version is used or whichever

modules are installed. After

using the software, it is as



etc. The number of places

is not small, varying from

many hundreds to

thousands of places to

change. Remember this is

Oracle – the columns

needing to be changed do

not all have names that

even suggest they contain

CCIDS, and columns with

names that include the

string CCID in the column

name are not all code

combinations for the

accounting flexfield!

though the new chart of

accounts was in existence

since the original

implementation. There is no

ongoing reconciliation

between the old values and

the new values. The process

for identifying what needs to

be changed has been

thoroughly tested, and the

results (and the integrity of

the data) are guaranteed.

Knowledge of

Related Data and

Completeness of

COA Change. There

are other areas that

map to the chart of

accounts (the HR

Cost Allocation

flexfield)

Developer must have

knowledge of all related

modules and

functionality. Developer

must know how to address

in the code the special

problems raised by the

presence of multiple

ledgers or sets of books

handled to ensure they are

all properly updated and

consistent.

FlexField software has built in

functionality to address all

subledgers and related

flexfields. Software has a

structured methodology for

handling secondary ledgers,

subledgers, and multiple sets

of books in a consistent

manner.

Generate the correct

post-COA

conversion balances,

including net debit

and credit amounts,

for every accounting

period in every

balance table.

Developer must know that

balances need to be

updated in every period,

including net debit and net

credit amounts. This is easy

if all mapping is 1:1, but is

very complicated as soon as

mapping is one-to-many or

many-to-one at the

segment or value level or

many-to-one at the code

combination level.

Developer must be able to

write code that does

FlexField software has

functionality to align balances

for every period in every

balance table. A user

generates standard Oracle

before and after reports and

uses reports generated by the

software to perform a one-

time, conversion

reconciliation. FlexField

identifies where multiple GL

code combinations map to a

single new one, and sum the

sources into the single target



precisely what is needed. balance.

Exception Reporting

and Compliance with

Standard Accounting

Methods and

Practices

Developer must have a

sufficient accounting

background to identify and

code exception reporting.

That exception reporting

must detail conflicts

between natural account

types, descriptions, end-

dates, and balancing

segments. These

exceptions are most

prevalent with many-to-one

mapping, and the validation

and conflict resolution is

even more complex when

mapping many charts of

accounts to a new or

existing chart of accounts.

FlexField has built-in

exception reporting that

doesn’t allow different

account types to be mapped

to a new natural account

value, doesn’t allow a

balancing segment to be

split, enforces a standard

definitions (even across

multiple charts of accounts)

and has built in logic to deal

with different end

dates. Complies with GAAP,

IFRS, and other accounting

standards.

Testing, Cutover, Auditing, and Post-Change Maintenance


eprentise Packaged

Software

Converting the COA

within the EBS

database in

production and non-

production

environments must

be operationally

robust.

Developer’s code should

include extensive error

handling for

processes. What happens if

there is not enough

tablespace, or the power

goes out? Is the system left

in a stable state and able to

be restarted to pick up

where it left off?

When FlexField software is

restarted, it picks up where it

left off. There are standard

queries to monitor the

processes and troubleshoot

any issues.

Minimum downtime

for production COA

conversions.Minimal

duration of non-

production

tests.Performance

Developer must be an

expert at optimization to

ensure acceptable cutover

times for large tables. Will

the scripts run fast enough

to handle high volume

FlexField software has been

tuned to handle large

volumes of data within a

reasonable cutover time.



architecture, parallel

processing, and

code

optimization. Ability

to extrapolate from

test environment to

the production

environment, so as

to predict and plan

for the conversion

downtime.

systems with billions of

code combinations?

Ability to audit the

COA change

Developer must code in a

fully compliant audit trail or

fully document the changes

made at a level of specificity

sufficient to meet auditing

standards.Developer’s code

must be unit tested to make

sure that everything is

mapped, (that all rows are

accounted for), and that the

logic is correct in updating

the mapped values. Even

after testing there remains a

risk if the test and

development environments

are not identical to the

production environment, in

regard to version, patch

level and all code

combinations in use.

FlexField software

automatically generates a full

audit trail that is in

compliance with all regulatory

requirements.

Ongoing support for

an extended period

after the production

COA

conversion. Access

to people who

understand what

was done, the code

that was used, the

customer’s

environment, and

It may be necessary to

research problems in an

R12 environment, long after

a COA change and upgrade

from 11i to R12.

Software has been tested

with customers who have

done an upgrade, added new

modules, and made other

changes in their EBS

environment. Services and

support are included in the

license price with no

additional fees in

perpetuity.The FlexField

software license includes



Oracle EBS. warranty terms.Software code

is standard and has been put

into production without any

defects at multiple customers.

Numerous references are

available upon request. The

product and the code are

mature. The client only needs

to test that the mapping is

what they want, not that the

code doesn’t violate the data

integrity of the EBS database.

The table delineates some but not all of the challenges of using custom scripts and software to change an

EBS accounting flexfield. When we consider all of the requirements, using custom scripts and code is

really no different than a development effort to create a software package to operate in a company’s

production environment. Potential problems include missed deadlines, budget overruns, overall quality

and defect control issues, and project failure. The technical change of the COA within EBS is part but not

all of an enterprise project to change the COA for accounting classifications and for financial and

operational reporting. The price differential between different software products and custom scripts and

software is likely a secondary decision factor. Commercial software, by creating economies of scale, puts

the costs that went into its research and development into a proven repeatable technology at a

reasonable price. Packaged software minimizes and controls risk; custom code and scripts invite

risk. Changing your chart of accounts is a critical undertaking. The risks of getting it wrong with custom

code are substantial, and the cost of recovering from errors is greater still.

Conclusion

Our conclusion is based on the observations in the table above, knowledge of consulting projects that

have reported changing the COA, and our experience with Oracle E-Business Suite customers. Most

decision makers will find that using commercial third party software to change the COA is a low risk

approach, but that one-off projects by in-house staff or external consultants is high risk. The risk of

custom solutions is not consistent with most Oracle E-Business Suite customers’ profiles given they prefer

commercial over custom software and eliminate customizations as fast as possible when Oracle provides

needed functionality “out of the box.” Using commercial software to fix COA problems enables decision

makers to fix a problem, lay a foundation for better reporting and decisions, eliminate uncertainty, and

continue to deploy Oracle to support their business.

eprentise’s FlexField product is the first, and still the only commercially-available software for changing

accounting flexfields in the Oracle EBS. With extensive research, experience with many different customers

and requirements, and twelve years experience developing this technology, eprentise provides a risk-free,

mature solution to change the Chart of Accounts in Oracle’s E-Business Suite.



Curious?

For more information, please call eprentise at 1.888.943.5363 or visit www.eprentise.com.

About eprentise

eprentise provides transformation software products that allow growing companies to make their Oracle® E-Business

Suite (EBS) systems agile enough to support changing business requirements, avoid a reimplementation and lower the

total cost of ownership of enterprise resource planning (ERP). While enabling real-time access to complete, consistent

and correct data across the enterprise, eprentise software is able to consolidate multiple production instances, change

existing configurations such as charts of accounts and calendars, and merge, split or move sets of books, operating

units, legal entities, business groups and inventory organizations.

Approaches for Changing the Chart of Accounts: Eliminating ... · PDF fileApproaches for...

Documents

Transcript of Approaches for Changing the Chart of Accounts: Eliminating ... · PDF fileApproaches for...