Allowance objects follow a lifecycle in the system. The lifecycle starts with the creation of the object. An allowance that is created does not necessarily have to be active. It is possible to create an allowance that has a start date in the future.
The validity period of an allowance spans from the allowance's start date to the allowance's end date. During this validity period, the allowance is considered as active and consumption with a consumption date in the bounds of the validity period can be processed by it.
Once the allowance’s end date is reached, the allowance is expired. Expired allowances cannot be used anymore. They remain in the system available for rerating-processes but cannot be consumed by regular rating operations.
The retention period defines the number of days an allowance is kept in the system after it expired, so that it is available for rerating. After the retention period, the allowance is available for purging. A purging run can be triggered to delete all allowances that are not needed anymore.
Except for the purge operation, all steps along the lifecycle allow for the creation of billable items. When an allowance balance is not used completely by the customer, it is common to also expire any balance left in the allowance. The billable item can therefore report any leftover balance as expired, and therefore posted as revenue.
The following table provides an overview of the steps along the allowance’s lifecycle. An example for a custom logic for each step and the billable item types used in the training landscape for these steps.