Recent Posts


How to Address EBS Hierarchy Changes When They Break Your Oracle EPM (Hyperion) Environment in Pre- Versions
Posted on May 22, 2014
Author: Shane Hetzel, Performance Architects

For versions of Oracle EPM and earlier, Oracle ERP Integrator (or ERPi, now part of Oracle Hyperion Financial Data Quality Management Enterprise Edition or FDMEE in Version and Oracle Hyperion Enterprise Performance Management Architect (EPMA) had problems properly handling changes to an E-Business Suite (EBS) hierarchy.

For example, when members are moved to a different parent in EBS, EPMA creates a new primary instance of the member at the new location in the hierarchy. However, the originally placed member is also retained, but is switched to a shared member. The reason this happens is that, by default, ERPi imports metadata using the “Merge as Primary” process type, which will not delete or move existing members, but rather switch them to ‘shared’ while creating a new primary instance of a member based on the current location in the EBS hierarchy. This behavior is especially problematic because this will lead to double-counting, and application deployments from EPMA often fail in cases where the member was moved lower in the hierarchy. This causes an error where a shared member is encountered before the primary instance.

In the image below, member A50300 was originally a child of parent A501AM. After an EBS hierarchy change, the member is now a child of parent A501AP; however ERPi and EPMA failed to remove the member from the original parent, and instead made it a shared member. A deployment attempt with the hierarchy in this state would fail because the shared member will be encountered before the primary member.

This behavior is a known bug in Oracle that was not fixed until Version in ERPi’s replacement product, Financial Data Quality Management Enterprise Edition (FDMEE). In versions prior to, Hyperion administrators must be fully aware of any and all EBS hierarchy changes so they can monitor for this behavior. When an administrator identifies the problem, they must manually delete the shared member prior to deploying the application. This known bug necessitates a very strong business process to be in place so admins are made fully aware of all EBS hierarchy changes.

As of EPM Version, FDMEE now provides the option of choosing how hierarchy changes will be handled by EPMA. There is now an option to choose “Merge as Move,” which would likely be the most typical and preferable way for handling EBS hierarchy changes. The originally placed member is actually moved from its original parent, and placed under the new parent, leaving only a single primary instance of the member in EPMA. Administrators will need to be cognizant of the version of EPM they are on, and ensure the proper business processes are in place to handle the inherent limitations of the product.

Author: Shane Hetzel, Performance Architects


© 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.

Leave a Reply

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