approaches for changing the chart of accounts: eliminating ... · pdf fileapproaches for...
TRANSCRIPT
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 | Page 2
© 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
Approaches for Changing the Chart of Accounts: Eliminating the Risks
Copyright © 2014 eprentise, LLC. All rights reserved. www.eprentise.com | Page 3
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.
Approaches for Changing the Chart of Accounts: Eliminating the Risks
Copyright © 2014 eprentise, LLC. All rights reserved. www.eprentise.com | Page 4
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
Approaches for Changing the Chart of Accounts: Eliminating the Risks
Copyright © 2014 eprentise, LLC. All rights reserved. www.eprentise.com | Page 5
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
Approaches for Changing the Chart of Accounts: Eliminating the Risks
Copyright © 2014 eprentise, LLC. All rights reserved. www.eprentise.com | Page 6
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
Requirement Custom Scripts
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
Approaches for Changing the Chart of Accounts: Eliminating the Risks
Copyright © 2014 eprentise, LLC. All rights reserved. www.eprentise.com | Page 7
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
Approaches for Changing the Chart of Accounts: Eliminating the Risks
Copyright © 2014 eprentise, LLC. All rights reserved. www.eprentise.com | Page 8
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
Requirement Custom Scripts
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.
Approaches for Changing the Chart of Accounts: Eliminating the Risks
Copyright © 2014 eprentise, LLC. All rights reserved. www.eprentise.com | Page 9
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
Approaches for Changing the Chart of Accounts: Eliminating the Risks
Copyright © 2014 eprentise, LLC. All rights reserved. www.eprentise.com | Page 10
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.
Approaches for Changing the Chart of Accounts: Eliminating the Risks
Copyright © 2014 eprentise, LLC. All rights reserved. www.eprentise.com | Page 11
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 the Risks
Copyright © 2014 eprentise, LLC. All rights reserved. www.eprentise.com | Page 12