How to Get Your Data into the Correct Intersection

Mike Arnoldy

By
June 15th, 2011


As companies migrate from Enterprise to Financial Management, they face some new challenges with regard to data integrity. Financial Management, with its account and custom dimensions, creates millions of valid intersections—how many of you really want product detail for your cash accounts? Ensuring that data goes into the correct intersection out of all of these possibilities requires a mixture of design, security, education, and ultimately, trust.

From a design perspective, each account has an attribute that allows the valid top member of each custom dimension to be designated. A parent member in the custom dimension is designated to be the valid top member for that dimension, and all members below that parent are valid with that account. An example would be setting the product dimension detail to only be valid for revenue accounts. This is easy to implement, but it may not be as granular as some companies would like. I generally find this is a good initial step to define ‘valid intersection.’ Another aspect of design would be to include audit reports in your application. These reports look at intersections that really should not have data and are used to identify incorrect entries. Reviewing these reports is then included as a step in the close process.

A second option is to use security. First, security should be set so that users cannot enter data into a data grid. With this secured, data forms can be used to direct exactly where users can input data. The forms are built with the correct combinations of accounts and the custom dimensions to help ensure the data goes to the correct intersections. I have also seen applications where security classes are applied to provide some restrictions on what member of a custom dimension is used. This is typically done on a custom dimension that gives visibility to where data originates such as the G/L load, manual input or a journal adjustment. Using the security classes can be tricky and provides limited results.

Another option is to use the No Input rules. The No Input rules allow specific intersections of the dimensions to be defined as no input or invalid. An example might be that <Entity Curr Adjs> is not valid with the G/L load and manual input members of a custom dimension. No Input rules can also be developed referencing the user defined fields on dimension members. No Input rules allow for a very granular level of restriction to be developed. A word of caution though: I have seen very detailed No Input rules developed, and the corresponding rules file took over 15 minutes to load. Likewise, after a server reboot, the first user login took over 15 minutes. This is because the No Input intersections are loaded into memory when the rules are loaded or the application is started on the server, so there are some performance considerations. I have also seen clients using extensive No Input rules have to load a blank rules file to be able to turn off the rules so they can perform maintenance or restatements of prior periods. I generally use No Input rules sparingly, if at all.

The last option is a combination of education and trust. Users should be properly trained on the application. This includes how the accounts and custom dimensions are related and what the valid combinations are. There should be a detailed review of each dimension, the different members and what those members represent. When I have conducted end-user training, throughout the class, I ask questions about what custom members are valid with what accounts. By the end of the training, everyone knows the answers. And finally, let’s not forget that the users are generally well educated accountants that we trust to prepare our financial statements. You should not have to build an application that prevents every possible error they might make. You have to trust these users to do their job.

###

Please feel free to publish the above blog in full or in part with attribution according to the Creative Common license, or link to http://bit.ly/jdQwg7.

 

Tags: Enterprise Performance Management, EPM, HFM, Hyperion Enterprise, Hyperion Financial Management, Oracle Hyperion, Oracle Hyperion 11.1.2.1, TopDown Consulting

 


Mike Arnoldy

About Mike Arnoldy

Mike Arnoldy has over 20 years experience in all phases of design, development, and implementation of financial applications. He has exceptional problem-solving and architecting skills with a strong technical background. He specializes in financial consolidation applications that include complex calculations, foreign currency translation, inter-company/equity eliminations and varied reporting requirements to satisfy both external and management reporting needs. Mike is also a Certified Public Accountant.

Leave a Reply

Your email address will not be published. Required fields are marked *