...
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.
...
Order Process
Configuration matrix must be defined:
From Product and RatePlan | The combination of Product and RatePlan currently assigned. |
To Product and RatePlan | The allowed Product and RatePlan which may be used as target for a rate plan change. |
Effective date | The logic for calculating the date of making the rate plan change effective. Different rules may be applied: 'Tomorrow', 'EndOfMonth', ... |
Start date | A number of hours relative to the effective date, which describe when the rate plan change process starts. When this has passed, the rate plan change cannot be stopped (i.e. point of no return). |
Allowed channel(s) | Indication of which channels (customer care, self care, ...) allow ordering this rate plan change. Still to be defined how this is to be represented. |
Key | A string that will be the dynamic key for hookpoint keys, but may also be used for identifying price elements. |
To interact with this configuration matrix, and to place a rate plan change order, some API's should be implemented:
Retrieve valid configuration matrix elements:
- Given a subscription and a channel, return the list of available configuration elements valid for this subscription and channel.
Retrieve information about pending rate plan change:
- Given a subscription, return the pending rate plan change if it exists. Null otherwise. Used to show and potentially modify the existing rate plan change.
Order rate plan change:
- Given a configuration matrix element, subscription and effective date, validate if the rate plan change is allowed according to the configuration matrix element.
- Given a configuration matrix element, subscription, effective date, silent indication, fee apply indication and list of chosen options, persist the requested rate plan change and invoke the hookpoint "RATEPLAN.CHANGE.ORDER" + key from the configuration matrix element. The silent indication will be transferred to the various workflows to allow external communication to be excluded. The fee apply indication will be transferred to the various workflows to indicate if fees should be added or not.
The requirements in /wiki/spaces/callmobile/pages/109623384 indicate that provisioning may be requested and fees applied. The intention is to consider it business requirements and thus to place it in the appropriate workflow.
Implementation information
It should be rather straightforward to implement the configuration matrix and related API. However, a GUI must be created to maintain the configuration elements, and (at least) the current rate plan change panel in customer care must be updated to utilize the API functionality.
When a rate plan change is ordered, the current functionality that saves the rate plan change record and associated options must be inspected and validated. As far as I know, scheduling a rate plan change does not work that well. Some work is needed to validate and probably also correct the functionality.
| Include Page | ||||
|---|---|---|---|---|
|
...