Systems Integration

Seismi Case Study | Anglo American plc

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. 

Tagged , , , , ,

The Carrot or the Stick | Governance and Integration

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…

Tagged ,

Success Case (Financial Services) | ICAP plc

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.

Tagged , , , ,

Oracle Hyperion DRM Technical Issue | Integration with EBS

Hi everyone!

We just stumbled upon an interesting change in the latest version (11.1.2.3) 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 11.1.2.3.303.

We hope this is useful.

Tagged , , ,

Oracle Hyperion DRM Tips & Tricks | Clearing a Property Value

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

131211_Seismi Blog_Clear Property Value in Oracle DRM

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:

131211_Seismi Blog_Clear Property Value in Oracle DRM_2

Tagged , , , , ,

Oracle EPMA | Error on import

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

130802_Seismi_EPMA Error on Import_1

 

130802_Seismi_EPMA Error on Import_2

 

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:

#root|BALSHT

BALSHT|ASSET_ACC

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.

Tagged , ,

Estimating the Costs of implementing Oracle Hyperion DRM

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:

  1. Software and licensing costs;
  2. Hardware costs; and
  3. 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.

Tagged , , , ,

The Value of Managing Your Data Effectively

We recently came across a very good presentation that described concisely, in business terms, why a strategic approach to data and masterdata management is a must for any serious organisation.

I highly recommend that anyone who is struggling to understand the benefits of these critical areas, or needs a reminder, to take a few minutes out of their day to view the slides below:
 

 
Do you agree or are there other areas we all should also be considering….?

Tagged , , ,

Oracle Hyperion DRM Basics | Scripts

In this blog, we will have a look at Scripts which were called automators in some earlier versions. Scripts in Oracle Hyperion DRM (Data Relationship Manager) are a simple tool that execute sets of simple instructions in one bulk load. For example, if you need to change the value of one property against hundreds of nodes, the simplest way to do this is to create a Script. An effective way to increase productivity through the use of automation.

The basic rule in a script is that each line is a specific action. Each line also needs to be divided into columns by a delimiter. The first column should contain the action code. Oracle Hyerion DRM supports an important list of action codes that allow you to carry out a lot of different actions such as change property (“ChangeProp”), add a node (“Add”), insert a node (“Insert”), remove a node (“Remove”) and so on. The full list of actions available is described in the Oracle Hyperion DRM user guide. The following columns will contain the parameters for the action.

As an example in this blog, I am going to add a node into a hierarchy then change its description. This will require two actions and my Script will need two lines:

  1. First add the node using the “Add” action code. This code takes 5 parameters:
    1. Version – This is the name of the version in which the node will be added.
    2. Hierarchy – Name of the hierarchy in which the node will be added.
    3. Node Name – Name of the node to be added.
    4. Parent name – Name of the parent of the node.
    5. Leaf – Flag indicating if the node is a limb or a leaf.
    6. In the second line we use the action code “ChangeProp” to modify the description. This action also takes 5 parameters:
      1. Version
      2. Hierarchy
      3. Node Name
      4. Property – Name of the property to be modified.
      5. Value – New property value.

So the file looks like this:

You can build this file using a simple text editor or Excel. In Excel, just save the script as a .csv file.

To execute the Script, navigate in Oracle Hyperion DRM to the Script section.

Specify the file characteristics like the column order, the column delimiter or the encoding in the “Source” section. Then browse to your file and press “Load”. Once the file is loaded, you will see the list of actions Oracle Hyperion DRM has recognized in the bottom section. Any action code that was not recognized will be ignored.

In the menu called “Script” there are some additional options. For example, you can substitute the versions in the Script for a different version present in Oracle Hyperion DRM. You can also select only a subset of lines you which to execute. Once you are ready, press the play button. This will execute all the selected lines.

Once the Script has been executed, you can see the result in the “Status” and “Return Value” columns.

“Status” will flag any error and “Return Value” will return the error message if there was an error or any other return value depending on the action code. These results can be saved by navigating into the Script menu then selecting download then the format.

While this was a simple example we hope that it was clear and useful. If you have any questions you know where we are and we would be delighted to help.

 

Tagged , , , ,

Oracle Hyperion DRM Basics | Imports (2 of 2)

In last week’s first post on importing into Oracle Hyperion DRM (Data Relationship Management) we looked at how to build a file to import master data into Oracle Hyperion DRM. Now we will create the import in DRM. Browse to Oracle Hyperion DRM, then go to imports and click on “New Import”.

The first step when users configure Oracle Hyperion DRM to import requires selecting the file to be imported, specifying the character encoding, the field delimiter and the sections present in the file. You can also customize the headers for each section.

 

The second step when customising Oracle Hyperion DRM for imports is deciding what style to use for the import.

 

In this step you can configure the import so that it populates sort relations, leaf or limb as well as customising how it handles duplicate nodes. I will spare you too much details for this post. You can always play around with these options to understand how they impact the result of your import. So for our example, we will elect to leave everything to default and go to the next step.

Next you must select the columns for each section. In this example, I have a hierarchy section and a relation section so I must configure the columns for these two sections. First select the hierarchy section.

 

In this file I have three fields, the hierarchy name, the top node and the hierarchy description. So I select these columns by placing them in the box on the right. (Columns noted with a star are required in any hierarchy sections). The second section is the relation section. In my file, I had three columns: parents, child and description. So I select these columns as shown here:

 

Please note you need to be careful with the order of the columns, they need to be selected in the same order as they appear in the flat file.

The fourth configuration step is the filters. Filters will allow you to define the behaviour for properties. It allows you to configure the import to skip blank values and skip default values if that is required. For this example, I am going to leave all the filters to the default values.

The final step is to define the target. As I have no version section, I must define the target version name and description. In this step you can also define the “Max Errors” number. This number defines how many errors can occur before the import is aborted. I’ll leave it to 20.

 

Now you have defined your import. You can save it using the usual save button. Execute it with the green arrow. Once you execute the import, Oracle Hyperion DRM will show a log for the import. The log will return an error message for each error, which allows you to correct your file or import.

 

Now you can navigate to “Browse” and see your new version with the imported hierarchies.

 

These last two posts on the basic requirements for Importing, intended to give you the basics on how to import into Oracle Hyperion DRM but there is much other functionality that it is worth exploring and utilising in your deployments of Oracle Hyperion DRM. If you would like to Seismi to look at anything specifically in future blog posts then please let us know.
 

Tagged , , , ,