# Using Assumption Models to Provide Parametrized Calculations for End-Users

By - Jan 23, 2015

Often times when developing rules for end-users, you’d need to provide areas of flexibility for the end-users to have the ability to input parametrized assumptions that impacts 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 will 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 would only cover the architectural structure of how the data models and rules should be configured.

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 are collecting the capital asset spend name and amount, fixed asset type and start date: #### Assumption Model

Here we have a cube called “Cap Asset-Assumption”. The purpose for this cube is to collect the parametrized input needed for your calculation. In this example, we are collecting number of monthly periods for depreciation spread. #### Calculation Setup

Once you have both the “Assumption” model and “Planning” model in place, we can 1.) reference both data sets to produce the calculated results with either a business rule or data view and 2.) create a dedicated “Calculated” partition to store the data in. The calculated partition setup is a best practice for separating user write-back 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 defined is contained in the rules/data view logic, but with access to the parametrized assumption and planning data in scope.