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.
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:
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 184.108.40.206 of Oracle Hyperion DRM and is fixed in the latest release (220.127.116.11.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…
In a recent meeting I was asked whether there is a standard approach to signage in reporting. I think we can all agree this is a big question. “Reporting” covers a wide range of purposes and platforms. Did the client mean management, statutory or transactional? Were they looking at the consolidation tool, budgeting and forecasting or analytical? The implications of the decision are wide ranging for the usability of your financial applications, and therefore it needs significant thought.
However, it is a common question. There is no standard! With my consulting hat on, the solution is clear: an organisation needs to adopt a single reporting standard which addresses its management, financial and transactional reporting purposes. What that standard is, from my selfish point of view, is immaterial! I have included an example of signage standards, but this is by no means the only approach.
In my past life as a management accountant, I spent many a late night during month-end trying to reconcile reports across Oracle Hyperion Essbase, HFM (Hyperion Financial Management and Oracle E-Business suite (EBS). Were the numbers I was seeing correctly sign-flipped? As each application was using its own approach to sign-flipping, how could I be sure that the rules had not fallen out of alignment?
Then I discovered masterdata governance. I found that by centralising all our financial masterdata (including our report definitions) into a single location we could create a single definition of our core financial constructs, including a single definition of the signage rules. These rules were then published for use in all our financial reporting applications, thereby ensuring that they were using the standard definition. Once implemented, I spent less time reconciling and more time analysing, a benefit that I think all my fellow accountants and the business would see as a “positive”!
Until next week.