How to write better Oracle Financial Management (HFM) rules by copying Calc Manager

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

 Advantages

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.

Disadvantages

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.