Goal

A complete solution for lifecycle of price lists

User stories

• As a admin, I want to be able to define different versions of the price model, so that the proper version can be shown for stored and new calculation

• As an admin, I want to be able to define when a new version will be applied

Problem

Being able to differentiate between charges being calculated and recalculated for the current billing period with the charges that were calculated in the past with a different price model.

Why is this important

It allows admins to manage their price models and enable new versions in advance, so they can set them up without waiting for the billing period when they want it be applied to be active.

Examples

Example 1.

A user looks at the data for 3 months ago. The price model has been changed since that moment and there is new active one, but the calculations where done with an old version of it.

When the user sees any calculated data in the interface he is presented with the version of the price model that was used to calculate the data, and a message that lets him know if there is a new version of the cost model.

Example 2.

An admin knows that they want to change the markup on a cloud with the new year, from 10% to 20%. The administrator decides to implement the price model modification today, but with an applicability date of the new year. During the months until the price model change, the current model is used, and the admin can update the price model without creating a new version.

Once the date is reached, the new model is used.

Example 3

AWS updates its price list, and calculations are updated. As there are no changes in the price model, the user still sees the same model