Monthly Archives: December 2015

The Importance of a Well-Designed, Stable, and Flexible Chart of Accounts (COA)

December 30, 2015

Author: Sree Kumar, Performance Architects

A stable and flexible Chart of Accounts (COA) is essential to a company, not only to track transactions, but also to help the organization plan and grow. Therefore, it is important to have a fairly stable COA from both a tactical and strategic angle. In this blog, I highlight some of the benefits, risks and options to consider for organizations to successfully manage their COA, thereby minimizing any adverse impacts.

A common misconception with a COA is that a stable COA means sticking to the status quo with a static COA structure. This is certainly not true. Even in the cases when you have an enterprise resource planning (ERP) and/or budgeting and planning system already in place, there are several situations when a COA overhaul might be the need of the hour.

However, in the cases when you have an established budgeting and planning system, the impact of a COA redesign could be greater, and risks are higher, as compared to the case when you are implementing a new budgeting and planning system altogether. With an existing system in place, some of the areas of impact and risk from a COA change or redesign are as follows:

  • Change metadata and associated hierarchies for the updated COA
  • Modify other associated dimensions
  • Remap historical data from the old COA to the new COA
  • Update all reporting, budgeting and planning processes and modules
  • Update all budgeting and planning processes and steps to accommodate the new COA

As you may be already aware, there is a significant amount of risk associated with the changes mentioned above, amplified as a result of redesigning your COA. Having outlined some of the risks, let’s now look into the backdrop of some of the situations that lead to a COA redesign.

One of the primary reasons for the mismanagement of a COA is the diverse reporting needs of an organization. Instead of expanding the use of a range of dimensions, most organizations choose to expand on the COA to arrive at meaningful reports. Segmenting of data in this fashion is based on the presumption that it keeps things simple and avoids complexity. In most cases however, it is anything but simple as you end up with an unmanageable COA. The original design and intent is lost in this need for diverse reporting.

Reporting for a COA should be flexible enough to allow end users to drill down to the level of granularity desired or to summarize information at a higher level. You also need to consider the use of other dimensions (like location, department, cost center, project, etc.) that will allow you to slice and dice the data as desired without expanding the COA to unmanageable levels. Remember that if you do not factor in all the dimensionality and instead have a narrower focus, you will end up with an unmanageable COA or an unmanageable budgeting and planning process.

Let’s now talk a little bit about the impact of technology. The reality about systems and technology in today’s world is that they sometimes cloud (not to be confused with the cloud we all are gravitating towards) design considerations involved with a COA discussion. Most reporting, planning and budgeting systems (cloud or onsite) are robust enough to handle a wide range of dimensions and a robust COA.

Some organizations and integration partners, however, start with designing a COA based on system limitations and technology considerations. This is where they fail. A COA should be based primarily on the way your organization runs your business, not based on whether it is a good fit from a systems or technology perspective.

A well-designed COA will not only allow an organization to view “one version of the data” but also will stand the test of time as your business evolves. Different departments will not have a need to massage the data in a form that conforms to their reporting requirements. Each individual department can then budget and report at the levels that match the way the business is run for that specific department, as well as slice and dice data across other hierarchies or dimensions needed from a more holistic perspective as well.

As you can see, a stable COA has a profound impact on an entire organization. A stable COA should not be static, but instead should be robust, flexible, and designed to adapt to the changing nature of your business. It’s not just the finance and accounting departments that depend on a stable and flexible COA, but also strategy, sales, marketing, legal, technology and other departments in your business. It also helps align the entire organization towards one common goal and one version of the data. And remember this, “When a General Ledger (GL) ends up being a “specific ledger,” it’s most likely a time to overhaul your COA.”


© Performance Architects, Inc. and Performance Architects Blog, 2006 - present. Unauthorized use and/or duplication of this material without express and written permission from this blog's author and/or owner is strictly prohibited. Excerpts and links may be used, provided that full and clear credit is given to Performance Architects, Inc. and Performance Architects Blog with appropriate and specific direction to the original content.

Oracle Business Intelligence 12c: “Hide Object If” Solution to Permissions Issue

December 16, 2015

Author: Thomas Dodds, Performance Architects

Running into a snag where permissions in Oracle Business Intelligence 12c (formerly known as Oracle Enterprise Edition or OBIEE) BI Roles were such that the use of the “Permissions” feature to restrict access to a particular presentation layer object is ineffective?

Use the “Hide object if” capability to solve the issue.

  1. Create an AD group that users can be assigned to; either in WebLogic (defaultAuthenticator) or in the system that the AD_Authenticator points to in WebLogic.Consult Oracle’s Product Documentation for specific steps: http://www.oracle.com/technetwork/middleware/bi-enterprise-edition/documentation/bi-ee-087853.html
  2. In “Enterprise Manager,” create an “Application Role;” in this example ‘ALLOW_RESTRICTED_OBJECT’ and member the AD group to this role.Consult Oracle’s Product Documentation for specific steps: http://www.oracle.com/technetwork/middleware/bi-enterprise-edition/documentation/bi-ee-087853.html
  3. Create a “Session Variable Initialization Block”The SQL statement is reading the list of the user’s BI Roles and is leveraging Oracle DUAL table and INSTR() Function. Highlighted in BLUE below.The INSTR() function will return an integer value representing the character location where a substring is found in the search string. IE: INSTR(‘Hello World!’,’World’,1,1) returns 7.

    Wrap this INSTR() function in a case statement to return ‘SHOW’ if the integer returned is greater than zero (the text was found) or return ‘HIDE.’

    Also create a Session Variable to hold the returned value; in this example ‘SHOW_HIDE_OBJECT’ and default its initialized value to ‘HIDE’. Highlighted in RED below.

    TD1

Test the Initialization block. Note, the block will return the list of values for the user you are logged in to the RPD with.

  1. In the Presentation Layer, double-click object that you want to conditionally show or hide to open it. On the general tab, locate the ‘Hide object if’ property and click the expression editor icon. Highlighted in RED below.In the expression editor window, enter the formula to evaluate your variable value to a Boolean TRUE/FALSE. Highlighted in BLUE below.VALUEOF(NQ_SESSION.SHOW_HIDE_OBJECT) = ‘HIDE’

    The property is designed to hide the object if the Boolean evaluation is TRUE.

    TD2

  1. Test it out!

This property is available for both presentation columns and tables. If applied to a table, sub-tables and columns will also be affected. If you have any questions about what was discussed in this post, please email us at info@performancearchitects.com.


© Performance Architects, Inc. and Performance Architects Blog, 2006 - present. Unauthorized use and/or duplication of this material without express and written permission from this blog's author and/or owner is strictly prohibited. Excerpts and links may be used, provided that full and clear credit is given to Performance Architects, Inc. and Performance Architects Blog with appropriate and specific direction to the original content.