Development in a model(previously App) with poor architecture can be a frustrating task for any BPC professional. Complex architecture impedes performance, maintenance and consultant desirability. Sticking to the basics in terms of what is needed is most certainly the quickest route to delivering a solution.
In this short blog I'd like to emphasize what are the system prerequisites for the architecture within a bare bone legal consolidation:
Environment
Models:
- Legal Consolidation - This can be classified as the framework for the consolidation where the bulk of the work is done
- Rate - This model would house data pertinent to exchange rates and currency translation
- Ownership - This model is where we store data required for the consolidating roll up or structure, necessary for the Ownership Manager or previously Dynamic Hierarchy Editor (DHE)
(Note: An intercompany model is seen more often than not, however it is not a system requirement for setup of a legal consolidation. This model is used to match and pair intercompany transactions within the organizational structure)
Dimensions
Legal Consolidation
- Account
- Category
- Entity
- Time
- Flow/Movement
- RptCurrency
- Intercompany
- AuditID
- Consolidation Group
Rate
- Account
- Category
- Entity
- Time
- Input Curreny
Ownership
- Account
- Category
- Entity
- Time
- Intercompany
- Consolidation Group
You may notice that each model has the same first 4 dimensions. These dimensions are the basic system requirement for any model type, can can be easily referenced using the acronym
A(ccount)
.C(ategory)
.E(ntity)
.T(ime)
Hope this helps, and I'd invite correction if I have misinterpreted the above in any way.
Devon Abraham
Follow me: @_Devon_Abraham
