This content has been marked as final. Show 3 replies
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.
To clarify the question:
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.