1. What is a chart of accounts (COA)?
Chart of Accounts is a key tool in capturing your transactional accounting information to be able to report in a manner that supports and benefits the organization's various requirements like consolidation, planning, and reporting.
The chart of accounts contains all the accounts used by a business. It defines how and what account titles to use in recording the transactions. Account titles may depend upon the lien of business, the type of ownership, preferences, and other factors.
2. Explain about the structure and representation of COA?
It is a combination of multiple fields that defines the complete transaction details. Each field we call it a segment in Oracle. So, Multiple segments put together is your chart of accounts.
Effectiveness of the current business process and future depends on how you chose the number of segments, length, names, and order.
COA Structure: Company-CostCenter-Account-SubAccount-Product-Future
Eg: 101-2020-401010-1210-13210-0000
Segment1 is a company/ legal entity, mostly, it will be the balancing segment
Segment3 is a natural account like Sales, Cost, Cash, and Asset.
Segment6 is for the future. It means you have a need for 5 segments now. Still, you are adding one extra that may need in the future for the effective classification of transactions.
3. I have a group company that has multiple companies and multiple lines of business. To add, more to the complexity, we use multiple accounting systems with multiple COAs ranging from bad to okay. If I offer a project to implement EPM & BI, how do you develop the reporting COA?
I wish I can explain this better in a pictorial representation. I am. I did.
4. This looks to be a complicated process. is there a way to simplify this?
5. After the implementation of Reporting COA, are we ready with all EPM Dimensions?
Mostly yes. Still, we need to make them ready for EPM based on the EPM Design.
Once your Reporting COA/ Master Data is ready from the Organisation side. is it enough for EPM? definitely not. It is sure, by now, you have Metadata - Sets and Attributes, anything that is meaningful at the organization level and at finer detail. what exactly, we need for EPM depends on the below.
Processes are at a high level like - Financial Planning, Consolidation and Reporting
Sub processes are the blocks that make up the process. In Planning, we call them models. Below are the few.
Profit and Loss Model
Balance Sheet Model
Cash Flow Model
WorkForce Model
Capex Model
Feasibility Model
Grain/ Granularity is the lowest level of detail. Defined at process and mapped to the cube/Plan Type based on the processes that sit in the respective Plan Type.
Plan Type is technically a vessel that contains one or multiple processes/ Models.
Your dimensions are relevant to the process, not to the Plan Type. If a Plan Type contains multiple process dimensional irrelevance arises.
for e.g. Profit and Loss Model, Balance Sheet Model and Cash Flow Model are part of "Finance" Plan Type. Product dimension is must in Profit and Loss Model to derive the Product level profitability, where as not required in the other two.
Thus, Product dimension is relevant in P&L and not in other. Here, you should maintain this dimension in the other two also and associate with a default member AKA, "All Products" or "No Product".
Let's come back to the "Grain"; Say Product dimension detail is as below from Top to Bottom
Product Total -> Product Line->Product ID->SKU. Here, SKU is the grain of the product master in the organisation. In the EPM, we may define "Product ID" as the leaf. Likewise, combination of leaf level from all dimensions is the grain of the Plan Type. This is the input/ load level, and similar to segment string in ERP.
First, let me explain what the Facts mean. Facts are measures in Analytical Models - like
"No. of Deals"
"Value of Deals in $"
"No. of unsuccessful deals"
"Value of Lost Deals in $"
These are generally BI Models. Key is to go as detail as available to you.
But, In Financial models, Facts are Accounts used to prepare Financial Statements - like revenue, expense, Asset, Liability etc.Here, in this case, facts are Lev0 members of the Account dimension in EPM.
is there a standard to identify this level? Yes, we have techniques not standards.
It's driven by the requirements a.k.a Business determines the solution, but not otherwise.
We must consider the below factors, when doing the P&L Hierarchy
1. Actual entry point in ERP or any Accounting Information Systems.
2. Budget entry point in Planning Solutions - existing and new
3. Reporting Levels - Summary and Detail
4. Face of the P&L and Notes
When It comes to Balance Sheet and Cash Flow, I consider the Face of the Financial Statements and a place to capture the movements. I consider sub-models with the assumption accounts to arrive at a specific element as needed. Say - Fixed Asset Block for PPE and Depreciation.
***********************
Ohh. Dad! I have finished the first part...
Am I really done? Yes for the first part with in the Conceptual and Logical layer. Anything, I write more, sure to overstep into Physical layer.
Is it as beautiful as I wanted to? Mind is an amazing thing. I am not an artist to paint all thoughts beautiful. I am Tech, Just a Tech!
I will try to be a better in the second part. And, and, what a feeling it is, to finish a work on Sunday before the lights on.
***********************
I wish I can explain this better in a pictorial representation. I am. I did.
4. This looks to be a complicated process. is there a way to simplify this?
Yes and No. Reporting COA Implementation is a logical solution. And, it is an upstream requirement created by the EPM & BI implementation. It is the basis for EPM & BI. You can't quit or go away from it.
But, if we take it up as a separate project, a Master Data project, we can simplify the EPM & BI implementation. And, at the same time, you can build a single source of truth across the organization, systems, and processes.
Oracle has a solution for this, called DRM - Data Relationship Management, running on Oracle Database and IIS.
But, if we take it up as a separate project, a Master Data project, we can simplify the EPM & BI implementation. And, at the same time, you can build a single source of truth across the organization, systems, and processes.
Oracle has a solution for this, called DRM - Data Relationship Management, running on Oracle Database and IIS.
5. After the implementation of Reporting COA, are we ready with all EPM Dimensions?
Mostly yes. Still, we need to make them ready for EPM based on the EPM Design.
6. For an EPM Project, Can you explain what's the road next after Reporting COA?
Once your Reporting COA/ Master Data is ready from the Organisation side. is it enough for EPM? definitely not. It is sure, by now, you have Metadata - Sets and Attributes, anything that is meaningful at the organization level and at finer detail. what exactly, we need for EPM depends on the below.
- Identify the Process and Sub-process
- Identify the grain
- Identify the dimensions
- Identify the facts
- Verify the model
7. What do you mean by Process and Sub process?
Sub processes are the blocks that make up the process. In Planning, we call them models. Below are the few.
Profit and Loss Model
Balance Sheet Model
Cash Flow Model
WorkForce Model
Capex Model
Feasibility Model
8. What do you mean by grain and how to identify?
Plan Type is technically a vessel that contains one or multiple processes/ Models.
Your dimensions are relevant to the process, not to the Plan Type. If a Plan Type contains multiple process dimensional irrelevance arises.
for e.g. Profit and Loss Model, Balance Sheet Model and Cash Flow Model are part of "Finance" Plan Type. Product dimension is must in Profit and Loss Model to derive the Product level profitability, where as not required in the other two.
Thus, Product dimension is relevant in P&L and not in other. Here, you should maintain this dimension in the other two also and associate with a default member AKA, "All Products" or "No Product".
Let's come back to the "Grain"; Say Product dimension detail is as below from Top to Bottom
Product Total -> Product Line->Product ID->SKU. Here, SKU is the grain of the product master in the organisation. In the EPM, we may define "Product ID" as the leaf. Likewise, combination of leaf level from all dimensions is the grain of the Plan Type. This is the input/ load level, and similar to segment string in ERP.
9. How do you identify the facts?
"No. of Deals"
"Value of Deals in $"
"No. of unsuccessful deals"
"Value of Lost Deals in $"
These are generally BI Models. Key is to go as detail as available to you.
But, In Financial models, Facts are Accounts used to prepare Financial Statements - like revenue, expense, Asset, Liability etc.Here, in this case, facts are Lev0 members of the Account dimension in EPM.
is there a standard to identify this level? Yes, we have techniques not standards.
It's driven by the requirements a.k.a Business determines the solution, but not otherwise.
We must consider the below factors, when doing the P&L Hierarchy
1. Actual entry point in ERP or any Accounting Information Systems.
2. Budget entry point in Planning Solutions - existing and new
3. Reporting Levels - Summary and Detail
4. Face of the P&L and Notes
When It comes to Balance Sheet and Cash Flow, I consider the Face of the Financial Statements and a place to capture the movements. I consider sub-models with the assumption accounts to arrive at a specific element as needed. Say - Fixed Asset Block for PPE and Depreciation.
***********************
Ohh. Dad! I have finished the first part...
Am I really done? Yes for the first part with in the Conceptual and Logical layer. Anything, I write more, sure to overstep into Physical layer.
Is it as beautiful as I wanted to? Mind is an amazing thing. I am not an artist to paint all thoughts beautiful. I am Tech, Just a Tech!
I will try to be a better in the second part. And, and, what a feeling it is, to finish a work on Sunday before the lights on.
***********************
