Find Information on the Feasibility of the Recharging
Definition
To determine if the recharging for a charging contract at a specified date is feasible
Technical Data
| Software Product and Version | SAP Convergent Charging 4.1 |
| Technical Details | chargingContractRechargingFeasibilityInfoFind |
| Namespace | http://recharging.ws.highdeal.com/ |
| Proxy Instance in SAP CC System | Dispatcher |
| Service Operation Version | 0 |
| Application Area | IS-CC |
| Direction | inbound |
| Mode | synchronous |
| Idempotency | false |
Business Context and Use
This service operation is used to find information about the feasibility of the recharging of chargeable items for a specified
charging contract and at a specified date.
This operation must be called when the recharging of chargeable items is requested to check whether SAP CC is able to
restore the charging contract at a specified date called 'recharging date'. For the same recharging date, the charging contracts may not be restored
in the same way and so the feasibility of the recharging could be different between two charging contracts.
According to the recharging date, recharging chargeable items for a specified contract is:
Rerating Scenario
A correction step precedes the recharging step of the rerating scenario. This step performs corrections when errors leading to the computation of wrong prices are identified. For example, such errors are related to the pricing logic, the properties of chargeable items, and so on.
The recharging step of the rerating scenario consists in sending again chargeable items which were previously charged so that SAP Convergent Charging computes the correct prices after the correction step.
You can implement the following customizing sequence of operations for the recharging step if you want to provide rerating services in your system landscape:
- Find the charging contracts which must be recharged together
- Lock the related charging contracts
- Find information on the feasibility of the recharging for a charging contract at a given date
- Prepare the execution of the recharging process
- Search the restoration points for the related charging contracts
- Restore the related charging contracts at a date corresponding to one of their restoration points
- Recharge the related chargeable items
- Unlock the related charging contracts
The recharging step may be followed by:
- An activation step, in order to trigger again recurring charges which have been undone during the recharging step. See the Activate charging contracts in bulk operation.
- A re-invoicing step in the connected billing system
Related Service Operations
Features
The following examples show for a given recharging date, what is the feasibility of a recharging of chargeable items for a given contract.
All the examples have the same structure. After a description of a charging contract to which this operation will be applied, a table gives the result of this
operation applied to the charging contract for different interesting date.
It is supposed that the retention period of the counter snapshots is 5 days and that the current day is the 10th of the month. When the time of the date
is not specified, that means it is 00:00am.
Sample#1
The charging contract was created several months ago. Every day at 00:00am, a counter snapshot is created and the last chargeable item was charged the 09th at 3:00pm. The oldest
counter snapshot date is the 05th of the month and the youngest one is the 09th.
Sample#2
If the recharging is possible but there is no counter snapshot for the recharging date, then no restoration point is returned and that means there is no needed charging contract restoration.
Examples
According to the previous table, the recharging date is possible the 10th and the charging contract doesn't need to be restored (no restoration point). However a recharging the 04th is
not possible and then the oldest recharging date is the 05th. Finally the recharging date the 09th at 05:00pm is possible but the recharging date must be shifted to the 09th at 00:00am
(notice that this may recharge more chargeable items).
Recharging date
Recharging feasibility
Possible Recharging date
Restoration point date
10th
possible
10th
none
09th at 05:00pm
possibleAt
09th at 00:00
09th
09th at 10:00am
possibleAt
09th at 00:00
09th
08th at 05:00am
possible
08th
08th
08th at 00:00am
possible
08th
08th
04th
notPossibleUntil
05th
05th
The charging contract was created the 07th of the month. Every day at 00:00, a counter snapshot is created and the last chargeable item was charged the 09th at 05:00pm. The oldest
counter snapshot date is the 7th of the month. The recharging feasibility is like for the sample#1 except for the recharging date before the first
restoration point of the charging contract.
Recharging date
Recharging feasibility
Possible Recharging date
Restoration point date
06th
possible
06th
07th
02nd
possible
02nd
07th
Sample#3
The charging contract was created several month ago. Its oldest counter snapshot date is the 02nd of the month (7 days before the current day).
| Recharging date | Recharging feasibility | Possible Recharging date | Restoration point date |
|---|---|---|---|
| 10th | possible | 10th | none |
| 02nd | possible | 02nd | 02nd |
Sample#4
The charging contract was created the 07th of the month at 10:00am. Some recurring charges/one-shot/chargeable items was only charged the 07th. So the oldest counter snapshot date is the 07th of the month.
The youngest counter snapshot is also the 07th.
| Recharging date | Recharging feasibility | Possible Recharging date | Restoration point date |
|---|---|---|---|
| 10th | possible | 10th | none |
| 07th at 5:00pm | possibleAt | 07th | 07th |
| 07th at 3:00am | possibleAt | 07th | 07th |
| 06th | possible | 06th | 07th |
Sample#5
The charging contract was created the 07th of the month at 10:00am. No recurring charges/one-shot/chargeable items was charged until now. The charging contract has no counter snapshot.
| Recharging date | Recharging feasibility | Possible Recharging date | Restoration point date |
|---|---|---|---|
| 10th | possible | 10th | none |
| 05th | possible | 05th | none |
| 02nd | possible | 02nd | none |
Sample#6
The charging contract was created several month ago. Every day at 00:00am, a counter snapshot is created and the last chargeable item was charged the 09th at 3:00pm. The oldest
counter snapshot date is the 05th of the month and the youngest one is the 09th. However the counter snapshots of the 06th and the 07th are corrupted.
| Recharging date | Recharging feasibility | Possible Recharging date | Restoration point date |
|---|---|---|---|
| 09th | possible | 09th | 09th |
| 07th | possibleAt | 05th | 05th |
| 05th | possible | 05th | 05th |
| 04th | notPossibleUntil | 05th | 05th |
Sample#7
The charging contract was created several month ago. Every day at 00:00am, a counter snapshot is created and the last chargeable item was charged the 09th at 3:00pm. The oldest
counter snapshot date is the 05th of the month and the youngest one is the 09th. However ALL the counter snapshots until the 07th included are corrupted.
| Recharging date | Recharging feasibility | Possible Recharging date | Restoration point date |
|---|---|---|---|
| 09th | possible | 09th | 09th |
| 06th | notPossibleUntil | 08th | 08th |
Sample#8
The charging contract was created several month ago. Every day at 00:00am, a counter snapshot is created and the last chargeable item was charged the 09th at 3:00pm. The oldest
counter snapshot date is the 05th of the month and the youngest one is the 09th. However ALL the counter snapshots are corrupted.
| Recharging date | Recharging feasibility | Possible Recharging date | Restoration point date |
|---|---|---|---|
| 09th | notPossible | none | none |
| 06th | notPossible | none | none |
if (status is possible) then
// continue the recharging with the possible recharging date
else if (status is possibleAt) then
// restart the recharging of the consumption items with the possible recharging date
// and possibly check again with the chargeable item/charged item storage for the possible recharging date
else if (status is notPossibleUntil) then
// the recharging must be interrupted for the charging contract
// and the user must be advised to choose a date after the possible recharging date
else if (status is notPossible) then
// the recharging must be interrupted for the charging contract
// and the user must be informed that it isn't possible to recharge this charging contract
end
Authorization
Refer to the SAP CC Security Guide , to know the role that is expected in the SAP CC user profile of the service user specified in your request messages.
Error Handling
The SAP CC system may return a charging error classified into a category and an error stack detailing the issue and its cause.
Categories
Use the following error categories to customize the behavior of your application or system:
| Prerequisite Missing | The master data required for the execution of the operation request is missing, or the request is incorrect and does not target the correct master data. |
Applicable for this service operation: Next follows a non-exhaustive list of errors linked to the Prerequisite Missing category:
|
| Invalid | The parameters of the request are not valid. The request must be corrected before sending it again. |
Applicable for this service operation: Next follows a non-exhaustive list of errors linked to the Invalid category:
|
| Invalid Configuration | The configuration of the SAP CC system is not valid. It must be corrected before sending the request again. |
Applicable for this service operation: Next follows a non-exhaustive list of errors linked to the Invalid Configuration category:
|
| Illegal State | The master data used by the operation is not in a valid state. This is usually a normal behavior of the process and should be acknowledged as a failure. |
Applicable for this service operation |
| Temporary Illegal System State | The connected SAP CC system is currently not in an appropriate state to execute the operation request. The request can usually be sent again later without any modification. If the error persists, the system administrators must be informed about it. |
Applicable for this service operation |
| Illegal System State | The operation request failed because of a technical error or an unexpected issue. The system administrators must be informed about this error. |
Applicable for this service operation |
Note
This list of errors is not exhaustive.
Troubleshooting
Refer to the SAP CC Error Code Reference (SAP Site) for more information about a returned error code and the corrective actions necessary for troubleshooting your implementation project.
Message Types
Consult the structures of the message types related to this service operation:
Prerequisites
Integration
There is no specific integration information.
Constraints and Integrity Conditions
There is no specific constraint.
Notes on SAP CC Implementation
You must have installed and configured the SAP CC Core Server system.