Find Information on the Feasibility of the Recharging

Service Operation (WS)

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 2025
Technical Details chargingContractRechargingFeasibilityInfoFind
Namespace http://recharging.v2.ws.highdeal.com/
Proxy Instance in SAP CC System Dispatcher
Service Operation Version 2
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:

  • Possible when the recharging date is the date of a restoration point of the charging contract or if the recharging date is before the first restoration point of the charging contract
  • Possible but the recharging date must be adapted in the past to be the date of the first older restoration point compared to the recharging date.
  • Not possible until the oldest of restoration point when the date is older than the counter snapshot retention period. In that case the relevant restoration point has been already deleted and the charging contract could not be reset.
  • Not possible when the charging contract cannot be reset and no better date can be provided.

It is the version 2 of the Web Service (WS) operation. It replaces the former versions.

Important

This is the latest version of this service operation. It replaces the previous versions: version 1 and version 0.

With the version 1, decimal numbers are no longer restricted to the (28,6) precision. For decimal numbers stored in the database, the precision is limited to the precision supported by the database.

With this version 2, the scope of the recharging is extended to support the charging contracts that belong to a sharing group and that use shared allowances.

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 (SAP CC) 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 SAP CC system landscape:

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 such as SAP Convergent Invoicing

Rerating Scenario for Contracts Using Shared Allowances Within a Sharing Group

As of the version 2 of the Recharging web service, the WS operations are enhanced to support the recharging step for charging contracts that use shared allowances within a sharing group. This version provides you with this new scenario of rerating to implement in your SAP CC system landscape.

To be able to rerate all the charging contracts that belong to the same sharing group and that use shared allowances created by the contributor contract, you implement the following operations:

  • Find the charging contracts belonging to a given sharing group and that must be recharged together as dependent charging contracts
  • Lock the related charging contracts belonging to the sharing group
  • Find information on the feasibility of the recharging for charging contracts belonging to the sharing group at a given date/time
  • Prepare the execution of the recharging process by purging the remaining item files
  • Find the restoration points for all the related charging contracts belonging to the sharing group
  • Check the reversibility of the billable items (BITs) related to all the charging contracts to rerate (belonging to the sharing group)
  • Restore the related charging contracts at a common date/time corresponding to one of their restoration points
  • Reverse the BITs related to all the charging contracts to rerate (belonging to the sharing group)
  • Retrieve all consumption items issued from the charging contracts belonging to the sharing group
  • Recharge all the collected consumption items ordered by ascending dates/times (oldest to newest) to ensure consistency in counter values
  • Unlock all the related charging contracts belonging to the sharing group

The operations for checking the reversibility of BITs and for reversing BITs are not part of SAP CC Web Services.

Important

Refer to the SAP CC Application Help for more information about the rerating feature, its detailed process, and technical functions/mechanisms. Consult the counter snapshot management (storage, creation, and triggering within a sharing group) feature.

Review the prerequisites, conditions of use, limitations, and recommendations for implementing this rerating scenario for contracts that use shared allowances within a sharing group.

Rerating is not possible for charging contracts using shared allowances outside of any sharing group.

When consumption items to recharge are not ordered by ascending consumption dates/times (oldest to newest), the processing may lead to inconsistencies in counter values.

Related Service Operations

You can also use the following operations to restore charging contract:

Features

The feasibility of the recharging of chargeable items for a specified charging contract and for a specified recharging date is described with the following information in the operation response:

  • A status indicating the feasibility of the recharging for the charging contract. The status can be:
    • possible: The recharging is possible at the requested recharging date.
    • possibleAt: The recharging is possible but must start before the requested recharging date.
    • notPossibleUntil: The recharging is not possible until a date after the requested recharging date.
    • notPossible: The recharging is not possible.
  • The requested recharging date: The date on which the feasibility of the recharging has been checked.
  • The possible recharging date:

    The date when the recharging is really possible in SAP CC. This date is computed from the requested recharging date. If the recharging is really not possible then the possible recharging date is empty.

  • A restoration point that contains the following information:
    • The identifier of the restoration point (a date, which can be used in the operations which restore the state of charging contracts)
    • The identifier of the related charging contract
    • The range of charged item set unique identifiers
    • The consumption date of the oldest consumption item charged on the restoration point
    • The list of external accounts of the charging contract

    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

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.

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
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).

Sample #2
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 months 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 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. 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 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. 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 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. 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

The expected behavior of the consumer according to this operation result would be the following:
      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
    

Authorizations

To know the role that is expected in the user profile of the SAP CC user specified in your request messages, refer to the SAP CC Security Guide of SAP Convergent Charging.

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:

  • The subscriber account specified does not exist
  • The subscriber account specified does not have associated charging contracts
  • The charging contract specified does not exist
  • The charging contract specified does not belong to the subscriber account specified

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:

  • No subscriber account identifier was specified in the request

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:

  • The recharging feature is deactivated

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 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 of SAP CC:

Prerequisites

  • The relevant subscriber account exists
  • The relevant charging contract exists
  • The relevant charging contract belongs to the subscriber account

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.

Configuration

Consult the SAP CC Configuration and Implementation Guide to know the necessary configuration or Customizing of the SAP CC system.

Before implementing SAP Convergent Charging in your SAP system landscape, you must configure the systems and the data (master data, business data).