Financials Cloud for EPM folks - Hierarchies

This is the second post of my Financials Cloud for EPM folks series, in these posts I'm trying to familiarize EPM professionals with ERP Financials Cloud because we all have to interact and work with ERP cloud at some point. 

In the first post, I covered value sets and in this post I will briefly writing about hierarchies. In the ERP world metadata is defined in two ways:

1- Value sets (flat lists) primarily used for transactions, journal entries and all kind of ERP related configuration/

2- Hierarchies - primarily used for reporting and budgetary control purposes (hierarchical reporting in ERP? Yes, there are multiple Essbase cubes in ERP for reporting ad budgetary control purposes)

Why is it important for us in EPM world? Well, unless your metadata is 100% synced between Planning/Consolidation applications and ERP then there is always a need to get metadata information from ERP. Whether it is for manual updates, description changes, member additions/movements in the hierarchy etc.

So let's get on with it and show how to access your hierarchies in ERP cloud.


From Settings and Actions go to Setup and Maintenance

Search for "Manage Account Hierarchies" and click on it, as you can see below this task is located in Financial Reporting Structures.

In Manage Account Hierarchies you will see all the available dimensions, and the associated tree versions. (Tree version is another copy of the hierarchy).

If you expand any of the nodes you will find the tree version(s) and the active/current one. From there, simply click on Actions -> View Tree Version.

And here you can navigate the hierarchy in a simple way. Let's say you are trying to load actual data in Planning and the rule is failing because of a missing member, the log will tell you what is the member name but it won't tell what is the parent member! So from here you can easily figure it out.

Hope you find it useful.

Dashboards 2.0 - Geomaps Part 2

 This blog is a quick follow-up to my last post about Geomaps, and the focus of this post is to show another way we can build the metadata to support Geomaps chart types.

While there are restrictions when it comes to country names, there is nothing that stops us from creating additional members that roll up to countries. For example, let us look at the following hierarchy:

As you can see above, I have suburbs rolling up to cities, and finally to countries which is the level the Geomaps will work at. So this means we can store data in non-recognized Geographical members (Manly as an example) but as long as they roll up to recognised members (Australia) then we are good to go.

To test this I have created a data form to enter some data and created a dashboard on top of it. Here is the data in a tabular format:

The same data in a Geomap chart type:

Yes, it works just fine! pretty cool and extremely powerful if you ask me!