Charging Contract

business object

Definition

A charging contract is the pricing and charging view of a provider contract stored in SAP Convergent Charging. This master data relates to a long-term business relationships between an end customer of a marketable service and the service provider.

Technical Data

Software Product and Version	SAP Convergent Charging 4.1
Technical Details	Data Types
Version	2
Application Area	IS-CC

Business Context and Use

A charging contract is a long-term agreement between a service provider and an end customer based on specific terms that have been negotiated beforehand which defines how and how much the customer shall be charged:

• To have access to marketable services or goods
• To consume these goods or services (usage pricing)

In order to access to goods or services, the customer shall be charged:

• Once during time: These are one-off prices
• Recurrently: These are periodic prices

In order to consume goods or services, the customer shall be charged:

• Once per consumption
• Recurrently, for all the consumptions made during a time period

The charging contract also defines what modifications in the customer basic charging definition are applied when accessing and consuming goods or services. The modification in the customer basic charging definition can be:

• Price redefinition
• Price discount or surcharge
• Charging redefinition
• Condition redefinition for price computation and charging

The modifications may depend on the customer context and the way the customer consumes the goods and services. The modifications can impact:

• The customer charging definition only:
  • The price to access and/or consume more goods and/or services is reduced
  • The price to access and/or consume more goods and/or services is increased
  • For the same price, more goods and/or services can be consumed
  • For the same price, less goods and/or services can be consumed
• The customer economic environment, such as:
  • An extra charge, which is a remuneration, i.e. the payment of commission to another entity of the economic environment, such as another customer
  • A split charge, which is a sponsorship, i.e. the splitting of the payment between the customer and another entity of the economic environment, such as another customer.

A charging contract also defines how a customer shall technically access to good and services thanks to the definition of user service identifiers, and which accounts shall be charged for this consumption, thanks to account assignments. These accounts are the one defined in the related subscriber account.

Order Capture and Contract Management

A CRM application or another provisioning system manages master data related to the order capture and contract management and replicates data in SAP CC by maintaining subscriber data for end customers. Data includes: Charging contracts (provider contracts) , subscriber mapping tables , subscriber range tables .

Related Operations

You can use the following operations to perform actions on charging contracts.

• Create or change a charging contract
• Create or change charging contracts in bundle mode
• Create or change charging contracts in mass mode
• Find charging contracts
• Cancel a charging contract

Related Process Components

• Customer Master Data (Business Partner Management): Charging Contract Management
• Customer Master Data (Business Agreement Management): Subscriber Account Management
• Data Migration (Order Capture and Contract Management): Charging Contract State Management

Features

This customer master data represents a business agreement between the customer service provider and an end customer or a subscriber.

Life Cycle and Revision

A charging contract evolves over time and several versions exist for different periods of time. These versions (called revisions) are automatically managed by the SAP CC system when maintaining this master data.

Structure

A charging contract is defined by:

• An identifier which is unique in SAP Convergent Charging (mandatory)
• The identifier of its related subscriber account; Mandatory for:
  • Parent contracts
  • Single contracts that are not linked to a parent contract
• The identifier of the parent charging contract (optional and only relevant for a charging contract linked to a parent charging contract to reuse a pool of counters)
• Some additional information (optional)
• Some items that are activations of a defined charge plan class, refill plan class or monitoring plan class

Contract Item

A charging contract contains at most one item that activates a refill plan and at least one item that activates a charge plan. A charging contract item is defined by:

• A charge plan class identifier, a refill plan class identifier or monitoring plan class identifier (mandatory)
• An identifier which is unique within the charging contract (mandatory)
• An external identifier which is not unique within the charging contract (optional)
• A set of validity periods that specify:
  • A start date: The validity start date of the considered period, which is inclusive
  • An end date: The validity end date of the considered period, which is exclusive
  A one shot of type activation will be internally triggered and charged at start date if the validity period is the first validity period, otherwise a one shot of type resumption will be internally triggered and charged. A one shot of type suspension will be internally triggered and charged at end date. A Chargeable item can only be charged when its consumption date is included in a validity period. The validity periods are not necessary subsequent.
• A set of configuration periods that specify:
  • A start date: The configuration start date of the considered period
  • An end date: The configuration end date of the considered period
  • A set of parameters: Each parameter defined in a charge plan class, refill plan class or monitoring plan class can be redefined in a charging contract item. If your pricing modeling is based on business data tables defined in the pricing catalog of the service provider (mapping tables or range tables) or defined in the customer master data (subscriber mapping tables or subscriber range tables), a contract item can include a string parameter set to the ID of such a business data table.
  • A set of shared counter(s): Each counter defined in a charge plan class or refill plan class can be shared. The sharing can be influenced by the definition of the namespace. Name and namespace identifiers of a shared counter define a unique counter of the charging contract.
  • A set of pooled counter(s) in a parent contract: Each counter defined in a charge plan class or refill plan class can be shared. The sharing can be influenced by the definition of the namespace. Name and namespace identifiers of a shared counter define a unique counter of the charging contract.
  • A set of account(s): Each expected account assignment defined in a charge plan class or refill plan class must be set to one account defined in subscriber account.
  • A set of user service identifiers (USIDs): Each user technical identifier defined in a charge plan class or refill plan class can be set by one or several user service identifier(s). A user service identifier is a technical key that uniquely pinpoints the user (end customer) inside the customer service. For example an e-mail address, a phone number, the IMSI or the MSISDN.
  The configuration periods are not necessary subsequent.

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 system landscape, you must configure the systems and the data (master data, business data).

Additional Information

Consult the SAP CC Application Help for more information about:

• The provider contract in master data
• The provisioning process to configure customer master data