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
Billing OperationsParticipant Handbook – Table of Contents
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
Billing OperationsParticipant Handbook – Table of Contents
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
Billing OperationsParticipant Handbook – Module Outline
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
Billing OperationsParticipant Handbook – Module Outline
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
Billing OperationsParticipant Handbook – Module Outline
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
Billing OperationsParticipant Handbook –
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
Billing OperationsParticipant Handbook –
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
Billing OperationsParticipant Handbook –
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 Provide an overview of the rating and billing process
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.
Billing OperationsParticipant Handbook – Rating and Billing Overview
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
Billing OperationsParticipant Handbook – Rating and Billing Overview
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
Billing OperationsParticipant Handbook – Rating and Billing Overview
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.
Billing OperationsParticipant Handbook – Rating and Billing Overview
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.
Billing OperationsParticipant Handbook – Rating and Billing Overview
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.
Billing OperationsParticipant Handbook – Rating
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
Billing OperationsParticipant Handbook – 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.
Billing OperationsParticipant Handbook – Rating
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
Billing OperationsParticipant Handbook – Rating
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
Billing OperationsParticipant Handbook – Rating
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.
Billing OperationsParticipant Handbook – Rating
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
Billing OperationsParticipant Handbook – Rating
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
Billing OperationsParticipant Handbook – Rating
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.
Billing OperationsParticipant Handbook – Rating
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?
Billing OperationsParticipant Handbook – Rating
Page 26 CB v4.02
Ask participants if they have any questions about the rating architecturebefore you proceed to the next section.
Billing OperationsParticipant Handbook – Rating
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.
Billing OperationsParticipant Handbook – 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.
Billing OperationsParticipant Handbook – Rating
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.
Billing OperationsParticipant Handbook – Rating
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.
Billing OperationsParticipant Handbook – Rating
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.
Billing OperationsParticipant Handbook – Rating
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
Billing OperationsParticipant Handbook – Rating
CB v4.02 Page 33
Attribute Name Description
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
Billing OperationsParticipant Handbook – Rating
Page 34 CB v4.02
Attribute Name Description
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
Billing OperationsParticipant Handbook – Rating
CB v4.02 Page 35
Attribute Name Description
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
Billing OperationsParticipant Handbook – Rating
Page 36 CB v4.02
Attribute Name Description
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.
Attribute Name Description
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
Billing OperationsParticipant Handbook – Rating
CB v4.02 Page 37
Attribute Name Description
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
Billing OperationsParticipant Handbook – Rating
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.
Billing OperationsParticipant Handbook – Rating
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.
Perform the following:
1. Select Maintenanceð Server ðConfigurationItems
The Configuration Item Search form displays.
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
Billing OperationsParticipant Handbook – Rating
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.
Billing OperationsParticipant Handbook – Rating
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.
Billing OperationsParticipant Handbook – 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.
Billing OperationsParticipant Handbook – Rating
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.
Billing OperationsParticipant Handbook – Rating
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.
Billing OperationsParticipant Handbook – Rating
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.
Billing OperationsParticipant Handbook – Rating
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
Billing OperationsParticipant Handbook – Rating
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
Perform the following:
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
Billing OperationsParticipant Handbook – Rating
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
Billing OperationsParticipant Handbook – Rating
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
Billing OperationsParticipant Handbook – Rating
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
Billing OperationsParticipant Handbook – Rating
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
Billing OperationsParticipant Handbook – Rating
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.
Billing OperationsParticipant Handbook – Rating
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.
Billing OperationsParticipant Handbook – Rating
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
Billing OperationsParticipant Handbook – Rating
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
Perform the following:
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
Billing OperationsParticipant Handbook – Rating
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)
Billing OperationsParticipant Handbook – Rating
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.
Billing OperationsParticipant Handbook – Rating
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
Billing OperationsParticipant Handbook – Rating
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.
Billing OperationsParticipant Handbook – Rating
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.
Billing OperationsParticipant Handbook – Rating
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.
Answer the following questions:
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.
Answer the following questions:
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?
Billing OperationsParticipant Handbook – Rating
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.
Billing OperationsParticipant Handbook – Rating
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.
Perform the following:
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.
Billing OperationsParticipant Handbook – Rating
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
Answer the following questions:
1. How many of your events were:
a) Rated? If using the sample event file, six
b) Errors? Three
c) Corrupted? One
Billing OperationsParticipant Handbook – Rating
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.
Answer the following questions:
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
Billing OperationsParticipant Handbook – Rating
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
Billing OperationsParticipant Handbook – Rating
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.
Answer the following question:
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).
Billing OperationsParticipant Handbook – Rating
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.
Billing OperationsParticipant Handbook – Rating
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
Billing OperationsParticipant Handbook – Rating
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
Billing OperationsParticipant Handbook – Rating
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.
Billing OperationsParticipant Handbook – Rating
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
Billing OperationsParticipant Handbook – Rating
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
Billing OperationsParticipant Handbook – Rating
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
Perform the following:
1. Display theNormalised Fileform forbilling_opxx.evt
Billing OperationsParticipant Handbook – Rating
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.
Billing OperationsParticipant Handbook – Rating
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.
Billing OperationsParticipant Handbook – Rating
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.
Billing OperationsParticipant Handbook – Rating
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
Answer the following question:
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.
Billing OperationsParticipant Handbook – Rating
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.
Perform the following:
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.
Billing OperationsParticipant Handbook – Rating
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
Billing OperationsParticipant Handbook – Rating
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
Answer the following question:
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.
Billing OperationsParticipant Handbook – Rating
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.
Billing OperationsParticipant Handbook – Rating
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.
Billing OperationsParticipant Handbook – Rating
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.
Answer the following questions:
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
Billing OperationsParticipant Handbook – Billing
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
Billing OperationsParticipant Handbook – Billing
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.
Billing OperationsParticipant Handbook – Billing
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
Billing OperationsParticipant Handbook – Billing
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.
Billing OperationsParticipant Handbook – Billing
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.
Billing OperationsParticipant Handbook – Billing
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.
Billing OperationsParticipant Handbook – Billing
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
Billing OperationsParticipant Handbook – Billing
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.
Billing OperationsParticipant Handbook – Billing
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.
Billing OperationsParticipant Handbook – Billing
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:
Billing OperationsParticipant Handbook – Billing
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.
Billing OperationsParticipant Handbook – Billing
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.
Billing OperationsParticipant Handbook – Billing
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
Billing OperationsParticipant Handbook – Billing
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.
Billing OperationsParticipant Handbook – Billing
Page 100 CB v4.02
Guided Practice 6 – View a BGP Configuration Item
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.
Billing OperationsParticipant Handbook – Billing
CB v4.02 Page 101
3. Select and displaythe BGP1configuration item
The attributes on the Base Attributes tab are outlined in the followingtable.
Attribute Name Description
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
Billing OperationsParticipant Handbook – Billing
Page 102 CB v4.02
Attribute Name Description
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
Billing OperationsParticipant Handbook – Billing
CB v4.02 Page 103
Attribute Name Description
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
Billing OperationsParticipant Handbook – Billing
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.
Billing OperationsParticipant Handbook – Billing
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.
Billing OperationsParticipant Handbook – Billing
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.
Billing OperationsParticipant Handbook – Billing
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.
Billing OperationsParticipant Handbook – Billing
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.
Billing OperationsParticipant Handbook – Billing
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.
Billing OperationsParticipant Handbook – Billing
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
Billing OperationsParticipant Handbook – Billing
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
This task would normally be the responsibility of the billingmanager.
• 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
This task would normally be the responsibility of the billingmanager.
• 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
Billing OperationsParticipant Handbook – Billing
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.
Billing OperationsParticipant Handbook – Billing
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
Billing OperationsParticipant Handbook – Billing
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.
Billing OperationsParticipant Handbook – Billing
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
Billing OperationsParticipant Handbook – Billing
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)
Billing OperationsParticipant Handbook – Billing
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.
Billing OperationsParticipant Handbook – Billing
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.
Billing OperationsParticipant Handbook – Billing
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
Billing OperationsParticipant Handbook – Billing
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.
Perform the following:
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.
Billing OperationsParticipant Handbook – Billing
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.
Billing OperationsParticipant Handbook – Billing
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
Answer the following questions:
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.
Billing OperationsParticipant Handbook – Billing
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.
Billing OperationsParticipant Handbook – Billing
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.
Perform the following:
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.
Billing OperationsParticipant Handbook – Billing
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.
Billing OperationsParticipant Handbook – Billing
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
Billing OperationsParticipant Handbook – Billing
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.
Billing OperationsParticipant Handbook – Billing
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
Billing OperationsParticipant Handbook – Billing
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.
Billing OperationsParticipant Handbook – Billing
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
Billing OperationsParticipant Handbook – Billing
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
Billing OperationsParticipant Handbook – Billing
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
Billing OperationsParticipant Handbook – Billing
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.
Billing OperationsParticipant Handbook – Billing
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
Billing OperationsParticipant Handbook – Billing
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?
Billing OperationsParticipant Handbook – Billing
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
Billing OperationsParticipant Handbook – Billing
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
Billing OperationsParticipant Handbook – Billing
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.
Billing OperationsParticipant Handbook – Billing
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
Billing OperationsParticipant Handbook – Billing
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
Billing OperationsParticipant Handbook – Billing
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
Billing OperationsParticipant Handbook – Billing
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
Perform the following:
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
Billing OperationsParticipant Handbook – Billing
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.
Billing OperationsParticipant Handbook – Billing
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.
Billing OperationsParticipant Handbook – Billing
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.
Billing OperationsParticipant Handbook – Billing
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.
Billing OperationsParticipant Handbook – Billing
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.
Billing OperationsParticipant Handbook – Billing
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
Perform the following:
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.
Billing OperationsParticipant Handbook – Billing
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.
Billing OperationsParticipant Handbook – Billing
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.
Billing OperationsParticipant Handbook – Billing
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.
Billing OperationsParticipant Handbook – Billing
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.
Billing OperationsParticipant Handbook – 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.
In either case, the schedule type has parameters that must be completedfor the task to execute correctly. These parameters are outlined in thefollowing table.
Process PaymentParameter
Description
File Pattern TDA*
An example of a completed One-Off Task form with a Process Paymentschedule type is Task 20521.
Billing OperationsParticipant Handbook – Billing
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.
Billing OperationsParticipant Handbook – Billing
CB v4.02 Page 155
Exercise 13 – Process Payment
Answer the following questions:
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
Billing OperationsParticipant Handbook – Billing
Page 156 CB v4.02
Guided Practice 10 – Payments Upload
The purpose of this guided practice is to:
• Familiarise yourself with the Payments Upload schedule type and itsparameters
Task ID 20521
Billing OperationsParticipant Handbook – Billing
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
Billing OperationsParticipant Handbook – Billing
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.
In either case, the schedule type has parameters that must be completedfor the task to execute correctly. These parameters are outlined in thefollowing table.
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.
Billing OperationsParticipant Handbook – Billing
CB v4.02 Page 159
Exercise 14 – Fraud Management
Answer the following questions:
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
Billing OperationsParticipant Handbook – Billing
Page 160 CB v4.02
Guided Practice 11 – Fraud Management
The purpose of this guided practice is to:
• Familiarise yourself with the Fraud Management schedule type andits parameters
See Task ID 20523
Answer the following question:
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)
Billing OperationsParticipant Handbook – Billing
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
Billing OperationsParticipant Handbook – Billing
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.
In either case, the schedule type has parameters that must be completedfor the task to execute correctly. These parameters are outlined in thefollowing table.
Billing OperationsParticipant Handbook – Billing
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
Billing OperationsParticipant Handbook – Billing
Page 164 CB v4.02
Exercise 15 – GL Upload
Answer the following questions:
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
Billing OperationsParticipant Handbook – Billing
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
Billing OperationsParticipant Handbook – Billing
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.
In either case, the schedule type has parameters that must be completedfor the task to execute correctly. These parameters are outlined in thefollowing table.
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.
Billing OperationsParticipant Handbook – Billing
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
Billing OperationsParticipant Handbook – Billing
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.
The Treatment interface schedule type will be run once a month and canbe scheduled to run at regular 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.
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.
Billing OperationsParticipant Handbook – Billing
CB v4.02 Page 169
Exercise 16 – Treatment Datafeed
Answer the following questions:
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
Billing OperationsParticipant Handbook – Billing
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
Billing OperationsParticipant Handbook – Billing
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.
The Treatment interface schedule type will be run once a month and canbe scheduled to run at regular 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.
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
Billing OperationsParticipant Handbook – Billing
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.
.
Billing OperationsParticipant Handbook – Billing
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 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 – Your Notes
CB v4.02 Page 175
Your Notes