How to address EBS Hierarchy change when they break in pre EPM 11.1.2.3 versions


For versions of Oracle EPM 11.1.2.2 and earlier, Oracle ERP Integrator (or ERPi, now part of Oracle Hyperion Financial Data Quality Management Enterprise Edition or FDMEE in Version 11.1.2.3) 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.

KKT-ERP-7

This behavior is a known bug in Oracle that was not fixed until Version 11.1.2.3 in ERPi’s replacement product, Financial Data Quality Management Enterprise Edition (FDMEE). In versions prior to 11.1.2.3, 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 11.1.2.3, 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.

Thanks,
~KKT~

 

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s