Analyze Master Data and Price Design in Convergent Charging

CutAbove is a large company that deals with videos in the Cloud. The company receives the cloud platform and physical infrastructure for their work from the O2C Company.

The provider contract for CutAbove was created in Solution Quotation in Subscription Order Management (SOM) and replicated to SAP Convergent Charging. Charge plans and charges for usage fees are assigned to the provider contract in the SAP Convergent Charging view of the provider contract.

CutAbove decides to order the cloud selection service product with the service level Gold. Karen, the O2C Company's billing specialist, is responsible for monitoring the rating and charging process in SAP Convergent Charging.

Let's look at the different variants available with the cloud selection service product:

• With SAP Convergent Charging, service providers can bring innovative pricing offers to market faster than the competition with an intuitive user interface that requires zero coding.
• SAP Convergent Charging supports the True Service convergence to allow any kind of service, current or future, to be defined within the same billing module.
• It provides unlimited flexibility to allow any pricing rule for any service to be modeled through configuration and no coding.
• SAP Convergent Charging has deployment flexibility and scalability according to high volume and high performance for B2C and B2B processes.
• Support Real-time and Batch rating in a single instance to allow true Prepaid/Post paid convergence.
• SAP Convergent Charging can easily integrate with other third party systems, allowing those systems to interact fully with SAP Convergent Charging, and as such use the functionality provided by SAP Convergent Charging in a multitude of ways.
• SAP Convergent Charging exposes all functionality via elaborately documented APIs based on Web-Services Java and XML standards.
• Integration can be via standardized implementation of SAP Convergent Charging APIs using standard technologies such as Web-Services APIs for flexible integration with other web applications.

As a result, SAP Convergent Charging was designed as a modular solution, with a particular emphasis on Pricing & Rating as the key enabler of true flexibility and service convergence. The Price & Rate module can support any kind of service requiring any kind of pricing rule, using simple configuration only. Pricing is not just limited to revenue streams, but cost streams too, as you can use the same tool to calculate revenue and cost algorithms in the same instance and all done in real-time.

Master Data Management

Within the context of Master Data Management, there are several key components related to Price and Charge. They include managing Subscriber Account information, and External Account and Provider Contracts. Also, Access and Partner Provider Contracts are crucial aspects to consider when it comes to SAP Convergent Charging. Furthermore, effective Bill Cycle Management is essential for accurately tracking and processing charges related to the services provided.

Pricing Modeling

In the context of pricing modeling, SAP Convergent Charging includes various elements such as the charge plan, which outlines the pricing structure for different services. Usage charges are also considered, as well as recurring charges which are charged periodically. Dependent charges are calculated based on other charges. Also, Convergent Charging Design functions play a role in determining the pricing model. In this process, Mapping Tables and Range Tables are used to map different pricing parameters. Subscriber Mapping Tables provide a means of identifying specific subscriber-related charges. Finally, Macros are used to automate the pricing process.

Rating and Charging

Under the Rating and Charging topic, there are several methods for determining price and charge. These include online rating, offline (batch) rating, deferred rating, and aggregation sessions. Online rating refers to the immediate determination of charges for services rendered, while offline (batch) rating involves the processing of charges in batches. Deferred rating allows for charges to be determined and processed later, and aggregation sessions involve the combining of multiple services for a single charge.

Re-Rating

Under Re-Rating, the following actions must be taken: Restore the counter and reset the activation date of recurring charges, reverse billable items, compensate billed items, rerate consumption items, and send new priced items.

Partner Price Models and Rating

When it comes to partner agreements, the rating of customer consumption is done according to the terms laid out in the partner agreements. This not only establishes clear guidelines for both parties, but also ensures fairness in pricing. Also, billing and invoicing of partners is done in accordance with the agreed upon price models, allowing for transparency and accuracy in the financial aspects of the partnership.

SAP Convergent Charging is connected to three systems.

1. SAP S/4HANA SOM

Provides the price conditions (for recurring fees) and the provider contracts. One-time fees (for example, activation fees) are sent direct from CRM SOM to SAP Convergent Invoicing.

2. SAP Convergent Mediation by DigitalRoute

The mediation engine is responsible for transforming the data sent by the network infrastructure into records which can be handled and processed by the rating engine. These records must contain all data necessary for rating and charging:

• User ID pointing to the correct (technical) user using the service.
• Service ID pointing to the correct service which was used.
• Consumption date in the right common format.
• Any user-defined properties which are necessary for the rating and charging process.

3. SAP Convergent Invoicing

SAP Convergent Invoicing receives the usage data with a price and assigned to a specific customer account.

SAP Convergent Charging uses recurring charges and usage charges for the creation of subscription-related fees. An access object will only be created if the charge contains a usage rate. Charges with only recurring rates do not have access:

• The UserID is a unique identifier of the subscriber account/provider contract.
• The ServiceID is a unique technical identifier of the service (charge).
• The access is the combination of UserID and Service ID.
• The usage Events can be assigned to the usage charge with help of the access.

A provider contract is made up of at least one or more contract items. Each contract item corresponds to a charge plan which includes the charges. How many contract items (or charge plans) are activated inside a provider contract is defined in the Product Model and the contained Cross-Catalog Mapping in CRM.

Master data objects like Business Partner, Contract Accounts, Subscription contracts, and Products are created once in the BRIM solution and replicated between SAP S/4HANA and SAP Convergent Charging.

Hardware products like the License fee for cloud selection service can be replicated between SAP SOM and Materials Management of SAP S/4HANA.

Similarly, invoice products for rate plans or fees, for example, cloud selection service can be exchanged between these systems.

In addition to that, the following SOM objects can be replicated to FI-CA of SAP S/4HANA and SAP Convergent Charging:

• Business Partner, called subscriber accounts in SAP Convergent Charging.
• Contract Account, called contract accounts in FI-CA and external accounts in SAP Convergent Charging.

The Subscription Contract is replicated uni-directional from SAP SOM to FI-CA of SAP S/4HANA and to SAP Convergent Charging. The contract is sent to the common object layer in FI-CA, from where the contract generation in SAP FI-CA itself but also in SAP Convergent Charging is triggered. Only where the contract can be stored in both systems, the contract is created. Otherwise, there is a rollback in both systems.

The provider contract is replicated to SAP Convergent Charging with all pricing and charging relevant parameters and technical details as there are, for example, counter, technical identifier, and subscriber assigned prices.

On the SAP Convergent Charging site, each provider contract is linked to the corresponding charge plans defined in the Cross Catalog mapping.

Monitoring of Replication from SAP S/4HANA to SAP Convergent Charging can be done with the help of replication reports in SAP S/4HANA FI-CA.

The replication of Provider Contracts is done via ODI and Web Services:

Pricing is the term describing the process of creating the logic that calculates the prices to be charged for the various services to the customers. The logic is created in so called "price plans" which are stored in so called "charges".

Rating is the term which describes the process of actually calculating what the usage of a certain service costs, for instance, how much has to be paid.

Charging is the term which describes the process of determining the account of the customer/person who is paying for the service consumption. The charging logic is stored in the so called "charging plan", a decision tree-based structure similar to price plans.

Explanation of Objects in SAP Convergent Charging:

1. Charge Plans

Charge plans are the building blocks of a commercial offer for the customer and combine charges to meaningful packages. Charge plans transfer Counter, Parameter, and technical objects to charges.

2. Tables

Tables contain the price or other information. There are different table types in place: Mapping Tables and Range Tables. Both are adaptable to subscriber Mapping tables and Subscriber Range tables.

3. Macros

Macros contain reusable logic of price plans.

4. Charge

The Charge is the representation of an amount, which is charged to someone. Convergent Charging uses three types of charges: one-time, recurring charges, and usage charges. A Charge includes two plans:

4.1: Price Plans describe how to calculate the price.

4.2: Charging Plans describe how to determine the account to credit/debit.

5. Chargeable Item Class

The Chargeable Item Class is responsible for the format of data provided by a mediation system, which is to be processed by Convergent Charging.

In the integrated BRIM scenario, the chargeable item class is automatically derived from the consumption item class in SAP Convergent Invoicing during the import of the consumption item mapping. Consumption Items store the unrated incoming data events and allow deferred rating or re-rating.

The Charged Item Class describes the output data format. Billable Items are the rated events, which are processed by SAP Convergent Invoicing into invoices.

6. Billable Item Mapping

Billable Items Class and Charged Item class are mapped via Billable item mapping.

An allowance allows the customer to consume a defined volume (allowance counter) of a service during a defined time. Therefore, the following objects in Convergent Charging are used:

7. Allowance Plan

The allowance plan defines the behavior of an allowance when the charging and refilling processes are executed. The allowance plan consists of:

• One or several allowance logic objects.
• A set of counters linked to the allowance logic objects.
• A set of parameters optionally linked to the allowance logic objects.
• A status which can be open or released.

8. Allowance Logic

The allowance logic performs calculations only when the allowance plan is triggered by:

• Any allowance event.
• A periodic allowance event.
• A one-shot allowance event.
• From the financial view, allowances create deferred revenues in SAP Convergent Invoicing.

A charge in SAP Convergent Charging is a unique price determination logic. It is described as a tree structure called price plan and has a dedicated set of charging rules. These rules are also set up in a tree structure called a charging plan.

A charge generates an amount that must be used to either debit or credit a client or partner. It can be either a master or dependent charge and is included in a charge plan. The following figure shows a charge from the Convergent Charging system.

Each charge contains a price plan and a charging plan. The charging plan determines the account to debit or credit.

As previously shown, the price plan represents the business logic used to compute an amount. It is made up of rating components. Users configure the rating components into a "Decision Tree" that SAP Convergent Charging Core Server uses to determine the price for a particular usage, recurring or one-shot rate.

There are three main steps involved in designing a price plan. The steps are:

1. Analyze your business price determination logic to find out:
   • Variables and constants,
   • Branches in the logic (If…Then…Else…),
   • Reasons to rate the same event several times with different logic,
   • Any needed non-price calculations,
   • How the actual price is determined,
   • If tables are needed,
   • If the same logic is used to rate multiple charges,
   • Map the logic in the AUI.
2. Map the logic in the AUI.
3. Test the logic for correctness.

A price plan is graphically represented by a tree structure called a rating tree. A price plan component represents each instruction inside a price plan. A rating tree is a decision tree that contains the price plan. This structure consists of a root from which rate components create branches. At the ends of each branch, a Function component describes an amount.

The components of a rating tree are grouped into five families depending on their main function:

Rates

Rate components always begin the main branches of a rating tree. Rates define the rating type (Usage, Recurring, or One-Shot) and are always at the root of the decision tree.

Note

Unavailable in a pricing macro.

Comparator

Comparators help to calculate a rate. Its function is to generate two or more branches in order to evaluate properties. Selects one branch according to the result. It is located in the middle area of the decision tree, after Rates and before Functions as previously shown.

Splitters

Splitters help to calculate a rate. Its function is to split a number or duration. Splitters generates and rates multiple branches. They are located in the middle area of the decision tree, after Rates and before Functions.

Operators

Operators help to calculate a rate. Its function is that it adds properties to the calculation context. They are located in the middle area of the decision tree, after Rates and before Functions.

Functions

Function components end each branch of a rating tree with a final calculated amount. They calculates the final amount and are always found at the end of the branches. Functions are the leaves of the tree.