Need to have some clarity over the multiple base load in same Hyperion application. Just to give some background of the requirement our current HFM application captures the base level data in Indian GAAP reporting structure only just like any other incorporation would do in their statutory reporting format. Now we are looking at prospects and possible impact of capturing, at base level data, both as per Indian GAAP and IFRS formats- both being active but populated by different end users.
We would like to receive some valuable inputs as to how feasible it is to capture at base level, financials of different GAAP as part of same application substantiated by an example, if any. In other words what could be the possible challenges and adverse impact because of the the multiple base load. One such impact which I could foresee could be handling of business rules and validations for different base load in the same rule file.
This is fairly common. You could have a dimension set up as "Input Type" or similar with local GAAP numbers loaded. Then you could apply US GAAP, IFRS, or other type of adjustments into another member of the Input Type dimension. Rules, member lists, aggregation weight of members, will all need to be considered. If you have very few adjustments, you could potentially do this in the Account dimension, but that would be a bit more rare.
the query asks for multiple base loads - i.e Base / Lowest level data being loaded into the application (loaded thru FDM, Data Forms etc - and not Journals/Adjustments), both for Indian GAAP and IFRS, parallely
The requirement is to specifically load both Indian GAAP and IFRS as base level information - to enable both reporting journeys, in the same application.
- 1 base load in Indian GAAP, with related IFRS adjustments to reach financials as per IFRS requirement
- 1 base load in IFRS, with related Indian GAAP adjustments to reach financials as per Indian Gaap requirements
Both hierarchies - operating within the same application - but for two different set of entity hierarchies, for two different end-user groups, with different reporting timelines.
What are your inputs, from a Best Practice approach - whether to develop such structures as part of the same application or go for separate applications - from a design, development, testing and ongoing maintenance perspective
Edited by: Indraneel Mazumder on Feb 19, 2013 7:41 PM
Just a heads up, your big problem won't necessarily be the inability to perform multiple loads. You can easily do that by setting up a custom dimension and having one for each of the load types.
The "gotcha" with this approach though comes from the fact that users will have to load data on a merge(otherwise each load wipes the other one out). The risk with a merge is that if the data is load one and then a gl reclass is done to another intersection and reloaded, you'll duplicate the data since the merge won't wipe out the original amount.
Your best bet for this is either teaching users to use database management to do a selective clear when reloading(kind of risky in my opinion) or alternatively build a clear rule that allows them to enter a 1 in a data form and calculate the entity to clear it.
Alternatively, you could do replace by security, but that assumes that each of the loaders can't load to the other load type. But that's not too common in my experience.