Order Overview
Ot the date of the order, the order is placed which starts the ordering process. This process is ended by invoking the hookpoint "RATEPLAN.CHANGE.ORDER". After successful completion, the rate plan change enters a pending state.
Based on the given effective date, a start date is calculated. When this date is passed, the corresponding process begins and ends with invoking the hookpoint "RATEPLAN.CHANGE.START". After successful completion, the rate plan change enters into the 'started' state.
Immediately after the rate plan change has entered the 'started' state, the execute process begins by invoking the hookpoint "RATEPLAN.CHANGE.PRIOR" followed by applying the core business logic. Subsequently, the hookpoint "RATEPLAN.CHANGE.AFTER" is invoked. Upon successful completion the rate plan change enters the 'completed' state.
Please note that two different workflows are invoked in the 'started' state. The reason is to allow the customer to implement required logic in either workflow based on what is considered the most appropriate. We should discuss if both the "START" and the "PRIOR" workflows are needed.
RatePlanChange Order Process
RatePlanChange Start Process
Execute Process
It is important that a rate plan change is executed before the effective date in order to ensure that traffic, fees etc. are billed correctly on that date.
In order for a rate plan change to become active no later than the effective date, it is necessary to initiate the execution process some time before midnight on the day before the effective date, i.e. if the effective date is set to the 2nd December, the process must be completed before the 2nd December at 00:00.
A rate plan change consists of a number of steps:
- Business logic to be executed prior to the core logic (hookpoint key "RATEPLAN.CHANGE.PRIOR"). By using this business logic the rate plan change information may be altered, fees may be added, provisioning tasks may be created, and external communication may be initiated.
- A billing group member must be created referring to the new rate plan, and service options must be created or deleted.
- The set of new billing group members, updated service options as well as potentially information about a product change will be added to a workflow context which allows the result to be altered and invoke other types of business logic. This should happen as part of workflow identified by the hookpoint key "RATEPLAN.CHANGE.AFTER".
- The set of new billing group members, updated service options and product information will be persisted. This change should happen no later than 00:00 ot the effective date, otherwise rating and billing may be wrong.
To ensure that the rate plan change is persisted prior to the effective start date, the process must be initiated some time before the effective date. It is suggested that this is a parameter for the rate plan change process which specifies that the execution should begin some hours before the effective date. Thus it is up to the prior workflow to keep the logic simple and avoid external dependencies to ensure that the actual rate plan change may be handled in time.
Today it is possible to create the billing group membership in advance, so this could actually happen immediately after the start of the process. However, this is not possible to do for product changes nor option changes.
Implementation Information
The current rate plan change engine must be altered to allow the identification of pending rate plan changes according to the start date and effective date.
The current rate plan change process must be inspected to ensure the changes are done according to core logic, and that the appropriate workflows are executed. Changes are needed to separate the outcome of the rate plan change process with the persistence of the same outcome.
RatePlanChange Post Process