Oftentimes when developing Rules for end users, you need to provide flexible solutions so they can input parameterized assumptions that impact their overall plan.
Examples where this would be the case include:
- Spread % based parameters
- Interest & tax % allocation parameters
- Currency exchange rates
- Travel costs (per diem) parameters
In this article, we'll look at one example of how Assumption Models can best handle these types of scenarios.
Note: Since all calculations are specific to each case, this article will cover only the architectural structure dictating the configurations of Data Models and Rules.
Here we will be using our Capital Asset Planning Module as an example. The functionality we are configuring here is for the following scenario:
Planning Input: Capital asset spend name & amount, fixed asset type (drop-down) & start date
Assumption Input: Number of depreciation periods (monthly) for each asset type
Calculated Results: Starting from specified start date, evenly spread the capital asset spend amount based on depreciation period of each fixed asset type
The Cap Asset-Planning cube collects the planning data that drive the calculated results. In this example, we're collecting the capital asset spend name and amount, fixed asset type, and start date.
Which gives us the following Dashboard Page:
The Cap Asset-Assumption cube collects the parameterized input needed for your calculation. In this example, we are collecting the number of monthly periods for the depreciation spread.
Which is shown below in the same module:
Once you have both the Assumption Model and Planning Model in place, we can reference both data sets to produce the calculated results with either a Business Rule or Data View. Then, we can create a dedicated Calculated partition to store the data in. The Calculated partition setup is a best practice for separating user Writeback data from the Calculated data.
Afterwards, we can see the calculated results on this Form, or any reports connected to the Cap Asset-Planning cube.
For a majority of assumption-based scenarios, this is the best practice. The specifics on how the Rules are defined is contained in the Rules/Data View logic, but with access to the parameterized assumption and planning data in scope.