500 System Operations Guide

System
Operations
Guide
for
Singl.eView Convergent Billing V5.00

Printing History
First Printing, June 2002
Document Number
VA500-55-1015-BR3, V5.00
Disclaimer
Although every effort has been made to ensure the accuracy of the information contained in this
document, ADC Software Systems Ireland Limited makes no warranty, expressed or implied, with
respect to the quality, correctness, reliability, currency, accuracy, or freedom from error of this
document or the products it describes. ADC Software Systems Ireland Limited may make
improvements and/or changes to the products and services described in this document at any time.
ADC Software Systems Ireland Limited disclaims all liability for any direct, indirect, incidental,
consequential, special, or exemplary damages resulting from the use of the information in this
document or from the use of any products described in this document. Mention of any other product
not owned by ADC does not constitute an endorsement of that product by ADC Software Systems
Ireland Limited. Data used in examples and sample data files are intended to be fictional and any
resemblance to real persons or companies is entirely coincidental.
Persons reading this document should rely on their own enquiries in making any decisions touching
on their own interests.
Licence Agreement
The software described in this guide is supplied under a licence agreement and may only be used in
accordance with the terms of that agreement.
Copyright Information
© 2000 ADC Software Systems Ireland Limited. All rights reserved. Apart from any use permitted
under the Copyright Act, no part may be reproduced by any process without the written permission of
ADC Software Systems Ireland Limited, IDA Business Park, Dangan, Galway, Ireland.
The following is a trademark of ADC Software Systems Ireland Limited:
The following are third party trademarks used in this document:

Microsoft is a registered trademark and Windows is a trademark of Microsoft Corporation in the
USA and other countries. FrontPage is a trademark of Microsoft. TEX is a trademark of the
American Mathematical Society. PostScript and Acrobat Reader are trademarks of Adobe Systems
Incorporated. UNIX is a registered trademark of The Open Group. TUXEDO is a registered
trademark of BEA Systems, Inc. Oracle is a registered trademark of Oracle Corporation. AIX is a
registered trademark of International Business Machines Corporation. InstallShield is a registered
trademark of InstallShield Software Corporation. Java is a trademark of Sun Microsystems, Inc.
SQR is a trademark of Brio Technology, Inc.
Table of Contents
Preface....................................................................................................................................... v
Welcome to Singl.eView Convergent Billing ............................................................................ v
Who Should Read this Guide .................................................................................................... vi
Before Beginning....................................................................................................................... vi
How this Guide is Structured ................................................................................................... vii
Other Singl.eView Convergent Billing Documentation...........................................................vii
Conventions Used in this Guide ..............................................................................................viii
Obtaining Help .......................................................................................................................... ix
The Online Help System ............................................................................................... ix
Form Help ...................................................................................................................... x
Context-sensitive help................................................................................................... xi
Hint text........................................................................................................................xii
Help on Confirm window options................................................................................xii
Help on error messages ...............................................................................................xiii
Part 1 – Billing Operations
Chapter 1 – Introduction to Rating and Billing.................................................................1-1

Overview of Rating and Billing...............................................................................................1-1
Events..........................................................................................................................1-3
Balance Management ..............................................................................................................1-5
Event Rating ............................................................................................................................1-6
Event Rating Broker (ERB) process ...........................................................................1-7
Event Normalisation (ENM) process ..........................................................................1-9
Event Rating (ERT) process......................................................................................1-10
Event Rating Output (ERO) process .........................................................................1-11
Rating errors..............................................................................................................1-12
Parallel tariffing ........................................................................................................1-13
Recurring charges......................................................................................................1-13
Billing ....................................................................................................................................1-14
Rental Generation Process (RGP).............................................................................1-15
Bill Generation Process (BGP) .................................................................................1-16
Invoice Generation Process (IGP).............................................................................1-17
trerwdb ......................................................................................................................1-17
trerodb .......................................................................................................................1-18
General Output Process (GOP) .................................................................................1-18
Working with invoices ..............................................................................................1-18
Invoice templates.......................................................................................................1-18
Chapter 2 – Rating................................................................................................................2-1
Managing Rating Files ............................................................................................................2-1
Running a Rating Task ............................................................................................................2-3
Preparation ..................................................................................................................2-3
Running the rating task ...............................................................................................2-3
Checking the results ....................................................................................................2-4
System Operations Guide for Singl.eView Convergent Billing V5.00 i

Table of Contents
Correcting Rating Errors .........................................................................................................2-8

Unsuccessful rating task..............................................................................................2-9
Correcting corrupted events ........................................................................................2-9
Correcting error events................................................................................................2-9
Correcting wrong charges .........................................................................................2-11
Revoking a rated and reprocessed file ......................................................................2-12
Removing unwanted events and charges ..................................................................2-12
Rating Schedule Types ..........................................................................................................2-12
Using selection criteria..............................................................................................2-13
Chapter 3 – Billing ................................................................................................................3-1

The Bill Run Process ...............................................................................................................3-2
Processing billing operations ......................................................................................3-3
Bill run operations.......................................................................................................3-5
Tracking the status of a bill run ..................................................................................3-5
Server process .............................................................................................................3-6
Configuring the customer node...................................................................................3-7
Setting priorities..........................................................................................................3-7
Performing a Bill Run .............................................................................................................3-8
Preparation ..................................................................................................................3-8
Supported task types ...................................................................................................3-8
Setting up a bill run.....................................................................................................3-8
Bill Run Types ............................................................................................................3-9
Bill Run Schedule Parameters...................................................................................3-11
Modifying a bill run ..................................................................................................3-11
Performing an operation on a bill run .......................................................................3-11
Stopping a bill run.....................................................................................................3-12
Revoking a Billing Task............................................................................................3-13
Checking the results ..................................................................................................3-13
Suppressing Invoice Generation ...............................................................................3-14
Correcting Billing Errors.......................................................................................................3-15
Billing Schedule Types..........................................................................................................3-17
Billing of Customer Hierarchies............................................................................................3-20
Chapter 4 – Batch Printing ..................................................................................................4-1

Invoice Output using the Scheduler ........................................................................................4-2
GOP schedule configuration parameters.....................................................................4-2
GOP schedule processing............................................................................................4-3
Invoice Output using a Bill Run ..............................................................................................4-4
Bill run configuration parameters ...............................................................................4-4
Setting up a bill run to print invoices or statements....................................................4-5
Printing invoices on a previously-completed bill run .................................................4-5
Single invoice printing ................................................................................................4-6
Printing Document Images ......................................................................................................4-7
Preparation for printing...............................................................................................4-7
Checking the output ....................................................................................................4-7
ii System Operations Guide for Singl.eView Convergent Billing V5.00

Table of Contents
Configuring Output Processing for the GOP...........................................................................4-8

Output method type.....................................................................................................4-8
Output device ..............................................................................................................4-9
Scripts for output.......................................................................................................4-10
Output device examples ............................................................................................4-11
Output method definition ..........................................................................................4-13
Output method example ............................................................................................4-13
Part 2 – The Transaction Engine
Chapter 5 – The Transaction Engine (TRE) ......................................................................5-1
Part 3 – Task Automation
Chapter 6 – Scheduling Server Tasks .................................................................................6-1

Scheduling Overview ..............................................................................................................6-2
Terms used in scheduling............................................................................................6-3
Working with Schedules..........................................................................................................6-5
Submitting a schedule .................................................................................................6-5
Re-submitting a task....................................................................................................6-5
Changing the frequency of a schedule ........................................................................6-5
Deleting a schedule .....................................................................................................6-6
Chapter 7 – Schedule Types.................................................................................................7-1

Schedule Type Details.............................................................................................................7-7
Apply & Allocate Invoices..........................................................................................7-8
Apply & Allocate Invoices for Customer ...................................................................7-9
Apply Invoices ..........................................................................................................7-10
Apply Invoices for Customer ....................................................................................7-11
Apply Transactions ...................................................................................................7-12
Archive......................................................................................................................7-13
Billing Suppress ........................................................................................................7-14
Billing Unsuppress ....................................................................................................7-16
Complete Bill Run.....................................................................................................7-17
Complete Bill Run for Customer ..............................................................................7-18
Contract Cancel/Notify ............................................................................................7-19
Create Partitions........................................................................................................7-21
DIL Validation ..........................................................................................................7-23
Dunning Letter Generation .......................................................................................7-24
ECP Command ..........................................................................................................7-25
Explain BGP Hierarchy Passes .................................................................................7-26
Full Database Validation...........................................................................................7-27
General Bulk Output By Task...................................................................................7-28
General Bulk Output Process ....................................................................................7-29
Generate Invoice Images ...........................................................................................7-30
Generate Invoice Images for Customer.....................................................................7-31
Invoice Generate Image.............................................................................................7-32
Invoice Print Image ...................................................................................................7-33
Invoice Reprint Generation .......................................................................................7-34
System Operations Guide for Singl.eView Convergent Billing V5.00 iii

Table of Contents
Invoice View Image ..................................................................................................7-35

Partition Maintenance ...............................................................................................7-36
Print Invoices ............................................................................................................7-38
Print Invoices for Customer ......................................................................................7-39
Purge Error Events ....................................................................................................7-40
Purge Events (non Error) ..........................................................................................7-42
Purge Files.................................................................................................................7-43
Quality Assurance Bill Run ......................................................................................7-44
Rate Files...................................................................................................................7-45
Re-analyze tables.......................................................................................................7-46
Re-rate Error Events..................................................................................................7-47
Re-rate Error Events (bulk) .......................................................................................7-48
Re-rate Events (bulk) ................................................................................................7-50
Re-rate File................................................................................................................7-52
Reconfigure Auditing................................................................................................7-53
Report Reference Type (RRRT) ...............................................................................7-54
Reprocess Error Events .............................................................................................7-55
Reprocess Event ........................................................................................................7-57
Revoke Bill Run ........................................................................................................7-59
Revoke Bill Run for Customer..................................................................................7-61
Revoke Event File .....................................................................................................7-62
Revoke File and move back ......................................................................................7-63
Revoke Invoice Images .............................................................................................7-64
Revoke Invoice Images for Customer .......................................................................7-65
Revoke Invoice Print Settings ...................................................................................7-66
Revoke Invoice Print Settings for Customer.............................................................7-67
Revoke Invoices ........................................................................................................7-68
Revoke Invoices (keep Rentals) ................................................................................7-69
Revoke Invoices (keep Rentals) for Customer..........................................................7-70
Revoke Invoices for Customer .................................................................................7-71
Revoke Rental Events ...............................................................................................7-72
Revoke Rental Events for Customer .........................................................................7-73
Revoke Reprocessed File ..........................................................................................7-74
Rotate Partitions........................................................................................................7-75
Standard Bill Run......................................................................................................7-78
Switch Files...............................................................................................................7-79
UnApply & Deallocate Invoices ...............................................................................7-80
UnApply & Deallocate Invoices for Customer .........................................................7-81
UnApply Invoices .....................................................................................................7-82
UnApply Invoices for Customer ...............................................................................7-83
Unarchive ..................................................................................................................7-84
Update Account Unbilled..........................................................................................7-85
Update Charge Categories.........................................................................................7-86
Update Invoice Unbilled ...........................................................................................7-87
Update Lists ..............................................................................................................7-88
Verify Charge Partition.............................................................................................7-89
Verify Charge Partition Range..................................................................................7-90
Index
iv System Operations Guide for Singl.eView Convergent Billing V5.00

Preface
Welcome to Singl.eView Convergent Billing
Singl.eView Convergent Billing has been designed specifically for new

generation customer care and billing environments to increase
competitive advantage by making it easier to design, deliver, and bill the
products and services customers want. It provides modules for billing
mediation, rating, discounting, and bill production.
Singl.eView Convergent Billing is based on industry standard
architecture, relational database technology and interfaces, to ensure
portability across operating platforms.
This guide describes the facilities provided in Singl.eView Convergent
Billing for the control of server processes. The three major topics
covered are:
• Billing operations.
• The Transaction Engine (TRE).
• Scheduling server tasks using the client workstation scheduler.
Note: Throughout this manual the name 'Singl.eView Convergent
Billing' has been abbreviated to 'Convergent Billing' wherever an
abbreviated form contributes to easier reading.
System Operations Guide for Singl.eView Convergent Billing V5.00 v

Preface
Who Should Read this Guide
This guide is specifically aimed at staff responsible for controlling

Convergent Billing server operations for a range of tasks, including:
• Rating and billing.
• Generating invoices and letters.
• Batch printing of invoices, statements, and letters.
This guide does not discuss the preparation and printing of reports, which
can also involve server processes. This is discussed in the Reports Guide.
Before Beginning
This guide assumes that the reader has some experience in using:
• Microsoft Windows
• UNIX
• SQL.
It also assumes a through knowledge of the company's system operation
and billing procedures.
vi System Operations Guide for Singl.eView Convergent Billing V5.00

Preface
How this Guide is Structured
This guide consists of seven chapters, divided into three parts:

Part 1 provides details on billing. This part consists of the following
four chapters:
• Chapter 1, Introduction to Rating and Billing
Overview of rating and billing.
• Chapter 2, Rating
Normalisation and rating of events.
• Chapter 3, Billing
Billing and invoice creation.
• Chapter 4, Batch Printing
Batch printing and other output methods available.
Part 2 provides information on operational aspects of the Convergent
Billing Transaction Engine, used to interface Convergent Billing with
other applications. This part consists of the following chapter:
• Chapter 5, The Transaction Engine (TRE)
Overview of the Transaction Engine.
Part 3 provides information on using the Scheduler to automate server
tasks, and on the types of schedule which can be defined. This part
consists of the following two chapters:
• Chapter 6, Scheduling Server Tasks
Describes the use of the Scheduler, and how tasks are created.
• Chapter 7, Schedule Types
Lists schedule types in the base installation that are available for
users. It also explains how to create new schedule types.
Other Singl.eView Convergent Billing Documentation
This guide is part of a suite of documentation, covering every aspect of

the system. For detailed information on the documents available, refer to
the Overview for Singl.eView Convergent Billing.
System Operations Guide for Singl.eView Convergent Billing V5.00 vii

Preface
Conventions Used in this Guide
The following conventions are used in this guide:
File ➩ Exit Indicates that the File menu should be opened

and the Exit option selected.
Save button Button on the toolbar or on a form.
Customer Detail Name of a specific form.
form
Account Status field Name of a field on a form.
UNIX output In interactive and code examples, this typeface
is used to indicate system output.
UNIX input In interactive examples, this bold typeface is
used to show user input.
Ctrl+F4 In procedures, a key sequence indicates that the
Ctrl key must be held down while another key
is pressed. In this example, the Ctrl key must
be held down while the function key F4 is
pressed.
Use of a mouse in Singl.eView Convergent Billing is identical to that in

other Microsoft Windows applications. The following terminology is
used in this guide to describe the mouse functions:
Select Highlight one or more characters to perform an

operation on those characters.
Click Point to an object, then press and release the
left mouse button.
Double-click Point to an object, then press and release the
left mouse button twice in quick succession.
Drag Point to an object, hold down the left mouse
button, reposition the mouse, and release the
mouse button.
The terms select, click, double-click, and drag refer to the mouse cursor
and the left-hand button on the mouse.
viii System Operations Guide for Singl.eView Convergent Billing V5.00

Preface
Obtaining Help
Online help is currently available in the form of:

• The Online Help System, which provides access to task based
help, reference information, glossary of terms, examples, and
demonstrations.
• Form help associated with each form.
• Context-sensitive help associated with each form, field, and
control.
• Hint text associated with each form, field, and control.
• Help on Confirm window options.
• Help on error messages.
These help facilities are described briefly in the following subsections.
The Online Help The Online Help System has been designed to provide information to suit
System the needs of many types of operators. It consists of the following fully
integrated and linked suite of help components, together with a number of
navigational aids that allow movement between and within help topics:
• Task based (procedural) help that provides step-by-step
instructions on how to perform a specific task, with links to
reference information relevant to the task.
• Reference information to assist operators new to Singl.eView
Convergent Billing in obtaining the knowledge required to use
the system effectively and efficiently.
• Full text search and keyword (index) search facilities to locate
information in the help system.
• Examples and video demonstrations, to show by example how to
perform some of the more common procedures.
• Glossary of terms, which defines each of the terms used in
Singl.eView Convergent Billing.
System Operations Guide for Singl.eView Convergent Billing V5.00 ix

Preface
Options to access the Online Help

System are provided on the
Singl.eView Convergent Billing
Help menu.
For example, to access the
Welcome Screen, select the
Contents option from the Help
menu.
Form Help Forms are used to enter, view, and modify data. A form may contain tabs
and controls such as data entry fields, display only fields, function
buttons, option buttons and check boxes. Several forms can be opened
and displayed on the screen at one time. However, only one form can
have input focus. The form that currently has input focus is referred to as
the active form.
To display help for a specific form:
1. Make the form active.
2. Click the Help button on the toolbar.
Details about the form are displayed in a separate window.
2. Click the Help button

1. Make the form active
x System Operations Guide for Singl.eView Convergent Billing V5.00

Preface
Where a form contains one or more tabs, a link is provided on the Form
Help window to details relevant to that tab. Such information is
displayed in a pop-up window.
For the majority of forms, links are also provided to the task based help in
the Online Help System.
Context- Context-sensitive help is provided for all components (data entry fields,
sensitive help buttons, check box, and option buttons) associated with each form within
Singl.eView Convergent Billing.
To obtain information about a component:
1. Click inside the component (or tab to the component).
2. Press the F1 key.
Information about the component is displayed in a pop-up window.
Sample context-sensitive help for the Query Number field is shown
below.
System Operations Guide for Singl.eView Convergent Billing V5.00 xi

Preface
Hint text Hint text is provided for each form field. Sample hint text for the Family
Name field is shown below.
To display the hint text for a specific field:

1. Ensure that the Options ➩ Show Hints option is selected
(when selected, a tick is displayed to the left of the option). If
not currently selected, select it before proceeding.
2. Position the cursor over that field. Hint text for that field is
displayed either below the field or below and to the right of the
field.
Help on Confirm A Confirm window is displayed whenever confirmation of a particular

window options action is required. For example, when changes have been made to a
record and then an attempt is made to close the window, a Confirm
window is displayed asking whether the changes should be saved.
xii System Operations Guide for Singl.eView Convergent Billing V5.00

Preface
Typically, a Confirm window displays a Help button in addition to a

Yes, No, and Cancel button. Clicking the Help button provides details
of what options are available.
Help on error Whenever an error occurs, an error message is displayed in a separate

messages window. For example, if a mandatory field is omitted and an attempt is
made to save the form, an error message similar to the following is
displayed:
To obtain further details of the error:

1. Click the Help button on the Error window. The Error
Message Help window is displayed.
2. Read the details of options displayed.

3. Selecting the File ➩ Exit option to return to the Error window.
4. Click the OK button on the Error window.
5. Before continuing, an attempt should be made to rectify the
problem causing the error.
System Operations Guide for Singl.eView Convergent Billing V5.00 xiii

Preface
Note: Access to the errors, warnings, and messages displayed by

Singl.eView Convergent Billing are also available through the Online
Help System.
xiv System Operations Guide for Singl.eView Convergent Billing V5.00

Part 1
Billing Operations
This part provides details on billing. This part consists of the following
four chapters:
• Chapter 1, Introduction to Rating and Billing
• Chapter 4, Batch Printing
White text
Chapter 1
Introduction to Rating and Billing
This chapter provides an overview of Convergent Billing rating and

billing processes. Full details are provided in the following chapters:
• Chapter 4, Batch Printing.
Overview of Rating and Billing
The balance management functionality described in this section is

only available as part of the separate Singl.eView Commerce
Engine licence option.
Rating and billing is divided into six operations:
• Balance management, which provides event authorisation, advice
of charge information, and customer credit reservations.
• Event normalisation, in which input data is converted into a
standard format for storage in the Convergent Billing database.
• Event rating, in which the normalised event records are
aggregated and rated (costed) by applying the appropriate tariffs.
• Billing, in which the costed event records are aggregated and any
applicable discounts are applied.
• Invoicing, in which billing data is combined with customer detail
records and incorporated into an invoice or statement.
• Invoice output, in which invoices and statements are printed or
converted for electronic distribution.
These six operations are carried out by four major components:
• TRE servers: the trerate, which provides an interface to the Event
Rating Module (enabling real-time account balancing and credit
reservations), and the trerodb, which passes completed events on
to the rating engine.
• The rating engine, which combines normalisation and rating.
System Operations Guide for Singl.eView Convergent Billing V5.00 1-1

• The billing engine, which generates invoice data, creates the

invoice images ready for printing, and passes information back to
the rating engine for the generation of recurring charges.
• The General Output Process (GOP), which selects and sorts
invoices or statements, then outputs them to printers or other
output devices.
The rating engine and the billing engine are described briefly in later
sections of this chapter, and in detail in the following chapters:
• Chapter 3, Billing.
The GOP is described in Chapter 4, Batch Printing.
Carriers, Switches, Faults,

Remote Hosts
Work Orders, and Rental Events
Call Establishment, Authorisaton,

and Completion
Rated and
Normalised
Events
Real-time
Rating Database
TRE servers, trerodb and trerate Pipeline
Charges, Events,
and Account
Event Rate and Reservations Updates
Store Management
Invoice images
Rater Biller
Normalised Invoice
events data
Normalisation Rating Billing Invoicing
General Output Process (GOP)

Invoice or statement
output
Invoices or Statements
Figure 1–1 Convergent Billing Rating and Billing Overview
1-2 System Operations Guide for Singl.eView Convergent Billing V5.00

Events Any event that results in a charge or benefit being passed on to a

customer can be input to, or generated within, the system. Events can
originate from any source of charge information, including network
elements, other service providers, other mediation systems, customer
contacts (such as one-off rebates), service enquiries, faults, and so on.
All such events can be input provided only that the format of the data is
known, and is consistent for each type of input.
Table 1–1 lists the terms used in Convergent Billing to describe the
different kinds of event.
Table 1–1 Convergent Billing Event Types
Term Definition
Alpha event Event supplied as input to Convergent
Billing for normalisation. Alpha events may
be in these formats:
• Automated Message Accounting
(AMA) records Version 1.0, as
output by the AT&T 5ESS switch.
• Incoming Traffic Accounting Data
(ITAD) records Version 1.0, as
output by the AT&T 5ESS switch.
• Convergent Billing native event
format, consisting of fields in user
definable order, prefixed with a
record length field. V3.03 delimits
each field with the ASCII character
255. V4.00 delimits with an ASCII 0
(null).
• Any format that can be specified in
the subset of ASN.1 supported by
the Convergent Billing Data
Interface Language (DIL)(for more
information, refer to the System
Administration Guide).
Charge Amount billed associated with a specific
event once it has been rated.
Corrupted event Alpha event that the ENM process could
not decode or interpret. Corrupted events
from a file are saved in the ENM error
directory for external reprocessing. If
received from a remote host, corrupted
events are discarded and the sender
informed.

Term Definition
Error event An error event is either a normalisation
error event or a rater error event, as output
by the ERO.
Mediated or pre- Event that has been pre-processed in
normalised event some way before being presented to
Convergent Billing. The event format is
typically implementation specific.
Normalisation Event in which one or more of the
error event normalising expressions could not be
evaluated. Normalisation error events are
not rated.
Normalised event Event that has been converted to a
common format by the Event Normalisation
(ENM) process. Each normalised event is
sent to an Event Rating Output (ERO)
process and normally is also sent to one or
more Event Rating (ERT) processes for
rating.
Rated event Normalised event that has been output by
an ERO process after being rated
successfully by one or more ERT
processes.
Rater error event Event that caused an error in the ERT
during rating, such as incorrect evaluation
of a tariff expression or a reference to an
undefined service. All charges generated
for a rater error event are discarded.
Raw event Event generated by a switch or other
device. The event format is typically device
specific.

Balance Management

Balance management is the process by which real-time account
management is achieved. TRE servers work together with the rating
engine to offer service authorisation, information on advice of charge,
and event-driven billing. The balance management process is shown in
Figure 1–2.
Carriers, Switches, Faults, Work

Orders, and Rental Events
Event Completion Event Establishment,

Event Authorisation
trerodb trerate
Submit events for rating Cancel and Update Reservations
Shared Memory
Rating Segment (Account,
Engine Customer Node,
Service, and Rating
Subtotal Caches)
Figure 1–2 Balance Management Process
Two TRE servers, the trerodb and the trerate, provide functions for
handling events coming in to Convergent Billing. These events may
include, among others, events from carriers and switches, and rental
events.
Once a call is established (or a request for authorisation arrives) in the
Convergent Billing system, balance management can be used to uniquely
identify that event and to make reservations. This process, using a
combination of functions offered by the trerate's biAccount and
biTrerate services, checks a customer's credit limit and reserves a
portion of that credit for the current event. This enables calls to be
refused if the customer's credit is not sufficient.

Once the call is complete, the complete event can be passed on to the
rating engine for normalisation and rating, using functions offered by the
trerodb's biEvent service. Balance management ensures that the event
continues to be uniquely identified in the process by passing its
reservation ID on to the rating engine.
Event Rating

Event rating is the process in which alpha events are converted into rated
events, using the tariffs that have been defined for each service and
customer. Rating is carried out by the rating engine, which is an
interlocking set of cooperative UNIX processes. The rating engine
architecture is shown in Figure 1–3.
ERB
Event
Rating
Broker
process
Rating Information
(including service,
Shared Memory Segment - product, and tariff
includes inter-process communication details)
Database cache (including

Commit Normalised
account, customer node, service,
rating events,
and rating subtotal caches)
trerate stream charges
server
Service, Account Database
Normalised
events Begin rating customer, and
tariff, account subtotal Online
stream Charges
details updates
Normalised events,
trerodb error events,
server ERO charges
ENM ERT
Normalised Event
Event Event events File SQL *Loader
Rating
Normalisation Rating
Output
process process
process
Socket
Corrupted and
duplicate events
ENM error
directory Event formats,
decoding expressions
Figure 1–3 Rating Engine Architecture

The rating engine runs under the control of the Event Rating Broker
(ERB) process, which in turn is controlled by the Backend Monitor
Process (BMP). The ERB provides services to the other rating processes
and manages the shared memory segments used for caching data from the
database, and for interprocess communication (for more information,
refer to the System Administration Guide).
The three cooperative processes of the rating engine are:
• The Event Normalisation (ENM) process, which converts alpha
events from file or from a remote host into normalised events.
• The Event Rating (ERT) process, which applies tariffs to the
normalised events to generate charges.
• The Event Rating Output (ERO) process, which directs the rated
events from the ENM and the ERT to a remote host, or to the
database. Database loading can be done directly or by means of
intermediate files and the SQL*Loader utility.
A minimum configuration for a single instance of the rating engine is one
each of the ENM, ERT and ERO. Providing memory and processing
power are available, it is often desirable to define extra processes to
improve throughput. An ENM can process multiple event types. In
addition, specially configured ENM and ERO processes are required if
the Real Time Rating Pipeline (RTR) is implemented.
For more information on rating engine optimisation and Real Time
Rating, refer to the System Administration Guide.
Event Rating The Event Rating Broker (ERB) process controls rating under the
Broker (ERB) supervision of the BMP. Multiple broker processes can be configured to
process run on one Singl.eView instance. The other rating processes (ENM,
ERT, and ERO) run as child processes of each individual ERB.
The ERB also creates the shared memory segment used for inter-process
communication, as well as the account, customer node, rating subtotal,
and service caches. Caches speed up performance by providing
immediate information to the rating engine. If the required information is
not in the cache, the rating engine retrieves it from the database and
stores it in the cache for later use. For more information on caches and
cache configuration items, refer to the System Administration Guide.
ERB Processing
The flow of processing in the ERB is as follows:
1. On startup, the broker connects to the database and creates, or
connects to, the caches used by the ERT and trerate processes.
2. If there are ENM, ERT, or ERO processes associated with the
broker, the ERB creates, or attaches to, the shared-memory
segment and starts the ENM, ERT, and ERO processes that have
been configured for that ERB.

3. If no ENM, ERT, and ERO processes are associated with that

particular ERB, the ERB does not create or attach to any ERB
shared memory segments. This allows one broker to be
responsible for the caches and other brokers to be responsible for
one or more ENM, ERT, and ERO processes.
4. If all processes are running on one machine, the ERB performs
no other function other than to monitor the other processes, and
to pass external commands onto the appropriate rating process.
5. Every EXPIRY_POLL seconds, the ERB cleans up the rating
streams and caches.
Account Cache
The account cache is used for caching database details associated with
accounts and account reservations. Account cache fetches and updates
are primarily performed by rating processes to total all of the unbilled
charges for each account, and to provide a mechanism during rating to
check these unbilled charges and see whether they exceed some pre-
determined limit.
Customer Node Caches

The customer node caches are used for caching database details
associated with customer nodes. There are two customer node caches:
• CustomerNode – A configurable set of columns from the
CUSTOMER_NODE_HISTORY_V database view.
• CustomerNodeDA – A cache of derived attributes from the
CUSTOMER_NODE_DA_ARRAY table.
Rating Subtotal Cache

The rating subtotal cache enables the access and creation of subtotal
values (aggregates) at rating time. In practice, only the ERT and the
trerate server have access to the Rating Subtotal cache.
Service Caches
The service caches are used for caching database details associated with
services, currencies, and general ledger (GL) codes. The ERT and the
trerate processes use these caches primarily to retrieve service and tariff
details that are required to rate an event.
There are seven service caches that are supported: Service ID, Service
Name, Derived Attribute, Network Name, Currency, GL Code, and
Product caches.

Event The Event Normalisation (ENM) process is responsible for converting

Normalisation alpha events into normalised events. Depending on its configuration, it
(ENM) process either waits for a command to start normalising events from a binary file
on disk containing events of a specified type, or listens on a socket for
one or more Real Time Rating events from a remote host. For more
information on Real Time Rating, refer to the System Administration
Guide.
For either form of input, the source is represented by a normalised event
file and is a collection of normalised events and one or more charges
generated for those events.
The flow of processing in the ENM is as follows:
1. The alpha event is parsed, using an event record definition
retrieved from the database.
If an event from a file does not conform to the specified input
format (a corrupted event), it is appended to a file (with an
extension of .e) in the ENM's error directory (for more
information, refer to Rating errors later in this chapter).
Similarly, if the ENM process is reading a disk file and it detects
that the remainder of the file is corrupt, the remainder of the file
is appended to the error file. Corrupted events received from
remote hosts are rejected, and the host informed.
2. The input record is unpacked, and data fields are assigned to
variables.
3. The ENM applies any defined expressions to the variables.
These expressions are used to:
• Validate the input data.
• Calculate the normalised equivalent value.
If a variable cannot be normalised for any reason, it is flagged as
a normalisation error event (for more information, refer to Rating
errors later in this chapter).
4. The variables are re-ordered to build the normalised event.
5. The normalised event is passed through the ERB to the ERO for
output, and normally to one or more ERT processes for rating.
Normalisation error events are sent only to the ERO.

Tracer Record
An ENM process may successfully decode a record that does not
represent an event to be normalised. This type of record is termed a
tracer record and may include information such as the number of records
in a disk file. It may also include header or footer information for the
file. If the ENM process is reading from a disk file, any detected tracer
records are buffered in memory.
If an error file is created for that disk file, any tracer records buffered up
to that point are written to the error file before any corrupt data is written.
This means that any information stored in the tracer records of the
original disk file is preserved in the tracer records of the resultant error
file in order to assist with subsequent processing.
Count File
If the ENM process is counting events from a file, the ENM performs all
the processing that it normally would for rating, except that the event is
not sent to the ERT and ERO. Count results are appended to the count
file upon completion. The count file is stored in the home directory and
is labeled enm<process number>.cnt, where <process number> is
the number of the ENM process.
Status File
While processing events from a source, the ENM process maintains a
status file in its home directory. The name of this file is enm<process
number>.sts (where <process number> is the number of the ENM
process).
The status file contains pertinent event file information (such as process
dates and times, current and previous file byte offsets, and error counts).
The status file is updated each time the ENM is synchronised with the
ERO. Synchronisation is completed once the ENM's output to the ERO
matches the output by the ERO into the database. The ENM may
synchronise many times during the processing of a large normalised event
file. The number of times an ENM will synchronise depends on the
configuration attributes set up for that particular ENM (SYNC and
SYNC_TIMEOUT).
If processing of a data file is interrupted unexpectedly (for example, due

to an electrical power failure), the ENM process uses the information in
this file to resume processing when it is restarted. The ENM also checks
for duplicate events during this process. Once the end of the source is
reached, the ENM process removes the status file.
Event Rating The Event Rating (ERT) process is responsible for generating charge
(ERT) process records for normalised events received by the ERB. It uses methods from
the ERM (Event Rating Module) to access information in caches and rate
normalised events.

For each normalised event, the flow of processing in the ERT is as

follows:
1. The ERT decodes normalised event attributes from the event and
assigns them to the direct variables associated with the
NORMALISED_EVENT_V database view.
2. The RSC (Rating Subtotal Cache) is prepared for updates to

rating subtotal values (as a result of rating the normalised event).
3. An ERM method is then used to generate charges, evaluate
subtotals, and (if account aggregation is enabled) aggregate
unbilled amounts to accounts.
4. If an error occurs, the ERT flags the normalised event as an error
event, reverses any rating subtotal updates, and aborts rating of
the event.
5. If rating is successful, the ERT commits all subtotal updates
made for that event to the RSC.
6. If the commit fails, the ERT reverses any account updates (if
account aggregation is enabled), and tries again (up to
RATE_RETRY_LIMIT) to execute the above steps. Once the retry
limit is reached, the event is flagged as an error event.
Event Rating The Event Rating Output (ERO) process takes normalised events from
Output (ERO) the ENM and charges from the ERT, and sends them to a remote host (for
process Real Time Rating) or to the database. Database updating can be done
directly, or the ERO can write its output to a SQL *Loader file for later
batch updating. ERO output direction depends on the configuration
parameter OUTPUT_METHOD.
Note: For large volumes of data, batch updating from files is likely to be
more efficient than direct updating (for more information, refer to the
System Administration Guide).
During rating, each ENM establishes a link with one ERO (if there are
multiple ENMs or EROs running), and maintains this link for the current
event file only. The ENM selects an ERO that is not currently processing
records, based on the ERO's priority (set up in the process configuration).
The ENM/ERO pair communicate with each other (using the inter-
process communication shared memory segments) to ensure that events
pass successfully through the ENM and one or more ERTs, and that the
ERO remains synchronised with the ENM. Events that are successfully
normalised and rated are passed to the database normalised event and
charge tables, or to the remote host. Normalisation or rater error events
(collectively referred to as error events) are either stored in the database
or are transmitted to the remote host.
Each normalised event file record is associated with a rating stream, and
each normalised event contained in that file shares the same rating
stream.

The ERO process logs all error messages to the following file:
$ATA_DATA_SERVER_LOG/log.out
Database Synchronisation
The ERO is responsible for ensuring that the account and rating subtotal
caches (ACM and RSC) are kept in synchronisation with the database.
Therefore, both caches are updated when the ERO commits records
(normalised event files, normalised events, normalised event errors, and
charges) to the database.
If an error occurs and either of the caches cannot be updated, the ERO
logs an error message and performs a database rollback. The ERO then
rolls back all account and rating subtotal cache updates associated with
the file that it is currently processing.
If the database is successfully committed, but an error occurs in the
cache, the ERO logs an error message and continues processing. If a
cache is corrupted, the rating engine should be restarted.
Duplicate event checking

The ERO process supports duplicate event checking if loading directly to
the database. In this case, a unique index should be set up in the
NORMALISED_EVENT table. The Oracle system will automatically check
this index when loading the event, and if a duplicate already exists, the
event will be rejected.
Note: If a TCP/IP socket connection is being used, the remote system
should perform duplicate event checking.
Rating errors Errors in the rating process can take one of two forms:
1. The alpha event cannot be parsed by the ENM because it does
not conform to the specified input format; these are referred to as
corrupted events. If received from a remote host, corrupted
events are rejected and an error message sent to the originator.
Corrupted events found in files are put in the ENM error
directory in a file with the same name as the source file and a .e
extension. Possible courses of action are to:
• Correct the corrupted events outside of Convergent
Billing, then copy them back to the ENM home
directory, and rate them again; this is appropriate if there
is only a small number of errors.
• To revoke the entire rating run, correct the input files by
some external means, then rate them again; this is
appropriate if there is a large number of errors, perhaps
caused by a software problem at the switch.

2. The event conforms with the specified input format, but contains
data that either cannot be normalised or rated; such events are
known as error events (events are either stored in the database or
are transmitted to the remote host).
3. The event can be normalised, but errors occur when committing
to the database. For more information, refer to Database
Synchronisation earlier in this chapter.
For more information on viewing and correcting corrupted and error
events, refer to Chapter 2, Rating.
Parallel tariffing The rating engine can apply different tariffs to the same normalised event
in one pass. This technique is known as parallel tariffing which makes it
possible to apply simultaneously separate tariffs that calculate charges to
customers, commissions, taxes (such as VAT or GST), general levies,
competitor's tariffs (for bill comparisons), and loyalty points.
Parallel tariffing simplifies rating as each event requires only a single
pass through the rating engine, but it also increases the ERT processing
load. It is often appropriate to provide two or more ERT processes for
each ENM process to avoid processing bottlenecks (for more
information, refer to the System Administration Guide).
Recurring Recurring charges, such as equipment rentals and maintenance contracts,

charges differ from other events in that they are generated by Convergent Billing
itself, rather than coming from an external source.
The process used is the Rental Generation Process, which runs as the
TRE server trergp (for more information, refer to Billing later in this
chapter). The RGP uses customer and service data to generate
normalised events for recurring and one-off charges. These events are
then rated like any other event, to produce charges for inclusion in the
Bill Generation Process (BGP).

Billing
Billing is the stage when the rated events generated by the rating engine
are processed by the billing engine to generate billing data, and
eventually invoices for printing or delivery to the customer by electronic
means. Figure 1–4 shows the architecture of the billing engine.
Product/Facility details
Recurring tariffs
RGP BGP IGP Database GOP

Transactional
(trergp) (trebgp) (treigp) Read-only
Server Printer
Rental Bill Invoice Server General
or file
Generation Generation Generation Output
trerwdb
Program Process Process trerodb Process
Rental Adjustment Billing data

Customer Invoice images
events events product Templates
details Billing data
Rater Charges
Database
Rentals and adjustments (charges)
Figure 1–4 Billing Engine Architecture
All processes shown in the Figure 1–4, with the exception of the GOP,
are run as TRE servers and are automatically executed with the start-up
of the system. The GOP, used to print the final invoices (or output them
to file), is an independent process that runs as required.
The bill run schedule types provided with the base installation offer the
option of running a range of billing operations, from adjusting rental
events to un-applying invoices. If invoices are generated, they can be
sent to an output device, as well as applied to customer accounts.

Rental The Rental Generation Process is a TRE server (trergp). It can be used
Generation during billing to generate rental events and rental adjustment events
Process (RGP) before invoices or statements are generated. In rental generation mode,
rental refers to any recurring charge, such as a subscription to a service or
a maintenance charge, as well as equipment rental. In most cases, these
recurring charges are paid in advance. The RGP is also able to generate
events for one-off rental charges.
The RGP is able to run in Quality Assurance (QA) mode, which means
that these generated events will not be used to bill a customer.
If called in rental adjustment mode, the RGP is used to make any
corrections required to existing advance rental charges if the details of the
rental have changed since the charge was made. For example, an
adjustment may be required if the service was not available to the
customer during part of the relevant period. The rental adjustment mode
is therefore concerned with adjusting past rental charges, whereas the
rental generation mode is used to generate rental charges in advance.
All events generated by QA calls to the RGP are ignored for the purposes
of retrospective adjustment.
Note: The rating of events that are generated in both modes of the RGP
cannot contribute to aggregations or real-time unbilled account balances.
RGP Processing
Processing for recurring charges in the RGP is as follows:
1. Retrieves product, facility, and service details from the database.
2. Calculates the dates applicable to the rental generation period for
each recurring tariff. These dates are derived from the:
• Bill cycle, giving the effective start date.
• Tariff cycle, which defines the rental period and the
advance period.
• Pro-rating adjustment, which is used to bring the rental
charge into line with the bill cycle.
3. Builds the active time line for the rental generation period; this
line may not be continuous, for example, if the service was not
available for part of the period.
4. Generates rental events for each segment of the time line.
5. Stores information about the rental events for use by a
subsequent Rental Adjustment Process.
6. Writes the events into a specified directory, and instructs a
specified ENM process to rate them.

One-off charges are generated using specific tariffs associated with a

product. The RGP applies these tariffs exactly once when certain events
associated with a product lifecycle occur. Activation and cancellation of
a product instance, facility group instance, or service can result in one-off
charges. When multiple events occur in one billing cycle, multiple one-
off charges are generated.
Rental adjustments can be generated by the RGP before the BGP is run.
If the details of existing advance rental charges have changed since the
charge was made, rental adjustments are used to make the required
correction. For example, an adjustment may be required if the rental
service was not available to the customer during part of the period. The
RGP performs the following when processing adjustments:
1. Calculates the rental charges for a period in the same way as in
rental generation mode. The period is specified as a
configuration item attribute, with a default value of 90 days.
2. Compares the result of its calculation with the originally
generated rental charge.
3. Generates appropriate adjustment events that are rated for
inclusion in the customer's bill if the charges differ.
Bill Generation The BGP is a TRE server (trebgp) and is used to create the invoice detail
Process (BGP) from the charges incurred by a customer node (and by any child nodes for
which this node is specified as the invoicing node), and to calculate totals
and subtotals.
The processing flow through the BGP is as follows:
1. Retrieves all tariffs, subtotals, and derived attributes with context
'Normalised Event', 'Charge', 'Service', 'Customer Node', or
'Customer', and application environment of 'Rating' or 'Billing'.
2. Retrieves customer, service details and product information for
each customer hierarchy in the bill cycle.
3. Aggregates charges as required by the reporting level defined for
the node (invoice, statement, or none).
4. Applies eligible tariffs (normally discount tariffs), subtotals, and
derived attributes and lists depending on configuration.
5. Generates and saves invoice data for invoice generation.
The BGP is similar to the ERT in that it applies tariffs and supports
parallel tariffing, but there are two major differences:

1. The BGP applies tariffs to aggregated data records, rather than

individual ones. Aggregation means that the individual charges
are aggregated into one or more pre-defined groups for the
purpose of obtaining a total value for that grouping. In general,
charge records are aggregated according to the pre-defined
customer hierarchy to give totals for normalised events, services,
individual and child customer nodes, and customers.
2. The tariffs applied to the aggregated records are generally
discount tariffs rather than charge tariffs; for example, if a
customer's usage is higher than a preset limit for the specified
billing cycle, then a volume discount could be applied to the total
cost of the calls.
Invoice The IGP is a TRE server (treigp) and creates the invoice image for each
Generation customer, ready for output using the General Output Process (GOP). It
Process (IGP) does this by retrieving invoice data from the database and substituting it
into an invoice template. Current Convergent Billing releases use
templates in ASCII text, but any suitable text based page description
language can be used.
The IGP is also used to generate dunning letters for customers who are
overdue with payment.
The processing flow through the IGP is as follows:
1. Retrieves billing or dunning letter templates from the database.
2. Uses macro substitution to insert data into the appropriate
template for each customer or customer node. Data insertion is
based on Convergent Billing expressions.
3. Evaluates any calls to nested templates, substituting printable
information for template code.
4. Checks the eligibility criteria.
5. Stores the compressed invoice or letter image in the database.
trerwdb The Transactional server trerwdb is a general-purpose server supporting

global transactions using the TUXEDO two-phase commit. The
Transactional server advertises services that read and write to the
database and ensures the integrity of the transactions. For more
information refer to Chapter 19, Transaction Engine Servers and
Services, of the System Administrators Guide.

trerodb The read-only server trerodb provides database services that read data
from the database. The purpose of the read-only server is to separate
services that read database information from services that need to commit
data, so that the transaction load is shared across the TRE servers. In
addition, performance is enhanced as fewer servers are required for data
to be committed. For more information refer to Chapter 19, Transaction
Engine Servers and Services, of the System Administrators Guide.
General Output The final stage in billing operations is the production of the invoices or
Process (GOP) statements, either by printing or by generating files for electronic transfer
of accounting information. The procedures for doing this are explained
in Chapter 4, Batch Printing.
Working with Various schedule types allow the configuration of invoices and invoice
invoices images before committing them to customers' accounts. For more
information on billing schedule types, refer to Chapter 3, Billing.
Invoice Invoice templates play a significant part in billing; not only do they
control the appearance of the final bill displayed to the customer, they
templates
also play a significant role in processing the data that is displayed on
them.
For more information on the design and use of invoice templates, refer to
the System Administration Guide and the manual Invoice Design Tool.

Chapter 2
Rating
This chapter describes the use of the rating engine to process incoming
events in order to generate normalised events and charges. It also
describes methods for checking that events have been correctly
normalised and rated, and for correcting events that contain errors.
Events for normalising and rating come from two sources:
• Files generated by switches or other event sources (including
Convergent Billing internal events).
• A TCP/IP socket connection with a remote host.
This chapter deals only with the normalising and rating of events in files.
For more information about processing events from remote hosts, known
as Real Time Rating, refer to the System Administration Guide. The
System Administration Guide also describes processes that make up the
rating engine, and issues such as defining additional rating processes and
optimising rating engine performance.
Managing Rating Files
Event files should be placed in a known location, conventionally in the

data/server/input directory under the home directory of Convergent
Billing instance. They should be given names that reflect the source and
type of the event they contain and, if necessary, some indication of the
date range covered by the events.
Event file names must be unique. A new file that has the same name as
a file already processed cannot be processed. Including the date and
time of creation in the file name ensures that it is unique.

Rating
After rating, events are moved to an archive directory, conventionally

data/server/archive. If the Event Normalisation (ENM) process
cannot parse any events, these corrupted events are written to a file in the
error directory, conventionally data/server/error. The file has the
same name as the original file, with a .e extension.
The recommended directory structure for handling event files in
Convergent Billing is shown in Figure 2–1.
Singl.eView Convergent
Billing instance
home directory
data
server
input archive error log
data_file data_file data_file.e log.out

The log.out file contains
Successfully normalised files
progress and status details
are moved to the archive
from the rating process
directory
Corrupted events are written to
a file in the error directory with
the original file name and a '.e'
extension
Figure 2–1 Singl.eView Convergent Billing Directories for

Rating
The ENM can process multiple event types. Among the ENM attributes
are the paths to the input, archive, and error directories (for more
information on creating and configuring ENM processes, refer to the
System Administration Guide).
Each ENM can be configured with a different set of paths; for example,
to create subdirectories for each type of event under
data/server/input to better manage event files. This done by
specifying the path to the correct input directory in each configured
ENM.

Rating
Running a Rating Task
This section explains the running of a rating task, including the checks
required both before and after the task is run.
Note: The running of a rating task can consume substantial server
resources and requires frequent database access. Demand for server and
database resources may reduce performance, both for the rating process
itself, and for concurrent Convergent Billing processes. If possible, the
rating task should be run when other system demands are at a minimum.
Preparation Before scheduling a rating task:

• Correctly name all event files for rating, and place in the correct
directory.
• Create at least one ENM process for rating.
• Run all server processes including the TUXEDO processes (for
more information, refer to the System Administration Guide).
• Check that 'Update Lists' and 'Update Charge Categories' tasks
are either not required or have been run, as changes in list and
charge category definitions are not automatically extended to
existing product instances.
Running the A rating task is run by defining a schedule or an Immediate Task of type
rating task 'Rate Files'. By using a schedule, a rating task can be run at specified
intervals; an Immediate Task can run a single rating task immediately
(refer to Chapter 6, Scheduling Server Tasks for more information on
scheduling).
A 'Rate Files' schedule takes these parameters:
ENM Process
The ENM process that has been configured to handle the type of event
being rated should be selected; if events of different types are being rated,
it is necessary for each one to have its own ENM and schedule.
File Pattern
Pattern of the files being rated; wild cards are permitted. For example,
evt.*.itad
should be entered to rate all files in the directory with names starting with
the characters evt then contain arbitrary text (perhaps a time stamp), and
have the extension .itad.

Rating
ENM File Type

Defines the method used to parse the event, and an optional list of
expressions being evaluated as part of normalisation; the value selected
should match the type of event in the files.
ENM Event Type
Controls the way that normalised events of the given type are displayed.
The appropriate definition from the list should be selected.
Event Source
Name of the switch or other source of the files being rated; this
mandatory parameter is included in each Normalised Event generated by
the task.
After the task has been run, a message is received in a pop-up window if
logged on; if not, by email, advising of completion of the task.
The rating process can have one of four outcomes for an individual event
in a file:
• The event is in an invalid or unexpected format, and cannot be
parsed by the ENM; such corrupted events are written to a file in
the ENM error directory with the same name as the source file
and a.e extension.
• The event is parsed by the ENM, but is flagged as being in error
by the ENM or the ERT; such error events are saved in the
database.
• The event is normalised and rated without apparent error, but the
charge is incorrect (for example, because of the wrong definition
of a product or tariff); the event and charge are stored in the
database. Errors of this kind are often difficult to detect.
• The event is normalised and rated correctly; the normalised event
and the resulting charges are stored in the database.
Checking the Information on the results of a 'Rate Files' task can be obtained from these
results sources:
• Task Status and Results text on the Task Detail form
• log.out file
• Location of the original files
• Presence of files in the error directory
• Viewing normalised events
• Viewing error events
• Data feed reconciliation report
• Other reports.
Some techniques for correcting errors revealed by these checks are
discussed in Correcting Rating Errors later in this chapter.

Rating
Task Status and Results

To view the Task Status and Results fields of the rating task:
1. Select the Server Tasks ➩ Schedules option. The Schedule
Search form is displayed.
2. Click the Search button to list schedules.
3. Double-click on relevant list entry. The Schedule Detail form
is displayed.
4. Click the Search Task button. The Task Search form is
displayed.
5. Double-click on the list entry for the relevant task. The Task
Detail form is displayed.
A status of 'Success' shows that the file was successfully rated, and the
Results tab indicates the number of events found in the file; a status of
'Failure' is accompanied by the reasons for failure on the Results tab.
The log-out file

The progress of rating is recorded in the file $ATA_SERVER_LOG/
log.out, together with other events of interest. The easiest way to
inspect this file is to enter the command:
LOG <n>
at the UNIX command line, where <n> is the number of lines from the
tail of the file being inspected.
A text editor, such as vi or ed, can also be used to examine the file. A
rating run is bounded by messages such as enm: Commenced
processing file <filename> and enm: Completed processing
file <filename>. An analysis of the output, and a listing of any
errors encountered, can be found between these messages.
Note: Additional help on error messages can be found in the Online Help
System.
Original file location

When rating is complete, events that were successfully rated are moved
from the data/server/input directory to the
data/server/archive directory.
Error files
If the ENM detects any corrupted events, it puts them in a file in the error
directory. The file has the same name as the original event file, with a .e
extension. The data/server/error directory should also be checked
for any such corrupted event files.

Rating
Viewing normalised files and events

To retrieve details of all files that have been rated and the normalised
events they contain:
1. Select the Server Tasks ➩ Events ➩ View Normalised
Files and Events option. The Normalised File Search form
is displayed.
2. Use the search criteria to locate the file on which information is
required (for example, by searching on the file name).
3. Double-click on the list entry of the file. The Normalised File
The Normalised File Detail form displays the following information:
• File name, file type, and event source.
• Start and end dates.
• Creation Task information (rating engine version and Task Id).
• Rated and unrated event counts.
• Normalised and rating error event counts.
• Tracer event count.
• Discarded event count.
• Input event count (showing this to be the sum of the decoded and
corrupt event counts).
• Reprocessed counts (both event and error event).
• Deleted counts (both event and error event).
• External input event count.
• The normalised events and error events associated with that file
(each event should correspond to an event in the original file.
There may be multiple event types per file).
Viewing error events

If an event is parsed by the ENM, but is flagged as being in error by the
ERT, it is stored as an error event; if the event is flagged as being in error
by the ENM, it is stored as a normalised error event. The Normalised
File Detail form indicates the presence of such events; a value is
displayed in the Rating Error Event Count field, for errors flagged by the
ERT, or in the Normalised Error Event Count field for errors flagged by
the ENM.

Rating
To view Error Events:

1. Select the Server Tasks ➩ Events ➩ View/Assign Error
Events option. The Normalised Event Error Search form is
displayed.
2. Click the Search button to list all error events.
3. Double-click on the relevant list entry. The Error Message field
in the Normalised Event Error Detail displays the reason why
the event is in error.
The Data Feed Reconciliation Report

The Data Feed Reconciliation Report (RDFR) is a report that provides
details of call records input within the specified dates, and a summary of
the charges that resulted (for more information, refer to the Reports
Guide).
Other reports
Other reports on rating may have been defined for specific Convergent
Billing installations, for example to detect abnormally high charges (for
more information on these reports, refer to the Reports Guide).

Rating
Correcting Rating Errors
This section outlines techniques that can be used to correct any errors
occurring as a result of a rating task.
The techniques are summarised in the flow chart of Figure 2–2.
Rate File
Determine and
Rating task resolve
No
successful? processing
problems
Yes
Correct records
Error file created Investigate the

Rename error file
on the server?
Yes nature of the
and move back to
errors
input directory to
be rated
No
Bulk assign
error events and
reprocess
Normalised error Are events in
Yes Yes
events created? error needed?
Assign single
Reprocess error
events to a file to
events
be reprocessed
Revoke file, or
revoke and move Re-rate file No
No
file
Purge error
events
Make
appropriate Are the charge
tariff/product details correct?
changes
Yes
Revoke file to
remove an entire End
file
Is there a need to
remove successfully
Yes
rated events that have
not been billed?
Purge events to
remove selected End
events
End
Figure 2–2 Rating Error Flow Chart

Rating
Unsuccessful If the rating task returns a status of 'Failure':

rating task 1. Check that all the required server processes are running (for more
2. Investigate the causes of failure reported on the Results tab of the
Task Detail form and take any corrective action.
3. Submit the rating task again.
Correcting Corrupted events are events that could not be parsed by the ENM, and are
corrupted written to the error directory.
events To deal with corrupted events:
1. Examine the events to determine the cause of the errors.
• Sporadic errors may indicate data transmission problems.
• More consistent and widespread errors may indicate a
problem with the switch or mediation software.
• Complete failure may indicate an incorrect Normalised
Event File type was selected for processing the file.
2. Take whatever measures are necessary to correct the corrupted
events in the error files.
• For smaller numbers, correct by hand.
• For larger numbers, a script might be more efficient.
• In severe cases, it may be necessary to refer the problem
back to the originator of the events.
3. When the corrupted events have been corrected, move the file
containing them to the input directory; it is suggested that the
error file be renamed to reflect its origin and current status.
4. Rate the corrected file, using an ENM of the correct
configuration for the type of event contained in the file.
Correcting error If an event was successfully parsed by the ENM, but an error was
events detected during normalisation or rating, the event is termed an error
event.
To deal with error events:
1. If the event is not required, purge by running a task of type 'Purge
Error Events' (for more information, refer to Rating Schedule
Types later in this chapter).

Rating
2. Examine the error events to decide if the problem is in the event

itself, or has been caused by another problem such as a wrongly
defined tariff, derived attribute, function, or other rating
component; for example, a derived attribute lookup table that
does not contain all the possible lookup values may have been
defined. An otherwise valid event might be treated as an error
event because the lookup failed.
3. If the problem is in the event itself, it should be corrected in the
Normalised Event Error Detail form, and assigned to a file for
rerating; this procedure is described below. A task of type 'Re-
rate Error Events' is then run.
4. If the problem lies in Convergent Billing configuration, take
whatever steps are required to correct the problem, then run a
task of type 'Re-rate Error Events (bulk)'; this allows entry of
selection criteria to identify the error events to be rerated. These
events are processed directly, without the need to assign them to
a file.
Viewing and correcting errors

To view and correct error events:
1. Select the Server Tasks ➩ Events ➩ View/Assign Error
Events option. The Normalised Event Error Search form is
displayed.
2. Enter search criteria, and click the Search button; if nothing is
entered, all errors are found.
The search criteria can be used to select only errors of a

particular type; for example, if the error 'No charges were
generated for this event' has the Error Message ID 2950, the
Search Field 'Error Message ID' and the value '2950' can be used
to retrieve only those events where no charges were generated.
3. Double-click the event in the list. The Normalised Event Error

4. Click the Update button on the toolbar.
5. Make any appropriate changes to the event; data on the Settings,
Party, or Attributes tabs may need to be checked.
6. Assign the event to a rerating file as described below.

Rating
Assigning an event to a rerated file

To assign an error event to a rerated file:
2. Click the Assign/View Existing button. The Assign/View
Existing Rerated File Search form is displayed.
3. Click the Search button to list the rerated files.
Note: The contents of a rerated file are inspected by double-
clicking its name in the list.
4. Select the required file by clicking on it, then click the Assign
button. The Assign/View Existing Rerated File Search form
closes. Check that the file name chosen is displayed in the
Rerated group. The sequence number of the event within this
file is also displayed.
5. Click the Save button on the toolbar.
Creating a new rerating file

To create a new file if a suitable rerating file described in step 3 above is
not found:
2. Click the Assign New button in the Normalised Event Error
Detail form. The New Rerated File form is displayed.
3. Enter the appropriate details in the File Name and Event Source
fields and click the Create button. The New Rerated File form
closes, and the error event is assigned to the new file.
4. Click the Save button on the toolbar; this saves the changes
made to the error event and the rerating file just created.
Correcting If normalised events and charges are created without apparent error, but
wrong charges the charges are consistently wrong:
1. Run a task of type 'Revoke File and move back'; this rolls back
all normalised events, error events, and charges that were
generated by the file. The original event file is re-created (except
for any corrupted events), and placed back in the input directory.
Note: If a task of type 'Revoke Event File' is run, the same
rollback process occurs and the event file is re-created; the
difference is that the file remains in the archive directory.
2. Correct the problem that caused generation of the wrong charges.
3. Run the rating task again on the re-created file.

Rating
Revoking a A file that has had one of its original normalised event errors reprocessed
rated and can be revoked in the:
reprocessed file • Reprocessed file, by running the task of schedule type 'Revoke
Event File' and then 'Revoke Reprocessed File'.
• Original file, by running the task of schedule type 'Revoke Event
File'.
Removing If certain events and charges are not needed (for example, because they
unwanted duplicate charges already processed), they can be removed by running a
events and task of schedule type:
charges • 'Revoke Event File', if all the events and charges originated in the
same file.
• 'Purge Events (non Error)' (using selection criteria to restrict the
purge to the unwanted events), if the unwanted events come from
a variety of sources.
Rating Schedule Types
Table 2–1 lists the schedule types that are available for rating tasks, with
a brief explanation of the function of each (for more information, refer to
Chapter 7, Schedule Types).
Table 2–1 Rating Schedule Types
Name Function
Purge Error Events Allows use of selection criteria to purge
selected error events from the database.
Purge Events (non Allows use of selection criteria to purge
Error) selected normalised events and
associated charges from the database.
Purge Files Deletes files that are older than a given
date from a specified directory. This can
be used for housekeeping.
Rate Files Rates the selected files with a specified
ENM.
Re-rate Error Events Rerates error events that have been
assigned to a rerating file.

Rating
Name Function
Re-rate Error Events Allows use of selection criteria to rerate
(bulk) selected error events without assigning
them to a file.
Re-rate Events Allows use of selection criteria to rerate
(bulk) events. Any charges for the associated
events are discarded and re-calculated;
any error events in the file are also
rerated.
Re-rate File Rerates the specified file. Any
associated charges are discarded and
re-calculated; any error events in the file
are also rerated.
Reprocess Error Reprocesses error events whose
Events charges are dependent on the value of
rating subtotals.
Reprocess Events Reprocesses normalised events that
have associated rating subtotals.
Revoke Event File Rolls back all normalised events, error
events, and charges for the file, and re-
creates the original event file (except for
corrupted events). The re-created file
remains in the archive directory.
Revoke File and Rolls back all normalised events, error
move back events, and charges for the file, and re-
creates the original event file (except for
corrupted events). The re-created file is
moved to the input directory.
Revoke Rolls back all normalised events, error
Reprocessed File events, and charges for the file, and re-
creates the original rerating file.
Using selection Certain rating schedule types for purging and rerating allow entry of
criteria selection criteria to confine the operation of the resulting task to a subset
of events. The criteria available in each case are taken from those listed
in Table 2–2 (the actual criteria vary from case to case), and may be used
in combination to further refine selection criteria.

Rating
Table 2–2 Selection Parameters
Criterion Description
ENM Process ENM process that rated the original
events.
File Process Start Date Dates between which the events were
File Process End Date processed in Convergent Billing.
Base Event File Name Name of the file in which the original
events were provided.
Event Start Date Period in which the events occurred.
Event End Date
Error Message Id Code for the error message attached
to the error events.
Event Source Source from which the events came
(switch or mediator).
Event Type Normalised event type associated with
the events.
File Type Normalised event file type associated
with the events.
File Record Start Nr Start and end positions of events in
File Record End Nr the file.
Event Where Clause SQL Where clause on the
NORMALISED_EVENT or NORMALISED_
EVENT_ERROR table that restricts the
choice of events.
File Where Clause SQL Where clause on the
NORMALISED_EVENT_FILE table that
restricts the choice of events.
Example
A certain tariff, applied to events of a particular type, has been identified
as incorrectly defined during a certain period of time. After correcting
the tariff, rerating all events that used the wrong tariff during that period
is required.
To achieve this, schedule a task of type 'Re-rate Events' using the
following parameters.
File Type
Normalised event file type appropriate to the events; alternatively, if the
ENM process which rated the events is known (provided just one ENM
process had been used to rate all the events in error), that ENM process
could be chosen.

Rating
Tariff
Tariff responsible for the incorrect charges generated for the events.
Event Start Date and Event End Date
Period during which the incorrect charges were generated.

Rating

Chapter 3
Billing
This chapter describes the use of bill runs to process normalised events
and charges to produce invoice information and invoice images for
customers and customer nodes. In addition, this chapter describes
methods for checking that invoice data and images are correct, and for
making any corrections that may be required.
For more information on the separate components of the Billing Engine,
refer to Chapter 1, Introduction to Rating and Billing. The output of
invoice images to printers or other output devices using the General
Output Process (GOP) is described in Chapter 4, Batch Printing.

Billing
The Bill Run Process
A specific set of billing operations can be applied to a single customer

node or a batch of customer nodes by performing a bill run. The ability
to perform separate billing operations allows the user to easily configure
the billing process. For example, the user can generate rental events
without producing invoices. Additional operations can also be performed
on existing bill runs. For more information, refer to Bill run operations
later in this chapter.
A bill run must be configured with a bill run type, which determines the
set of possible schedule types that can later be executed on this particular
bill run. For more information, refer to Bill Run Types later in this
chapter.
The ability to process multiple customer nodes allows the user to speed
up the bill run process, as well as control the quality of the process. For
example, the user can review initial invoices before the majority of
customer nodes have been processed; if the first invoices contain errors,
the bill run can be stopped. For more information, refer to Processing
operations later in this chapter.
Statistical information for each billing operation is recorded, including

the success or failure of the operation and its duration. For bill runs
processing multiple customers, the statistical information is recorded for
each operation and summarised for the overall bill run (for more
information, refer to Tracking the status of a bill run later in this
chapter).
Billing operators also have complete control over how many errors can
occur before the bill run is aborted. If errors do occur, it is only
necessary to revoke the billing operations on the customer nodes that
actually failed (for more information, refer to Correcting Billing Errors
later in this chapter).
In addition to producing invoices for customers, bill runs can also be used
to produce statements, which can be used for quality assurance purposes
or for customer information (for more information, refer to Setting up a
bill run later in this chapter).

Billing
Processing All schedule types used for performing billing operations for a set of
billing customers on a bill run have two common parameters that control how
operations the operations will be performed: Customer Batch Size and the Number of
Child Processes.
Customer Batch Size

The Customer Batch Size parameter controls the number of customers
that are passed to each bill run operation in turn. After identifying all
eligible customers for the specified operations, the customers are
prioritised and grouped into batches of the specified size. The requested
range of billing operations is then sequentially performed on each batch
in turn.
For example, if the billing operations to be performed are 'Rental Event

Generation' to 'Invoice Image Generation', the total number of eligible
customers is 1500 and the customer batch size is 100, then the processing
is as follows:
1. The customers are divided into 15 batches.

2. For the first 100 (highest priority) customers, perform the
following operations:
a) Rental Event Generation
b) Invoice Generation
c) Invoice Image Generation
3. For the second 100 customers, perform the following operations:

a) Rental Event Generation
b) Invoice Generation
c) Invoice Image Generation
4. For the third 100 customers....

Billing
Each operation on a customer batch results in the generation of a Bill Run

Operation Record. This record summarises the results of the operation on
the batch of customers, and appears in the Auditing tab on the Bill Run
Detail form. Customer Bill Run Operation Records are also generated
for each customer in the batch. These are viewable from the Customer
Details form and contain a basic summary of the result of the operation
for the customer node.
Number of Child Processes

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

set to 3, then the first 3 highest priority batches of 100 customers will be
allocated to the three child processes and their billing operations will be
performed concurrently.
Each parallel-processing stream acts independently of the others. As

soon as one stream completes processing a customer batch, it
immediately starts processing the next available batch in order of priority.
Specifying a number of parallel-processing streams can improve server
utilisation and billing throughput. It can also minimise the impact of a
certain customer batch stalling, due to the batch containing customer
nodes that take a long time to process. If multiple parallel-processing
streams are specified, other customer batches can be automatically started
and completed while the long-running customer batch is still processing.
Neither of these concepts were available in Convergent Billing version

3.03 or earlier versions. In earlier versions of Convergent Billing, the
processing was equivalent to all customers being processed as part of a
single batch on a single processing stream.
The graph in Figure 3–1 displays bill run processing with a batch size of
100 and number of child processes set to 3.
Rental Invoice
Invoice Image
h2 Generation Generation
tc s
ba er
er tom
om s
st cu
cu 00)
(1
bill_run_execute customer batch 1
(multi processing) (100) customers Rental Invoice to customer
Invoice Image
bill_run_cust Generation Generation
(single processing)
cu
(1 stom
00
) c er b
us at
to ch
m
er 3 Rental Invoice
s Invoice Image
Generation Generation
Figure 3–1 Bill Run Processing

Billing
Bill run A bill run consists of a set of bill run operations and each bill run
operations operation is performed on a set of customers. The results of each
operation on each customer is recorded and therefore provides a complete
audit trail. Bill run operations can be performed on individual customers
or on a specified group of customers.
Bill run operations can not be deleted or directly updated. The
BILL_RUN_OPERATION reference type defines the operations that
perform and revoke operations on the bill run. The following table lists
the available billing operations:
Perform Operation Revoke Operation

Rental Adjustment Generation Revoke rentals and adjustments
Rental Event Generation Revoke rentals and adjustments
Invoice/Statement Generation Revoke invoices/statements
Invoice/Statement Image Revoke invoice/statement
Generation images
Apply invoices Unapply invoices
Allocate invoices De-allocate invoices
Print invoices Discard printing of invoices
Depending on the mode of operation, biBillRunExecute& or

biBillRunExecuteForCustomer& performs each operation. For each
operation, the bill run ID, effective date, effective day of month, bill run
operation ID, and the quality assurance indicator is passed to the
interface. In addition to these, biBillRunExecute& also passes the list
of root customer nodes. For biBillRunExecuteForCustomer&, the
TRE then returns statistical information on the operation,
biBillRunExecute& returns statistical information as well as a list of
customer nodes that were successfully processed, the list of customer
nodes that failed, and a list of customer nodes that where suppressed.
Tracking the Statistical information for each operation is recorded, including the
status of a bill success or failure of the operation and its duration. For bill runs that
run process batches of customers, the statistical information is recorded for
each operation and summarised for the overall bill run. This statistical
information is displayed on the Auditing Information tab:

Billing
Server process Different server processes are responsible for implementing the different
TRE interfaces for each operation. All revoke operations are run by the
EPM trerodb process, except 'Unapply Invoices', which is run by the
trerwdb process. The primary server responsible for each operation is
shown in the following table:
Bill run operation TRE interface

Rental Adjustment Event Generation TRERGP
Rental Event Generation TRERGP
Invoice/Statement Generation TREBGP
Invoice/Statement Image Generation TREIGP
Apply Invoices TRERWDB
Allocate Invoices TRERODB
Print Invoices GOP
Revoke Rental Events and Adjustments TRERODB
Revoke Invoices/Statements TRERODB
Revoke Invoice/Statement Images TRERODB
Unapply Invoices TRERWDB
De-allocate Invoices TRERODB
Discard Printing of Invoices TRERODB

Billing
Configuring the The billing configuration specified for each customer determines the set
customer node of functions executed to perform each of the operations configured for a
bill run. Three steps are necessary to configure customer nodes for a bill
runs:
1. The billing configuration must be defined.
The CUSTOMER_BILLING_CONFIGURATION reference type
defines the available billing configurations. There are three types
of billing configurations supplied with Convergent Billing:
'Default', 'High Volume Service', and 'Large Corporate
Hierarchy'.
2. The billing configuration and its operations must be mapped to
TRE functions.
The BillingConfiguration derived attribute table maps each
billing configuration and operation to the TRE function that is to
be called to invoke it. The user can add new configuration
mappings to the BillingConfiguration table. If nothing is
added to this table for the new billing configuration, the
operations defined in the 'Default' configuration will be used.
It is possible to add new TRE operation functions to be used in
the billing configuration. An EPM sample function,
biBillRunTemplateOperation&, is provided with
Convergent Billing as an example of how to write a function to
perform a new billing operation.
3. A billing configuration must be selected for the customer.
A configuration is selected using the Configuration field on the
Billing tab on Customer Detail form. A configuration can only
be selected for a root customer node, and must be null for child
nodes. Selecting the correct billing configuration ensures that the
bill run uses the appropriate functions. For example, for a
corporate customer with a large hierarchy, the corporate billing
configuration can be selected to ensure that the bill run is
efficiently executed using parallel processing.
Setting priorities Prioritising customers and services on a bill run is controlled by

specifying the Billing Priority of the Customer Detail and Service
Detail form. The lower the numerical value specified for the Billing
Priority, the higher the priority. The bill_run_execute script always
processes the highest priority customers first.

Billing
Performing a Bill Run
This section describes how to perform a bill run, including the checks
that are required both before and after the task is run.
Note: Performing a bill run can consume substantial server resources and
requires frequent database access. Demand for server and database
resources may reduce performance, both for the billing processes and for
concurrent users. If possible, the bill run should be run when other
system demands are at a minimum.
Preparation Before scheduling a bill run, ensure that the event files containing events
for inclusion on bills have been successfully rated, and any corrupted or
normalisation error events have been corrected.
Supported task There are two available task types that are supported by the schedule
types types used to perform a bill run:
• Bill Run Operation and
• Bill Run Customer Operation.
Bill Run Operation performs a range of operations for all customers.
Bill Run Customer Operation performs a range of operations for
the specified customer.
Setting up a bill A bill run schedule uses one of the following supported task types:
run • Standard Bill Run, which generates an invoice that is sent out to
customers.
• Quality Assurance Bill Run, which generates a temporary bill
that is not sent to the customer and not paid; this can be used for
quality assurance purposes and quoting.
• Complete Bill Run, which completes a standard bill run, a QA
bill run, or a part thereof for the total bill run.
• Complete Bill Run for Customer, which completes a standard bill
run, a QA bill run, or a part thereof for a specific customer
hierarchy.
By using a schedule, a billing task can be run at specified intervals; a one-
off task runs a single rating task immediately (for more information, refer
to Chapter 6, Scheduling Server Tasks). Several billing schedules for
different customers or groups of customers can be set up.

Billing
When defining a bill run schedule, the following are some of the
methods that can be used to specify the date for a monthly schedule:
• Fixed date, relative to the start of the month.

Example: 15th of the month.
• Fixed date, relative to the end of the month.
Example: 2nd last day of the month.
• Specific day/week combination, relative to the start of the
month.
Example: 1st Friday of the month.
• Specific day/week combination, relative to the end of the
month.
Example: Last Friday of the month.
The RGP adds periods and calculates durations based on the day number
relative to the start of the month. It is therefore strongly recommended
that bill runs including rental generation operations are run on the same
basis, to avoid potentially inconsistent calculation of the day number.
This requires the selection of a Repeat type of 'Month Day' when
defining the bill cycle schedule.
For information about usage of the separate schedule types, refer to

Chapter 7, Schedule Types.
If the appropriate settings were selected when the task or schedule was
defined, after the task has been run, a message is received in a pop-up
window (if the user is logged on); if the user is not logged on, an email
notification is sent advising of completion of the task.
Bill run types Each bill run is configured with a particular bill run type. Bill run types
help to determine the outcome of a bill run schedule and are defined
using the Bill Run Type Definition form.

Billing
The bill run type allows the user to specify the following for bill runs
using this specific type:
• Quality Assurance flag, which indicates whether the bill run is

used for quality assurance purposes or not.
• Bill Run Validation, which specifies the entity validation that is
used to configure the display of the general statistics for all bill
runs of this type. These statistics are displayed on the General
tab of the Bill Run Detail form. Entity validation can also be
used to specify the Schedule Name label on the Details tab.
• Operation Validation, which specifies the entity validation that is
used to configure the display of the general statistics for all bill
run operations associated with bill runs of this type.
• Currency, which indicates the currency in which billed or
revoked amounts are stored for bill runs of this type (and bill run
operations associated with it).
• Summary Function, which specifies the function that is used to
summarise the current state of a bill run after the current task or
process is finished. The results of this function can be used, for
example, to populate the General Statistics fields on the General
tab.
• Supported Tasks, which is the list of schedule types that can be
performed on bill runs of this type. Only these tasks will be
displayed on the list of available operations in the Perform
Operation window (accessible from the Bill Run Detail or
Customer Bill Run Detail forms).
The supported tasks list also allows compatible schedule types to
be filtered based on the operation status of the bill run, as well as
establishing whether particular operations can be revoked.
• Status Highlighting, which enables display characteristics for
individual bill run summaries.

Billing
Bill run Important schedule parameters for new bill runs include:
schedule • Bill Run Type
parameters
Refer to Bill Run Types earlier in this chapter.
• From Operation and To Operation
These two codes specify the range of operations which are to be
executed for the bill run.
• Customer Batch Size, and Number of Child Processes
Refer to Processing Operations earlier in this chapter.
• Error Thresholds
The bill run will fail if the total number of customers with errors
equals or exceeds this parameter.
• Where Clause
Allows a refining of the selection of customers (to be processed)
by specifying a relevant SQL WHERE clause. This clause uses
fields from the CUSTOMER_NODE_TRE_V view. The order or
priority of the customers selected is by
CUSTOMER_NODE_TRE_V.BILLING_PRIORITY and then by
CUSTOMER_NODE_TRE_V BILLING_CONFIGURATION_CODE.
Modifying a bill Once a bill run is set up using the Schedule Definition form, any
run changes required in the schedule itself can be made by searching for and
changing the appropriate form.
A bill run schedule that was set up using the One-off Task Definition
form can be changed using the Task Details form, which is accessed
from the Bill Run Detail form. The task date and times can be changed
and the task re-submitted by clicking the Re-submit… button.
Once a bill run is actually executed, the details cannot be directly
modified. Additional operations can however be performed later (refer to
Performing an operation on a bill run later in this chapter).
Performing an Additional operations can be performed on existing bill runs for either a
operation on a batch of customers or for a single customer:
bill run • To perform an operation on a batch of customers, select the
Perform Operation… button from the Bill Run Detail form to
display the Perform Operation for Bill Run form.
• To perform an operation for a single customer, select the
Perform Operation… button from the Bill Runs for
Customer form to display the Perform Operation for
Customer form.

Billing
Both of these forms list the bill run operations that can be subsequently
performed. Selecting the appropriate operations from the list and
pressing the Submit button creates a one-off task that prompts for any
additional details before performing the requested operations.
Stopping a bill A bill run that is in progress can be stopped by entering the appropriate
run expression, including the function biBillRunStop&(), in the
Expression Test form. To stop a bill run:
1. Select the Server Tasks ➩ Bill Runs option. The Bill Run
Search form is displayed.
2. Enter the appropriate search criteria and click the Search…
button. A list of matching bill runs is displayed in the Bill Run
List form.
3. Select the appropriate bill run and click the Details… button.
The Bill Run Details for Bill Run form is displayed.
4. Note the bill run ID, last modified date, and the task ID (this
information is used to stop the bill run).
5. Select the Maintenance ➩ Data Definition ➩ Expression
Test option. The Expression Test form is displayed.
6. Enter biBillRunStop&() in the Function Name field.
7. Enter the appropriate expression to stop the bill run in the
Expression field. For example:
{
var lBillRunId& := 5673;
var lLastModified~ := to_date('13/11/2001
14:04:51','dd/mm/yyyy hh:nn:ss');
var lTaskId& := 12543;
var lReason$ := 'Killed by operator';
return biBillRunStop&(lBillRunId&,
lLastModified~,
lTaskId&,
lReason$);
}
8. Click the Evaluate button. The result of the expression is
displayed in the Results field.
When all processes have stopped, all operations with a status of 'Running'
are changed to a status of 'Error' and the bill run is updated.
For more information on using the Expression Test form, refer to the
manual Variables, Expressions, and Functions.

Billing
Revoking a A bill run operation or task, which has already been executed in a
billing task schedule, can be revoked using the schedule type 'Revoke Bill Run'. For
information about this schedule type, refer to Chapter 7, Schedule Types.
Additionally, depending on the bill run type configuration, the Perform
Operations window can be used to revoke individual operations. For
more information, refer to Performing an operation on a bill run earlier
in this chapter.
Checking the Information on the results of a bill run is displayed on the Bill Run Detail
results form for that particular bill run. The form summarises the results of the
bill run, as well as displaying errors for both the bill run (if it failed) or
any individual operations on the bill run that failed.
Results for an individual customer node can be viewed by clicking the
Bill Run Details… button (Billing tab) on the Customer Detail form.
Techniques for correcting bill run errors are provided in Correcting
Billing Errors later in this chapter.
Invoice Data and Images

To view invoice data and images for a customer account:
1. Select the Accounts ➩ Invoices option. The Invoice Search
form is displayed.
2. Enter the appropriate search criteria and click the Search…
button. A list of invoices matching the specified criteria is
displayed.
3. Double-click on the invoice in the list with an issue date
matching the bill cycle. The Invoice Detail form is displayed.
4. Select the Transactions tab to view adjustments and payments
that have been received since the last invoice.
5. Select the Images tab and click the Invoice Image… button to
view the invoice image; this requires the execution of a server
task and may take some time.
Display Types for Invoice Images

Convergent Billing offers the ability to view different types of invoices
from the client. The image type extension, specified in the invoice, is
mapped to a display image type in the DisplayImageType derived
attribute. This attribute can be altered to suit the invoice templates that
are used. The following table lists the current mapping from extension
(output image type) to display image type.
Output Image Type Display Image Type

.tex.gz pdf
.tex.Z pdf

Billing
Output Image Type Display Image Type

.txt txt
.txt.Z txt
.txt.gz txt
.pdf pdf
.xml xml
.xml.gz xml
.xml.Z xml
Producing and checking appropriate reports

Billing reports are defined for the installation of Convergent Billing. For
more information, refer to the Reports Guide.
Suppressing There are two possibilities for invoice suppression:

invoice • Suppress invoice generation in bill runs for particular customers.
generation
It is possible to suppress invoices for individual customers,
customer types, or groups of customers. For individual
customers, this can be executed using direct updates on the
Customer Details form.
Invoices are suppressed for a specific type of customer using the
Customer Type form.
Invoices for customer groups or hierarchies are handled using a
schedule. Invoices can be suppressed using the schedule type
'Billing Suppress'. Suppressions can then be revoked using the
'Billing Unsuppress' schedule type. For usage of the separate
schedule types, refer to Chapter 7, Schedule Types. Invoices can
also be suppressed for a specific type of customer using the
Customer Type form.
• Automatically suppress certain types of invoices.
Invoices can be suppressed based on calculated invoice values.
For example, if an invoice amount is less than $2 and an invoice
has already been generated in the last six months, the invoice can
be suppressed using invoice type expressions.
For more information on configuring invoice types, refer to the
System Administration Guide.

Billing
Correcting Billing Errors
This section describes the techniques used to correct any errors that may
arise as the result of bill runs.
When creating bill runs, the number of errors permitted before the bill
run is stopped can be specified on the Schedule Definition or the One-
off Task Definition form in the Error Threshold parameter. If a bill run
results in the specified amount of errors, the errors can be fixed, the
particular operation can be revoked if necessary, and the bill run
performed again with only the outstanding operations performed. If a
particular operation failed the first time, the operation is automatically
revoked and performed again.
Once errors are generated, or a bill run schedule has failed, the following
must be done:
1. View the Bill Run Detail form for the particular bill run and
determine which operation or operations failed. Failed
customers can be investigated using the Failed Customers…
button.
2. If no operations failed, but the bill run results are in error,
determine at which point in the operations the error occurred.
3. Revoke any operations that succeeded that were in error.
4. Correct the problem.
5. Complete the bill run.
The flow chart in Figure 3–2 summarises the process of correcting any
errors that are generated by executing a schedule of type 'Standard Bill
Run'. This type of bill run performs, by default, all standard billing
operations from 'Rental adjustment event generation' to 'Print Invoices'.
The flow chart can also be used for any subset of this range of operations.
Although it is possible to use individual tasks and schedules to correct
errors (revoke and re-do operations), it is highly recommended that the
user use the bill run process for this task. An individual bill run ties
separate billing operations together in one process and ensures that the
operations are completed in the correct order with the correct
prerequisites.

Billing
Run a Standard
Bill Run schedule
Check schedule status
Complete the Bill Run
Did schedule fail?
No Check schedule
parameters and correct
if necessary
Schedule post-billing Yes

reconciliation reports and
reconcile billing output View Bill Run Details
Revoke the operation in

error (and any operations
which succeeded it).
Billing details OK? No
Yes If necessary, perform a
Revoke Bill Run schedule
(revokes the entire bill run).
End
Rated
charges
Correct tariffs and
Billed charges Reason for incorrect incorrect
re-rate appropriate
incorrect details
events
Correct Tariff/ Invoice

Subtotal/Customer Invoices not
format
details printed
incorrect
Correct printing Fix invoice

problem templates
Complete the Bill Run
Figure 3–2 Billing Error Flow Chart

Billing
Billing Schedule Types
Table 3–1 lists the schedule types that are available for billing tasks, for
an entire bill run, with a brief explanation of each.
Table 3–1 Billing Schedule Types for Bill Runs
Name Function
Apply & Allocate Applies invoices to the appropriate
Invoices customer accounts for a specific bill run
and allocates credit payments and
adjustments.
Apply Invoices Applies invoices to the appropriate
customer accounts for a specific bill run.
Complete Bill Run Completes a standard bill run, QA run, or
part thereof that has previously been
interrupted, failed, or revoked.
Generate Invoice Generates invoice images for a specific
Images bill run.
Print Invoices Prints invoices for a specific bill run.
Revoke Bill Run Revokes a standard bill run, QA run, or
part thereof.
Revoke Invoice Rolls back invoice images in the database.
Images
Revoke Invoice Print Revokes the ‘Printed’ flag, so that the
Settings batch can be printed again.
Revoke Invoices Rolls back all invoice data and images
associated with the specified billing task.
Revoke Invoices Revokes invoices and images, but keeps
(keep Rentals) rental events, for a specific bill run.
Revoke Rental Revokes rental events.
Events
Un-apply & De- Un-applies invoices and de-allocates any
allocate Invoices credit payment and adjustment amounts.
Un-apply Invoices Un-applies invoices.

Billing
Table 3–2 lists the schedule types that are available for billing tasks, for
individual customers, with a brief explanation of each.
Table 3–2 Billing Schedule Types for Individual Customers
Name Function
Apply & Allocate Applies invoices for a specific customer
Invoices for and allocates credit payments and
Customer adjustments.
Apply Invoices for Applies invoices for a specific customer.
Customer
for Customer part thereof that has previously been
Images for customer.
Customer
Print Invoices for Prints an invoice for a specific customer.
Customer
Revoke Bill Run for Revokes a bill run for a specific customer.
Customer
Revoke Invoice Revokes invoice images for a specific
Customer
Revoke Invoice Print Clears the print settings for a specific
Settings for customer.
Customer
(keep Rentals) for rental events, for a specific customer.
Customer
Revoke Invoices for Revokes invoice images, invoice details,
Customer and rental events for a specific customer.
Revoke Rental Revokes rental events for a specific
Events for Customer customer.
Unapply & De- Un-applies invoices and de-allocates any
allocate Invoices for credit payment and adjustment amount for
Customer a specific customer.
Unapply Invoices for Un-applies invoices for a specific
Customer customer.

Billing
Table 3–3 lists the schedule types that are available for related billing
tasks with a brief explanation of each.
Table 3–3 Related Billing Schedule Types
Name Function
Apply Transactions Applies future dated payments and
adjustments.
Billing Suppress Suppresses invoice generation for
customer hierarchies, causing these
hierarchies to be skipped by schedules
running types such as 'Standard Bill Run'.
Billing Unsuppress Halts suppression of invoice generation.
Dunning Letter Allows creation of dunning letters for
Generation customers with overdue accounts. The
letters are printed using the GOP.
General Bulk Output Runs the General Bulk Output Process for
by Task a specific task.
General Bulk Output Allows invoice or letter images to output to
Process a printer or other output device. Refer to
Chapter 4, Batch Printing.
Invoice Reprint Generates new invoice images for
Generation invoices that have been flagged for
reprinting.
Invoice View Image Used internally by Convergent Billing for
viewing invoice images on request.
Quality Assurance Creates and executes a QA bill run for a
Bill Run set of customers associated with a given
schedule.
Events
Standard Bill Run Creates and executes a standard bill run.

Billing
Billing of Customer Hierarchies
Each customer node is assigned a reporting level, which can be one of

these values:
• Invoice
• Statement
• None.
Invoices are produced for every node in the billing schedule with a
reporting level of 'Invoice'. Invoices will automatically include, in the
calculated invoice amount, any charges assigned to 'Statement' or 'No-
reporting' nodes that are below them in the hierarchy.
Nodes with a reporting level of 'Statement' receive a statement of charges
incurred by that node only.
Displayed invoice or statement details are almost completely
configurable using the parameters of the
biInvoiceReportAccount&() function (which is called in the
generation of an invoice or statement image).
Note: The root customer node can only have a reporting level of
'Invoice'.
The following example shows the effect of reporting level on invoice and
statement generation. The hierarchy involved is shown in Figure 3–3.
ABC
Banking
East Central West

Branch Branch Branch
Loans Investments
Figure 3–3 Customer Hierarchy
The details of each node are included in Table 3–4.

Billing
Table 3–4 Node Details
Node Type Parent Reporting Level

ABC Banking Root Invoice
East Branch Child ABC Banking Statement
West Branch Child ABC Banking Statement
Central Branch Child/ ABC Banking Invoice
Parent
Loans Child Central Branch None
Investments Child Central Branch Statement
The billing implications of this hierarchy are:

1. ABC Banking (the root node) receives an invoice for its own
charges, and those for East Branch and West Branch.
2. Central Branch receives an invoice for its own charges, and those
for Loans and Investments.
3. East Branch, West Branch, and Investments receive statements of
their own charges.
4. Loans receives nothing.

Billing

Chapter 4
Batch Printing
This chapter describes the General Output Process (GOP) and how it
performs the task of printing bulk information, such as dunning letters or
invoices, using tasks on the scheduler or information from previous
billing operations.
It also describes dunning letters (with its configuration) and how to set up
a printing configuration. Printing configuration is based on the following
elements:
Scheduler
• Output Device, which defines the commands used by the server
to direct the output to the required printer or other device.
• Output Method Type, which defines the location in the database
of the query view and the document image; it also specifies any
table update required (for example, to flag a dunning letter as
having been printed).
• Output Method, which consists of an Output Method Type and
one or more Output Devices. If the data is split over two or more
output devices; it can also select output order (for example,
dunning letter output might be ordered by state or province, or by
postal code).
Bill Run
• Configuration item type INVOICE_PRINT.
Knowledge of UNIX, SQL, and the Convergent Billing database structure
is required to carry out some of the tasks described in this chapter.
Access to a server terminal to issue UNIX commands may also be
needed.

Batch Printing
Invoice Output using the Scheduler
The following schedule types can be used for the output of invoices or
dunning letters using a schedule or an immediate task:
• General Bulk Output Process
Generates bulk output for a previous schedule (bill run, dunning
generation, or invoice re-print).
• General Bulk Output By Task
Runs the General Bulk Output Process by task ID.
• Dunning Letter Generation
Generates dunning letters for particular customers. Dunning
letters are used to remind customers about unpaid accounts.
By using a schedule, a task can be run at specified intervals; an
immediate task can run a single task immediately (for more information,
refer to Chapter 6, Scheduling Server Tasks).
GOP schedule The GOP requires these schedule parameters for the schedule types
configuration 'General Bulk Output Process' and 'General Bulk Output by Task':
parameters • Schedule to output (General Bulk Output Process)
Schedule producing the images for processing. The images
generated by the most recent task with 'Success' status are used
for input to the GOP.
• Task (General Bulk Output by Task)
Task ID producing the images for output.
• Output Method
Defines the processing that the images receive; the components
and configuration of the output method are described later in this
chapter.
• Directory for temporary data
Must exist when the task is run.
The following schedule parameters are required for the schedule type
'Dunning Letter Generation':
• Dunning Template
Select to generate the dunning letter (for more information, refer
to the System Administration Guide).

Batch Printing
• Percentage Unpaid (%)

Unpaid percentage of the total sum due that is required to trigger
a dunning letter; this can be used in combination with the Days
Overdue parameter.
• Days Overdue
Number of days the sum is overdue and which triggers a dunning
letter; this can be used in combination with the Percentage
Unpaid (%) parameter.
• Extension
File extension for the output file used when creating the report.
GOP schedule The GOP retrieves all the document images stored in the database by the
processing specified schedule's most recent task, then outputs them as instructed by
the output method. Images can be divided into as many batches as
necessary and each batch separately ordered and sent to a different output
device. The general flow of processing in the GOP is as follows:
1. The schedule ID parameter is used to identify the most recently
completed task for that schedule; only data produced during the
execution of that task is considered for output.
2. The output method type defined in the output method is used to
identify the database tables and views used to retrieve the data
required, including the document images; it can also define an
update performed on the database when an image has been
processed (for example, to flag that a dunning letter has been
printed).
3. The output method is associated with a table of output criteria.
This table may contain zero or more rows, and the criteria
retrieved include:
• The output device, which defines where the selected
document images are sent.
• An SQL WHERE clause, used to select which of the
retrieved images use this output device.
• An SQL ORDER BY clause, used to specify the output
ordering.
4. For each row in the criteria table, the GOP outputs the selected
data to the specified output device, using the appropriate
selection and sorting criteria.
5. Any images that remain after all the rows in the criteria table
have been processed are then sent to a default output device,
using a default ordering.

Batch Printing
If the criteria table is empty (that is, if the output is treated as a single
batch), then the default output method and ordering apply to the whole
batch.
Invoice Output using a Bill Run
The General Output Process is able to print images generated by previous

billing operations. This is done by specifying the billing operation 'Print
Invoices' when setting up the bill run, or by running the 'Print Invoices'
operation on previously-completed bill runs.
The numbers of customers for whom invoices are printed is determined
by the billing configuration set up in the customer configuration. For
more information on the Bill Run process, refer to Chapter 3, Billing.
Bill run The execution of the 'Print Invoices' operation requires a configuration
configuration item of type INVOICE_PRINT. This configuration item must be created
parameters prior to printing invoices. By default, the operation will look for the first
item in the list of configuration items of type INVOICE_PRINT.
For more information on creating configuration items, refer to the System
Administration Guide.
The following parameters are required for setting up the
INVOICE_PRINT item:
OUTPUT_METHOD
Defines the processing that the images receive; the components and
configuration, of the output method, are described later in this chapter.
TMP_DIR
Directory for holding temporary files used by the GOP.
ERROR_THRESHOLD
Maximum number of non-fatal errors that can occur before the GOP
terminates.
MAX_CHILD_PROCESSES
Maximum number of child processes for the GOP to use for the parallel
output of images. If this parameter is greater than '1', the GOP is run in
multi-process mode. Setting a maximum number of child processes
controls the number of simultaneous GOP processes and therefore system
performance. If parallel processing is used, the order in which invoice
images are output may not match the order in which they were input.
This parameter is ignored for a batch if the selected output device is
configured to concatenate images.

Batch Printing
Note: Parallel processing between separate report, invoice, and

statement images is supported. Parallel processing within a single report,
invoice, or statement image is not supported. For example, a 200,000-
page single invoice image will not be generated any faster using the
MAX_CHILD_PROCESSES attribute. However, other invoice and
statement images can be generated at the same time.
Setting up a bill Bill runs are set up using the Scheduler. Several billing schedules for
run to print different customers or groups of customers can be set up.
invoices or A new bill run schedule (that is, not completing an earlier run) uses one
statements of the following supported schedule types:
• Standard Bill Run, which generates an invoice that is sent out to
customers.
Note: The Customer Batch Size (a bill run parameter) controls
the number of customers that are passed to each bill run operation
in turn. Setting this number will determine how many customer
invoices are produced at a time. For more information, refer to
Chapter 3, Billing.
• Quality Assurance Bill Run, which generates a temporary bill
that is not sent to the customer and not paid; this can be used for
quality assurance purposes and quoting. This bill run does not
execute the 'Print Invoices' operation by default.
To ensure that the schedule actually prints invoices, the 'Print Invoices'
operation must be selected in the schedule parameters.
For more information on setting up schedules, refer to Chapter 6,
Scheduling Server Tasks.
Printing In order to print bulk invoices from a bill run that has already been
invoices on a completed, the following steps must be performed:
previously- 1. Select the Server Tasks ➩ Bill Runs option.
completed bill
run 2. Use the Bill Run Search form to select the correct bill run.
3. Once the Bill Run Detail form is open, click the Perform
Operation… button. The resulting window displays details of
the last operation and a list of available operations that can be
executed on the bill run.
4. Select 'Print Invoices' from the list of available operations.
5. Click the Submit button. The One-off Task form is displayed
with the appropriate task already filled out for that particular bill
run.
6. Ensure that the Customer Batch Size parameter is
appropriately set. This parameter determines the number of
customers that are processed at a time.

Batch Printing
The graphic below displays the window for performing additional

operations on a bill run.
Figure 4–1 Perform Operations on a Bill Run
Single invoice In order to print invoices for a single customer (from a bill run that is
printing complete), the following steps must be performed:
1. Open the Customer Detail form for the specified customer.
2. Click the Bill Run Details… button on the Billing tab.
3. Select the correct bill run, and click the Perform Operation…
button.
4. Select 'Print Invoices' from the list of available operations.
5. Click the Submit button. The One-off Task form is displayed
with the appropriate task filled out for that particular bill run.

Batch Printing
Printing Document Images
This section describes the steps required to prepare for printing and
checking the output.
Preparation for The following conditions should be met before billing output can begin
printing (each site may have additional requirements):
• The number of documents awaiting output is established. This
information can be obtained from the Results tab of the Task
Detail form for the task that generated the document images.
• Required reports are produced and analysed, and any problems
rectified.
• Any required legal or financial procedures are performed.
• Printers are configured, online, and containing sufficient and
correctly loaded stationery.
• Other forms of output device, such as disk or tape, are online,
ready, and contain sufficient storage for data volume. Factors
that affect storage include:
− Number of documents
− Average number of pages in each
− File format used
− Presence of bitmaps or other large elements in the
document
− Average level of compression achieved on files of this
type.
• Special arrangements made for subsequent processing of
documents (folding, putting in envelopes, posting, and so on).
An unsuccessful billing output run can be expensive; it can cause delays
in the billing process and subsequent collection of payments from
customers.
Checking the The following quality checks should be made before printed dunning
output letters can be accepted (each site may have extra requirements):
• Have all the expected documents been printed? ]
• Is the output quality acceptable? Are the documents clean,
legible, and is the print properly aligned on the paper?
• Is the static information shown on the documents, such as the
company logo and address, correct?

Batch Printing
• Do selected documents match the data in the database?

• Are there any extra procedures required at this stage? If so, have
they been carried out successfully?
Configuring Output Processing for the GOP
The output of the GOP reflects batch-oriented billing. The GOP is

executed once per batch and this execution is repeated for each and every
batch. GOP Output is controlled by the output method selected as a
parameter for the task. The output method consists of:
• An output method type, which defines the database views used to
retrieve the data for output, and also defines any changes that the
output process is to make to the database (for example, to set a
'Printed' indicator in the invoice table).
• One or more output devices, which specify, by means of UNIX
commands, the device to which output is directed.
If an output method is given more than one output device, then
each device operates on a part of the output, specified by an SQL
WHERE clause. Each section of the data can be sorted using its
own SQL ORDER BY clause.
This means that an output method can be configured to print
invoices for customers in the local area to a local printer, and
invoices for customers in other regions are spooled to magnetic
tape for processing by a print vendor. In either case, the invoices
could be produced in postal code order, if any bulk posting
arrangements are required.
Output method The output method type defines the source of the data that is printed. It
type can also update a database table, for example to set a flag showing that an
invoice has been printed. All types can be configured with an image type
of .spf, .tex, .txt, or .xml. Each of these (excluding .spf) can also
be compressed using the .gz or the .Z format.
The options provided with Convergent Billing are shown in Table 4–1

Batch Printing
Table 4–1 Singl.eView Convergent Billing Output Method

Types
Name Description
Print Print invoices from an invoice run.
invoices Updates the INVOICE table.
Print Print dunning or promotional letters.
dunning Updates the
letters CUSTOMER_NODE_CORRESPOND table.
Reprint Reprint flagged invoices. Updates the
invoices CUSTOMER_NODE_CORRESPOND table.
Output method types can be defined or updated when the underlying

tables and appropriate access privileges are thoroughly understood. The
following example uses the standard 'Print Invoices' output method type
for illustration.
Output device The output device defines the UNIX command used to send the output to
the required device. A knowledge of UNIX, the Convergent Billing
environment, and device configuration are required in order to work with
output devices.
The output device includes the following information:
• The Output Image Type, which defines the format of the image
stored in the database.
• A Start Command, which is an optional UNIX command that is
executed before a batch of images is output. The Start command
can be used, for example, to instruct the printer to select the
correct stationery.
• An optional Stop Command, which is an optional UNIX
command that is executed once each batch is completed.
The Stop command can be used, for example, to advise an
operator that the batch print has finished. The Stop command can
also be used to track the batch number, or where in the entire run
a particular batch happens to be.
• A Run Command. The two options Pipe images to run
command? and Concatenate Images? are processed in
conjunction with this option. The possible outcomes are
specified in Table 4–2.

Batch Printing
Table 4–2 Pipe and Concatenate Options
Option Selected Result

Concatenate The Run command is executed after all
images in the batch have been concatenated
into $file.
Note: The only file type that can be
concatenated is .txt.
Pipe The output image is piped to the Run
command.
Both The same as Pipe, except that the pipe is not
closed and re-opened between images.
Neither The Run command (taking $file as an
argument) is executed after each image is
output.
Scripts for Two shell scripts are available for printing control:
output • print_inv <texfile> <output_file>
This script takes an uncompressed TEX file containing a
document and generates a PostScript output file. If the TEX input
file is specified as - the script reads TEX source from the
standard input. If the output file is specified as - the script sends
the PostScript to the standard output. If an output filename is not
given, it is generated from the TEX file name by replacing .tex
with .ps.
• smb_lpr [-P <printer>] <file1> <file2> ...
This script sends files to a printer using the smb protocol. If the
printer is not named, the environment variable $PRINTER is
used. If this variable is not set, the script exits with a failure. If
no files are named on the command line, the standard input is
copied to the printer.
The script uses the two environment variables SMBHOST and
SMBCLIENT to name the printer host and path to the smbclient
executable respectively. Default values are supplied for each.
The GNU Samba suite must be installed on the server for this
command to work.
Note: Samba may not be available on site.

Batch Printing
Output device Example 1: PostScript output through Samba to printer

examples
The Run Command is executed after each image has been output to the
default file ($file). The image is decompressed by zcat, converted to
Postscript by print_inv and printed using the smb protocol on the
network printer named local_printer.
Example 2: Text output concatenated to file
The text output of all images sent to the GOP is concatenated in the
default output file ($file), which is then copied as file concat_file;
this might be useful if a single text file is transmitted to another location.

Batch Printing
Note: The only Convergent Billing output file format that can be
concatenated is .txt.
Example 3: Images piped to the null device using cat
Images are piped to the cat command, which is redirected to the null
device. This may be used if all images are not being printed out.
Example 4: Postscript images archived using tar
This example shows:

• A Start command being used to create a subdirectory temp
within the current directory (the process needs authority to create
and delete directories and files).

Batch Printing
• A Run command to copy PostScript versions of each file in the

GOP output to that directory.
• A Stop command that executes the following once the batch is
completed:
− Archives the directory and its contents in the default tar
output device (normally tape).
− Empties the temp directory.
− Removes the temp directory.
If files are sent to a print vendor for printing, this procedure can be
followed.
Note: When the GOP creates multiple output files, each is given a
unique filename by appending a sequence number to the default name
(task_id_<seq_nr>.<ext> where <task_id> is the ID of the task,
<seq_nr> is a unique sequence number and <ext> is the extension for
files of this type).
Output method An output method is an object that brings together the various elements
definition required for printing. It allows selection of the order in which the output
is printed; for example, invoices printed by state and by postal code can
be chosen for ease of posting. Different output devices for different sets
of invoices can be selected; for example, a different printer for each state
or region can be used.
The output method is a GOP parameter that needs defining when
scheduling printing tasks.
Output method This example output method shows how the fields can be used:
example

Batch Printing
In this example, local invoices (postal_code >= 4000 AND

postal_code < 5000) are printed locally, while others (specified in
the WHERE clause for the second line of the grid) are sent to a tar
archive device. Printed invoices are ordered by postal code and customer
ID. Any invoice images not printed locally or archived are discarded, as
specified in the default output device (null).

Part 2
The Transaction Engine
This part provides information on operational aspects of the Convergent

Billing Transaction Engine, used to interface Convergent Billing with
other applications. This part consists of the following chapter:
• Chapter 5, The Transaction Engine (TRE)
Information about configuring transactions is given in the System
Administration Guide.
white text
Chapter 5
The Transaction Engine (TRE)
The Transaction Engine (TRE) is a Convergent Billing component that

manages client/server transactions. Convergent Billing uses a four-tier
architecture, in which clients connect to the server by means of the
Transaction Engine (TRE), which uses TUXEDO middleware.
• Clients, remote hosts, and external applications form the first
tier, using a workstation or remote functions to enter, inspect,
and modify data, and initiate processes.
• The second tier consists of the system's expression-driven
configuration and the Transaction Engine (TRE). Configuration
is used to reflect the customer's individual business logic. This
tier manages transactions initiated from the first tier and returns
results to the first tier.
• The third tier contains both the Convergent Billing processes and
the TRE services that clients can use for core business functions.
In addition, an Application Programming Interface (API) is
available to provide other applications with access to TRE
functionality.
• The fourth tier in the Convergent Billing architecture is the
Oracle database, in which business and administrative data is
stored.
The basic architecture is shown in Figure 5–1.

The Transaction Engine (TRE)
UNIX shell, External

Remote hosts Applications
Workstations 1st tier:

Presentation
2nd tier:
Configuration Configuration/
Business Logic
TRE
Transaction
Engine
Server
Services
Processes
3rd tier:
Core Engine
ORACLE
Database
4th tier:
Data Repository
Figure 5–1 Singl.eView Convergent Billing Four-tier

Architecture
TRE functions are used when writing functions and expressions (for more

Part 3
Task Automation
This part provides information on using the Scheduler to automate server

tasks, and on the types of schedule which can be defined. This part
consists of the following two chapters:
• Chapter 6, Scheduling Server Tasks
• Chapter 7, Schedule Types
white text
Chapter 6
Scheduling Server Tasks
Most server tasks in Convergent Billing are run automatically, under the
control of the Scheduled Task Dispatcher (STD) process and the Task
Launch and Monitor (TLM) process. The client workstation's scheduling
features are used to control these processes, collectively referred to as the
Scheduler.
The Scheduler is used to set up tasks that run regularly at pre-defined
intervals, or tasks that run only once, either immediately or at a date and
time chosen. Once set up, these tasks run automatically at the chosen
time without further intervention, and then notify the user on completion.
When setting up a schedule, an instance of Convergent Billing can be
specified to run the schedule. If an instance is not specified, the schedule
is run on the default instance defined for the Scheduler. (The default
instance is defined in the STD Configuration Item.)
This chapter describes how to define and modify schedules, and to
monitor the tasks created by the schedules.

Scheduling Overview
A schedule specifies:
• When a task is run for the first time.
• The instance on which the task is run.
• How often the task should be repeated, and at what intervals.
• What program the task runs to perform its function, and what
parameters are passed to it.
When a schedule is defined and submitted, Convergent Billing creates
one or more tasks that are queued until the date and time specified, when
they run automatically. On completion of each task, a message is sent so
the user can verify that the task executed successfully.
Figure 6–1 shows a schedule and its tasks in diagrammatic form.
Time
Schedule Now
Effective date
Task 1 First date

Interval
Effective date
Task 2 Task date
Effective date
Task N Task date
Last date
Figure 6–1 Schedule and Tasks

Terms used in The following terms are used when defining a schedule:
scheduling Schedule Name
Each schedule has its own schedule name.
Description
A schedule may optionally be given a textual description.
Schedule Type
Every schedule is assigned a schedule type which defines the type of task
to create, the program that the schedule tasks runs, what parameters are
required, and similar information (for more information, refer to Chapter
7, Schedule Types).
Instance Name
A schedule can optionally be given an instance name. By specifying an
instance name, tasks associated with the schedule can be run on a specific
instance of Convergent Billing. If an instance is not specified, the task is
run on the default instance defined for the Scheduler. The default
instance is defined in the STD Configuration Item. The Instance Name
field will be enabled only if the reference type ATA_INSTANCE
contains more than 2 rows.
Email Address
A schedule may optionally be given an email address that is notified
when tasks associated with the schedule are completed.
Schedule Status
A schedule can be either 'Active' or 'Complete'. An active schedule
creates tasks as required; a complete schedule is effectively turned off,
and cannot create tasks.
Preschedule Count
Defines the number of advance tasks that the scheduler maintains; for
example, if the schedule calls for a task at monthly intervals with a pre-
schedule count of five, then five tasks are created when the schedule is
submitted. A new task is generated whenever the earliest one completes,
keeping the number of advance tasks at five, until the last date is reached.
First Date
Start date and time for the first task; if this is earlier than the date and
time on which the schedule is submitted, then the first task runs
immediately.
Last Date
Last date for which a task is created; the schedule's status then changes to
'Complete'. If the last date is not defined, the schedule continues
indefinitely.

Effective Date
Effective date is the date and time used by some tasks to retrieve
information from the database; for example, a billing task may be
required to run in early September, but using the data for August. In this
case, the effective date would be set to 31st August.
Repeat Units
Multiplier to use in conjunction with the repeat type; for example, a
repeat type of Month Day and a repeat unit of 2 means that tasks are
scheduled every two months.
Repeat Type
Repeat interval for creating future tasks, such as day, week, or month;
this is used in conjunction with the defined repeat unit (n in the following
examples). The repeat types available are:
• Second – every n seconds.
• Minute – every n minutes.
• Hour – every n hours.
• Day – every nth day at the start time.
• Week – every nth week.
• Month Day – every nth month, on the same day of the month as
the start date.
• Month End Day – every nth month, using the same number of
days from the end of the month as the start date.
• Month Start – every nth month, on the same day of the same
week as the start date.
• Month End – every nth month, on the same day of the same week
as the start date, calculated back from the end of the month.
Task Start Date
Date and time at which a task is started. For the first task in the schedule,
this is the same as the first date (unless the first date has already passed
when the schedule is submitted, when the task starts immediately);
thereafter, the first date and the repeat factors control the start date.
Task Effective Date
Date and time that may be used by the task to retrieve data from the
database, depending on the processing required by the task. For the first
task in the schedule, this is the same as the schedule's effective date;
thereafter, the task effective date is controlled by the schedule's effective
date and the repeat factors.

Working with Schedules
The following sections describe how to work with schedules. The topics
covered are:
• Submitting a schedule
• Re-submitting a task
• Changing the frequency of a schedule
• Deleting a schedule.
The schedules required may have been defined when Convergent Billing
was installed. Before a new schedule is defined, check whether there is
an existing schedule or one that can be modified to fit requirements.
Submitting a Before a new schedule is defined, ensure that there is an existing

schedule schedule or one that can be modified to fit requirements. Schedules are
defined, maintained, and modified using the Schedule Definition form.
Re-submitting a A task with a 'Completed' status can be resubmitted by clicking the Re-
task submit button on the Task Detail form. A pop-up message asks for
confirmation.
This action sets the task status back to 'Pending' without changing the
start date. When the STD receives the re-submitted task, it finds that the
start date is in the past, and therefore schedules the new task immediately.
A task for execution at some future time can also be resubmitted by using
the Update button on the toolbar to modify the information on the
Details tab, including the Start Date and Effective Date entries.
Changing the Changing frequency can cause complications if a large number of tasks
frequency of a are pending for the old frequency. To minimise the number of pending
schedule tasks and prevent complications, use a preschedule count of 1 when
defining schedules.

Deleting a A schedule that is no longer required can be deleted, but any pending
schedule tasks will also be deleted. All tasks must be completed before deleting
the schedule.
At some future time, a particular schedule may be required. It is

advisable to stop the schedule, rather than delete it.

Chapter 7
Schedule Types
A schedule task uses the schedule type to determine what program to run
and how to run it. The schedule type also defines the parameters that the
user needs to provide when a schedule of this type is defined.
This chapter describes the schedule types provided with the Convergent
Billing base installation, including the server command that the task
executes, and any parameters required. It also provides information on
defining new schedule types.
To define a schedule type, it is necessary to have:
• Appropriate access privileges in Convergent Billing.
• A good understanding of the working of the program that the
schedule type runs, including:
− Any required command line options.
− Any parameters the user needs to pass.
• An understanding of reference types, attribute types, and entity
validation, required for the definition of user parameters (for
more information, refer to the Customer Care Configuration
Guide).
Note: The server commands are included for reference information only.
For more information about the server command parameters, refer to the
manual System Administration Guide.

Schedule Types
Table 7–1 lists the schedule types supplied with the Convergent Billing
base installation; report schedule types are not included (for more
information on these, refer to the Reports Guide).
Table 7–1 Schedule Types Summary
Schedule Type Description

Apply & Allocate Applies invoices for a specific bill run and
Invoices allocates credit payments and
adjustments.
Apply & Allocate Applies invoices for a specific customer
Invoices for and allocates credit payments and
Customer adjustments.
Apply Invoices Applies invoices for the last bill run on the
specified bill cycle schedule.
Apply Invoices for Applies invoices for a specific customer.
Customer
Apply Transactions Applies future dated payments and
adjustments.
Archive Archives selected tables and other data.
Billing Suppress Suppresses invoice generation for
customer hierarchies, causing these
hierarchies to be skipped by schedules
running types such as 'Complete Bill
Run'.
Billing Unsuppress Halts suppression of invoice generation.
part thereof that has previously been
for Customer part thereof that has previously been
interrupted, failed, or revoked for a
specific customer.
Contract Cancel / Cancels expired contracts and/or
Notify generates expiry warnings.
Create Partitions Creates a set of partitions in the CHARGE,
NORMALISED_EVENT, or
SUBTOTAL_RATING_VALUE table.
DIL Validation Validates DIL definitions.
Dunning Letter Generates letters for customers with
Generation overdue invoice payments.
ECP Command Executes an expression.

Schedule Types

Explain BGP Generates an explanation of the
Hierarchy Passes customer hierarchy passes the BGP
performs on the specified customers.
Full Database Runs the full database validation process.
Validation
General Bulk Output Run the General Bulk Output Process by
By Task task ID.
General Bulk Output Generates output for a previous schedule
Process (bill run, dunning generation, or invoice
re-print).
Images bill run.
Customer
Invoice Generate Generates the invoice image for a single
Image invoice.
Invoice Print Image Prints or re-prints the image of a single
invoice.
Invoice Reprint Generates the data required to reprint a
Generation set of invoices. The GOP must be run on
a separate schedule to re-print the
invoices.
Invoice View Image Generates the viewing image file in any
supported format for the source file
specified by the Invoice ID.
Partition Runs the Table Partition Maintenance
Maintenance schedule.
Print Invoices Prints invoices for a specific bill run.
Print Invoices for Prints an invoice for a specific customer.
Customer
Purge Error Events Purges error events using selection
criteria.
Purge Events (non Purges normalised events and charges,
Error) using selection criteria.
Purge Files Deletes files from a given directory older
than the specified date.
Quality Assurance Creates and executes a QA bill run for a
Bill Run set of customers associated with a given
schedule.

Schedule Types

Rate Files Rates files in an ENM's data directory
that are older than the effective date.
Re-analyze tables Re-computes optimiser statistics for all
tables.
Re-rate Error Events Re-rates a set of error events that have
been assigned to a file for re-rating.
Re-rate Error Events Re-rates a set of error events using
(bulk) selection criteria.
Re-rate Events Re-rates a set of normalised events and
(bulk) charges using selection criteria.
Re-rate File Re-rates the set of events from a
normalised event file that were
successfully rated.
Reconfigure Auditing Re-generates triggers based on the
specification of all AUDIT_TABLE
configuration items.
Reprocess Error Reprocesses error events associated with
Events real-time rating feeds that use rating
subtotals.
Reprocess Events Reprocesses normalised events that
have associated rating subtotals.
Revoke Bill Run Revokes a standard bill run, QA run, or
part thereof.
Revoke Bill Run for Revokes a bill run for a specific customer.
Customer
Revoke Event File Revokes all normalised events, error
events, and charges for a file. The file
remains in the archive directory.
Revoke File and Revokes all normalised events, error
move back events, and charges for a file, and
replaces the file in the data directory.
Revoke Invoice Deletes all invoice images for the last bill
Images run in the specified bill cycle schedule.
Revoke Invoice Revokes invoice images for a specific
Customer
Revoke Invoice Print Revokes invoice print settings.
Settings
Revoke Invoice Print Clears the print setting for all invoices on
Settings for the specified schedule, so that the entire
Customer bill run can be printed again.

Schedule Types

Revoke Invoices Deletes all invoices generated in the last
bill run for the specified bill cycle
schedule.
(keep Rentals) rental events, for a specific bill run.
(keep Rentals) for rental events, for a specific customer.
Customer
Revoke Invoices for Revokes invoice images, invoice details,
Customer and rental events for a specific customer.
Events
Revoke Rental Revokes rental events for a specific
Events for Customer customer.
Revoke Revokes a reprocessed file and un-
Reprocessed File assigns all normalisation error events
associated with it.
Rotate Partitions Updates partitions to archive old data,
and allocate partitions for new data.
Standard Bill Run Creates and executes a standard bill run.
Switch Files Renames files in a given directory and
matches a given file pattern.
UnApply & De-allocates any credit payment and
Deallocate Invoices adjustment amounts.
UnApply & De-allocates any credit payment and
Deallocate Invoices adjustment amount for a specific
for Customer customer.
UnApply Invoices Un-applies invoices.
UnApply Invoices for Un-applies invoices for a specific
Customer customer.
Unarchive Recovers archived data.
Update Account Validates and updates the unbilled
Unbilled amount of an account.
Note: This script should only be run
when there is no rating activity on the
system, otherwise accounts may be
updated incorrectly.

Schedule Types

Update Charge Generates new charge categories for any
Categories services or customer nodes that need
them. Only needs to be run if new
charge categories are assigned to
products that are in use.
Update Invoice Validates and updates the unbilled
Unbilled amount of an invoice.
Update Lists Generates new empty derived attribute
arrays for any services or customer
nodes that need them. Only needs to be
run if new derived attributes are assigned
to products that are in use.
Verify Charge Verifies and updates details on charges
Partition stored in the CHARGE table.
Verify Charge Verifies that the specified partitions fall
Partition Range within a specified date range.

Schedule Types
Schedule Type Details
This section describes schedule types provided with the Convergent

Billing base installation; report schedule types are not described (for
more information on these, refer to the Reports Guide).
The following conventions are used when describing the type of
parameters:
List
Select the required value from a drop-down list.
Text
Enter a text value in upper or lower case as required.
TEXT
Enter a text value in upper case only.
Integer
Enter a whole number.
Yes/No
Select either 'Yes' or 'No' from a drop-down list.
[Data Type]
Data types enclosed in square brackets are optional.

Schedule Types
Apply & Allocate This schedule type applies invoices for a specific bill run and allocates
Invoices any credit payments and adjustments.
Server command
bill_run_wrapper –c 50 60 40
Schedule Type Parameters

Parameter Type Description
Bill Run Id Integer Identifier of the bill run for which
this operation is being
performed.
Customer Batch Integer Maximum allowable number of
Size root customer nodes to be
processed by a single process at
any given time.
Number of Child Integer Number of child processes to
Processes handle the customer batches.
Error Threshold Integer Maximum number of customers
with errors. The bill run will fail
once it reaches or exceeds this
number.

Schedule Types
Apply & Allocate This schedule type applies invoices for a specific customer on a bill run,
Invoices for and allocates any credit payments and adjustments.
Customer
Server command
bill_run_cust_wrapper -c 50 60

performed.
Customer Node Id Integer Identifier of the customer for
which this operation is being
performed.

Schedule Types
Apply Invoices This schedule type applies invoices for the last bill run on the specified
bill cycle schedule.
Server command

performed.
any given time.
number.

Schedule Types
Apply Invoices This schedule type applies invoices for a specific customer on a bill run;
for Customer invoice allocation is not performed.
Server command
bill_run_cust_wrapper –c 50 50

Bill Run Id Integer Identifier of the bill run for
performed.
performed.

Schedule Types
Apply This schedule type applies future-dated payments and adjustments, and is
Transactions able to re-calculate multi-currency transactions using current exchange
rates.
Server command
apply_transactions

Rederive Multi- List Set to ‘Yes’ if multi-currency
Currency transactions are to have their
Transactions amounts and allocations re-
calculated, based on the current
exchange rates. Otherwise, set to
‘No’.
Notes
If multi-currency transactions are newly calculated and re-inserted, the
invoice and RT allocations are performed automatically. Multi-currency
payment transactions having associated payment items are NOT re-
inserted under these conditions.

Schedule Types
Archive This schedule type archives selected tables and other data.
Server command
client_archive

Archive Type List List of archive types.
Archive file Text Name of the archive export file.
name
Purge data? Yes/No Select 'Yes' if the data is to be
purged after it is archived.
Rows per [Integer] Number of rows inserted or
commit updated before a commit. If not
specified, the commit is on a
table-by-table basis.
Where Clause [Text] SQL WHERE clause for selecting
data.
Delete existing Yes/No Select 'Yes' to delete any existing
archive data? archive data before starting this
archive.
Archive [List] Select the desired archive data.
Format
Report missing Yes/No Select 'Yes' to report missing
data? data.
Prevent Yes/No Select 'Yes' to prevent duplicate
duplicate data.
data?
Other archive [Text] Enter any other archive flags not
flags directly supported by prompts.
Archive Sub- [List] List of archive sub-types.
type x 4

Schedule Types
Billing Suppress This schedule type suppresses invoice generation for the specified
customer hierarchies, causing these hierarchies to be skipped by
schedules using types such as 'Standard Bill Run', 'Quality Assurance
Bill Run', and 'Complete Bill Run'.
Server command
billing_suppress

Suppress Until Date The date on or after which invoice
Issue Date generation will recommence.
Suppress Bill Integer The number of bill cycles for
Cycle Count which invoice generation will be
suppressed.
Customer [Text] Customer hierarchies having one
Node Name or more customers with a name
matching this pattern.
Customer [List] Customer hierarchies having one
Node Type or more customers with a node
Name type name matching this name.
Account Name [Text] Customer hierarchies having one
or more prime account names
Account Type [List] Customer hierarchies having one
Name or more prime accounts of this
type.
Service Name [Text] Customer hierarchies having one
or more services with a name
Network Name [Text] Customer hierarchies having one
or more services with a network
name matching this pattern.
Service Type [List] Customer hierarchies having one
Name or more services of this type.
Where Clause [Text] Additional selection criteria in the
form of an SQL WHERE clause
(minus the WHERE keyword),
based on the
CUSTOMER_NODE_TRE_V view.

Schedule Types
Notes
Only one of the two parameters, 'Suppress Until Issue Date' or 'Suppress
Bill Cycle Count', should be specified, in order to determine when
invoice generation should recommence. If both parameters are entered
and they do not match, the date parameter will be taken as default.

Schedule Types
Billing This schedule type removes any 'suppressions' of invoice generation for
Unsuppress the specified customer hierarchies.
Server command
billing_suppress -r -v

Customer [Text] Customer hierarchies having one
Node Name or more customers with a name
Customer [List] Customer hierarchies having one
Node Type or more customers with a node
Name type name matching this name.
Account Name [Text] Customer hierarchies having one
or more prime account names
Account Type [List] Customer hierarchies having one
Name or more prime accounts of this
type.
Service Name [Text] Customer hierarchies having one
or more services with a name
Network Name [Text] Customer hierarchies having one
or more services with a network
name matching this pattern.
Service Type [List] Customer hierarchies having one
Name or more services of this type.
based on the

Schedule Types
Complete Bill This schedule type completes a standard bill run, quality assurance run,
Run or part thereof that has previously been interrupted, failed, or revoked.
Server command
bill_run_execute -c

Bill Run Id Integer ID of already-scheduled bill run.
From List Start of range of failed/interrupted
Operation billing run.
To Operation List End of range of failed/interrupted
billing run.
Prerequisite List Prerequisite billing operation. If
Operation this operation lies outside of the
range of the 'To' and 'From'
operations, then only customer
nodes for this bill run which have
successfully completed this
operation (taking into account any
revoking) will be eligible.
Customer Integer Maximum allowable number of
Batch Size root customer nodes to be
any given time.
Number of Integer Number of child processes to
Child handle the customer batches.
processes
Error Integer Maximum number of customers
Threshold with errors. The bill run will fail
number.
using fields from the

Schedule Types
Complete Bill This schedule type completes a standard bill run, quality assurance run,
Run for or part thereof that has previously been interrupted, failed, or revoked for
Customer a specific customer on a bill run.
Server command
bill_run_cust -c

Bill Run Id Integer Identifier of the already
scheduled bill run.
performed.
From Operation List Start of the range of
failed/interrupted bill run.
To Operation List End of the range of
failed/interrupted bill run.

Schedule Types
Contract This schedule type cancels expired contracts and/or generates expiry
Cancel/Notify warnings.
Server command
update_contracts

Contract Type List Contract type to be cancelled or
notified.
Cancel Yes/No Select 'Yes' to cancel contracts
Expired that have expired.
Contracts?
Cancellation Text Notification function used to
Notification generate cancellation messages.
Function
Re-negotiate Text Notification function used to
Notification generate renegotiation messages.
Function
Expiry Text Notification function used to
Notification generate expiry messages.
Function
Repeat Integer Number indicating how often
Frequency contract notification messages are
generated.
Repeat Unit List Time unit indicating how often
contract notification messages are
generated.
Max Errors Integer Maximum number of errors to
ignore before task fails. If this
parameter is not entered, the
script will stop on the first error
encountered. If no message is
generated, no update will be
performed for that contract
(including cancellation where a
message function has been
specified).

Schedule Types
Notes
• All the parameters, other than -d <debugLevel>, are mandatory;
however, they are allowed to be empty.
• At least one of the Cancel Expired Contracts?, Re-negotiate
Notification Function, or Expiry Notification Function
parameters must be specified.
• The Cancellation Notification Function parameter can only be
passed if Cancel Expired Contracts? is set to 'Yes'.
• The functions specified by the Cancellation Notification
Function parameter, Renegotiate Notification Function
parameter, and Expiry Notification Function parameter must be
remote functions with an application environment of 'Any', a
context of 'Any', and take the following parameters:
– TaskQueueId&
– EffectiveDate~
– ContractId&.
• The default remote functions to generate cancellation
notifications, re-negotiation reminder, and expiry warnings are
biContractCancelNotice&(), biContractReneg&(), and
biContractExpiry&().
• All date checks and updates are done according to the effective
date passed to the script. The exception is setting of the reminder
dates and determining if a re-reminder is necessary, these are
done using the current date and time. When updating a contract
to cancel, the status is set to 'Cancelled' and the
EFFECTIVE_START_DATE is set to the effective date and time
passed.

Schedule Types
Create Partitions This schedule type creates a set of partitions in the CHARGE,
NORMALISED_EVENT, or SUBTOTAL_RATING VALUE table.
Server command
create_partitions

Table to List Select the table for which
partition partitions are to be generated.
Start date of Date Start date of the first partition to
first partition be created.
Number of Integer Number of partitions that are to be
partitions created.
Duration of Integer Duration of each created partition
each partition in the selected units.
Units List Units of duration for each created
partition.
The create_partitions script creates a set of entries in the partition

definition for the specified <base table> and does the following:
• Deletes any existing entry in the partition definition for the

specified <base table> (CHARGE, NORMALISED_EVENT, or
SUBTOTAL_RATING_VALUE).
• Generates <quantity> partitions for the base table with names
of <base_table>_P<partition_number> (where
<partition_number> starts at 1). The first partition is given
a FROM_CHARGE_START_DATE of <start_date>. All
partitions including the last are given a duration of <duration>
<units> (where <units> can be Days (0), Weeks (1) or
Months (2)). The last partition is given a
TO_CHARGE_START_DATE of 30/12/9999 23:59:29.
• The dbrebuild script is executed to re-generate table definition
scripts. If the environment is configured appropriately, (for
example, the ATA_PARTITION environment variable is set to a
non-zero value) this includes generating the SQL to create the set
of partitions specified by this script.

Schedule Types
Notes
For the partitions to be created, or recreated in the database, dbsync
must be executed from the command line. If there is a significant
quantity of data already in <base_table>, then this data should be
exported and <base_table> truncated prior to running dbsync. The
<base table> can then be imported into the newly created set of
partitions.
Sizing and tablespace information for these partitions and their associated
indexes is specified in $ATA_DATA_SERVER_CONFIG/ata_create.db.
This script is mainly designed for use on new database installations,
where partitioning is being used for the first time, or installations where it
has been decided to make major changes in the partitioning strategy (for
example, changing the duration and quantity of the number of partitions
in a table). For regular partition maintenance operations (dropping,
adding, and archiving partitions), the update_partitions script
should be used.
The last partition is deliberately not given an end date of the end of time
to allow for the efficient rotation of partitions. The end date of the last
partition should be some time in the future to minimise the risk of
receiving events for which there is no valid partition.

Schedule Types
DIL Validation This schedule type validates Data Interface Language (DIL) definitions.
The script is run internally by Convergent Billing when saving a modified
DIL definition, and should not be run at any other time.
Server command
dil

None.

Schedule Types
Dunning Letter This schedule type generates letters for customers with overdue invoice
Generation payments, but does not print the letters. Printing should be done by a
schedule of the 'General Bulk Output Process' or 'General Bulk Output by
Task' type.
Server command
dunning

Dunning List TEX template used for building the
Template letters.
Percentage [Integer] Unpaid percentage that triggers
Unpaid (%) the letter generation.
Days Overdue [Integer] Number of days overdue which
triggers the letter generation.
Extension List Select a file extension for the
output file used when creating the
report.

Schedule Types
ECP Command This schedule type executes an expression.
Server command
ecp_cmd

Expression Text Expression to be executed.

Schedule Types
Explain BGP This schedule type generates an explanation of the customer hierarchy
Hierarchy passes the BGP performs on the specified customer.
Passes
Server command
bgp_explain

Bill Cycle List List of all current billing cycle
Schedule schedules.
Customer Text Name of the customer in the
Node Name pass.

Schedule Types
Full Database This schedule type runs the full database validation process.
Validation
Server command
dvp

None.

Schedule Types
General Bulk This schedule type runs the General Bulk Output Process for a given task.
Output By Task For example, this type can be used to print invoice images marked for
reprinting or letters generated by the dunning process.
Server command
gop -q

Task Integer Task ID that specifies the
entities requiring bulk output.
Output Method List Specifies the output method,
such as invoice generation or
dunning letters. This is a
mandatory parameter.
Directory for Text Directory to store temporary
temporary data data and working files. This is a
mandatory parameter.

Schedule Types
General Bulk This schedule type generates output for a given previous schedule (bill
Output Process run, dunning generation, or invoice reprint).
Server command
gop

Schedule to List Schedule from which to select the
output last successful task for output.
Output Method List Output method to use (refer to
Chapter 4, Batch Printing).
Directory for Text Directory to store temporary data
temporary data and working files.

Schedule Types
Generate This schedule type generates invoice images for a specific bill run.
Invoice Images
Server command

performed.
any given time.
Error Threshold Integer Maximum number of customer
nodes with errors. The bill run
will fail once it reaches or
exceeds this number.

Schedule Types
Generate This schedule type generates invoice images for a specific customer on a
Invoice Images bill run.
for Customer
Server command

performed.
performed.

Schedule Types
Invoice This schedule type generates the invoice image for a single invoice.
Generate Image
Server command
generate_image

Invoice Integer Invoice ID needed as the argument
Identifier for the Invoice Viewing Process
module.
Sequence Integer Sequence number.
Number

Schedule Types
Invoice Print This schedule type prints or reprints the image of a single invoice.
Image
Server command
print_image

Identifier for Invoice Viewing Process
module.
Sequence Integer Sequence number.
Number
Output Device List Output device (printer).

Schedule Types
Invoice Reprint This schedule type generates the data required to reprint a set of invoices,
Generation using the original output method. The GOP must be run on a separate
schedule to reprint the invoices.
Server command
dunning -r

None.

Schedule Types
Invoice View This schedule type generates the viewing image file in any supported
Image format for the source file specified by the Invoice ID. This schedule type
is only used internally by Convergent Billing.
Server command
ivp

Identifier for the Invoice Viewing Process
module.
Number Integer Sequence number.
Output Image List Output Image Type.
Type

Schedule Types
Partition This schedule type runs the Table Partition Maintenance schedule.
Maintenance
Server command
update_partitions

Archive Text Directory in which archived files
Directory are placed.
The update_partitions script is used to update a set of partitions in

accordance with the specified operations in the partition definitions. The
script operates on rows in the partition definition that have the
SCHEDULE_ID associated with <task_queue_id>, an
OPERATION_OUTCOME_CODE of pending (1), and either the specified
TASK_QUEUE_ID or a TASK_QUEUE_ID of null.
Partitions with a REQUIRED_OPERATION_CODE specified have that
operation performed. If both archiving and truncating are requested, then
archiving is performed prior to truncation. The
REQUIRED_OPERATION_CODE is cleared on completion.
Partitions with a DESIRED_STATUS_CODE different from their
ACTUAL_STATUS_CODE and a DESIRED_STATUS_CODE of 'Dropped'
require the following steps to be performed:
• The contents of the partition are exported into a temporary export
file, if they were not previously archived.
• The partition is dropped.
• The contents of the partition are imported back into the table,
only if they were not previously archived.
• The temporary export file, if any, is removed.
• The ACTUAL_STATUS_CODE is set equal to the
DESIRED_STATUS_CODE, and all date fields are cleared.
The remaining pending partitions are processed in order of their
DESIRED_TO_CHARGE_START_DATE, with the newest partition being
processed first.
For each partition processed, the following steps are performed:
• If the partition is not new, its contents are exported into a
temporary export file.
• If the partition is not new, it is dropped.

Schedule Types
• If this partition does not have the highest

TO_CHARGE_START_DATE, then a Split Partition command is
generated for the next partition with a value equal to the
DESIRED_TO_CHARGE_START_DATE of the current partition. If
the partition is the last, then an Add Partition command is
generated.
• The contents of the old partition are imported back into the table.
• All local indexes on the split partitions (or added partition) are
renamed, their storage characteristics altered appropriately, and
the indexes rebuilt.
• The actual dates and status are set to equal the desired dates and
status.
The dbrebuild script is executed to regenerate the partition definition
scripts. If the environment is configured appropriately, (for example, the
ATA_PARTITION environment variable is set to a non-zero value) this
will include generating the SQL to create the set of partitions as specified
by their current actual status.
The OPERATION_OUTCOME_CODE is updated to 'Running' and
TASK_QUEUE_ID updated to <task_queue_id> during each operation
on a partition. The OPERATION_OUTCOME_CODE is then set to:
• 'Success' (3) if all operations were completed successfully
• 'Pending' (1) if the current operation completed successfully but
more are outstanding
• 'Failure' (4) if the current operation failed.
The script stops processing on the first failure.
Progress and timing information for this script are sent to the standard
output.
Caveats
Oracle's import command can output numerous warnings during an
import of a partition. All warnings about entities already existing can be
ignored.
The update_partitions script uses the exit code from the import
command to check for success or failure; therefore, it is possible that data
may not have been imported successfully, but the update_partitions
script continues processing. For this reason, it is recommended that
archives of data be performed prior to changes that require the data to be
exported and re-imported.

Schedule Types
Print Invoices This schedule type prints invoices for a specific bill run.
Server command

performed.
any given time.
number.

Schedule Types
Print Invoices This schedule type prints invoices for a specific customer on the bill run.
for Customer
Server command

performed.
performed.

Schedule Types
Purge Error This schedule type purges normalisation error events, using selection
Events criteria.
Server command
reprocess_bulk_assign –p

ENM Process [List] ENM process used to process the
purged events.
Native File Type [List] Normalised event file type used to
purge the events.
File Process [Date] Earliest file processing date for
Start Date selecting files.
File Process [Date] Latest file processing date for
End Date selecting files.
Base Event File [List] Original source file for events to
Name be purged.
Event Start Date [Date] Earliest event start date for events
to be purged.
Event End Date [Date] Latest event end date for events to
be purged.
Error Message [List] Error message identifier for events
Id to be purged.
Event Source [Text] Switch or mediation system that
originated the events for purging.
Event Type [List] Normalised event type of the
events to be purged.
File Type [List] Normalised event file type of the
File Record [Integer] File record number of the first
Start Nr event to be purged.
File Record End [Integer] File record number of the last
Nr event to be purged.
C Party Id [Text] Chargeable party whose events
are to be re-rated.

Schedule Types

Event Where [Text] SQL WHERE clause on the
Clause NORMALISED_EVENT_ERROR table
to select events to be purged.
File Where [Text] SQL WHERE clause on the
Clause NORMALISED_EVENT_FILE table to
select events to be purged.

Schedule Types
Purge Events This schedule type purges normalised events using selection criteria.
(non Error)
Server command
reprocess_bulk_assign –n –p

ENM Process [List] ENM process used to process the
purged events.
Native File [List] Normalised event file type used to
Type purge the events.
Start Date selecting events for purging.
End Date selecting events for purging.
Base Event [List] Original source file for events to be
File Name purged.
Event Start [Date] Earliest event start date for events to
Date be purged.
Event End [Date] Latest event end date for events to
Date be purged.
Tariff [List] Tariff used to rate the events to be
purged.
Event Type [List] Normalised event type of the events
to be purged.
File Record [Integer] File record number of the first event
Start Nr to be purged.
File Record [Integer] File record number of the last event
End Nr to be purged.
C Party Id [Text] Chargeable party whose events are
to be re-rated.
Clause NORMALISED_EVENT table to select
select events to be purged.

Schedule Types
Purge Files This schedule type deletes specified files older than the task's effective
date from a given directory.
Server command
purge_files

Directory Text Directory to be purged.
File Pattern Text File pattern of files to be removed.

Schedule Types
Quality This schedule type creates and executes a quality assurance bill run for a
Assurance Bill set of customers associated with a given schedule.
Run
Server command
bill_run_execute -q

Bill Run List Type of bill run, which defines the
Type(QA) run’s accessible list of operations.
Schedule List Associated schedule ID for bill run
to be checked.
From List Starting operation code for bill run.
Operation
To Operation List Ending operation code for bill run.
Customer Integer Maximum allowable number of root
Batch Size customer nodes to be processed
by a single process at any given
time.
Processes
number.

Schedule Types
Rate Files This schedule type rates files in an ENM's data directory that are older
than the task effective date.
Server command
rate_files

ENM Process List Number of the ENM process to be
used for rating.
File Pattern Text File pattern to match.
ENM File Type List Normalised event file type of the
event file.
ENM Event List Normalised event type of the
Type events to be processed.
Event Source Text Event source to associate with the
event.

Schedule Types
Re-analyze This schedule type recomputes optimiser statistics for all tables.
tables
Server command
dbanalyze

None.

Schedule Types
Re-rate Error This schedule type re-rates a set of error events that have been assigned
Events to a file for re-rating.
Server command
reprocess_file_events -r

Re-rated file Text File name of the file to be re-rated.
name
ENM Process List Number of the ENM process used
for rating.
Native File List Normalised event file type to use to
Type re-rate the event.

Schedule Types
Re-rate Error This schedule type re-rates normalisation error events, using selection
Events (bulk) criteria.
Server command
reprocess_bulk_assign

ENM Process List ENM process to use for rerating the
events.
Base Event [List] The original source file for events to
File Name be re-rated.
Event Start [Date] Earliest event start date for events
Date to be re-rated.
Date be re-rated.
Error [List] Error message identifier for events
Message Id to be re-rated.
to be re-rated.
events to be re-rated.
Start Nr to be re-rated.
End Nr to be re-rated.
CPartyId [Text] Chargeable party whose events are
to be re-rated.

Schedule Types

Clause NORMALISED_EVENT_ERROR table to
select events to be re-rated.

Schedule Types
Re-rate Events This schedule type re-rates normalised events and normalised error
(bulk) events, using selection criteria. All charges are regenerated.
Server command
reprocess_bulk_assign –n

ENM Process List ENM process to use for rerating the
events.
Base Event [List] Original source file for events to be
File Name re-rated.
Event Start [Date] Earliest event start date for events
Date to be re-rated.
Date be re-rated.
Error [List] Error message identifier for events
Message Id to be re-rated.
Tariff [List] Tariff used to rate the events to be
re-rated.
to be re-rated.
File Type [List] Normalised Event File type of the
Start Nr to be re-rated.
End Nr to be re-rated.

Schedule Types

Clause NORMALISED_EVENT table to select

Schedule Types
Re-rate File This schedule type re-rates the set of events from a normalised event file
that were successfully rated.
Server command
reprocess_file_events –n

Normalised List List of the normalised event files
Event File available.
Name
ENM Process List Number of the ENM process to use
for rerating.

Schedule Types
Reconfigure This schedule type regenerates triggers based on the specification of all
Auditing AUDIT_TABLE configuration items.
Server command
dbtrigger

None.

Schedule Types
Report This schedule type examines the current entity validation configuration
Reference Type and generates derived information about it into a number of other tables.
(RRRT) This derived information is used to display summary of change details
about CSR entities, and by certain reports such as the Call Detail Display
Report (CDDR).
This schedule type should be run as a one-off task whenever changes are
made to the entity validation configuration.
Server command
run_sqr_script rrrt

None.

Schedule Types
Reprocess Error This schedule type reprocesses error events associated with real-time
Events rating feeds that use rating subtotals.
Server command
error_event_reprocess

Confirm Only List If set to TRUE, the schedule
reports how many error events
would have been processed
instead of reprocessing all
qualifying error events.
File Process Start Date Reprocesses only error events
Date that are associated with files that
commenced processing on or
after this date.
File Process End Date Reprocesses only error events
Date that are associated with files that
completed processing on or
before this date.
Event Start Date Date Reprocesses only error events
with a charge start date on or
after this date.
Event End Date Date Reprocesses only error events
with a charge start date on or
before this date.
C Party Id Text Reprocesses only error events
with the specified chargeable
party identifier.
Error Message ID Test Reprocesses only error events
that have this error message
identifier.
Event Type List Reprocesses only error events
that have the specified
normalised event type.
Event Where Text An SQL Where clause on the
Clause NORMALISED_EVENT_ERROR table
that restricts the error events
being reprocessed.

Schedule Types

Maximum Number Integer The maximum number of error
of Events events that can be reprocessed.
If the amount of error events
based on the above selection
criteria exceeds the specified
number, they will not be
processed.
Minimum Event Date Reprocess only error events with
Start Date a charge start date after this
date.

Schedule Types
Reprocess This schedule type re-rates normalised events that have rating subtotals
Event associated with them.
Server command
event_reprocess

Confirm Only List If set to TRUE, the schedule
reports how many events,
charges, accounts, and services
would have been processed
instead of reprocessing all
qualifying events.
File Process Start Date Reprocesses only events that
Date are associated with files that
commenced processing on or
after this date.
File Process End Date Reprocesses only events that
Date are associated with files that
completed processing on or
before this date.
Event Start Date Date Reprocesses only events with a
charge start date on or after this
date.
Event End Date Date Reprocesses only events with a
charge start date on or before
this date.
C Party Id Text Reprocesses only events with
the specified chargeable party
identifier.
Tariff Text Tariff used to rate the
normalised events.
Event Type List Reprocesses only events that
have the specified normalised
event type.
Event Where Text An SQL Where clause on the
Clause NORMALISED_EVENT table to
restrict the error events to be
reprocessed.

Schedule Types

Maximum Number Integer The maximum number of events
of Events that can be reprocessed. If the
amount of error events based on
the above selection criteria
exceeds the specified number,
they will not be processed.
Minimum Event Date Reprocess only events with a
Start Date charge start date after this date.

Schedule Types
Revoke Bill Run This schedule type revokes a standard bill run, a quality assurance run, or
a part thereof. The Revoke Bill Run schedule type allows the operator to
specify which operations within the specified bill run need to be revoked.
For example, the From Operation parameter could be set to 'Rental
Adjustment' and the To Operation parameter could be set to 'Apply
Invoices'. This would mean that the operations 'Rental event generation
(RGP)', 'Invoice/Statement generation (BGP)', and 'Invoice/Statement
Image generation (IGP)' would also be revoked.
Server command
bill_run_execute -r

Bill Run ID List ID of already-scheduled bill run.
From List Starting operation code of bill run
Operation to be revoked.
To Operation List Ending operation code of bill run to
be revoked.
Prerequisite List Prerequisite billing operation. If
Operation this operation lies outside of the
range of the 'To' and 'From'
operations, then only customer
nodes for this bill run which have
failed or are not yet up to this
specified operation will be eligible.
time.
Processes
Threshold with errors. The operation will fail
if it reaches or exceeds this
number.

Schedule Types
Notes
The bill run is revoked if the schedule associated with the Bill Run ID is
the same as the customer’s schedule and the customers have:
a) successfully completed the To Operation and not past, or

b) failed a revoke operation corresponding to the To Operation, or
c) are not yet up to the To Operation, but have completed operations
greater or equal to the From Operation.

Schedule Types
Revoke Bill Run This schedule type revokes a standard bill run, a quality assurance run, or
for Customer a part thereof, for a specific customer on a bill run. The Revoke Bill Run
for Customer schedule type allows the operator to specify a specific
customer, in addition to the operations within the specified bill run need
to be revoked.
For example, the From Operation parameter could be set to 'Rental
Adjustment' and the To Operation parameter could be set to 'Apply
Invoices'. This would mean that the operations 'Rental event generation
(RGP)', 'Invoice/Statement generation (BGP)', and 'Invoice/Statement
Image generation (IGP)' would also be revoked.
Server command
bill_run_cust -r

Bill Run Id Integer Identifier of the already-
scheduled bill run.
performed.
From Operation List Starting operation code of bill
run to be revoked.
To Operation List Ending operation code of bill
run to be revoked.

Schedule Types
Revoke Event This schedule type revokes all normalised events, normalised error
File events, and charges associated with the file. The file remains in the
archive directory, and the unbilled amount of any accounts associated
with the revokes changes is the updated.
Server command
revoke_file

Normalised List List of the normalised event files
Event File available.
Name

Schedule Types
Revoke File and This schedule type revokes all normalised events, normalised error
move back events, and charges associated with the file. The file is moved to the data
directory.
Server command
revoke_file -f

Normalised List Available normalised event files.
Event File
Name
ENM Process List ENM with the home directory as
the destination for the revoked file.

Schedule Types
Revoke Invoice This schedule type revokes invoice image settings; for example, deletes
Images all invoice images for the last bill run in the specified bill cycle schedule.
Server command
bill_run_wrapper 40 40 40

Bill Run Id Integer Identifier of the bill run for which this
operation is being performed.
Batch Size customer nodes to be processed by
a single process at any given time.
Processes
Error Integer Maximum number of customers with
Threshold errors. The bill run will fail once it
reaches or exceeds this number.

Schedule Types
Revoke Invoice This schedule type revokes invoice images for a specific customer on a
Images for bill run.
Customer
Server command
bill_run_cust_wrapper –r 40 40

scheduled bill run.
performed.

Schedule Types
Revoke Invoice This schedule type revokes invoice print settings and allows for a bulk re-
Print Settings print.
Server command
bill_run_wrapper 70 70 70

Processes

Schedule Types
Revoke Invoice This schedule type revokes invoice print settings. For example, it clears
Print Settings the print setting for all invoices on the specified schedule so that the
for Customer entire bill run can be printed again.
Server command

Processes

Schedule Types
Revoke Invoices This schedule type revokes invoice settings. For example, it deletes all
invoices generated in the last bill run in the specified bill cycle schedule.
The Revoke Invoice schedule type automatically carries out the following
operations:
• Revoke Invoice/Statement Images
• Revoke Invoices/Statements
• Revoke Rental Adjustments
• Revoke Rental Events.
If this schedule type is used, it could mean that separate schedules would
need to be run as well (for example, Unapplying Invoices). The
advantage of using the Revoke Invoices schedule type is that all revoke
operations are specified in one step.
Server command
bill_run_wrapper –r 10 40 10

Processes

Schedule Types
Revoke Invoices This schedule type revokes invoices and images, but keeps rental events
(keep Rentals) (and adjustments), for a specific bill run.
Server command

Processes

Schedule Types
Revoke Invoices This schedule type revokes invoices and images, but keeps rental events
(keep Rentals) (and adjustments), for a specific customer.
for Customer
Server command

scheduled bill run.
performed.

Schedule Types
Revoke Invoices This schedule type revokes invoice images, invoice details, rental events,
for Customer and rental adjustments, for a specific customer on a bill run. For
example, it deletes all invoices generated in the last bill run in the
specified bill cycle schedule for the specified customer.
The Revoke Invoice for Customer schedule type automatically carries out
the following operations for the specified customer:
• Revoke Invoice/Statement Images
• Revoke Invoices/Statements
• Revoke Rental Adjustments
• Revoke Rental Events.
If this schedule type is used, it could mean that separate schedules would
need to be run as well (for example, Unapplying Invoices). The
advantage of using the Revoke Invoices for Customer schedule type is
that all revoke operations are specified in one step.
Server command

scheduled bill run.
performed.

Schedule Types
Revoke Rental This schedule type revokes rental events and adjustments for a specific
Events bill run.
Server command

Processes

Schedule Types
Revoke Rental This schedule type revokes rental events and adjustments for a specific
Events for customer on a bill run.
Customer
Server command
bill_run_cust_wrapper -r 10 10

Bill Run Id Integer Identifier of the already-
scheduled bill run.
performed.

Schedule Types
Revoke This schedule type revokes all normalised events, normalisation error
Reprocessed events and charges, and recreates the original event file.
File
Server command
revoke_file –r

Reprocessed List File to have output revoked.
File

Schedule Types
Rotate Partitions This schedule type updates partitions to archive old data, and allocates
partitions for new data.
Server command
rotate_partitions

Table to List Table which is to be updated.
partition
Schedule to List Schedule which is used to
use perform the partition maintenance
optimiser.
Drop partitions Integer Duration (in the selected units)
older than that data is kept in the table
before being archived.
Units List Units for the duration that data is
kept in the table before being
archived.
Duration of Integer Duration of each partition (in
each partition selected units).
Units List Units for the duration of each
partition.
Sort Partitions Integer Duration (in the selected units)
older than that data is kept in the table
before being sorted. This
parameter is ignored if the
affected data is also set to be
'dropped'.
Units List Units for the duration that data is
kept before being sorted.
This script rotates a set of existing entries in the partition definition for
the specified <Table to partition>. The script’s three major
tasks are:
1. Find any partitions associated with the <Table to
partition> which:
• are not dropped, and
• have a TO_CHARGE_START_DATE which is less than the
<effective_date> (date when script is run) minus
<Drop partitions older than> <Units>.

Schedule Types
For each partition found the:

• REQUIRED_OPERATION_CODE is set to 'Archive'
• DESIRED_STATUS_CODE is set to 'Dropped'
• SCHEDULE_ID is set to <Schedule to use>
• TASK_QUEUE_ID is set to null
• LAST_MODIFIED is updated to the current date and time
• ATLANTA_OPERATOR_ID is set to the operator ID
associated with <task_queue_id>.
2. Checks to see if any partitions for the <Table to
partition> exist where the TO_CHARGE_START_DATE or
DESIRED_TO_CHARGE_START_DATE is greater than or equal to
the effective date. If none exist, than all partitions with an
ACTUAL_STATUS_CODE of 'Dropped' are found, ordered by their
partition name. The partition with the maximum
TO_CHARGE_START_DATE or
DESIRED_TO_CHARGE_START_DATE is found. The dropped
partitions are then updated using the following method, until
either all dropped partitions are updated, or a partition is updated
with a DESIRED_TO_CHARGE_START_DATE greater than or
equal to the effective date.
• DESIRED_STATUS_CODE is set to 'Indexed'
• DESIRED_FROM_CHARGE_START_DATE is set to 1
second after the greater of TO_CHARGE_START_DATE
or DESIRED_TO_CHARGE_START_DATE
• DESIRED_TO_CHARGE_START_DATE is set to
DESIRED_FROM_CHARGE_START_DATE plus
<Duration of each partition><Units>
minus 1 second
associated with the task’s ID.
3. If the sort duration and units have been specified, find all
partitions for the <Table to partition> that have:
• a TO_CHARGE_START_DATE which is less than or equal
to the effective date minus <Sort Partitions
older than><Units>
• a DESIRED_STATUS_CODE which is not 'Dropped'
• an ACTUAL_STATUS_CODE which is equal to 'Indexed.

Schedule Types
For each partition found the:

• DESIRED_STATUS_CODE is set to 'Sorted'
assocoiated with the task’s ID.
Notes
All updates are performed as part of a single transaction. If an error
occurs, all changes are rolled back.
If there are insufficient dropped partitions available to get a partition that
covers <effective_date>, then an error is output and all changes are
rolled back.
For efficient loading into new partitions, the indexes should be marked as
unusable during the load. This should be performed automatically by
SQL*Loader when run in direct mode. It can also be performed manually
for a partition by using the Partition Maintenance form to update the
status of a partition. This improves performance if the import command
(imp) is used to import data into a new partition. If an import is applied
across multiple partitions (or the entire table), then the ata_dropcit
command can be used to drop all indexes on the table prior to importing
the data. In this case, dbsync should be used to recreate the indexes.

Schedule Types
Standard Bill This schedule type creates and executes a standard bill run.
Run
Server command
bill_run_execute

Bill Run Type List Type of bill run, which defines the
run’s accessible list of operations.
From List Starting operation code of bill run.
Operation
To Operation List Ending operation code of bill run.
time.
Processes
number.

Schedule Types
Switch Files This schedule type renames all files that match the given file pattern in
the specified directory to <filename> YYYYMMDD where YYYYMMDD is
the task's effective date.
Server command
switch_files

Directory Text Directory containing the files to be
processed.
File Pattern Text File pattern for files to be renamed.

Schedule Types
UnApply & This schedule type de-allocates any credit payment and adjustment
Deallocate amounts for a specific bill run.
Invoices
Server command

Processes

Schedule Types
UnApply & This schedule type de-allocates any credit payment and adjustment
Deallocate amounts, and un-applies them, for a specific customer on a bill run.
Invoices for
Customer Server command

Processes

Schedule Types
UnApply Invoices This schedule type un-applies invoices for a specific bill run; the invoices
must already be de-allocated.
Server command

Processes

Schedule Types
UnApply Invoices This schedule type un-applies invoices for a specific customer on a bill
for Customer run; the invoices must already be de-allocated.
Server command

Processes

Schedule Types
Unarchive This schedule type unarchives selected tables and other data.
Server command
client_unarchive

Archive file Text Name of the archive import file.
name
Import buffer Text Changes the default Oracle import
size (in bytes) buffer size (in bytes).
Report missing [List] Select 'Yes' to report and view the
data? missing data.
Unarchive [List] Select the mode for handling
mode existing data during unarchiving.
Archive [List] Select the archive data format.
Format
Other archive Text Any other archive flags not
flags supported by prompts.

Schedule Types
Update Account This schedule type validates and updates the unbilled amount of an
Unbilled account.
Note: This script should only be run when there is no rating activity on
the system; otherwise, the account may be updated incorrectly.
Server command
update_unbilled_account

Account Text Account number to update.
Number
Notes
If an account is specified, then the unbilled amount of that account is
validated and updated. Otherwise, the unbilled amounts of all accounts
are validated and updated.
Validation of an account involves examining all charges that reference
the account and adding together all the charge amounts (converted into
the currency of the account) where the charge has a tariff with an
account_aggregate_ind_code = 1. This summed charge total is
then compared to the account unbilled amount. If the amounts differ then
the account unbilled amount is updated by that difference.
After the database changes have been committed, all updated accounts
are purged from the account cache.

Schedule Types
Update Charge This schedule type generates new charge categories for any services or
Categories customer nodes that need them. This schedule only needs to be run if
new charge categories are assigned to products that are in use.
Server command
update_cc

None.

Schedule Types
Update Invoice This schedule type validates and updates the unbilled amount of an
Unbilled invoice.
Server command
update_unbilled_invoice

Invoice Integer Invoice number to update.
Number
Notes
If an invoice is specified in the invoice number parameter then the
unbilled amount of that invoice is validated. If the unbilled amount is not
correct it is updated. Otherwise the unbilled amounts of all invoices are
validated and updated.
Validation of an invoice involves examining all charges that reference
that invoice and adding together all the charge amounts (converted into
the currency of the invoice's account) where the charge has a tariff with
an account_aggregate_ind_code = 1. This summed charge total is
then compared to the invoice unbilled amount. If the amounts differ then
the invoice unbilled amount must be updated by that difference.
account_aggregate_ind_code maintains a running total of all
unbilled charges for an account. These charges will not include billing
discounts or any billing specific charges but can be used to give an
indication of the customer's unbilled amount.
When the invoice is applied to the account, the unbilled amount in the
account table is decremented by the unbilled amount in the invoice table.
This script only needs to be run if the charge has a tariff with the Add
Charges to Account in Real-time? check box selected. If this script is
used, it can be run at any predetermined time and does not have to
correlate with bill cycles because the unbilled amount is maintained
independently of the invoiced amount. If used, this script should also be
run after a rating engine crash.

Schedule Types
Update Lists This schedule type generates new empty derived attribute arrays for any
services or customer nodes that need them. This schedule only needs to
be run if new derived attributes are assigned to products, service types, or
customer node types that are in use.
Server command
update_list

None.
Notes
A check is done in three parts.
1. A check is done for each product; all customers, customer nodes,
and any services associated with the product to ensure they have
the derived attributes required by the product.
2. All customers and customer nodes are checked to ensure they
have all the derived attributes required by their customer type.
3. All services are checked to ensure they have all the derived
attributes required by their service type.

Schedule Types
Verify Charge This type verifies that the UNINVOICED_IND_CODE (indicating whether
Partition uninvoiced charges exist in the CHARGE table) is correct in the
ATLANTA_TABLE_PARTITION table for all charge table partitions within
a calculated date range.
The calculated starting date is the schedule's effective date minus the
specified <No of Units><Units>. The end date is equal to the effective
date.
If there are no longer any uninvoiced changes left in the partition, the
UNINVOICED_IND_CODE is cleared. Because the biller automatically
uses this code (no flags need to be set) to check which charge table
partitions need to be scanned for unbilled charges, clearing the code for
unnecessary scanning improves performance.
Frequency of usage for this schedule type depends on the bill cycle and
partition range. For example, for daily partitions with monthly bill
cycles, once per week should be sufficient.
Server command
update_partitions_uninvoiced -n

No Of Units Integer Number of units to use in the date
range calculation.
Units List The type of units to use in the
date range calculation ('Day's,
'Months', or 'Weeks').
Notes
For each partition found, this function:
• Checks the CHARGE partition for any uninvoiced charges
• Updates the
ATLANTA_TABLE_PARTITION.UNINVOICED_IND_CODE as
required
• Outputs a message to advise the date and time of completion of
the task, with notification of any uninvoiced charges.

Schedule Types
Verify Charge This type verifies that the UNINVOICED_IND_CODE (indicating whether
Partition Range uninvoiced charges exist in the CHARGE table) is correct in the
ATLANTA_TABLE_PARTITION table for all charge table partitions within
the specified start and end dates.
If there are no longer any uninvoiced changes left in the partition, the
UNINVOICED_IND_CODE is cleared. Because the biller automatically
uses this code (no flags need to be set) to check which charge table
partitions need to be scanned for unbilled charges, clearing the code for
unnecessary scanning improves performance.
Frequency of usage for this schedule type depends on the bill cycle and
partition range. For example, for daily partitions with monthly bill
cycles, once per week should be sufficient.
Server command
update_partitions_uninvoiced

Start Date Date Start date of the range to verify.
End Date Date End date of the range to verify.
Notes
For each partition found, this function:
• Checks the CHARGE partition for any uninvoiced charges
• Updates the
ATLANTA_TABLE_PARTITION.UNINVOICED_IND_CODE as
required
• Outputs a message to advise the date and time of completion of
the task, with notification of any uninvoiced charges.

Index
Account cache 1-8 schedule parameters 3-11

Apply Invoices 7-10 schedule type 3-8
Apply Invoices for Customer 7-11 server processes 3-6
Apply Transactions 7-12 set up 3-8
Apply&Allocate Invoices 7-8 status of 3-5
Apply&Allocate Invoices for Customer 7-9 stopping 3-12
Architecture task type 3-8
billing and rating 1-3 tracking 3-5
billing engine 1-14 types 3-9, 3-10
Convergent Billing 5-2 Billing
rating engine 1-7 architecture 1-14
Archive correcting errors 3-15
schedule types 7-13 overview 1-14
Balance Management performing a bill run 3-8
concept 1-5 schedule types 3-17
Batch Printing 4-1 Billing Processes
BGP (Bill Generation Process) 1-16 Bill Generation Process (BGP) 1-16
BGP Hierarchy Passes customer hierarchies 3-20
explanation 7-26 General Output Process (GOP) 1-18
Bill Generation Process (BGP) Invoice Generation Process (IGP) 1-17
description 1-16 overview 3-1
steps in billing 1-16 Rental Adjustment Mode (RGP) 1-16
Bill Run Rental Generation Program (RGP) 1-15
configuration 3-7, 3-9, 3-10, 3-11 trerodb 1-17
correcting errors 3-15 trerwdb 1-17
customer batch size 4-5 Billing Schedule Types
Customer Batch Size 3-3 for bill runs 3-17
INVOICE_PRINT 4-4 for individual 3-19
modifying 3-11 for individual customers 3-18
Number of Child Processes 3-4 Billing Suppress 7-14
operations 3-5 Billing Task
overview 3-2 preparation 3-8
parameters 3-3 revoking 3-13
perform an additional operation 3-11 Billing Unsuppress 7-16
perform operations 3-5 Caches
preparation 3-8 account 1-8
print configuration 4-4 Customer Node 1-8
print set up 4-5 Rating Subtotal 1-8
priority 3-7 Service 1-8
process example 3-4 Charges
quality assurance 4-5 recurring 1-13
reports 3-14 removing unwanted 2-12
revoke operations 3-5 Child Processes 3-4
System Operations Guide for Singl.eView Convergent Billing V5.00 Index-1

Index
Complete Bill Run 7-17 schedule 6-6

Complete Bill Run for Customer 7-18 DIL Validation 7-23
Configuring Document Images
bill run customer 3-7 printing 4-7
Context-sensitive Help xii Dunning Letters
Contract Cancel/Notify 7-19 generating 4-2, 7-24
Conventions Duplicate event checking 1-10, 1-12
document ix ECP Command 7-25
Convergent Billing ENM See Event Normalisation (ENM) Process
architecture overview 5-1 ERB See Event Rating Broker (ERB) Process
Convergent Billing Architecture ERO See Event Rating Output (ERO) Process
three-tier 5-2 Error Events
Convergent Billing Processes assigning to rerating file 2-11
Balance Management 1-5 correcting 2-9
Bill Generation Process (BGP) 1-16 re-rating 7-47
Event Normalisation (ENM) 1-9 viewing 2-6
Event Rating (ERT) 1-6, 1-10 viewing and correcting 2-10
Event Rating Broker (ERB) 1-7 Error Events (bulk)
Event Rating Output (ERO) 1-11 re-rate 7-48
General Output Process (GOP) 1-18 Error Files
Invoice Generation Process (IGP) 1-17 ENM process 2-5
rating errors 1-12 Error Messages xiv
recurring charges 1-13 Errors
rental adjustment mode (RGP) 1-15 correcting (billing) 3-15
Rental Generation Program (RGP) 1-15 correcting (rating) 2-8
trerate 1-5 ERT See Event Rating (ERT) Process
trerodb 1-5, 1-18 Event File
trerwdb 1-17 revoke 7-62
Correct Event Normalisation (ENM) Process
billing errors 3-15 count file 1-10
corrupted events 2-9 description 1-7, 1-9
error events 2-9, 2-10 error file 1-9
rating errors 2-8 status file 1-10
wrong charges 2-11 tracer record 1-10
Corrupted Events Event Rating (ERT) Process
correcting 2-9 description 1-6, 1-7, 1-10
Create errors in 1-12
rerating file 2-11 parallel tariffing 1-13
table partitions 7-21 recurring charges 1-13
Create Partitions 7-21 Event Rating Broker (ERB) Process
Customer Batch Size 3-3 caches 1-7
Customer Hierarchy description 1-7
reporting level 3-20 Event Rating Output (ERO) Process
Customer Node cache 1-8 database synchronisation 1-12
Database Synchronisation 1-12 description 1-7, 1-11
Deallocate duplicate event checking 1-12
invoices 7-80 Events
invoices for customer 7-81 concept 1-3
Define removing unwanted 2-12
output method 4-13 types 1-3, 1-4
Delete Events (bulk)
Index-2 System Operations Guide for Singl.eView Convergent Billing V5.00

Index
re-rating 7-50 Normalised Files

Executing expressions 7-25 retrieving details 2-6
Form Help xi Online Help x
Full Database Validation 7-27 Output Device 4-8
General Bulk Output By Task 4-2, 7-28 examples 4-11, 4-12
General Bulk Output Process 4-2, 7-29 overview 4-9
General Output Process (GOP) Output Method 4-1
description 1-18 components 4-8
output device 4-8, 4-9 defining 4-13
printing document images 4-7 example 4-13
process 4-8 Output Method Type 4-1
processing 4-3 Output Method Types
schedule types 7-29 searching 4-8
using a schedule or task 4-2 Output Processing
Generate configuring 4-8
customer invoice image 7-31 Output scripts 4-10
dunning letter 7-24 Parallel Processing
invoice image 7-30, 7-32 support for 4-5
invoices reprint 7-34 Parallel Tariffing
viewing image file 7-35 description 1-13
Help Partition Maintenance 7-36, 7-37
context-sensitive xii Pipe/Concatenate
error messages xiv options 4-9
form xi Printing
online x bill run configuration 4-4
IGP (Invoice Generation Process) 1-17 bill run set up 4-5
Immediate Task bulk invoices 4-5
scheduling 2-3 checking output 4-7
Incorrect Charges configuring output 4-8
correcting 2-11 customer invoice 7-39
Invoice document images 4-7
generate customer invoice image 7-31 invoices 7-38
generate image 7-30, 7-32 overview 4-1
print 7-38 preparation 4-7
print customer invoice 7-39 schedule parameters 4-2
print image 7-33 schedule processing 4-3
reprint generation 7-34 schedule type 7-28
templates 1-18 scripts 4-10
view image 3-13, 7-35 single invoices 4-6
viewing data 3-13 using bill runs 4-1, 4-4
working with 1-18 using schedules 4-2
Invoice Generation Using schedules 4-1
checking results 3-13 Purge
suppressing 3-14 error events 7-40
Invoice Generation Process (IGP) events (non-error) 7-42
description 1-17 files 7-43
steps in billing 1-17 Quality Assurance Bill Run 7-44
INVOICE_PRINT 4-4 Rate Files 7-45
Modifying Rated and Reprocessed File
bill run 3-11 revoking 2-12

Index
Rating Re-rate
architecture 1-7 error events 7-47
archive directory 2-2 error events (bulk) 7-48
correcting errors 2-8 event file 7-52
directory structure 2-2 events (bulk) 7-50
errors 1-12 Re-rate File
managing files 2-1 assigning error events 2-11
overview 2-1 creating 2-11
schedule types 2-12 Revoke
Rating and Billing bill run 7-59
overview 1-1 billing task 3-13
Rating Processes customer bill run 7-61
Event Normalisation (ENM) 1-9 event file 7-62
Event Rating (ERT) 1-10 file and move back 7-63
Event Rating Broker (ERB) 1-7 invoice image settings 7-64
Event Rating Output (ERO) 1-11 invoice images for customer 7-65
trerate 1-5 invoice print settings 7-66
trerodb 1-5 invoice print settings for customer 7-67
Rating Subtotal cache 1-8 invoice settings 7-68
Rating Task invoices (keep Rentals) 7-69
checking results 2-4 invoices (keep rentals) for customer 7-70
data feed reconciliation report 2-7 invoices for customer 7-71
description 2-3 rental events 7-72
error files 2-5 rental events for customer 7-73
log-out file 2-5 reprocessed file 7-74
notifying completion 2-4 Rotate
original file location 2-5 partitions 7-75
parameters 2-3 RRRT See Report Reference Type (RRRT)
preparation 2-3 Schedule Types
running 2-3 Apply Invoices 7-10
status and result 2-5 Apply Invoices for Customer 7-11
unsuccessful 2-9 Apply Transactions 7-12
view error events 2-6 Apply&Allocate Invoices 7-8
view normalised files and events 2-6 Apply&Allocate Invoices for Customer 7-9
Re-analyse Tables 7-46 Archive 7-13
Reconfigure Auditing 7-53 Billing Suppress 7-14
Rental Generation Program (RGP) Billing Unsuppress 7-16
description 1-15 Complete Bill Run 7-17
generating charges 1-13 Complete Bill Run for Customer 7-18
processing 1-15 Contract Cancel/Notify 7-19
quality assurance mode 1-15 Create Partitions 7-21
rental adjustment mode 1-15, 1-16 description 7-1
steps in billing 1-15 details 7-7
Report Reference Type (RRRT) 7-54 DIL validation 7-23
Reporting Levels Dunning Letter Generation 7-24
billing 3-20 ECP Command 7-25
Reprocess Explain BGP hierarchy passes 7-26
error event 7-55 for bill runs 3-17
event 7-57 for individual customers 3-18, 3-19
Requirements Full Database Validation 7-27
for use of the document vii General Bulk Output By Task 7-28

Index
General Output Process (GOP) 7-29 UnApply&Deallocate Invoices 7-80

Generate Invoice Image for Customer 7-31 UnApply&Deallocate Invoices for Customer
Generate Invoice Images 7-30 7-81
Invoice Generate Image 7-32 Unarchive 7-84
Invoice Print Image 7-33 Update Account Unbilled 7-85
Invoice Reprint Generation 7-34 Update Charge Categories 7-86
Invoice View Image 7-35 Update Invoice Unbilled 7-87
Partition Maintenance 7-36, 7-37 Update Lists 7-88
Print Invoices 7-38 update partitions 7-37
Print Invoices for Customer 7-39 Verify Charge Partition 7-89
Purge Error Events 7-40 Verify Charge Partition Range 7-89, 7-90
Purge Events (non Error) 7-42 Schedules
Purge Files 7-43 deleting 6-6
Quality Assurance Bill Run 7-44 description of terms 6-3
Rate Files 7-45 frequency 6-5
rating 2-12 overview 6-2
Re-analyze Tables 7-46 server tasks 6-1
Reconfigure Auditing 7-53 working with 6-5
Report Reference Type(RRRT) 7-54 Search
Reprocess Error Event 7-55 for output method type 4-8
Reprocess Event 7-57 Server
requirements 7-1 processes 5-1
Re-rate Error Events 7-47 Transaction Engine (TRE) 5-1
Re-rate Error Events (bulk) 7-48 Server Commands
Re-rate Events (bulk) 7-50 schedule types 7-7
Re-rate File 7-52 Server Processes
Revoke Bill Run 7-59 bill run 3-6
Revoke Bill Run for Customer 7-61 Server Tasks
Revoke Event File 7-62 scheduling 6-1
Revoke File and Move Back 7-63 Service cache 1-8
Revoke Invoice Images 7-64 Singl.eView Convergent Billing
Revoke Invoice Images for Customer 7-65 architecture overview 5-1
Revoke Invoice Print Settings 7-66 Standard Bill Run 7-78
Revoke Invoice Print Settings for Customer Stopping
7-67 bill run 3-12
Revoke Invoices 7-68 Suppressing
Revoke Invoices (keep Rentals) 7-69 Invoice generation 3-14
Revoke Invoices (keep Rentals) for Switch Files 7-79
Customer 7-70 Tables
Revoke Invoices for Customer 7-71 unarchive 7-84
Revoke Rental Events 7-72 Tariffing
Revoke Rental Events for Customer 7-73 parallel 1-13
Revoke Reprocessed File 7-74 Tasks
Rotate Partitions 7-75 resubmitting 6-5
selecting criteria 2-13 Transaction Engine (TRE)
Standard Bill Run 7-78 Convergent Billing architecture 5-1
summary 7-2 TUXEDO
Switch Files 7-79 trerate 1-5
UnApply Invoices 7-82 trerodb 1-5, 1-18
UnApply Invoices for Customer 7-83 trerwdb 1-17

Index
UnApply
invoices 7-80, 7-82
invoices for customer 7-81, 7-83
Unarchive
selected tables 7-84
Update
account unbilled 7-85
charge categories 7-86
invoice unbilled 7-87
lists 7-88
Update Partitions 7-36, 7-37
Update Partitions Uninvoiced 7-89
Verify Charge Partition 7-89
Verify Charge Partition Range 7-89, 7-90
View
error events 2-6, 2-10
invoice data 3-13

500 System Operations Guide

Загружено:

Сведения о документе

Исходное описание:

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

500 System Operations Guide

Загружено:

Авторское право:

Доступные форматы

System

Singl.eView Convergent Billing V5.00

The following are third party trademarks used in this document:

Part 1 – Billing Operations

Chapter 1 – Introduction to Rating and Billing.................................................................1-1

System Operations Guide for Singl.eView Convergent Billing V5.00 i

Correcting Rating Errors .........................................................................................................2-8

Chapter 3 – Billing ................................................................................................................3-1

Chapter 4 – Batch Printing ..................................................................................................4-1

ii System Operations Guide for Singl.eView Convergent Billing V5.00

Configuring Output Processing for the GOP...........................................................................4-8

Part 2 – The Transaction Engine

Chapter 5 – The Transaction Engine (TRE) ......................................................................5-1

Part 3 – Task Automation

Chapter 6 – Scheduling Server Tasks .................................................................................6-1

Chapter 7 – Schedule Types.................................................................................................7-1

System Operations Guide for Singl.eView Convergent Billing V5.00 iii

Invoice View Image ..................................................................................................7-35

iv System Operations Guide for Singl.eView Convergent Billing V5.00

Welcome to Singl.eView Convergent Billing

Singl.eView Convergent Billing has been designed specifically for new

System Operations Guide for Singl.eView Convergent Billing V5.00 v

Who Should Read this Guide

This guide is specifically aimed at staff responsible for controlling

vi System Operations Guide for Singl.eView Convergent Billing V5.00

How this Guide is Structured

This guide consists of seven chapters, divided into three parts:

Other Singl.eView Convergent Billing Documentation

This guide is part of a suite of documentation, covering every aspect of

System Operations Guide for Singl.eView Convergent Billing V5.00 vii

Conventions Used in this Guide

The following conventions are used in this guide:

File ➩ Exit Indicates that the File menu should be opened

Use of a mouse in Singl.eView Convergent Billing is identical to that in

Select Highlight one or more characters to perform an

viii System Operations Guide for Singl.eView Convergent Billing V5.00

Online help is currently available in the form of:

System Operations Guide for Singl.eView Convergent Billing V5.00 ix

Options to access the Online Help

2. Click the Help button

x System Operations Guide for Singl.eView Convergent Billing V5.00

System Operations Guide for Singl.eView Convergent Billing V5.00 xi

To display the hint text for a specific field:

Help on Confirm A Confirm window is displayed whenever confirmation of a particular

xii System Operations Guide for Singl.eView Convergent Billing V5.00

Typically, a Confirm window displays a Help button in addition to a

Help on error Whenever an error occurs, an error message is displayed in a separate

To obtain further details of the error:

2. Read the details of options displayed.

System Operations Guide for Singl.eView Convergent Billing V5.00 xiii

Note: Access to the errors, warnings, and messages displayed by

xiv System Operations Guide for Singl.eView Convergent Billing V5.00

This chapter provides an overview of Convergent Billing rating and

Overview of Rating and Billing

The balance management functionality described in this section is

System Operations Guide for Singl.eView Convergent Billing V5.00 1-1

• The billing engine, which generates invoice data, creates the

Carriers, Switches, Faults,

Call Establishment, Authorisaton,

General Output Process (GOP)

Figure 1–1 Convergent Billing Rating and Billing Overview

1-2 System Operations Guide for Singl.eView Convergent Billing V5.00

Events Any event that results in a charge or benefit being passed on to a