Bill Ops Workbook For Reliancev1

Convergent Billing v4.
02
Operations Program
Billing Operations for Reliance Infocomm
Participant Handbook
Document Type = P
December, 2002
Software Version
Version 4.02
Disclaimer
Although every effort has been made to ensure the accuracy of the information contained in this
document, ADC Software Systems Ireland Limited makes no warranty, expressed or implied, with
respect to the quality, correctness, reliability, currency, accuracy, or freedom from error of this
document or the products it describes. ADC Software Systems Ireland Limited may make
improvements and/or changes in the products and services described in this document at any time.
ADC Software Systems Ireland Limited disclaims all liability for any direct, indirect, incidental,
consequential, special or exemplary damages resulting from the use of the information in this document
or from the use of any products described in this document. Mention of any other product not owned by
ADC does not constitute an endorsement of that product by ADC Software Systems Ireland Limited.
Data used in examples and sample data files are intended to be fictional and any resemblance to real
persons or companies is entirely coincidental.
Persons reading this document should rely on their own enquiries in making any decisions touching on
their own interests.
Licence Agreement
The software described in this guide is supplied under a licence agreement and may only be used in
accordance with the terms of that agreement.
Copyright Information
© 2002 ADC Software Systems Ireland Limited. All rights reserved. Apart from any use permitted
under the Copyright Act, no part may be reproduced by any process without the written permission of
ADC Software Systems Ireland Limited, IDA Business Park, Dangan, Galway, Ireland.
The following are trademarks of ADC Software Systems Ireland Limited:
Singl.eView™ Singl.eView Commerce Engine™ Singl.eView Commerce Index™
The following are third party trademarks:
Microsoft is a registered trademark and Windows is a trademark of Microsoft Corporation in the USA
and other countries. TE X is a trademark of the American Mathematical Society. PostScript and Adobe
Reader are trademarks of Adobe Systems Incorporated. UNIX is a registered trademark of The Open
Group. TUXEDO is a registered trademark of BEA Systems, Inc.
Document Name
F:\
Billing Operations
Aim
The purpose of this document is to provide the trainer with a guide to the preparation and training of
Billing Operations. Use of this document will ensure that the training of this program is as
appropriate and effective as possible.
The purpose of this document is to lead you through the key points and procedures you will need to
effectively understand the concepts and gain the skills outlined in the objectives.
As this document is designed to be used in the training program Billing Operations , each section is
structured in a way that supports learning.
Components include:
• Overviews of functionality in the area being covered
• Step by step guides to show you how to perform relevant tasks
• Exercises designed to reinforce your understanding of each learning outcome.
This document is also designed to be used as a reference guide.
Key to Icons
Trainer Explanation
Trainer Demonstration
Overhead Projector
Refer to handbook
Key Point
Ask Questions
CB v4.02 Page i
Participant Exercise
6 Time Permitting
Trainer Note
Page ii CB v4.02
Billing Operations
Participant Handbook – Table of Contents
Table of Contents
Module Outline..........................................................................................................2
Learning Objectives ................................................................................................9
Rating and Billing Overview............................................................................... 10

Rating and Billing Process Flow.................................................................. 11
Prerequisites for Rating and Billing............................................................. 12
Product Definitions ............................................................................... 12
Product Instance................................................................................... 13
Product Usage and Events ................................................................. 14
Exercise 1 – Create a Customer and a Product Instance ............. 15
Rating....................................................................................................................... 16
Event Terminology......................................................................................... 17
Rating Architecture ........................................................................................ 18
Event Rating Broker (ERB)................................................................. 19
Event Normalisation (ENM) ................................................................ 19
Event Rating (ERT).............................................................................. 22
Event Rating Output (ERO) ................................................................ 24
Exercise 2 – Rating .............................................................................. 24
Location of Rating Files ................................................................................ 27
Rating Files from Multiple Sources.................................................... 28
Configuring Rating Processes ..................................................................... 29
Configuration Items.............................................................................. 29
Guided Practice 1 – View an ENM Configuration Item .................. 31
How the ENM Selects an ERT and ERO Process.......................... 37
Exercise 3 – View Other Rating Configuration Items ..................... 38
Guided Practice 2 – Create an ENM Configuration Item............... 39
Managing Rating Tasks ................................................................................ 41
Pre-rating Tasks ................................................................................... 41
Scheduling Server Tasks .................................................................... 43
One-Off Tasks and Schedules .................................................................... 45
Schedule Types.................................................................................... 45
One-Off Tasks....................................................................................... 46
Exercise 4 – Schedule Types and One-Off Tasks.......................... 47
Schedules.............................................................................................. 48
Rating Event Files.......................................................................................... 51
More on ENM File Types and ENM Event Types ........................... 52
Exercise 5 – Performing Rating ......................................................... 54
CB v4.02 Page iii

Billing Operations
Guided Practice 3 – Rate Files .......................................................... 55

Rating Results ................................................................................................ 57
Task Status and Results ..................................................................... 57
Input, Archive and Error Directories.................................................. 58
log.out File ............................................................................................. 58
Normalised Events ............................................................................... 59
Error Events .......................................................................................... 60
Exercise 6 – Rating Results ............................................................... 61
Guided Practice 4 – View the Normalised Events .......................... 63
Correcting Rating Errors............................................................................... 68
The Rating Task Fails.......................................................................... 68
Corrupted Events ................................................................................. 68
Error Events .......................................................................................... 69
Incorrect Charges................................................................................. 70
Rating Schedule Types ....................................................................... 72
Exercise 7 – Correcting Corrupted Events....................................... 73
Guided Practice 5 – Correcting Error Events................................... 74
Revoking Rating............................................................................................. 83
Which Schedule Type for Revoking?................................................ 83
Exercise 8 – Revoking Rating ............................................................ 84
Billing ....................................................................................................................... 85
Billing Terminology........................................................................................ 86
Bill Runs and Invoice Cycles .............................................................. 86
Reporting Levels................................................................................... 87
Suppress Billing .................................................................................... 89
Billing Architecture......................................................................................... 91
Rental Generation Process (RGP).................................................... 92
Bill Generation Process (BGP)........................................................... 94
Invoice Generation Process (IGP)..................................................... 95
Applying and Allocating Invoices ....................................................... 96
General Output Process (GOP)......................................................... 97
Configuring Billing Processes ...................................................................... 99
Configuration Items.............................................................................. 99
Guided Practice 6 – View a BGP Configuration Item...................100
Billing Streaming.................................................................................104
Exercise 9 – View Other Billing Configuration Items ....................109
Managing Billing Tasks...............................................................................110
Pre-billing Tasks .................................................................................110
Bill Run Schedules .............................................................................112
Bill Run Schedule Types...................................................................114
Guided Practice 7 – Create a Bill Run Schedule ..........................120
Exercise 10 – Update A Customer with a New Invoice Cycle.....123
Guided Practice 8 – Run a Pending Schedule ..............................124
Page i v CB v4.02
Billing Operations
Billing Results...............................................................................................126
Task Status and Results ...................................................................126
Bill Run Details Form .........................................................................128
Exercise 11 – Billing Results ............................................................135
Correcting Billing Errors..............................................................................136
Bill Run Failure ...................................................................................136
Incorrect Billing or Invoice Details ...................................................136
Single Customer Errors .....................................................................138
Guided Practice 9 – Correcting Billing Errors ................................142
Applying and Allocating Invoices...............................................................148
Exercise 12 – Apply and Allocate Invoices ....................................148
Collecting Diagnostic Information..............................................................149
Failures Due to Data Problems........................................................149
BGP Tracing........................................................................................149
Incorrect Processing ..........................................................................151
Process Payments.......................................................................................153
Payments are made against account not invoices .......................154
Exercise 13 – Process Payment......................................................155
Guided Practice 10 – Payments Upload ........................................156
Payment Allocation Results..............................................................157
Fraud Management Schedule ...................................................................158
Fraud Management Files ..................................................................158
Exercise 14 – Fraud Management ..................................................159
Guided Practice 11 – Fraud Management.....................................160
Fraud Management Extract Results................................................161
GL Upload.....................................................................................................162
When to run GL Upload.....................................................................163
Exercise 15 – GL Upload ..................................................................164
GL Upload Results .............................................................................165
Treatment Monitoring ..................................................................................166
Treatment Monitoring.........................................................................166
Treatment Monitoring Results ..........................................................167
Treatment Interface .....................................................................................168
Exercise 16 – Treatment Datafeed..................................................169
Treatment Interface Results .............................................................170
Product Catalogue Output..........................................................................171
Conclusion ...........................................................................................................174
Your Notes ............................................................................................................175
CB v4.02 Page v
Billing Operations
Participant Handbook – Module Outline
Program Outline
Program:
Operations Program
Pre-Requisites:
Windows 2000 experience
End to End training
CB v4.02 Page 1
Billing Operations
Module Outline
1. Introduction
2. Learning Objectives
3. Rating and Billing Overview
a) Rating and Billing Process Flow
b) Prerequisites for Rating and Billing
4. Rating
a) Event Terminology
b) Rating Architecture
c) Location of Rating Files
d) Configuring Rating Processes
e) One-Off Tasks and Schedules
f) Rating Event Files
g) Rating Results
h) Correcting Rating Errors
i) Revoking Rating
Page 2 CB v4.02
Billing Operations
5. Billing
a) Billing Terminology
b) Billing Architecture
c) Configuring Billing Processes
d) Bill Run Schedules
e) Billing Results
f) Correcting Billing Errors
g) Payments Upload
h) Fraud Management
i) GL Upload
j) Treatment Schedule
6. Conclusion
CB v4.02 Page 3
Billing Operations
Preparation Checklist
Instruction
Instructors will have formal teaching or training qualifications or be
currently employed in an area related to the module content.
Facilities and Equipment

This program will be delivered in a room equipped for the instruction of
computer applications and should include:
• One workstation per participant which will include:
− Terminal / Monitor (17”)
− Mouse
− Keyboard
• One workstation for the trainer equipped with mouse, keyboard,
terminal and set up for a LCD projector for demonstrations with
capabilities of 1024 x 768 resolution
• All workstations to be configured with access to the appropriate
training database
• Whiteboard or Flip-Chart
• Whiteboard markers and erasers
Page 4 CB v4.02
Billing Operations
Participant Handbook –
Database Preparation
You need to check the following for the database you are training with:
• Participant user names and passwords are set up with correct
security settings (full access rights and permissions if the training is
to take place in a non-production database).
It is necessary to determine the number of participants to ensure
there are sufficient Trainee Logins.
User Name train01 Password train01
….
• Trainer user name and password is set up (with full access rights
and permissions).
User Name trainer01 Password trainer01
• Windows desktop shortcuts to the training database are set up and
functioning on each PC (including the trainer’s).
• Help is functioning correctly on all PCs (including the trainer’s).
• Unix logons for each participant (trainxx/trainxx)
• senter and samba access for each participant
• billing_opsxx.evt files for each participant as generated by Billing
Ops Event File Generator.xls
As participants create their own customer and assign a product to
that customer, all in the one day, the date of the events in the event
files you create need to be just after product creation.
Instructions for creating the proper events are in the Event File
Generator for Billing Ops .xls file on the Data tab
• The sS_CLEC_DIS_InvChg# is updated to include
tCC_Voice_Discount# as an Expression to be Aggregated on the
Terms tab
This ensures the discount displays on the invoice. Otherwise, the
discount is calculated into the invoice total, but does not actually
appear as a line item
CB v4.02 Page 5
Billing Operations
Introduction [duration] mins
Introduction of Trainer
Introduce yourself and the product:
• Introduce yourself and give an overview of your background
• Write your name on the whiteboard
• Introduce the product, including:
− Where product was developed
− How product was named
Introduction of Participants
Ask participants to introduce themselves:
• Write the following headings on the whiteboard:
− Name & Position
− Level of Experience
∗ Windows 95
∗ In product
− Objective / Aim of Attending the Training Program
Administration
Complete the following administration functions:
• Participants to complete Attendance Sheet
• Outline the housekeeping for the training program, including:
− Length of the training program
− Start time/End time
− Break times
Page 6 CB v4.02
Billing Operations
− Location of facilities
− Emergencies - Location of fire escapes etc.
Program Structure
The Operations Program is made up of [number of modules] modules:
•
To obtain a Certificate of Completion for the Operations Program

participants:
• Must attend each day of the program
• Must successfully complete the final assessment
Program Materials
A Trainers Guide is provided for each module. The Handbook is made
up of the following components:
• Learning Objectives
− Identify the skills and concepts that the trainee must be familiar
with
• Overview
− Provides a conceptual overview of a topic
• Guided Practice
− Trainer demonstrates a task
− Trainee repeats the task following the step-by-step instructions
in their handbook
• Self Assessment
− Made up of written and practical exercises
− Addresses the key learning objectives
− Practical portion of the self-assessment based on realistic
business situations
− Provides the trainee with the opportunity to assess their
understanding of the concepts and tasks that were presented to
them in the module
CB v4.02 Page 7
Billing Operations
• Final Assessment Handout at the end of the training program:

− A combination of written and practical exercises
− Practical exercises based on realistic business situations
− Trainees will be able to use their notes, handbooks and the
online help to complete the assessment
− Final Assessment will be evaluated by the trainer
Page 8 CB v4.02
Billing Operations
Participant Handbook – Learning Objectives
Learning Objectives
Display Slide 1 – Learning Objectives
By the end of this program you will be able to:

s Provide an overview of the rating and billing process
s Describe in detail the process of rating
s Describe in detail the process of billing
CB v4.02 Page 9
Billing Operations
Participant Handbook – Rating and Billing Overview
Rating and Billing Overview xx mins
Learning Objectives
s List the prerequisites for rating and billing
Content Overview
Rating and billing is all about generating charges for products and
services, assigning these charges to customers and then invoicing the
customers. Service providers must be able to perform rating and billing
operations in an efficient manner.
The purpose of this section is to overview the Singl.eView Convergent

Billing (CB) rating and billing process flow and review what is required
for rating and billing to occur successfully.
Page 10 CB v4.02
Billing Operations
Rating and Billing Process Flow

Display Slide 2 – Rating and Billing Process Flow
The entire rating and billing process flow is summarised in the diagram
below.
Carrier
Remote
Switch
host
Database
Remote
Events host
es
arg
Rating Billing
Ch
Charges
Normalised Invoice
events data
Normalisation Rating Billing Invoicing
Invoice images
Events
Apply Invoices
Usage One-off
Invoice Output
Rental
Invoices
Briefly walk the participants through the Rating and Billing process
flow diagram. Emphasise that the diagram is a process, so that the
arrows pointing from one box to another are indicative of the process
flow, not the actual results. For example, charges generated from rating
are actually stored on the database, not sent directly to billing.
Rating and billing is made up of six operations:

1. Normalisation: Data records containing usage or charge details
about a product or service (events) are converted to a normalised
format (a native CB format) for storage in the CB database
2. Rating: Normalised events are rated by applying the appropriate
tariffs to produce a series of charge records
3. Billing: Recurring charges, discounts, one-off charges and
adjustments are calculated, and combined with the charge records
calculated in rating. These charge details are combined with
customer detail records, ready to appear on the invoice
4. Invoicing: Billing data is combined with an invoice or statement
format and an invoice image is generated
CB v4.02 Page 11
Billing Operations
5. Invoice Output: Invoices and statements are output to a printer or

some other output device
6. Apply Invoices: Invoice charges are applied to the customers’
accounts
Prerequisites for Rating and Billing

Ask the participants the following question:
What do you need for rating and billing to occur successfully?
Look for answers such as:

• Active customers with active product instances
• Active services associated with a product instance
• Tariffs associated with the product definition
• Usage of the product
Display Slide 3 – Prerequisites for Rating and Billing
For rating and billing to occur successfully, you need the following:
• Active customers with active product instances
• Active services associated with a product instance
• Tariffs associated with the product definition
• Usage of the product
Before we move on to rating and billing, lets review these requirements.
Product Definitions
Products are defined using components from three component groups:
1. Fundamental components
2. Costing components
3. Selection components
Page 12 CB v4.02
Billing Operations
Display Slide 4 –Product Definition
A representation of this is shown in the following diagram.
Selection Components Costing Components
Product Tariffs
Groups
Charge
Base Categories
Icon Product
Definition Subtotals
Product
Compatibility Payment Items
Service Types Derived Facility

Attribute Groups
Mandatory Tables (Lists)
element Equipment Facilities Facility Group
Types Compatibility
Fundamental Components
At a minimum, the key components in the product definition are the

service type and the tariffs.
The service type defines the functionality of the product, the tariffs
define the charges for the product.
Product Instance
Display Slide 5 – Product Instance
A product instance is created by selling a product definition to a

customer.
While the product definition specifies all of the mandatory and optional
services, equipment, tariffs, subtotals and facility groups for that
product, the product instance is a unique, one-off copy of the product
definition, altered to meet the needs of the customer.
A crucial element in the customer’s product instance is the associated

service, in particular, the service number.
CB v4.02 Page 13
Billing Operations
Using the service number, the system is able to link all the way back to
the product definition to get the list of tariffs that may be eligible to
determine charges for the product. This is known as guiding and is
illustrated in the following diagram.
Display Slide 6 – Guiding
Tariffs defined for

Service number Service instance Product instance Product definition the product
definition
Product Usage and Events

The details about the usage of a product or service, which ultimately
result in a charge or benefit to a customer, are stored in data records
known as events.
Events can originate from many different sources, including:

• Intelligent networks
• Mediation systems
• Other service providers
• From within CB itself
The information contained within an event varies depending on the

event source and event type, but usually includes:
• The originating service number (A Party ID)
• The terminating service number (B Party ID)
• The charged service number (C Party ID)
• The date and time of the event
• The duration of the event
• Any other information relevant to that type of event
The C Party ID is used in the guiding process to find the list of tariffs.
Page 14 CB v4.02
Billing Operations
Exercise 1 – Create a Customer and a Product

Instance
The purpose of this exercise is to create a customer and assign them a
product instance for use through the rest of the training module.
Perform the following steps:

1. Create a customer, Bill Johnsonxx, where xx is your training ID. For
example, train05 should create the customer Bill Johnson05
a) Create the customer as of today’s date
b) Select a customer type of Small/Medium Business
c) Select a contact from the list of available people
d) Select any market region
2. Assign the Calling Card Product to your customer
a) The Calling Card Product is in the Product Group
b) Assign the product as of today’s date
c) Equipment items are not required for this product
d) Assign trainxx as the service number for the product. For
example, user train05 should assign train05 as the service
number
Ensure all participants have active customers and products before

proceeding.
This is the end of the Rating and Billing Overview section. Ask
participants if they have any questions, particularly about the guiding
process, before you proceed.
CB v4.02 Page 15
Billing Operations
Participant Handbook – Rating
Rating xx mins
Learning Objectives
s List event terminology
s Describe the rating architecture
s Describe the location of rating files
s Configuring rating processes
s Create one-off tasks and schedules
s Rate event files
s Check rating results
s Correct rating errors
s Revoke rating
Content Overview
Rating is the process of accepting events into CB and processing them

to generate charges. The charges and the rated events are written to the
database, or to a different server, or to a file for later upload to a
database.
This section examines in detail the entire rating process, from event
terminology through to rating events, checking the results and correcting
rating errors.
Page 16 CB v4.02
Billing Operations
Event Terminology
Depending on where an event is from, or the stage an event is at,
different terms are used to describe the event. These terms are outlined
in the following table.
Event Term Description

Raw event An event generated by a switch or some other
type of device. The format of the event is
usually specific to the device
Mediated event An event pre-processed in some way before
input to CB
Alpha event An event input to CB for normalisation. Raw
and mediated events as well as events
generated from with CB are all considered
alpha events
Normalised event An event converted to CB native event format
Corrupted event An alpha event not conforming to the format
for its source, and hence cannot be normalised
Normalisation error An event where a normalising expression could
event not be evaluated. Normalisation error events
are not rated
Rater error events An event causing an error during rating, such
as the incorrect evaluation of a tariff or a
reference to an undefined service. All previous
charges generated for a rater error event are
discarded
Error event An event in the correct format for its source,
but due to the data in the event, either cannot
be normalised or rated. Normalised error and
rater error events are both error events
Charge An amount associated with an event after it is
rated
Rated Event A normalised event, successfully rated and
output from rating
CB v4.02 Page 17
Billing Operations
Rating Architecture
Display Slide 7 – Rating Architecture
The rating architecture is outlined in the following diagram.

ERB
Event
Rating
Broker
process
Event format
Database
Expressions
Normalising and rating data
Online
Normalised events
Error events
Socket Database cache shared memory segment ERO Charges
ENM
Event
Alpha File
Event Inner-process communication shared memory segment Rating SQL *Loader
events File
Normalisation Normalised Output
process events process
File Charges Socket
Corrupted Service and

events tariff details
ENM error ERT

directory
Event
Rating
process
The processes in rating are the:

• Event Rating Broker (ERB) process
• Event Normalisation (ENM) process
• Event Rating (ERT) process
• Event Rating Output (ERO) process
Only one instance of the ERB can be running at a time. However,

multiple instances of the ENM, ERT and ERO can be running
depending on processing requirements.
Page 18 CB v4.02
Billing Operations
Event Rating Broker (ERB)

Display Slide 8 – Event Rating Broker (ERB)
Rating is controlled by the ERB. All the other rating processes (ENMs,
ERTs, and EROs) run as child processes to the ERB.
The ERB performs the following:

• Provides services to the other rating processes
• Manages the shared memory segments used for caching data from
the database
• Manages communications between the ENM, ERT and ERO
Event Normalisation (ENM)

Display Slide 9 – Event Normalisation (ENM)
The ENM accepts incoming alpha events and converts them into
normalised events.
Multiple ENMs may be configured to process events:

• Contained in a file
In this case, the ENM waits for a command to start normalising
events
• Received on a TCP/IP socket
The ENM listens for events arriving in real time
In either case, the processing flow in an ENM is as follows:

1. The alpha event is parsed, using a Data Interchange Language (DIL)
specification retrieved from the database
Corrupted events (events not conforming to the format for its
source) in a file are appended to an error file of the same name (with
a .e extension) in an error directory. Corrupted events from a socket
are rejected and the host informed
2. The parsed data fields in the input event are assigned to system
variables
CB v4.02 Page 19
Billing Operations
3. The ENM applies expressions to the variables. These expressions

are used to:
a) Validate the data
b) Calculate an equivalent value for the normalised event. For
example, if an input field was three digits long and the
normalised event field expected eight, the expression could pad
the field with leading zeros
4. The variables are reordered to build the normalised event
5. Successfully normalised events are passed to an ERT process for
rating and to an ERO for output. Normalisation error events are
only sent to an ERO for output and are not rated
Page 20 CB v4.02
Billing Operations
Display Slide 10 – ENM Process Flow
The flow of event normalisation is summarised in the following

diagram.
Alpha event
Corrupted events are sent to an error

DIL Specification Alpha event file
parsed
Parsed data fields

assigned to
variables
Expressions:
Expressions - Validate the data
- Calculate values for normalised event
applied to the
variables If an expression fails, event is flagged
as a normalisation error event and sent
to the ERO for output
Variables
reordered to form
the normalised
event
Normalised event
passed to an ERO
and ERT
Summarise the ENM process and ask participants if they have any
questions.
CB v4.02 Page 21
Billing Operations
Event Rating (ERT)

Display Slide 11 – Event Rating (ERT)
The ERT accepts normalised events from the ENM and applies tariffs to
produce rated events and charges. Like the ENM, multiple ERTs may be
configured.
All tariff definitions, derived attributes and functions needed for rating
are preloaded from the database into memory when the rating processes
start.
For each normalised event, the processing flow in an ERT is as follows:

1. The C Party ID in the normalised event matches with an active
service number in the database. The service number matches with a
service instance and a product instance (including any companion
product instances) and a customer node. This is the guiding process
discussed earlier
If an active service is not found, rating fails and the event is flagged
as a rater error event
2. For each tariff associated with the product instance, plus any global
tariffs, the eligibility expressions are evaluated:
a) If they evaluate false, the tariff is discarded and the ERT moves
on to the next tariff
b) If they evaluate true the charge expressions for the tariff are
evaluated to generate charges records
If a charge expression causes an error, the event is flagged as a
rater error event and any charges generated to that point are
discarded
If an event fails to generate any charges, the event is flagged as
a rater error event
Page 22 CB v4.02
Billing Operations
3. The account number specified in the charge category instance is

associated with each charge
Usually, this is the account that corresponds to the account type
specified in the charge category for the tariff. However, the charge
category can be overridden by charge categories specified in the:
− Product definition
− Customer node
− Customer type
− Service type
4. Each charge is passed to an ERO for output
Display Slide 12 – ERT Process Flow
The flow of event rating is summarised in the following diagram.
Normalised event
C Party ID
Guiding
matches with
service number,
matches with
product instance
Eligibility expressions evaluated, and if

true, the charge expressions evaluated
Tariffs associated to generate charges
with the product If a charge expression causes an error,
instance are the event is flagged as a rater error
evaluated event and charges up to that point are
discarded
Events failing to generate any charges

are flagged as a rater error event
Account number
from the service is
associated with
the charge
Charge passed to
an ERO for output
CB v4.02 Page 23
Billing Operations
Summarise the ERT process and ask participants if they have any
questions.
Event Rating Output (ERO)

Display Slide 13 – Event Rating Output (ERO)
The ERO takes normalised events from the ENM and charges from the
ERT, and outputs them to:
• The database
• A TCP/IP socket, in the case of real time rating
• A file for later upload to a database
Like the ENM and ERT, there may be multiple EROs configured. Each
ERO is linked to at least one ENM, and maintains this link for all events
and charges.
For EROs configured to output to the database, the details of

successfully normalised and rated events are written to the
NORMALISED_EVENT and CHARGE tables. The details of
normalisation error or rater error events are written to the
NORMALISED_EVENT_ERROR table.
Exercise 2 – Rating
Answer the following questions about rating.
1. List the four processes within rating and describe their function.
Page 24 CB v4.02
Billing Operations
2. What is the difference between corrupted events, normalisation

error events and rater error events?
3. Describe the process known as guiding that determines the list of

tariffs to evaluate for an event.
4. The details of successfully normalised and rated events are written

to which two tables in the database?
CB v4.02 Page 25
Billing Operations
Ask participants if they have any questions about the rating architecture
before you proceed to the next section.
Page 26 CB v4.02
Billing Operations
Location of Rating Files

As stated before, rating may be performed on events:
• Contained in a file
• Received on a TCP/IP socket
The difference is that rating event files is operator initiated while rating
events received via TCP/IP is configured to happen automatically.
For the purposes of this training, we will discuss rating event files,
rather than via TCP/IP.
Display Slide 14 – Location of Rating Files
Rating event files requires four directories on the server:

1. input
2. archive
3. error
4. log
Event files ready for rating reside in an input directory. The

environment variable $ATA_DATA_SERVER_INPUT points to the
system input directory.
After rating, event files are moved from the input directory to an archive
directory. The environment variable
$ATA_DATA_SERVER_ARCHIVE points to the system archive
directory.
Corrupted events are written to an error file with a .e extension in an

error directory. The environment variable
$ATA_DATA_SERVER_ERROR points to the system archive
directory.
The log.out file in a log directory contains status information about all
CB processes, including rating.
CB v4.02 Page 27
Billing Operations
A suggested structure for these directories is shown in the following

diagram.
home directory
data
server
input archive error log
data_file data_file data_file.e log.out
The log.out file contains

Successfully normalised files
progress and status details
are moved to the archive
from the rating process
directory
Corrupted events are written to
a file in the error directory with
the original file name and a '.e'
extension
Rating Files from Multiple Sources

For systems with multiple ENMs, each may be configured with its own
directory structure to better manage incoming event files. For example,
separate subdirectories can be set up within the input, archive and error
directories for each ENM.
Page 28 CB v4.02
Billing Operations
Configuring Rating Processes

Display Slide 15 – Configuring Rating Processes
As stated previously, multiple instances of the ENM, ERT and ERO

processes can be configured to meet the processing requirements of a
service provider. For example, it may be determined that while the
number of ENM and ERO processes are sufficient for the volume of
events coming in and going out, there are not enough ERT processes to
process the events in a timely manner. In this case additional ERTs
could be configured.
Other examples of when additional rating processes may be required

include:
• The volume of events that need to be rated requires additional
processes
• Events from different sources, such as event stored in files and
events received in real time from a TCP/IP socket
• Different types of events, such as wireless and IP/Data type events
In addition to the number of rating processes you can configure, the

attributes of individual processes can be fine-tuned to enhance rating
performance.
There are no absolute guidelines for determining the optimal number of

rating processes or attributes for individual processes. A configuration
that provides good rating performance for one service provider may
provide poor performance for another. The only way to determine the
'best' configuration is by analysis of event volumes and event
characteristics versus current rating performance, and then using that
information to experiment with different configuration options.
Configuration Items
All of the rating processes (plus other types of processes) started and
maintained by the system are determined by Configuration Items set up
in the system. Creating new configuration items result in new processes.
The configuration item for a process specifies all of the attributes for
that process. Each process has its own configuration item.
CB v4.02 Page 29
Billing Operations
Like other entities in CB, configuration items are created from the
characteristics defined in configuration item types.
Configuration items can be created and maintained from the CB client

by selecting Maintenance ð Server ð Configuration Items, or by using
the cfg configuration utility at the UNIX command line.
This training concentrates on maintaining configuration items via the

CB client only. Information on how to use the cfg configuration utility is
found in the System Administration Guide for Singl.eView Convergent
Billing v4.02.
Page 30 CB v4.02
Billing Operations
Guided Practice 1 – View an ENM Configuration Item

The purpose of this guided practice is to view an ENM configuration
item and its attributes.
Perform the following:
1. Select Maintenance The Configuration Item Search form displays.

ð Server ð
Configuration
Items
The list of configuration items displays in the bottom part of the form.
2. Click
In the above list, note the three ENM configuration items, ENM1,
ENM2 and ENM3. The configuration item type for each is ENM.
CB v4.02 Page 31
Billing Operations
3. Select and display

the ENM1
configuration item
The Base Attributes tab determines the attributes of the process while
the Related Attributes tab determines how the process works with other
processes. Not all configuration items have entries on the Related
Attributes tab.
The attributes on the Base Attributes tab are outlined in the following
table.
Attribute Name Description

ENABLED Whether the process is started
automatically by the ERB
COMMAND_LINE_ARGS Command line arguments used at
process startup
For example, -d 64 turns debugging on
for the EPM. The command line
arguments available are listed in the
Singl.eView Convergent Billing System
Administration Guide
Page 32 CB v4.02
Billing Operations

INPUT_METHOD The input method for events
Options are file and socket
INPUT_SERVICE If INPUT_METHOD is socket, the
name of TCP/IP service the ENM
listens to for events
HOME_DIR If INPUT_METHOD is file, the
directory from which event files for
processing are retrieved
ARCHIVE_DIR If INPUT_METHOD is file, the
directory to which event files are moved
after processing
FILE_TYPE The Normalised Event File Type for the
ENM
SYNC The number of events sent to the ERO
for output before the ENM stops and
waits for the ERO to process all the
events
The default value is 1000
EVENT_TYPE The Normalised Event Type for the
ENM
ERB_MACHINE The name of the system running the
ERB
Must be (or equate to) a fully qualified
Domain Name Server (DNS) name or
an IP address
INPUT_HOSTS If INPUT_METHOD is socket, a
comma-delimited list of DNS names or
IP addresses from which the ENM may
accept socket connections
ERB_SERVICE The TCP/IP service for communications
with the ERB
CB v4.02 Page 33
Billing Operations

ERROR_DIR The directory to which event that cannot
be parsed by the ENM are written
Events are appended to a file with the
same name as the input file, with a .e
extension
INTERNAL_ERO Not used
EVENT_SOURCE If INPUT_METHOD is socket, a DNS

name or IP address to be associated
with all events processed from a remote
host
INACTIVITY_TIMEOUT The maximum time the ENM waits for
events from a TCP/IP socket before
closing the connection
The default is 60 seconds. If set to 0, no
timeout occurs
OPERATOR If INPUT_METHOD is socket, an
operator ID to be associated with all
events processed from a remote host
POLL_TIMEOUT If INPUT_METHOD is socket, while
waiting for events on its TCP/IP socket,
the frequency (in seconds) that the
ENM checks for commands from the
ERB
GLOBAL_DA_CACHE_ The maximum number of global
SIZE derived attribute tables that may be
cached at any one time
If the limit has been reached and
another derived attribute table is to be
cached, the least recently used table is
removed
If no value or 0 is specified, cache size
is unlimited
Page 34 CB v4.02
Billing Operations

FILE_TIMEOUT If INPUT_METHOD is socket, the
frequency with which the ENM closes a
TCP/IP socket connection and opens a
new one
The TCP/IP socket connection acts like
a virtual event file. If no value or 0 is
specified, the timeout never occurs
FILE_EVENT_ If INPUT_METHOD is socket, the
THRESHOLD maximum number of events received
for rating from the TCP/IP socket
connection
If no value or 0 is specified, the number
of events is unlimited
SYNC_TIMEOUT The maximum amount of time (in
seconds) permitted before the ENM
waits for the ERO to re-synchronise
The ENM pauses until the last event
that it sent has been processed by the
ERO. If this parameter is set, the system
effectively guarantees that events and
their charges will appear in the database
no longer than SYNC_TIMEOUT
seconds after they were rated
This attribute is applicable only if
INPUT_METHOD is socket
CB v4.02 Page 35
Billing Operations

QUEUE_CONNECTIONS If INPUT_METHOD is socket, whether
the ENM queues TCP/IP socket
connection attempts
If true, when the ENM accepts a TCP/IP
socket connection attempt, all
subsequent attempts are queued. When
the current connection closes, the ENM
accepts the next connection on the
queue
If false, when the ENM accepts a
TCP/IP socket connection attempt, all
subsequent attempts are ignored. When
the current connection closes, the ENM
listens on the socket for the next
connection attempt
The default value is true
The attributes on the Related Attributes tab are outlined in the following
table.
Note that each attribute is repeated for each ERO and ERT process.

ERT_PRIORITY The priority assigned to this ERT
Normalised events are sent to the ERT
with the highest priority. 1 is the highest
priority
ERO_PRIORITY The priority assigned to this ERO
Normalised events are sent to the ERO
with the highest priority. 1 is the highest
priority
ERT_THRESHOLD The maximum number of events that
may be queued to this ERT before
sending events to the next highest
priority ERT
Page 36 CB v4.02
Billing Operations

ERO_THRESHOLD The maximum number of events that
may be queued to this ERO before
sending events to the next highest
priority ERO
ERT_GROUP The group number for the ERT
ERTs may be grouped, with each group
performing a different part of rating for
each event. For example, the ENM can
send multiple copies of each event to an
ERT in each group (selected on the
basis of priority and threshold). This is a
form of parallel tariffing
The rating engine can apply different tariffs to the same normalised
event in one pass. This is known as parallel tariffing, and makes it
possible to apply separate tariffs that calculate charges to customer,
commissions, taxes, loyalty points or competitors tariffs (for bill
comparisions).
Parallel tariffing simplifies rating as each event requires only a single

pass through the rating engine. However, it also increases the ERT
processing load. It may be appropriate to provide two or more ERT
processes for each ENM process to avoid processing bottlenecks.
How the ENM Selects an ERT and ERO Process

Display Slide 16 – Selecting an ERT and ERO
The following criteria determines the ERT and ERO processes to which
normalised events are passed from the ENM for further processing:
• The process with the highest priority
• If more than one process has the same priority, the threshold values
specified in the ENM are examined. The process with the number of
queued events furthest away from its specified threshold is selected
CB v4.02 Page 37
Billing Operations
• If all processes with the highest priority have exceeded their

threshold values, then the above criteria is repeated for the processes
with the next highest priority
Exercise 3 – View Other Rating Configuration Items
Allow a maximum of 15 minutes for this exercise (5 minutes per

process).
View the other rating configuration items including the ERB, ERO and
ERT. Use online help (Help ð Reference Information ð Index) to
search for and display the base attribute descriptions for each.
Page 38 CB v4.02
Billing Operations
Guided Practice 2 – Create an ENM Configuration

Item
The purpose of this exercise is to create your own ENM configuration
item, which in turn will set up your own ENM process for use in rating
events.

ð Server ð
Configuration
Items
The Configuration Item form displays in Inserting mode.
2. Click
3. Select ENM in the

Configuration Item
Type field
4. Enter ENMxx in the
Configuration Item
Name field
5. Complete the fields
on the Base
Attributes tab as
shown
CB v4.02 Page 39
Billing Operations
6. Select the Related

Attributes tab
7. Enter 1 in one of the
ERT_PRIORITY
field and 2 in the
other
8. Enter 1 in one of the
ERO_PRIORITY
field and 2 in the
other
9. Enter 10 in all of the
THRESHOLD fields
Remind participants that what they enter in the ERO1/ERT1 or

ERO2/ERT2 PRIORITY fields determines what ERO and ERT will be
used for their rating processes.
The Configuration Item form displays in Viewing mode.

10. Click
These changes do not take effect until the ERB is shutdown and
restarted. Your instructor will do this now.
biBkrStop&(1) in the Expression Test form or ecp "biBkrStop&(1) on

the Unix command line to stop the ERB and all related child processes.
Then biBkrStart&(1) or ecp "biBkrStart&(1) to start the ERB.
Check the log.out file to ensure all processes start up ok.
More information on how to configure rating processes is the System

Administration Guide for Singl.eView Convergent Billing.
Page 40 CB v4.02
Billing Operations
Managing Rating Tasks

Before the process of actually rating an event file begins, there are some
considerations that may assist in a successful rating process. Similarly,
there are processes that must be undertaken after the rating process in
order to check that events have rated successfully.
This section looks at the end to end processes needed to prepare for
rating, execute rating and to check the rating results.
Pre-rating Tasks
There are certain tasks that can be undertaken prior to running the rating
process that will minimise problems during rating. These tasks could
form part of a checklist that identifies the tasks as well as who has
responsibility for the task.
Display Slide 17, 18 & 19 – Pre-rating Tasks
Pre-rating tasks that could be completed include:

• Identify any pending tasks that may run during the proposed rating
activity that would impact or compete for resources
This would typically be part of the operational plan, which is usually

developed by a system architect. Billing Operations staff need to know
what tasks are running, therefore this should still be part of a pre-rating
checklist.
• The running of a rating task can consume substantial server
resources and requires frequent database access. Demand for server
and database resources may reduce performance, both for the rating
process itself, and for concurrent CB processes. If possible, rating
tasks should be run when other system demands are at a minimum.
• If scheduled tasks are identified, these can be modified so they do
not impact rating.
CB v4.02 Page 41
Billing Operations
It is important to note that the following high-risk tasks should not

be run during rating:
− dbanalyse
− DVP checks
− Update Charge Categories
− Update Lists
− Rotating/sorting partitions.
Other possible risks include running event management reports that are
reporting on the same time period as the events being rated. These
reports may not give accurate results depending on the stage of the
rating task when the report is run.
• Check that all required rate changes have been made to the rate
tables that are needed for this billing period. This is most likely a
business responsibility
• Correctly name all event files for rating, and place in the correct
directory
• Create at least one ENM process for rating
• Check that partitions have been sorted
• Run all server processes including the TUXEDO processes
For more information on TUXEDO processes refer to the Convergent

Billing System Administration Guide V5.00.
• Check that Update Lists and Update Charge Categories tasks are
either not required or have already been run (changes in list and
charge category definitions are not automatically extended to
existing product instances)
• Check that there are no enmX.sts (where X represents the sequence
number of the enm configured in the production environment) files
in the input directory or subdirectories
An enmX.sts is an enm status file that is created while a rating task
is in progress. It is removed at the end of a successful rating job. If
the rating task is not completed, the enmX.sts file remains on the
server to indicate where in the event file processing ceased.
Page 42 CB v4.02
Billing Operations
Any existing enmX.sts files must be removed before the specific

ENM server process can be restarted.
• Check that the mandatory server processes required by rating are
running including:
- Backend Monitor Process (BMP)
- Scheduled Task Dispatcher (STD)
- Task Launch and Monitor (TLM)
The TLM executes tasks as server processes and monitors their

progress. When a task has been performed, the TLM process notifies the
STD process of its completion.
- Event Rating Broker (BKR)
- Event Rating Process (ERT). If there are multiple rating streams,
ensure the ERT for your rating task is active
- Event Rating Output Process (ERO). If there are multiple rating
streams, ensure the ERO for your rating task is active
- Event Normalisation Process (ENM). If there are multiple rating
streams, ensure the ENM for your rating task is active
If a sound operational plan exists, operations staff would be aware that

mandatory server processes are running.
Scheduling Server Tasks

Most server tasks in CB, including rating tasks, are controlled and run
automatically by the STD and the TLM. These processes are
collectively referred to as the Scheduler.
The scheduler is used to define tasks that are run regularly at pre-
defined intervals, as well as tasks that run only once (one-off tasks).
One-off tasks can run immediately or at a future date and time.
Once set up, these tasks run automatically at the chosen time without
any further intervention required, and the user is notified on completion
of the task.
CB v4.02 Page 43
Billing Operations
Every schedule has a schedule type. A scheduled task uses the schedule
type to determine what program to run and how to run it. The schedule
type also defines the parameters that the user needs to provide when
defining a schedule of this type.
Page 44 CB v4.02
Billing Operations
One-Off Tasks and Schedules

Display Slide 20 – One-Off Tasks and Schedules
Rating and billing tasks may be run either as a:

• One-off task
• Schedule
Rating tasks may be run as schedules, but are usually run as one-off
tasks allowing you to run rating on demand. Billing tasks must be run as
schedules, allowing them to run at specified intervals with specific
parameters.
Schedule Types
Whether run as a one-off task or as a schedule, the details of the task to
run are defined in a schedule type. A schedule type definition specifies
among other things, the command to execute on the server.
An example schedule type is shown below.
In the Rate Files schedule type shown above, the server command to
execute is rate_files.
CB v4.02 Page 45
Billing Operations
Note that the majority of rating and billing schedule types are already
defined.
One-Off Tasks
The simplest way to run a task is as a one-off task using the One-Off
Task form. The form is accessed by selecting Server Tasks ð One-off
Task. An example of the form is shown below.
In the above form, the Rate Files schedule type is already selected.
The elements of the One-Off Task form are outlined in the following
table.
Element Description
Schedule Type field The schedule type, and hence the task to
execute
Selecting a schedule type and tabbing out of
the field displays all of the parameters for the
schedule type in the Parameters section
Page 46 CB v4.02
Billing Operations
Element Description
Email Address field The email address to notify when the task
completes
An email message is only sent if the operator is
not logged on when the task completes
Effective Date fields Items dated up to and including this date and
time are available for use by the one-off task
For example, with a Rate Files schedule type,
event files dated on or after the Effective Date
are available to be rated
Start Date fields The date and time the one-off task starts
Parameters section The parameter fields associated with the
schedule type selected
Display Task button Display the status of a saved one-off task
The button is only accessible after the one-off
task is saved.
Exercise 4 – Schedule Types and One-Off Tasks

1. Select Maintenance ð Server ð Schedule Types to display the
different schedule types available.
Select and display at least the Rate Files and the Standard Bill Run
schedule types. In particular, note the Server Command field for the
different schedule types.
What is the Task Validation field used for?
Entity Validation for parameters fields on the One-Off Task or

Schedule forms.
2. Select Server Tasks ð One-off Task to display the One-Off Task
form.
Select different schedule types in the Schedule Type field to see the
difference in the Parameters section
CB v4.02 Page 47
Billing Operations
Schedules
Schedules allows you to specify the dates and frequency that a task
executes as well as the parameters for the task. Selecting Server Tasks
ð Schedules displays the Schedule Search form that allows you to
search for existing schedules or create new ones.
An example Schedule form is shown below.
In the above form, the Standard Bill Run schedule type is already
selected and the scheduling fields are completed.
The elements of the Schedule form are outlined in the following table.
Element Description
Schedule Name field The name of the schedule
Description field The description of the schedule
Settings tab Contains the fields to specify the schedule type
and the scheduling details
Page 48 CB v4.02
Billing Operations
Element Description
Parameters tab Contains the fields to specify the parameters
for the schedule type
The parameters vary for each schedule type
Schedule Type field The schedule type, and hence the task to
execute
Selecting a schedule type and tabbing out of
the field displays all of the parameters for the
schedule type on the Parameters tab
Email Address field The email address to notify when the task
completes
An email is only sent if the operator is not
logged on when the task completes
Preschedule count The number of instances of the schedule to
field create in the future
For example, a Preschedule Count of 2 causes
two schedules to be created in advance
Repeat Type field The frequency at which the schedule is
repeated
For example, every hour, every day or the last
day of every month
Repeat Units field The multiplier of the repeat type
For example, a schedule with a Repeat Unit of
7 and a Repeat Type of Day, is scheduled to
run every week
Schedule Status field Whether the schedule is Active, Failed or
Pending. Schedules created via the Preschedule
Count feature are created in the future with a
status of Pending
First Date fields The first date and time the schedule runs
Last Date fields The last date and time the schedule runs
CB v4.02 Page 49
Billing Operations
Element Description
Effective Date fields Items dated up to and including this date and
time are available for use by the schedule
For example, with a Standard Bill Run
schedule type, charges dated up to and
including the Effective Date are available to be
displayed on an invoice
Page 50 CB v4.02
Billing Operations
Rating Event Files

Rating event files is performed using the Rate Files schedule type, either
as a one-off task or as a schedule.
The Rate Files schedule type, and most of the other rating schedule
types, are usually run as one-off tasks because rating is not run at
regular frequencies.
In either case, the schedule type has parameters that must be completed
for the task to execute correctly. These parameters are outlined in the
following table.
Rate Files Parameter Description

ENM Process The ENM process to normalise the events
The process selected should be one
configured for the type of file or type of
event being rated
File Pattern The event files to rate
Wild cards are permitted. For example,
train*.evt could be entered to rate all of the
files starting with train and ending with the
.evt extension
ENM File Type The type of file to rate
The Normalised Event File Type chosen in
this field determines how the events are
parsed plus any expressions used in the
parsing
The type selected should match the type of
file being rated
ENM Event Type The Normalised Event Type chosen in this
field determines how to display the
resulting normalised events
The type selected should match the type of
events being rated
CB v4.02 Page 51
Billing Operations
Rate Files Parameter Description

Event Source The source of the file to rate
The operator can put anything in this field
such as their user name or where the event
file came from. This information is
included in each normalised event
generated by rating to assist with
identification
An example of a completed One-Off Task form with a Rate Files

schedule type is shown below.
More on ENM File Types and ENM Event Types

Display Slide 21 – ENM File Types and ENM Event Types
Confusion may occur between the purpose of the Normalised Event File
Type and Normalised Event Type. They serve two distinct purposes.
Page 52 CB v4.02
Billing Operations
A Normalised Event File Type defines how incoming events are parsed
using DIL specifications or decoding expressions. An example
Normalised Event File Type definition is shown below.
A Normalised Event Type definition specifies the entity validation

required to properly display the event details of that type. An example
Normalised Event Type definition is shown below.
CB v4.02 Page 53
Billing Operations
Exercise 5 – Performing Rating

Answer the following questions:
1. List the four directories on the server used by rating and describe
what they contain.
input – contain the event files to be rated
archive – after rating, event files are moved to an archive directory
error – corrupted events are written to an error file with a .e extension

in an error directory
log – contains status information about all CB processes, including

rating
2. What are the two ways of running the Rate Files schedule type?
As a one-off task or as a schedule
Page 54 CB v4.02
Billing Operations
Guided Practice 3 – Rate Files

The purpose of this guided practice is to:
• Familiarise yourself with the Rate Files schedule type and its
parameters
• Rate an event file using a one-off task
11. Using Windows

Explorer and
information provided
by your instructor,
copy an event file
from your C: drive
into the appropriate
directory on the
server
12. In CB, select Server The One-Off Task form displays.
Tasks ð One-off
Task
13. Select Rate Files in The list of parameters for the schedule type display in the Parameters
the Schedule Type section of the form
field
14. Press Tab on the
keyboard
CB v4.02 Page 55
Billing Operations
15. Select ENMxx in the

ENM Process field
16. Enter
billing_opsxx.evt in
the File Pattern field
17. Select
SavilleExpress
Native v4 format in
the ENM File Type
field
18. Select GSM Usage
in the ENM Event
Type field
19. Enter your user
name in the Event
Source field
The one-off task is saved.
20. Click
21. When the task
completes, view the
results to ensure it
completed
successfully
Leave the form open

for the next guided
practice
Answer the following question:

1. What is the difference between the ENM File Type and ENM Event
Type parameters?
The ENM File Type specifies the normalised event file type (how the
events are parsed)
The ENM Event Type specifies the normalised event type (how the event
record is displayed)
Page 56 CB v4.02
Billing Operations
Rating Results
Display Slide 22 – Rating Results
After rating has completed, you can confirm it ran successfully or not by
checking the:
• Task Status field and Results tab on the Task form of a completed
Rate Files task
• Input, archive and error directories
• log.out file
• Normalised events
• Error events
Task Status and Results

Viewing the Task Status field and Results tab on the Task form provides
the first level of detail as to whether rating ran successfully.
A Task Status of:

• Success indicates the task completed successfully. However, errors
in the processing of the event records may still have occurred
• Failure indicates the Rate Files task was unsuccessful. The reasons
for failure display on the Results tab. Perhaps one of the rating
processes (ENM, ERT or ERO) was not running
The Results tab also lists information such as the database, the effective
date and the name of the event file rated.
CB v4.02 Page 57
Billing Operations
An example of the Task form is shown below.
Input, Archive and Error Directories

When rating is complete, the rated event file is moved from the input
directory to the archive directory.
Corrupted error events are written to a file in the error directory. The file
has the same name as the original event file, but with a .e extension.
log.out File
The progress of all tasks on the system, including rating, is recorded in
the log.out file in the log directory.
You can view the contents of this file by using:

• The LOG command in UNIX
• A UNIX text editor like vi
• A Windows text editor like Notepad, provided you have access to
the UNIX file structure through Windows
Page 58 CB v4.02
Billing Operations
Some example text from a log.out file is shown below.

<02818> Thu Aug 2 15:14:29 2001
<M> enm: Commenced processing "train02082001.evt"
using file type "SavilleExpress native" as at 08/02/01
errno = 0, pid = 13105, login = gnoble
<02820> Thu Aug 2 15:14:30 2001

<M> enm: Completed processing "train02082001.evt"
14 events processed in 0.18 seconds (78.83 events/second)
<02776> Thu Aug 2 15:14:32 2001

<M> ecp: ENM 2 completed processing file
"train02082001.evt"
Normalised Events
Successfully normalised and rated events are written to the
NORMALISED_EVENT table in the database. The Normalised File
form displays the entries in this table for an event file.
The form lists the number of events input, output and not rated (error
events). Details about the individual events can also be displayed.
Examples of the Statistics and Events tabs on the Normalised File form
are shown below.
CB v4.02 Page 59
Billing Operations
Error Events
Normalisation and rater error events are written to the NORMALISED_
EVENT_ERROR table in the database. The Normalised Event Error
form displays the individual error events in this table.
An example of the Normalised Event Error form is shown below.
Page 60 CB v4.02
Billing Operations
Exercise 6 – Rating Results

The purpose of this exercise to check the success or otherwise of the
rating task completed in the previous exercise.
The exercise is divided into five parts, one for each of the methods
outlined above.
Part A – Task Status and Results
View the Task Status field and Results tab on the Task form.

1. Did the task complete successfully?
2. Does this mean that rating completed successfully without error and
that all records rated correctly?
No, just the task executed successfully.
Part B – Input, Archive and Error Directories
Using Windows Explorer, view the contents of the input, archive and
error directories.

1. In what directory does your event file now reside?
2. What does this mean?
3. Is there a .e file in the error directory as a result of your rating task?

What does this signify?
CB v4.02 Page 61
Billing Operations
Part C – log.out File
View the log.out file. The information about your rating tasks is at the
end. Look for references to the ENM and the name of your event file.
Page 62 CB v4.02
Billing Operations
Guided Practice 4 – View the Normalised Events

The purpose of this guided practice is to view the normalised events for
your rating task.
1. Select Server Tasks The Normalised File Search form displays.

ð Events ð View
Normalised Files
and Events
2. Enter
billing_opsxx.evt in
the Search Criteria
field
A list of event files matching the search criteria display in the bottom
3. Click part of the form.
CB v4.02 Page 63
Billing Operations
4. Select the file from The Normalised File form displays in Viewing mode.
the list and click
This form displays:

• Statistics about the rated event file, including the rated event count,
error event counts and the corrupt event count
• Details about the rated and error events

1. How many of your events were:
a) Rated? If using the sample event file, six
b) Errors? Three
c) Corrupted? One
Page 64 CB v4.02
Billing Operations
5. Select the Events tab

to view the details
about the rated
events
6. Select an event and The Normalised Event form displays in Viewing mode.
click

1. For your selected event, what is the:
a) Duration: If using the sample event file, they range from 191 to
200
b) Event Class: Usage
c) Event Type: GSM National
CB v4.02 Page 65
Billing Operations
d) Charge Subtype: Local (National)

e) Date of the event: Today’s date
f) C Party Number: trainxx where xx is the user number
2. What is the significance of the C Party Number?
It is the number of the service to be charged for the event. It is used to

guide back to the product definition and the tariffs for the product.
7. Close the
Normalised Event
form and select the
Error Events tab on
the Normalised File
form to view details
about the error
events
Page 66 CB v4.02
Billing Operations
8. Select an event and The Normalised Event Error form displays in Viewing mode.
click
The top part of the form displays event and error details. The bottom
part of the form contains the File, Settings, Date, Party and Attribute
tabs. These tabs display all the details about the event.
This form can also be accessed through the menu by selecting Server
Tasks ð Events ð View/Assign Error Events and searching for an
event error record.

1. From the information provided on the File, Settings, Date, Party
and Attributes tabs of this form, what are the causes of the event
errors in your event file?
If using the sample event file, the first two errors have an incorrect C
Party ID, the third has an invalid date (2000 not 2001).
CB v4.02 Page 67
Billing Operations
Correcting Rating Errors

Display Slide 23 –Correcting Rating Errors
Errors in the rating process could result in any of the following:

• The rating task fails
• Error events (normalised error and rater error events)
• Corrupted events
• Generated charges are incorrect
The Rating Task Fails

If the rating task completes with a Task Status of Failure, the steps to
correct this are:
1. Check all the required server processes are running
2. Check the causes of failure reported of the Results tab of the Task
form
3. Submit the rating task again
Corrupted Events
Corrupted error events received from a remote host are rejected.
Depending on how the systems are configured, an error message may be
sent back to the host.
Corrupted events in an input file are written to an error file in the ENM
error directory. The file has the same name as the input file, with a .e
extension. If the error file already exists, the corrupted events are
appended to the end of the file.
Page 68 CB v4.02
Billing Operations
The steps to correct corrupted events are:

1. Examine the events in the error file to determine the cause of the
errors
a) Intermittent errors may simply be the result of a data
transmission error
b) Consistent errors may indicate a problem at the source of the
records
c) A total failure may mean you are rating with the wrong ENM
File Type. For example, you may have selected SavilleExpress
Native v4 format in the ENM File Type, when the event file is
of a different type
2. Depending on the service provider’s business rules, correct the
corrupted events in the file
a) For a relatively small number of events, correct them manually
or by a script
b) For larger numbers, you may need to refer the problem back to
the source of the events
3. Rename the file with the corrected events and move it to the input
directory
4. Rate the file
Error Events
Error events are written to the NORMALISED_EVENT_ERROR table
in the database. The steps to correct error events are:
1. If the error events are not required, delete them
Use the Purge Error Events schedule type to do this. More
information about this and other schedule types you can use in
rating, is found in the Rating Schedule Types section on page 72
2. Examine the event to determine if the error is caused by the event
itself, or by some other problem, like an incorrect tariff definition
a) If the event is the problem, correct it, assign it to a re-rating file
and re-rate it
b) If it is a configuration problem, like an incorrect tariff, correct
the configuration and re-rate the event or events
CB v4.02 Page 69
Billing Operations
Incorrect Charges
While rating may be successful and generate normalised events and
charges, the charges may be wrong. The steps for this are:
1. Revoke or roll back the entire rating process. All normalised events,
charges and error events generated are deleted and the original event
file is moved from the archive directory to the input directory
Use the Revoke File and move back schedule type to do this. More
information about this and other schedule types that you can use in
rating is found in the Rating Schedule Types section on page 72
2. Correct the problem resulting in the wrong charges
3. Rate the file again
Page 70 CB v4.02
Billing Operations
The entire process of correcting rating errors is summarised in the

following diagram.
Start
Event File
Rating
Check the cause

Rating task
No of failure and
successful?
correct
Yes
Correct events,
Corrupted rename error file
Yes
events? and move to the
input directory
No Specify criteria to
select error events
for re-rating
Correct the Error events Yes
Error events? Yes
problem required?
Assign error
events to a
No No re-rating file
Are charges
Roll back rating No Purge error events
correct?
Yes
Finish
Summarise the process of correcting rating errors and ask participants

if they have any questions.
CB v4.02 Page 71
Billing Operations
Rating Schedule Types

To correct rating errors, there are rating schedule types for such things
as deleting unwanted error events, re-rating error events and rolling back
an entire rating process.
All of the rating schedules types, plus a brief description of each, are
listed in the following table.
Rating Schedule Description

Type
Purge Error Events Selectively delete error events from the
database
Purge Events (non Selectively delete normalised events and

Error) associated charges from the database
Purge Files Delete files from a specific directory on the
server
Rate Files Rate event files using a specific ENM
Re-rate Error Events Re-rate error events assigned to a re-rating file

Re-rate Error Events Selectively re-rate error events without
(bulk) assigning them to a re-rating file
Re-rate Events Selectively re-rate previously rated events.
(bulk) Previous charges are discarded and recalculated
Re-rate File Re-rate a specific event file. Previous charges
are discarded and recalculated. Error events in
the file are also re-rated
Revoke Event File Deletes all normalised events, error events and
charges from the database
Revoke File and Deletes all normalised events, error events and
move back charges from the database and moves the event
file from the archive directory back to the input
directory
Revoke Reprocessed After completion of a Revoke Event File or
File Revoke File and move back schedule type, this
recreates the original re-rating file
Page 72 CB v4.02
Billing Operations
Exercise 7 – Correcting Corrupted Events

Following on from the previous guided practice, the corrupted events
and error events need to be corrected.
In this exercise, you will correct the corrupted events and in the
following guided practice you will use two different methods to correct
the error events.
While this is an exercise to correct corrupted eve nts, it is worth noting

that service providers may not actually fix corrupted event. Depending
on their business rules, they may send them back to the source.
Perform the following steps:

1. Using TextPad, or some other text editor, examine the file in the
error directory to determine the reason for the corrupted event
2. Correct the file
In this case, change the word 'error' to '60000'

3. Move the corrected file back to the input directory
Use the UNIX mv command or the features of Windows Explorer if
you have Windows access to the server
4. Rate the file
5. Ensure the file rates successfully, using the list provided in the
Rating Results section on page 57
CB v4.02 Page 73
Billing Operations
Guided Practice 5 – Correcting Error Events

There are two methods for dealing with error events:
1. Correct the events, assign them to a re-rating file and rate the file
2. Correct the events and selectively re-rate them
Both of these methods are outlined in the following steps.
Method 1 – Assigning Error Events to a Re-Rating File
1. Display the
Normalised File
form for
billing_opxx.evt
Page 74 CB v4.02
Billing Operations
2. Display the details of

the first error event
The Normalised Event Error form displays in Updating mode.

3. Click
Note the button is now active.
4. Correct the field or The New Rerated File form displays.

fields causing the
error This form allows you to create a file to which you can assign your
corrected events.
Note the Category
field on the
Attributes tab is
mandatory
5. Select the File tab
again
6. Click
CB v4.02 Page 75
Billing Operations
7. Enter
trainxx_correct.evt
in the File Name
field
8. Enter your user
name in the Event
Source field
The New Rerated File form closes.

9. Click
10. Click The Normalised Event Error form redisplays in Viewing mode.
11. Close the The Normalised File form redisplays.

Normalised Event
Error form
12. Display and update The Assign/View Existing Rerated File form displays.
the next event error
13. Select the File tab
14. Click
Page 76 CB v4.02
Billing Operations
The name of the file you created for the first error event displays in the
15. Click bottom part of the form.
16. Select the rerated file The Normalised Event Error form redisplays in Updating mode.
you created for the
first error event and
click
CB v4.02 Page 77
Billing Operations
17. Click The Normalised Event Error form redisplays in Viewing mode.
Note the File Name and Record Number fields in the Rerated File
section on the File tab of the form.
18. Run a one-off task
using the Re-rate
Error Events
schedule type

1. Based on the information displayed on the Results tab when the task
completes, what is the first operation the schedule type performs?
Creates an event file in the input directory.
View the normalised events for the rating task. If they did not rate
successfully, work through the process again to fix the events and re-
rate them again.
Page 78 CB v4.02
Billing Operations
Method 2 – Selectively Re-Rate Error Events
The second way to deal with error event is to selectively re-rate them.
While this guided practice only gets participants to selectively re-rate a

single error event, this feature is typically used to re-rate hundreds of
events at a time.
1. Display the details of

the third error event
The Normalised Event Error form displays in Updating mode.

2. Click
3. Correct the field or The Normalised Event Error form displays in Viewing mode.
fields causing the
error
4. Click
CB v4.02 Page 79
Billing Operations
5. Create a one-off task

of schedule type Re-
rate Error Events
(bulk)
The optional parameters for this schedule type allow you to specify
which error events to re-rate. All of these parameters are outlined in the
following table.
Parameter Description
File Process Start Date The dates between which the events were
and originally rated
File Process End Date
Base Event File Name The original event file
Event Start Date The dates between which the events
and occurred
Event End Date
Error Message Id The error code attached to the error events
Page 80 CB v4.02
Billing Operations
Parameter Description
Event Source The information entered in the Event
Source field of the original Rate Files task
Event Type The normalised event type of the error
events
File Type The normalised event file type of the
original event file
File Record Start Nr The range of events within the original
and event file
File Record End Nr
C Party Id C Party ID of the error events
Event Where Clause An SQL where clause on the
NORMALISED_EVENT_ERROR table
For example, WHERE
EVENT_TYPE_CODE = 01
File Where Clause An SQL where clause on the
NORMALISED_EVENT_FILE table
For example, WHERE
EVENT_TYPE_CODE = 01

1. Which parameter or parameters could you use to re-rate your error
events for this exercise? Why?
The best parameters to use in this case would be the Base Event File
Name and the File Record Start/Stop Nr fields, as this would allow you
to select the single error event in the original file.
In a real situation, you would complete whatever parameters necessary

to re-rate the appropriate error events.
CB v4.02 Page 81
Billing Operations
6. Run a one-off task

using the Re-rate
Error Events (bulk)
schedule type to re-
rate the error events
When the task completes, view the information displayed on the Results
tab. Write down the name of the event file created for this task.
Page 82 CB v4.02
Billing Operations
Revoking Rating
Display Slide 24 – Revoking Rating
After rating is complete it may be necessary to revoke, or roll back,

rating for certain events or event files.
For example after rating an event file, it is discovered that all the
charges generated are incorrect. In this case, the entire rating process
needs to be revoked, the tariff generating the charges updated and the
event file rated again.
There are three rating schedule types used for revoking rating, outlined
in the following table.
Rating Schedule Description

Type
Revoke Event File Deletes all normalised events, error events and
charges from the database
Revoke File and Deletes all normalised events, error events and
move back charges from the database and moves the event
file from the archive directory back to the input
directory
Revoke Reprocessed After completion of a Revoke Event File or

File Revoke File and move back schedule type, this
recreates the original re-rating file
Which Schedule Type for Revoking?

Generally, to revoke rating for a standard event file, use the Revoke File
and move back schedule type. In addition to rolling back rating, it
moves the event file from the archive directory back to the input
directory, ready for rating again.
CB v4.02 Page 83
Billing Operations
To revoke rating for a reprocessed file (events assigned to a file for re-
rating, or events selected for re-rating) use the following steps:
1. Use either the Revoke Event File or Revoke File and move back
schedule type to revoke the rating of the reprocessed file
2. Use the Revoke Reprocessed File schedule type to recreate the
original reprocessed file
Exercise 8 – Revoking Rating
Part A
Revoke rating for the reprocessed file, the name of which you wrote
down on page 82.

1. What schedule type did you use first?
Either Revoke Event File or Revoke File and move back
2. What schedule type did you use second?
Revoke Reprocessed File
Part B
Re-rate the event again, using the steps outlined on page 79.
Ensure the task completes successfully.
This is the end of the section on rating. Ask participants if they have any
questions before you move on to the Billing section.
Page 84 CB v4.02
Billing Operations
Participant Handbook – Billing
Billing xx mins
Learning Objectives
s List billing terminology
s Describe the billing architecture
s Configure billing processes
s Create and run bill run schedules
s Check billing results
s Perform bill run operations
s Correct billing errors
Content Overview
At a predetermined time, usually when invoices need to be produced,

billing occurs. Billing is the process of:
• Compiling all of the data that eventually appears on customer
invoices.
• Generating the invoices images
• Applying the invoices to customer’s accounts. This commits all
related charges to a customer’s account
• Outputting the invoices to either a printer or electronic media
This section examines:

• Billing terminology
• The processes within billing
• How to perform billing, including:
− Creating bill run schedules
− Checking billing results
− Performing bill run operations
− Correcting billing errors
CB v4.02 Page 85
Billing Operations
Billing Terminology
Display Slide 25 – Billing Terminology
Before discussing billing in detail, the following concepts require

further explanation:
• Bill runs
• Invoice cycles
• Reporting levels
• Suppress Billing
Bill Runs and Invoice Cycles

A set of billing operations can be applied to a single customer node or a
batch of customer nodes by performing a bill run. The ability to process
multiple customer nodes allows a faster billing process and also gives
control over the quality of the process.
For example, you are able to view initial invoices before the majority of
customer nodes have been processed. If errors are detected, the bill run
can be stopped.
The terms bill run and invoice cycle are often used interchangeably,
however they have different meanings.
Bill Runs
Bill runs are operational in nature and bring together all of the billing
processes required to produce invoices, apply them to customer
accounts and print them if required. Bill runs are created as schedules
allowing the specification of:
• When and how often they run
• What parameters are used
Page 86 CB v4.02
Billing Operations
Invoice Cycles
Invoice cycles, on the other hand, are customer concepts and determine
the frequency at which invoices are produced, such as monthly or
quarterly. An invoice cycle determines how often a bill run is
performed. A customer must be assigned to an invoice cycle to
determine when they are billed.
The name of the schedule set up for a bill run is the name of the invoice
cycle that can be assigned to a customer.
When a bill run is executed, all of the processes specified in the

schedule are performed.
Statistical information is recorded for each bill run indicating success or

failure for each process as well as the duration. This enables the tracking
of the status of the bill run during processing.
A bill run must be configured with a bill run type. This determines the
set of schedule types that can be executed on a particular bill run.
Reporting Levels
For billing purposes, each customer is assigned one of the following
reporting levels:
• Invoice
• Statement
• None
The reporting level for a customer is shown on the Invoicing tab of the
Customer form.
When a bill run occurs, customers in the invoice cycle with a reporting
level of Invoice receive an invoice of their charges for the billing period,
plus the charges of their child customers with a reporting level of
Statement or None.
Child customers with a reporting level of Statement receive a statement

of only their charges for the billing period.
Child customers with a reporting level of None, receive nothing.
CB v4.02 Page 87
Billing Operations
Note that root customers are automatically assigned a reporting level of

Invoice and this can not be updated.
Display Slide 26 – Reporting Levels
The following diagram shows an example customer hierarchy.
ABC
Banking
West Central East

Branch Branch Brach
Loans Investments
The table below lists the reporting level details for these customers.
Customer Customer Type Parent Reporting

Customer Level
ABC Banking Root -- Invoice
West Branch Child ABC Banking Statement
Central Branch Child and Parent ABC Banking Invoice

East Branch Child ABC Banking Statement
Loans Child Central Branch None
Investments Child Central Branch Statement
The billing implications for this hierarchy example are as follows:

• ABC Banking (the root customer) receives an invoice for its own
charges, and those for West Branch and East Branch
• Central Branch receives an invoice for its own charges, and those
for Loans and Investments
• West Branch, East Branch, and Investments each receive a
statement of their own charges
Page 88 CB v4.02
Billing Operations
• Loans receives nothing
Suppress Billing
It is possible to suppress billing on a customer by customer basis.
The Billing tab on the Customer form contains a Billing Suppression

section where an operator can specify to suppress billing until a specific
date.
An example of a completed Billing tab on the Customer form is shown

below.
If the Suppress Bill runs for Customer? check box is ticked, a date in the
Bill cycles suppressed until field must be entered.
The operator can either enter a number in the Suppress customer billing
for bill cycles field (the system then calculates and enters the date) or
enter a date directly.
The maximum number of bill runs that may be suppressed is defined in

the customer type definition.
CB v4.02 Page 89
Billing Operations
The customer’s bill cycle may not be suppressed for more than the
number of pending tasks (as specified in the Prescheduled Count field of
the schedule).
There are no limitations to the date to which bill cycles can be

suppressed. Even a date after the start date of the last pending task of
the invoice cycle schedule is acceptable. However, if a maximum
suppression period is defined in the customer node type, the suppress
until date may not exceed this period.
This period is calculated from the issue date of the last invoice
generated for this customer, or from the root customer node if invoices
have not yet been generated. Checking is done on the server when the
details are saved.
Page 90 CB v4.02
Billing Operations
Billing Architecture
The billing architecture is outlined in the following diagram:
Display Slide 27 –Billing Architecture
Product/Facility details
Recurring tariffs
RGP BGP IGP GOP

(trergp) (trebgp) (treigp)
Printer
Rental Bill Invoice General
or file
Generation Generation Generation Output
Process Process Process Process
Rental Adjustment Billing data

Customer Invoice images
events events product Templates
details Billing data
Rater Charges
Database
Rental and adjustment charges
The processes that make up billing are the:

• Rental Generation Process (RGP)
• Bill Generation Process (BGP)
• Invoice Generation Process (IGP)
• General Output Process (GOP)
Unlike the rating processes, which are UNIX processes, the RGP, BGP,
and IGP are all TUXEDO services (trergp, trebgp and treigp). Like the
rating processes, they are started automatically with the start-up of the
system. The GOP, used to print the final invoices (or output them to
file), is an independent UNIX process, run as required.
CB v4.02 Page 91
Billing Operations
Rental Generation Process (RGP)

Display Slide 28 – Rental Generation Process (RGP)
The RGP generates rental events and rental adjustment events before
invoice processing occurs. The term rental refers to any recurring
charge, such as a service subscription, a maintenance charge, or an
equipment rental. In many cases, recurring charges are paid in advance.
The RGP also generates events for one-off charges such as activation or
cancellation fees.
The RGP operates in two modes:

1. Rental generation mode
2. Rental adjustment mode
In rental generation mode, it generates normalised events for recurring

and one-off charges, as specified in the tariff definition.
In rental adjustment mode, it generates normalised events to correct or

adjust previously billed recurring charges. For example, if a service is
cancelled, an adjustment may be required to refund a portion of a
recurring charge already paid in advance.
Rental events and rental adjustment events are then sent to rating and
processed in exactly the same way as other events (that is, through the
ENM, ERT and ERO) to generate rental and adjustment charges.
Rental Processing
The process to generate rental events in the RGP is as follows:

1. Retrieve the product, facility, and service details from the database
2. Calculate the start and end dates of the rental period for each
recurring tariff. These dates are derived from the:
a) Bill run schedule (the invoice cycle), giving the effective date
b) Tariff definition, which define the:
i) Recurring charge period and the advance charge period
ii) Pro-rating details, if any
Page 92 CB v4.02
Billing Operations
3. Determine the active periods within the rental period. For example,
a service may have been suspended and then reactivated during the
same rental period
4. Generate rental events for each active period
5. Write the events to the input directory and instruct a specific ENM
process to rate them
Events for one-off charges are also generated by the RGP, but only
once.
Display Slide 29 – Rental Period Calculations
The following diagram illustrates how the start and end dates of the
rental period are calculated.
Jan 15 Feb 14 Mar 14
Recurring Charge Period (1 month) Advance Charge Period (1 month)
Effective Start of next

Date Invoice Cycle
Date of the
bill run
Pro-Rating
Pro-rating is an option for when the start date of the entity you are
billing for is not the same as the effective date of the bill run schedule.
For example, a customer purchases a new product in the middle of their

invoice cycle. Pro-rating adds units of time (usually days) to bring it into
line with the invoice cycle date.
Advance the animation to display the pro-rating portion of the slide
This is illustrated in the following diagram.
CB v4.02 Page 93
Billing Operations
Jan 15 Feb 14 Mar 14

Pro-rating period
Recurring Charge Period (1 month) Advance Charge Period (1 month)
Effective Start of next

Date Invoice Cycle
Product Date of the

start date bill run
Rental Adjustment Processing
As stated previously, rental adjustment generates normalised events to

correct or adjust previously billed recurring charges.
The process to generate rental adjustment events in the RGP is as

follows:
1. In the same way as rental processing, determine the active periods
within the adjustment period. The adjustment period is a
configurable number of days (90 is the default value) prior to the
effective date of the invoice cycle
2. Compare these active periods with those determined for the
previous rental period
3. Based on differences found between the active periods, generate
rental adjustment events
4. Write the events to the input directory and instruct a specific ENM
process to rate them
Bill Generation Process (BGP)

Display Slide 30 – Bill Generation Process (BGP)
For each customer in the invoice cycle, the BGP gathers all customer,
product and charge details dated within the range of the invoice cycle,
plus any charges not included in a previous bill run (charges that did not
exist at the time of a previous bill run).
It then evaluates any subtotals and billing tariffs. These tariffs are
typically discount tariffs applied against a range of charges. For
example, if a customer’s total usage for the period of the invoice cycle
(stored in a subtotal) is greater than a set amount, a tariff generates a
discount.
Page 94 CB v4.02
Billing Operations
The BGP then creates invoice data from the applicable charges for each
customer, including child customers.
The process to generate invoice data in the BGP is as follows:

1. Retrieve all tariffs, subtotals, and derived attributes with a context of
Normalised Event, Charge, Service, Customer Node, or Customer,
and an application environment of Rating or Billing
2. Retrieve customer, product and service details from the database for
each customer hierarchy in the invoice cycle
3. Evaluate the subtotals as required by the reporting level defined for
the customer node (invoice, statement, or none)
4. Evaluate the eligible tariffs with a context of Billing
5. Generate and save the invoice data to the database
The BGP is similar to the ERT in that it applies tariffs and supports
parallel tariffing, but there are two main differences:
• The BGP applies tariffs to aggregated records, rather than individual
ones. Aggregation means that the individual charges are aggregated
into one or more pre-defined groups so that a total value for the
group can be obtained
• The tariffs applied to the aggregated records are usually discount
tariffs rather than charge tariffs
Invoice Generation Process (IGP)

Display Slide 31 – Invoice Generation Process (IGP)
The IGP retrieves the invoice data from the database and merges it with
the appropriate invoice template to create an invoice image for each
customer, which is saved to the database.
CB currently uses templates in ASCII text, however any suitable text

based page description language can be used.
The IGP also generates dunning letters for customers who have overdue
payments.
The process to generate invoice data in the IGP is as follows:
CB v4.02 Page 95
Billing Operations
1. Retrieve invoice and dunning letter templates from the database

2. Insert the invoice and dunning letter data into the appropriate
sections of the templates
3. Check the eligibility criteria
4. Store the compressed invoice or letter images in the database
After the invoice images have been written to the database, it is possible
to view them online. Viewing a cross section of images online allows
you to check that images have been produced correctly prior to applying
the invoices to customer accounts.
Depending on the format of the image stored on the database, third party
applications such as Adobe Acrobat or a web browser may be used to
view it.
Invoice Templates
Invoice templates play a significant part in billing; not only do they

control the appearance of the final invoice presented to the customer,
they also determine the processing of the data displayed on them.
For more information on the design and use of invoice templates, refer
to the training module PC05 Invoice Design Tool and the
documentation manual Invoice Design Tool.
Applying and Allocating Invoices

Although not part of the billing architecture diagram displayed on page
91, one of the final steps in the billing process is to apply the invoices to
the customers’ accounts.
To this point, events have been rated and billed and the invoice images
produced, but the charges listed on the invoices are not yet reflected on
customers’ accounts.
Two options exist: Apply or Apply and Allocate.
Applying invoices posts the charges listed on the invoices to the

customers’ accounts.
Apply and Allocate applies the invoices plus allocates any unallocated
payments or adjustments to the invoices.
Page 96 CB v4.02
Billing Operations
Applying and Allocating Example
To help illustrate the difference between applying and allocating,

consider the following example.
A customer receives an invoice for $50. They make a payment of $60.

$50 is paid against the invoice while $10 is left unallocated. That is, the
account is in credit by $10, but that amount is not allocated to any
specific invoice.
In the next invoice cycle, another invoice for $50 is generated.
If the invoice is applied to the customers account, the account balance is

now $40, but $10 is still unallocated. That is, the $10 is not allocated to
the new invoice. It remains unallocated.
If the invoice is applied and allocated, the account balance is $40 and
the $10 previously unallocated is allocated to the new invoice.
Although applying and allocating invoices may be performed as part of

the overall billing process, many service providers keep it as a separate
step in case there are errors with the invoices. Like rating, you can
revoke or roll back the steps in the billing process, fix any errors and
then produce the invoice images again. Once the invoices are correct,
you can apply them to the customers’ accounts.
General Output Process (GOP)

Display Slide 32 – General Output Process (GOP)
The billing processes we have discussed run as TRE servers and are
automatically executed with the start up of the system. The General
Output Process (GOP) is an independent process that runs when
required.
The GOP is used to retrieve images stored by previous billing operations

or scheduled tasks (such as invoices, statements or dunning letters) and
send them to an appropriate output device. The GOP retrieves user-
defined information stored in the Convergent Billing database to
determine how images should be selected, sorted and output.
CB v4.02 Page 97
Billing Operations
Images can be divided into as many batches as necessary and each batch
can be separately ordered and sent to a different output device. For
example, images may be output directly to printers or onto disk or tape
for printing by third parties.
Each device is defined by an arbitrary UNIX command or pipeline.
The general flow of processing in the GOP is as follows:

• The Schedule ID parameter is used to identify the most recently
completed task for that schedule. Only data produced during the
execution of that task is considered for output
• The defined output method is used to identify the database tables
and views used to retrieve the required data, including document
images. It can also define an update performed on the database
when an image has been processed (for example, to flag that a
dunning letter has been printed)
• The output method is associated with a table of output criteria. This
table may contain zero or more rows. The criteria received may
include:
− The output device defining where the selected document images
are sent
− An SQL WHERE clause, used to select the retrieved images to
use this output device
− An SQL ORDER BY clause, used to specify the order of the
output
• For each row in the criteria table, the GOP outputs the selected data
to the output device using the appropriate selection and sorting
criteria
Page 98 CB v4.02
Billing Operations
Configuring Billing Processes

Display Slide 33 – Configuring Billing Processes
Like rating processes, the attributes for individual billing processes can
be altered, plus additional processes configured to meet the processing
requirements of a service provider. For example, configuring multiple
BGP processes to process multiple customers simultaneously.
Configuration Items
The billing processes started and maintained by the system are
determined by Configuration Items set up in the system. Creating new
configuration items result in new processes. The configuration item for a
process specifies all of the attributes for that process. Each process has
its own configuration item.
CB v4.02 Page 99
Billing Operations
Guided Practice 6 – View a BGP Configuration Item


ð Server ð
Configuration
Items
The list of configuration items displays in the bottom part of the form.
2. Click
Page 100 CB v4.02

Billing Operations
3. Select and display

the BGP1
configuration item
The attributes on the Base Attributes tab are outlined in the following
table.

CUSTOMER_CHILD_ The number of customer level child
PROCESSES processes created by the BGP
The processes are created at system
boot time and remain until the system is
shutdown
NODE_CHILD_ The number of customer node level
PROCESSES child processes created by the BGP
These processes are created as child
processes to a customer level process at
the beginning of a bill run and terminate
at the end of a bill run
CB v4.02 Page 101

Billing Operations

SERVICE_CHILD_ The number of service level child
PROCESSES processes created by the BGP
These processes are created as child
processes to a customer level process at
the beginning of a bill run and terminate
at the end of a bill run
See the following section for more
information about customer, customer
node and service level processes
NON_GLOBAL_DA_ The cache size for derived attributes
CACHE_SIZE with a customer, customer node or
service storage context
If specified as a positive number, this
indicates the number of derived
attributes that can be stored. If specified
as number followed by an upper case
M, this indicates the size of the cache in
megabytes
GLOBAL_DA_CACHE_ The cache size for derived attributes
SIZE with a global storage context
If specified as a positive number, this
indicates the number of derived
attributes that can be stored. If specified
as number followed by an upper case
M, this indicates the size of the cache in
megabytes
DISABLE_HASH_JOIN Disables the use of hash joins in queries
Page 102 CB v4.02

Billing Operations

DEBUG_LEVEL The level of tracing to run for the BGP
Levels are specified either as hex values
or a three letter mnemonic associated
with the trace level. Multiple levels may
be specified by adding the hex numbers
or listing the mnemonics separated by
commas
The tracing levels available are listed in
the Singl.eView Convergent Billing
System Administration Guide
ERROR_THRESHOLD The maximum number of errors
tolerated before a bill run is aborted
USAGE_CHARGES_ Whether the BGP processes usage
BEFORE_BILL_DATE charge up to and including the effective
date of the bill run
If TRUE, usage charges up to BUT
NOT including the bill run effective
date are included
If FALSE, usage charges up to AND
including the bill run effective date are
included
Recurring charges are not affected by
this attribute. That is, recurring charges
up to AND including the bill run
effective date are included
CB v4.02 Page 103

Billing Operations
Billing Streaming
Display Slide 34 – Billing Streaming
To ensure high performance within billing, the appropriate streaming of

the RGP, BGP and IGP processes must be set up. For example,
configuring multiple BGP processes to process multiple customers
simultaneously.
Like the other billing processes, the GOP has multi-processing

capabilities to allow multiple images to be processed simultaneously.
Rental Generation Process (RGP)
For most bill runs, the RGP processing time is minimal. The RGP is
capable of running multiple processes to increase processing
performance. The RGP can be streamed to generate multiple rental
event files simultaneously then pass these files to a single rating engine.
The size of the files produced by the RGP can be set in the configuration
items.
The RGP spawns the number of child processes specified by the

configuration attribute CHILD_PROCESSES. If this attribute equals
zero or is not present then no child processes are spawned, and the RGP
will run in single process mode.
This attribute may be over-ridden by the command line option -c

<number>. Where <number> is the number of child processes to be
spawned. Once again a value of zero (-c 0) means the RGP will run in
single process mode. If the -c option is specified the
CHILD_PROCESSES attribute is ignored.
Page 104 CB v4.02

Billing Operations
Bill Generation Process (BGP)
The BGP can run as multiple processes or as a single process depending

on the configuration item attributes. The BGP can be streamed based on
four criteria:
• Customer
• Customer node
• Service
• Event
Display Slide 35 – BGP Child Processes
The following child processes can be configured to provide multi-

processing of the BGP to enhance billing performance:
1. Customer level child processes
(CUSTOMER_CHILD_PROCESSES)
Created from the trebgp server and process root customers.
2. Customer node level child processes
(NODE_CHILD_PROCESSES)
Created from the customer level child processes and process
customer nodes.
3. Service level child processes (SERVICE_CHILD_PROCESSES)
Created from the customer level child processes and process
services.
4. Event level child processes (EVENT_CHILD_PROCESSES)
The number of child processes that the BGP will create in order to
process a single service. This attribute should only be set for bill
runs that contain high volume services (for example, for call
centres). Event level child processes are created from the customer
level child processes and process the events for a service.
The attributes of these child processes determine how many child

processes are created. If any of the attributes are greater than zero, the
BGP starts at least one customer level child process and the specified
number of customer node, service and event level child processes.
CB v4.02 Page 105

Billing Operations
The difference between single processing mode (no child processes) and
multi-processing mode is illustrated in the following diagram.
Display Slide 36 – BGP Child Process Attributes
Single Processing Mode
All processing done within

trebgp the trebgp
Multi-processing Mode
Processes root customers
Customer level
trebgp process
Manages overall bill run

operations
Customer node, Customer node,

service or event service or event
level process 1 level process n
Processes customer nodes, services or events.

Exist only for the duration of the bill run
If the multi-process option is enabled, the BGP server first executes a

BGP parent process (customer level process) which in turn creates a
number of child processes that process sections of a bill run in parallel.
The BGP parent process can spawn three types of child processes,
customer node, service or event.
(For the more technical audience) This is carried out by fork and exec
system calls.
The fork and exec system calls are UNIX processes
The fork system call creates two almost identical copies of a process.
One copy is called the parent, and one the child. All parts of the image
of the parent are inherited by the child.
Page 106 CB v4.02

Billing Operations
The exec system call overlays the process that is running with a new
program and begins execution of the program at its entry point.
As the names suggest, a customer node child process processes

customer nodes and a service child process processes services. Event
child processes allow the processing of services to be broken up over a
specified number of processes. Event level concurrency is designed to
allow the BGP to scale when processing high volume services such as
those associated with call centres. Unless the bill run contains this type
of service there is no value in this level of multi-processing.
Customer node processes are created at the start of a bill run and remain
alive for the duration of the run. If multiple customers are being
processed then the child process will not terminate until after the last
customer is finished being processed.
BGP performance is data dependent. When determining how to

configure the BGP streams the following should be considered:
• Size of the customer’s hierarchy of accounts
• Number of services sold
• Distribution of events between services
Like rating processes, there are no absolute guidelines for determining

the optimal number of BGP processes. Generally, service providers
with:
• A wide customer hierarchy (many root customers with multiple
customer nodes) will benefit from a configuration of multiple
customer node level processes
• Multiple services per customer will benefit from a configuration of
multiple service level processes
• Mostly residential customers (no or few child customers and usually
one service per customer) will benefit from a configuration of
multiple customer level processes
• Bill runs that contain high volume services such as free call
numbers will benefit from a configuration of multiple event level
processes
While it is possible to configure both multiple customer node and

multiple service level child processes in the same configuration, it has
been found that this does not improve performance.
CB v4.02 Page 107

Billing Operations
The only way to determine the 'best' configuration is by analysis of the

customer profile for a service provider versus current billing
performance, and then using that information to experiment with
different configuration options.
Invoice Generation Process (IGP)
The IGP takes the invoice information generated by the BGP and creates
invoice images using the invoice templates associated with each
customer.
The IGP may be configured in either single-process or multi-process

mode by specifying the maximum number of child processes.
In single-process mode, the treigp server process is the only process that
is invoked.
In multi-process mode, the treigp server creates and executes up to the

maximum number of IGP child processes required, as specified in the
MAX_CHILD_PROCESSES configuration item attribute. This attribute
is optional and specifies the number of child processes the IGP will
spawn.
For example:
• A value of 2 means run with one parent process and two child
processes
• A value of 1 means run with one parent process and one child
process
• A value of 0 means run in single process mode.
If the MAX_CHILD_PROCESSES attribute is not present the IGP runs

as if a zero value was specified (that is, in single process mode).
General Output Process (GOP)
The GOP is used to retrieve images stored by previous billing operations

or scheduled tasks (such as invoices, statements or dunning letters) and
send them to an appropriate output device.
Like the BGP, RGP and the IGP, the GOP has multi-processing
capability.
Page 108 CB v4.02

Billing Operations
GOP multi-processing allows multiple images to be processed

simultaneously in parallel. If this option is used, child processes are
spawned after the output method type and output method details are read
in from the database.
Inter-process communication between the child and parent processes is

achieved by creating a pipe for each child process. The parent process
sends requests to process an image to each child process via its pipe. A
common return pipe is used by all child processes to inform the parent
process when they have completed processing an image. If all child
processes are busy, then the parent process waits on this common return
pipe for a message from a child process.
Messages sent from a child to the parent always include the process ID
of the child to uniquely identify it. If the processing of an image fails,
the error message is also returned from the child process to the parent.
GOP multi-processing is set up using the -c flag on the command-line.

The -c flag is ignored for a batch if the selected output device is
configured to concatenate images. This flag is also ignored if the value
of max_children is less than 2.
Exercise 9 – View Other Billing Configuration Items
Allow a maximum of 10 minutes for this exercise (5 minutes per

process).
View the other RGP and IGP billing configuration items. Use online
help (Help ð Reference Information ð Index) to search for and display
the base attribute descriptions for each.
CB v4.02 Page 109

Billing Operations
Managing Billing Tasks

The successful management of billing tasks involves a number of
procedures and processes.
There are a number of tasks that can be performed prior to running

billing that can help to achieve a successful bill run. While some of
these tasks may be included in an operational plan, it is important for
billing operators to be aware of these tasks.
A bill run is created as a schedule allowing users to specify when and

how often it runs, as well as the parameters for the bill run. There are
two schedule types that can be used for a bill run. These are Standard
Bill Run and Quality Assurance Bill Run.
Pre-billing Tasks
Display Slides 37 & 38 – Pre-billing Tasks
There are certain tasks that can be undertaken prior to running the rating
process that will minimise problems during rating. These tasks could
form part of a checklist that identifies the tasks as well as who has
responsibility for the task.
As with rating, there are certain tasks that can be undertaken prior to
performing a bill run which can help to minimise billing problems. The
following tasks could form part of a checklist to run through prior to the
commencement of each bill run:
• Check for and resolve DVP errors
This is a critical step to ensure a successful bill run. Any errors
associated with customer data will have a significant impact on
billing. In some cases, it may cause billing to fail completely. DVP
is typically run by operations staff.
• Check that all required event files have been rated
This task would typically be performed by operations staff.
• Check that all required error events have been reprocessed
Operations staff would typically perform this task.
• Check that partitions have been sorted
Page 110 CB v4.02

Billing Operations
• Check that all CSR account activities that may affect the accounts
being billed have been completed, such as checking that all payment
or adjustment batches have been processed, and checking that all
necessary modifications have been made to customer and account
records
This task would normally be the responsibility of the billing
manager.
• Ensure that any pre-authorised payments have been run prior to the
commencement of billing
manager.
• Check that all necessary business changes that may affect the billing
output have been made to configuration. These changes could
include:
− Rate table updates
− Changes to invoice messages
− Any outstanding patches or code promotions
manager.
• Identify any pending tasks that may run during billing that would
impact billing functionality or compete for resources
If any tasks are schedules, their start dates can be modified to a date
in the future.
High-risk tasks that should not be run during billing include:
− Dbanalyse
− DVP checks
− Update Charge Categories
− Update Lists
− Rotating or sorting of partitions
− Full database backup
CB v4.02 Page 111

Billing Operations
Other possible risks include running reports that are reporting on the
same time period as the bill cycle. The report may not give accurate
results depending on what stage the billing task is at. Also, depending
on the nature of the report, there may be a clash for system resources as
well as a clash for the same data as the billing process. Either the
billing task or the report may timeout waiting for row locks to be
removed or system resources to free up.
• Perform a full database backup (optional)
For environments that have only a small number of bill cycles per
month, a full backup before each bill run is a good safety measure.
For environments that need to run more frequent bill cycles, such as
a daily bill run, a different backup strategy is required.
• Confirm that the details on the pending billing task are correct
For example:
− Check that the effective date is correct for the current bill cycle
− Check that the parameters have been set to spawn the right
number of child processes. This is discussed later in this
training. If parameters are not included to spawn child processes
on large production environments, billing will be slow
− Check that the path specified for the IGP parameters is a valid
path that exists on the server. This is for the storage of
temporary invoice image files
Bill Run Schedules

As stated previously, the bill run is the concept that ties all of the billing
processes together and allows you to specify the process or processes
you want to perform. A bill run is created as a schedule allowing users
to specify when and how often it runs, as well as the parameters for the
bill run.
By using a schedule, a billing task can be run at specified intervals,

whereas a one-off task runs a single rating task immediately. Multiple
bill run schedules can be set up for different customers or groups of
customers.
Page 112 CB v4.02

Billing Operations
Display Slide 39 – Bill Run Schedules
Bill run schedules can perform any or all of the following operations:
• Rental adjustment generation
• Rental generation
• Invoice and statement generation
• Invoice and statement image generation
• Apply and allocate invoices
• General output
The flow of these operations is summarised in the following diagram.
Rental adjustment
generation
Rental generation
Invoice and
statement
generation
Invoice and
statement image
generation
Apply and allocate

invoices
General output
CB v4.02 Page 113

Billing Operations
When creating a bill run schedule, any of these operations may be

specified. When you execute a bill run schedule, the operations
specified in the schedule are performed from top to bottom. If any
operation results in an error, it is possible to revoke back to the last
successful operation. If required, the entire bill run may be revoked.
Generally, service providers create and submit bill runs to perform just
rental adjustment, rental generation, invoice generation and invoice
image generation. After ensuring this completes successfully and the
invoices are correct, service providers can then apply and allocate the
invoices to the customers’ accounts and output the final invoices.
Bill Run Schedule Types

Display Slide 40 – Bill Run Schedule Types
There are two schedule types operators can use to perform billing:
1. Standard Bill Run
2. Quality Assurance Bill Run
The Standard Bill Run schedule type performs all of the processes, as
defined by the parameters in the schedule, for the customers on the
invoice cycle.
The Quality Assurance Bill Run schedule type operates the same as the
Standard Bill Run, except that the results are stored separately from
actual results and do not update customers’ account details. As the name
suggests, quality assurance bill runs are very useful for testing purposes
or to provide quote information.
Bill Run Parameters
The Parameters tab of a bill run schedule type allows you to specify all
of the parameters for the bill run.
Explain to participants that the fields on the Parameters tab for a

Quality Assurance Bill Run are the same as the fields that display for a
Standard Bill Run. The only difference is that for a Quality Assurance
Bill Run, the Schedule field displays to enable the schedule (invoice
cycle) on which to perform the Quality Assurance Bill Run to be
selected.
Page 114 CB v4.02

Billing Operations
The fields on the Parameters tab for a Standard Bill Run schedule type
are outlined in the following table.
Field Description
Bill Run Type The type of bill run to create
With configuration, different options could
change how the bill run schedule performs.
However, with the standard CB pre-
configuration, the bill run types listed are
samples only and do not effect the bill run
From Operation The first process to perform in the bill run
schedule
To Operation The last process to perform in the bill run

schedule
The From and To Operations available
correspond to the billing operations,
including:
• Rental
adjustment event generation
• Rental
event generation (RGP)
• Invoice/St
atement generation (BGP)
• Invoice/St
atement Image generation
• Apply
Invoices
• Apply and
Allocate Invoices
• Print
Invoices
CB v4.02 Page 115

Billing Operations
Field Description
Customer Batch Size If billing is configured for multi-processing
(running multiple copies of the billing
processes), the maximum number of
customers processed by an individual billing
process
Number of Child If billing is configured for multi-processing,
Processes the maximum number of billing processes for
the bill run
Error Threshold The maximum number of errors tolerated
before the bill run stops
Where Clause An SQL Where clause to specify the
customers processed in the bill run
Customer Batch Size and Number of Child Processes

Parameters
All schedule types used for bill run operations have two common
parameters that control how the billing operations will be performed for
the bill run. These parameters are:
• Customer Batch Size
• Number of Child Processes
The Customer Batch Size parameter controls the number of customers

that are passed to each bill run operation in turn. Customers are
prioritised and grouped into batches of the specified size. The requested
range of bill run operations (From Operation/To Operation) is then
performed on each batch in turn.
For example, if the operations to be performed are Rental Event

Generation to Invoice Image Generation, with a total of 1500 customers
with a batch size of 100, the processing is as follows:
1. Customers are sorted by priority
Priority is defined on the Billing tab of the Customer form.

2. The customers are divided into batches each with 100 customers
(that is, 15 batches)
Page 116 CB v4.02

Billing Operations
3. For each batch of customers, perform the following operations:

− Rental Event Generation
− Invoice Generation
− Invoice Image Generation
The Number of Child Processes parameter controls the number of

parallel processing streams used to process the customers. Each batch of
customers is processed on a single stream.
Using the above example, if the Number of Child Processes parameter is

set to 3, the first three highest priority batches of 100 customers will be
allocated to the three child processes and their billing operations will be
performed concurrently. Each parallel processing stream acts
independently of the others. As soon as one stream completes
processing a batch, it immediately starts processing the next available
batch in order of priority.
Specifying a number of child processes creates parallel processing

streams. This can improve server utilisation and billing throughput
provided server processes are appropriately configured.
Parallel processing can also minimise the impact of a certain customer

batch slowing processing due to customer nodes that take a long time to
process. If multiple parallel processing streams are specified, other
customer batches can be automatically started and completed while the
long-running customer batch is still processing.
CB v4.02 Page 117

Billing Operations
Display Slide 41 – Multi-processing Example
The diagram below displays bill run processing with a batch size of 100
and the number of child processes set to 3.
Rental Invoice Invoice

Generation Generation Image
h2
atc )
er B mers
m
sto sto
Multi-processing
Cu 00 cu
(1
Customer Batch 1 To customer

(100 customers)
Cu
s
(10 tome
0 c rB
ust at
om ch3
ers
)

An example of the Parameters tab for a Standard Bill Run schedule type
is shown below.
Page 118 CB v4.02

Billing Operations
The fields on the Parameters tab for a Standard Bill Run schedule type
and a Quality Assurance Bill Run schedule type are outlined in the
following table.
Field Description
Bill Run Type The type of bill run to create
or With configuration, different options could
change how the bill run schedule performs.
Bill Run Type (QA) However, with the standard CB pre-
configuration, the bill run types listed are
samples only and do not effect the bill run
Schedule For Quality Assurance Bill Run schedule
types only, the schedule (invoice cycle) to
perform a quality assurance bill run on
CB v4.02 Page 119

Billing Operations
Guided Practice 7 – Create a Bill Run Schedule

The purpose of this guided practice is to create a bill run schedule to bill
your customer.
1. Select Server Tasks The Schedule Search form displays.

ð Schedules
2. Select Standard Bill
Run in the Schedule
Type field
3. Select the Create a
new schedule radio
button
The Schedule form displays in Inserting mode.

4. Click
Page 120 CB v4.02

Billing Operations
5. Enter xxInvoice
Cycle in the
Schedule Name field
6. Enter xxInvoice
Cycle in the
Description field
7. Enter 1 in the
Preschedule Count
field
8. Enter 1 in the Repeat
Units field
9. Select Month Day
in the Repeat Type
field
10. Enter a date after
today's date in the
First Date field
11. Select the
Parameters tab
12. Select Standard Bill
Run in the Bill Run
Type field
13. Select
Invoice/Statement
image generation in
the To Operation
field
The Submit Schedule form displays.

14. Click
CB v4.02 Page 121

Billing Operations
15. Tick each check box

on the form
The check boxes on the Submit Schedule form are outlined in the
following table.
Check Box Description

Regenerate tasks? Whether or not to regenerate any pending
future tasks
When updating a schedule, and if selected, all
pending future tasks are regenerated with the
characteristics in this schedule
Be notified on Whether or not to notify the operator when the
receipt? schedule is received by the server
Be notified on Whether or not to notify the operator when the
completion? schedule completes
The schedule is saved and a message acknowledging update of the

16. Click schedule displays.
17. Click

1. Entering a date after today's date in the First Date field has what
effect? Why did we do this?
Stops the schedule from running immediately. We did this because we

don't want the schedule to execute before updating our customer with
this invoice cycle.
Page 122 CB v4.02

Billing Operations
2. If you only wanted to perform rental and rental adjustment

processing, how would you do this?
Rental adjustment event generation in the From Operation field
Rental event generation (RGP) in the To Operation field
Exercise 10 – Update A Customer with a New

Invoice Cycle
The new schedule just created is the invoice cycle for your customer.
Update the Invoice Cycle field for your customer, Bill Johnsonxx.
CB v4.02 Page 123

Billing Operations
Guided Practice 8 – Run a Pending Schedule

The schedule created in the previous guided practice is pending for
some date in the future. You wish to run it now to create an invoice for
your customer.
1. Display your
schedule on the
Schedule form
The Schedule form displays in Updating mode.
2. Click
3. Enter today's date

and time (according
to your PC clock) in
the First Date field
The Submit Schedule form displays.

4. Click
5. Tick each check box

on the form
The schedule is saved and a message acknowledging update of the

6. Click schedule displays.
Page 124 CB v4.02

Billing Operations
When the schedule completes, a message displays asking if you wish

7. Click
to view the results.
The Task form displays with the results of the bill run.
8. Click
CB v4.02 Page 125

Billing Operations
Billing Results
After the bill run schedule has completed, you can confirm it ran
successfully or not by checking the:
bill run schedule
• Information on the Bill Run Details form
Task Status and Results

Viewing the Task Status field and Results tab on the Task form provides
the first level of detail as to whether the bill run schedule ran
successfully.
A Task Status of:

• Success indicates the schedule completed successfully, but errors in
the billing of customers may still have occurred
• Failure indicates the schedule was unsuccessful and is accompanied
by the reasons for failure on the Results tab
The Results tab lists information such as the:

• Number of customers processed in the bill run
• Number of customer batches processed in the bill run
• Bill run ID
• Number of customers that were:
− Successful
− Erred
− Skipped
− Suppressed
Page 126 CB v4.02

Billing Operations
An example of the Task form is shown below.
The Details tab of the Task form shows the settings used for the bill run
schedule and the Parameters tab shows the parameters used for the bill
run schedule.
CB v4.02 Page 127

Billing Operations
Bill Run Details Form

More detailed information about a completed bill run schedule is
displayed on the Bill Run Details form. An example of this form is
shown below.
The components on the main part of the form are outlined in the
following table.
Component Description
Bill Run field The Bill Run ID
Bill Run Type field The type of bill run created
This comes from the Bill Run Type field on the
Parameters tab of the bill run schedule
Status field The last operation performed

Creation Start Date The creation date of the Bill Run
field
Effective Date field The effective date of the Bill Run
Page 128 CB v4.02

Billing Operations
Component Description
Effective Day of Usually the same day of the month as the
Month field Effective Date, but in cases where the Effective
Date falls on the last day of the month, the
Effective Day Of Month may be moved
forward or backward to maintain consistent
recurring event periods
Quality Assurance Whether the Bill Run is a Quality Assurance
Bill Run? field Bill Run or not
Perform Operation Displays the Perform Operation form listing
button further billing or revoke operations that may be
performed
Failed Customers Displays a list of all customers in the bill run
button with a status of Failure. Included in the list is
the operation that failed and the error message
reported
Refresh button Refreshes the fields on the Bill Run Details
form
The Perform Operations Button
All of the possible operations that may be performed for a bill run are
accessed via this button. Whether progressing a bill run, or revoking
individual steps, or revoking an entire bill run, these operations are
accessed from here.
The form also contains five tabs outlining additional information about
the bill run. They are: Details, Summary of Operations, Pending Tasks,
General and Auditing Information. The information displayed on these
tabs is outlined in the following sections.
CB v4.02 Page 129

Billing Operations
Details Tab
This tab is divided into four sections:

1. Customer Billing Details
Displays the number of customers processed by this bill run and the
total amount billed in the bill run, for reconciliation purposes
2. Last Operation
The Name field displays either the:
− The Bill Run Type of the task that performed the last operation,
or
− If the last operation was performed by via a direct TRE call, the
name that the TRE gave to the last operation
Clicking on the Details button displays the details of the task
3. Billing Schedule
Displays the name of the schedule that ran the task. Clicking on the
Details button displays the details of the schedule
4. Creation Task
Displays the task id of the bill run. Clicking on the Details button
displays the details of the task
Page 130 CB v4.02

Billing Operations
Summary of Operations Tab
This tab displays all of the operations performed by the bill run, plus a
great deal of information about each operation.
Ticking the Combine Billing and Revoke Operations? check box at the
bottom of the tab removes all revoke operations from the list. This has
the effect of just showing the final status of the bill run
The fields on this tab are outlined in the following table.
Field Description
Operation The operations performed by the bill run
Earliest Start Date The earliest start date of each operation
Latest End Date The latest end date of each operation
Operation Count The number of times the operation ran
Amount The total amount that was billed by the
operation
Total Duration The total time (in seconds) taken by the
operation
Average Duration The average time (in seconds) taken to perform
the operation. Not displayed when the Combine
Billing and Revoke Operations? check box is
ticked
Eligible Customers The number of customers initially eligible and
accepted as input to the operation
CB v4.02 Page 131

Billing Operations
Field Description
Successful The number of customers processed
Customers successfully by the operation
Failed Customers The number of customers with a status of
Failure
Skipped Customers The number of customers eligible, but skipped
before the operation started
Suppressed The total number of customers eligible, but
Customers whose results were suppressed following
processing by the operation
Invoices The number of invoices produced
Statements The number of statements produced
Images The number of images stored for the operation
Stored Images Size The size of the stored images
Customer Nodes The number of customer nodes processed
Services The number of services processed
Events The number of events processed
Error Events The number of Error Events processed

Rating Charges The number of rating charges generated
Billing Charges The number of billing charges generated
Page 132 CB v4.02

Billing Operations
Pending Tasks Tab
This tab lists any pending tasks in the system for the bill run. The fields
on this tab are outlined in the following table.
Field Description
Task Id The task ID of the pending task
Operation The billing operation to perform
Start Date The start date of the billing operation
General Tab
This tab displays the last 10 fields from the Summary of Operations tab.
CB v4.02 Page 133

Billing Operations
Auditing Information Tab
This tab contains two sections.
The bottom part displays any error information for each of the
operations.
The top part displays the same fields as the Summary of Operations tab,
with two additional fields, as outlined in the following table.
Field Name Description

Task The task ID that invoked the operation, if any
Process Name The name of the function or script that

performed the operation, if any
Page 134 CB v4.02

Billing Operations
Exercise 11 – Billing Results

Check the results of your bill run and answer the following questions:
1. What is the task number for your bill run?
2. How many billing charges were generated?
3. How many rating charges were generated?
4. How many invoices were generated?
5. Did you generate any Rental charges? Where are they?
CB v4.02 Page 135

Billing Operations
Correcting Billing Errors

Display Slide 42 –Billing Errors
Errors in the billing process could result in any of the following:

• Bill run failure
• Incorrect billing or invoice details
• Incorrect invoice printing
• Single customer errors
Bill Run Failure

If the bill run completes with a Task Status of Failure, the steps to
correct this are:
1. Check all the required server processes are running
2. Check the causes of failure reported on the Results tab of the Task
form
3. Check the Bill Run Details form. On the Auditing Information tab,
for each operation performed, you can examine the Error Details for
the Operation field at the bottom of the form
4. Examine the log.out file on the server to see if there were any
messages pertaining to the bill run displayed
Incorrect Billing or Invoice Details

After reconciling the results of a bill run, the invoice details may be
incorrect. Incorrect billing or invoice details may be caused by any of
the following:
• Wrong or incorrect invoice format
• Rating errors
• Billing errors
• Incorrect invoice print
Page 136 CB v4.02

Billing Operations
Wrong or Incorrect Invoice Format
If the invoices are not showing correct information or the format is

incorrect, the steps to correct this are:
1. Perform the Revoke Invoice Images operation
2. Make any changes to the invoice templates as required
3. Perform the Complete Bill Run operation to generate the invoice
image again
Rating Errors
If there are errors as a result of rating events, the steps to correct this
are:
1. Perform the Revoke Bill Run operation
2. Revoke the events or the event files causing the errors
3. Correct the appropriate tariffs or events
4. Re-rate the events or event files
5. Perform the Complete Bill Run operation
Billing Errors
If there are errors as a result of billing, such as an incorrect subtotal or

discount tariff, the steps to correct this are:
1. Perform the Revoke Bill Run operation
2. Correct the appropriate tariffs or subtotals
3. Perform the Complete Bill Run operation
Incorrect Invoice Print
If there is an error printing the invoices, such as paper problems, the

steps to correct this are:
1. Perform the Revoke Invoice Print Settings operation
2. Correct the printing problem
3. Perform the Print Invoices operation to reprint the invoices
CB v4.02 Page 137

Billing Operations
The entire process of correcting billing errors is summarised in the

following diagram.
Start
Perform Complete
Bill Run
Perform Bill Run

(Standard or QA)
Check and correct
schedule
parameters
Bill run
Yes (RGP,BGP,IGP)
successful?
View bill run

No
details
Reconcile billing
details
Billing and invoice Perform Revoke

No
details correct? Bill Run
Yes
Perform Print Correct printing Reason for

Invoices problem Rating error incorrect Billing error
details?
Invoice format
Perform Revoke Correct billing

Invoice print Correct rating Correct rating
No Invoice Print tariff/subtotal/
successful? tariffs tariffs
Settings customer details
Yes
Perform Apply Re-rate affected

Invoices events
Finish
Single Customer Errors

For relatively small numbers of customers with billing errors, it is not
necessary to perform corrective billing operations on all customers in
the invoice cycle.
Page 138 CB v4.02

Billing Operations
For customers that failed billing:

1. On the Bill Run Details form, click on the Failed Customers button
to determine the failed customers and the reason for the errors
2. Correct the errors
3. Perform the bill run again. The system does not attempt to re-bill the
successfully billed customers, just the failed customers
For customers that billed successfully, but with incorrect results, revoke
and re-bill just these customers:
1. Display the customer on the Customer form
2. Select the Billing tab
3. Click on the Bill Run Details… button
CB v4.02 Page 139

Billing Operations
This displays the Bill Runs for Customer form.
The left-hand side of the form displays all of the bill runs performed
for this customer.
4. Select the appropriate bill run from the list
This displays the operations performed for that bill run in the right-
hand side of the form.
5. Click on the Perform Operations… button
Page 140 CB v4.02

Billing Operations
This displays the Perform operation for Customer form with a list of
valid operations for just this customer.
6. Select and submit the appropriate billing operation for the customer
CB v4.02 Page 141

Billing Operations
Guided Practice 9 – Correcting Billing Errors

The purpose of this guided practice is to view an invoice image, and
assuming a problem exists with the invoice, revoke the bill run, fix the
problem and perform the bill run again
1. Select Accounts ð The Invoice Search form displays.

Invoices
2. Enter Bill Johnsonxx The Invoice form for your customer displays.
in the Customer
Name field
3. Click
If more that one invoice exists for the customer, a list displays allowing
you to select one and then display the details.
4. Select the Images tab
Page 142 CB v4.02

Billing Operations
5. Click Adobe Acrobat displays the invoice image.
There is a problem with the Frequent User Discount displaying on the

invoice. It should only apply when the total of the call charges is greater
than $30.00.
Using the process flow outlined on page 138, determine what the
problem is.
The eligibility expression for tCC_Voice_Discount# causes the discount

to generate when the total of charges is greater that $10 not $30.
Change this expression to be sCC_Voice_Charge > 30.00
After fixing the problem, use the Bill Run form to revoke the bill run
and run it again.
6. Select Server Tasks The Bill Run Search form displays.

ð Bill Runs
The Bill Run List form displays.
7. Click
CB v4.02 Page 143

Billing Operations
8. Select your bill run

from the list and
display the details
9. Click The Perform operation for Bill Run form displays.
Page 144 CB v4.02

Billing Operations
10. Select Revoke Bill The One-Off Task form displays in Inserting mode.
Run
11. Click
12. Click When the task completes, a message displays asking if you wish to
view the results.
The Task form displays with the details of the task. Ensure the bill run
13. Click
revoked successfully.
The Bill Run Details form displays.
14. Click
CB v4.02 Page 145

Billing Operations
15. Click The Perform operation for Bill Run form displays.
16. Select Complete Bill The One-Off Task form displays in Inserting mode.
Run
17. Click
Page 146 CB v4.02

Billing Operations
18. Select
Invoice/Statement
Image generation in
the To Operation
field
When the task completes, a message displays asking if you wish to

19. Click
view the results.
The Task form displays with the details of the task. Ensure the bill run
20. Click
completed successfully.
View the invoice image again to ensure it is correct. If not, repeat the
steps outlined in the above guided practice.
CB v4.02 Page 147

Billing Operations
Applying and Allocating Invoices

After confirmation that all of the invoices are correct, they may be
allocated to the customers' accounts.
From the Bill Run form, the Apply Invoices or Apply & Allocate
Invoices operations perform this.
As stated previously, Apply Invoices applies the invoices to the

customers' accounts. Apply & Allocate Invoices also allocates any
unallocated payments or adjustments to the invoice.
Exercise 12 – Apply and Allocate Invoices

1. View the customer's account balance. It should be $0.00
2. From the Bill Run form, apply and allocate the invoice.
3. When this is complete, view the account balance again. What is the
balance now?
4. Unapply the invoice and check the account balance again.
5. Finally, reapply and allocate the invoice again.
Page 148 CB v4.02

Billing Operations
Collecting Diagnostic Information

Display Slide 43 – Tracing
Some problems during the billing process require that server tracing be
turned on in order to provide detailed process information on what the
program is actually doing. This diagnostic information can be useful for
support personnel responsible for correcting system problems. It is
particularly useful for BGP failure.
Failures Due to Data Problems

The most common problems with the BGP are due to problems with the
data, not the system itself. The BGP (and other server processes) expect
that certain relationships exist between the data entities. If a certain
relationship does not exist, the BGP may stop processing and exit.
For example, a row in the CHARGE table may reference a

NORMALISED_EVENT_ID, but if a row does not exist in the
NORMALISED_EVENT table with that NORMALISED_EVENT_ID,
the BGP will fail when processing the charge. Such BGP failures are
usually indicated by the BGP failing with a corresponding message
appearing in the log file such as “Internal error at line NNN in
XXXX.c”.
BGP Tracing
When a data error is the expected cause of a billing failure, BGP tracing
should be turned on using the PHA trace level.
CB v4.02 Page 149

Billing Operations
This is done by specifying PHA in the DEBUG_LEVEL attribute of the

BGP configuration item, as shown on the example of the Configuration
Item form below.
PHA tracing provides information about what entity the BGP was
processing when it failed. This is the entity that has the data problems
and needs to be fixed.
The BGP must be restarted to activate the tracing option.
Prior to CB v4.00, this trace is enabled by specifying ‘–d PHA’ in the

BGP Command Line Parameters field of the Invoice Generation task.
PHA level tracing outputs the entity the BGP is processing (for
example, processing Customer Node with ID XXX, processing Event
with ID XXX, processing Charge with ID XXX).
Data problems causing billing failures can usually be investigated and

resolved by GCS teams themselves, without requiring a Singl.eView
Support ticket to be raised.
Page 150 CB v4.02

Billing Operations
GCS teams can analyse the PHA trace files to determine what entity the
BGP was processing when it failed (go to the end of the trace file). Once
the entity has been found, the actual data problem needs to be
determined. Doing a DVP on the database tables associated with this
entity should highlight what the problem is.
When turning tracing on, do not multi-stream the BGP (if possible) as a
separate trace file is generated by each BGP process and it is easier to
see what is happening if there is only one trace file.
The trace file (or files) is generated in the

$ATA_DATA_SERVER_LOG directory and has the name
bgp<pid>.trc where <pid> is the process ID of the BGP process
generating the trace file.
Incorrect Processing
Another type of billing problem occurs when the BGP is successful, but
does not appear to be performing the correct operation. Examples of this
are:
• A tariff is not generating a charge and the configuration and event
data indicate that it should be
• A subtotal not totalling values correctly
These problems also require trace information to be generated. In this

case both the PHA and the VAR tracing needs to be enabled. This is
done by specifying PHA,VAR in the DEBUG_LEVEL attribute of the
BGP configuration item.
Prior to CB v4.00, this trace is enabled by specifying

‘–dPHA,VAR’ in the BGP Command Line Parameters field of the
Invoice Generation task.
VAR tracing produces large amounts of trace information. For this

reason it is recommended that a small bill run (that is, one customer
with low numbers of events) be performed. This may require the
removal of a specific customer to a test invoice cycle if the problem is
being investigated in the production environment. Multi-streaming of
the BGP should be avoided when performing a test bill run to produce
tracing information.
CB v4.02 Page 151

Billing Operations
The trace files that are generated can be forwarded to the support team
for examination.
Details of tracing for other CB server processes can be found in the

System Administration Guide for Singl.eView Convergent Billing.
Page 152 CB v4.02

Billing Operations
Process Payments
The payment interface is used to send payments to Singl.eView. The
different payment types are Cash, Bank Cheque, Credit Card, Direct
Debit, Debit Card and ECS. All payments are collected and collated at
the payment server and sent to Singl.eView in batches of files. The
payment server executes payment reversals in Singl.eView by inserting
Payment reversal records in the file batch sent to Singl.eView.
Payments will be applied against the oldest outstanding invoice first

(first in first out) If no invoice exists, then it will be credited against the
account.
Uploading of payments is performed using the Process Payments

schedule type, either as a one-off task or as a schedule.
The Process Payments schedule type may need to be run more than once
a day and can be scheduled to run at regular frequencies.
following table.
Process Payment Description

Parameter
File Pattern TDA*
An example of a completed One-Off Task form with a Process Payment

schedule type is Task 20521.
CB v4.02 Page 153

Billing Operations
Payments are made against account not invoices

Display Slide 44 – Payments made against account
Once the payments have been uploaded successfully into Singl.eView

they need to be applied to the individual account. The payments are
allocated on an oldest invoice first principle and if there are no
outstanding invoices the monies are allocated to the account to be
subtracted on the next invoice generation.
Page 154 CB v4.02

Billing Operations
Exercise 13 – Process Payment

6. What is the process for Process payments into Singl.eView, What
are the steps involved?
The Process Payments schedule is run and payments are loaded into
Singl.eView, The payments are then applied to the account
7. What is the principle of account allocation?
Oldest invoice first
CB v4.02 Page 155

Billing Operations
Guided Practice 10 – Payments Upload

• Familiarise yourself with the Payments Upload schedule type and its
parameters
Task ID 20521
Page 156 CB v4.02

Billing Operations
Payment Allocation Results

Display Slide 45 – Payment Allocation Results
After allocation has completed, you can confirm it ran successfully or

not by checking the:
Upload Payments task
• Check payment against customer account
• log.out file
CB v4.02 Page 157

Billing Operations
Fraud Management Schedule
The fraud management interface will generate a file, which will be

pushed to SecureWave via FTP. The file contains information regarding
customers, products and services as well as some account information.
Each file will represent the difference (Deltas) since the last time the
schedule has been run.
The format of the file is ASCII and the name of the datafeed file will use
format ‘FRDMGT_YYYYMMDD_hhmmss.frd’
The file generation is performed using the Fraud Management Extract

The Fraud Management schedule type may need to be run more than
once a day and can be scheduled to run at regular frequencies.
following table.
Fraud Management Description

Extract Parameter
Effective Date All the updates since this effective date
will be picked up
Fraud Management Files

Display Slide 46 – Fraud Mgt
Once the Fraud Management Extract has been run successfully from
Singl.eView the downstream system will need to load the file.
Page 158 CB v4.02

Billing Operations
Exercise 14 – Fraud Management

8. What is the process for Fraud Management Extract from
Singl.eView, What are the steps involved?
The Fraud Management Extract schedule is run and ftp to the

downstream system
9. What is the name of the down stream system?
SecureWave
CB v4.02 Page 159

Billing Operations
Guided Practice 11 – Fraud Management

• Familiarise yourself with the Fraud Management schedule type and
its parameters
See Task ID 20523

10. Where is the file saved to? (Hint check out the configuration item)
The File is saved to $ATA_DATA_SERVER_OUTPUT/frdmgmt
For configuration item RIC Fraud Management Config)
Page 160 CB v4.02

Billing Operations
Fraud Management Extract Results

Display Slide 47 – Fraud Management Extract Results
After allocation has completed, you can confirm it ran successfully or

Fraud Management Extract task
• Check file has been sent to SecureWave
• TASK ID 20523
CB v4.02 Page 161

Billing Operations
GL Upload
The General Ledger Upload interface is required to upload summarised
financial information to a staging table “SAP_GL_UPLOAD” stored in
the CBS environment. This table is then accessed by the SAP financials
system to upload into SAP system.
The SAP financial system requires the following report:
Billed Charges
Collections (Payments and Adjustments)
Unbilled Charges (Unapplied charges and charges not invoiced)
Code definition:
BL for Billing charges
RA for refunds
PY for Payments
NA for Non-Refund Adjustments
PR for Provisioning
This Schedule is run at different times in the month with the staging
table pushed to the SAP server using FTP. Uploading of GL files is
performed using the GL Upload schedule type, either as a one-off task
or as a schedule.
The GL Upload schedule type will be run once a month and can be
scheduled to run at regular frequencies.
following table.
Page 162 CB v4.02

Billing Operations
GL Upload Parameter Description

GL Transaction type Billed Charges
Non-Refunding Adjustments
Paymants
Refund Adjustments
SAX Commission
UnBilled Charges
An example of a completed One-Off Task form with a GL Upload

schedule type is shown below.
When to run GL Upload

Display Slide 48 – GL Upload run
Once the GL have been uploaded successfully from Singl.eView they

need to process the file.
GL Upload Parameter When to run
Billed Charges After each bill cycle
Payments Daily
Non-Refunding Monthly
Adjustments
Refund Adjustments
SAX Commission
UnBilled Charges
An An example of a completed One-Off Task form with a GL Upload
CB v4.02 Page 163

Billing Operations
Exercise 15 – GL Upload
11. What are the five codes for the files generate?
The GL Upload schedule is run it produces 3 files out of Singl.eView,

The code are BL, PY and PR
12. When should the uploads be run?
See table above
Page 164 CB v4.02

Billing Operations
GL Upload Results
Display Slide 49 – GL Upload Results
After GL Upload has completed, you can confirm it ran successfully or

GL Upload task
TASK ID 20522
CB v4.02 Page 165

Billing Operations
Treatment Monitoring
Singl.eView will be configured to run a treatment monitor schedule. For
different customer levels there are different treatment levels. The
treatment monitor will identify if the customer treatment level increases
of if the customer is eligible to come off treatment.
Treatment Monitoring is performed using the Treatment Monitoring

The Treatment interface schedule type will be run once a month and can
be scheduled to run at regular frequencies.
following table.
Treatment Monitoring Description

Parameter
Customer Type Select from the drop down list
Credit Risk Low, Medium, High, VIP
Where Clause Customer specific if required
Treatment Monitoring
Display Slide 50 – Treatment Monitoring
Once the Treatment Monitoring should be run daily after any payments
have been made.
Page 166 CB v4.02

Billing Operations
Treatment Monitoring Results

Display Slide 51 – Treatment interface Results
After Treatment Interface has completed, you can confirm it ran

Treatment Interface task
• Check files have been created
• Task ID 20524
CB v4.02 Page 167

Billing Operations
Treatment Interface
Singl.eView will be configured to run a treatment schedule. For
different treatment levels, different actions need to be taken The range
of actions includes sending dunning letters, sending an SMS message,
sending an automatic IVR message or sending a request to provisioning
in order to suspend, un-suspend, barr or un-barr a particular service or
feature
Singl.eView will produce 4 different files for the treatment purpose. The
4 different files will be executed by 4 different systems. These 4
treatment interfaces types identified are SMS, IVR, Letters and
Provisioning (Suspension, barring etc) All these files will be pushed to
Clarify for them to upload.
Treatment files is performed using the Treatment Interface schedule

type, either as a one-off task or as a schedule.
following table.
Treatment Interface Description

Parameter
Clarify FTP Config Item RIC_TREAT_CLARIFY_FTP
IVR FTP Config Item RIC_TREAT_IVR_FTP
SMS ftp Config Item RIC_TREAT_SMS_FTP
Directory Config item RIC_DIRECTORIES_TREATMENT
An example of a completed One-Off Task form with Treatment

interface schedule type is shown in Task 20525.
Page 168 CB v4.02

Billing Operations
Exercise 16 – Treatment Datafeed

13. What are the four files generate?
The treatment Datafeed schedule is run it produces 4 files out of

Singl.eView, The formats are Code DDMMYYYY.trt
eg.LETTERDDMMYYY.trt
14. What is config item to FTP the files?
RIC_TREAT_IVR_FTP
CB v4.02 Page 169

Billing Operations
Treatment Interface Results

Display Slide 52 – Treatment interface Results
After Treatment Datafeed has completed, you can confirm it ran

Treatment Interface task
• Task ID 20525
Page 170 CB v4.02

Billing Operations
Product Catalogue Output

Singl.eView will provide a script that will publish 5 files in XML format
containing data pertaining to Bundles, reference data, bill cycles,
treatment and products with rate plans. The XML file are made
available for both Clarify (CRM) and Clarity (Provisioning) systems.
The bundle file will include information pertaining to the available rate
plans and which value added service is available with them
Reference data will refer to the subset of reference types in Singl.eView

of interest to Clarify and or Clarity.
The Bill Cycle file will contain the details of all active bill cycles in
Singl.eView.
The treatment file will provide to the other systems the information to
enable them to respond when Singl.eView places an account into
treatment and to maintain the records as such.
Treatment files is performed using the Treatment Interface schedule

type, either as a one-off task or as a schedule.
following table.
Product Catalogue Description

Datafeed Parameter
Effective date Date to report to
Start Date Date task to start
Clarify ftp FTP address
Clarity ftp FTP address
Output Directory RIC_DIRECTORIES_PROD_CAT
Send to Clarify Yes/No
CB v4.02 Page 171

Billing Operations
Product Catalogue Description

Datafeed Parameter
Send to Clarity Yes / No
Send Bundled Files Yes / No
Send Reference Data Yes / No
Send Bill Cycles Yes / No
Send treatment Data Yes / No
Send Product Rate Plan Yes / No

Data
An example of a completed One-Off Task form with Treatment

interface schedule type is shown in Task 20525.
Page 172 CB v4.02

Billing Operations
Quesions before you move on to the Conclusion.
CB v4.02 Page 173

Billing Operations
Participant Handbook – Conclusion
Conclusion xx mins
Display Slide 53 – Review of Learning Objectives
Review of Learning Objectives
By the end of this program you will be able to:

s Describe in detail the process of rating
s Describe in detail the process of billing
Page 174 CB v4.02

Billing Operations
Participant Handbook – Your Notes
Your Notes
CB v4.02 Page 175

Bill Ops Workbook For Reliancev1

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Bill Ops Workbook For Reliancev1

Uploaded by

Copyright:

Available Formats

Convergent Billing v4.

Billing Operations for Reliance Infocomm

The following are trademarks of ADC Software Systems Ireland Limited:

Singl.eView™ Singl.eView Commerce Engine™ Singl.eView Commerce Index™

The following are third party trademarks:

This document is also designed to be used as a reference guide.

Learning Objectives ................................................................................................9

Rating and Billing Overview............................................................................... 10

CB v4.02 Page iii

Guided Practice 3 – Rate Files .......................................................... 55

Your Notes ............................................................................................................175

Windows 2000 experience

End to End training

Facilities and Equipment

Introduction [duration] mins

To obtain a Certificate of Completion for the Operations Program

• Final Assessment Handout at the end of the training program:

Display Slide 1 – Learning Objectives

By the end of this program you will be able to:

Rating and Billing Overview xx mins

The purpose of this section is to overview the Singl.eView Convergent

Rating and Billing Process Flow

Rating and billing is made up of six operations:

5. Invoice Output: Invoices and statements are output to a printer or

Prerequisites for Rating and Billing

What do you need for rating and billing to occur successfully?

Look for answers such as:

Display Slide 3 – Prerequisites for Rating and Billing

Before we move on to rating and billing, lets review these requirements.

Display Slide 4 –Product Definition

A representation of this is shown in the following diagram.

Selection Components Costing Components

Service Types Derived Facility

At a minimum, the key components in the product definition are the

A product instance is created by selling a product definition to a

A crucial element in the customer’s product instance is the associated

Display Slide 6 – Guiding

Tariffs defined for

Product Usage and Events

Events can originate from many different sources, including:

The information contained within an event varies depending on the

Exercise 1 – Create a Customer and a Product

Perform the following steps:

Ensure all participants have active customers and products before

Rating is the process of accepting events into CB and processing them

Event Term Description

The rating architecture is outlined in the following diagram.

Corrupted Service and

ENM error ERT

The processes in rating are the:

Only one instance of the ERB can be running at a time. However,

Event Rating Broker (ERB)

The ERB performs the following:

Event Normalisation (ENM)

Multiple ENMs may be configured to process events:

In either case, the processing flow in an ENM is as follows:

3. The ENM applies expressions to the variables. These expressions

Display Slide 10 – ENM Process Flow

The flow of event normalisation is summarised in the following

Corrupted events are sent to an error

Parsed data fields

Event Rating (ERT)