Use Assumption Models

Introduction

Often times when developing Rules for end-users, you need to provide areas of flexibility for the users to have the ability to input parameterized assumptions that impact their overall plan.

A couple examples of these cases include:

• Spread % based parameters
• Interest & tax % allocation parameters
• Currency exchange rates
• Travel costs (per diem) parameters

In this article, we'll describe one example of how Assumption Models are best used to handle these types of scenarios.

Note: Since all calculations are specific in nature, this article will only cover the architectural structure of how the Data Models and Rules should be configured.

Example

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

Planning Model

Here we have a cube called Cap Asset-Planning. The purpose of this cube is to collect the planning data that is used to 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 in Capital Asset Planning:

Assumption Model

Next, we have a cube called Cap Asset-Assumption. The purpose for this cube is to collect 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:

Calculation Setup

Once you have both the Assumption Model and Planning Model in place, we can first reference both data sets to produce the calculated results with either a Business Rule or Data View and then 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 come through on this Form, or any reports connected to the Cap Asset-Planning cube.

For a majority of assumption-based scenarios, this is a best practice approach. The specific areas of 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.