Describing the Structure of a Charge

As a pricing manager it is your job to design a charge for the pricing of the subscription to the Cloud Selection Service monthly fee.

A charge represents a cost and a charging pattern linked to one or several customer services. The cost is described in a calculation algorithm and configured in the price plan within the charge, while the charging pattern is described in the charging plan. The charge is the object, that creates an output transaction (called a "charged item"), that is billed to a customer. Any charge can create a maximum of one charged item.

A charge:

• Calculates an amount, which can be linked to no, one or many chargeable item classes.
• Contains a unique price determination logic described in a tree structure called "price plan".
• Contains also a dedicated set of charging rules as a tree structured "charging plan".
• Generates an amount, that must be used to either debit or credit a customer or partner.
• Creates no charged item or one charged item.
• Can be either of the type "master" or "dependent" charge.

A charge calculates an amount that can be linked to no, one, or many chargeable item classes and this charge contains a unique price determination logic described in a tree structure referred to as "price plan." Furthermore, the charge also holds a dedicated set of charging rules depicted as a tree-structured "charging plan." It also generates an amount that must be used to either debit or credit a customer or partner, while it creates either no charged item or one charged item. Finally, a charge can be classified as either a "master" or "dependent" type of charge.

A charging business scenario consists of two stages:

1. Rating process (aka dynamic pricing)
2. Charging process (determination of invoice recipient)

For example, when an end customer consumes a usage-based service to monetize, the rating process dynamically calculates a priced amount while the charging process defines which account will be charged with the amount.

A charge allows you to configure this charging business scenario through a decision tree made up of two parts:

• The price plan that specifies the steps to execute by SAP Convergent Charging to determine the amount to charge. Additional information can also be determined as needed.
• The charging plan contains all steps to execute by SAP Convergent Charging to determine the external account to which the amount is charged.

On the right of the screen the charge has a set of tabs, that give access to several configuration settings. Lets start with the definition tab first.

On the Definition tab each charge must be assigned to one of two types:

• Master
• Dependent

Let’s find out what these types define.

When charging for services, the fee charged to the customer can be made up of several components. In SAP Convergent Charging each component would usually be calculated by a separate charge:

Icon	Explanation
	A base fee associated for every individual service usage
	A time based charge based on the duration of the usage
	A surcharge applied for certain premium functions provided
	A discount applied based on certain circumstances

When SAP Convergent Charging processes a chargeable item, it needs to identify exactly one charge, that is used to process the chargeable item first. These charges are called "master charges". In the examples given above, this charge could be responsible for the base fee associated for every service usage. When placing a phone call, this could be a connection fee, which is charged when a connection is established to the person that was called.

If this master charge is done with its calculations and additional fees need to be calculated, the chargeable item can be handed to additional charges afterwards. These additional charges are called "dependent charges". In the example above such a dependent charge could calculate the time-based fees for the call.

Sometimes discounts must be applied to fees. Often these fees are calculated as a percentage from a base fee.

In the example given above, a discount of 10% could be granted to the time-based fee for the phone call. The amount calculated by the previous charge is always handed to the dependent charge, so that it can be used there for further calculations.

Dependencies can be organized in snowflake-like structures. The following rules apply:

• A dependent charge must be linked to exactly one charge it depends on.
• A master or dependent charge can be referenced by no, one or many charges depending on it.
• Dependency relationships can be cascaded. There can be many levels of dependencies.

Let’s summarize: You need to set your charge to the type Master when it is the first in the line of charges to process the chargeable items. When your charge is planned to be one of the subsequent charges, that depends on another charge doing its job first, your charge needs to be assigned to the type Dependent. It is as simple as that. Please note, that this setting cannot be changed once your charge is saved to the database.

When you set up a charge with its calculation logic two things can happen:

1. You plan to create one charge for all currencies you charge in. In that case your charge needs to be able to deal with any currency you throw at it.
2. Your charge will certainly be dealing with fees associated to one specific currency only.

SAP Convergent Charging allows to assign a "Fixed Currency" to a charge. If you need more flexibility though, you can set the charge to support "Multicurrency". In the latter case a parameter called "currency" will be created automatically for you. You can then use that parameter to set the charges currency later.

In SAP Convergent Charging, reusing components is key to a sound design. You don’t want to create the same logic with a lot of redundancies repeatedly. This would increase the maintenance and development efforts and subsequently increase costs. To keep your charge logics flexible the concept of parameters has been introduced.

A parameter serves as a placeholder for a value and is designated to one of the three data types: number, string, or date. It will be provided with a value at a later stage, a value that can be read by the charge but cannot be altered by it. Additionally, the parameter has a visibility setting that ensures its visibility is limited solely to the price plan logic, and it is not discernable to other objects such as the charge plan. The primary function of a parameter is to allow the price plan logic to be configurable, thereby enhancing the flexibility of the charges.

The values for these parameters can be defined at later points in time. This can be when the charge is used in a charge plan (covered later in this course) or when the provider contract is created. The key aspect is that for different contracts or different charge plans the charge parameter can be provided with a different value. This allows to configure your charge. The price plan logic can read (but not write) the parameter value and act accordingly.

In the charge shown above, a parameter "SLA" was introduced to allow the selection of a specific service level agreement. The charge’s price plan can then use this SLA parameter value to determine the correct price to charge for the service usage within the selected service level.

Parameters must be assigned a visibility setting. This setting can either be "Internal" or "External". It controls whether the parameter can be "seen" by other objects like the charge plan (covered later in this course) or only by the charges price plan.

Counters are there to – you might have guessed it – count things. Price calculation rules often do contain thresholds, price tiers or similar complexities. Whenever your logic forces you to keep track of quantities over a certain period of time, counters can be used.

Let’s have a look at a counters definition.

Counters:

• Are placeholders for values, that can change at runtime.
• Are always of type number.
• Have a name.
• Have a value they are initialized with.
• Come in two flavors: "Persistent" and "Transient".

Let’s first have a look at the difference between persistent and transient counters.

Transient counters do not store their values in the database of SAP Convergent Charging. Their values will be lost when SAP Convergent Charging is shut down and started again. They are also lost between the processing of two separate chargeable items, which is even more important. Usually, transient counters are used to keep track of quantities within so called "rating sessions". Session based rating is not covered in this course. Think of sessions as a service usage, that continues over time, for which you want to charge as the consumption happens and goes on.

Often the usage of a service can only be charged when the service consumption has ended, and the properties of the consumption are therefore clear. When you want to charge as the service is continuously consumed, this comes with a set of challenges.

The figure above shows a transient counter within a charge. Note though, that the counter shown was added to one of the exercise objects as an example. It does not make sense there, as no session-based rating is covered in this course.

Persistent counters store their values to the database of SAP Convergent Charging. They are the most common type to use in business scenarios, where service usage is collected and billed periodically.

Persistent counters are expensive from a runtime perspective. Each time the counter is written the data must be passed to the database. The charging process must wait for the database to confirm the operation before the charge can deal with the net chargeable item. This can impact rating performance significantly. Therefore, counters should be used with care and only in cases where they are necessary. The following graphic illustrates the performance impact counters can have on rating throughput.

When setting up counters within a charge, the location to do that depends on its type. While persistent counters have their own tab at the root level of the charges tree, transient counters are set up by selecting the price plan in the charge’s tree structure.

When you create new catalog objects in SAP Convergent Charging like charges, tables, macros and so on, then the system will take a while to inform all system components about these new objects. A distribution mechanism will make sure that from time to time all components receive an update of all objects. As long as this process is not started and successfully finished, a new charge or table will not be available to all raters. This can lead to error messages, when the new objects are supposed to be used by other new objects.

As you probably do not want to wait for the distribution process to finish, it is possible to trigger the process manually. This way you can make sure all objects are well known by all system components before you put your new objects to a test. Otherwise, you might run into error message, as creating a new contract using a certain mapping table will fail, if the table is not yet known by the raters involved. Don’t worry that some of the terms mentioned are not known to you yet. This is explained during the course.

To trigger the distribution mechanism from the Core Tool choose Tools → Refresh Rating Instances.

The system will ask you for a confirmation. Choose "Yes" and you will receive a message, that all rating instances have been refreshed. After that you can safely assume your new objects are known by all system components.