For those not already familiar with Calc Manager, it is Oracle’s visual tool for creating rules for HFM and Planning. In my experience Calc Manager is not widely used to create HFM rules. However it is well worth looking at rules created using Calc Manager even if you do not intend to use it, as they are well structured and demonstrate good practice that can be used to improve classic HFM rules.
In my opinion, the best idea you can copy from Calc Manager is how it structures Calculate subroutines. A Calculate subroutine generated by Calc Manager might look like this:
Sub CALCULATE() Call CopyActualToForecast(false) Call CopyExchangeRates(false) Call CalcOpeningBalances(false) Call CalcMovements(false) Call CalcPlugMovements(false) Call CalcKpis(false) Call CalcRoundingPlugs(false) Call CalcCashflowFinancing(false) Call CalcCashflowInvesting(false) Call CalcCashflowOperating(false) Call CalcTransEquity(false) Call CalcTransMovement(false) Call CalcValidations(false) Call CopyAlternative(false) Call ImpactActuals(false) End Sub
Each subroutine called from Calculate is individually scoped to determine the POV it runs for. For example:
Sub CopyActualToForecast(bLog) If HS.Scenario.Member()= "P3Forecast" OR _ HS.Scenario.Member()= "P6Forecast" OR _ HS.Scenario.Member()= "P9Forecast" Then If HS.Value.Member()= "[None]" OR _ HS.Value.Member()= "<Entity Currency>" OR _ HS.Value.Member()= "<Entity Curr Adjs>" Then If HS.Entity.IsBase("","")= TRUE Then ' 'Rules to copy actuals to forecast ' End If End If End If End Sub
Short Calculate subroutine
Calculate subroutines are often hundreds and sometimes thousands of lines long. This length makes it very difficult to keep track of what is happening and work out when a particular rule runs. The very short procedure used above solves this problem.
Calculation order is clear
The order in which calculations are run is immediately apparent from the calculate function. Calculation order is often the source of hard-to-find errors in HFM applications. The very short procedure used above should make these problems easier to find and fix.
Encapsulation of functionality
All the code for specific functionality, for example copying actuals to forecast, is encapsulated in short procedures. This makes it much easier to build, maintain and optimise rules.
The only possible disadvantage I can see is that scoping functions, for example HS.Scenario.Member(), are called more often. I have not performed any benchmarking on this issue but I have not noticed any performance problems with any of the applications I have built.