Written by Helene Abrams Tuesday, February 10 2009
Last month, we wrote an article about putting numbers in boxes that presented the current chart of accounts and design considerations for a local/county government. This month, we are continuing that article with design considerations for a CoA for a high tech manufacturing company. We will refer to this company as HTM in this article. HTM has many of the same issues that the county government had, with segments representing multiple types of data and with different kinds of information within one segment. This chart is a little more complex because HTM is a global company with different statutory and regulatory requirements. Trying to get global consensus on a new chart around the world is also very difficult politically because everyone feels ownership of their current values and they want to continue doing things in the way that they are used to doing them.
The current accounting flexfield for HTM has nine segments.
Current COA Structure:
CO – company – 3 digitsBU – business unit – 4 digits
DEPT – department – 4 digits
ACCT – account – 4 digits
DETAIL –detail – 4 digits
INTERCO – intercompany – 3 digits
MGTCO – management company – 3 digits
PROJECT – project code – 8 digits
CHANNEL – channel – 2 digits
Current Situation: HTM performs extensive reorganizations every quarter to accommodate department changes. With department housed in the chart of accounts, these reorganizations include switching the costs for an individual or group of employees who is transferred to another department. The current chart limits the quality of analytic reporting, both within Oracle and with third-party reporting tools. Some segments are used for multiple data types, and the same data is used across multiple segments.
Designing a Solution
I. Design Guideline: Have one type of data in only one segment.
When the same data is represented in different segments, the values in each of those segments must be maintained. There is a possibility of inconsistencies between segments in descriptions, and errors can occur when the user enters a value in one segment and does not enter the corresponding value in the other segments. The only way to prevent these errors is by using lots of cross-validation rules between the segments having similar content. Having the same data in different segments also means duplicate data entry.
Example 1: CO - MGTCO - INTERCO are always the same, but they use different value sets. CO is used for balance sheet and P&L, MGTCO is used for reporting regions but does not always contain geographic data, and INTERCO is used for intercompany transactions.
MGTCO occasionally refers to the management company that pays for an employee rather than a region that the company would like to report on. For example, in Canada, 60% of the employees might be under MGTCO 555, but the remainder of employees might be under MGTCO 880, indicating that although they work in Canada, they are employed and paid for by another country.
Discussion: If three segments are necessary, CO - MGTCO – INTERCO should share a value set. However, it seems that the MGTCO that pays for an employee would be the cost center (so the payroll would have an allocation that allocates 60% of the cost to one cost center and the rest of the payroll to a different cost center). This example is also confusing because the location is mixed up in the MGTCO segment, but that will be discussed in the next design guideline.
Example 2: There is a legal company created for ABC but ABC also appears in the description for department values. Note too, that the description for these Departments also includes a building location.
DEPT Value Description
0123 ABC Quality Management Systems BU2200321 ABC Value of Production BU220
0432 ABC Engineering BU220
0423 ABC Manufacturing Bldg 12 BU220
0424 ABC Process Eng BU220
Discussion: A location description appears in both the DEPT segment and in the MGTCO description. As is noted later, location is also in the DETAIL segment.
Example 3: Cost center is defined as the concatenation of MGTCO - BUSUNT - DEPT (all in one: eg. 21115570157) for Hyperion reports, and the HR systems add the description in the cost center field. Every module that uses Cost Center had to be customized.
Discussion: HTM does not have a single segment for the cost center function. In order to track specific costs for activities or assets, a cost center segment is critical.
II. Design Guideline: Have only one type of data in a segment.
When multiple types of data appear in a single segment, there are two primary issues: the first is that both types of data might be required for reporting and the user can’t enter two separate values for one transaction. The second problem occurs when the values are not in a range within that segment, making it more difficult to do reports, summarize values, and create parent and child hierarchies, often causing the segment to run out of values for that segment.
Example 4: HTM used the DEPT segment in many different ways: as the HR organization to which an employee’s expenses are charged, as a job function, for real estate, for supplies purchased for a building, for location (as seen in the example 2 above), for local values, and by exception as a “department” as defined in common usage. Sales Engineers have the same department code across MCO’s. A manager uses the same department code as the staff because he is doing the same function. Available DEPT codes may run out in about a year since current practice confines the codes to being numeric, the codes are not reused, codes are allocated in pre-defined ranges, and each reorganization requires 500-2000 new department codes.
Discussion: If HTM wanted to do analysis on revenue by location, they would have to select individual departments from a list of over 9,000 departments to see which DEPT values included location. Similarly, it is difficult to track supplies purchased for performing a job function in a building since both supplies for a building and job function are contained within the DEPT segment. Reports driven from such dispersed data are easily corrupted and don’t confer accurate financial information to management.
III. Design Guideline: Use subledgers (HR and Project Accounting) to store data for people, departments, and projects rather than storing those transactions in the General Ledger.
The General Ledger is supposed to serve as a repository for the aggregated transaction data stored within each of the subledgers. From the General Ledger, it is possible to drill down into the detail of the subledgers. The subledgers are designed to carry out detailed transactions and have the supporting financial data represented by posting to the general ledger. For example, the HR subledger is designed to accommodate job and assignment changes, costing for different types of HR activity, benefits, and job functions. It is relatively straightforward within HR to reorganize reporting structures, to move people between departments, and to allocate their costs to a different entity.
Example 5: HTM is using the accounting flexfield as a substitute for operations normally performed and recorded in Oracle’s HR module, requiring that costs associated with individuals be moved whenever the individuals change departments. Quarterly reorganizations such as moving to another business unit, closing a department, or changing a department description are commonplace in the organization. Due to the loose interpretation of Department, reorganizations are recorded in the accounting flexfield, requiring an inefficient manual effort of about 500 person-hours each quarter to change the departmental costs as people are shifted to different job functions.
Discussion: HTM should carry out the employee transfer processes within the various HR functions and use the conventional notion of a work group rather than in the Chart of Accounts.
Discussion of other segments:
- CHANNEL is not used.
- PROJECT is the same information used in project accounting, but included in the accounting flexfield because HTM feels that it is too difficult to make adjustments and get reporting within the Project Accounting Module.
- DETAIL contains location information.
- BU is a rollup of DEPT values and may not be needed.
- The ACCT segment is not large enough to allow clean ranges for categories of accounts.
Recommended Chart of Accounts
The following structure will allow HTM to track their financials in different ways and have consistency and room for growth. The segment lengths are estimates, but should be based on the level of detail required and the extent to which the values in that segment will grow. Rollup groups should be established within each segment to allow summary reporting based on the range of child values. Just as it is common for the natural account segment to have a range of values for travel expense accounts or taxes, it is appropriate that each segment be broken up into categories of data that can be rolled up to a broader category of information. Locations at the lowest level of detail might include a room in a building, and at the highest level, it might be a continent. All of these are locations and would allow tracking at whatever level of detail HTM needed. The Cost Center segment would contain the detail to track specific costs and revenues. The Company and InterCompany segments should share a single value set so that maintenance is minimal and when a new company is added, it is consistent between the two segments. The Line of Business segment would include the different business lines of HTM such as Server Products, Small Business Products, Display Products, etc.
| < Prev | Next > |
|---|
Related Articles
Related Pages
Enter your email address to sign up for our Newsletter
January Puzzle
A traveler gets lost on a deserted island and finds himself surrounded by a group of n cannibals.
Each cannibal wants to eat the traveler but, as each knows, there is a risk. A cannibal that attacks and eats the traveler would become tired and defenseless. After he eats, he would become an easy target for another cannibal (who would also become tired and defenseless after eating).
The cannibals are all hungry, but they cannot trust each other to cooperate. The cannibals happen to be well versed in game theory, so they will think before making a move.
Does the nearest cannibal, or any cannibal in the group, devour the lost traveler?
Solution
The short answer is the traveler’s fate depends on the parity of the group. If there is an odd number of canibals, the traveler will be eaten, but if there is an even number, the traveler will survive.
To prove this, we will consider small groups and use mathematical induction to explain the solution for larger groups.
Case n = 1: this is an obvious case. If there is one cannibal, the traveler will be eaten. It doesn’t matter that the cannibal will get tired because there are no other cannibals around as a threat.
Case n = 2: this is a more interesting case. Each cannibal wishes to each the traveler, but each knows he cannot. If either cannibal eats the traveler, then he will become defenseless and the other one will eat him. So each cannibal uses backwards induction to realize that the only strategy is to not eat the traveler. The hapless traveler finds a bit of luck, therefore, and actually survives.
Case n = 3: this is where the problem gets interesting. The best strategy is for the closest cannibal to make a move and eat the traveler. The cannibal will be defenseless after eating, but ultimately he will be safe. Why is that? The reasoning is due to induction: once the cannibal eats the traveler, the resulting situation has 2 unfed cannibals and the 1 defenseless cannibal. But as we just showed above, when there are 2 unfed cannibals, neither will make a move for fear of being eaten by the other! Thus the first cannibal to make a move will be safe as the remaining 2 cannibals block each other.
We can prove the higher cases using mathematical induction. If the number n is odd, then the closest cannibal can safely eat the traveler because the remaining number of unfed cannibals is even (and by induction, with an even number of unfed cannibals no one makes a move). If the number n is even, then no cannibal will eat the traveler, for if he did, the remaining number of cannibals would be odd, meaning he will get eaten by the induction hypothesis.
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."
