Agility by Design - eprentise Blog

Approaches for Changing the Chart of Accounts: Eliminating the Risks

PDFPrintE-mail

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.

Read more: Approaches for Changing the Chart of Accounts: Eliminating the Risks

 

Into the Future (And Back Again)

PDFPrintE-mail

Designing an accounting flexfield is one of the most difficult processes in an Oracle implementation. A “good” chart of accounts has the following criteria:

  1. The segments support important aspects of the business.
  2. You are able to report on critical business components with standard reports without resorting to spreadsheets.
  3. There is enough room to expand within each segment.
  4. FSGs and other reports are easy to create.
  5. Summary accounts and rollup groups fall naturally within ranges.

    Read more: Into the Future (And Back Again)

   

Flexfield Differences Between Releases 11i and 12

PDFPrintE-mail

Most of the changes to flexfields in Oracle Apps occurred between Version 10.7 and 11i. These changes included the addition of several APIs for the flexfields and the change of the name FlexBuilder to the Account Generator.

The most significant change is the ability in Release 12 to synchronize the context field value with the reference field value for descriptive flexfields. The example given in the documentation is that generating an expense report would refer to the context field for a country code and that would remain constant and specific to the user. If payment processing is done in another country, the context would not be derived from the payment processor’s country, but by the user who generated the original expense report. However, if the payment processor enters his/her own expense report, then the expense report would be synchronized to the country in which the payment processor resides. If the context field is not synchronized, the context information defaults at the time the record is created, even if the reference field value subsequently change.

The Release 12 documentation corrects an error from the Release 11 documentation in the key flexfield names. The Release 12 Flexfields Guide correctly refers to the code for the key flexfield for Sales Orders as MKTS and the Owning Application as Oracle Inventory and the code for the Sales Tax Location Flexfield as RLOC, and the owning application as Oracle Receivables. The other changes between Releases 11i and 12 are relatively minor. The documentation for Release 12 has been updated with some formatting changes, changes in referenced document names, and an update of some of the years from 2002 to 2007. Most noticeably, all references to prior versions and upgrades from prior versions have been omitted in the Release 12 documentation.

   

Email Newsletter icon, E-mail Newsletter icon, Email List icon, E-mail List icon Enter your email address to sign up for our Newsletter

Sign up now

captcha
TEChanges - Agility by Design

May Puzzle

David is often referred to as Rainman due to his peculiar ability to effortlessly figure out a certain date's day of the week. He recently displayed this talent when I asked him if there was a conflict with the upcoming Fuzzy Dice Conference and our weekly court-ordered community service. He asked the date of the convention. It was April 20th, 2012.

"Oh, that’s a Friday," he said, effortlessly. "And your sentences have you committed for the next few dozen Wednesdays so you'll be able to go." And of course he was right.

One day a few weeks ago I asked out loud in the office about the date June 5th. And of all people, my brother Tommy piped up and said "Oh, that's a Tuesday."

"That's right," said David.

Well how about Otcober 3rd?

"That's a Wednesday," said Tommy. Then I asked about Christmas Day 2012.

"Oh, that's a Tuesday." David nodded in agreement.

Do we now have two rainmen? Or had Tommy figured something out?

Show solution...

Solution

Here's what was going on. Tommy was using something called anchor dates. And these dates apply to each and every year. April 4th, or 4/4 we’ll call it from now on, June 6th or 6/6, 8/8, 10/10, 12/12, are all the same day of the week, each and every year.

So too are 5/9 and 9/5, May 9th and September 5th. So too are 7/11 and 11/7, and all the above dates are the same day of the week, as is the last day in February, Leap Year or not. And they’re all the same day as January 4th, it would otherwise be January 3rd, but this was a leap year, and that’s changes the anchor day from January 3rd to January 4th.

Tommy also knew that New Year's Day was a Sunday. He was sobered up by then. And he knew it was a Sunday because Christmas was a Sunday in 2011, so New Year's Day is a Sunday, so the Anchor Day for 2012, January 4th, has to be a Wednesday!

So if that's a Wednesday, then 4/4, 6/6, 8/8, 10/10, 12/12, 5/9, 9/5, 7/11, 11/7, and February 29th are all the same day of the week, and they're all Wednesdays. So when I ask for example, about October 3rd, he knew October 10th was a Wednesday, 10/10. So 10/3 must also be a Wednesday. 12/12 is a Wednesday in 2012, so it’s 12/26, which is two weeks later. So 12/25, or Christmas Day, must be a Tuesday.

Success Tips for Oracle Project Management

  • Create a standard for documentation at the beginning of your project, and hold team members accountable for completing documentation requirements as well as keeping them at and above the standards required.
  • Before promulgating user documentation or training, it’s also a good idea to choose a representative from the among the business users base to review materials first.
  • If you are not sure about the resources and budget required, obtain several estimates from people that have experience with the same size and scope of your project.
  • Be explicit, before beginning the project, what internal resources are required for execution. This includes people, infrastructure, hardware, and software.
  • Help the project champion understand the impact your project will have on the organization and how its successful completion will make him or her an internal hero or heroine for supporting it.
  • Break up your project into smaller projects (try for projects that can be completed in 4-6 months, especially early on) to get success and demonstrate momentum.
  • Make sure that your testing includes reports, upstream and downstream interfaces, customizations, enhancements, and workflows.
  • Ensure that comprehensive transition reports and meetings between departing and incoming personnel are completed.
  • Instead of spending time and resources implementing third-party reporting, consider consolidating multiple instances, moving to a global chart of accounts (CoA), and/or standardizing on a consistent calendar.
  • Include governance, risk, and compliance management as part of the project plan.
  • Finally, celebrate the successes. Too many projects focus on defects, failures, or small cost over-runs without looking at the big picture and what was accomplished.

The Analyst Corner

John Van Decker, Research VP of Gartner, states:

"A single chart of accounts allows consistency in financial reporting across the enterprise by standardizing on common metrics and reporting structures, reduces dependencies on a separate financial consolidation system, and significantly reduces the costs incurred with ongoing, complex conversions and translations."