SAP BRIM Introduction

SAP Billing Revenue Innovation Management or simply SAP BRIM is a solution

that is build for telcos and utilities industry.
Just think of your mobile phone carrier. How do they know you have used up 2GB
of your broadband quota? SAP BRIM. How do they know that you have exceeded
your monthly credit limit? SAP BRIM.
The solution roadmap below shows the component of SAP BRIM with Offer-toCash (O2C) being the end to end solution.

For the next coming chapter Ill start by showing the configuration of SAP
Convergent Charging (SAP CC 3.0). Since you are a mobile subscriber lets use
that as an example to showcase what SAP CC does and does not do.
So lets start,..
(At the time of this writing, SAP have released SAP CC version 4.0. The
configuration of SAP CC 4.0 is relatively still the same as SAP CC 3.0. Please refer
to the SAP official page for the release update. )

1. SAP CC Introduction
Two words, Rating and Charging. Thats what SAP Convergent Charging is all
about.
Rating refers to all the calculation mechanism of coming up with the total bill
amount.
While, Charging refers to which account that will be charged against for a
particular customer. For example, other than your mobile phone, you might also
subscribe to a supplementary line, or you have another internet broadband
account with the same company. Notice that they come in with separate bills and
have different account id or account number! The Charging process will know
which services you use and selects the correct account to charge you with.
These two terms are heavily used in all the SAP CC documentations. So, better
get the terms right!
So the next question you might ask is how it looks like?

Yes, apparently this is how it looks like. Once the installation is done, the
sapmmc console is used to start the SAP CC server instances.
Luckily, SAP CC comes with a tool that provides the interface for configuration.
The tool is called Core Tool and in a standard installation, it is saved in the
directory below.

Just double click on the core_tool.bat and voil!

The instructor will provide you with the Log On id and Password if you are lucky
enough to enroll for the SAP CC training. But even if you dont have the system,
this website will provide you with all the step by step screenshots.
Note that there is a big difference in architecture here compared to the normal
SAP configuration. If you are familiar with SAP implementation guide on
transaction SPRO, and have accessed the SAP GUI before, you will notice that
multiple users can gain access to the SAP system and one time and multiple
configuration can be done by different user at the same time.
Well, for SAP CC, thats all not gonna happen. One user only!. And the whole
configuration interface will not look like your favourite SPRO. In fact, you should
not be comparing SAP CC to SAP ECC or SAP CRM configuration at all. Because,..

..,this is your so called SAP CC spro or correctly termed as the core tool.
For the coming next chapter, mostly all of the configuration will be done using
this tool.

2. SAP CC Components
So far, you have understood that the main functionality of SAP CC is to
providerating and charging .
We can simply say that the SAP Convergent Charging resembles a pricing
instrument.
As we have seen in the first chapter, SAP CC is not a standalone solution. It must
be interfaced with several external systems such as SAP ECC and SAP CRM to
perform its key rating and charging functions. For now, lets just accept this fact.
You will see the integration point much later to solve the overall jigsaw puzzle.
SAP CC is made up of 4 main servers:

Core Server

BART Server

Diameter Server

Communications Taxing Server

In Chapter 1 you have seen the SAP CC server instances.

For now, just go through the table list below for the summary details of the
overall SAP CC 4.0 Software Components.
However, our primary focus is still on the Core Tool.

The diagram below shows the integration overview in SAP CC.

Another important term used by SAP CC is Mediation. What this refers to is the
raw network data that your carrier uses to quantify your call, sms and internet
services. This raw data is also referred to as Consumption Detail Record
(CDR).
It contains information like your phone number, the number you are dialing out
to, start of call timestamp, end of call timestamp, duration, account number or
contract number etc.

This information is used for the upstream business-critical systems like billing,
reporting and analytics.
When you call someone on your phone, SAP CC uses the Online Mediation to
monitor your usage in real time.
For prepaid example, SAP CC can:
1. Control services and manage prepaid balances in real time by checking
balances before delivering services to the end customer
2. Notify the customer when a balance threshold is reached
3. Terminate the service session when the balance is depleted

3. Pricing Concept Overview

Now lets establish the pricing concept of SAP CC.
The diagram below shows the pricing objects that exist in SAP CC.
SAP calls them just Objects, but lets call them Pricing Objects to be precise.

(Note: Chargeable Item Class is not the same as Charged Item Class)

Getting back to our mobile phone example, when your carrier initially sets up the
SAP CC system, they need to first create the Chargeable Item Package (CIP).
This is to generally represent the service package. We can name the CIP object
as [T01]Mobile Telephony.
In this service package, your carrier may include call, sms, mms (i think this is
now obsolete), 3G or LTE broadband plans. In SAP CC this will be represented
by Chargeable Item Class (CIC).
Next we come to the pricing object Charge. This is where the whole pricing is
formulated. It contains Charging Plan which determines the account to be
charged. It also holds the information such as postpaid and prepaid account
type. Charge also contains Price Plan, which is the brain of the pricing
calculation. It is the rating component. This is where rates are being keyed in,
whether you will be charged a monthly flat rate or according to your usage
consumption for example. To simplify the Charge concept, we can group it as
Connection Charge, Equipment Rental, Commission, Calls, SMS, Installation etc.
A Charge Plan, is the object that exposes the SAP CC pricing objects to
provisioning system such as SAP CRM. Think of it as your carrier mobile phone
plans. For example a SmartPlanA gives you 60 minutes of free local calls, 500
sms and 2GB of internet data at a fix monthly rate of $100. SmartPlanA is
represented by the Charge Plan, while the rest of the statement is represented
by the Charge object.
Charge Plan contains two objects. First, is the Charged Item Class where we
define the output format of the rating and charging process. The result of the
rating and charging process is either called a Billable Item or a Consumption
Item. This information is feed to the SAP Convergent Invoicing (SAP CI) for the
billing process. The second object in the Charge Plan is the Technical Data. The
set of Technical Data is made of a Service Identifier and a User Technical
Identifier. For now, lets just agree that the Technical Data allows SAP CC to
retrieve the correct Provider Contract. The why and how will be explain later in
the following chapter.
Note: SAP Customer Relationship Management (CRM) handles the sales order or
service contract creation. It is not compulsory to use it with SAP CC. You can
directly feed the information to SAP CC but for our example, lets use SAP CRM as
the provisioning system.
Now that you have understood the Pricing Concept in SAP CC, lets take a
detailed look at each of the Pricing Objects and how it is created in the system.

4. Catalog
All the objects (pricing objects) in SAP CC must be saved to a specific Catalog.
Hence, we must first start by creating a Catalog.
Execute and Log into the Core Tool.

Chose File->New->Catalog

Name the Owner as T01.

Your catalog structure is shown in the screenshot below.

5. Chargeable Item Package (CIP)

CIP, as I have mentioned earlier, represents a service package.
Other details that we must remember about CIP are:

Is a container to hold Chargeable Item Classes

Belongs to a service provider

Is the first step of building Charge Plans

Is mandatory to reference at least one CIP in a Charge

Choose File->New->Chargeable Item Package

Name is as [T01] Mobile Telephony

6. Chargeable Item Class (CIC)

The CIC is actually created within the CIP.
The things that we need to know about CIC are:

Represents service types that can be consumed (calls, sms, data)

Includes details about the use of the service: consumption data

Is not mandatory if there no usage on the Chargeable Item Package

Unlimited number of CIC per Chargeable Item Package

The cardinality is one CIP can have one or more CICs.

Highlight the CIP, Click the Add Chargeable Item Class button on the top left as
shown below.

Notice that user properties node and default properties node are created
automatically.
Consumption Date, User Identifier and Service Identifier are mandatory
properties!

Name the CIC [T01] Cal.

Highlight the User Properties.

Click the Add Properties button and add the following properties:

Number dialed of type String

Calling number of type String

Duration of type Number with the Description in minutes

Add another CIC to your CIP named [T01] SMS with no user properties

In the menu bar, select File->Save->In the Database, choose the Owner of
your catalog T01 and click on Save.

Congratulations! You have just created your first Object in SAP CC.

But what exactly did you create?

Your carrier operator offers mobile plans to consumers. <- Represented by the
CIP
The consumer can sign up to Call and optionally SMS services. <- Represented
by the CIC
When the Consumer gives a call, SAP CC receives a chargeable item with a
given format including the number dialed, the calling number and the duration of
the call. In the same way, when this Consumer sends an SMS message, SAP CC
receives a chargeable item with another format. <- Represented by the user
properties and default properties

Now we can continue with the next object.

7. Charge
Charge is where the rating and charging process occurs.
Charge contains two main objects. When we create a Charge, in the Decision
Tree structure, you will see the Charging Plan and the Price Plan.
Charging Plan handles the charging process. While Price Plan contains the pricing
logic and calculation algorithm in the rating process. In the illustration below,
there are other objects that exist within the Charge that is essential to provide
the rating and charging process. However, lets just focus on the Charge for now.

To create a new Charge, at the Core Tool click File->New->Charge

Choose the Owner of your catalog, select the [T01] Mobile Telephony
chargeable item package, click on Add selected and then on Create.
Note: The Charge must be linked to a CIP.

At the new Charge, you can observe on the tree structure, there are two main
branches. At the top is the Charging Plan. The one below without any description
is the Price Plan.
As a Name of your charge, enter [T01] Mobile Recurring Charge.

At the definition tab of the Charge, there are 4 main settings that you can make.
First, determine if the Charge is a Master Charge or a Dependent Charge. A
Call, SMS or Data Charges are usually the Master Charge. A Commission Charge
is an example of a Dependent Charge.
Note: To trigger the Dependent Charge from the Master Charge, the Dependent
Charge must have the same rating type (either Usage Base, Occurrence or One
Shot rate) as the Master Charge.
Second, set the currency definition.
Third, you can add the persistence counter.
Forth, is the CIP information of the Charge.

The Parameters tab allows you to create variables that can be used to hold
information.

8. Price Plan (Part 1)

We continue from the previous Chapter by creating the Price Plan.
Select the node which has no label and, as a Name, enter Price Plan. In all the
tutorials, whenever we create a Price Plan, just give it the same name Price
Plan.

Before we go any further, you need to know the Price Plan Components in
order to design the calculation logic of the Charge. The Price Plan Components
terminology can be compared to the operators (such as the add, subtract or
multiply) on your calculator.
Lets take a look what are the existing operators in the Price Plan Components.
Then, we will finish off the Price Plan configuration.

9. Price Plan Components

Price Plan Components may be used in two different places as you can see in the
diagram below. At the Charging Plan Object, the Plan Components is used to
formulate the logic to identify the correct charging accounts. However, Functions
and Splitters are not allowed! Functions and Splitters component are discussed
below.
At the Price Plan, it is used to calculate the rates that will result as the total
billing amount.

Price Plan Components consist of 5 groups

We always start by creating the Rates and always always always end with
theFunctions. In between we can utilize
the Comparators, Splitters and Operators.
The Comparators, Splitters and Operators helps you to create your IF
THENELSE statements more easily. We will not use all of these components. In
fact, in our tutorials we will only use Prefix Switching, Counter, Table
Operator,Numbers (comparators), Output Property Update (Operators)
and Macro Operator.
The Rates are simply there to differentiate whether to charge a customer base on
his usage (usage rate), or a fix periodic charge (recurring rate) or a one time fee
(one shot rate). Your call charges will fall under the usage rate. Your data
charges will fall under the recurring rate. And lastly, your termination fee will
fall under theone shot rate. Remember, you must always start by creating the
Rates.
Also, I have mentioned that the Price Plan calculation logic must always always
always ends with a Functions. Functions holds the formula to calculate the
charges. For now, please familiarize yourself with the definition of each of the
Functions below.
1) Flat function

Computes a fixed amount

Example: $5.40

2) Linear function

Computes a price with a variable value (ax + b)

Example: $ 0.40 x (number of pages) + $ 1.00

3) Generic function

Computes a price with a more generic formula such as (axy + b) or (ax +

by +c)

Example: $0.25 x (number of person) x (duration of call) + $1.00

4) Polynomial function

Computes a sum of amounts

Example: $100 x ((number of person) x (duration of call) + ($ 45 x (QoS) x

distance )

5) Free

No price is computed

No transaction is produced by the rating engine.

No record is saved in the billing engine.

6) No access

No price is computed, an exception is returned by Price & Rate rating

engine.

It is possible to choose the properties sent back, and the error message.

It is not recommended to use this in a recurring or one shot rate

(background process).

7) Macro function

This component loads an external pricing rule in order to compute a

price (operates like a subroutine).

A pricing macro is a part of a tree.

This concept allows reusable rating libraries to be built and used

across several price plans.

In an unrelated note: In order to remember all the Functions, try the method
below. Take the first letter of each of the Functions. Rearrange them to
something that makes sense to you.
MNG FLFP
I personally can recall images better. So when I want to remember all the
Functions, all I need to picture is MNGs Flip-Flops.
Now we can continue completing our Price Plan configuration.

10. Price Plan (Part 2)

Highlight the Price Plan node.

Right click, Add Component->Rates->Recurring Rate

Call the Recurring Rate Monthly Fee which is to be triggered on the 1st of every
month, at the beginning of the month.

There is also an Advanced setting which we will not use.

Highlight the Monthly Free node and add a Flat function component to the new
branch of the price plan called 30 EUR and set the Fixed Amount to 30.

You may realize in the screenshot below, the fixed amount is in TWD currency.
Now where did this came from? It came from the Charge! Go ahead and change
the description to 30 TWD instead. Please pardon the mistake on the
screenshots.

We are done with the Price Plan. The logic tells us that the customer will be
charge 30 EUR, excuse me, 30 TWD every 1st day of the Month.
However, the Charge Object still cannot be saved. We have so far created the
pricing logic for the rating process, but we have not specified the account to
charge against for the charging process. Remember that the Charge Object is
responsible for both Rating and Charging? We configure the Charging process at
the Charging Plan object in the next chapter.
You may still have difficulties in remembering the objects. Why not open
thePricing Object Overview Diagram in another window and refer to it to make
sure we are always on the same page.

11. Charging Plan

When we create the Charge Object, two main Nodes are created automatically.
The top node is called the Charging Plan and it has a subnode called Default
Charging.
On the tree structure, click the Charging Plan Node.

Add a Charging Reference Name of type Postpaid called Default to the

Internal Reference Dictionary.

Then, under the Default Charging branch, add an Internal Reference component
called Default Reference, using the Default reference you have just created.
Right Click on the Default Charging->Add Component->References->Internal
Reference

Give the name as Default Reference. Under the Internal Reference Drop Down
List (DDL), choose Default. This value comes from the Internal Reference
Dictionary at the Charging Plan definition.

Lets map the configuration that we have done above with our telco example.
Lets say you only have one postpaid mobile plan with the carrier operator. The
account number is 138888. At the Charging Plan, instead of adding the
Default in the Internal Reference Dictionary, you enter 138888 with the type
Postpaid.
Under the Default Reference node (subnode of the Default Charging), you will
see the account number 138888 value under the DDL.
This account number will then be supplied to the billing processes for invoicing.
So there you have it. Charge Plan is responsible for determining the account to
be charged.
Now save the Charge.
Select File->Save->In the Database

Choose the owner T01 and the Catalog T01. Click Save.

Voil!

The diagram below shows the objects that have been created thus far.

12. Counters
In our previous tutorials, you may have come by or seen the counter settings.
There are two places where you can find the counter setting.
First is at the Charge object definition. This counter is called Persistent
Counter.

The second counter setting is located at the Definition of the Price Plan. This
counter is called the Transient Counter.

Transient Counter:

values are created and reset during a single rating session

values cannot be stored for use in subsequent rating session

values can be passed from master to dependent charges (must have same
name)

Persistent Counter: (e.g. free_minutes, minutes_used)

Can be set to a specific value

Can be reset to its initial value or modified arithmetically.

Can be shared across several charges when building the charge plan

Can be redefined at charge plan creation

Can be redefined at contract creation time

13. Parameters
The Parameters setting can be found at the Charge object definition.

A parameter is a constant that :

Introduces a new property available for rating

Can be a string, number or date

Has a name and a default value

Can be shared across several charges when building the charge plans

Can be redefined at charge plan creation

Can be redefined at contract creation time, enabling a la carte price

plans

The screenshot below shows the Parameter settings.

14. Prefix Switching

Lets implement the scenario below.
You want to create a charge for the pricing of usage events related
to the Call service. The price depends on the called number prefix and is defined
as follows:
Number Prefix
+33
+61
+1
Other

Rate per Minute

0.15TWD
0.50TWD
0.40TWD
0.20TWD

(Number Prefix can be equivalent to the country code)

For this we will use one of the Price Plan Components Prefix Switching
(comparators).
Create a new Charge object. File->New->Charge

Choose the CIP [T01] Mobile Telephony. Click Add Selected then Create.

Fill in the details as shown below. Its quite similar to the previous tutorial really.

Add a Persistent Counter called Minutes used with an Initial Value of 0.

Select the node which has no label and, as a Name, enter Price Plan.

In the price plan, add a new Usage Rate component called Call Usage Rate for
the [T01] Call Chargeable Item Class.

Add a Prefix Switching component called Destination check. As a Property

Name, choose Number dialed and add in 3 prefixes: +33, +61, +1.

Some of the Property in the DDL comes from the CIC.

For this tutorial, I have obliviously added an empty line above the +33 prefix.
Later on you will see an error when we try to verify the Charge.

Underneath the +33 branch, add a Linear function component called 0.15 TWD
per minute and:

Set the Property Name to Duration

Set the Scaled Amount to 0.15

Set the Fixed Amount to 0 (i.e. there is no base fee)

Add a Counter Update component called Increment counter and increment the
Minutes used counter by the Duration value.

Note that the Minutes Used counter belongs to the Persistent Counter defined at
the Charge object. While the Duration Property comes from the CIC.

Repeat steps above for the other branches with Scaled Amounts of 0.50, 0.40
and 0.20 respectively.
To save the Charge, specify the Charging Reference Name at the Internal
Reference Directory of the Charge. Add Default and Type Postpaid

Add the Internal Reference to the Charging Plan as Default.

To test the Charge logic, choose Action->Trial Run Price Plan

The system prompts me an error. Why? If you remembered, I have mentioned in

the previous chapters that the Tree should always always always ends with a
Functions component. But here, this error is not the case. A Prefix Switching just
cannot accept an empty value!

There is only one way to solve this error which is to delete the empty line above
the prefix +33 at the Prefix Switching comparator.

Now lets retry the Trial Run Price Plan.

The Trial Run Price Plan option allows you to test your pricing logic before
releasing it. In the Input Properties, enter the value shown below. Then click on
the start button (play symbol) at the top left corner.
The result is shown at the Line Items view.
Lets verify the result using manual calculation. We have specified the Duration
value as 100 minutes. The Number Dialed starts with the prefix +4. In the Prefix
Switching the calculation for this combination will fall under the Number Dialed
Does not start with any of the prefixes node. The calculation will use the Linear
functions component. 100 Minutes * 0.20TWD = 20TWD. The value at the Line
Item view displays the correct rate.

Save the Charge in the database.

The diagram below summarises the objects that are created in this tutorial

In the next chapter you will be introduced to the component Table.

15. Checks and Trial Run

Before we continue our tutorials, lets take quick detour. You have seen that the
Price Plan logic can cause an error if its not properly configured. The Core Tool
provides 3 functions to do a kind of syntax check on you Price Plan Logic. They
are the Verify, Read Price Plan and Trial Run Price Plan.
You can find them on the standard toolbar on your Core Tool.

Or you can find the in the Action DDL.

When you try to Verify a Charge object on a Price Plan that is not properly
configured, the system will point you where the error is occuring.

When you select the Read Price Plan, the system will translate your Price Plan
logic into a human-readable language.

You have already seen the Trial Run Price Plan in the previous chapter.

16. Tables
There are 3 kinds of table in the SAP CC. Translation Table, Tier
Table andMapping Table.
Translation Table:

Used to store data required to perform rating

Can be queried in price plans

Can be used across multiple charges

Supports versioning and start/end dates

Not visible from SAP CRM

Not override-able on Provider Contract basis

Price plans cannot write to Translation (or any other) tables. The SAP CC
APIs must be used to modify these objects.

Tier Table:

Defines different output values for different ranges of a numeric

input value (similar with the SAP SD scale pricing technique) .

Output values can be numbers or strings.

For number output values, different computation modes are available.

Tier Table management is similar to the Translation Table one

(versioning, overriding, sharing)

Not visible from SAP CRM

Not override-able on Provider Contract basis

Example:
Voice call tiered pricing
The first 30 minutes are charged at $0.10/min.
The following 30 minutes are charged at $0.05/min.
The following minutes are charged at $0.01/min.
A call duration of 80 minutes is charged $4.70.
(30*0.10) + (30*0.05) + (20*0.01)

Mapping Table

New for SAP CC 3.0

Viewable from SAP CRM

A Mapping Table Class defines the table schema.

A set of input and output column descriptions

A Mapping Table is an instance of a class.

Each instance is a table data that follows the schema.

Stored in the catalog of the service provider

Mapping Table management from the UI

Create, modify, search and delete operations
Row level operations

Component to execute a table lookup (from the pricing logic)

Can be created on a product and provider contract basis by SAP CRM

and specific instance referenced in price plans

Now that we have the theory over with, lets do some exercises. Below is the
scenario.
You need to create a Charge for the pricing of usage events related to the Call
Service. The price depends on the combination of the plan type and the called
number prefix as shown below.

Since its not a tiered scenario and it is not necessary for the SAP CRM
(provisioning system) to access the table, we choose Translation Table to
represent the reference data.
Create a new Translation Table called [T01] Call Pricing. File->New->Translation
Table

At the Table Schema tab, in the Input Columns add Plan Type ID with description
Plan Type User is subscribe to. Add a second input column Number Prefix with

description Dialed Number Prefix.

For the Output Columns add Rate per Minute type Number.

Select the Table Instance tab and key in the Translation Table data.
Save the Translation Table in the database.

Lets next create a Charge and utilize the Translation Table in the Price Plan logic.
You will reuse the Charge T[01] Mobile Usage Charge that you have created in
the previous chapters.
Choose File->Open->Charge

Choose the Charge T[01] Mobile Usage Charge.

Click on the Charges Parameters tab and click the add button.

Add Plan Type ID type String with Value Standard. This Parameter will act like a
property or a variable with the initial value Standard. We can then link the
Parameter to the Translation Table input in the Price Plan to get the output rate.
In real life (IRL), the CDR or the raw network information will hold such properties
and pass it to the SAP CC via mediation.

Remove the Prefix Switching component called Destination Check.

Right click on the Call Usage Rate node, Add Component->Operators->Table

Operator

Select the Translation Table T[01]Call Pricing if it is not yet selected.

Fill in the Table Operator name as Lookup in Cell Pricing Table. In the Table
Operator Definition, Select Start With for the Comparison Operator,
Consumption Date for the Reference Date.
In the Mapping of Rating Context view, choose the appropriate Mapping Property
as shown below.

Next, add a Numbers comparator to check if the Rate Per Minute value is > 0.
Where does the Rate Per Minute comes from? It comes from the Output Column
of the Translation Table.

Choose Property Name Rate per Minute, Operator Is Greater Than Comparison
Value 0.

If the Rate Per Minute value is > 0, add a Linear function component to
generate a fee of the Duration multiplied by the Rate per Minute.

If the Rate Per Minute value is < 0 , there has been a problem in the table
lookup so add a No access function component and an appropriate error.

Run the Trial Run Price Plan tool and experiment with different input values.
Verify that the rated amount is in line with our Price Plan logic design.

You can manipulate any values in the Input Properties.

We have initially gave the Plan Type ID a value of Standard in the Parameter of
the Charge. We can change it to a different value to test the rest of the
combination.

A No Access Function will throw an exception message. IRL, we should define a

more detail error message. This message will be routed to the relevant
messaging system for error handling. Bear in mind that the Rating and Charging
process is done in the background with hundreds or thousands of transaction
computed at any given moment.

Save the Charge in the Database.

Accept the default Effective Date and click OK.

Voil!

17. Pricing Macro

Some pricing logic can be shared across multiple price plan. A simple example is
the logic to derive the Country Name from the Number Dialed. This logic can be
encapsulated and used by many Charges. Here in SAP CC we can use thePricing
Macro object to provide re-usable function.
Pricing Macro:

Similar to a sub-routine (ABAP)

Can be used across multiple Charges

Accepts specified input parameters

Returns specified output parameters

Can be used in two ways:

1. Macros Rating Function Macro generates final rated amount
directly
2. Macro Operator Macro performs some logic and results are returned
to calling price plan for further computation.

Lets create a Pricing Macro that will take a phone number, look at its prefix and
return the name of the country associated to the prefix. Prefix +61 for Australia,
+33 for France and +1 for US of A.
Create a new Pricing Macro. Select File ->New Pricing Macro

Set up the input and output parameters of the pricing macro

Rating context properties: Phone Number (string) <- similar to your

import parameter in your sub-routine

Generated properties: County Name <-similar to your export parameter

in your sub-routine

Add a Prefix Switching component into the macro to check prefixes +33, +61
and +1

At the Prefix Switching Definition, Change the Property Name to Phone Number.
The property Phone Number is inherited from the Pricing Macros Rating
Context Properties.

Add the Output Property Updates to each branch in your logic. Set the value
to the appropriate country.

We have earlier defined the exporting parameter Country Name at the

Generated properties view of the Pricing Macros definition. In the Output
Property Component, when the prefix is +33, we assign the value of this
parameter to France.

Add a Free rating component to each branch.

Repeat the steps with the rest of the prefixes.

Lets go ahead and execute the Trial Run Price Plan.

Enter +61 as the value of the input property Phone Number. Then click the Start
button that looks like a play symbol on the top left of the Rating Trial Run
application. The output should be Australia. Aussie! Aussie! Aussie! Oi! Oi! Oi!

Now try it with other values and verify that the output value is correct.

Save the Pricing Macro. File->Save->In the Database

Select the Catalog T01 then Click Save.

Finally, lets use the Pricing Macro in one of the Charge that have been created in
the previous chapter.
Select File->Open->Charge

Select the [T01]Mobile Usage Charge and click Open.

Click on the node just before the fee is calculated. Insert a Pricing Macro
Operator under this branch.

Give the name of the Macro Operator as Look up country name. Choose the
Get country name from phone number Pricing Macro. Select the Number
Dialed property as the Mapping Property of the importing parameter of the
Pricing Macros Phone Number (thats a mouthful). Note that the property
Number Dialed comes from the CIC which is linked with the Charge.

Test the Price Plan to see the output of the Pricing Macro utilization.

Save the modified Charge in the Database.

Voil!

18. Charge Plan

In Chapter 3 we have briefly explained the function of a Charge Plan object.
The diagram below shows that the Charge Plan is connected to the Charge, SAP
CRM and SAP CI.

Charge Plans:

Represent the charging part of a service that Carrier Operator propose to

their customers, agents or partners via the provisioning system product
catalog (e.g. CRM)

Can be created by gathering existing Charges in the same Catalogue

Contains Charge Plan Items.

Each item defines a pricing and charging logic (decision tree).

Defines its class (exposed to the provisioning system)

A set of parameters (mandatory or optional)
A status (open, released or obsolete)

Stored in the Catalog of the service provider

Management from the UI

Create, modify, search and delete operations

Charge Plans enable:

Grouping multiple services into marketable units

Promotional time periods

Partner commissioning and settlement

Easy re-use for different marketing schemes

Family plans with shared buckets of minutes

Shared settings for similar charges

Charge Plans can be created by grouping existing charges from the same
catalogue.

Before you create a Charge Plan, make sure the Charged Item Class is created
first. This is a prerequisite. The Charged Item Class (not to be confused with the
CIC) provides the output mapping that is to be sent to the billing system (SAP
CI).
Now lets go ahead and create a new Charge Plan. But first, the Charged Item
Class must be created.
To create a Charged Item Class, in the menu bar, select File->New->Charged
Item Class.

As a Name, enter [T01] CITC

Save the Charged Item Class in the database.

Select Owner and Catalog T01 then, click Save.

We have successfully created an empty Charged Item Class. It is empty because

we did not specify any output field to it. Below is one example a Charged Item
Class with some output fields that will be used as the reference format for the
preceding billing system. For this chapter, we will only be using an empty
Charged Item Class. We will revisit the Charged Item Class in detail in the billing
chapter.

To create a new Charge Plan, in the menu bar of the Core Tool, select File->New>Charge Plan

Choose owner T01.

Enter [T01] Mobile Call Plan as the Name and for the Description enter Mobile
Call Plan (usage and monthly fees).

In the Parameters tab, add a new Parameter to the charge plan called Plan Type
ID (CP) of type String with the visibility set to External (Mandatory) and a
Description set to Plan type.

In the Account Assignments tab, add a new Account Reference to the charge
plan called Default of type Postpaid with a Description set to Default account.

In the Technical Data tab, add a User Technical Identifier called Phone Number
with a Description set to Users phone number.

Right-click on the [T01] Mobile Call Plan Charge Plan and add in the [T01]
Mobile Usage Charge. This Charge was created in the previous chapter.

In the Parameters tab of the Charge, set the Status of Plan Type ID parameter
to Linked and choose Plan Type ID (CP) as a Value. The Plan Type ID (CP)
comes from the Charge Plan.

In the Charged Item tab of the Charge, choose [T01] CITC as a Charged Item
Based On.

In the Account Assignments tab of the Charge, link the Default charging
reference to the Default account reference by choosing Default as a Linked
Value.

In the Technical Data tab of the Charge, add a new Service Identifier called Call
and link it to the Phone Number User Technical Identifier.

Right-click on the [T01] Mobile Call Plan charge plan and add in the [T01]
Mobile Recurring Charge charge.

Configure the Charged Item and the Account Assignments of the Charge.

Verify the charge plan.

Save the charge plan in the database.

Voil! You have successfully created a standalone Charge Plan. I call this a
standalone Charge Plan because we have only configured it in the SAP CC
portion. Remember that the main function of the Charge Plan is to expose the
Charge(s) of SAP CC to the provisioning system (e.g. SAP CRM). We did not
configure this yet. I hope in the later chapter, we will have the chance to see this
linkage. But for now, this tutorial is sufficient to give you the overall feel of the
Charge Plan configuration.

19. Charging Plan (Advance)

We have discussed about Charging Plan in Chapter 11. It determines the
account to be charged and also holds the information such as postpaid and
prepaid account type.
When you create a new Charge, the Charging Plan and Price Plan will be
created automatically. Additionally, the Default Charging node is also created
under the Charging Plan node in the Decision Tree.

However, apart from the Default Charging component, there are 3 more
components that can be attached to the Charging Plan.

Usage Charging
This component is triggered when its chargeable item class name is the same as
the usage event triggered in the Price Plan.
Recurring Charging
This component has no properties.
It is triggered by all recurring events contained within the Price Plan.
Only one recurring charging is available per charging plan.

One-Shot Charging
This component has no properties.
It will be triggered by all one-shot events contained in the Price Plan.
Only one one-shot charging is available per charging plan.
Default Charging
This component is triggered when the chargeable event does not correspond to
any root component.
Internal Reference
It represents either Prepaid or External Account.
Only internal references can be mapped at charging mapping level.
Internal References must be defined with a Type (Postpaid or Prepaid) in
the Internal Reference Dictionary (in the Charging Plan Definition)
When a customer creates a contract values for the charging references must
be supplied for billing
For our tutorial scenario, see the diagram below. Familiarize yourself with the
flow of the data and how they are linked and where they come from. In this
example, when the number dialed starts with the prefix +33, the company
account will be charged. If the number is dialed using other prefixes, the
employee account will be charged. Note that Functions and Splitters component
are not allowed! But you are free to use the Prefix Switching component or the
Translation Table Operator etc.

Now lets get started.

In the menu bar, select Window->View Catalogs. Select catalog [T01].

Right click on the charge [T01] Mobile Usage Charge and select Open as Copy

Rename the charge to [T01] Business Mobile Usage Charge.

Click on the Charging Plan. Add references for Company and Employee.

Add a new Usage Charging plan. Set the Chargeable Item Class to [T01] Call.
Name it Call Charging.

Add a new Prefix Switching comparator called Check if call is local. Set the
prefix to +33.

Add an Internal Reference for the Company account when the dialed number
starts with +33 and to the Employee account for other cases.

Verify and save the Charge in the Database.

Charging Plan Summary:

Charging represents the process to identify a unique entity to charge for

the use of a service.

This entity is usually called an account, however at this level, we can only
talk about a Charging Reference.

The account to be charged is not yet identified and charging plan only
leads to a charge reference.

A Charging Reference must be mapped to an account at the Provider

Contract level.

Speaking about Provider Contract, in the next chapter, lets look at

how Customer Master Data is maintained in SAP CC.

20. Master Data

There are two examples of Master Data in SAP CC. The Subscriber
Accountand the Provider Contract. Before creating a Provider Contract, you
must create at least one Subscriber Account. This is a prerequisite.
A Subscriber Account contains prepaid balances (accounts) and external
accounts which are debited when the customer consumes services or credited
when he makes refills. Refills here means credit recharge or credit top-ups for

prepaid services. A Provider Contract is a long-term agreement between a

service provider and a customer based on specific terms. In the SAP CC however,
the Provider Contract functions like a container that links the Subscriber Account,
his/her phone number and the Charge Plan which the Subscriber Account is
subscribing to.
The diagram below shows the dynamics between the Provider Contract,
Subscriber Account and the Charge Plan.

Dont worry if you feel the diagram is difficult to digest. The next chapter will
explain to you step by step how to create a Subscriber Account and the Provide
Contract as well as the linkage between them and the linkage made to the
Charge Plan. But first, feast your eyes on the lengthy theory below. In will make
more sense in due course.
How an account is debited or credited?

A Subscriber Account is linked to the Charging Plan (defined in a

Charge) through a mapping located in a Charge Plan within the Provider
Contract.

When a customer activates a new Charge, an Account

Assignmentstep populates the references that enable identification of
which account will be debited.

When a customer uses a service, the pricing process calculates

corresponding fees while the charging process defines which prepaid or
external accounts will be debited. (when a customer account is debited, it
means that the account is being charge)

Subscriber Account: Account Type

Prepaid accounts:
Monetary balance with associated empty limit

Expiration schedule: active, blocked, locked, closed

Alerts on amount or on expiration events
External accounts:
Account type: currency, account receivable or payable to control
online transaction consistency
Account references: Client / partner and Service Provider
Subscriber Account: Prepaid Accounts

Prepaid accounts contain a monetary counter associated with a currency.

Funds are placed in the account before the service begins, and then
the charges linked to the services consumed by the client are debited as
necessary in real-time.

The balance of an account is defined by a minimum value (empty limit).

Depending on service providers requirements, the empty limit is usually

close to 0 and must not be less than zero; however, if overspending is
authorized for specific usage, the empty limit is ignored, and usage can be
debited from the account even though the balance of the account is less
than 0.

Crediting a fee to a prepaid account consists in increasing the amount of

its balance. Conversely, debiting a fee consists in decreasing the amount
of its balance.

Empty limit: It is the minimum value of a balance ensuring that

the account is sufficiently funded to pay or to reserve money. When
empty limit is reached, usage/events are rejected.

Alerts: Prepaid account balances can be connected to expiration

and amount alerts. An alert is a notification sent to a dedicated system
when prepaid account balance is less than or equal to a value.

Refills: Prepaid accounts can be credited through refill plans

Subscriber Account: Prepaid Account States

Active: The prepaid account can be debited until the empty limit is
reached. It can be refilled. If overspending is authorized, debiting is
possible. You can block, lock or close an active prepaid account.

Blocked: The prepaid account cannot be debited (only free usage is

accepted). It can however be refilled. If overspending is authorized,
debiting is possible. You can reactivate, lock or close a blocked prepaid
account.

Locked: The prepaid account cannot be debited (free usage is not

accepted). Refills and overruns are authorized. If overspending is
authorized, debiting is possible. You can reactivate, block or close a locked
prepaid account.

Closed: The prepaid account cannot be debited. Refills and overruns are
forbidden. Once closed, you cannot change a prepaid account any more.

An expiration schedule allows you to schedule the states of a prepaid

account.

Subscriber Account: External Account

An external account is a reference to an account managed outside

Convergent Charging.

SAP Convergent Charging checks the compatibility between account types

and transactions in real time:

Payable: An account payable is an account by which a service provider

owes a partner money (and sends settlement reports to the partner)

Receivable: An account receivable is the customer account

Subscriber Account: Creation

In an integration end-to-end scenario with SAP Offer-to-Cash, subscriber
accounts are replicated from business partners.
In a standalone scenario with SAP CC, you can create subscriber accounts
directly using the Core Tool.
To create a subscriber account, we need:

List of prepaid accounts and external accounts owned by the customer

Account by default

Subscriber id and catalogue owner

Additional information

List of the provider contracts

Provider Contracts

A Provider Contract is a long-term agreement between a service provider

and a customer based on specific terms. Those terms, have been
negotiated beforehand to define how and when the customer will be
charged :
- To have access to goods / services
- To consume these goods / services

A provider contract can be updated at any time, based on :

- On customer request
- On customer consumption
- On provider request

In SAP CC 3.0, the creation of Provider Contracts is designed to be handled

by a provisioning system (e.g. SAP CRM)

It is possible to create these contracts with SAP Web-services or by SAP

CC Core Tool directly. (in the next tutorial, we create it using Core Tool)

To create a Provider Contract, we need the following:

A Subscriber Account (at least one)

One or several Charge Plans to subscribe to

One Refill Plan to subscribe to (Optional)

Contract effective date

SAP CRM Product that references the Charge Plan (via cross
catalog mapping) (Consume To Cash Deployment only)

Parameters required by Charge Plans (Account Assignment, Technical

Data, Shared Counter etc)

User Technical data. i.e. what is going to identify the user when
they consume a service (e.g. phone number)

21. Subscriber Account

Create a Subscriber Account. This will represent a customer. File->New>Subscriber account

Name the Subscriber account [T01] Subscriber Account 1.

Add a prepaid account and an external account. Give each account a name [T01]
Prepaid 1, [T01] Postpaid 1.

Save the Subscriber Account in the Database.

The Subscriber Account definition in SAP CC merely contains

the SubscriberAccount1 and the Contracting Service Provider T01.
You may wonder, where is the rest of the customer information such as customer
name, address and payment data. These customer information are kept in the
SAP CRM as shown below.

22. Provider Contract

Lets create a Provider Contract for a new Subscriber of a Family Mobile Plan.
The plan will feature the ability to share allowances across members in the
family. We have already Created the Subscriber Account in the previous chapter.
First we need to create a Counter to implement the ability to share allowances
(minutes used) across multiple users. In the chapter 12, we have talked about
Persistent and Transient counter. Here we add a Counter to
the CounterDictionary. This enables counter sharing between different Charge
Plan activations. (The term Charge Plan Activation refers to the activity where we
add one or more Charge Plan to the Provider Contract).
The diagram below shows the scenario that we will complete in this chapter.

Select Tools->Counter Dictionary->Edit

Add a new counter call [T01] Shared minutes and click Save.

In the Catalog for T01, right click on [T01]Mobile Call Plan, select Open as Copy.
We need to modify the Charge Plan in order to take the new Counter into
account.

Change the Name to [T01]Mobile Call Plan (2).

At the Charge Plan Counters tab, add [T01]Shared minutes with Visibility
External.

Select the [T01]Mobile Usage Charge node. There is a persistent counter called
Minutes used configured inside the Charge. This Persistent Counter value is
updated by the Duration property that comes from the user property of the CIC.
We need to link it with the counter [T01]Shared minutes.

Click on the definition tab of the CP. Set the Charge Plan to Released.

Save the charge plan in the Database.

Finally we can create the Provider Contract.

To create the Provider Contract select File->New->Provider Contract.

Search your Subscriber Account and click OK.

Give the name as Contract 1.

Add in the [T01] Mobile Charge Plan (2) 2 times. Each time edit the name of it
to User 1 then User 2.

Click on the Counters tab ,set each counter status to Shared and set
the Namespace to [T01].

On each Charge Plan activation, select the Technical Data tab and provide
a phone number for each user.

On each Charge Plan activation, select the Account Assignments tab and provide
select the External Account of your Subscriber Account.

On each Charge Plan activation, select the the Parameters tab, update the initial
Value of the Plan Type ID (CP) to X. In previous chapter, the Plan Type ID (CP)
was used to store either the value of Standard or Power User.

Verify the new Provider Contract.

Save the new Provider Contract in the Database.

23. Refill Overview

This chapter will give you an overview of the Refill concept in SAP CC. The Refill
object is design to handle prepaid Charges such as recharge or top-ups. By using
our mobile prepaid service example, this concept is easily understood. However,
On-Demand or Pay as You Go types of products that are deployed in the Cloud
can get very messy and complicated.
The good news about the Refill object is that it is not so complicated to
understand. The bad news is that it has a whole different set of components. It
has its own Class, its own Logic and its own Plan. We cannot reuse the CIP,
Charge or Charge Plan objects that we have created thus far.

Refill Item Class

Similar to a Chargeable Item Class (CIC)

Defines the structure of a Refill Item

Includes the following default properties:

Date
Amount
Currency

Includes additional user-defined properties

Information in an instantiation of the Refill Item Class is utilized by Refill

Logic within a Refill Plan to determine correct amount by which to refill a
prepaid account

Refill Logic

Equivalent to a Charge for the refilling process

Defines an algorithm whose purpose is to refill a customer prepaid account

Refill Plan Logic can be customized utilizing the following:

Counters and parameters, redefined or linked
Prepaid account reference linked to refill plan level account
User identifiers linked to refill plan identifiers
Configuration for creation of refill records (Result Data)
Tier Tables, Translation Tables cannot be redefined

Refill Plan

New structured object to manage refilling functionality in the catalog of

the Service Provider

Accessible from provisioning system via web service call to Refill Plan

Should be combined with a Charge Plan in the CRM or provisioning system,

in order to model new commercial products/offers

Each Refill Plan contains a Refill Logic module that defines the amount to
refill

24. Refill Item Class

Create a new Refill Item Class called [T01] Prepaid card for the [T01]
Catalogue.
In the Core Tool select File->New->Refill Item Class

Similar like the CIC, the Refill Item Class contains a default set of 3 properties.
Refill Date type Date, Refill Amount type Number and Refill Currency type String.

Add an additional User Property called Card ID.

Save the Refill Item Class in the Database.

Select Catalog T01, then click Save.

26. Refill Record Class

A Refill Record Class functions exactly the as Charged Item Class. It contains the
output that will be sent to the billing system.
Select New->Refill Record Class. Call the class [T01] Prepaid card refill record.

Add three fields and save the class:

Name: Amount, Type: Number, Value: Total Amount (Incl. Tax)

Name: Card ID, Type: String, Value: Empty Value

Name: Subscription ID, Type: String, Value: Subscription Code

Verify the Refill Record Class.

Save the Refill Record Class in the Database.

Choose Catalog T01 and then Click Save.

27. Refill Plan

Create a new Refill Plan called [T01] Prepaid Card Refill Plan for the [T01]
catalog. Enter the description as Prepaid card refill plan.

Click on the Technical Data tab and add an identifier Phone Number and enter
customer phone number as the description.

Right click on the Refill Plan object and add in the Refill Logic [T01] Prepaid card
refill logic by clicking the Add Item.

Select the Technical Data tab. Add an entry for Service Identifier called Prepaid
Card Refill and User Technical Identifier Phone Number.

Select the Refill Records tab. Select the [T01] Prepaid card refill record.

Set the Card ID value to the Card ID element located in the drop down list.

Click on the Refill Plan and select the Account Assignments tab. Create an
entry for account Name: Default, Type: Prepaid, Description: Prepaid account.

Click on the Refill Logic and select the Account Assignments tab to link the
account Default from the Refill Plan.

Verify the Refill Plan.

Save the Refill Plan in the Database.

Choose Catalog T01 and then click Save.

Voil!
The diagram below sums up what you have configured for the Refill process. In
real life project implementation, it is wise to design a systematic naming
convention especially for your properties. Try to create property names that
identifies where it is created. As you can see in the diagram, things can get
pretty unorganized when you have many linked properties.

28. Billing
There are two objects in SAP CC that needs to be configured to pass information
to the billing process. Its either the Charged Item Class and/or the Refill
Record Class. The result of the charging and rating process is the Charged
Item.
Charged Item:

Is the output of the rating and charging processes

Stored into files (prepaid or postpaid channels)

Loaded in SAP Convergent Invoicing as Billable Items

The format of a charged item is described by a Charged Item Class.

Charged Item Class is used to retrieve and configure the information included
in aCharged Item.
Charged Item Classes can be created and used for:

The SAP ERP system -> create Charged Item Class from the billable item
mapping

Any other external system -> create Charged Item Class from scratch

Charged Item Class is represented by a tree in the core tool of Convergent

Charging. Each node of the tree represents a value of type string, number, date
or boolean. We need to configure how these values are generated by the
system.

On the other hand, a Refill Record is the output of the refilling process.
Refill Records:

Are stored into files (prepaid channel).

Are then loaded in SAP Convergent Invoicing as Billable Items.

The format of a Refill Record is described by a Refill Record Class.

Refill Record Class

A Refill Record Class is used to retrieve and configure the information included in
a refill record. Refill Records are the resulting transactions of the refilling process
Refill Record classes can be created and used for:

The SAP ERP system -> create refill record class from the billable item
mapping

Any other external system -> create refill record class from scratch

Refill Record Class is represented by a table in the core tool of Convergent

Charging. Each row of the table represents a property of type string, number,
date or boolean. We need to Configure how the system generates these values.

29. Charged Item Class

Lets define the format for SMS output events that will be sent to your billing
system from SAP CC.
Select File->New->Charged Item Class

Call the class [T01] SMS Output

Add a number field called Amount with empty value.

Add a date field called Consumption Date with empty value.

Add a string field called Contract with value of Contract ID

Add a string field called Account Number with value of Prepaid Account Code

Save the Charged Item Class in the database.

Detour SAP CRM (the provisioning system)

Before we go further into creating more pricing objects for the SAP CC, lets take
a quick look at how the SAP CRM user interface looks like.
This will help you visualize the bigger picture.
So far we have seen screenshots from the SAP CC servers and Core Tool.
But as far as customer interaction is concern, they will see only the SAP CRM
portion.

Below is the user interface called SAP CRM Interaction Center (IC). Its usually
used by your carrier operators call center personnel. When they received a call
form a customer, the IC screen will alert the call center agent by flickering its
communication toolbar buttons. The agent clicks the Accepts button, takes the
customer details, creates a sales order for the customer and keys in the Mobile
Plan (as well as the free IPhone 4S5S, I wish!) and other products and services.

So there you have it. SAP CRM user interface. Sometimes, its called the SAP
WebUI.
A typical simplified solution for the telco business case is shown below.

Detour SAP BRIM Business Scenarios

By now, after going through most of the chapters, you should have the basic idea
of how your local mobile carrier operator system operates.
Let me give you some examples of the business scenarios that you will
encounter when implementing SAP BRIM in a real life project. Note that to
implement most of these business scenarios, we need the SAP CC to be
integrated with whole SAP BRIM components (e.g. CRM, CI, FICA).
1. Customer and Contract Creation for Postpaid Services
- Creation of a new customer and contract in the CRM Interaction Center
for postpaid services
2. Use Service, Create Invoices, and Pay for Postpaid Service
- Execution of the whole usage consumption, billing, invoicing, and
financials process using the predefined postpaid product and an available
customer who has subscribed to the product based on a preconfigured
sample of usage data
3. Customer and Contract Creation for Prepaid Services
- Creation of a new customer and contract in the CRM Interaction Center
for prepaid services
4. Use Service and Manage Balance and Financials for Prepaid
- Execution of the whole usage consumption, billing, invoicing, and
financials process using the predefined prepaid product and an available
customer who has subscribed to the product based on a preconfigured
sample of usage data
5. Terminating a Prepaid Service and Closing a Prepaid Account
- Automatic closing of prepaid accounts which are not used for a specific
period of time, including all required follow-up processes in the SAP Billing
and Revenue Innovation Management solution
6. Refill Prepaid Account via Voucher Activation
- Purchase of credit in retail outlets using vouchers or activation codes,
handled by an upstream third-party voucher management system
7. Financial Customer Care Financial Inquiries
- Inquire about financial data of a customer and initiate follow-up
processes in A/R
8. Financial Customer Care Bill Display and Dispute Management
- Access customer bill(s), including the bill detail information to handle
dispute and necessary adjustments
9. Financial Customer Care Collections in CRM Interaction Center
- Preparation and execution of outbound collection activities in CRM
Interaction Center

10.Contract Change from Prepaid to Postpaid Product

- Change of a customer contract from a prepaid to a postpaid product
11.Refill Prepaid Account by One Time Permission
- Refill of the prepaid account through crediting a payment card
12.Daily and Monthly Closing
- Daily and monthly closing processes in SAP ERP
13.Consolidated Statements for Banking Postpaid Services
- Consolidated statements for postpaid banking services combine
customer bills or statements from multiple accounts in multiple external
applications into one consolidated statement
In an unrelated note: Heres one of our BRIM consultant Dilbert who is exploring
Big Telecoms Confusopoly pricing.