bill ops workbook for reliancev1

Convergent Billing v4.02Operations Program

Billing Operations for Reliance Infocomm

Participant HandbookDocument 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 thisdocument, ADC Software Systems Ireland Limited makes no warranty, expressed or implied, withrespect to the quality, correctness, reliability, currency, accuracy, or freedom from error of thisdocument or the products it describes. ADC Software Systems Ireland Limited may makeimprovements 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 documentor from the use of any products described in this document. Mention of any other product not owned byADC 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 realpersons or companies is entirely coincidental.

Persons reading this document should rely on their own enquiries in making any decisions touching ontheir own interests.

Licence Agreement

The software described in this guide is supplied under a licence agreement and may only be used inaccordance with the terms of that agreement.

.

Copyright Information

© 2002 ADC Software Systems Ireland Limited. All rights reserved. Apart from any use permittedunder the Copyright Act, no part may be reproduced by any process without the written permission ofADC 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 USAand other countries. TEX is a trademark of the American Mathematical Society. PostScript and AdobeReader are trademarks of Adobe Systems Incorporated. UNIX is a registered trademark of The OpenGroup. TUXEDO is a registered trademark of BEA Systems, Inc.

Document Name

F:\

CB v4.02 Page i

Billing Operations

Aim

The purpose of this document is to provide the trainer with a guide to the preparation and training ofBilling Operations. Use of this document will ensure that the training of this program is asappropriate and effective as possible.

The purpose of this document is to lead you through the key points and procedures you will need toeffectively 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 isstructured 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

Page ii CB v4.02

Participant Exercise

6 Time Permitting

Trainer Note

Billing OperationsParticipant Handbook – Table of Contents

CB v4.02 Page iii

Table of Contents

Module Outline..........................................................................................................2

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

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

Rating and Billing Process Flow.................................................................. 11Prerequisites for Rating and Billing............................................................. 12

Product Definitions ............................................................................... 12Product Instance................................................................................... 13Product Usage and Events ................................................................. 14Exercise 1 – Create a Customer and a Product Instance ............. 15

Rating....................................................................................................................... 16

Event Terminology......................................................................................... 17Rating Architecture ........................................................................................ 18

Event Rating Broker (ERB)................................................................. 19Event Normalisation (ENM) ................................................................ 19Event Rating (ERT).............................................................................. 22Event Rating Output (ERO) ................................................................ 24Exercise 2 – Rating .............................................................................. 24

Location of Rating Files ................................................................................ 27Rating Files from Multiple Sources.................................................... 28

Configuring Rating Processes ..................................................................... 29Configuration Items.............................................................................. 29Guided Practice 1 – View an ENM Configuration Item .................. 31How the ENM Selects an ERT and ERO Process.......................... 37Exercise 3 – View Other Rating Configuration Items..................... 38Guided Practice 2 – Create an ENM Configuration Item............... 39

Managing Rating Tasks ................................................................................ 41Pre-rating Tasks ................................................................................... 41Scheduling Server Tasks .................................................................... 43

One-Off Tasks and Schedules .................................................................... 45Schedule Types.................................................................................... 45One-Off Tasks....................................................................................... 46Exercise 4 – Schedule Types and One-Off Tasks.......................... 47Schedules.............................................................................................. 48

Rating Event Files.......................................................................................... 51More on ENM File Types and ENM Event Types ........................... 52Exercise 5 – Performing Rating ......................................................... 54


Page iv CB v4.02

Guided Practice 3 – Rate Files .......................................................... 55Rating Results ................................................................................................ 57

Task Status and Results ..................................................................... 57Input, Archive and Error Directories.................................................. 58log.out File ............................................................................................. 58Normalised Events ............................................................................... 59Error Events .......................................................................................... 60Exercise 6 – Rating Results ............................................................... 61Guided Practice 4 – View the Normalised Events .......................... 63

Correcting Rating Errors............................................................................... 68The Rating Task Fails.......................................................................... 68Corrupted Events ................................................................................. 68Error Events .......................................................................................... 69Incorrect Charges................................................................................. 70Rating Schedule Types ....................................................................... 72Exercise 7 – Correcting Corrupted Events....................................... 73Guided Practice 5 – Correcting Error Events................................... 74

Revoking Rating............................................................................................. 83Which Schedule Type for Revoking?................................................ 83Exercise 8 – Revoking Rating ............................................................ 84

Billing ....................................................................................................................... 85

Billing Terminology........................................................................................ 86Bill Runs and Invoice Cycles .............................................................. 86Reporting Levels................................................................................... 87Suppress Billing .................................................................................... 89

Billing Architecture......................................................................................... 91Rental Generation Process (RGP).................................................... 92Bill Generation Process (BGP)........................................................... 94Invoice Generation Process (IGP)..................................................... 95Applying and Allocating Invoices ....................................................... 96General Output Process (GOP)......................................................... 97

Configuring Billing Processes ...................................................................... 99Configuration Items.............................................................................. 99Guided Practice 6 – View a BGP Configuration Item...................100Billing Streaming.................................................................................104Exercise 9 – View Other Billing Configuration Items ....................109

Managing Billing Tasks...............................................................................110Pre-billing Tasks .................................................................................110Bill Run Schedules .............................................................................112Bill Run Schedule Types...................................................................114Guided Practice 7 – Create a Bill Run Schedule ..........................120Exercise 10 – Update A Customer with a New Invoice Cycle.....123Guided Practice 8 – Run a Pending Schedule ..............................124


CB v4.02 Page v

Billing Results...............................................................................................126Task Status and Results ...................................................................126Bill Run Details Form.........................................................................128Exercise 11 – Billing Results ............................................................135

Correcting Billing Errors..............................................................................136Bill Run Failure ...................................................................................136Incorrect Billing or Invoice Details ...................................................136Single Customer Errors .....................................................................138Guided Practice 9 – Correcting Billing Errors ................................142

Applying and Allocating Invoices...............................................................148Exercise 12 – Apply and Allocate Invoices ....................................148

Collecting Diagnostic Information..............................................................149Failures Due to Data Problems........................................................149BGP Tracing........................................................................................149Incorrect Processing ..........................................................................151

Process Payments.......................................................................................153Payments are made against account not invoices .......................154Exercise 13 – Process Payment......................................................155Guided Practice 10 – Payments Upload ........................................156Payment Allocation Results..............................................................157

Fraud Management Schedule ...................................................................158Fraud Management Files ..................................................................158Exercise 14 – Fraud Management ..................................................159Guided Practice 11 – Fraud Management.....................................160Fraud Management Extract Results................................................161

GL Upload.....................................................................................................162When to run GL Upload.....................................................................163Exercise 15 – GL Upload..................................................................164GL Upload Results .............................................................................165

Treatment Monitoring ..................................................................................166Treatment Monitoring.........................................................................166Treatment Monitoring Results ..........................................................167

Treatment Interface .....................................................................................168Exercise 16 – Treatment Datafeed..................................................169Treatment Interface Results .............................................................170

Product Catalogue Output..........................................................................171

Conclusion ...........................................................................................................174

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

Billing OperationsParticipant Handbook – Module Outline

CB v4.02 Page 1

Program Outline

Program:

Operations Program

Pre-Requisites:

Windows 2000 experience

End to End training


Page 2 CB v4.02

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


CB v4.02 Page 3

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


Page 4 CB v4.02

Preparation Checklist

Instruction

Instructors will have formal teaching or training qualifications or becurrently employed in an area related to the module content.

Facilities and Equipment

This program will be delivered in a room equipped for the instruction ofcomputer 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 withcapabilities of 1024 x 768 resolution

• All workstations to be configured with access to the appropriatetraining database

• Whiteboard or Flip-Chart

• Whiteboard markers and erasers

Billing OperationsParticipant Handbook –

CB v4.02 Page 5

Database Preparation

You need to check the following for the database you are training with:

• Participant user names and passwords are set up with correctsecurity settings (full access rights and permissions if the training isto take place in a non-production database).

It is necessary to determine the number of participants to ensurethere are sufficient Trainee Logins.

User Name train01 Password train01User Name train02 Password train02….User Name train08 Password train08

• Trainer user name and password is set up (with full access rightsand permissions).

User Name trainer01 Password trainer01

• Windows desktop shortcuts to the training database are set up andfunctioning 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 BillingOps Event File Generator.xls

As participants create their own customer and assign a product tothat customer, all in the one day, the date of the events in the eventfiles you create need to be just after product creation.

Instructions for creating the proper events are in the Event FileGenerator for Billing Ops .xls file on the Data tab

• The sS_CLEC_DIS_InvChg# is updated to includetCC_Voice_Discount# as an Expression to be Aggregated on theTerms tab

This ensures the discount displays on the invoice. Otherwise, thediscount is calculated into the invoice total, but does not actuallyappear as a line item


Page 6 CB v4.02

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


CB v4.02 Page 7

− 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 Programparticipants:

• 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 madeup of the following components:

• Learning Objectives

− Identify the skills and concepts that the trainee must be familiarwith

• Overview

− Provides a conceptual overview of a topic

• Guided Practice

− Trainer demonstrates a task

− Trainee repeats the task following the step-by-step instructionsin their handbook

• Self Assessment

− Made up of written and practical exercises

− Addresses the key learning objectives

− Practical portion of the self-assessment based on realisticbusiness situations

− Provides the trainee with the opportunity to assess theirunderstanding of the concepts and tasks that were presented tothem in the module


Page 8 CB v4.02

• 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 theonline help to complete the assessment

− Final Assessment will be evaluated by the trainer

Billing OperationsParticipant Handbook – Learning Objectives

CB v4.02 Page 9

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

Billing OperationsParticipant Handbook – Rating and Billing Overview

Page 10 CB v4.02

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 andservices, assigning these charges to customers and then invoicing thecustomers. Service providers must be able to perform rating and billingoperations in an efficient manner.

The purpose of this section is to overview the Singl.eView ConvergentBilling (CB) rating and billing process flow and review what is requiredfor rating and billing to occur successfully.


CB v4.02 Page 11

Rating and Billing Process Flow

Display Slide 2 – Rating and Billing Process Flow

The entire rating and billing process flow is summarised in the diagrambelow.

Usage

Events

Rental

One-off

Events

Remotehost

Carrier

Switch

Remotehost

Normalisation

Apply Invoices

Rating InvoicingBilling

Rating Billing

Invoices

Invoicedata

Normalisedevents

Database

Invoice images

Charges

Invoice Output

Charg

es

Briefly walk the participants through the Rating and Billing processflow diagram. Emphasise that the diagram is a process, so that thearrows pointing from one box to another are indicative of the processflow, not the actual results. For example, charges generated from ratingare 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 detailsabout a product or service (events) are converted to a normalisedformat (a native CB format) for storage in the CB database

2. Rating: Normalised events are rated by applying the appropriatetariffs to produce a series of charge records

3. Billing: Recurring charges, discounts, one-off charges andadjustments are calculated, and combined with the charge recordscalculated in rating. These charge details are combined withcustomer detail records, ready to appear on the invoice

4. Invoicing: Billing data is combined with an invoice or statementformat and an invoice image is generated


Page 12 CB v4.02

5. Invoice Output: Invoices and statements are output to a printer orsome 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


CB v4.02 Page 13

Display Slide 4 –Product Definition

A representation of this is shown in the following diagram.

Facilities Facility GroupCompatibility

BaseProduct

Definition

ProductGroups

Icon

ProductCompatibility

Costing Components

ChargeCategories

Subtotals

EquipmentTypes

Service Types FacilityGroups

DerivedAttribute

Tables (Lists)

Selection Components

Payment Items

Tariffs

Fundamental Components

Mandatoryelement

At a minimum, the key components in the product definition are theservice type and the tariffs.

The service type defines the functionality of the product, the tariffsdefine the charges for the product.

Product Instance

Display Slide 5 – Product Instance

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

While the product definition specifies all of the mandatory and optionalservices, equipment, tariffs, subtotals and facility groups for thatproduct, the product instance is a unique, one-off copy of the productdefinition, altered to meet the needs of the customer.

A crucial element in the customer’s product instance is the associatedservice, in particular, the service number.


Page 14 CB v4.02

Using the service number, the system is able to link all the way back tothe product definition to get the list of tariffs that may be eligible todetermine charges for the product. This is known as guiding and isillustrated in the following diagram.

Display Slide 6 – Guiding

Service number Service instance Product instance Product definitionTariffs defined for

the productdefinition

Product Usage and Events

The details about the usage of a product or service, which ultimatelyresult in a charge or benefit to a customer, are stored in data recordsknown 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 theevent 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.


CB v4.02 Page 15

Exercise 1 – Create a Customer and a ProductInstance

The purpose of this exercise is to create a customer and assign them aproduct 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. Forexample, 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. Forexample, user train05 should assign train05 as the servicenumber

Ensure all participants have active customers and products beforeproceeding.

This is the end of the Rating and Billing Overview section. Askparticipants if they have any questions, particularly about the guidingprocess, before you proceed.

Billing OperationsParticipant Handbook – Rating

Page 16 CB v4.02

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 themto generate charges. The charges and the rated events are written to thedatabase, or to a different server, or to a file for later upload to adatabase.

This section examines in detail the entire rating process, from eventterminology through to rating events, checking the results and correctingrating errors.


CB v4.02 Page 17

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 outlinedin the following table.

Event Term Description

Raw event An event generated by a switch or some othertype of device. The format of the event isusually specific to the device

Mediated event An event pre-processed in some way beforeinput to CB

Alpha event An event input to CB for normalisation. Rawand mediated events as well as eventsgenerated from with CB are all consideredalpha events

Normalised event An event converted to CB native event format

Corrupted event An alpha event not conforming to the formatfor its source, and hence cannot be normalised

Normalisation errorevent

An event where a normalising expression couldnot be evaluated. Normalisation error eventsare not rated

Rater error events An event causing an error during rating, suchas the incorrect evaluation of a tariff or areference to an undefined service. All previouscharges generated for a rater error event arediscarded

Error event An event in the correct format for its source,but due to the data in the event, either cannotbe normalised or rated. Normalised error andrater error events are both error events

Charge An amount associated with an event after it israted

Rated Event A normalised event, successfully rated andoutput from rating


Page 18 CB v4.02

Rating Architecture

Display Slide 7 – Rating Architecture

The rating architecture is outlined in the following diagram.

ERT

EventRating

process

ERB

EventRatingBrokerprocess

ENM

EventNormalisation

process

ERO

EventRatingOutputprocess

ENM errordirectory

Corruptedevents

Alphaevents

Socket

File

Normalisedevents

Database cache shared memory segment

Inner-process communication shared memory segment

Service andtariff details

Charges

Online

Normalising and rating data

Normalised eventsError eventsCharges

File

Socket

SQL *LoaderFile

Event format

Expressions Database

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 runningdepending on processing requirements.


CB v4.02 Page 19

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 fromthe 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 intonormalised events.

Multiple ENMs may be configured to process events:

• Contained in a file

In this case, the ENM waits for a command to start normalisingevents

• 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 itssource) in a file are appended to an error file of the same name (witha .e extension) in an error directory. Corrupted events from a socketare rejected and the host informed

2. The parsed data fields in the input event are assigned to systemvariables


Page 20 CB v4.02

3. The ENM applies expressions to the variables. These expressionsare used to:

a) Validate the data

b) Calculate an equivalent value for the normalised event. Forexample, if an input field was three digits long and thenormalised event field expected eight, the expression could padthe field with leading zeros

4. The variables are reordered to build the normalised event

5. Successfully normalised events are passed to an ERT process forrating and to an ERO for output. Normalisation error events areonly sent to an ERO for output and are not rated


CB v4.02 Page 21

Display Slide 10 – ENM Process Flow

The flow of event normalisation is summarised in the followingdiagram.

Alpha eventparsed

Parsed data fieldsassigned tovariables

Expressionsapplied to the

variables

Variablesreordered to formthe normalised

event

Normalised eventpassed to an ERO

and ERT

Alpha event

DIL Specification

Expressions:- Validate the data- Calculate values for normalised event

If an expression fails, event is flaggedas a normalisation error event and sentto the ERO for output

Corrupted events are sent to an errorfile

Summarise the ENM process and ask participants if they have anyquestions.


Page 22 CB v4.02

Event Rating (ERT)

Display Slide 11 – Event Rating (ERT)

The ERT accepts normalised events from the ENM and applies tariffs toproduce rated events and charges. Like the ENM, multiple ERTs may beconfigured.

All tariff definitions, derived attributes and functions needed for ratingare preloaded from the database into memory when the rating processesstart.

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 activeservice number in the database. The service number matches with aservice instance and a product instance (including any companionproduct instances) and a customer node. This is the guiding processdiscussed earlier

If an active service is not found, rating fails and the event is flaggedas a rater error event

2. For each tariff associated with the product instance, plus any globaltariffs, the eligibility expressions are evaluated:

a) If they evaluate false, the tariff is discarded and the ERT moveson to the next tariff

b) If they evaluate true the charge expressions for the tariff areevaluated to generate charges records

If a charge expression causes an error, the event is flagged as arater error event and any charges generated to that point arediscarded

If an event fails to generate any charges, the event is flagged asa rater error event


CB v4.02 Page 23

3. The account number specified in the charge category instance isassociated with each charge

Usually, this is the account that corresponds to the account typespecified in the charge category for the tariff. However, the chargecategory 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.

C Party IDmatches with

service number,matches with

product instance

Tariffs associatedwith the product

instance areevaluated

Account numberfrom the service is

associated withthe charge

Charge passed toan ERO for output

Normalised event

Eligibility expressions evaluated, and iftrue, the charge expressions evaluatedto generate charges

If a charge expression causes an error,the event is flagged as a rater errorevent and charges up to that point arediscarded

Events failing to generate any chargesare flagged as a rater error event

Guiding


Page 24 CB v4.02

Summarise the ERT process and ask participants if they have anyquestions.

Event Rating Output (ERO)

Display Slide 13 – Event Rating Output (ERO)

The ERO takes normalised events from the ENM and charges from theERT, 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. EachERO is linked to at least one ENM, and maintains this link for all eventsand charges.

For EROs configured to output to the database, the details ofsuccessfully normalised and rated events are written to theNORMALISED_EVENT and CHARGE tables. The details ofnormalisation error or rater error events are written to theNORMALISED_EVENT_ERROR table.

Exercise 2 – Rating

Answer the following questions about rating.

1. List the four processes within rating and describe their function.


CB v4.02 Page 25

2. What is the difference between corrupted events, normalisationerror events and rater error events?

3. Describe the process known as guiding that determines the list oftariffs to evaluate for an event.

4. The details of successfully normalised and rated events are writtento which two tables in the database?


Page 26 CB v4.02

Ask participants if they have any questions about the rating architecturebefore you proceed to the next section.


CB v4.02 Page 27

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 ratingevents 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. Theenvironment variable $ATA_DATA_SERVER_INPUT points to thesystem input directory.

After rating, event files are moved from the input directory to an archivedirectory. The environment variable$ATA_DATA_SERVER_ARCHIVE points to the system archivedirectory.

Corrupted events are written to an error file with a .e extension in anerror directory. The environment variable$ATA_DATA_SERVER_ERROR points to the system archivedirectory.

The log.out file in a log directory contains status information about allCB processes, including rating.


Page 28 CB v4.02

A suggested structure for these directories is shown in the followingdiagram.

home directory

data

server

archiveinput error log

data_file data_file data_file.e log.out

The log.out file containsprogress and status detailsfrom the rating process

Successfully normalised filesare moved to the archivedirectory

Corrupted events are written toa file in the error directory withthe original file name and a '.e'extension

Rating Files from Multiple Sources

For systems with multiple ENMs, each may be configured with its owndirectory structure to better manage incoming event files. For example,separate subdirectories can be set up within the input, archive and errordirectories for each ENM.


CB v4.02 Page 29

Configuring Rating Processes

Display Slide 15 – Configuring Rating Processes

As stated previously, multiple instances of the ENM, ERT and EROprocesses can be configured to meet the processing requirements of aservice provider. For example, it may be determined that while thenumber of ENM and ERO processes are sufficient for the volume ofevents coming in and going out, there are not enough ERT processes toprocess the events in a timely manner. In this case additional ERTscould be configured.

Other examples of when additional rating processes may be requiredinclude:

• The volume of events that need to be rated requires additionalprocesses

• Events from different sources, such as event stored in files andevents 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, theattributes of individual processes can be fine-tuned to enhance ratingperformance.

There are no absolute guidelines for determining the optimal number ofrating processes or attributes for individual processes. A configurationthat provides good rating performance for one service provider mayprovide poor performance for another. The only way to determine the'best' configuration is by analysis of event volumes and eventcharacteristics versus current rating performance, and then using thatinformation to experiment with different configuration options.

Configuration Items

All of the rating processes (plus other types of processes) started andmaintained by the system are determined by Configuration Items set upin the system. Creating new configuration items result in new processes.The configuration item for a process specifies all of the attributes forthat process. Each process has its own configuration item.


Page 30 CB v4.02

Like other entities in CB, configuration items are created from thecharacteristics defined in configuration item types.

Configuration items can be created and maintained from the CB clientby selecting Maintenance ð Server ð Configuration Items, or by usingthe cfg configuration utility at the UNIX command line.

This training concentrates on maintaining configuration items via theCB client only. Information on how to use the cfg configuration utility isfound in the System Administration Guide for Singl.eView ConvergentBilling v4.02.


CB v4.02 Page 31

Guided Practice 1 – View an ENM Configuration Item

The purpose of this guided practice is to view an ENM configurationitem and its attributes.

Perform the following:

1. Select Maintenanceð Server ðConfigurationItems

The Configuration Item Search form displays.

2. Click The list of configuration items displays in the bottom part of the form.

In the above list, note the three ENM configuration items, ENM1,ENM2 and ENM3. The configuration item type for each is ENM.


Page 32 CB v4.02

3. Select and displaythe ENM1configuration item

The Base Attributes tab determines the attributes of the process whilethe Related Attributes tab determines how the process works with otherprocesses. Not all configuration items have entries on the RelatedAttributes tab.

The attributes on the Base Attributes tab are outlined in the followingtable.

Attribute Name Description

ENABLED Whether the process is startedautomatically by the ERB

COMMAND_LINE_ARGS Command line arguments used atprocess startup

For example, -d 64 turns debugging onfor the EPM. The command linearguments available are listed in theSingl.eView Convergent Billing SystemAdministration Guide


CB v4.02 Page 33


INPUT_METHOD The input method for events

Options are file and socket

INPUT_SERVICE If INPUT_METHOD is socket, thename of TCP/IP service the ENMlistens to for events

HOME_DIR If INPUT_METHOD is file, thedirectory from which event files forprocessing are retrieved

ARCHIVE_DIR If INPUT_METHOD is file, thedirectory to which event files are movedafter processing

FILE_TYPE The Normalised Event File Type for theENM

SYNC The number of events sent to the EROfor output before the ENM stops andwaits for the ERO to process all theevents

The default value is 1000

EVENT_TYPE The Normalised Event Type for theENM

ERB_MACHINE The name of the system running theERB

Must be (or equate to) a fully qualifiedDomain Name Server (DNS) name oran IP address

INPUT_HOSTS If INPUT_METHOD is socket, acomma-delimited list of DNS names orIP addresses from which the ENM mayaccept socket connections

ERB_SERVICE The TCP/IP service for communicationswith the ERB


Page 34 CB v4.02


ERROR_DIR The directory to which event that cannotbe parsed by the ENM are written

Events are appended to a file with thesame name as the input file, with a .eextension

INTERNAL_ERO Not used

EVENT_SOURCE If INPUT_METHOD is socket, a DNSname or IP address to be associatedwith all events processed from a remotehost

INACTIVITY_TIMEOUT The maximum time the ENM waits forevents from a TCP/IP socket beforeclosing the connection

The default is 60 seconds. If set to 0, notimeout occurs

OPERATOR If INPUT_METHOD is socket, anoperator ID to be associated with allevents processed from a remote host

POLL_TIMEOUT If INPUT_METHOD is socket, whilewaiting for events on its TCP/IP socket,the frequency (in seconds) that theENM checks for commands from theERB

GLOBAL_DA_CACHE_SIZE

The maximum number of globalderived attribute tables that may becached at any one time

If the limit has been reached andanother derived attribute table is to becached, the least recently used table isremoved

If no value or 0 is specified, cache sizeis unlimited


CB v4.02 Page 35


FILE_TIMEOUT If INPUT_METHOD is socket, thefrequency with which the ENM closes aTCP/IP socket connection and opens anew one

The TCP/IP socket connection acts likea virtual event file. If no value or 0 isspecified, the timeout never occurs

FILE_EVENT_THRESHOLD

If INPUT_METHOD is socket, themaximum number of events receivedfor rating from the TCP/IP socketconnection

If no value or 0 is specified, the numberof events is unlimited

SYNC_TIMEOUT The maximum amount of time (inseconds) permitted before the ENMwaits for the ERO to re-synchronise

The ENM pauses until the last eventthat it sent has been processed by theERO. If this parameter is set, the systemeffectively guarantees that events andtheir charges will appear in the databaseno longer than SYNC_TIMEOUTseconds after they were rated

This attribute is applicable only ifINPUT_METHOD is socket


Page 36 CB v4.02


QUEUE_CONNECTIONS If INPUT_METHOD is socket, whetherthe ENM queues TCP/IP socketconnection attempts

If true, when the ENM accepts a TCP/IPsocket connection attempt, allsubsequent attempts are queued. Whenthe current connection closes, the ENMaccepts the next connection on thequeue

If false, when the ENM accepts aTCP/IP socket connection attempt, allsubsequent attempts are ignored. Whenthe current connection closes, the ENMlistens on the socket for the nextconnection attempt

The default value is true

The attributes on the Related Attributes tab are outlined in the followingtable.

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 ERTwith the highest priority. 1 is the highestpriority

ERO_PRIORITY The priority assigned to this ERO

Normalised events are sent to the EROwith the highest priority. 1 is the highestpriority

ERT_THRESHOLD The maximum number of events thatmay be queued to this ERT beforesending events to the next highestpriority ERT


CB v4.02 Page 37


ERO_THRESHOLD The maximum number of events thatmay be queued to this ERO beforesending events to the next highestpriority ERO

ERT_GROUP The group number for the ERT

ERTs may be grouped, with each groupperforming a different part of rating foreach event. For example, the ENM cansend multiple copies of each event to anERT in each group (selected on thebasis of priority and threshold). This is aform of parallel tariffing

The rating engine can apply different tariffs to the same normalisedevent in one pass. This is known as parallel tariffing, and makes itpossible to apply separate tariffs that calculate charges to customer,commissions, taxes, loyalty points or competitors tariffs (for billcomparisions).

Parallel tariffing simplifies rating as each event requires only a singlepass through the rating engine. However, it also increases the ERTprocessing load. It may be appropriate to provide two or more ERTprocesses 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 whichnormalised 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 valuesspecified in the ENM are examined. The process with the number ofqueued events furthest away from its specified threshold is selected


Page 38 CB v4.02

• If all processes with the highest priority have exceeded theirthreshold values, then the above criteria is repeated for the processeswith the next highest priority

Exercise 3 – View Other Rating Configuration Items

Allow a maximum of 15 minutes for this exercise (5 minutes perprocess).

View the other rating configuration items including the ERB, ERO andERT. Use online help (Help ð Reference Information ð Index) tosearch for and display the base attribute descriptions for each.


CB v4.02 Page 39

Guided Practice 2 – Create an ENM ConfigurationItem

The purpose of this exercise is to create your own ENM configurationitem, which in turn will set up your own ENM process for use in ratingevents.




2. Click The Configuration Item form displays in Inserting mode.

3. Select ENM in theConfiguration ItemType field

4. Enter ENMxx in theConfiguration ItemName field

5. Complete the fieldson the BaseAttributes tab asshown


Page 40 CB v4.02

6. Select the RelatedAttributes tab

7. Enter 1 in one of theERT_PRIORITYfield and 2 in theother

8. Enter 1 in one of theERO_PRIORITYfield and 2 in theother

9. Enter 10 in all of theTHRESHOLD fields

Remind participants that what they enter in the ERO1/ERT1 orERO2/ERT2 PRIORITY fields determines what ERO and ERT will beused for their rating processes.

10. Click The Configuration Item form displays in Viewing mode.

These changes do not take effect until the ERB is shutdown andrestarted. Your instructor will do this now.

biBkrStop&(1) in the Expression Test form or ecp "biBkrStop&(1) onthe 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 SystemAdministration Guide for Singl.eView Convergent Billing.


CB v4.02 Page 41

Managing Rating Tasks

Before the process of actually rating an event file begins, there are someconsiderations that may assist in a successful rating process. Similarly,there are processes that must be undertaken after the rating process inorder to check that events have rated successfully.

This section looks at the end to end processes needed to prepare forrating, execute rating and to check the rating results.

Pre-rating Tasks

There are certain tasks that can be undertaken prior to running the ratingprocess that will minimise problems during rating. These tasks couldform part of a checklist that identifies the tasks as well as who hasresponsibility 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 ratingactivity that would impact or compete for resources

This would typically be part of the operational plan, which is usuallydeveloped by a system architect. Billing Operations staff need to knowwhat tasks are running, therefore this should still be part of a pre-ratingchecklist.

• The running of a rating task can consume substantial serverresources and requires frequent database access. Demand for serverand database resources may reduce performance, both for the ratingprocess itself, and for concurrent CB processes. If possible, ratingtasks should be run when other system demands are at a minimum.

• If scheduled tasks are identified, these can be modified so they donot impact rating.


Page 42 CB v4.02

It is important to note that the following high-risk tasks should notbe run during rating:

− dbanalyse

− DVP checks

− Update Charge Categories

− Update Lists

− Rotating/sorting partitions.

Other possible risks include running event management reports that arereporting on the same time period as the events being rated. Thesereports may not give accurate results depending on the stage of therating task when the report is run.

• Check that all required rate changes have been made to the ratetables that are needed for this billing period. This is most likely abusiness responsibility

• Correctly name all event files for rating, and place in the correctdirectory

• 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 ConvergentBilling System Administration Guide V5.00.

• Check that Update Lists and Update Charge Categories tasks areeither not required or have already been run (changes in list andcharge category definitions are not automatically extended toexisting product instances)

• Check that there are no enmX.sts (where X represents the sequencenumber of the enm configured in the production environment) filesin the input directory or subdirectories

An enmX.sts is an enm status file that is created while a rating taskis in progress. It is removed at the end of a successful rating job. Ifthe rating task is not completed, the enmX.sts file remains on theserver to indicate where in the event file processing ceased.


CB v4.02 Page 43

Any existing enmX.sts files must be removed before the specificENM server process can be restarted.

• Check that the mandatory server processes required by rating arerunning including:

- Backend Monitor Process (BMP)

- Scheduled Task Dispatcher (STD)

- Task Launch and Monitor (TLM)

The TLM executes tasks as server processes and monitors theirprogress. When a task has been performed, the TLM process notifies theSTD 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 ratingstreams, ensure the ERO for your rating task is active

- Event Normalisation Process (ENM). If there are multiple ratingstreams, ensure the ENM for your rating task is active

If a sound operational plan exists, operations staff would be aware thatmandatory server processes are running.

Scheduling Server Tasks

Most server tasks in CB, including rating tasks, are controlled and runautomatically by the STD and the TLM. These processes arecollectively 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 withoutany further intervention required, and the user is notified on completionof the task.


Page 44 CB v4.02

Every schedule has a schedule type. A scheduled task uses the scheduletype to determine what program to run and how to run it. The scheduletype also defines the parameters that the user needs to provide whendefining a schedule of this type.


CB v4.02 Page 45

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-offtasks allowing you to run rating on demand. Billing tasks must be run asschedules, allowing them to run at specified intervals with specificparameters.

Schedule Types

Whether run as a one-off task or as a schedule, the details of the task torun are defined in a schedule type. A schedule type definition specifiesamong 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 toexecute is rate_files.


Page 46 CB v4.02

Note that the majority of rating and billing schedule types are alreadydefined.

One-Off Tasks

The simplest way to run a task is as a one-off task using the One-OffTask form. The form is accessed by selecting Server Tasks ð One-offTask. 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 followingtable.

Element Description

Schedule Type field The schedule type, and hence the task toexecute

Selecting a schedule type and tabbing out ofthe field displays all of the parameters for theschedule type in the Parameters section


CB v4.02 Page 47

Element Description

Email Address field The email address to notify when the taskcompletes

An email message is only sent if the operator isnot logged on when the task completes

Effective Date fields Items dated up to and including this date andtime 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 Dateare available to be rated

Start Date fields The date and time the one-off task starts

Parameters section The parameter fields associated with theschedule type selected

Display Task button Display the status of a saved one-off task

The button is only accessible after the one-offtask is saved.

Exercise 4 – Schedule Types and One-Off Tasks


1. Select Maintenance ð Server ð Schedule Types to display thedifferent schedule types available.

Select and display at least the Rate Files and the Standard Bill Runschedule types. In particular, note the Server Command field for thedifferent schedule types.

What is the Task Validation field used for?

Entity Validation for parameters fields on the One-Off Task orSchedule forms.

2. Select Server Tasks ð One-off Task to display the One-Off Taskform.

Select different schedule types in the Schedule Type field to see thedifference in the Parameters section


Page 48 CB v4.02

Schedules

Schedules allows you to specify the dates and frequency that a taskexecutes as well as the parameters for the task. Selecting Server Tasksð Schedules displays the Schedule Search form that allows you tosearch 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 alreadyselected 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 typeand the scheduling details


CB v4.02 Page 49

Element Description

Parameters tab Contains the fields to specify the parametersfor the schedule type

The parameters vary for each schedule type

Schedule Type field The schedule type, and hence the task toexecute

Selecting a schedule type and tabbing out ofthe field displays all of the parameters for theschedule type on the Parameters tab

Email Address field The email address to notify when the taskcompletes

An email is only sent if the operator is notlogged on when the task completes

Preschedule countfield

The number of instances of the schedule tocreate in the future

For example, a Preschedule Count of 2 causestwo schedules to be created in advance

Repeat Type field The frequency at which the schedule isrepeated

For example, every hour, every day or the lastday of every month

Repeat Units field The multiplier of the repeat type

For example, a schedule with a Repeat Unit of7 and a Repeat Type of Day, is scheduled torun every week

Schedule Status field Whether the schedule is Active, Failed orPending. Schedules created via the PrescheduleCount feature are created in the future with astatus of Pending

First Date fields The first date and time the schedule runs

Last Date fields The last date and time the schedule runs


Page 50 CB v4.02

Element Description

Effective Date fields Items dated up to and including this date andtime are available for use by the schedule

For example, with a Standard Bill Runschedule type, charges dated up to andincluding the Effective Date are available to bedisplayed on an invoice


CB v4.02 Page 51

Rating Event Files

Rating event files is performed using the Rate Files schedule type, eitheras a one-off task or as a schedule.

The Rate Files schedule type, and most of the other rating scheduletypes, are usually run as one-off tasks because rating is not run atregular frequencies.

In either case, the schedule type has parameters that must be completedfor the task to execute correctly. These parameters are outlined in thefollowing table.

Rate Files Parameter Description

ENM Process The ENM process to normalise the events

The process selected should be oneconfigured for the type of file or type ofevent being rated

File Pattern The event files to rate

Wild cards are permitted. For example,train*.evt could be entered to rate all of thefiles starting with train and ending with the.evt extension

ENM File Type The type of file to rate

The Normalised Event File Type chosen inthis field determines how the events areparsed plus any expressions used in theparsing

The type selected should match the type offile being rated

ENM Event Type The Normalised Event Type chosen in thisfield determines how to display theresulting normalised events

The type selected should match the type ofevents being rated


Page 52 CB v4.02

Rate Files Parameter Description

Event Source The source of the file to rate

The operator can put anything in this fieldsuch as their user name or where the eventfile came from. This information isincluded in each normalised eventgenerated by rating to assist withidentification

An example of a completed One-Off Task form with a Rate Filesschedule 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 FileType and Normalised Event Type. They serve two distinct purposes.


CB v4.02 Page 53

A Normalised Event File Type defines how incoming events are parsedusing DIL specifications or decoding expressions. An exampleNormalised Event File Type definition is shown below.

A Normalised Event Type definition specifies the entity validationrequired to properly display the event details of that type. An exampleNormalised Event Type definition is shown below.


Page 54 CB v4.02

Exercise 5 – Performing Rating

Answer the following questions:

1. List the four directories on the server used by rating and describewhat 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 extensionin an error directory

log – contains status information about all CB processes, includingrating

2. What are the two ways of running the Rate Files schedule type?

As a one-off task or as a schedule


CB v4.02 Page 55

Guided Practice 3 – Rate Files

The purpose of this guided practice is to:

• Familiarise yourself with the Rate Files schedule type and itsparameters

• Rate an event file using a one-off task


11. Using WindowsExplorer andinformation providedby your instructor,copy an event filefrom your C: driveinto the appropriatedirectory on theserver

12. In CB, select ServerTasks ð One-offTask

The One-Off Task form displays.

13. Select Rate Files inthe Schedule Typefield

14. Press Tab on thekeyboard

The list of parameters for the schedule type display in the Parameterssection of the form


Page 56 CB v4.02

15. Select ENMxx in theENM Process field

16. Enterbilling_opsxx.evt inthe File Pattern field

17. SelectSavilleExpressNative v4 format inthe ENM File Typefield

18. Select GSM Usagein the ENM EventType field

19. Enter your username in the EventSource field

20. Click The one-off task is saved.

21. When the taskcompletes, view theresults to ensure itcompletedsuccessfully

Leave the form openfor the next guidedpractice

Answer the following question:

1. What is the difference between the ENM File Type and ENM EventType parameters?

The ENM File Type specifies the normalised event file type (how theevents are parsed)

The ENM Event Type specifies the normalised event type (how the eventrecord is displayed)


CB v4.02 Page 57

Rating Results

Display Slide 22 – Rating Results

After rating has completed, you can confirm it ran successfully or not bychecking the:

• Task Status field and Results tab on the Task form of a completedRate 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 providesthe first level of detail as to whether rating ran successfully.

A Task Status of:

• Success indicates the task completed successfully. However, errorsin the processing of the event records may still have occurred

• Failure indicates the Rate Files task was unsuccessful. The reasonsfor failure display on the Results tab. Perhaps one of the ratingprocesses (ENM, ERT or ERO) was not running

The Results tab also lists information such as the database, the effectivedate and the name of the event file rated.


Page 58 CB v4.02

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 inputdirectory to the archive directory.

Corrupted error events are written to a file in the error directory. The filehas 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 inthe 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 tothe UNIX file structure through Windows


CB v4.02 Page 59

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) errno = 0, pid = 13105, login = gnoble

<02776> Thu Aug 2 15:14:32 2001 <M> ecp: ENM 2 completed processing file"train02082001.evt" errno = 0, pid = 12815, login = gnoble

Normalised Events

Successfully normalised and rated events are written to theNORMALISED_EVENT table in the database. The Normalised Fileform displays the entries in this table for an event file.

The form lists the number of events input, output and not rated (errorevents). Details about the individual events can also be displayed.

Examples of the Statistics and Events tabs on the Normalised File formare shown below.


Page 60 CB v4.02

Error Events

Normalisation and rater error events are written to the NORMALISED_EVENT_ERROR table in the database. The Normalised Event Errorform displays the individual error events in this table.

An example of the Normalised Event Error form is shown below.


CB v4.02 Page 61

Exercise 6 – Rating Results

The purpose of this exercise to check the success or otherwise of therating task completed in the previous exercise.

The exercise is divided into five parts, one for each of the methodsoutlined 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 andthat 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 anderror 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?


Page 62 CB v4.02

Part C – log.out File

View the log.out file. The information about your rating tasks is at theend. Look for references to the ENM and the name of your event file.


CB v4.02 Page 63

Guided Practice 4 – View the Normalised Events

The purpose of this guided practice is to view the normalised events foryour rating task.


1. Select Server Tasksð Events ð ViewNormalised Filesand Events

The Normalised File Search form displays.

2. Enterbilling_opsxx.evt inthe Search Criteriafield

3. Click A list of event files matching the search criteria display in the bottompart of the form.


Page 64 CB v4.02

4. Select the file fromthe list and click

The Normalised File form displays in Viewing mode.

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


CB v4.02 Page 65

5. Select the Events tabto view the detailsabout the ratedevents

6. Select an event and

click

The Normalised Event form displays in Viewing mode.


1. For your selected event, what is the:

a) Duration: If using the sample event file, they range from 191 to200

b) Event Class: Usage

c) Event Type: GSM National


Page 66 CB v4.02

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 toguide back to the product definition and the tariffs for the product.

7. Close theNormalised Eventform and select theError Events tab onthe Normalised Fileform to view detailsabout the errorevents


CB v4.02 Page 67

8. Select an event and

click

The Normalised Event Error form displays in Viewing mode.

The top part of the form displays event and error details. The bottompart of the form contains the File, Settings, Date, Party and Attributetabs. These tabs display all the details about the event.

This form can also be accessed through the menu by selecting ServerTasks ð Events ð View/Assign Error Events and searching for anevent error record.


1. From the information provided on the File, Settings, Date, Partyand Attributes tabs of this form, what are the causes of the eventerrors in your event file?

If using the sample event file, the first two errors have an incorrect CParty ID, the third has an invalid date (2000 not 2001).


Page 68 CB v4.02

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 tocorrect this are:

1. Check all the required server processes are running

2. Check the causes of failure reported of the Results tab of the Taskform

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 besent back to the host.

Corrupted events in an input file are written to an error file in the ENMerror directory. The file has the same name as the input file, with a .eextension. If the error file already exists, the corrupted events areappended to the end of the file.


CB v4.02 Page 69

The steps to correct corrupted events are:

1. Examine the events in the error file to determine the cause of theerrors

a) Intermittent errors may simply be the result of a datatransmission error

b) Consistent errors may indicate a problem at the source of therecords

c) A total failure may mean you are rating with the wrong ENMFile Type. For example, you may have selected SavilleExpressNative v4 format in the ENM File Type, when the event file isof a different type

2. Depending on the service provider’s business rules, correct thecorrupted events in the file

a) For a relatively small number of events, correct them manuallyor by a script

b) For larger numbers, you may need to refer the problem back tothe source of the events

3. Rename the file with the corrected events and move it to the inputdirectory

4. Rate the file

Error Events

Error events are written to the NORMALISED_EVENT_ERROR tablein 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. Moreinformation about this and other schedule types you can use inrating, is found in the Rating Schedule Types section on page 72

2. Examine the event to determine if the error is caused by the eventitself, 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 fileand re-rate it

b) If it is a configuration problem, like an incorrect tariff, correctthe configuration and re-rate the event or events


Page 70 CB v4.02

Incorrect Charges

While rating may be successful and generate normalised events andcharges, 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 eventfile is moved from the archive directory to the input directory

Use the Revoke File and move back schedule type to do this. Moreinformation about this and other schedule types that you can use inrating 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


CB v4.02 Page 71

The entire process of correcting rating errors is summarised in thefollowing diagram.

Rating

Check the causeof failure and

correct

Rating tasksuccessful?

Corruptedevents?

Error events?

Are chargescorrect?

Error eventsrequired?

No

Correct events,rename error fileand move to theinput directory

Yes

Yes

No

Yes

No

Yes

Purge error events

No

Specify criteria toselect error events

for re-rating

Roll back rating

Correct theproblem

No

Assign errorevents to are-rating file

Yes

Event File

Start

Finish

Summarise the process of correcting rating errors and ask participantsif they have any questions.


Page 72 CB v4.02

Rating Schedule Types

To correct rating errors, there are rating schedule types for such thingsas deleting unwanted error events, re-rating error events and rolling backan entire rating process.

All of the rating schedules types, plus a brief description of each, arelisted in the following table.

Rating ScheduleType

Description

Purge Error Events Selectively delete error events from thedatabase

Purge Events (nonError)

Selectively delete normalised events andassociated charges from the database

Purge Files Delete files from a specific directory on theserver

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(bulk)

Selectively re-rate error events withoutassigning them to a re-rating file

Re-rate Events(bulk)

Selectively re-rate previously rated events.Previous charges are discarded and recalculated

Re-rate File Re-rate a specific event file. Previous chargesare discarded and recalculated. Error events inthe file are also re-rated

Revoke Event File Deletes all normalised events, error events andcharges from the database

Revoke File andmove back

Deletes all normalised events, error events andcharges from the database and moves the eventfile from the archive directory back to the inputdirectory

Revoke ReprocessedFile

After completion of a Revoke Event File orRevoke File and move back schedule type, thisrecreates the original re-rating file


CB v4.02 Page 73

Exercise 7 – Correcting Corrupted Events

Following on from the previous guided practice, the corrupted eventsand error events need to be corrected.

In this exercise, you will correct the corrupted events and in thefollowing guided practice you will use two different methods to correctthe error events.

While this is an exercise to correct corrupted events, it is worth notingthat service providers may not actually fix corrupted event. Dependingon 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 theerror 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 ifyou have Windows access to the server

4. Rate the file

5. Ensure the file rates successfully, using the list provided in theRating Results section on page 57


Page 74 CB v4.02

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 theNormalised Fileform forbilling_opxx.evt


CB v4.02 Page 75

2. Display the details ofthe first error event

3. Click The Normalised Event Error form displays in Updating mode.

Note the button is now active.

4. Correct the field orfields causing theerror

Note the Categoryfield on theAttributes tab ismandatory

5. Select the File tabagain

6. Click

The New Rerated File form displays.

This form allows you to create a file to which you can assign yourcorrected events.


Page 76 CB v4.02

7. Entertrainxx_correct.evtin the File Namefield

8. Enter your username in the EventSource field

9. Click The New Rerated File form closes.

10. Click The Normalised Event Error form redisplays in Viewing mode.

11. Close theNormalised EventError form

The Normalised File form redisplays.

12. Display and updatethe next event error

13. Select the File tab

14. Click

The Assign/View Existing Rerated File form displays.


CB v4.02 Page 77

15. Click The name of the file you created for the first error event displays in thebottom part of the form.

16. Select the rerated fileyou created for thefirst error event and

click

The Normalised Event Error form redisplays in Updating mode.


Page 78 CB v4.02

17. Click The Normalised Event Error form redisplays in Viewing mode.

Note the File Name and Record Number fields in the Rerated Filesection on the File tab of the form.

18. Run a one-off taskusing the Re-rateError Eventsschedule type


1. Based on the information displayed on the Results tab when the taskcompletes, 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 ratesuccessfully, work through the process again to fix the events and re-rate them again.


CB v4.02 Page 79

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 asingle error event, this feature is typically used to re-rate hundreds ofevents at a time.


1. Display the details ofthe third error event

2. Click The Normalised Event Error form displays in Updating mode.

3. Correct the field orfields causing theerror

4. Click

The Normalised Event Error form displays in Viewing mode.


Page 80 CB v4.02

5. Create a one-off taskof schedule type Re-rate Error Events(bulk)

The optional parameters for this schedule type allow you to specifywhich error events to re-rate. All of these parameters are outlined in thefollowing table.

Parameter Description

File Process Start DateandFile Process End Date

The dates between which the events wereoriginally rated

Base Event File Name The original event file

Event Start DateandEvent End Date

The dates between which the eventsoccurred

Error Message Id The error code attached to the error events


CB v4.02 Page 81

Parameter Description

Event Source The information entered in the EventSource field of the original Rate Files task

Event Type The normalised event type of the errorevents

File Type The normalised event file type of theoriginal event file

File Record Start NrandFile Record End Nr

The range of events within the originalevent file

C Party Id C Party ID of the error events

Event Where Clause An SQL where clause on theNORMALISED_EVENT_ERROR table

For example, WHEREEVENT_TYPE_CODE = 01

File Where Clause An SQL where clause on theNORMALISED_EVENT_FILE table

For example, WHEREEVENT_TYPE_CODE = 01


1. Which parameter or parameters could you use to re-rate your errorevents for this exercise? Why?

The best parameters to use in this case would be the Base Event FileName and the File Record Start/Stop Nr fields, as this would allow youto select the single error event in the original file.

In a real situation, you would complete whatever parameters necessaryto re-rate the appropriate error events.


Page 82 CB v4.02

6. Run a one-off taskusing the Re-rateError Events (bulk)schedule type to re-rate the error events

When the task completes, view the information displayed on the Resultstab. Write down the name of the event file created for this task.


CB v4.02 Page 83

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 thecharges generated are incorrect. In this case, the entire rating processneeds to be revoked, the tariff generating the charges updated and theevent file rated again.

There are three rating schedule types used for revoking rating, outlinedin the following table.

Rating ScheduleType

Description

Revoke Event File Deletes all normalised events, error events andcharges from the database

Revoke File andmove back

Deletes all normalised events, error events andcharges from the database and moves the eventfile from the archive directory back to the inputdirectory

Revoke ReprocessedFile

After completion of a Revoke Event File orRevoke File and move back schedule type, thisrecreates the original re-rating file

Which Schedule Type for Revoking?

Generally, to revoke rating for a standard event file, use the Revoke Fileand move back schedule type. In addition to rolling back rating, itmoves the event file from the archive directory back to the inputdirectory, ready for rating again.


Page 84 CB v4.02

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 backschedule type to revoke the rating of the reprocessed file

2. Use the Revoke Reprocessed File schedule type to recreate theoriginal reprocessed file

Exercise 8 – Revoking Rating

Part A

Revoke rating for the reprocessed file, the name of which you wrotedown 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 anyquestions before you move on to the Billing section.

Billing OperationsParticipant Handbook – Billing

CB v4.02 Page 85

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 customerinvoices.

• Generating the invoices images

• Applying the invoices to customer’s accounts. This commits allrelated 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


Page 86 CB v4.02

Billing Terminology

Display Slide 25 – Billing Terminology

Before discussing billing in detail, the following concepts requirefurther 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 abatch of customer nodes by performing a bill run. The ability to processmultiple customer nodes allows a faster billing process and also givescontrol over the quality of the process.

For example, you are able to view initial invoices before the majority ofcustomer nodes have been processed. If errors are detected, the bill runcan 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 billingprocesses required to produce invoices, apply them to customeraccounts and print them if required. Bill runs are created as schedulesallowing the specification of:

• When and how often they run

• What parameters are used


CB v4.02 Page 87

Invoice Cycles

Invoice cycles, on the other hand, are customer concepts and determinethe frequency at which invoices are produced, such as monthly orquarterly. An invoice cycle determines how often a bill run isperformed. A customer must be assigned to an invoice cycle todetermine when they are billed.

The name of the schedule set up for a bill run is the name of the invoicecycle that can be assigned to a customer.

When a bill run is executed, all of the processes specified in theschedule are performed.

Statistical information is recorded for each bill run indicating success orfailure for each process as well as the duration. This enables the trackingof the status of the bill run during processing.

A bill run must be configured with a bill run type. This determines theset of schedule types that can be executed on a particular bill run.

Reporting Levels

For billing purposes, each customer is assigned one of the followingreporting levels:

• Invoice

• Statement

• None

The reporting level for a customer is shown on the Invoicing tab of theCustomer form.

When a bill run occurs, customers in the invoice cycle with a reportinglevel of Invoice receive an invoice of their charges for the billing period,plus the charges of their child customers with a reporting level ofStatement or None.

Child customers with a reporting level of Statement receive a statementof only their charges for the billing period.

Child customers with a reporting level of None, receive nothing.


Page 88 CB v4.02

Note that root customers are automatically assigned a reporting level ofInvoice and this can not be updated.

Display Slide 26 – Reporting Levels

The following diagram shows an example customer hierarchy.

ABCBanking

CentralBranch

WestBranch

EastBrach

Loans Investments

The table below lists the reporting level details for these customers.

Customer Customer Type ParentCustomer

ReportingLevel

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 owncharges, and those for West Branch and East Branch

• Central Branch receives an invoice for its own charges, and thosefor Loans and Investments

• West Branch, East Branch, and Investments each receive astatement of their own charges


CB v4.02 Page 89

• 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 Suppressionsection where an operator can specify to suppress billing until a specificdate.

An example of a completed Billing tab on the Customer form is shownbelow.

If the Suppress Bill runs for Customer? check box is ticked, a date in theBill cycles suppressed until field must be entered.

The operator can either enter a number in the Suppress customer billingfor bill cycles field (the system then calculates and enters the date) orenter a date directly.

The maximum number of bill runs that may be suppressed is defined inthe customer type definition.


Page 90 CB v4.02

The customer’s bill cycle may not be suppressed for more than thenumber of pending tasks (as specified in the Prescheduled Count field ofthe schedule).

There are no limitations to the date to which bill cycles can besuppressed. Even a date after the start date of the last pending task ofthe invoice cycle schedule is acceptable. However, if a maximumsuppression period is defined in the customer node type, the suppressuntil date may not exceed this period.

This period is calculated from the issue date of the last invoicegenerated for this customer, or from the root customer node if invoiceshave not yet been generated. Checking is done on the server when thedetails are saved.


CB v4.02 Page 91

Billing Architecture

The billing architecture is outlined in the following diagram:

Display Slide 27 –Billing Architecture

RGP(trergp)Rental

GenerationProcess

GOP

GeneralOutput

Process

IGP(treigp)Invoice

GenerationProcess

BGP(trebgp)

BillGeneration

Process

Rater

Database

Product/Facility detailsRecurring tariffs

Rentalevents

Adjustmentevents

Customerproductdetails

Charges

Billing data

TemplatesBilling data

Invoice images

Printeror file

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 therating processes, they are started automatically with the start-up of thesystem. The GOP, used to print the final invoices (or output them tofile), is an independent UNIX process, run as required.


Page 92 CB v4.02

Rental Generation Process (RGP)

Display Slide 28 – Rental Generation Process (RGP)

The RGP generates rental events and rental adjustment events beforeinvoice processing occurs. The term rental refers to any recurringcharge, such as a service subscription, a maintenance charge, or anequipment rental. In many cases, recurring charges are paid in advance.The RGP also generates events for one-off charges such as activation orcancellation fees.

The RGP operates in two modes:

1. Rental generation mode

2. Rental adjustment mode

In rental generation mode, it generates normalised events for recurringand one-off charges, as specified in the tariff definition.

In rental adjustment mode, it generates normalised events to correct oradjust previously billed recurring charges. For example, if a service iscancelled, an adjustment may be required to refund a portion of arecurring charge already paid in advance.

Rental events and rental adjustment events are then sent to rating andprocessed in exactly the same way as other events (that is, through theENM, 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 eachrecurring 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


CB v4.02 Page 93

3. Determine the active periods within the rental period. For example,a service may have been suspended and then reactivated during thesame rental period

4. Generate rental events for each active period

5. Write the events to the input directory and instruct a specific ENMprocess to rate them

Events for one-off charges are also generated by the RGP, but onlyonce.

Display Slide 29 – Rental Period Calculations

The following diagram illustrates how the start and end dates of therental period are calculated.

Recurring Charge Period (1 month) Advance Charge Period (1 month)

EffectiveDate

Jan 15 Feb 14 Mar 14

Start of nextInvoice Cycle

Date of thebill run

Pro-Rating

Pro-rating is an option for when the start date of the entity you arebilling 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 theirinvoice cycle. Pro-rating adds units of time (usually days) to bring it intoline with the invoice cycle date.

Advance the animation to display the pro-rating portion of the slide

This is illustrated in the following diagram.


Page 94 CB v4.02

Feb 14

Recurring Charge Period (1 month) Advance Charge Period (1 month)

EffectiveDate

Jan 15 Mar 14

Start of nextInvoice Cycle

Date of thebill run

Productstart date

Pro-rating period

Rental Adjustment Processing

As stated previously, rental adjustment generates normalised events tocorrect or adjust previously billed recurring charges.

The process to generate rental adjustment events in the RGP is asfollows:

1. In the same way as rental processing, determine the active periodswithin the adjustment period. The adjustment period is aconfigurable number of days (90 is the default value) prior to theeffective date of the invoice cycle

2. Compare these active periods with those determined for theprevious rental period

3. Based on differences found between the active periods, generaterental adjustment events

4. Write the events to the input directory and instruct a specific ENMprocess 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 notexist at the time of a previous bill run).

It then evaluates any subtotals and billing tariffs. These tariffs aretypically discount tariffs applied against a range of charges. Forexample, 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 adiscount.


CB v4.02 Page 95

The BGP then creates invoice data from the applicable charges for eachcustomer, 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 ofNormalised 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 foreach customer hierarchy in the invoice cycle

3. Evaluate the subtotals as required by the reporting level defined forthe 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 supportsparallel tariffing, but there are two main differences:

• The BGP applies tariffs to aggregated records, rather than individualones. Aggregation means that the individual charges are aggregatedinto one or more pre-defined groups so that a total value for thegroup can be obtained

• The tariffs applied to the aggregated records are usually discounttariffs 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 withthe appropriate invoice template to create an invoice image for eachcustomer, which is saved to the database.

CB currently uses templates in ASCII text, however any suitable textbased page description language can be used.

The IGP also generates dunning letters for customers who have overduepayments.

The process to generate invoice data in the IGP is as follows:


Page 96 CB v4.02

1. Retrieve invoice and dunning letter templates from the database

2. Insert the invoice and dunning letter data into the appropriatesections 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 possibleto view them online. Viewing a cross section of images online allowsyou to check that images have been produced correctly prior to applyingthe invoices to customer accounts.

Depending on the format of the image stored on the database, third partyapplications such as Adobe Acrobat or a web browser may be used toview it.

Invoice Templates

Invoice templates play a significant part in billing; not only do theycontrol 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, referto the training module PC05 Invoice Design Tool and thedocumentation manual Invoice Design Tool.

Applying and Allocating Invoices

Although not part of the billing architecture diagram displayed on page91, one of the final steps in the billing process is to apply the invoices tothe customers’ accounts.

To this point, events have been rated and billed and the invoice imagesproduced, but the charges listed on the invoices are not yet reflected oncustomers’ accounts.

Two options exist: Apply or Apply and Allocate.

Applying invoices posts the charges listed on the invoices to thecustomers’ accounts.

Apply and Allocate applies the invoices plus allocates any unallocatedpayments or adjustments to the invoices.


CB v4.02 Page 97

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, theaccount is in credit by $10, but that amount is not allocated to anyspecific invoice.

In the next invoice cycle, another invoice for $50 is generated.

If the invoice is applied to the customers account, the account balance isnow $40, but $10 is still unallocated. That is, the $10 is not allocated tothe new invoice. It remains unallocated.

If the invoice is applied and allocated, the account balance is $40 andthe $10 previously unallocated is allocated to the new invoice.

Although applying and allocating invoices may be performed as part ofthe overall billing process, many service providers keep it as a separatestep in case there are errors with the invoices. Like rating, you canrevoke or roll back the steps in the billing process, fix any errors andthen 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 areautomatically executed with the start up of the system. The GeneralOutput Process (GOP) is an independent process that runs whenrequired.

The GOP is used to retrieve images stored by previous billing operationsor scheduled tasks (such as invoices, statements or dunning letters) andsend them to an appropriate output device. The GOP retrieves user-defined information stored in the Convergent Billing database todetermine how images should be selected, sorted and output.


Page 98 CB v4.02

Images can be divided into as many batches as necessary and each batchcan be separately ordered and sent to a different output device. Forexample, images may be output directly to printers or onto disk or tapefor 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 recentlycompleted task for that schedule. Only data produced during theexecution of that task is considered for output

• The defined output method is used to identify the database tablesand views used to retrieve the required data, including documentimages. It can also define an update performed on the databasewhen an image has been processed (for example, to flag that adunning letter has been printed)

• The output method is associated with a table of output criteria. Thistable may contain zero or more rows. The criteria received mayinclude:

− The output device defining where the selected document imagesare sent

− An SQL WHERE clause, used to select the retrieved images touse this output device

− An SQL ORDER BY clause, used to specify the order of theoutput

• For each row in the criteria table, the GOP outputs the selected datato the output device using the appropriate selection and sortingcriteria


CB v4.02 Page 99

Configuring Billing Processes

Display Slide 33 – Configuring Billing Processes

Like rating processes, the attributes for individual billing processes canbe altered, plus additional processes configured to meet the processingrequirements of a service provider. For example, configuring multipleBGP processes to process multiple customers simultaneously.

Configuration Items

The billing processes started and maintained by the system aredetermined by Configuration Items set up in the system. Creating newconfiguration items result in new processes. The configuration item for aprocess specifies all of the attributes for that process. Each process hasits own configuration item.


Page 100 CB v4.02

Guided Practice 6 – View a BGP Configuration Item




2. Click The list of configuration items displays in the bottom part of the form.


CB v4.02 Page 101

3. Select and displaythe BGP1configuration item

The attributes on the Base Attributes tab are outlined in the followingtable.


CUSTOMER_CHILD_PROCESSES

The number of customer level childprocesses created by the BGP

The processes are created at systemboot time and remain until the system isshutdown

NODE_CHILD_PROCESSES

The number of customer node levelchild processes created by the BGP

These processes are created as childprocesses to a customer level process atthe beginning of a bill run and terminateat the end of a bill run


Page 102 CB v4.02


SERVICE_CHILD_PROCESSES

The number of service level childprocesses created by the BGP

These processes are created as childprocesses to a customer level process atthe beginning of a bill run and terminateat the end of a bill run

See the following section for moreinformation about customer, customernode and service level processes

NON_GLOBAL_DA_CACHE_SIZE

The cache size for derived attributeswith a customer, customer node orservice storage context

If specified as a positive number, thisindicates the number of derivedattributes that can be stored. If specifiedas number followed by an upper caseM, this indicates the size of the cache inmegabytes

GLOBAL_DA_CACHE_SIZE

The cache size for derived attributeswith a global storage context

If specified as a positive number, thisindicates the number of derivedattributes that can be stored. If specifiedas number followed by an upper caseM, this indicates the size of the cache inmegabytes

DISABLE_HASH_JOIN Disables the use of hash joins in queries


CB v4.02 Page 103


DEBUG_LEVEL The level of tracing to run for the BGP

Levels are specified either as hex valuesor a three letter mnemonic associatedwith the trace level. Multiple levels maybe specified by adding the hex numbersor listing the mnemonics separated bycommas

The tracing levels available are listed inthe Singl.eView Convergent BillingSystem Administration Guide

ERROR_THRESHOLD The maximum number of errorstolerated before a bill run is aborted

USAGE_CHARGES_BEFORE_BILL_DATE

Whether the BGP processes usagecharge up to and including the effectivedate of the bill run

If TRUE, usage charges up to BUTNOT including the bill run effectivedate are included

If FALSE, usage charges up to ANDincluding the bill run effective date areincluded

Recurring charges are not affected bythis attribute. That is, recurring chargesup to AND including the bill runeffective date are included


Page 104 CB v4.02

Billing Streaming

Display Slide 34 – Billing Streaming

To ensure high performance within billing, the appropriate streaming ofthe RGP, BGP and IGP processes must be set up. For example,configuring multiple BGP processes to process multiple customerssimultaneously.

Like the other billing processes, the GOP has multi-processingcapabilities to allow multiple images to be processed simultaneously.

Rental Generation Process (RGP)

For most bill runs, the RGP processing time is minimal. The RGP iscapable of running multiple processes to increase processingperformance. The RGP can be streamed to generate multiple rentalevent 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 configurationitems.

The RGP spawns the number of child processes specified by theconfiguration attribute CHILD_PROCESSES. If this attribute equalszero or is not present then no child processes are spawned, and the RGPwill 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 bespawned. Once again a value of zero (-c 0) means the RGP will run insingle process mode. If the -c option is specified theCHILD_PROCESSES attribute is ignored.


CB v4.02 Page 105

Bill Generation Process (BGP)

The BGP can run as multiple processes or as a single process dependingon the configuration item attributes. The BGP can be streamed based onfour 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 processcustomer nodes.

3. Service level child processes (SERVICE_CHILD_PROCESSES)

Created from the customer level child processes and processservices.

4. Event level child processes (EVENT_CHILD_PROCESSES)

The number of child processes that the BGP will create in order toprocess a single service. This attribute should only be set for billruns that contain high volume services (for example, for callcentres). Event level child processes are created from the customerlevel child processes and process the events for a service.

The attributes of these child processes determine how many childprocesses are created. If any of the attributes are greater than zero, theBGP starts at least one customer level child process and the specifiednumber of customer node, service and event level child processes.


Page 106 CB v4.02

The difference between single processing mode (no child processes) andmulti-processing mode is illustrated in the following diagram.

Display Slide 36 – BGP Child Process Attributes

Customer levelprocess

Customer node,service or eventlevel process 1

Customer node,service or eventlevel process n

trebgp

trebgp

Manages overall bill runoperations

Processes root customers

Processes customer nodes, services or events.Exist only for the duration of the bill run

Multi-processing Mode

Single Processing Mode

All processing done withinthe trebgp

If the multi-process option is enabled, the BGP server first executes aBGP parent process (customer level process) which in turn creates anumber 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 execsystem 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 imageof the parent are inherited by the child.


CB v4.02 Page 107

The exec system call overlays the process that is running with a newprogram and begins execution of the program at its entry point.

As the names suggest, a customer node child process processescustomer nodes and a service child process processes services. Eventchild processes allow the processing of services to be broken up over aspecified number of processes. Event level concurrency is designed toallow the BGP to scale when processing high volume services such asthose associated with call centres. Unless the bill run contains this typeof service there is no value in this level of multi-processing.

Customer node processes are created at the start of a bill run and remainalive for the duration of the run. If multiple customers are beingprocessed then the child process will not terminate until after the lastcustomer is finished being processed.

BGP performance is data dependent. When determining how toconfigure 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 determiningthe optimal number of BGP processes. Generally, service providerswith:

• A wide customer hierarchy (many root customers with multiplecustomer nodes) will benefit from a configuration of multiplecustomer node level processes

• Multiple services per customer will benefit from a configuration ofmultiple service level processes

• Mostly residential customers (no or few child customers and usuallyone service per customer) will benefit from a configuration ofmultiple customer level processes

• Bill runs that contain high volume services such as free callnumbers will benefit from a configuration of multiple event levelprocesses

While it is possible to configure both multiple customer node andmultiple service level child processes in the same configuration, it hasbeen found that this does not improve performance.


Page 108 CB v4.02

The only way to determine the 'best' configuration is by analysis of thecustomer profile for a service provider versus current billingperformance, and then using that information to experiment withdifferent configuration options.

Invoice Generation Process (IGP)

The IGP takes the invoice information generated by the BGP and createsinvoice images using the invoice templates associated with eachcustomer.

The IGP may be configured in either single-process or multi-processmode by specifying the maximum number of child processes.

In single-process mode, the treigp server process is the only process thatis invoked.

In multi-process mode, the treigp server creates and executes up to themaximum number of IGP child processes required, as specified in theMAX_CHILD_PROCESSES configuration item attribute. This attributeis optional and specifies the number of child processes the IGP willspawn.

For example:

• A value of 2 means run with one parent process and two childprocesses

• A value of 1 means run with one parent process and one childprocess

• A value of 0 means run in single process mode.

If the MAX_CHILD_PROCESSES attribute is not present the IGP runsas 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 operationsor scheduled tasks (such as invoices, statements or dunning letters) andsend them to an appropriate output device.

Like the BGP, RGP and the IGP, the GOP has multi-processingcapability.


CB v4.02 Page 109

GOP multi-processing allows multiple images to be processedsimultaneously in parallel. If this option is used, child processes arespawned after the output method type and output method details are readin from the database.

Inter-process communication between the child and parent processes isachieved by creating a pipe for each child process. The parent processsends requests to process an image to each child process via its pipe. Acommon return pipe is used by all child processes to inform the parentprocess when they have completed processing an image. If all childprocesses are busy, then the parent process waits on this common returnpipe for a message from a child process.

Messages sent from a child to the parent always include the process IDof 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 isconfigured to concatenate images. This flag is also ignored if the valueof max_children is less than 2.

Exercise 9 – View Other Billing Configuration Items

Allow a maximum of 10 minutes for this exercise (5 minutes perprocess).

View the other RGP and IGP billing configuration items. Use onlinehelp (Help ð Reference Information ð Index) to search for and displaythe base attribute descriptions for each.


Page 110 CB v4.02

Managing Billing Tasks

The successful management of billing tasks involves a number ofprocedures and processes.

There are a number of tasks that can be performed prior to runningbilling that can help to achieve a successful bill run. While some ofthese tasks may be included in an operational plan, it is important forbilling operators to be aware of these tasks.

A bill run is created as a schedule allowing users to specify when andhow often it runs, as well as the parameters for the bill run. There aretwo schedule types that can be used for a bill run. These are StandardBill 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 ratingprocess that will minimise problems during rating. These tasks couldform part of a checklist that identifies the tasks as well as who hasresponsibility for the task.

As with rating, there are certain tasks that can be undertaken prior toperforming a bill run which can help to minimise billing problems. Thefollowing tasks could form part of a checklist to run through prior to thecommencement of each bill run:

• Check for and resolve DVP errors

This is a critical step to ensure a successful bill run. Any errorsassociated with customer data will have a significant impact onbilling. In some cases, it may cause billing to fail completely. DVPis 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


CB v4.02 Page 111

• Check that all CSR account activities that may affect the accountsbeing billed have been completed, such as checking that all paymentor adjustment batches have been processed, and checking that allnecessary modifications have been made to customer and accountrecords

This task would normally be the responsibility of the billingmanager.

• Ensure that any pre-authorised payments have been run prior to thecommencement of billing


• Check that all necessary business changes that may affect the billingoutput have been made to configuration. These changes couldinclude:

− Rate table updates

− Changes to invoice messages

− Any outstanding patches or code promotions


• Identify any pending tasks that may run during billing that wouldimpact billing functionality or compete for resources

If any tasks are schedules, their start dates can be modified to a datein 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


Page 112 CB v4.02

Other possible risks include running reports that are reporting on thesame time period as the bill cycle. The report may not give accurateresults depending on what stage the billing task is at. Also, dependingon the nature of the report, there may be a clash for system resources aswell as a clash for the same data as the billing process. Either thebilling task or the report may timeout waiting for row locks to beremoved or system resources to free up.

• Perform a full database backup (optional)

For environments that have only a small number of bill cycles permonth, a full backup before each bill run is a good safety measure.For environments that need to run more frequent bill cycles, such asa 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 rightnumber of child processes. This is discussed later in thistraining. If parameters are not included to spawn child processeson large production environments, billing will be slow

− Check that the path specified for the IGP parameters is a validpath that exists on the server. This is for the storage oftemporary invoice image files

Bill Run Schedules

As stated previously, the bill run is the concept that ties all of the billingprocesses together and allows you to specify the process or processesyou want to perform. A bill run is created as a schedule allowing usersto specify when and how often it runs, as well as the parameters for thebill 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. Multiplebill run schedules can be set up for different customers or groups ofcustomers.


CB v4.02 Page 113

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 generation

Invoice andstatementgeneration

Invoice andstatement image

generation

Apply and allocateinvoices

General output

Rental adjustmentgeneration


Page 114 CB v4.02

When creating a bill run schedule, any of these operations may bespecified. When you execute a bill run schedule, the operationsspecified in the schedule are performed from top to bottom. If anyoperation results in an error, it is possible to revoke back to the lastsuccessful operation. If required, the entire bill run may be revoked.

Generally, service providers create and submit bill runs to perform justrental adjustment, rental generation, invoice generation and invoiceimage generation. After ensuring this completes successfully and theinvoices are correct, service providers can then apply and allocate theinvoices 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, asdefined by the parameters in the schedule, for the customers on theinvoice cycle.

The Quality Assurance Bill Run schedule type operates the same as theStandard Bill Run, except that the results are stored separately fromactual results and do not update customers’ account details. As the namesuggests, quality assurance bill runs are very useful for testing purposesor to provide quote information.

Bill Run Parameters

The Parameters tab of a bill run schedule type allows you to specify allof the parameters for the bill run.

Explain to participants that the fields on the Parameters tab for aQuality Assurance Bill Run are the same as the fields that display for aStandard Bill Run. The only difference is that for a Quality AssuranceBill Run, the Schedule field displays to enable the schedule (invoicecycle) on which to perform the Quality Assurance Bill Run to beselected.


CB v4.02 Page 115

The fields on the Parameters tab for a Standard Bill Run schedule typeare outlined in the following table.

Field Description

Bill Run Type The type of bill run to create

With configuration, different options couldchange how the bill run schedule performs.However, with the standard CB pre-configuration, the bill run types listed aresamples only and do not effect the bill run

From Operation The first process to perform in the bill runschedule

To Operation The last process to perform in the bill runschedule

The From and To Operations availablecorrespond to the billing operations,including:

• Rentaladjustment event generation

• Rentalevent generation (RGP)

• Invoice/Statement generation (BGP)

• Invoice/Statement Image generation

• ApplyInvoices

• Apply andAllocate Invoices

• PrintInvoices


Page 116 CB v4.02

Field Description

Customer Batch Size If billing is configured for multi-processing(running multiple copies of the billingprocesses), the maximum number ofcustomers processed by an individual billingprocess

Number of ChildProcesses

If billing is configured for multi-processing,the maximum number of billing processes forthe bill run

Error Threshold The maximum number of errors toleratedbefore the bill run stops

Where Clause An SQL Where clause to specify thecustomers processed in the bill run

Customer Batch Size and Number of Child ProcessesParameters

All schedule types used for bill run operations have two commonparameters that control how the billing operations will be performed forthe bill run. These parameters are:

• Customer Batch Size

• Number of Child Processes

The Customer Batch Size parameter controls the number of customersthat are passed to each bill run operation in turn. Customers areprioritised and grouped into batches of the specified size. The requestedrange of bill run operations (From Operation/To Operation) is thenperformed on each batch in turn.

For example, if the operations to be performed are Rental EventGeneration to Invoice Image Generation, with a total of 1500 customerswith 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)


CB v4.02 Page 117

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 ofparallel processing streams used to process the customers. Each batch ofcustomers is processed on a single stream.

Using the above example, if the Number of Child Processes parameter isset to 3, the first three highest priority batches of 100 customers will beallocated to the three child processes and their billing operations will beperformed concurrently. Each parallel processing stream actsindependently of the others. As soon as one stream completesprocessing a batch, it immediately starts processing the next availablebatch in order of priority.

Specifying a number of child processes creates parallel processingstreams. This can improve server utilisation and billing throughputprovided server processes are appropriately configured.

Parallel processing can also minimise the impact of a certain customerbatch slowing processing due to customer nodes that take a long time toprocess. If multiple parallel processing streams are specified, othercustomer batches can be automatically started and completed while thelong-running customer batch is still processing.


Page 118 CB v4.02

Display Slide 41 – Multi-processing Example

The diagram below displays bill run processing with a batch size of 100and the number of child processes set to 3.

Rental Generation

Invoice Generation

Invoice Image

Rental Generation

Invoice Image

Invoice Generation

Invoice Image

Invoice Generation

Rental Generation

Mul

ti-p

roce

ssin

g

Customer Batch 1(100 customers)

Customer B

atch 2

(100 cu

stomers)

Customer Batch 3

(100 customers)

To customer

An example of the Parameters tab for a Standard Bill Run schedule typeis shown below.


CB v4.02 Page 119

The fields on the Parameters tab for a Standard Bill Run schedule typeand a Quality Assurance Bill Run schedule type are outlined in thefollowing table.

Field Description

Bill Run Type

or

Bill Run Type (QA)

The type of bill run to create

With configuration, different options couldchange how the bill run schedule performs.However, with the standard CB pre-configuration, the bill run types listed aresamples only and do not effect the bill run

Schedule For Quality Assurance Bill Run scheduletypes only, the schedule (invoice cycle) toperform a quality assurance bill run on


Page 120 CB v4.02

Guided Practice 7 – Create a Bill Run Schedule

The purpose of this guided practice is to create a bill run schedule to billyour customer.


1. Select Server Tasksð Schedules

The Schedule Search form displays.

2. Select Standard BillRun in the ScheduleType field

3. Select the Create anew schedule radiobutton

4. Click The Schedule form displays in Inserting mode.


CB v4.02 Page 121

5. Enter xxInvoiceCycle in theSchedule Name field

6. Enter xxInvoiceCycle in theDescription field

7. Enter 1 in thePreschedule Countfield

8. Enter 1 in the RepeatUnits field

9. Select Month Dayin the Repeat Typefield

10. Enter a date aftertoday's date in theFirst Date field

11. Select theParameters tab

12. Select Standard BillRun in the Bill RunType field

13. SelectInvoice/Statementimage generation inthe To Operationfield

14. Click The Submit Schedule form displays.


Page 122 CB v4.02

15. Tick each check boxon the form

The check boxes on the Submit Schedule form are outlined in thefollowing table.

Check Box Description

Regenerate tasks? Whether or not to regenerate any pendingfuture tasks

When updating a schedule, and if selected, allpending future tasks are regenerated with thecharacteristics in this schedule

Be notified onreceipt?

Whether or not to notify the operator when theschedule is received by the server

Be notified oncompletion?

Whether or not to notify the operator when theschedule completes

16. Click The schedule is saved and a message acknowledging update of theschedule displays.

17. Click


1. Entering a date after today's date in the First Date field has whateffect? Why did we do this?

Stops the schedule from running immediately. We did this because wedon't want the schedule to execute before updating our customer withthis invoice cycle.


CB v4.02 Page 123

2. If you only wanted to perform rental and rental adjustmentprocessing, 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 NewInvoice Cycle

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


Page 124 CB v4.02

Guided Practice 8 – Run a Pending Schedule

The schedule created in the previous guided practice is pending forsome date in the future. You wish to run it now to create an invoice foryour customer.


1. Display yourschedule on theSchedule form

2. Click The Schedule form displays in Updating mode.

3. Enter today's dateand time (accordingto your PC clock) inthe First Date field

4. Click The Submit Schedule form displays.

5. Tick each check boxon the form

6. Click The schedule is saved and a message acknowledging update of theschedule displays.


CB v4.02 Page 125

7. Click When the schedule completes, a message displays asking if you wishto view the results.

8. Click The Task form displays with the results of the bill run.


Page 126 CB v4.02

Billing Results

After the bill run schedule has completed, you can confirm it ransuccessfully or not by checking the:

• Task Status field and Results tab on the Task form of a completedbill 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 providesthe first level of detail as to whether the bill run schedule ransuccessfully.

A Task Status of:

• Success indicates the schedule completed successfully, but errors inthe billing of customers may still have occurred

• Failure indicates the schedule was unsuccessful and is accompaniedby 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


CB v4.02 Page 127

An example of the Task form is shown below.

The Details tab of the Task form shows the settings used for the bill runschedule and the Parameters tab shows the parameters used for the billrun schedule.


Page 128 CB v4.02

Bill Run Details Form

More detailed information about a completed bill run schedule isdisplayed on the Bill Run Details form. An example of this form isshown below.

The components on the main part of the form are outlined in thefollowing 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 theParameters tab of the bill run schedule

Status field The last operation performed

Creation Start Datefield

The creation date of the Bill Run

Effective Date field The effective date of the Bill Run


CB v4.02 Page 129

Component Description

Effective Day ofMonth field

Usually the same day of the month as theEffective Date, but in cases where the EffectiveDate falls on the last day of the month, theEffective Day Of Month may be movedforward or backward to maintain consistentrecurring event periods

Quality AssuranceBill Run? field

Whether the Bill Run is a Quality AssuranceBill Run or not

Perform Operationbutton

Displays the Perform Operation form listingfurther billing or revoke operations that may beperformed

Failed Customersbutton

Displays a list of all customers in the bill runwith a status of Failure. Included in the list isthe operation that failed and the error messagereported

Refresh button Refreshes the fields on the Bill Run Detailsform

The Perform Operations Button

All of the possible operations that may be performed for a bill run areaccessed via this button. Whether progressing a bill run, or revokingindividual steps, or revoking an entire bill run, these operations areaccessed from here.

The form also contains five tabs outlining additional information aboutthe bill run. They are: Details, Summary of Operations, Pending Tasks,General and Auditing Information. The information displayed on thesetabs is outlined in the following sections.


Page 130 CB v4.02

Details Tab

This tab is divided into four sections:

1. Customer Billing Details

Displays the number of customers processed by this bill run and thetotal 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, thename 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 theDetails button displays the details of the schedule

4. Creation Task

Displays the task id of the bill run. Clicking on the Details buttondisplays the details of the task


CB v4.02 Page 131

Summary of Operations Tab

This tab displays all of the operations performed by the bill run, plus agreat deal of information about each operation.

Ticking the Combine Billing and Revoke Operations? check box at thebottom of the tab removes all revoke operations from the list. This hasthe 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 theoperation

Total Duration The total time (in seconds) taken by theoperation

Average Duration The average time (in seconds) taken to performthe operation. Not displayed when the CombineBilling and Revoke Operations? check box isticked

Eligible Customers The number of customers initially eligible andaccepted as input to the operation


Page 132 CB v4.02

Field Description

SuccessfulCustomers

The number of customers processedsuccessfully by the operation

Failed Customers The number of customers with a status ofFailure

Skipped Customers The number of customers eligible, but skippedbefore the operation started

SuppressedCustomers

The total number of customers eligible, butwhose results were suppressed followingprocessing 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


CB v4.02 Page 133

Pending Tasks Tab

This tab lists any pending tasks in the system for the bill run. The fieldson 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.


Page 134 CB v4.02

Auditing Information Tab

This tab contains two sections.

The bottom part displays any error information for each of theoperations.

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 thatperformed the operation, if any


CB v4.02 Page 135

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?


Page 136 CB v4.02

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 tocorrect this are:

1. Check all the required server processes are running

2. Check the causes of failure reported on the Results tab of the Taskform

3. Check the Bill Run Details form. On the Auditing Information tab,for each operation performed, you can examine the Error Details forthe Operation field at the bottom of the form

4. Examine the log.out file on the server to see if there were anymessages pertaining to the bill run displayed

Incorrect Billing or Invoice Details

After reconciling the results of a bill run, the invoice details may beincorrect. Incorrect billing or invoice details may be caused by any ofthe following:

• Wrong or incorrect invoice format

• Rating errors

• Billing errors

• Incorrect invoice print


CB v4.02 Page 137

Wrong or Incorrect Invoice Format

If the invoices are not showing correct information or the format isincorrect, 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 invoiceimage again

Rating Errors

If there are errors as a result of rating events, the steps to correct thisare:

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 ordiscount 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, thesteps 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


Page 138 CB v4.02

The entire process of correcting billing errors is summarised in thefollowing diagram.

Start

Finish

Perform Bill Run(Standard or QA)

Bill run(RGP,BGP,IGP)

successful?

Reconcile billingdetails

Yes

View bill rundetails

No

Check and correctschedule

parameters

Perform CompleteBill Run

Billing and invoicedetails correct?

Perform PrintInvoices

No

Yes

Invoice printsuccessful?

Perform RevokeBill Run

Perform ApplyInvoices

Yes

Perform RevokeInvoice Print

SettingsNo

Correct printingproblem

Reason forincorrectdetails?

Correct ratingtariffs

Rating error

Correct billingtariff/subtotal/

customer details

Billing error

Re-rate affectedevents

Correct ratingtariffs

Invoice format

Single Customer Errors

For relatively small numbers of customers with billing errors, it is notnecessary to perform corrective billing operations on all customers inthe invoice cycle.


CB v4.02 Page 139

For customers that failed billing:

1. On the Bill Run Details form, click on the Failed Customers buttonto 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 thesuccessfully billed customers, just the failed customers

For customers that billed successfully, but with incorrect results, revokeand 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


Page 140 CB v4.02

This displays the Bill Runs for Customer form.

The left-hand side of the form displays all of the bill runs performedfor 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


CB v4.02 Page 141

This displays the Perform operation for Customer form with a list ofvalid operations for just this customer.

6. Select and submit the appropriate billing operation for the customer


Page 142 CB v4.02

Guided Practice 9 – Correcting Billing Errors

The purpose of this guided practice is to view an invoice image, andassuming a problem exists with the invoice, revoke the bill run, fix theproblem and perform the bill run again


1. Select Accounts ðInvoices

The Invoice Search form displays.

2. Enter Bill Johnsonxxin the CustomerName field

3. Click

The Invoice form for your customer displays.

If more that one invoice exists for the customer, a list displays allowingyou to select one and then display the details.

4. Select the Images tab


CB v4.02 Page 143

5. Click Adobe Acrobat displays the invoice image.

There is a problem with the Frequent User Discount displaying on theinvoice. It should only apply when the total of the call charges is greaterthan $30.00.

Using the process flow outlined on page 138, determine what theproblem is.

The eligibility expression for tCC_Voice_Discount# causes the discountto 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 runand run it again.

6. Select Server Tasksð Bill Runs

The Bill Run Search form displays.

7. Click The Bill Run List form displays.


Page 144 CB v4.02

8. Select your bill runfrom the list anddisplay the details

9. Click The Perform operation for Bill Run form displays.


CB v4.02 Page 145

10. Select Revoke BillRun

11. Click

The One-Off Task form displays in Inserting mode.

12. Click When the task completes, a message displays asking if you wish toview the results.

13. Click The Task form displays with the details of the task. Ensure the bill runrevoked successfully.

14. Click The Bill Run Details form displays.


Page 146 CB v4.02

15. Click The Perform operation for Bill Run form displays.

16. Select Complete BillRun

17. Click

The One-Off Task form displays in Inserting mode.


CB v4.02 Page 147

18. SelectInvoice/StatementImage generation inthe To Operationfield

19. Click When the task completes, a message displays asking if you wish toview the results.

20. Click The Task form displays with the details of the task. Ensure the bill runcompleted successfully.

View the invoice image again to ensure it is correct. If not, repeat thesteps outlined in the above guided practice.


Page 148 CB v4.02

Applying and Allocating Invoices

After confirmation that all of the invoices are correct, they may beallocated to the customers' accounts.

From the Bill Run form, the Apply Invoices or Apply & AllocateInvoices operations perform this.

As stated previously, Apply Invoices applies the invoices to thecustomers' accounts. Apply & Allocate Invoices also allocates anyunallocated 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 thebalance now?

4. Unapply the invoice and check the account balance again.

5. Finally, reapply and allocate the invoice again.


CB v4.02 Page 149

Collecting Diagnostic Information

Display Slide 43 – Tracing

Some problems during the billing process require that server tracing beturned on in order to provide detailed process information on what theprogram is actually doing. This diagnostic information can be useful forsupport personnel responsible for correcting system problems. It isparticularly useful for BGP failure.

Failures Due to Data Problems

The most common problems with the BGP are due to problems with thedata, not the system itself. The BGP (and other server processes) expectthat certain relationships exist between the data entities. If a certainrelationship does not exist, the BGP may stop processing and exit.

For example, a row in the CHARGE table may reference aNORMALISED_EVENT_ID, but if a row does not exist in theNORMALISED_EVENT table with that NORMALISED_EVENT_ID,the BGP will fail when processing the charge. Such BGP failures areusually indicated by the BGP failing with a corresponding messageappearing in the log file such as “Internal error at line NNN inXXXX.c”.

BGP Tracing

When a data error is the expected cause of a billing failure, BGP tracingshould be turned on using the PHA trace level.


Page 150 CB v4.02

This is done by specifying PHA in the DEBUG_LEVEL attribute of theBGP configuration item, as shown on the example of the ConfigurationItem form below.

PHA tracing provides information about what entity the BGP wasprocessing when it failed. This is the entity that has the data problemsand 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 theBGP Command Line Parameters field of the Invoice Generation task.

PHA level tracing outputs the entity the BGP is processing (forexample, processing Customer Node with ID XXX, processing Eventwith ID XXX, processing Charge with ID XXX).

Data problems causing billing failures can usually be investigated andresolved by GCS teams themselves, without requiring a Singl.eViewSupport ticket to be raised.


CB v4.02 Page 151

GCS teams can analyse the PHA trace files to determine what entity theBGP was processing when it failed (go to the end of the trace file). Oncethe entity has been found, the actual data problem needs to bedetermined. Doing a DVP on the database tables associated with thisentity should highlight what the problem is.

When turning tracing on, do not multi-stream the BGP (if possible) as aseparate trace file is generated by each BGP process and it is easier tosee 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 namebgp<pid>.trc where <pid> is the process ID of the BGP processgenerating the trace file.

Incorrect Processing

Another type of billing problem occurs when the BGP is successful, butdoes not appear to be performing the correct operation. Examples of thisare:

• A tariff is not generating a charge and the configuration and eventdata indicate that it should be

• A subtotal not totalling values correctly

These problems also require trace information to be generated. In thiscase both the PHA and the VAR tracing needs to be enabled. This isdone by specifying PHA,VAR in the DEBUG_LEVEL attribute of theBGP configuration item.

Prior to CB v4.00, this trace is enabled by specifying‘–dPHA,VAR’ in the BGP Command Line Parameters field of theInvoice Generation task.

VAR tracing produces large amounts of trace information. For thisreason it is recommended that a small bill run (that is, one customerwith low numbers of events) be performed. This may require theremoval of a specific customer to a test invoice cycle if the problem isbeing investigated in the production environment. Multi-streaming ofthe BGP should be avoided when performing a test bill run to producetracing information.


Page 152 CB v4.02

The trace files that are generated can be forwarded to the support teamfor examination.

Details of tracing for other CB server processes can be found in theSystem Administration Guide for Singl.eView Convergent Billing.


CB v4.02 Page 153

Process Payments

The payment interface is used to send payments to Singl.eView. Thedifferent payment types are Cash, Bank Cheque, Credit Card, DirectDebit, Debit Card and ECS. All payments are collected and collated atthe payment server and sent to Singl.eView in batches of files. Thepayment server executes payment reversals in Singl.eView by insertingPayment 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 theaccount.

Uploading of payments is performed using the Process Paymentsschedule type, either as a one-off task or as a schedule.

The Process Payments schedule type may need to be run more than oncea day and can be scheduled to run at regular frequencies.


Process PaymentParameter

Description

File Pattern TDA*

An example of a completed One-Off Task form with a Process Paymentschedule type is Task 20521.


Page 154 CB v4.02

Payments are made against account not invoices

Display Slide 44 – Payments made against account

Once the payments have been uploaded successfully into Singl.eViewthey need to be applied to the individual account. The payments areallocated on an oldest invoice first principle and if there are nooutstanding invoices the monies are allocated to the account to besubtracted on the next invoice generation.


CB v4.02 Page 155

Exercise 13 – Process Payment


6. What is the process for Process payments into Singl.eView, Whatare the steps involved?

The Process Payments schedule is run and payments are loaded intoSingl.eView, The payments are then applied to the account

7. What is the principle of account allocation?

Oldest invoice first


Page 156 CB v4.02

Guided Practice 10 – Payments Upload


• Familiarise yourself with the Payments Upload schedule type and itsparameters

Task ID 20521


CB v4.02 Page 157

Payment Allocation Results

Display Slide 45 – Payment Allocation Results

After allocation has completed, you can confirm it ran successfully ornot by checking the:

• Task Status field and Results tab on the Task form of a completedUpload Payments task

• Check payment against customer account

• log.out file


Page 158 CB v4.02

Fraud Management Schedule

The fraud management interface will generate a file, which will bepushed to SecureWave via FTP. The file contains information regardingcustomers, products and services as well as some account information.Each file will represent the difference (Deltas) since the last time theschedule has been run.

The format of the file is ASCII and the name of the datafeed file will useformat ‘FRDMGT_YYYYMMDD_hhmmss.frd’

The file generation is performed using the Fraud Management Extractschedule type, either as a one-off task or as a schedule.

The Fraud Management schedule type may need to be run more thanonce a day and can be scheduled to run at regular frequencies.


Fraud ManagementExtract Parameter

Description

Effective Date All the updates since this effective datewill be picked up

Fraud Management Files

Display Slide 46 – Fraud Mgt

Once the Fraud Management Extract has been run successfully fromSingl.eView the downstream system will need to load the file.


CB v4.02 Page 159

Exercise 14 – Fraud Management


8. What is the process for Fraud Management Extract fromSingl.eView, What are the steps involved?

The Fraud Management Extract schedule is run and ftp to thedownstream system

9. What is the name of the down stream system?

SecureWave


Page 160 CB v4.02

Guided Practice 11 – Fraud Management


• Familiarise yourself with the Fraud Management schedule type andits 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)


CB v4.02 Page 161

Fraud Management Extract Results

Display Slide 47 – Fraud Management Extract Results

After allocation has completed, you can confirm it ran successfully ornot by checking the:

• Task Status field and Results tab on the Task form of a completedFraud Management Extract task

• Check file has been sent to SecureWave

• TASK ID 20523


Page 162 CB v4.02

GL Upload

The General Ledger Upload interface is required to upload summarisedfinancial information to a staging table “SAP_GL_UPLOAD” stored inthe CBS environment. This table is then accessed by the SAP financialssystem 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 stagingtable pushed to the SAP server using FTP. Uploading of GL files isperformed using the GL Upload schedule type, either as a one-off taskor as a schedule.

The GL Upload schedule type will be run once a month and can bescheduled to run at regular frequencies.



CB v4.02 Page 163

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 Uploadschedule 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 theyneed to process the file.GL Upload Parameter When to run

Billed Charges After each bill cycle

Payments Daily

Non-RefundingAdjustments

Refund Adjustments

SAX Commission

UnBilled Charges

Monthly

An An example of a completed One-Off Task form with a GL Upload


Page 164 CB v4.02

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


CB v4.02 Page 165

GL Upload Results

Display Slide 49 – GL Upload Results

After GL Upload has completed, you can confirm it ran successfully ornot by checking the:

• Task Status field and Results tab on the Task form of a completedGL Upload task

TASK ID 20522


Page 166 CB v4.02

Treatment Monitoring

Singl.eView will be configured to run a treatment monitor schedule. Fordifferent customer levels there are different treatment levels. Thetreatment monitor will identify if the customer treatment level increasesof if the customer is eligible to come off treatment.

Treatment Monitoring is performed using the Treatment Monitoringschedule type, either as a one-off task or as a schedule.

The Treatment interface schedule type will be run once a month and canbe scheduled to run at regular frequencies.


Treatment MonitoringParameter

Description

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 paymentshave been made.


CB v4.02 Page 167

Treatment Monitoring Results

Display Slide 51 – Treatment interface Results

After Treatment Interface has completed, you can confirm it ransuccessfully or not by checking the:

• Task Status field and Results tab on the Task form of a completedTreatment Interface task

• Check files have been created

• Task ID 20524


Page 168 CB v4.02

Treatment Interface

Singl.eView will be configured to run a treatment schedule. Fordifferent treatment levels, different actions need to be taken The rangeof actions includes sending dunning letters, sending an SMS message,sending an automatic IVR message or sending a request to provisioningin order to suspend, un-suspend, barr or un-barr a particular service orfeature

Singl.eView will produce 4 different files for the treatment purpose. The4 different files will be executed by 4 different systems. These 4treatment interfaces types identified are SMS, IVR, Letters andProvisioning (Suspension, barring etc) All these files will be pushed toClarify for them to upload.

Treatment files is performed using the Treatment Interface scheduletype, either as a one-off task or as a schedule.



Treatment InterfaceParameter

Description

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 Treatmentinterface schedule type is shown in Task 20525.


CB v4.02 Page 169

Exercise 16 – Treatment Datafeed


13. What are the four files generate?

The treatment Datafeed schedule is run it produces 4 files out ofSingl.eView, The formats are Code DDMMYYYY.trteg.LETTERDDMMYYY.trt

14. What is config item to FTP the files?

RIC_TREAT_IVR_FTP


Page 170 CB v4.02

Treatment Interface Results

Display Slide 52 – Treatment interface Results

After Treatment Datafeed has completed, you can confirm it ransuccessfully or not by checking the:

• Task Status field and Results tab on the Task form of a completedTreatment Interface task

• Task ID 20525


CB v4.02 Page 171

Product Catalogue Output

Singl.eView will provide a script that will publish 5 files in XML formatcontaining data pertaining to Bundles, reference data, bill cycles,treatment and products with rate plans. The XML file are madeavailable for both Clarify (CRM) and Clarity (Provisioning) systems.

The bundle file will include information pertaining to the available rateplans and which value added service is available with them

Reference data will refer to the subset of reference types in Singl.eViewof interest to Clarify and or Clarity.

The Bill Cycle file will contain the details of all active bill cycles inSingl.eView.

The treatment file will provide to the other systems the information toenable them to respond when Singl.eView places an account intotreatment and to maintain the records as such.

Treatment files is performed using the Treatment Interface scheduletype, either as a one-off task or as a schedule.



Product CatalogueDatafeed Parameter

Description

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


Page 172 CB v4.02

Product CatalogueDatafeed Parameter

Description

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 PlanData

Yes / No

An example of a completed One-Off Task form with Treatmentinterface schedule type is shown in Task 20525.

.


CB v4.02 Page 173

Quesions before you move on to the Conclusion.

Billing OperationsParticipant Handbook – Conclusion

Page 174 CB v4.02

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

Billing OperationsParticipant Handbook – Your Notes

CB v4.02 Page 175

Your Notes

bill ops workbook for reliancev1

Documents