Seismi is pleased to announce that we have achieved the Oracle Partner Network Specialisation in Oracle Hyperion Data Relationship Management.
To become specialized, our company met stringent, product-specific competency and business requirements. Specialisation offers you confidence that we have the required resources and solution knowledge you need, including:
- Product-specific Oracle presales, sales, support and Certified Implementation Specialists
- A proven track record with recent Oracle transactions
- Successful implementations verified by Oracle
Check out our OPN Profile here.
Learn about OPN specialized here.
Many of our multi-national clients have the same challenge – local reporting on one accounting standard (normally local GAAP); group reporting (normally a flavour of IFRS) on another; as well as specific reporting requirements for regulators in certain verticals.
The difference between accounting standards can be summarised as follows:
- Differences in report definitions (for example, the balance sheet may be presented in an different order, granularity or definitions); and
- Differences in accounting policy (say development cost may be expensed under one standard and capitalised under another).
From my experience as an auditor, report definitions should be treated as an integral part of a company’s financial reference data, as they are one of the major reasons for material disclosure errors. Oracle Hyperion Data Relationship Manager (DRM) is a dedicated financial metadata management tool that we have implemented successfully at our clients to govern metadata and report definitions.
Historically differences in accounting policies are normally tackled by using adjustment ledgers or separate ledgers. This often introduces a governance problem, in that different subsets of a chart needs to be shared across multiple ledgers, and kept aligned.
Oracle Hyperion DRM is adept at defining these types of business rules and controlling the complete ERP metadata. It is application independent and can therefore integrate with ERP’s from any vendor. We have found it to be a very useful and flexible tool to manage multiple accounting and reporting standards, as well as many other historically challenging scenarios.
Firstly apologies that 3 weeks have passed since we last updated our weekly blog. Like many others Seismi’s team have been taking some well earned leave, as well as meeting other development deadlines.
We wanted to bring to your attention a case study that Oracle has published on their website that highlights an example of a project that we have recently delivered. Our client was Anglo Copper a USD4 billion division of Anglo American plc and the environment was relatively complex with many applications and over 200,000 account codes.
The case study is a good example of the type of project that Seismi team have delivered for their clients. It also provides a good example of the flexibility of Oracle Hyperion Data Relationship Manager (DRM) tool and how it can be adapted to meet key business issues.
Not only were Seismi able to allow Anglo Copper to resolve some significant issues within their finance applications architecture but it has also provided their finance team with a robust and flexible platform that will be able to adapt to Anglo Copper’s business as its strategy evolves, including the ability to integrate acquisitions effectively.
In addition we were able to implement the solution over a rapid a 6-month timetable. Seismi are continuing to provide second line support to Anglo Copper’s user base.
You can read the brief case study here and please get in touch if you would like to hear more of the detail.
Also if there any specific topics you would like us to cover then do reach out.
In the UK the FSA’s Code of Corporate Governance and in the US the SOX Act, require companies to ensure that their financial statements are an accurate representation of their underlying transactional and forecasting systems.
In most companies, the flow of data from the diverse ledgers and forecasting systems, through group consolidation and into the financial statements is a highly manual process. It is not possible to certify from a governance or internal-control perspective, so most companies require that the financial controller of each division sign off on their respective data once they have manipulated it into a single repository on a single standard. However, this passing of the corporate buck has no legal effect on the company’s, CEO’s or CFO’s responsibility! In our experience , it is also a very unreliable and inefficient method of identifying errors…
The alternative is to integrate a company’s diverse ledgers, forecasting, consolidation and reporting systems. One option to achieve this is to convert all of your systems to the same chart and platform. However, Seismi’s preferred route in the right instance, such as when the principle aim is to standardise business reporting, is to: understand and define the business rules to align the reference data across these multiple standards; centralise and govern this masterdata; and finally distribute the refined masterdata to the relevant systems and applications thereby creating the necessary standard reporting. The benefits of this method of standardisation extend way beyond avoiding the legislative stick.
Imagine your organisation where someone from head office can drill through the group financial statements to the divisional data balance, and then to a specific transaction, to understand who and why an accrual was raised, without the normal month-end ‘please explain..’. Converting bean counters into bean farmers, well almost…
We are delighted to announce some fundamental changes to our management structure which will come into effect from today, 3rd February 2014.
- Quentin Vermolen has joined Seismi. Quentin previously worked at Oracle-Hyperion and brings a wealth of experience implementing financial solutions which complement our existing capabilities. He will focus on business development and further extends our experience implementing planning, consolidation and financial reporting solutions.
- Jerome Marcq has been promoted to Director, Technical Solutions.
As a result our management team is now:
- James Gordon (Managing Director) – James has assumed responsibility for our strategy, performance and operations. He remains responsible for our team of technical architects;
- Ross Gilfillan (Director, Business Analysis and Client Services) – Ross has assumed responsibility for our relationships with our customers. He continues to run our Business Analysis team;
- Quentin Vermolen (Director, Business Development) – Quentin is responsible for Business Development. He will also head up our Consulting Practice; and
- Jerome Marcq (Director, Technology) - Jerome is now our Technical Director and is tasked with understanding how best to use the Oracle Hyperion EPM suite to create truly integrated solutions.
Our key objective as a management team remains to deliver robust, scalable and efficient financial solutions, on time and to budget. We will continue to differentiate ourselves from our competitors by creating truly integrated solutions underpinned by efficient use of masterdata management.
If you have any questions please do not hesitate to get in touch.
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 (188.8.131.52) 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 184.108.40.206.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:
We are doing a fair amount of work with Oracle Enterprise Performance Management Architect (EPMA) application at the moment. We came across the following error message recently. (In the spirit of paying it forward we thought we should share it with you.)
“EPMA Error on import – Member cannot be inserted because the parent member has another child member with the same name.”
It took me some time to understand this one although in the end the cause was quite simple. I hope that this can save you some time…
One of my imports to EPMA was failing and returning the error “This member cannot be inserted because the parent member has another child member with the same name.”
At first this seemed like a simple mistake in my load file. After checking, I was disappointed to discover the error message was misleading. My file contained the correct structure:
The member ASSET_ACC was not repeated in the hierarchy section. The import profile was set to replace the current dimension so the fact that the member ASSET_ACC was already in EPMA should not have been an issue.
This article from Oracle’s Knowledge Base gave me a hint as to the source of the issue in the document EPMA Error “This member cannot be inserted because the parent member has another child member with the same name” [ID 1361635.1]
The issue was that in my current dimension, the member BALSHT was written BalSht. It looks like EPMA is only partially case sensitive so it was partly recognizing BALSHT and BalSht as being the same member but it was not updating that member correctly. As soon as I renamed BALSHT to BalSht in the file, the import worked.
The root cause to keep in mind is that EPMA does not handle subtle differences in cases well.