A quick one this week we just thought we should share a small Oracle Hyperion DRM (Data Relationship Manager) feature that can be helpful and most importantly save time and raise your productivity.
Whenever you are working within a tab, you can right-click on the tab bar and see the different sections of the Home menu. This allows you to navigate directly from one module of Oracle Hyperion DRM to another, rather than having to click on Home then the name of the module you want. In the long run, this sav
es not just time but also frustration…
With the team having returned from a well-earned break, we thought it was time to share another success case with you. The client is ICAP, a leading markets operator and provider of post trade risk and information services. With a local footprint in 32 countries, more than 70 locations worldwide and an average daily transaction volume of US$1.3 trillion, ICAP can truly be considered a global company.
ICAP recognised that they needed a strategic approach to masterdata to underpin a comprehensive Financial Transformation Programme. They looked to us to “improve ICAP’s approach to masterdata governance, help improve the end-to-end visibility of data and help improve our ability to automate interfaces.”
We are glad to announce that ICAP have realised the benefits of a strategic approach to masterdata and this is evidenced by the following case study – ICAP Case Study.pdf.
If you would like to find out more about what we did and how we did it, then please do not hesitate to get in contact.
We just stumbled upon an interesting change in the latest version (22.214.171.124) of Oracle Hyperion Data Relationship Manager (DRM). For performance reasons,
Oracle has decided to limit the number of tables Oracle Hyperion DRM can detect when you define an external connection to 2000.
This is usually not a problem. However, if you follow the DRM Oracle General Ledger Integration Guide you’ll see that you ‘must’ use the APPS schema to integrate DRM to E-Business Suite (EBS). This schema usually has more than 2000 tables associated. This means there is a risk that the two target tables used by DRM (GL_DRM_SEGVALUES_INTERFACE and GL_DRM_HIERARCHY_INTERFACE) will be missing from the list of tables for the external connection.
Despite what the integration guide says, however, you can in fact define a different database user with write access to just these two tables and gain access to them that way.
Note that Oracle has logged an enhancement request to remove this restriction, so future releases may not come with this limitation. We experienced this with DRM 126.96.36.199.303.
We hope this is useful.
If you ever need to clear all values of a defined property within a hierarchy (prior to blending in a completely fresh set of property values, say), it can be done in a few brief steps.
Firstly select the top node of the hierarchy and choose the tab the property is on. If the top node does not normally show this property, you will have to select Show All Properties on the property viewer. Only administrators can do this but then again, only administrators should be doing this.
Next, right-click on the property label and choose Clear All Below, followed by Save. This removes all explicitly defined values from each node below the selected node. (This is a useful little option in itself.)
Finally, right-click on the property label and choose Remove Value, then Save. This removes the property value from the top node.
There are action script equivalents of these two commands, so if you have a whole set of properties to clear an action script is probably the way to go:
Estimating the cost of an Oracle Hyperion Data Relationship Manager (DRM) implementation can be difficult. This blog will highlight the areas and risks you should consider.
When developing the business case for the costs can broadly be separated into 3 distinct areas:
- Software and licensing costs;
- Hardware costs; and
- Implementation costs.
The first of these can be difficult to understand as you need to have some indication of how many nodes will be required for you solution. This information is not often available until after implementation as the agreed design will affect the number of nodes required.
The second, hardware costs, can be identified relatively easily using the software vendor’s prior experience.
The main issue comes with estimating implementation costs. At the point at which the decision is being taken to purchase the relevant software, it is unlikely that you have expertise already on the site. You therefore have a few options available. In some instances we have seen organisations ask for an estimate from the software vendor. This can be a huge mistake for two reasons. The software provider is unlikely to have a detailed understanding of your requirements and in addition they are conflicted as they are trying to sell you the software. They have a vested interested in trying to minimise the estimate to ensure you buy the software.
Alternatively, you may be tempted to use a formula to try and determine the final implementation costs. This approach is fine as long as the formula used is not arbitrary, and is based on a good understanding of both the requirements and the technology.
In our opinion, the best method of understanding the implementation costs is to approach an independent organisation that has demonstrable experience of implementing the same software in a similar environment. Most consulting organisations should be willing to give you guidance for free to help you understand expected costs. In some instances, this may require more analysis time to understand the requirement, but surely a minimal cost upfront, to avoid a huge under, or over, estimation is a necessary investment?
If you need any help understanding the potential implementation costs of Oracle Hyperion DRM can help your organisation please do not hesitate to contact us.
Oracle Hyperion Data Relationship Manager (DRM) has a somewhat unorthodox interface, which can lead the unwary into losing their work. Grizzled Oracle Hyperion DRM veterans will have discovered these traps the hard way, but if you are relatively new to the product this blog post might spare you some pain, we hope.
Items Displayed in Tabs
Oracle Hyperion DRM uses tabs to display the details of queries, compares, imports, blends, exports and all the objects managed by a system administrator. When you have one of these open, as the image below shows the only indication that you have unsaved changes is an asterisk next to the item name (and even this cannot always be relied on).
If you close an item after making changes, you don’t see the Save / Don’t Save / Cancel dialog box that most programs would display – Oracle Hyperion DRM simply closes the item and discards any unsaved work. It is thus important to get into the habit of being conscious of whether you need to click the Save icon towards the top left before closing a Oracle Hyperion DRM tab.
When an Oracle Hyperion DRM version is created it starts in an unsaved state. Unsaved versions are deleted whenever the Oracle Hyperion DRM service is restarted (which happens every night at some sites). New versions are often used for importing data to blend into other versions, so are legitimately temporary. However, if you have created a version you want to keep, it does not matter how often you clicked Save after adding or moving nodes or updating properties. If the Oracle Hyperion DRM service is restarted you will lose everything.
You should save a version you want to keep as soon as you have created it, by right-clicking on its name and selecting Save.
Once a version has been saved, all confirmed node changes and property updates are preserved without you having to save the version again.
Hopefully that should save you some time and stress!
This is the first item in an on-going series of blog posts designed to help our readers get the most out of Oracle Hyperion DRM (Database Relationship Manager).
This post addresses a limitation in the way Oracle Hyperion DRM allows users to define queries. Specifically, Oracle Hyperion DRM allows you to structure queries using parentheses but does not allow you to put a NOT in front of criteria grouped in this way.
What if you were making a complex query and wanted to exclude nodes that meet two conditions? For instance you want to select all nodes that are below the top node, except leaf nodes if they are also linked in from another hierarchy. In Oracle Hyperion DRM terms what you are trying to achieve is:
- Level Greater Than 1 And Not (Leaf Equal True And Linked Equal True)
You cannot code this as it stands in an Oracle Hyperion DRM query. However, the following rule of logic can help:
- not-(A and B) is logically equivalent to (not-A or not-B)
Our example now becomes:
- Level Greater Than 1 And (Leaf Equal False Or Linked Equal False)
Which as the screenshot below shows can be implemented in Oracle Hyperion DRM in the following way:
If you have anything you want to add please do post a comment. Until next time….
We recently encountered a small problem with the “remove validations” functionality in Oracle Hyperion DRM (Data Relationship Manager). As the screenshot below shows, we had set up a validation to prevent the deletion of certain nodes.
This is an important issue as most finance applications need to be assured that no nodes can be deleted to ensure no historical data is deleted. Disappointingly, when we assigned this validation to a hierarchy, it was ignored.
This problem affects release 188.8.131.52 of Oracle Hyperion DRM and is fixed in the latest release (184.108.40.206.300). Fortunately, for clients still on the earlier release, Oracle has provided a workaround. As the screenshot below shows this is simply to define the validation as both real time and batch:
Once assigned to a hierarchy as both a real time and batch validation, it successfully prevented nodes from being deleted. This is only a small bug, but it could have had a wide impact. We hope you have found this useful and we’ll be back next week!
What is financial intelligence, I hear you say? Well it goes by many names and comes in many shapes…
Example 1: You have a single intercompany account in your ledger, but you need to present this in your consolidation and/or reporting solution as either an asset or a liability, depending on whether the balance this month is a debit or credit.
Example 2: You have 20 sales tax (VAT) accounts in your ledger. You need to evaluate the sum of all the accounts and present the entire amount as either an asset or liability in your consolidation and/or reporting solution, depending on whether the cumulative balance is a debit or a credit.
In my experience, there are the following three approaches to solving this challenge:
- use the ledger to present the information in the required format. This can be done via an automated or manual month-end journal;
- use the ETL (Extract Transfer Load) process via a rule based mapping to transform the data; and
- load the data into the consolidation and reporting tools in the format of the ledger, and use scripts within these tools to copy this data into presentation accounts.
Which of these three options are right for you, depends on your business process. I thought it would be useful to share the following considerations when you are deciding which of the three options to use:
- In my experience clients are often cautious about putting presentation journals in their ledger, because of the concern that these will not be visible or auditable in the consolidation and reporting solutions. There are effective solutions to this requirement via the ledger setup;
- Rule based mapping solutions should be evaluated to confirm that they a) do not jeapodise the audit trail and b) will support solutions that allow you to drill from a consolidation or reporting tool back to your ledger. For example, logic groups in Oracle Financial Data Manager (FDM) can affect the audit trail and the ability to drill through;
- If the mapping approach is selected, the mapping must be available to all the consolidation and reporting tools: say HFM (Oracle Hyperion Financial Management), Oracle Essbase and OBIEE (Oracle Business Intelligence Suite Enterprise Edition); and
- The third option, using scripts to create the presentation data in the consolidation and reporting tool, has the obvious risk that if these multiple scripts fall out-of-alignment, the tools will not reconcile.
As a final comment, in my experience, regardless of which of the three approaches you decide to use, incorporating a masterdata governance tool can provide a robust as well as a flexible long–term solution…
Some good news to share! We have started a comprehensive BI (Business Intelligence) Finance initiative for the UK’s favourite retailer. We have been asked to design a solution to use Oracle Hyperion DRM (Data Relationship Manager) as the single repository of all the retailer’s financial masterdata. Oracle Hyperion DRM will provide them with a comprehensive governance solution enabling efficient maintenance of all their core financial masterdata.
Oracle Hyperion DRM’s scope will encompass Oracle EBS, ERPi (Enterprise Resource Planning Integrator), FDM (Financial Data Quality Management), HFM, Essbase and OBIEE (Oracle Business Intelligence Suite Enterprise Edition) applications and tools.
This represents another great opportunity to show how masterdata management (MDM) should be a primary consideration at the start of any EPM (Enterprise Performance Management) initiative, not, an afterthought.
We look forward to sharing more over the course of the project. Off to celebrate!