500 system operations guide

System

Operations

Guidefor

Singl.eView Convergent Billing V5.00

Printing HistoryFirst Printing, June 2002

Document NumberVA500-55-1015-BR3, V5.00

DisclaimerAlthough every effort has been made to ensure the accuracy of the information contained in thisdocument, ADC Software Systems Ireland Limited makes no warranty, expressed or implied, withrespect to the quality, correctness, reliability, currency, accuracy, or freedom from error of thisdocument or the products it describes. ADC Software Systems Ireland Limited may makeimprovements and/or changes 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 thisdocument or from the use of any products described in this document. Mention of any other productnot owned by ADC does not constitute an endorsement of that product by ADC Software SystemsIreland Limited. Data used in examples and sample data files are intended to be fictional and anyresemblance to real persons or companies is entirely coincidental.

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

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

Copyright Information© 2000 ADC Software Systems Ireland Limited. All rights reserved. Apart from any use permittedunder the Copyright Act, no part may be reproduced by any process without the written permission ofADC Software Systems Ireland Limited, IDA Business Park, Dangan, Galway, Ireland.

The following 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 theUSA and other countries. FrontPage is a trademark of Microsoft. TEX is a trademark of theAmerican Mathematical Society. PostScript and Acrobat Reader are trademarks of Adobe SystemsIncorporated. UNIX is a registered trademark of The Open Group. TUXEDO is a registeredtrademark of BEA Systems, Inc. Oracle is a registered trademark of Oracle Corporation. AIX is aregistered trademark of International Business Machines Corporation. InstallShield is a registeredtrademark of InstallShield Software Corporation. Java is a trademark of Sun Microsystems, Inc.SQR is a trademark of Brio Technology, Inc.

Table of Contents

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

Preface.......................................................................................................................................vWelcome to Singl.eView Convergent Billing ............................................................................ vWho Should Read this Guide .................................................................................................... viBefore Beginning....................................................................................................................... viHow this Guide is Structured ...................................................................................................viiOther Singl.eView Convergent Billing Documentation...........................................................viiConventions Used in this Guide ..............................................................................................viiiObtaining Help .......................................................................................................................... ix

The Online Help System ............................................................................................... ixForm Help ...................................................................................................................... xContext-sensitive help................................................................................................... xiHint text........................................................................................................................xiiHelp on Confirm window options................................................................................xiiHelp on error messages ...............................................................................................xiii

Part 1 – Billing Operations

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

Events ..........................................................................................................................1-3Balance Management ..............................................................................................................1-5Event Rating ............................................................................................................................1-6

Event Rating Broker (ERB) process ...........................................................................1-7Event Normalisation (ENM) process ..........................................................................1-9Event Rating (ERT) process......................................................................................1-10Event Rating Output (ERO) process .........................................................................1-11Rating errors..............................................................................................................1-12Parallel tariffing ........................................................................................................1-13Recurring charges......................................................................................................1-13

Billing ....................................................................................................................................1-14Rental Generation Process (RGP).............................................................................1-15Bill Generation Process (BGP) .................................................................................1-16Invoice Generation Process (IGP).............................................................................1-17trerwdb ......................................................................................................................1-17trerodb .......................................................................................................................1-18General Output Process (GOP) .................................................................................1-18Working with invoices ..............................................................................................1-18Invoice templates.......................................................................................................1-18

Chapter 2 – Rating................................................................................................................2-1Managing Rating Files ............................................................................................................2-1Running a Rating Task ............................................................................................................2-3

Preparation ..................................................................................................................2-3Running the rating task ...............................................................................................2-3Checking the results ....................................................................................................2-4

Table of Contents

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

Correcting Rating Errors .........................................................................................................2-8Unsuccessful rating task..............................................................................................2-9Correcting corrupted events ........................................................................................2-9Correcting error events................................................................................................2-9Correcting wrong charges .........................................................................................2-11Revoking a rated and reprocessed file ......................................................................2-12Removing unwanted events and charges ..................................................................2-12

Rating Schedule Types ..........................................................................................................2-12Using selection criteria..............................................................................................2-13

Chapter 3 – Billing................................................................................................................3-1The Bill Run Process ...............................................................................................................3-2

Processing billing operations ......................................................................................3-3Bill run operations.......................................................................................................3-5Tracking the status of a bill run ..................................................................................3-5Server process .............................................................................................................3-6Configuring the customer node...................................................................................3-7Setting priorities..........................................................................................................3-7

Performing a Bill Run .............................................................................................................3-8Preparation ..................................................................................................................3-8Supported task types ...................................................................................................3-8Setting up a bill run.....................................................................................................3-8Bill Run Types ............................................................................................................3-9Bill Run Schedule Parameters...................................................................................3-11Modifying a bill run ..................................................................................................3-11Performing an operation on a bill run .......................................................................3-11Stopping a bill run.....................................................................................................3-12Revoking a Billing Task............................................................................................3-13Checking the results ..................................................................................................3-13Suppressing Invoice Generation ...............................................................................3-14

Correcting Billing Errors.......................................................................................................3-15Billing Schedule Types..........................................................................................................3-17Billing of Customer Hierarchies............................................................................................3-20

Chapter 4 – Batch Printing ..................................................................................................4-1Invoice Output using the Scheduler ........................................................................................4-2

GOP schedule configuration parameters.....................................................................4-2GOP schedule processing............................................................................................4-3

Invoice Output using a Bill Run..............................................................................................4-4Bill run configuration parameters ...............................................................................4-4Setting up a bill run to print invoices or statements....................................................4-5Printing invoices on a previously-completed bill run .................................................4-5Single invoice printing ................................................................................................4-6

Printing Document Images ......................................................................................................4-7Preparation for printing...............................................................................................4-7Checking the output ....................................................................................................4-7

Table of Contents

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

Configuring Output Processing for the GOP...........................................................................4-8Output method type.....................................................................................................4-8Output device ..............................................................................................................4-9Scripts for output.......................................................................................................4-10Output device examples ............................................................................................4-11Output method definition ..........................................................................................4-13Output 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-1Scheduling Overview ..............................................................................................................6-2

Terms used in scheduling............................................................................................6-3Working with Schedules..........................................................................................................6-5

Submitting a schedule .................................................................................................6-5Re-submitting a task....................................................................................................6-5Changing the frequency of a schedule ........................................................................6-5Deleting a schedule .....................................................................................................6-6

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

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

Table of Contents

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

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

Index

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

Preface

Welcome to Singl.eView Convergent Billing

Singl.eView Convergent Billing has been designed specifically for newgeneration customer care and billing environments to increasecompetitive advantage by making it easier to design, deliver, and bill theproducts and services customers want. It provides modules for billingmediation, rating, discounting, and bill production.

Singl.eView Convergent Billing is based on industry standardarchitecture, relational database technology and interfaces, to ensureportability across operating platforms.

This guide describes the facilities provided in Singl.eView ConvergentBilling for the control of server processes. The three major topicscovered are:

• Billing operations.

• The Transaction Engine (TRE).

• Scheduling server tasks using the client workstation scheduler.

Note: Throughout this manual the name 'Singl.eView ConvergentBilling' has been abbreviated to 'Convergent Billing' wherever anabbreviated form contributes to easier reading.

Preface

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

Who Should Read this Guide

This guide is specifically aimed at staff responsible for controllingConvergent 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, whichcan 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 operationand billing procedures.

Preface

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

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 followingfour 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 ConvergentBilling Transaction Engine, used to interface Convergent Billing withother 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 servertasks, and on the types of schedule which can be defined. This partconsists 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 forusers. 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 ofthe system. For detailed information on the documents available, refer tothe Overview for Singl.eView Convergent Billing.

Preface

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

Conventions Used in this Guide

The following conventions are used in this guide:

File ➩ Exit Indicates that the File menu should be openedand the Exit option selected.

Save button Button on the toolbar or on a form.

Customer Detailform

Name of a specific 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 keyis pressed. In this example, the Ctrl key mustbe held down while the function key F4 ispressed.

Use of a mouse in Singl.eView Convergent Billing is identical to that inother Microsoft Windows applications. The following terminology isused in this guide to describe the mouse functions:

Select Highlight one or more characters to perform anoperation on those characters.

Click Point to an object, then press and release theleft mouse button.

Double-click Point to an object, then press and release theleft mouse button twice in quick succession.

Drag Point to an object, hold down the left mousebutton, reposition the mouse, and release themouse button.

The terms select, click, double-click, and drag refer to the mouse cursorand the left-hand button on the mouse.

Preface

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

Obtaining Help

Online help is currently available in the form of:

• The Online Help System, which provides access to task basedhelp, reference information, glossary of terms, examples, anddemonstrations.

• Form help associated with each form.

• Context-sensitive help associated with each form, field, andcontrol.

• 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 System has been designed to provide information to suitthe needs of many types of operators. It consists of the following fullyintegrated and linked suite of help components, together with a number ofnavigational aids that allow movement between and within help topics:

• Task based (procedural) help that provides step-by-stepinstructions on how to perform a specific task, with links toreference information relevant to the task.

• Reference information to assist operators new to Singl.eViewConvergent Billing in obtaining the knowledge required to usethe system effectively and efficiently.

• Full text search and keyword (index) search facilities to locateinformation in the help system.

• Examples and video demonstrations, to show by example how toperform some of the more common procedures.

• Glossary of terms, which defines each of the terms used inSingl.eView Convergent Billing.

The Online HelpSystem

Preface

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

Options to access the Online HelpSystem are provided on theSingl.eView Convergent BillingHelp menu.

For example, to access theWelcome Screen, select theContents option from the Helpmenu.

Forms are used to enter, view, and modify data. A form may contain tabsand controls such as data entry fields, display only fields, functionbuttons, option buttons and check boxes. Several forms can be openedand displayed on the screen at one time. However, only one form canhave input focus. The form that currently has input focus is referred to asthe 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.

1. Make the form active 2. Click the Help button

Form Help

Preface

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

Where a form contains one or more tabs, a link is provided on the FormHelp window to details relevant to that tab. Such information isdisplayed in a pop-up window.

For the majority of forms, links are also provided to the task based help inthe Online Help System.

Context-sensitive help is provided for all components (data entry fields,buttons, check box, and option buttons) associated with each form withinSingl.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 shownbelow.

Context-sensitive help

Preface

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

Hint text is provided for each form field. Sample hint text for the FamilyName 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). Ifnot currently selected, select it before proceeding.

2. Position the cursor over that field. Hint text for that field isdisplayed either below the field or below and to the right of thefield.

A Confirm window is displayed whenever confirmation of a particularaction is required. For example, when changes have been made to arecord and then an attempt is made to close the window, a Confirmwindow is displayed asking whether the changes should be saved.

Hint text

Help on Confirmwindow options

Preface

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

Typically, a Confirm window displays a Help button in addition to aYes, No, and Cancel button. Clicking the Help button provides detailsof what options are available.

Whenever an error occurs, an error message is displayed in a separatewindow. For example, if a mandatory field is omitted and an attempt ismade to save the form, an error message similar to the following isdisplayed:

To obtain further details of the error:

1. Click the Help button on the Error window. The ErrorMessage 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 theproblem causing the error.

Help on errormessages

Preface

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

Note: Access to the errors, warnings, and messages displayed bySingl.eView Convergent Billing are also available through the OnlineHelp System.

Part 1Billing Operations

This part provides details on billing. This part consists of the followingfour chapters:

• Chapter 1, Introduction to Rating and Billing



• Chapter 4, Batch Printing

White text

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

Chapter 1Introduction to Rating and Billing

This chapter provides an overview of Convergent Billing rating andbilling 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 isonly available as part of the separate Singl.eView CommerceEngine licence option.

Rating and billing is divided into six operations:

• Balance management, which provides event authorisation, adviceof charge information, and customer credit reservations.

• Event normalisation, in which input data is converted into astandard format for storage in the Convergent Billing database.

• Event rating, in which the normalised event records areaggregated and rated (costed) by applying the appropriate tariffs.

• Billing, in which the costed event records are aggregated and anyapplicable discounts are applied.

• Invoicing, in which billing data is combined with customer detailrecords and incorporated into an invoice or statement.

• Invoice output, in which invoices and statements are printed orconverted for electronic distribution.

These six operations are carried out by four major components:

• TRE servers: the trerate, which provides an interface to the EventRating Module (enabling real-time account balancing and creditreservations), and the trerodb, which passes completed events onto the rating engine.

• The rating engine, which combines normalisation and rating.

Introduction to Rating and Billing

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

• The billing engine, which generates invoice data, creates theinvoice images ready for printing, and passes information back tothe rating engine for the generation of recurring charges.

• The General Output Process (GOP), which selects and sortsinvoices or statements, then outputs them to printers or otheroutput devices.

The rating engine and the billing engine are described briefly in latersections of this chapter, and in detail in the following chapters:


• Chapter 3, Billing.

The GOP is described in Chapter 4, Batch Printing.

Normalisation

Invoice or statementoutput

Rating InvoicingBilling

Rater Biller

General Output Process (GOP)

Invoices or Statements

Invoicedata

Normalisedevents

Database

Invoice images

TRE servers, trerodb and trerate

Event Rate andStore

ReservationsManagement

Carriers, Switches, Faults,Work Orders, and Rental Events

Charges, Events,and Account

Updates

Remote Hosts

Rated andNormalised

EventsReal-time

RatingPipeline

Call Establishment, Authorisaton,and Completion

Figure 1–1 Convergent Billing Rating and Billing Overview



Any event that results in a charge or benefit being passed on to acustomer can be input to, or generated within, the system. Events canoriginate from any source of charge information, including networkelements, other service providers, other mediation systems, customercontacts (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 isknown, and is consistent for each type of input.

Table 1–1 lists the terms used in Convergent Billing to describe thedifferent kinds of event.

Table 1–1 Convergent Billing Event Types

Term DefinitionAlpha event Event supplied as input to Convergent

Billing for normalisation. Alpha events maybe in these formats:• Automated Message Accounting

(AMA) records Version 1.0, asoutput by the AT&T 5ESS switch.

• Incoming Traffic Accounting Data(ITAD) records Version 1.0, asoutput by the AT&T 5ESS switch.

• Convergent Billing native eventformat, consisting of fields in userdefinable order, prefixed with arecord length field. V3.03 delimitseach field with the ASCII character255. V4.00 delimits with an ASCII 0(null).

• Any format that can be specified inthe subset of ASN.1 supported bythe Convergent Billing DataInterface Language (DIL)(for moreinformation, refer to the SystemAdministration Guide).

Charge Amount billed associated with a specificevent once it has been rated.

Corrupted event Alpha event that the ENM process couldnot decode or interpret. Corrupted eventsfrom a file are saved in the ENM errordirectory for external reprocessing. Ifreceived from a remote host, corruptedevents are discarded and the senderinformed.

Events



Term DefinitionError event An error event is either a normalisation

error event or a rater error event, as outputby the ERO.

Mediated or pre-normalised event

Event that has been pre-processed insome way before being presented toConvergent Billing. The event format istypically implementation specific.

Normalisationerror event

Event in which one or more of thenormalising expressions could not beevaluated. Normalisation error events arenot rated.

Normalised event Event that has been converted to acommon format by the Event Normalisation(ENM) process. Each normalised event issent to an Event Rating Output (ERO)process and normally is also sent to one ormore Event Rating (ERT) processes forrating.

Rated event Normalised event that has been output byan ERO process after being ratedsuccessfully by one or more ERTprocesses.

Rater error event Event that caused an error in the ERTduring rating, such as incorrect evaluationof a tariff expression or a reference to anundefined service. All charges generatedfor a rater error event are discarded.

Raw event Event generated by a switch or otherdevice. The event format is typically devicespecific.



Balance Management


Balance management is the process by which real-time accountmanagement is achieved. TRE servers work together with the ratingengine to offer service authorisation, information on advice of charge,and event-driven billing. The balance management process is shown inFigure 1–2.

Carriers, Switches, Faults, WorkOrders, and Rental Events

trerodb trerate

RatingEngine

Shared MemorySegment (Account,

Customer Node,Service, and Rating

Subtotal Caches)

Cancel and Update ReservationsSubmit events for rating

Event Establishment,Event Authorisation

Event Completion

Figure 1–2 Balance Management Process

Two TRE servers, the trerodb and the trerate, provide functions forhandling events coming in to Convergent Billing. These events mayinclude, among others, events from carriers and switches, and rentalevents.

Once a call is established (or a request for authorisation arrives) in theConvergent Billing system, balance management can be used to uniquelyidentify that event and to make reservations. This process, using acombination of functions offered by the trerate's biAccount andbiTrerate services, checks a customer's credit limit and reserves aportion of that credit for the current event. This enables calls to berefused if the customer's credit is not sufficient.



Once the call is complete, the complete event can be passed on to therating engine for normalisation and rating, using functions offered by thetrerodb's biEvent service. Balance management ensures that the eventcontinues to be uniquely identified in the process by passing itsreservation ID on to the rating engine.

Event Rating


Event rating is the process in which alpha events are converted into ratedevents, using the tariffs that have been defined for each service andcustomer. Rating is carried out by the rating engine, which is aninterlocking set of cooperative UNIX processes. The rating enginearchitecture is shown in Figure 1–3.

ERT

EventRating

process

ERB

EventRatingBroker

process

ENM

EventNormalisation

process

ERO

EventRatingOutput

process

ENM errordirectory

SQL *Loader

Database

Event formats,decoding expressions

trerateserver

Normalised events,error events,charges

Database cache (includingaccount, customer node, service,

and rating subtotal caches)

Shared Memory Segment -includes inter-process communication

Accountand

subtotalupdates

Service,customer,

tariff, accountdetails

trerodbserver

Normalisedevents

Charges

Normalisedevents

Normalisedevents,charges

Rating Information(including service,product, and tariff

details)

Online

File

Corrupted andduplicate events

Socket

Commitratingstream

Begin ratingstream

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 MonitorProcess (BMP). The ERB provides services to the other rating processesand manages the shared memory segments used for caching data from thedatabase, 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 alphaevents from file or from a remote host into normalised events.

• The Event Rating (ERT) process, which applies tariffs to thenormalised events to generate charges.

• The Event Rating Output (ERO) process, which directs the ratedevents from the ENM and the ERT to a remote host, or to thedatabase. Database loading can be done directly or by means ofintermediate files and the SQL*Loader utility.

A minimum configuration for a single instance of the rating engine is oneeach of the ENM, ERT and ERO. Providing memory and processingpower are available, it is often desirable to define extra processes toimprove throughput. An ENM can process multiple event types. Inaddition, specially configured ENM and ERO processes are required ifthe Real Time Rating Pipeline (RTR) is implemented.

For more information on rating engine optimisation and Real TimeRating, refer to the System Administration Guide.

The Event Rating Broker (ERB) process controls rating under thesupervision of the BMP. Multiple broker processes can be configured torun 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-processcommunication, as well as the account, customer node, rating subtotal,and service caches. Caches speed up performance by providingimmediate information to the rating engine. If the required information isnot in the cache, the rating engine retrieves it from the database andstores it in the cache for later use. For more information on caches andcache configuration items, refer to the System Administration Guide.

ERB ProcessingThe flow of processing in the ERB is as follows:

1. On startup, the broker connects to the database and creates, orconnects to, the caches used by the ERT and trerate processes.

2. If there are ENM, ERT, or ERO processes associated with thebroker, the ERB creates, or attaches to, the shared-memorysegment and starts the ENM, ERT, and ERO processes that havebeen configured for that ERB.

Event RatingBroker (ERB)process



3. If no ENM, ERT, and ERO processes are associated with thatparticular ERB, the ERB does not create or attach to any ERBshared memory segments. This allows one broker to beresponsible for the caches and other brokers to be responsible forone or more ENM, ERT, and ERO processes.

4. If all processes are running on one machine, the ERB performsno other function other than to monitor the other processes, andto pass external commands onto the appropriate rating process.

5. Every EXPIRY_POLL seconds, the ERB cleans up the ratingstreams and caches.

Account CacheThe account cache is used for caching database details associated withaccounts and account reservations. Account cache fetches and updatesare primarily performed by rating processes to total all of the unbilledcharges for each account, and to provide a mechanism during rating tocheck these unbilled charges and see whether they exceed some pre-determined limit.

Customer Node CachesThe customer node caches are used for caching database detailsassociated with customer nodes. There are two customer node caches:

• CustomerNode – A configurable set of columns from theCUSTOMER_NODE_HISTORY_V database view.

• CustomerNodeDA – A cache of derived attributes from theCUSTOMER_NODE_DA_ARRAY table.

Rating Subtotal CacheThe rating subtotal cache enables the access and creation of subtotalvalues (aggregates) at rating time. In practice, only the ERT and thetrerate server have access to the Rating Subtotal cache.

Service CachesThe service caches are used for caching database details associated withservices, currencies, and general ledger (GL) codes. The ERT and thetrerate processes use these caches primarily to retrieve service and tariffdetails that are required to rate an event.

There are seven service caches that are supported: Service ID, ServiceName, Derived Attribute, Network Name, Currency, GL Code, andProduct caches.



The Event Normalisation (ENM) process is responsible for convertingalpha events into normalised events. Depending on its configuration, iteither waits for a command to start normalising events from a binary fileon disk containing events of a specified type, or listens on a socket forone or more Real Time Rating events from a remote host. For moreinformation on Real Time Rating, refer to the System AdministrationGuide.

For either form of input, the source is represented by a normalised eventfile and is a collection of normalised events and one or more chargesgenerated for those events.

The flow of processing in the ENM is as follows:

1. The alpha event is parsed, using an event record definitionretrieved from the database.

If an event from a file does not conform to the specified inputformat (a corrupted event), it is appended to a file (with anextension of .e) in the ENM's error directory (for moreinformation, refer to Rating errors later in this chapter).Similarly, if the ENM process is reading a disk file and it detectsthat the remainder of the file is corrupt, the remainder of the fileis appended to the error file. Corrupted events received fromremote hosts are rejected, and the host informed.

2. The input record is unpacked, and data fields are assigned tovariables.

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 asa normalisation error event (for more information, refer to Ratingerrors 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 foroutput, and normally to one or more ERT processes for rating.Normalisation error events are sent only to the ERO.

EventNormalisation(ENM) process



Tracer RecordAn ENM process may successfully decode a record that does notrepresent an event to be normalised. This type of record is termed atracer record and may include information such as the number of recordsin a disk file. It may also include header or footer information for thefile. If the ENM process is reading from a disk file, any detected tracerrecords are buffered in memory.

If an error file is created for that disk file, any tracer records buffered upto 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 theoriginal disk file is preserved in the tracer records of the resultant errorfile in order to assist with subsequent processing.

Count FileIf the ENM process is counting events from a file, the ENM performs allthe processing that it normally would for rating, except that the event isnot sent to the ERT and ERO. Count results are appended to the countfile upon completion. The count file is stored in the home directory andis labeled enm<process number>.cnt, where <process number> isthe number of the ENM process.

Status FileWhile processing events from a source, the ENM process maintains astatus file in its home directory. The name of this file is enm<processnumber>.sts (where <process number> is the number of the ENMprocess).

The status file contains pertinent event file information (such as processdates and times, current and previous file byte offsets, and error counts).The status file is updated each time the ENM is synchronised with theERO. Synchronisation is completed once the ENM's output to the EROmatches the output by the ERO into the database. The ENM maysynchronise many times during the processing of a large normalised eventfile. The number of times an ENM will synchronise depends on theconfiguration attributes set up for that particular ENM (SYNC andSYNC_TIMEOUT).

If processing of a data file is interrupted unexpectedly (for example, dueto an electrical power failure), the ENM process uses the information inthis file to resume processing when it is restarted. The ENM also checksfor duplicate events during this process. Once the end of the source isreached, the ENM process removes the status file.

The Event Rating (ERT) process is responsible for generating chargerecords for normalised events received by the ERB. It uses methods fromthe ERM (Event Rating Module) to access information in caches and ratenormalised events.

Event Rating(ERT) process



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

1. The ERT decodes normalised event attributes from the event andassigns them to the direct variables associated with theNORMALISED_EVENT_V database view.

2. The RSC (Rating Subtotal Cache) is prepared for updates torating subtotal values (as a result of rating the normalised event).

3. An ERM method is then used to generate charges, evaluatesubtotals, and (if account aggregation is enabled) aggregateunbilled amounts to accounts.

4. If an error occurs, the ERT flags the normalised event as an errorevent, reverses any rating subtotal updates, and aborts rating ofthe event.

5. If rating is successful, the ERT commits all subtotal updatesmade for that event to the RSC.

6. If the commit fails, the ERT reverses any account updates (ifaccount aggregation is enabled), and tries again (up toRATE_RETRY_LIMIT) to execute the above steps. Once the retrylimit is reached, the event is flagged as an error event.

The Event Rating Output (ERO) process takes normalised events fromthe ENM and charges from the ERT, and sends them to a remote host (forReal Time Rating) or to the database. Database updating can be donedirectly, or the ERO can write its output to a SQL *Loader file for laterbatch updating. ERO output direction depends on the configurationparameter OUTPUT_METHOD.

Note: For large volumes of data, batch updating from files is likely to bemore efficient than direct updating (for more information, refer to theSystem Administration Guide).

During rating, each ENM establishes a link with one ERO (if there aremultiple ENMs or EROs running), and maintains this link for the currentevent file only. The ENM selects an ERO that is not currently processingrecords, 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 eventspass successfully through the ENM and one or more ERTs, and that theERO remains synchronised with the ENM. Events that are successfullynormalised and rated are passed to the database normalised event andcharge tables, or to the remote host. Normalisation or rater error events(collectively referred to as error events) are either stored in the databaseor are transmitted to the remote host.

Each normalised event file record is associated with a rating stream, andeach normalised event contained in that file shares the same ratingstream.

Event RatingOutput (ERO)process



The ERO process logs all error messages to the following file:$ATA_DATA_SERVER_LOG/log.out

Database SynchronisationThe ERO is responsible for ensuring that the account and rating subtotalcaches (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, andcharges) to the database.

If an error occurs and either of the caches cannot be updated, the EROlogs an error message and performs a database rollback. The ERO thenrolls back all account and rating subtotal cache updates associated withthe file that it is currently processing.

If the database is successfully committed, but an error occurs in thecache, the ERO logs an error message and continues processing. If acache is corrupted, the rating engine should be restarted.

Duplicate event checkingThe ERO process supports duplicate event checking if loading directly tothe database. In this case, a unique index should be set up in theNORMALISED_EVENT table. The Oracle system will automatically checkthis index when loading the event, and if a duplicate already exists, theevent will be rejected.

Note: If a TCP/IP socket connection is being used, the remote systemshould perform duplicate event checking.

Errors in the rating process can take one of two forms:

1. The alpha event cannot be parsed by the ENM because it doesnot conform to the specified input format; these are referred to ascorrupted events. If received from a remote host, corruptedevents are rejected and an error message sent to the originator.Corrupted events found in files are put in the ENM errordirectory in a file with the same name as the source file and a .eextension. Possible courses of action are to:

• Correct the corrupted events outside of ConvergentBilling, then copy them back to the ENM homedirectory, and rate them again; this is appropriate if thereis only a small number of errors.

• To revoke the entire rating run, correct the input files bysome external means, then rate them again; this isappropriate if there is a large number of errors, perhapscaused by a software problem at the switch.

Rating errors



2. The event conforms with the specified input format, but containsdata that either cannot be normalised or rated; such events areknown as error events (events are either stored in the database orare transmitted to the remote host).

3. The event can be normalised, but errors occur when committingto the database. For more information, refer to DatabaseSynchronisation earlier in this chapter.

For more information on viewing and correcting corrupted and errorevents, refer to Chapter 2, Rating.

The rating engine can apply different tariffs to the same normalised eventin one pass. This technique is known as parallel tariffing which makes itpossible to apply simultaneously separate tariffs that calculate charges tocustomers, 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 singlepass through the rating engine, but it also increases the ERT processingload. It is often appropriate to provide two or more ERT processes foreach ENM process to avoid processing bottlenecks (for moreinformation, refer to the System Administration Guide).

Recurring charges, such as equipment rentals and maintenance contracts,differ from other events in that they are generated by Convergent Billingitself, rather than coming from an external source.

The process used is the Rental Generation Process, which runs as theTRE server trergp (for more information, refer to Billing later in thischapter). The RGP uses customer and service data to generatenormalised events for recurring and one-off charges. These events arethen rated like any other event, to produce charges for inclusion in theBill Generation Process (BGP).

Parallel tariffing

Recurringcharges



Billing

Billing is the stage when the rated events generated by the rating engineare processed by the billing engine to generate billing data, andeventually invoices for printing or delivery to the customer by electronicmeans. Figure 1–4 shows the architecture of the billing engine.

RGP(trergp)Rental

GenerationProgram

IGP(treigp)Invoice

GenerationProcess

BGP(trebgp)

BillGeneration

Process

Rater

Database

Product/Facility details

Recurring tariffs

Rentalevents

Adjustmentevents

Customerproductdetails

Charges

Billing data

TemplatesBilling data

Invoice images

Rentals and adjustments (charges)

TransactionalServer

trerwdb

Printeror file

GOP

GeneralOutput

Process

DatabaseRead-only

Server

trerodb

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-upof the system. The GOP, used to print the final invoices (or output themto file), is an independent process that runs as required.

The bill run schedule types provided with the base installation offer theoption of running a range of billing operations, from adjusting rentalevents to un-applying invoices. If invoices are generated, they can besent to an output device, as well as applied to customer accounts.



The Rental Generation Process is a TRE server (trergp). It can be usedduring billing to generate rental events and rental adjustment eventsbefore invoices or statements are generated. In rental generation mode,rental refers to any recurring charge, such as a subscription to a service ora maintenance charge, as well as equipment rental. In most cases, theserecurring charges are paid in advance. The RGP is also able to generateevents for one-off rental charges.

The RGP is able to run in Quality Assurance (QA) mode, which meansthat these generated events will not be used to bill a customer.

If called in rental adjustment mode, the RGP is used to make anycorrections required to existing advance rental charges if the details of therental have changed since the charge was made. For example, anadjustment may be required if the service was not available to thecustomer during part of the relevant period. The rental adjustment modeis therefore concerned with adjusting past rental charges, whereas therental generation mode is used to generate rental charges in advance.

All events generated by QA calls to the RGP are ignored for the purposesof retrospective adjustment.

Note: The rating of events that are generated in both modes of the RGPcannot contribute to aggregations or real-time unbilled account balances.

RGP ProcessingProcessing 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 foreach recurring tariff. These dates are derived from the:

• Bill cycle, giving the effective start date.

• Tariff cycle, which defines the rental period and theadvance period.

• Pro-rating adjustment, which is used to bring the rentalcharge into line with the bill cycle.

3. Builds the active time line for the rental generation period; thisline may not be continuous, for example, if the service was notavailable 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 asubsequent Rental Adjustment Process.

6. Writes the events into a specified directory, and instructs aspecified ENM process to rate them.

RentalGenerationProcess (RGP)



One-off charges are generated using specific tariffs associated with aproduct. The RGP applies these tariffs exactly once when certain eventsassociated with a product lifecycle occur. Activation and cancellation ofa product instance, facility group instance, or service can result in one-offcharges. 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 thecharge was made, rental adjustments are used to make the requiredcorrection. For example, an adjustment may be required if the rentalservice was not available to the customer during part of the period. TheRGP performs the following when processing adjustments:

1. Calculates the rental charges for a period in the same way as inrental generation mode. The period is specified as aconfiguration item attribute, with a default value of 90 days.

2. Compares the result of its calculation with the originallygenerated rental charge.

3. Generates appropriate adjustment events that are rated forinclusion in the customer's bill if the charges differ.

The BGP is a TRE server (trebgp) and is used to create the invoice detailfrom the charges incurred by a customer node (and by any child nodes forwhich this node is specified as the invoicing node), and to calculate totalsand 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 foreach customer hierarchy in the bill cycle.

3. Aggregates charges as required by the reporting level defined forthe node (invoice, statement, or none).

4. Applies eligible tariffs (normally discount tariffs), subtotals, andderived 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 supportsparallel tariffing, but there are two major differences:

Bill GenerationProcess (BGP)



1. The BGP applies tariffs to aggregated data records, rather thanindividual ones. Aggregation means that the individual chargesare aggregated into one or more pre-defined groups for thepurpose of obtaining a total value for that grouping. In general,charge records are aggregated according to the pre-definedcustomer hierarchy to give totals for normalised events, services,individual and child customer nodes, and customers.

2. The tariffs applied to the aggregated records are generallydiscount tariffs rather than charge tariffs; for example, if acustomer's usage is higher than a preset limit for the specifiedbilling cycle, then a volume discount could be applied to the totalcost of the calls.

The IGP is a TRE server (treigp) and creates the invoice image for eachcustomer, ready for output using the General Output Process (GOP). Itdoes this by retrieving invoice data from the database and substituting itinto an invoice template. Current Convergent Billing releases usetemplates in ASCII text, but any suitable text based page descriptionlanguage can be used.

The IGP is also used to generate dunning letters for customers who areoverdue 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 appropriatetemplate for each customer or customer node. Data insertion isbased on Convergent Billing expressions.

3. Evaluates any calls to nested templates, substituting printableinformation for template code.

4. Checks the eligibility criteria.

5. Stores the compressed invoice or letter image in the database.

The Transactional server trerwdb is a general-purpose server supportingglobal transactions using the TUXEDO two-phase commit. TheTransactional server advertises services that read and write to thedatabase and ensures the integrity of the transactions. For moreinformation refer to Chapter 19, Transaction Engine Servers andServices, of the System Administrators Guide.

InvoiceGenerationProcess (IGP)

trerwdb



The read-only server trerodb provides database services that read datafrom the database. The purpose of the read-only server is to separateservices that read database information from services that need to commitdata, so that the transaction load is shared across the TRE servers. Inaddition, performance is enhanced as fewer servers are required for datato be committed. For more information refer to Chapter 19, TransactionEngine Servers and Services, of the System Administrators Guide.

The final stage in billing operations is the production of the invoices orstatements, either by printing or by generating files for electronic transferof accounting information. The procedures for doing this are explainedin Chapter 4, Batch Printing.

Various schedule types allow the configuration of invoices and invoiceimages before committing them to customers' accounts. For moreinformation on billing schedule types, refer to Chapter 3, Billing.

Invoice templates play a significant part in billing; not only do theycontrol the appearance of the final bill displayed to the customer, theyalso play a significant role in processing the data that is displayed onthem.

For more information on the design and use of invoice templates, refer tothe System Administration Guide and the manual Invoice Design Tool.

trerodb

General OutputProcess (GOP)

Working withinvoices

Invoicetemplates


Chapter 2Rating

This chapter describes the use of the rating engine to process incomingevents in order to generate normalised events and charges. It alsodescribes methods for checking that events have been correctlynormalised 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 (includingConvergent 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, knownas Real Time Rating, refer to the System Administration Guide. TheSystem Administration Guide also describes processes that make up therating engine, and issues such as defining additional rating processes andoptimising rating engine performance.

Managing Rating Files

Event files should be placed in a known location, conventionally in thedata/server/input directory under the home directory of ConvergentBilling instance. They should be given names that reflect the source andtype of the event they contain and, if necessary, some indication of thedate range covered by the events.

Event file names must be unique. A new file that has the same name asa file already processed cannot be processed. Including the date andtime of creation in the file name ensures that it is unique.

Rating


After rating, events are moved to an archive directory, conventionallydata/server/archive. If the Event Normalisation (ENM) processcannot parse any events, these corrupted events are written to a file in theerror directory, conventionally data/server/error. The file has thesame name as the original file, with a .e extension.

The recommended directory structure for handling event files inConvergent Billing is shown in Figure 2–1.

Singl.eView ConvergentBilling instancehome directory

data

server

archiveinput error log

data_file data_file data_file.e log.out

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

Successfully normalised filesare moved to the archivedirectory

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

Figure 2–1 Singl.eView Convergent Billing Directories forRating

The ENM can process multiple event types. Among the ENM attributesare the paths to the input, archive, and error directories (for moreinformation on creating and configuring ENM processes, refer to theSystem Administration Guide).

Each ENM can be configured with a different set of paths; for example,to create subdirectories for each type of event underdata/server/input to better manage event files. This done byspecifying the path to the correct input directory in each configuredENM.

Rating


Running a Rating Task

This section explains the running of a rating task, including the checksrequired both before and after the task is run.

Note: The running of a rating task can consume substantial serverresources and requires frequent database access. Demand for server anddatabase resources may reduce performance, both for the rating processitself, and for concurrent Convergent Billing processes. If possible, therating task should be run when other system demands are at a minimum.

Before scheduling a rating task:

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

• Create at least one ENM process for rating.

• Run all server processes including the TUXEDO processes (formore information, refer to the System Administration Guide).

• Check that 'Update Lists' and 'Update Charge Categories' tasksare either not required or have been run, as changes in list andcharge category definitions are not automatically extended toexisting product instances.

A rating task is run by defining a schedule or an Immediate Task of type'Rate Files'. By using a schedule, a rating task can be run at specifiedintervals; an Immediate Task can run a single rating task immediately(refer to Chapter 6, Scheduling Server Tasks for more information onscheduling).

A 'Rate Files' schedule takes these parameters:

ENM ProcessThe ENM process that has been configured to handle the type of eventbeing 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 PatternPattern 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 withthe characters evt then contain arbitrary text (perhaps a time stamp), andhave the extension .itad.

Preparation

Running therating task

Rating


ENM File TypeDefines the method used to parse the event, and an optional list ofexpressions being evaluated as part of normalisation; the value selectedshould match the type of event in the files.

ENM Event TypeControls the way that normalised events of the given type are displayed.The appropriate definition from the list should be selected.

Event SourceName of the switch or other source of the files being rated; thismandatory parameter is included in each Normalised Event generated bythe task.

After the task has been run, a message is received in a pop-up window iflogged on; if not, by email, advising of completion of the task.

The rating process can have one of four outcomes for an individual eventin a file:

• The event is in an invalid or unexpected format, and cannot beparsed by the ENM; such corrupted events are written to a file inthe ENM error directory with the same name as the source fileand a.e extension.

• The event is parsed by the ENM, but is flagged as being in errorby the ENM or the ERT; such error events are saved in thedatabase.

• The event is normalised and rated without apparent error, but thecharge is incorrect (for example, because of the wrong definitionof a product or tariff); the event and charge are stored in thedatabase. Errors of this kind are often difficult to detect.

• The event is normalised and rated correctly; the normalised eventand the resulting charges are stored in the database.

Information on the results of a 'Rate Files' task can be obtained from thesesources:

• 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 arediscussed in Correcting Rating Errors later in this chapter.

Checking theresults

Rating


Task Status and ResultsTo view the Task Status and Results fields of the rating task:

1. Select the Server Tasks ➩ Schedules option. The ScheduleSearch form is displayed.

2. Click the Search button to list schedules.

3. Double-click on relevant list entry. The Schedule Detail formis displayed.

4. Click the Search Task button. The Task Search form isdisplayed.

5. Double-click on the list entry for the relevant task. The TaskDetail form is displayed.

A status of 'Success' shows that the file was successfully rated, and theResults 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 fileThe progress of rating is recorded in the file $ATA_SERVER_LOG/log.out, together with other events of interest. The easiest way toinspect this file is to enter the command:

LOG <n>

at the UNIX command line, where <n> is the number of lines from thetail of the file being inspected.

A text editor, such as vi or ed, can also be used to examine the file. Arating run is bounded by messages such as enm: Commencedprocessing file <filename> and enm: Completed processingfile <filename>. An analysis of the output, and a listing of anyerrors encountered, can be found between these messages.

Note: Additional help on error messages can be found in the Online HelpSystem.

Original file locationWhen rating is complete, events that were successfully rated are movedfrom the data/server/input directory to thedata/server/archive directory.

Error filesIf the ENM detects any corrupted events, it puts them in a file in the errordirectory. The file has the same name as the original event file, with a .eextension. The data/server/error directory should also be checkedfor any such corrupted event files.

Rating


Viewing normalised files and eventsTo retrieve details of all files that have been rated and the normalisedevents they contain:

1. Select the Server Tasks ➩ Events ➩ View NormalisedFiles and Events option. The Normalised File Search formis displayed.

2. Use the search criteria to locate the file on which information isrequired (for example, by searching on the file name).

3. Double-click on the list entry of the file. The Normalised FileDetail form is displayed.

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 andcorrupt 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 eventsIf an event is parsed by the ENM, but is flagged as being in error by theERT, it is stored as an error event; if the event is flagged as being in errorby the ENM, it is stored as a normalised error event. The NormalisedFile Detail form indicates the presence of such events; a value isdisplayed in the Rating Error Event Count field, for errors flagged by theERT, or in the Normalised Error Event Count field for errors flagged bythe ENM.

Rating


To view Error Events:

1. Select the Server Tasks ➩ Events ➩ View/Assign ErrorEvents option. The Normalised Event Error Search form isdisplayed.

2. Click the Search button to list all error events.

3. Double-click on the relevant list entry. The Error Message fieldin the Normalised Event Error Detail displays the reason whythe event is in error.

The Data Feed Reconciliation ReportThe Data Feed Reconciliation Report (RDFR) is a report that providesdetails of call records input within the specified dates, and a summary ofthe charges that resulted (for more information, refer to the ReportsGuide).

Other reportsOther reports on rating may have been defined for specific ConvergentBilling installations, for example to detect abnormally high charges (formore information on these reports, refer to the Reports Guide).

Rating


Correcting Rating Errors

This section outlines techniques that can be used to correct any errorsoccurring as a result of a rating task.

The techniques are summarised in the flow chart of Figure 2–2.

Rating tasksuccessful?

Normalised errorevents created?

Are the chargedetails correct?

No

Revoke file, orrevoke and movefile

Yes

Error file createdon the server?

Is there a need toremove successfullyrated events that havenot been billed?

Re-rate file

Makeappropriatetariff/productchanges

Purge errorevents

Assign singleevents to a file tobe reprocessed

Bulk assignerror events andreprocess

Correct records

Rename error fileand move back toinput directory tobe rated

Investigate thenature of theerrors

Rate File

Determine andresolveprocessingproblems

End

Are events inerror needed?

Reprocess errorevents

No

Yes

No

Yes

Yes

Yes

No

Purge events toremove selectedevents

Revoke file toremove an entirefile

End

End

Yes

Figure 2–2 Rating Error Flow Chart

Rating


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

1. Check that all the required server processes are running (for moreinformation, refer to the System Administration Guide).

2. Investigate the causes of failure reported on the Results tab of theTask Detail form and take any corrective action.

3. Submit the rating task again.

Corrupted events are events that could not be parsed by the ENM, and arewritten to the error directory.

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 aproblem with the switch or mediation software.

• Complete failure may indicate an incorrect NormalisedEvent File type was selected for processing the file.

2. Take whatever measures are necessary to correct the corruptedevents 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 problemback to the originator of the events.

3. When the corrupted events have been corrected, move the filecontaining them to the input directory; it is suggested that theerror file be renamed to reflect its origin and current status.

4. Rate the corrected file, using an ENM of the correctconfiguration for the type of event contained in the file.

If an event was successfully parsed by the ENM, but an error wasdetected during normalisation or rating, the event is termed an errorevent.

To deal with error events:

1. If the event is not required, purge by running a task of type 'PurgeError Events' (for more information, refer to Rating ScheduleTypes later in this chapter).

Unsuccessfulrating task

Correctingcorruptedevents

Correcting errorevents

Rating


2. Examine the error events to decide if the problem is in the eventitself, or has been caused by another problem such as a wronglydefined tariff, derived attribute, function, or other ratingcomponent; for example, a derived attribute lookup table thatdoes not contain all the possible lookup values may have beendefined. An otherwise valid event might be treated as an errorevent because the lookup failed.

3. If the problem is in the event itself, it should be corrected in theNormalised Event Error Detail form, and assigned to a file forrerating; 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, takewhatever steps are required to correct the problem, then run atask of type 'Re-rate Error Events (bulk)'; this allows entry ofselection criteria to identify the error events to be rerated. Theseevents are processed directly, without the need to assign them toa file.

Viewing and correcting errorsTo view and correct error events:

1. Select the Server Tasks ➩ Events ➩ View/Assign ErrorEvents option. The Normalised Event Error Search form isdisplayed.

2. Enter search criteria, and click the Search button; if nothing isentered, all errors are found.

The search criteria can be used to select only errors of aparticular type; for example, if the error 'No charges weregenerated for this event' has the Error Message ID 2950, theSearch Field 'Error Message ID' and the value '2950' can be usedto retrieve only those events where no charges were generated.

3. Double-click the event in the list. The Normalised Event ErrorDetail form is displayed.

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 fileTo assign an error event to a rerated file:


2. Click the Assign/View Existing button. The Assign/ViewExisting 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 Assignbutton. The Assign/View Existing Rerated File Search formcloses. Check that the file name chosen is displayed in theRerated group. The sequence number of the event within thisfile is also displayed.

5. Click the Save button on the toolbar.

Creating a new rerating fileTo create a new file if a suitable rerating file described in step 3 above isnot found:


2. Click the Assign New button in the Normalised Event ErrorDetail form. The New Rerated File form is displayed.

3. Enter the appropriate details in the File Name and Event Sourcefields and click the Create button. The New Rerated File formcloses, and the error event is assigned to the new file.

4. Click the Save button on the toolbar; this saves the changesmade to the error event and the rerating file just created.

If normalised events and charges are created without apparent error, butthe charges are consistently wrong:

1. Run a task of type 'Revoke File and move back'; this rolls backall normalised events, error events, and charges that weregenerated by the file. The original event file is re-created (exceptfor any corrupted events), and placed back in the input directory.

Note: If a task of type 'Revoke Event File' is run, the samerollback process occurs and the event file is re-created; thedifference 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.

Correctingwrong charges

Rating


A file that has had one of its original normalised event errors reprocessedcan be revoked in the:

• Reprocessed file, by running the task of schedule type 'RevokeEvent File' and then 'Revoke Reprocessed File'.

• Original file, by running the task of schedule type 'Revoke EventFile'.

If certain events and charges are not needed (for example, because theyduplicate charges already processed), they can be removed by running atask of schedule type:

• 'Revoke Event File', if all the events and charges originated in thesame file.

• 'Purge Events (non Error)' (using selection criteria to restrict thepurge to the unwanted events), if the unwanted events come froma variety of sources.

Rating Schedule Types

Table 2–1 lists the schedule types that are available for rating tasks, witha brief explanation of the function of each (for more information, refer toChapter 7, Schedule Types).

Table 2–1 Rating Schedule Types

Name FunctionPurge Error Events Allows use of selection criteria to purge

selected error events from the database.

Purge Events (nonError)

Allows use of selection criteria to purgeselected normalised events andassociated charges from the database.

Purge Files Deletes files that are older than a givendate from a specified directory. This canbe used for housekeeping.

Rate Files Rates the selected files with a specifiedENM.

Re-rate Error Events Rerates error events that have beenassigned to a rerating file.

Revoking arated andreprocessed file

Removingunwantedevents andcharges

Rating


Name FunctionRe-rate Error Events(bulk)

Allows use of selection criteria to rerateselected error events without assigningthem to a file.

Re-rate Events(bulk)

Allows use of selection criteria to rerateevents. Any charges for the associatedevents are discarded and re-calculated;any error events in the file are alsorerated.

Re-rate File Rerates the specified file. Anyassociated charges are discarded andre-calculated; any error events in the fileare also rerated.

Reprocess ErrorEvents

Reprocesses error events whosecharges are dependent on the value ofrating subtotals.

Reprocess Events Reprocesses normalised events thathave associated rating subtotals.

Revoke Event File Rolls back all normalised events, errorevents, and charges for the file, and re-creates the original event file (except forcorrupted events). The re-created fileremains in the archive directory.

Revoke File andmove back

Rolls back all normalised events, errorevents, and charges for the file, and re-creates the original event file (except forcorrupted events). The re-created file ismoved to the input directory.

RevokeReprocessed File

Rolls back all normalised events, errorevents, and charges for the file, and re-creates the original rerating file.

Certain rating schedule types for purging and rerating allow entry ofselection criteria to confine the operation of the resulting task to a subsetof events. The criteria available in each case are taken from those listedin Table 2–2 (the actual criteria vary from case to case), and may be usedin combination to further refine selection criteria.

Using selectioncriteria

Rating


Table 2–2 Selection Parameters

Criterion DescriptionENM Process ENM process that rated the original

events.

File Process Start DateFile Process End Date

Dates between which the events wereprocessed in Convergent Billing.

Base Event File Name Name of the file in which the originalevents were provided.

Event Start DateEvent End Date

Period in which the events occurred.

Error Message Id Code for the error message attachedto the error events.

Event Source Source from which the events came(switch or mediator).

Event Type Normalised event type associated withthe events.

File Type Normalised event file type associatedwith the events.

File Record Start NrFile Record End Nr

Start and end positions of events inthe file.

Event Where Clause SQL Where clause on theNORMALISED_EVENT or NORMALISED_EVENT_ERROR table that restricts thechoice of events.

File Where Clause SQL Where clause on theNORMALISED_EVENT_FILE table thatrestricts the choice of events.

ExampleA certain tariff, applied to events of a particular type, has been identifiedas incorrectly defined during a certain period of time. After correctingthe tariff, rerating all events that used the wrong tariff during that periodis required.

To achieve this, schedule a task of type 'Re-rate Events' using thefollowing parameters.

File TypeNormalised event file type appropriate to the events; alternatively, if theENM process which rated the events is known (provided just one ENMprocess had been used to rate all the events in error), that ENM processcould be chosen.

Rating


TariffTariff responsible for the incorrect charges generated for the events.

Event Start Date and Event End DatePeriod during which the incorrect charges were generated.

Rating



Chapter 3Billing

This chapter describes the use of bill runs to process normalised eventsand charges to produce invoice information and invoice images forcustomers and customer nodes. In addition, this chapter describesmethods for checking that invoice data and images are correct, and formaking 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 ofinvoice images to printers or other output devices using the GeneralOutput 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 customernode or a batch of customer nodes by performing a bill run. The abilityto perform separate billing operations allows the user to easily configurethe billing process. For example, the user can generate rental eventswithout producing invoices. Additional operations can also be performedon existing bill runs. For more information, refer to Bill run operationslater in this chapter.

A bill run must be configured with a bill run type, which determines theset of possible schedule types that can later be executed on this particularbill run. For more information, refer to Bill Run Types later in thischapter.

The ability to process multiple customer nodes allows the user to speedup the bill run process, as well as control the quality of the process. Forexample, the user can review initial invoices before the majority ofcustomer nodes have been processed; if the first invoices contain errors,the bill run can be stopped. For more information, refer to Processingoperations later in this chapter.

Statistical information for each billing operation is recorded, includingthe success or failure of the operation and its duration. For bill runsprocessing multiple customers, the statistical information is recorded foreach operation and summarised for the overall bill run (for moreinformation, refer to Tracking the status of a bill run later in thischapter).

Billing operators also have complete control over how many errors canoccur before the bill run is aborted. If errors do occur, it is onlynecessary to revoke the billing operations on the customer nodes thatactually failed (for more information, refer to Correcting Billing Errorslater in this chapter).

In addition to producing invoices for customers, bill runs can also be usedto produce statements, which can be used for quality assurance purposesor for customer information (for more information, refer to Setting up abill run later in this chapter).

Billing


All schedule types used for performing billing operations for a set ofcustomers on a bill run have two common parameters that control howthe operations will be performed: Customer Batch Size and the Number ofChild Processes.

Customer Batch SizeThe Customer Batch Size parameter controls the number of customersthat are passed to each bill run operation in turn. After identifying alleligible customers for the specified operations, the customers areprioritised and grouped into batches of the specified size. The requestedrange of billing operations is then sequentially performed on each batchin turn.

For example, if the billing operations to be performed are 'Rental EventGeneration' to 'Invoice Image Generation', the total number of eligiblecustomers is 1500 and the customer batch size is 100, then the processingis as follows:

1. The customers are divided into 15 batches.

2. For the first 100 (highest priority) customers, perform thefollowing operations:

a) Rental Event Generationb) Invoice Generationc) Invoice Image Generation

3. For the second 100 customers, perform the following operations:

a) Rental Event Generationb) Invoice Generationc) Invoice Image Generation

4. For the third 100 customers....

Processingbillingoperations

Billing


Each operation on a customer batch results in the generation of a Bill RunOperation Record. This record summarises the results of the operation onthe batch of customers, and appears in the Auditing tab on the Bill RunDetail form. Customer Bill Run Operation Records are also generatedfor each customer in the batch. These are viewable from the CustomerDetails form and contain a basic summary of the result of the operationfor the customer node.

Number of Child ProcessesThe Number of Child Processes parameter controls the number of parallelprocessing streams used to process the customers. Each batch ofcustomers is processed on a single stream.

Using the above example, if the Number of Child Processes parameter isset to 3, then the first 3 highest priority batches of 100 customers will beallocated to the three child processes and their billing operations will beperformed concurrently.

Each parallel-processing stream acts independently of the others. Assoon as one stream completes processing a customer batch, itimmediately starts processing the next available batch in order of priority.Specifying a number of parallel-processing streams can improve serverutilisation and billing throughput. It can also minimise the impact of acertain customer batch stalling, due to the batch containing customernodes that take a long time to process. If multiple parallel-processingstreams are specified, other customer batches can be automatically startedand completed while the long-running customer batch is still processing.

Neither of these concepts were available in Convergent Billing version3.03 or earlier versions. In earlier versions of Convergent Billing, theprocessing was equivalent to all customers being processed as part of asingle batch on a single processing stream.

The graph in Figure 3–1 displays bill run processing with a batch size of100 and number of child processes set to 3.

RentalGeneration

InvoiceGeneration

Invoice Image

RentalGeneration

RentalGeneration

InvoiceGeneration

InvoiceGeneration

Invoice Image

Invoice Image

bill_run_execute(multi processing)

bill_run_cust(single processing)

to customer

customer batch 2

(100) customers

customer batch 3

(100) customers

customer batch 1(100) customers

Figure 3–1 Bill Run Processing

Billing


A bill run consists of a set of bill run operations and each bill runoperation is performed on a set of customers. The results of eachoperation on each customer is recorded and therefore provides a completeaudit trail. Bill run operations can be performed on individual customersor on a specified group of customers.

Bill run operations can not be deleted or directly updated. TheBILL_RUN_OPERATION reference type defines the operations thatperform and revoke operations on the bill run. The following table liststhe available billing operations:

Perform Operation Revoke OperationRental Adjustment Generation Revoke rentals and adjustments

Rental Event Generation Revoke rentals and adjustments

Invoice/Statement Generation Revoke invoices/statements

Invoice/Statement ImageGeneration

Revoke invoice/statementimages

Apply invoices Unapply invoices

Allocate invoices De-allocate invoices

Print invoices Discard printing of invoices

Depending on the mode of operation, biBillRunExecute& orbiBillRunExecuteForCustomer& performs each operation. For eachoperation, the bill run ID, effective date, effective day of month, bill runoperation ID, and the quality assurance indicator is passed to theinterface. In addition to these, biBillRunExecute& also passes the listof root customer nodes. For biBillRunExecuteForCustomer&, theTRE then returns statistical information on the operation,biBillRunExecute& returns statistical information as well as a list ofcustomer nodes that were successfully processed, the list of customernodes that failed, and a list of customer nodes that where suppressed.

Statistical information for each operation is recorded, including thesuccess or failure of the operation and its duration. For bill runs thatprocess batches of customers, the statistical information is recorded foreach operation and summarised for the overall bill run. This statisticalinformation is displayed on the Auditing Information tab:

Bill runoperations

Tracking thestatus of a billrun

Billing


Different server processes are responsible for implementing the differentTRE interfaces for each operation. All revoke operations are run by theEPM trerodb process, except 'Unapply Invoices', which is run by thetrerwdb process. The primary server responsible for each operation isshown in the following table:

Bill run operation TRE interfaceRental 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

Server process

Billing


The billing configuration specified for each customer determines the setof functions executed to perform each of the operations configured for abill run. Three steps are necessary to configure customer nodes for a billruns:

1. The billing configuration must be defined.

The CUSTOMER_BILLING_CONFIGURATION reference typedefines the available billing configurations. There are three typesof billing configurations supplied with Convergent Billing:'Default', 'High Volume Service', and 'Large CorporateHierarchy'.

2. The billing configuration and its operations must be mapped toTRE functions.

The BillingConfiguration derived attribute table maps eachbilling configuration and operation to the TRE function that is tobe called to invoke it. The user can add new configurationmappings to the BillingConfiguration table. If nothing isadded to this table for the new billing configuration, theoperations defined in the 'Default' configuration will be used.

It is possible to add new TRE operation functions to be used inthe billing configuration. An EPM sample function,biBillRunTemplateOperation&, is provided withConvergent Billing as an example of how to write a function toperform a new billing operation.

3. A billing configuration must be selected for the customer.

A configuration is selected using the Configuration field on theBilling tab on Customer Detail form. A configuration can onlybe selected for a root customer node, and must be null for childnodes. Selecting the correct billing configuration ensures that thebill run uses the appropriate functions. For example, for acorporate customer with a large hierarchy, the corporate billingconfiguration can be selected to ensure that the bill run isefficiently executed using parallel processing.

Prioritising customers and services on a bill run is controlled byspecifying the Billing Priority of the Customer Detail and ServiceDetail form. The lower the numerical value specified for the BillingPriority, the higher the priority. The bill_run_execute script alwaysprocesses the highest priority customers first.

Configuring thecustomer node

Setting priorities

Billing


Performing a Bill Run

This section describes how to perform a bill run, including the checksthat are required both before and after the task is run.

Note: Performing a bill run can consume substantial server resources andrequires frequent database access. Demand for server and databaseresources may reduce performance, both for the billing processes and forconcurrent users. If possible, the bill run should be run when othersystem demands are at a minimum.

Before scheduling a bill run, ensure that the event files containing eventsfor inclusion on bills have been successfully rated, and any corrupted ornormalisation error events have been corrected.

There are two available task types that are supported by the scheduletypes 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 forthe specified customer.

A bill run schedule uses one of the following supported task types:

• Standard Bill Run, which generates an invoice that is sent out tocustomers.

• Quality Assurance Bill Run, which generates a temporary billthat is not sent to the customer and not paid; this can be used forquality assurance purposes and quoting.

• Complete Bill Run, which completes a standard bill run, a QAbill run, or a part thereof for the total bill run.

• Complete Bill Run for Customer, which completes a standard billrun, a QA bill run, or a part thereof for a specific customerhierarchy.

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, referto Chapter 6, Scheduling Server Tasks). Several billing schedules fordifferent customers or groups of customers can be set up.

Preparation

Supported tasktypes

Setting up a billrun

Billing


When defining a bill run schedule, the following are some of themethods 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 themonth.Example: 1st Friday of the month.

• Specific day/week combination, relative to the end of themonth.Example: Last Friday of the month.

The RGP adds periods and calculates durations based on the day numberrelative to the start of the month. It is therefore strongly recommendedthat bill runs including rental generation operations are run on the samebasis, to avoid potentially inconsistent calculation of the day number.This requires the selection of a Repeat type of 'Month Day' whendefining the bill cycle schedule.

For information about usage of the separate schedule types, refer toChapter 7, Schedule Types.

If the appropriate settings were selected when the task or schedule wasdefined, after the task has been run, a message is received in a pop-upwindow (if the user is logged on); if the user is not logged on, an emailnotification is sent advising of completion of the task.

Each bill run is configured with a particular bill run type. Bill run typeshelp to determine the outcome of a bill run schedule and are definedusing the Bill Run Type Definition form.

Bill run types

Billing


The bill run type allows the user to specify the following for bill runsusing this specific type:

• Quality Assurance flag, which indicates whether the bill run isused for quality assurance purposes or not.

• Bill Run Validation, which specifies the entity validation that isused to configure the display of the general statistics for all billruns of this type. These statistics are displayed on the Generaltab of the Bill Run Detail form. Entity validation can also beused to specify the Schedule Name label on the Details tab.

• Operation Validation, which specifies the entity validation that isused to configure the display of the general statistics for all billrun operations associated with bill runs of this type.

• Currency, which indicates the currency in which billed orrevoked amounts are stored for bill runs of this type (and bill runoperations associated with it).

• Summary Function, which specifies the function that is used tosummarise the current state of a bill run after the current task orprocess is finished. The results of this function can be used, forexample, to populate the General Statistics fields on the Generaltab.

• Supported Tasks, which is the list of schedule types that can beperformed on bill runs of this type. Only these tasks will bedisplayed on the list of available operations in the PerformOperation window (accessible from the Bill Run Detail orCustomer Bill Run Detail forms).

The supported tasks list also allows compatible schedule types tobe filtered based on the operation status of the bill run, as well asestablishing whether particular operations can be revoked.

• Status Highlighting, which enables display characteristics forindividual bill run summaries.

Billing


Important schedule parameters for new bill runs include:

• Bill Run Type

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 beexecuted 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 errorsequals 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 usesfields from the CUSTOMER_NODE_TRE_V view. The order orpriority of the customers selected is byCUSTOMER_NODE_TRE_V.BILLING_PRIORITY and then byCUSTOMER_NODE_TRE_V BILLING_CONFIGURATION_CODE.

Once a bill run is set up using the Schedule Definition form, anychanges required in the schedule itself can be made by searching for andchanging the appropriate form.

A bill run schedule that was set up using the One-off Task Definitionform can be changed using the Task Details form, which is accessedfrom the Bill Run Detail form. The task date and times can be changedand the task re-submitted by clicking the Re-submit… button.

Once a bill run is actually executed, the details cannot be directlymodified. Additional operations can however be performed later (refer toPerforming an operation on a bill run later in this chapter).

Additional operations can be performed on existing bill runs for either abatch of customers or for a single customer:

• To perform an operation on a batch of customers, select thePerform Operation… button from the Bill Run Detail form todisplay the Perform Operation for Bill Run form.

• To perform an operation for a single customer, select thePerform Operation… button from the Bill Runs forCustomer form to display the Perform Operation forCustomer form.

Bill runscheduleparameters

Modifying a billrun

Performing anoperation on abill run

Billing


Both of these forms list the bill run operations that can be subsequentlyperformed. Selecting the appropriate operations from the list andpressing the Submit button creates a one-off task that prompts for anyadditional details before performing the requested operations.

A bill run that is in progress can be stopped by entering the appropriateexpression, including the function biBillRunStop&(), in theExpression Test form. To stop a bill run:

1. Select the Server Tasks ➩ Bill Runs option. The Bill RunSearch 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 RunList 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 (thisinformation is used to stop the bill run).

5. Select the Maintenance ➩ Data Definition ➩ ExpressionTest 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 theExpression field. For example:

{var lBillRunId& := 5673;var lLastModified~ := to_date('13/11/200114: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 isdisplayed 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 themanual Variables, Expressions, and Functions.

Stopping a billrun

Billing


A bill run operation or task, which has already been executed in aschedule, can be revoked using the schedule type 'Revoke Bill Run'. Forinformation about this schedule type, refer to Chapter 7, Schedule Types.Additionally, depending on the bill run type configuration, the PerformOperations window can be used to revoke individual operations. Formore information, refer to Performing an operation on a bill run earlierin this chapter.

Information on the results of a bill run is displayed on the Bill Run Detailform for that particular bill run. The form summarises the results of thebill run, as well as displaying errors for both the bill run (if it failed) orany individual operations on the bill run that failed.

Results for an individual customer node can be viewed by clicking theBill Run Details… button (Billing tab) on the Customer Detail form.

Techniques for correcting bill run errors are provided in CorrectingBilling Errors later in this chapter.

Invoice Data and ImagesTo 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 isdisplayed.

3. Double-click on the invoice in the list with an issue datematching the bill cycle. The Invoice Detail form is displayed.

4. Select the Transactions tab to view adjustments and paymentsthat have been received since the last invoice.

5. Select the Images tab and click the Invoice Image… button toview the invoice image; this requires the execution of a servertask and may take some time.

Display Types for Invoice ImagesConvergent Billing offers the ability to view different types of invoicesfrom the client. The image type extension, specified in the invoice, ismapped to a display image type in the DisplayImageType derivedattribute. This attribute can be altered to suit the invoice templates thatare 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

Revoking abilling task

Checking theresults

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 reportsBilling reports are defined for the installation of Convergent Billing. Formore information, refer to the Reports Guide.

There are two possibilities for invoice suppression:

• Suppress invoice generation in bill runs for particular customers.

It is possible to suppress invoices for individual customers,customer types, or groups of customers. For individualcustomers, this can be executed using direct updates on theCustomer Details form.

Invoices are suppressed for a specific type of customer using theCustomer Type form.

Invoices for customer groups or hierarchies are handled using aschedule. 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 separateschedule types, refer to Chapter 7, Schedule Types. Invoices canalso be suppressed for a specific type of customer using theCustomer 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 invoicehas already been generated in the last six months, the invoice canbe suppressed using invoice type expressions.

For more information on configuring invoice types, refer to theSystem Administration Guide.

Suppressinginvoicegeneration

Billing


Correcting Billing Errors

This section describes the techniques used to correct any errors that mayarise as the result of bill runs.

When creating bill runs, the number of errors permitted before the billrun is stopped can be specified on the Schedule Definition or the One-off Task Definition form in the Error Threshold parameter. If a bill runresults in the specified amount of errors, the errors can be fixed, theparticular operation can be revoked if necessary, and the bill runperformed again with only the outstanding operations performed. If aparticular operation failed the first time, the operation is automaticallyrevoked and performed again.

Once errors are generated, or a bill run schedule has failed, the followingmust be done:

1. View the Bill Run Detail form for the particular bill run anddetermine which operation or operations failed. Failedcustomers 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 anyerrors that are generated by executing a schedule of type 'Standard BillRun'. This type of bill run performs, by default, all standard billingoperations 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 correcterrors (revoke and re-do operations), it is highly recommended that theuser use the bill run process for this task. An individual bill run tiesseparate billing operations together in one process and ensures that theoperations are completed in the correct order with the correctprerequisites.

Billing


Did schedule fail?

Run a StandardBill Run schedule

Billing details OK?

Reason for incorrectdetails

Check schedule status

Schedule post-billingreconciliation reports andreconcile billing output

Complete the Bill Run

Check scheduleparameters and correctif necessary

Revoke the operation inerror (and any operationswhich succeeded it).If necessary, perform aRevoke Bill Run schedule(revokes the entire bill run).

Complete the Bill Run

Correct tariffs andre-rate appropriateevents

Correct Tariff/Subtotal/Customerdetails

No

View Bill Run Details

Yes

No

Correct printingproblem

Fix invoicetemplates

Invoices notprinted

Invoiceformat

incorrect

Ratedchargesincorrect

End

Yes

Billed chargesincorrect

Figure 3–2 Billing Error Flow Chart

Billing


Billing Schedule Types

Table 3–1 lists the schedule types that are available for billing tasks, foran entire bill run, with a brief explanation of each.

Table 3–1 Billing Schedule Types for Bill Runs

Name FunctionApply & AllocateInvoices

Applies invoices to the appropriatecustomer accounts for a specific bill runand allocates credit payments andadjustments.

Apply Invoices Applies invoices to the appropriatecustomer accounts for a specific bill run.

Complete Bill Run Completes a standard bill run, QA run, orpart thereof that has previously beeninterrupted, failed, or revoked.

Generate InvoiceImages

Generates invoice images for a specificbill run.

Print Invoices Prints invoices for a specific bill run.

Revoke Bill Run Revokes a standard bill run, QA run, orpart thereof.

Revoke InvoiceImages

Rolls back invoice images in the database.

Revoke Invoice PrintSettings

Revokes the ‘Printed’ flag, so that thebatch can be printed again.

Revoke Invoices Rolls back all invoice data and imagesassociated with the specified billing task.

Revoke Invoices(keep Rentals)

Revokes invoices and images, but keepsrental events, for a specific bill run.

Revoke RentalEvents

Revokes rental events.

Un-apply & De-allocate Invoices

Un-applies invoices and de-allocates anycredit payment and adjustment amounts.

Un-apply Invoices Un-applies invoices.

Billing


Table 3–2 lists the schedule types that are available for billing tasks, forindividual customers, with a brief explanation of each.

Table 3–2 Billing Schedule Types for Individual Customers

Name FunctionApply & AllocateInvoices forCustomer

Applies invoices for a specific customerand allocates credit payments andadjustments.

Apply Invoices forCustomer

Applies invoices for a specific customer.

Complete Bill Runfor Customer

Completes a standard bill run, QA run, orpart thereof that has previously beeninterrupted, failed, or revoked.

Generate InvoiceImages forCustomer

Generates invoice images for a specificcustomer.

Print Invoices forCustomer

Prints an invoice for a specific customer.

Revoke Bill Run forCustomer

Revokes a bill run for a specific customer.

Revoke InvoiceImages forCustomer

Revokes invoice images for a specificcustomer.

Revoke Invoice PrintSettings forCustomer

Clears the print settings for a specificcustomer.

Revoke Invoices(keep Rentals) forCustomer

Revokes invoices and images, but keepsrental events, for a specific customer.

Revoke Invoices forCustomer

Revokes invoice images, invoice details,and rental events for a specific customer.

Revoke RentalEvents for Customer

Revokes rental events for a specificcustomer.

Unapply & De-allocate Invoices forCustomer

Un-applies invoices and de-allocates anycredit payment and adjustment amount fora specific customer.

Unapply Invoices forCustomer

Un-applies invoices for a specificcustomer.

Billing


Table 3–3 lists the schedule types that are available for related billingtasks with a brief explanation of each.

Table 3–3 Related Billing Schedule Types

Name FunctionApply Transactions Applies future dated payments and

adjustments.

Billing Suppress Suppresses invoice generation forcustomer hierarchies, causing thesehierarchies to be skipped by schedulesrunning types such as 'Standard Bill Run'.

Billing Unsuppress Halts suppression of invoice generation.

Dunning LetterGeneration

Allows creation of dunning letters forcustomers with overdue accounts. Theletters are printed using the GOP.

General Bulk Outputby Task

Runs the General Bulk Output Process fora specific task.

General Bulk OutputProcess

Allows invoice or letter images to output toa printer or other output device. Refer toChapter 4, Batch Printing.

Invoice ReprintGeneration

Generates new invoice images forinvoices that have been flagged forreprinting.

Invoice View Image Used internally by Convergent Billing forviewing invoice images on request.

Quality AssuranceBill Run

Creates and executes a QA bill run for aset of customers associated with a givenschedule.

Revoke RentalEvents


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 ofthese values:

• Invoice

• Statement

• None.

Invoices are produced for every node in the billing schedule with areporting level of 'Invoice'. Invoices will automatically include, in thecalculated 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 chargesincurred by that node only.

Displayed invoice or statement details are almost completelyconfigurable using the parameters of thebiInvoiceReportAccount&() function (which is called in thegeneration 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 andstatement generation. The hierarchy involved is shown in Figure 3–3.

ABCBanking

CentralBranch

EastBranch

Loans

WestBranch

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 LevelABC Banking Root Invoice

East Branch Child ABC Banking Statement

West Branch Child ABC Banking Statement

Central Branch Child/Parent

ABC Banking Invoice

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

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

3. East Branch, West Branch, and Investments receive statements oftheir own charges.

4. Loans receives nothing.

Billing



Chapter 4Batch Printing

This chapter describes the General Output Process (GOP) and how itperforms the task of printing bulk information, such as dunning letters orinvoices, using tasks on the scheduler or information from previousbilling operations.

It also describes dunning letters (with its configuration) and how to set upa printing configuration. Printing configuration is based on the followingelements:

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 databaseof the query view and the document image; it also specifies anytable update required (for example, to flag a dunning letter ashaving been printed).

• Output Method, which consists of an Output Method Type andone or more Output Devices. If the data is split over two or moreoutput devices; it can also select output order (for example,dunning letter output might be ordered by state or province, or bypostal code).

Bill Run• Configuration item type INVOICE_PRINT.

Knowledge of UNIX, SQL, and the Convergent Billing database structureis required to carry out some of the tasks described in this chapter.Access to a server terminal to issue UNIX commands may also beneeded.

Batch Printing


Invoice Output using the Scheduler

The following schedule types can be used for the output of invoices ordunning letters using a schedule or an immediate task:

• General Bulk Output Process

Generates bulk output for a previous schedule (bill run, dunninggeneration, 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. Dunningletters are used to remind customers about unpaid accounts.

By using a schedule, a task can be run at specified intervals; animmediate task can run a single task immediately (for more information,refer to Chapter 6, Scheduling Server Tasks).

The GOP requires these schedule parameters for the schedule types'General Bulk Output Process' and 'General Bulk Output by Task':

• Schedule to output (General Bulk Output Process)

Schedule producing the images for processing. The imagesgenerated by the most recent task with 'Success' status are usedfor 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 componentsand configuration of the output method are described later in thischapter.

• 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, referto the System Administration Guide).

GOP scheduleconfigurationparameters

Batch Printing


• Percentage Unpaid (%)

Unpaid percentage of the total sum due that is required to triggera dunning letter; this can be used in combination with the DaysOverdue parameter.

• Days Overdue

Number of days the sum is overdue and which triggers a dunningletter; this can be used in combination with the PercentageUnpaid (%) parameter.

• Extension

File extension for the output file used when creating the report.

The GOP retrieves all the document images stored in the database by thespecified schedule's most recent task, then outputs them as instructed bythe output method. Images can be divided into as many batches asnecessary and each batch separately ordered and sent to a different outputdevice. The general flow of processing in the GOP is as follows:

1. The schedule ID parameter is used to identify the most recentlycompleted task for that schedule; only data produced during theexecution of that task is considered for output.

2. The output method type defined in the output method is used toidentify the database tables and views used to retrieve the datarequired, including the document images; it can also define anupdate performed on the database when an image has beenprocessed (for example, to flag that a dunning letter has beenprinted).

3. The output method is associated with a table of output criteria.This table may contain zero or more rows, and the criteriaretrieved include:

• The output device, which defines where the selecteddocument images are sent.

• An SQL WHERE clause, used to select which of theretrieved images use this output device.

• An SQL ORDER BY clause, used to specify the outputordering.

4. For each row in the criteria table, the GOP outputs the selecteddata to the specified output device, using the appropriateselection and sorting criteria.

5. Any images that remain after all the rows in the criteria tablehave been processed are then sent to a default output device,using a default ordering.

GOP scheduleprocessing

Batch Printing


If the criteria table is empty (that is, if the output is treated as a singlebatch), then the default output method and ordering apply to the wholebatch.

Invoice Output using a Bill Run

The General Output Process is able to print images generated by previousbilling operations. This is done by specifying the billing operation 'PrintInvoices' 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 determinedby the billing configuration set up in the customer configuration. Formore information on the Bill Run process, refer to Chapter 3, Billing.

The execution of the 'Print Invoices' operation requires a configurationitem of type INVOICE_PRINT. This configuration item must be createdprior to printing invoices. By default, the operation will look for the firstitem in the list of configuration items of type INVOICE_PRINT.

For more information on creating configuration items, refer to the SystemAdministration Guide.

The following parameters are required for setting up theINVOICE_PRINT item:OUTPUT_METHODDefines the processing that the images receive; the components andconfiguration, of the output method, are described later in this chapter.TMP_DIRDirectory for holding temporary files used by the GOP.ERROR_THRESHOLDMaximum number of non-fatal errors that can occur before the GOPterminates.MAX_CHILD_PROCESSESMaximum number of child processes for the GOP to use for the paralleloutput of images. If this parameter is greater than '1', the GOP is run inmulti-process mode. Setting a maximum number of child processescontrols the number of simultaneous GOP processes and therefore systemperformance. If parallel processing is used, the order in which invoiceimages are output may not match the order in which they were input.

This parameter is ignored for a batch if the selected output device isconfigured to concatenate images.

Bill runconfigurationparameters

Batch Printing


Note: Parallel processing between separate report, invoice, andstatement 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 theMAX_CHILD_PROCESSES attribute. However, other invoice andstatement images can be generated at the same time.

Bill runs are set up using the Scheduler. Several billing schedules fordifferent customers or groups of customers can be set up.

A new bill run schedule (that is, not completing an earlier run) uses oneof the following supported schedule types:

• Standard Bill Run, which generates an invoice that is sent out tocustomers.

Note: The Customer Batch Size (a bill run parameter) controlsthe number of customers that are passed to each bill run operationin turn. Setting this number will determine how many customerinvoices are produced at a time. For more information, refer toChapter 3, Billing.

• Quality Assurance Bill Run, which generates a temporary billthat is not sent to the customer and not paid; this can be used forquality assurance purposes and quoting. This bill run does notexecute 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.

In order to print bulk invoices from a bill run that has already beencompleted, the following steps must be performed:

1. Select the Server Tasks ➩ Bill Runs option.

2. Use the Bill Run Search form to select the correct bill run.

3. Once the Bill Run Detail form is open, click the PerformOperation… button. The resulting window displays details ofthe last operation and a list of available operations that can beexecuted 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 displayedwith the appropriate task already filled out for that particular billrun.

6. Ensure that the Customer Batch Size parameter isappropriately set. This parameter determines the number ofcustomers that are processed at a time.

Setting up a billrun to printinvoices orstatements

Printinginvoices on apreviously-completed billrun

Batch Printing


The graphic below displays the window for performing additionaloperations on a bill run.

Figure 4–1 Perform Operations on a Bill Run

In order to print invoices for a single customer (from a bill run that iscomplete), 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 displayedwith the appropriate task filled out for that particular bill run.

Single invoiceprinting

Batch Printing


Printing Document Images

This section describes the steps required to prepare for printing andchecking the output.

The following conditions should be met before billing output can begin(each site may have additional requirements):

• The number of documents awaiting output is established. Thisinformation can be obtained from the Results tab of the TaskDetail form for the task that generated the document images.

• Required reports are produced and analysed, and any problemsrectified.

• Any required legal or financial procedures are performed.

• Printers are configured, online, and containing sufficient andcorrectly loaded stationery.

• Other forms of output device, such as disk or tape, are online,ready, and contain sufficient storage for data volume. Factorsthat affect storage include:

− Number of documents

− Average number of pages in each

− File format used

− Presence of bitmaps or other large elements in thedocument

− Average level of compression achieved on files of thistype.

• Special arrangements made for subsequent processing ofdocuments (folding, putting in envelopes, posting, and so on).

An unsuccessful billing output run can be expensive; it can cause delaysin the billing process and subsequent collection of payments fromcustomers.

The following quality checks should be made before printed dunningletters 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 thecompany logo and address, correct?

Preparation forprinting

Checking theoutput

Batch Printing


• Do selected documents match the data in the database?

• Are there any extra procedures required at this stage? If so, havethey been carried out successfully?

Configuring Output Processing for the GOP

The output of the GOP reflects batch-oriented billing. The GOP isexecuted once per batch and this execution is repeated for each and everybatch. GOP Output is controlled by the output method selected as aparameter for the task. The output method consists of:

• An output method type, which defines the database views used toretrieve the data for output, and also defines any changes that theoutput 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 UNIXcommands, the device to which output is directed.

If an output method is given more than one output device, theneach device operates on a part of the output, specified by an SQLWHERE clause. Each section of the data can be sorted using itsown SQL ORDER BY clause.

This means that an output method can be configured to printinvoices for customers in the local area to a local printer, andinvoices for customers in other regions are spooled to magnetictape for processing by a print vendor. In either case, the invoicescould be produced in postal code order, if any bulk postingarrangements are required.

The output method type defines the source of the data that is printed. Itcan also update a database table, for example to set a flag showing that aninvoice has been printed. All types can be configured with an image typeof .spf, .tex, .txt, or .xml. Each of these (excluding .spf) can alsobe compressed using the .gz or the .Z format.

The options provided with Convergent Billing are shown in Table 4–1

Output methodtype

Batch Printing


Table 4–1 Singl.eView Convergent Billing Output MethodTypes

Name DescriptionPrintinvoices

Print invoices from an invoice run.Updates the INVOICE table.

Printdunningletters

Print dunning or promotional letters.Updates theCUSTOMER_NODE_CORRESPOND table.

Reprintinvoices

Reprint flagged invoices. Updates theCUSTOMER_NODE_CORRESPOND table.

Output method types can be defined or updated when the underlyingtables and appropriate access privileges are thoroughly understood. Thefollowing example uses the standard 'Print Invoices' output method typefor illustration.

The output device defines the UNIX command used to send the output tothe required device. A knowledge of UNIX, the Convergent Billingenvironment, and device configuration are required in order to work withoutput devices.

The output device includes the following information:

• The Output Image Type, which defines the format of the imagestored in the database.

• A Start Command, which is an optional UNIX command that isexecuted before a batch of images is output. The Start commandcan be used, for example, to instruct the printer to select thecorrect stationery.

• An optional Stop Command, which is an optional UNIXcommand that is executed once each batch is completed.

The Stop command can be used, for example, to advise anoperator that the batch print has finished. The Stop command canalso be used to track the batch number, or where in the entire runa particular batch happens to be.

• A Run Command. The two options Pipe images to runcommand? and Concatenate Images? are processed inconjunction with this option. The possible outcomes arespecified in Table 4–2.

Output device

Batch Printing


Table 4–2 Pipe and Concatenate Options

Option Selected ResultConcatenate The Run command is executed after all

images in the batch have been concatenatedinto $file.

Note: The only file type that can beconcatenated is .txt.

Pipe The output image is piped to the Runcommand.

Both The same as Pipe, except that the pipe is notclosed and re-opened between images.

Neither The Run command (taking $file as anargument) is executed after each image isoutput.

Two shell scripts are available for printing control:

• print_inv <texfile> <output_file>

This script takes an uncompressed TEX file containing adocument and generates a PostScript output file. If the TEX inputfile is specified as - the script reads TEX source from thestandard input. If the output file is specified as - the script sendsthe PostScript to the standard output. If an output filename is notgiven, it is generated from the TEX file name by replacing .texwith .ps.

• smb_lpr [-P <printer>] <file1> <file2> ...

This script sends files to a printer using the smb protocol. If theprinter is not named, the environment variable $PRINTER isused. If this variable is not set, the script exits with a failure. Ifno files are named on the command line, the standard input iscopied to the printer.

The script uses the two environment variables SMBHOST andSMBCLIENT to name the printer host and path to the smbclientexecutable respectively. Default values are supplied for each.The GNU Samba suite must be installed on the server for thiscommand to work.

Note: Samba may not be available on site.

Scripts foroutput

Batch Printing


Example 1: PostScript output through Samba to printer

The Run Command is executed after each image has been output to thedefault file ($file). The image is decompressed by zcat, converted toPostscript by print_inv and printed using the smb protocol on thenetwork printer named local_printer.

Example 2: Text output concatenated to file

The text output of all images sent to the GOP is concatenated in thedefault 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.

Output deviceexamples

Batch Printing


Note: The only Convergent Billing output file format that can beconcatenated is .txt.

Example 3: Images piped to the null device using cat

Images are piped to the cat command, which is redirected to the nulldevice. 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 tempwithin the current directory (the process needs authority to createand delete directories and files).

Batch Printing


• A Run command to copy PostScript versions of each file in theGOP output to that directory.

• A Stop command that executes the following once the batch iscompleted:

− Archives the directory and its contents in the default taroutput device (normally tape).

− Empties the temp directory.

− Removes the temp directory.

If files are sent to a print vendor for printing, this procedure can befollowed.

Note: When the GOP creates multiple output files, each is given aunique 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 forfiles of this type).

An output method is an object that brings together the various elementsrequired for printing. It allows selection of the order in which the outputis printed; for example, invoices printed by state and by postal code canbe chosen for ease of posting. Different output devices for different setsof invoices can be selected; for example, a different printer for each stateor region can be used.

The output method is a GOP parameter that needs defining whenscheduling printing tasks.

This example output method shows how the fields can be used:

Output methoddefinition

Output methodexample

Batch Printing


In this example, local invoices (postal_code >= 4000 ANDpostal_code < 5000) are printed locally, while others (specified inthe WHERE clause for the second line of the grid) are sent to a tararchive device. Printed invoices are ordered by postal code and customerID. Any invoice images not printed locally or archived are discarded, asspecified in the default output device (null).

Part 2The Transaction Engine

This part provides information on operational aspects of the ConvergentBilling Transaction Engine, used to interface Convergent Billing withother applications. This part consists of the following chapter:

• Chapter 5, The Transaction Engine (TRE)

Information about configuring transactions is given in the SystemAdministration Guide.

white text


Chapter 5The Transaction Engine (TRE)

The Transaction Engine (TRE) is a Convergent Billing component thatmanages client/server transactions. Convergent Billing uses a four-tierarchitecture, in which clients connect to the server by means of theTransaction Engine (TRE), which uses TUXEDO middleware.

• Clients, remote hosts, and external applications form the firsttier, using a workstation or remote functions to enter, inspect,and modify data, and initiate processes.

• The second tier consists of the system's expression-drivenconfiguration and the Transaction Engine (TRE). Configurationis used to reflect the customer's individual business logic. Thistier manages transactions initiated from the first tier and returnsresults to the first tier.

• The third tier contains both the Convergent Billing processes andthe TRE services that clients can use for core business functions.In addition, an Application Programming Interface (API) isavailable to provide other applications with access to TREfunctionality.

• The fourth tier in the Convergent Billing architecture is theOracle database, in which business and administrative data isstored.

The basic architecture is shown in Figure 5–1.

The Transaction Engine (TRE)


UNIX shell,Remote hosts

ExternalApplications

ORACLEDatabase

ServerProcesses

Configuration

TRETransaction

Engine

Services

1st tier:Presentation

2nd tier:Configuration/Business Logic

3rd tier:Core Engine

4th tier:Data Repository

Workstations

Figure 5–1 Singl.eView Convergent Billing Four-tierArchitecture

TRE functions are used when writing functions and expressions (for moreinformation, refer to the System Administration Guide).

Part 3Task Automation

This part provides information on using the Scheduler to automate servertasks, and on the types of schedule which can be defined. This partconsists of the following two chapters:

• Chapter 6, Scheduling Server Tasks

• Chapter 7, Schedule Types

white text


Chapter 6Scheduling Server Tasks

Most server tasks in Convergent Billing are run automatically, under thecontrol of the Scheduled Task Dispatcher (STD) process and the TaskLaunch and Monitor (TLM) process. The client workstation's schedulingfeatures are used to control these processes, collectively referred to as theScheduler.

The Scheduler is used to set up tasks that run regularly at pre-definedintervals, or tasks that run only once, either immediately or at a date andtime chosen. Once set up, these tasks run automatically at the chosentime without further intervention, and then notify the user on completion.

When setting up a schedule, an instance of Convergent Billing can bespecified to run the schedule. If an instance is not specified, the scheduleis run on the default instance defined for the Scheduler. (The defaultinstance is defined in the STD Configuration Item.)

This chapter describes how to define and modify schedules, and tomonitor the tasks created by the schedules.

Scheduling Server Tasks


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 whatparameters are passed to it.

When a schedule is defined and submitted, Convergent Billing createsone or more tasks that are queued until the date and time specified, whenthey run automatically. On completion of each task, a message is sent sothe user can verify that the task executed successfully.

Figure 6–1 shows a schedule and its tasks in diagrammatic form.

Schedule

Task N

Task 2

Task 1

Effective date

Effective date

Effective date

Time

First date

Last date

Task date

Task date

Now

Inte

rva

l

Figure 6–1 Schedule and Tasks



The following terms are used when defining a schedule:

Schedule NameEach schedule has its own schedule name.

DescriptionA schedule may optionally be given a textual description.

Schedule TypeEvery schedule is assigned a schedule type which defines the type of taskto create, the program that the schedule tasks runs, what parameters arerequired, and similar information (for more information, refer to Chapter7, Schedule Types).

Instance NameA schedule can optionally be given an instance name. By specifying aninstance name, tasks associated with the schedule can be run on a specificinstance of Convergent Billing. If an instance is not specified, the task isrun on the default instance defined for the Scheduler. The defaultinstance is defined in the STD Configuration Item. The Instance Namefield will be enabled only if the reference type ATA_INSTANCEcontains more than 2 rows.

Email AddressA schedule may optionally be given an email address that is notifiedwhen tasks associated with the schedule are completed.

Schedule StatusA schedule can be either 'Active' or 'Complete'. An active schedulecreates tasks as required; a complete schedule is effectively turned off,and cannot create tasks.

Preschedule CountDefines the number of advance tasks that the scheduler maintains; forexample, 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 issubmitted. 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 DateStart date and time for the first task; if this is earlier than the date andtime on which the schedule is submitted, then the first task runsimmediately.

Last DateLast date for which a task is created; the schedule's status then changes to'Complete'. If the last date is not defined, the schedule continuesindefinitely.

Terms used inscheduling



Effective DateEffective date is the date and time used by some tasks to retrieveinformation from the database; for example, a billing task may berequired to run in early September, but using the data for August. In thiscase, the effective date would be set to 31st August.

Repeat UnitsMultiplier to use in conjunction with the repeat type; for example, arepeat type of Month Day and a repeat unit of 2 means that tasks arescheduled every two months.

Repeat TypeRepeat interval for creating future tasks, such as day, week, or month;this is used in conjunction with the defined repeat unit (n in the followingexamples). 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 asthe start date.

• Month End Day – every nth month, using the same number ofdays from the end of the month as the start date.

• Month Start – every nth month, on the same day of the sameweek as the start date.

• Month End – every nth month, on the same day of the same weekas the start date, calculated back from the end of the month.

Task Start DateDate 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 passedwhen the schedule is submitted, when the task starts immediately);thereafter, the first date and the repeat factors control the start date.

Task Effective DateDate and time that may be used by the task to retrieve data from thedatabase, depending on the processing required by the task. For the firsttask in the schedule, this is the same as the schedule's effective date;thereafter, the task effective date is controlled by the schedule's effectivedate and the repeat factors.



Working with Schedules

The following sections describe how to work with schedules. The topicscovered 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 Billingwas installed. Before a new schedule is defined, check whether there isan existing schedule or one that can be modified to fit requirements.

Before a new schedule is defined, ensure that there is an existingschedule or one that can be modified to fit requirements. Schedules aredefined, maintained, and modified using the Schedule Definition form.

A task with a 'Completed' status can be resubmitted by clicking the Re-submit button on the Task Detail form. A pop-up message asks forconfirmation.

This action sets the task status back to 'Pending' without changing thestart date. When the STD receives the re-submitted task, it finds that thestart 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 usingthe Update button on the toolbar to modify the information on theDetails tab, including the Start Date and Effective Date entries.

Changing frequency can cause complications if a large number of tasksare pending for the old frequency. To minimise the number of pendingtasks and prevent complications, use a preschedule count of 1 whendefining schedules.

Submitting aschedule

Re-submitting atask

Changing thefrequency of aschedule



A schedule that is no longer required can be deleted, but any pendingtasks will also be deleted. All tasks must be completed before deletingthe schedule.

At some future time, a particular schedule may be required. It isadvisable to stop the schedule, rather than delete it.

Deleting aschedule


Chapter 7Schedule Types

A schedule task uses the schedule type to determine what program to runand how to run it. The schedule type also defines the parameters that theuser needs to provide when a schedule of this type is defined.

This chapter describes the schedule types provided with the ConvergentBilling base installation, including the server command that the taskexecutes, and any parameters required. It also provides information ondefining 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 theschedule type runs, including:

− Any required command line options.

− Any parameters the user needs to pass.

• An understanding of reference types, attribute types, and entityvalidation, required for the definition of user parameters (formore information, refer to the Customer Care ConfigurationGuide).

Note: The server commands are included for reference information only.For more information about the server command parameters, refer to themanual System Administration Guide.

Schedule Types


Table 7–1 lists the schedule types supplied with the Convergent Billingbase installation; report schedule types are not included (for moreinformation on these, refer to the Reports Guide).

Table 7–1 Schedule Types Summary

Schedule Type DescriptionApply & AllocateInvoices

Applies invoices for a specific bill run andallocates credit payments andadjustments.

Apply & AllocateInvoices forCustomer

Applies invoices for a specific customerand allocates credit payments andadjustments.

Apply Invoices Applies invoices for the last bill run on thespecified bill cycle schedule.

Apply Invoices forCustomer

Applies invoices for a specific customer.

Apply Transactions Applies future dated payments andadjustments.

Archive Archives selected tables and other data.

Billing Suppress Suppresses invoice generation forcustomer hierarchies, causing thesehierarchies to be skipped by schedulesrunning types such as 'Complete BillRun'.

Billing Unsuppress Halts suppression of invoice generation.

Complete Bill Run Completes a standard bill run, QA run, orpart thereof that has previously beeninterrupted, failed, or revoked.

Complete Bill Runfor Customer

Completes a standard bill run, QA run, orpart thereof that has previously beeninterrupted, failed, or revoked for aspecific customer.

Contract Cancel /Notify

Cancels expired contracts and/orgenerates expiry warnings.

Create Partitions Creates a set of partitions in the CHARGE,NORMALISED_EVENT, orSUBTOTAL_RATING_VALUE table.

DIL Validation Validates DIL definitions.


Generates letters for customers withoverdue invoice payments.

ECP Command Executes an expression.

Schedule Types


Schedule Type DescriptionExplain BGPHierarchy Passes

Generates an explanation of thecustomer hierarchy passes the BGPperforms on the specified customers.

Full DatabaseValidation

Runs the full database validation process.

General Bulk OutputBy Task

Run the General Bulk Output Process bytask ID.

General Bulk OutputProcess

Generates output for a previous schedule(bill run, dunning generation, or invoicere-print).

Generate InvoiceImages

Generates invoice images for a specificbill run.

Generate InvoiceImages forCustomer

Generates invoice images for a specificcustomer.

Invoice GenerateImage

Generates the invoice image for a singleinvoice.

Invoice Print Image Prints or re-prints the image of a singleinvoice.


Generates the data required to reprint aset of invoices. The GOP must be run ona separate schedule to re-print theinvoices.

Invoice View Image Generates the viewing image file in anysupported format for the source filespecified by the Invoice ID.

PartitionMaintenance

Runs the Table Partition Maintenanceschedule.

Print Invoices Prints invoices for a specific bill run.

Print Invoices forCustomer

Prints an invoice for a specific customer.

Purge Error Events Purges error events using selectioncriteria.

Purge Events (nonError)

Purges normalised events and charges,using selection criteria.

Purge Files Deletes files from a given directory olderthan the specified date.

Quality AssuranceBill Run

Creates and executes a QA bill run for aset of customers associated with a givenschedule.

Schedule Types


Schedule Type DescriptionRate Files Rates files in an ENM's data directory

that are older than the effective date.

Re-analyze tables Re-computes optimiser statistics for alltables.

Re-rate Error Events Re-rates a set of error events that havebeen assigned to a file for re-rating.

Re-rate Error Events(bulk)

Re-rates a set of error events usingselection criteria.


Re-rates a set of normalised events andcharges using selection criteria.

Re-rate File Re-rates the set of events from anormalised event file that weresuccessfully rated.

Reconfigure Auditing Re-generates triggers based on thespecification of all AUDIT_TABLEconfiguration items.


Reprocesses error events associated withreal-time rating feeds that use ratingsubtotals.

Reprocess Events Reprocesses normalised events thathave associated rating subtotals.

Revoke Bill Run Revokes a standard bill run, QA run, orpart thereof.

Revoke Bill Run forCustomer

Revokes a bill run for a specific customer.

Revoke Event File Revokes all normalised events, errorevents, and charges for a file. The fileremains in the archive directory.


Revokes all normalised events, errorevents, and charges for a file, andreplaces the file in the data directory.


Deletes all invoice images for the last billrun in the specified bill cycle schedule.


Revokes invoice images for a specificcustomer.

Revoke Invoice PrintSettings

Revokes invoice print settings.

Revoke Invoice PrintSettings forCustomer

Clears the print setting for all invoices onthe specified schedule, so that the entirebill run can be printed again.

Schedule Types


Schedule Type DescriptionRevoke Invoices Deletes all invoices generated in the last

bill run for the specified bill cycleschedule.


Revokes invoices and images, but keepsrental events, for a specific bill run.

Revoke Invoices(keep Rentals) forCustomer

Revokes invoices and images, but keepsrental events, for a specific customer.

Revoke Invoices forCustomer

Revokes invoice images, invoice details,and rental events for a specific customer.

Revoke RentalEvents


Revoke RentalEvents for Customer

Revokes rental events for a specificcustomer.

RevokeReprocessed File

Revokes a reprocessed file and un-assigns all normalisation error eventsassociated 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 andmatches a given file pattern.

UnApply &Deallocate Invoices

De-allocates any credit payment andadjustment amounts.

UnApply &Deallocate Invoicesfor Customer

De-allocates any credit payment andadjustment amount for a specificcustomer.

UnApply Invoices Un-applies invoices.

UnApply Invoices forCustomer

Un-applies invoices for a specificcustomer.

Unarchive Recovers archived data.

Update AccountUnbilled

Validates and updates the unbilledamount of an account.

Note: This script should only be runwhen there is no rating activity on thesystem, otherwise accounts may beupdated incorrectly.

Schedule Types


Schedule Type DescriptionUpdate ChargeCategories

Generates new charge categories for anyservices or customer nodes that needthem. Only needs to be run if newcharge categories are assigned toproducts that are in use.

Update InvoiceUnbilled

Validates and updates the unbilledamount of an invoice.

Update Lists Generates new empty derived attributearrays for any services or customernodes that need them. Only needs to berun if new derived attributes are assignedto products that are in use.

Verify ChargePartition

Verifies and updates details on chargesstored in the CHARGE table.

Verify ChargePartition Range

Verifies that the specified partitions fallwithin a specified date range.

Schedule Types


Schedule Type Details

This section describes schedule types provided with the ConvergentBilling base installation; report schedule types are not described (formore information on these, refer to the Reports Guide).

The following conventions are used when describing the type ofparameters:

ListSelect the required value from a drop-down list.

TextEnter a text value in upper or lower case as required.

TEXTEnter a text value in upper case only.

IntegerEnter a whole number.

Yes/NoSelect either 'Yes' or 'No' from a drop-down list.

[Data Type]Data types enclosed in square brackets are optional.

Schedule Types


This schedule type applies invoices for a specific bill run and allocatesany credit payments and adjustments.

Server commandbill_run_wrapper –c 50 60 40

Schedule Type Parameters

Parameter Type DescriptionBill Run Id Integer Identifier of the bill run for which

this operation is beingperformed.

Customer BatchSize

Integer Maximum allowable number ofroot customer nodes to beprocessed by a single process atany given time.

Number of ChildProcesses

Integer Number of child processes tohandle the customer batches.

Error Threshold Integer Maximum number of customerswith errors. The bill run will failonce it reaches or exceeds thisnumber.

Apply & AllocateInvoices

Schedule Types


This schedule type applies invoices for a specific customer on a bill run,and allocates any credit payments and adjustments.

Server commandbill_run_cust_wrapper -c 50 60




Customer Node Id Integer Identifier of the customer forwhich this operation is beingperformed.

Apply & AllocateInvoices forCustomer

Schedule Types


This schedule type applies invoices for the last bill run on the specifiedbill cycle schedule.





Customer BatchSize





Apply Invoices

Schedule Types


This schedule type applies invoices for a specific customer on a bill run;invoice allocation is not performed.

Server commandbill_run_cust_wrapper –c 50 50


Parameter Type DescriptionBill Run Id Integer Identifier of the bill run for

which this operation is beingperformed.


Apply Invoicesfor Customer

Schedule Types


This schedule type applies future-dated payments and adjustments, and isable to re-calculate multi-currency transactions using current exchangerates.

Server commandapply_transactions


Parameter Type DescriptionRederive Multi-CurrencyTransactions

List Set to ‘Yes’ if multi-currencytransactions are to have theiramounts and allocations re-calculated, based on the currentexchange rates. Otherwise, set to‘No’.

Notes

If multi-currency transactions are newly calculated and re-inserted, theinvoice and RT allocations are performed automatically. Multi-currencypayment transactions having associated payment items are NOT re-inserted under these conditions.

ApplyTransactions

Schedule Types


This schedule type archives selected tables and other data.

Server commandclient_archive


Parameter Type DescriptionArchive Type List List of archive types.

Archive filename

Text Name of the archive export file.

Purge data? Yes/No Select 'Yes' if the data is to bepurged after it is archived.

Rows percommit

[Integer] Number of rows inserted orupdated before a commit. If notspecified, the commit is on atable-by-table basis.

Where Clause [Text] SQL WHERE clause for selectingdata.

Delete existingarchive data?

Yes/No Select 'Yes' to delete any existingarchive data before starting thisarchive.

ArchiveFormat

[List] Select the desired archive data.

Report missingdata?

Yes/No Select 'Yes' to report missingdata.

Preventduplicatedata?

Yes/No Select 'Yes' to prevent duplicatedata.

Other archiveflags

[Text] Enter any other archive flags notdirectly supported by prompts.

Archive Sub-type x 4

[List] List of archive sub-types.

Archive

Schedule Types


This schedule type suppresses invoice generation for the specifiedcustomer hierarchies, causing these hierarchies to be skipped byschedules using types such as 'Standard Bill Run', 'Quality AssuranceBill Run', and 'Complete Bill Run'.

Server commandbilling_suppress


Parameter Type DescriptionSuppress UntilIssue Date

Date The date on or after which invoicegeneration will recommence.

Suppress BillCycle Count

Integer The number of bill cycles forwhich invoice generation will besuppressed.

CustomerNode Name

[Text] Customer hierarchies having oneor more customers with a namematching this pattern.

CustomerNode TypeName

[List] Customer hierarchies having oneor more customers with a nodetype name matching this name.

Account Name [Text] Customer hierarchies having oneor more prime account namesmatching this pattern.

Account TypeName

[List] Customer hierarchies having oneor more prime accounts of thistype.

Service Name [Text] Customer hierarchies having oneor more services with a namematching this pattern.

Network Name [Text] Customer hierarchies having oneor more services with a networkname matching this pattern.

Service TypeName

[List] Customer hierarchies having oneor more services of this type.

Where Clause [Text] Additional selection criteria in theform of an SQL WHERE clause(minus the WHERE keyword),based on theCUSTOMER_NODE_TRE_V view.

Billing Suppress

Schedule Types


NotesOnly one of the two parameters, 'Suppress Until Issue Date' or 'SuppressBill Cycle Count', should be specified, in order to determine wheninvoice generation should recommence. If both parameters are enteredand they do not match, the date parameter will be taken as default.

Schedule Types


This schedule type removes any 'suppressions' of invoice generation forthe specified customer hierarchies.

Server commandbilling_suppress -r -v


Parameter Type DescriptionCustomerNode Name

[Text] Customer hierarchies having oneor more customers with a namematching this pattern.

CustomerNode TypeName

[List] Customer hierarchies having oneor more customers with a nodetype name matching this name.

Account Name [Text] Customer hierarchies having oneor more prime account namesmatching this pattern.

Account TypeName

[List] Customer hierarchies having oneor more prime accounts of thistype.

Service Name [Text] Customer hierarchies having oneor more services with a namematching this pattern.

Network Name [Text] Customer hierarchies having oneor more services with a networkname matching this pattern.

Service TypeName

[List] Customer hierarchies having oneor more services of this type.

Where Clause [Text] Additional selection criteria in theform of an SQL WHERE clause(minus the WHERE keyword),based on theCUSTOMER_NODE_TRE_V view.

BillingUnsuppress

Schedule Types


This schedule type completes a standard bill run, quality assurance run,or part thereof that has previously been interrupted, failed, or revoked.

Server commandbill_run_execute -c


Parameter Type DescriptionBill Run Id Integer ID of already-scheduled bill run.

FromOperation

List Start of range of failed/interruptedbilling run.

To Operation List End of range of failed/interruptedbilling run.

PrerequisiteOperation

List Prerequisite billing operation. Ifthis operation lies outside of therange of the 'To' and 'From'operations, then only customernodes for this bill run which havesuccessfully completed thisoperation (taking into account anyrevoking) will be eligible.

CustomerBatch Size


Number ofChildprocesses


ErrorThreshold

Integer Maximum number of customerswith errors. The bill run will failonce it reaches or exceeds thisnumber.

Where Clause [Text] Additional selection criteria in theform of an SQL WHERE clause(minus the WHERE keyword),using fields from theCUSTOMER_NODE_TRE_V view.

Complete BillRun

Schedule Types


This schedule type completes a standard bill run, quality assurance run,or part thereof that has previously been interrupted, failed, or revoked fora specific customer on a bill run.

Server commandbill_run_cust -c


Parameter Type DescriptionBill Run Id Integer Identifier of the already

scheduled bill run.


From Operation List Start of the range offailed/interrupted bill run.

To Operation List End of the range offailed/interrupted bill run.

Complete BillRun forCustomer

Schedule Types


This schedule type cancels expired contracts and/or generates expirywarnings.

Server commandupdate_contracts


Parameter Type DescriptionContract Type List Contract type to be cancelled or

notified.

CancelExpiredContracts?

Yes/No Select 'Yes' to cancel contractsthat have expired.

CancellationNotificationFunction

Text Notification function used togenerate cancellation messages.

Re-negotiateNotificationFunction

Text Notification function used togenerate renegotiation messages.

ExpiryNotificationFunction

Text Notification function used togenerate expiry messages.

RepeatFrequency

Integer Number indicating how oftencontract notification messages aregenerated.

Repeat Unit List Time unit indicating how oftencontract notification messages aregenerated.

Max Errors Integer Maximum number of errors toignore before task fails. If thisparameter is not entered, thescript will stop on the first errorencountered. If no message isgenerated, no update will beperformed for that contract(including cancellation where amessage function has beenspecified).

ContractCancel/Notify

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-negotiateNotification Function, or Expiry Notification Functionparameters must be specified.

• The Cancellation Notification Function parameter can only bepassed if Cancel Expired Contracts? is set to 'Yes'.

• The functions specified by the Cancellation NotificationFunction parameter, Renegotiate Notification Functionparameter, and Expiry Notification Function parameter must beremote functions with an application environment of 'Any', acontext of 'Any', and take the following parameters:

– TaskQueueId&

– EffectiveDate~

– ContractId&.

• The default remote functions to generate cancellationnotifications, re-negotiation reminder, and expiry warnings arebiContractCancelNotice&(), biContractReneg&(), andbiContractExpiry&().

• All date checks and updates are done according to the effectivedate passed to the script. The exception is setting of the reminderdates and determining if a re-reminder is necessary, these aredone using the current date and time. When updating a contractto cancel, the status is set to 'Cancelled' and theEFFECTIVE_START_DATE is set to the effective date and timepassed.

Schedule Types


This schedule type creates a set of partitions in the CHARGE,NORMALISED_EVENT, or SUBTOTAL_RATING VALUE table.

Server commandcreate_partitions


Parameter Type DescriptionTable topartition

List Select the table for whichpartitions are to be generated.

Start date offirst partition

Date Start date of the first partition tobe created.

Number ofpartitions

Integer Number of partitions that are to becreated.

Duration ofeach partition

Integer Duration of each created partitionin the selected units.

Units List Units of duration for each createdpartition.

The create_partitions script creates a set of entries in the partitiondefinition for the specified <base table> and does the following:

• Deletes any existing entry in the partition definition for thespecified <base table> (CHARGE, NORMALISED_EVENT, orSUBTOTAL_RATING_VALUE).

• Generates <quantity> partitions for the base table with namesof <base_table>_P<partition_number> (where<partition_number> starts at 1). The first partition is givena FROM_CHARGE_START_DATE of <start_date>. Allpartitions including the last are given a duration of <duration><units> (where <units> can be Days (0), Weeks (1) orMonths (2)). The last partition is given aTO_CHARGE_START_DATE of 30/12/9999 23:59:29.

• The dbrebuild script is executed to re-generate table definitionscripts. If the environment is configured appropriately, (forexample, the ATA_PARTITION environment variable is set to anon-zero value) this includes generating the SQL to create the setof partitions specified by this script.

Create Partitions

Schedule Types


NotesFor the partitions to be created, or recreated in the database, dbsyncmust be executed from the command line. If there is a significantquantity of data already in <base_table>, then this data should beexported and <base_table> truncated prior to running dbsync. The<base table> can then be imported into the newly created set ofpartitions.

Sizing and tablespace information for these partitions and their associatedindexes 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 ithas been decided to make major changes in the partitioning strategy (forexample, changing the duration and quantity of the number of partitionsin a table). For regular partition maintenance operations (dropping,adding, and archiving partitions), the update_partitions scriptshould be used.

The last partition is deliberately not given an end date of the end of timeto allow for the efficient rotation of partitions. The end date of the lastpartition should be some time in the future to minimise the risk ofreceiving events for which there is no valid partition.

Schedule Types


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

Server commanddil

Schedule Type ParametersNone.

DIL Validation

Schedule Types


This schedule type generates letters for customers with overdue invoicepayments, but does not print the letters. Printing should be done by aschedule of the 'General Bulk Output Process' or 'General Bulk Output byTask' type.

Server commanddunning


Parameter Type DescriptionDunningTemplate

List TEX template used for building theletters.

PercentageUnpaid (%)

[Integer] Unpaid percentage that triggersthe letter generation.

Days Overdue [Integer] Number of days overdue whichtriggers the letter generation.

Extension List Select a file extension for theoutput file used when creating thereport.


Schedule Types


This schedule type executes an expression.

Server commandecp_cmd


Parameter Type DescriptionExpression Text Expression to be executed.

ECP Command

Schedule Types


This schedule type generates an explanation of the customer hierarchypasses the BGP performs on the specified customer.

Server commandbgp_explain


Parameter Type DescriptionBill CycleSchedule

List List of all current billing cycleschedules.

CustomerNode Name

Text Name of the customer in thepass.

Explain BGPHierarchyPasses

Schedule Types


This schedule type runs the full database validation process.

Server commanddvp


Full DatabaseValidation

Schedule Types


This schedule type runs the General Bulk Output Process for a given task.For example, this type can be used to print invoice images marked forreprinting or letters generated by the dunning process.

Server commandgop -q


Parameter Type DescriptionTask Integer Task ID that specifies the

entities requiring bulk output.

Output Method List Specifies the output method,such as invoice generation ordunning letters. This is amandatory parameter.

Directory fortemporary data

Text Directory to store temporarydata and working files. This is amandatory parameter.

General BulkOutput By Task

Schedule Types


This schedule type generates output for a given previous schedule (billrun, dunning generation, or invoice reprint).

Server commandgop


Parameter Type DescriptionSchedule tooutput

List Schedule from which to select thelast successful task for output.

Output Method List Output method to use (refer toChapter 4, Batch Printing).

Directory fortemporary data

Text Directory to store temporary dataand working files.

General BulkOutput Process

Schedule Types


This schedule type generates invoice images for a specific bill run.





Customer BatchSize




Error Threshold Integer Maximum number of customernodes with errors. The bill runwill fail once it reaches orexceeds this number.

GenerateInvoice Images

Schedule Types


This schedule type generates invoice images for a specific customer on abill run.






GenerateInvoice Imagesfor Customer

Schedule Types


This schedule type generates the invoice image for a single invoice.

Server commandgenerate_image


Parameter Type DescriptionInvoiceIdentifier

Integer Invoice ID needed as the argumentfor the Invoice Viewing Processmodule.

SequenceNumber

Integer Sequence number.

InvoiceGenerate Image

Schedule Types


This schedule type prints or reprints the image of a single invoice.

Server commandprint_image



Integer Invoice ID needed as the argumentfor Invoice Viewing Processmodule.

SequenceNumber

Integer Sequence number.

Output Device List Output device (printer).

Invoice PrintImage

Schedule Types


This schedule type generates the data required to reprint a set of invoices,using the original output method. The GOP must be run on a separateschedule to reprint the invoices.

Server commanddunning -r



Schedule Types


This schedule type generates the viewing image file in any supportedformat for the source file specified by the Invoice ID. This schedule typeis only used internally by Convergent Billing.

Server commandivp



Integer Invoice ID needed as the argumentfor the Invoice Viewing Processmodule.

Number Integer Sequence number.

Output ImageType

List Output Image Type.

Invoice ViewImage

Schedule Types


This schedule type runs the Table Partition Maintenance schedule.

Server commandupdate_partitions


Parameter Type DescriptionArchiveDirectory

Text Directory in which archived filesare placed.

The update_partitions script is used to update a set of partitions inaccordance with the specified operations in the partition definitions. Thescript operates on rows in the partition definition that have theSCHEDULE_ID associated with <task_queue_id>, anOPERATION_OUTCOME_CODE of pending (1), and either the specifiedTASK_QUEUE_ID or a TASK_QUEUE_ID of null.

Partitions with a REQUIRED_OPERATION_CODE specified have thatoperation performed. If both archiving and truncating are requested, thenarchiving is performed prior to truncation. TheREQUIRED_OPERATION_CODE is cleared on completion.

Partitions with a DESIRED_STATUS_CODE different from theirACTUAL_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 exportfile, 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 theDESIRED_STATUS_CODE, and all date fields are cleared.

The remaining pending partitions are processed in order of theirDESIRED_TO_CHARGE_START_DATE, with the newest partition beingprocessed first.

For each partition processed, the following steps are performed:

• If the partition is not new, its contents are exported into atemporary export file.

• If the partition is not new, it is dropped.

PartitionMaintenance

Schedule Types


• If this partition does not have the highestTO_CHARGE_START_DATE, then a Split Partition command isgenerated for the next partition with a value equal to theDESIRED_TO_CHARGE_START_DATE of the current partition. Ifthe partition is the last, then an Add Partition command isgenerated.

• The contents of the old partition are imported back into the table.

• All local indexes on the split partitions (or added partition) arerenamed, their storage characteristics altered appropriately, andthe indexes rebuilt.

• The actual dates and status are set to equal the desired dates andstatus.

The dbrebuild script is executed to regenerate the partition definitionscripts. If the environment is configured appropriately, (for example, theATA_PARTITION environment variable is set to a non-zero value) thiswill include generating the SQL to create the set of partitions as specifiedby their current actual status.

The OPERATION_OUTCOME_CODE is updated to 'Running' andTASK_QUEUE_ID updated to <task_queue_id> during each operationon 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 butmore 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 standardoutput.

CaveatsOracle's import command can output numerous warnings during animport of a partition. All warnings about entities already existing can beignored.

The update_partitions script uses the exit code from the importcommand to check for success or failure; therefore, it is possible that datamay not have been imported successfully, but the update_partitionsscript continues processing. For this reason, it is recommended thatarchives of data be performed prior to changes that require the data to beexported and re-imported.

Schedule Types


This schedule type prints invoices for a specific bill run.





Customer BatchSize





Print Invoices

Schedule Types


This schedule type prints invoices for a specific customer on the bill run.






Print Invoicesfor Customer

Schedule Types


This schedule type purges normalisation error events, using selectioncriteria.

Server commandreprocess_bulk_assign –p


Parameter Type DescriptionENM Process [List] ENM process used to process the

purged events.

Native File Type [List] Normalised event file type used topurge the events.

File ProcessStart Date

[Date] Earliest file processing date forselecting files.

File ProcessEnd Date

[Date] Latest file processing date forselecting files.

Base Event FileName

[List] Original source file for events tobe purged.

Event Start Date [Date] Earliest event start date for eventsto be purged.

Event End Date [Date] Latest event end date for events tobe purged.

Error MessageId

[List] Error message identifier for eventsto be purged.

Event Source [Text] Switch or mediation system thatoriginated the events for purging.

Event Type [List] Normalised event type of theevents to be purged.

File Type [List] Normalised event file type of theevents to be purged.

File RecordStart Nr

[Integer] File record number of the firstevent to be purged.

File Record EndNr

[Integer] File record number of the lastevent to be purged.

C Party Id [Text] Chargeable party whose eventsare to be re-rated.

Purge ErrorEvents

Schedule Types


Parameter Type DescriptionEvent WhereClause

[Text] SQL WHERE clause on theNORMALISED_EVENT_ERROR tableto select events to be purged.

File WhereClause

[Text] SQL WHERE clause on theNORMALISED_EVENT_FILE table toselect events to be purged.

Schedule Types


This schedule type purges normalised events using selection criteria.

Server commandreprocess_bulk_assign –n –p


Parameter Type DescriptionENM Process [List] ENM process used to process the

purged events.

Native FileType

[List] Normalised event file type used topurge the events.


[Date] Earliest file processing date forselecting events for purging.


[Date] Latest file processing date forselecting events for purging.

Base EventFile Name

[List] Original source file for events to bepurged.

Event StartDate

[Date] Earliest event start date for events tobe purged.

Event EndDate

[Date] Latest event end date for events tobe purged.

Tariff [List] Tariff used to rate the events to bepurged.


Event Type [List] Normalised event type of the eventsto be purged.

File Type [List] Normalised event file type of theevents to be purged.

File RecordStart Nr

[Integer] File record number of the first eventto be purged.

File RecordEnd Nr

[Integer] File record number of the last eventto be purged.

C Party Id [Text] Chargeable party whose events areto be re-rated.

Event WhereClause

[Text] SQL WHERE clause on theNORMALISED_EVENT table to selectevents to be purged.

File WhereClause

[Text] SQL WHERE clause on theNORMALISED_EVENT_FILE table toselect events to be purged.

Purge Events(non Error)

Schedule Types


This schedule type deletes specified files older than the task's effectivedate from a given directory.

Server commandpurge_files


Parameter Type DescriptionDirectory Text Directory to be purged.

File Pattern Text File pattern of files to be removed.

Purge Files

Schedule Types


This schedule type creates and executes a quality assurance bill run for aset of customers associated with a given schedule.

Server commandbill_run_execute -q


Parameter Type DescriptionBill RunType(QA)

List Type of bill run, which defines therun’s accessible list of operations.

Schedule List Associated schedule ID for bill runto be checked.

FromOperation

List Starting operation code for bill run.

To Operation List Ending operation code for bill run.

CustomerBatch Size

Integer Maximum allowable number of rootcustomer nodes to be processedby a single process at any giventime.

Number ofChildProcesses


ErrorThreshold



QualityAssurance BillRun

Schedule Types


This schedule type rates files in an ENM's data directory that are olderthan the task effective date.

Server commandrate_files


Parameter Type DescriptionENM 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 theevent file.

ENM EventType

List Normalised event type of theevents to be processed.

Event Source Text Event source to associate with theevent.

Rate Files

Schedule Types


This schedule type recomputes optimiser statistics for all tables.

Server commanddbanalyze


Re-analyzetables

Schedule Types


This schedule type re-rates a set of error events that have been assignedto a file for re-rating.

Server commandreprocess_file_events -r


Parameter Type DescriptionRe-rated filename

Text File name of the file to be re-rated.

ENM Process List Number of the ENM process usedfor rating.

Native FileType

List Normalised event file type to use tore-rate the event.

Re-rate ErrorEvents

Schedule Types


This schedule type re-rates normalisation error events, using selectioncriteria.

Server commandreprocess_bulk_assign


Parameter Type DescriptionENM Process List ENM process to use for rerating the

events.

Native FileType






Base EventFile Name

[List] The original source file for events tobe re-rated.

Event StartDate

[Date] Earliest event start date for eventsto be re-rated.

Event EndDate

[Date] Latest event end date for events tobe re-rated.

ErrorMessage Id

[List] Error message identifier for eventsto be re-rated.


Event Type [List] Normalised event type of the eventsto be re-rated.

File Type [List] Normalised event file type of theevents to be re-rated.

File RecordStart Nr

[Integer] File record number of the first eventto be re-rated.

File RecordEnd Nr

[Integer] File record number of the last eventto be re-rated.

CPartyId [Text] Chargeable party whose events areto be re-rated.

Re-rate ErrorEvents (bulk)

Schedule Types



[Text] SQL WHERE clause on theNORMALISED_EVENT_ERROR table toselect events to be re-rated.

File WhereClause

[Text] SQL WHERE clause on theNORMALISED_EVENT_FILE table toselect events to be re-rated.

Schedule Types


This schedule type re-rates normalised events and normalised errorevents, using selection criteria. All charges are regenerated.

Server commandreprocess_bulk_assign –n


Parameter Type DescriptionENM Process List ENM process to use for rerating the

events.

Native FileType






Base EventFile Name

[List] Original source file for events to bere-rated.

Event StartDate

[Date] Earliest event start date for eventsto be re-rated.

Event EndDate

[Date] Latest event end date for events tobe re-rated.

ErrorMessage Id

[List] Error message identifier for eventsto be re-rated.

Tariff [List] Tariff used to rate the events to bere-rated.


Event Type [List] Normalised event type of the eventsto be re-rated.

File Type [List] Normalised Event File type of theevents to be re-rated.

File RecordStart Nr

[Integer] File record number of the first eventto be re-rated.

File RecordEnd Nr

[Integer] File record number of the last eventto be re-rated.


Schedule Types



[Text] SQL WHERE clause on theNORMALISED_EVENT table to selectevents to be re-rated.

File WhereClause

[Text] SQL WHERE clause on theNORMALISED_EVENT_FILE table toselect events to be re-rated.

Schedule Types


This schedule type re-rates the set of events from a normalised event filethat were successfully rated.

Server commandreprocess_file_events –n


Parameter Type DescriptionNormalisedEvent FileName

List List of the normalised event filesavailable.

ENM Process List Number of the ENM process to usefor rerating.

Native FileType


Re-rate File

Schedule Types


This schedule type regenerates triggers based on the specification of allAUDIT_TABLE configuration items.

Server commanddbtrigger


ReconfigureAuditing

Schedule Types


This schedule type examines the current entity validation configurationand generates derived information about it into a number of other tables.This derived information is used to display summary of change detailsabout CSR entities, and by certain reports such as the Call Detail DisplayReport (CDDR).

This schedule type should be run as a one-off task whenever changes aremade to the entity validation configuration.

Server commandrun_sqr_script rrrt


ReportReference Type(RRRT)

Schedule Types


This schedule type reprocesses error events associated with real-timerating feeds that use rating subtotals.

Server commanderror_event_reprocess


Parameter Type DescriptionConfirm Only List If set to TRUE, the schedule

reports how many error eventswould have been processedinstead of reprocessing allqualifying error events.

File Process StartDate

Date Reprocesses only error eventsthat are associated with files thatcommenced processing on orafter this date.

File Process EndDate

Date Reprocesses only error eventsthat are associated with files thatcompleted processing on orbefore this date.

Event Start Date Date Reprocesses only error eventswith a charge start date on orafter this date.

Event End Date Date Reprocesses only error eventswith a charge start date on orbefore this date.

C Party Id Text Reprocesses only error eventswith the specified chargeableparty identifier.

Error Message ID Test Reprocesses only error eventsthat have this error messageidentifier.

Event Type List Reprocesses only error eventsthat have the specifiednormalised event type.

Event WhereClause

Text An SQL Where clause on theNORMALISED_EVENT_ERROR tablethat restricts the error eventsbeing reprocessed.


Schedule Types


Parameter Type DescriptionMaximum Numberof Events

Integer The maximum number of errorevents that can be reprocessed.If the amount of error eventsbased on the above selectioncriteria exceeds the specifiednumber, they will not beprocessed.

Minimum EventStart Date

Date Reprocess only error events witha charge start date after thisdate.

Schedule Types


This schedule type re-rates normalised events that have rating subtotalsassociated with them.

Server commandevent_reprocess


Parameter Type DescriptionConfirm Only List If set to TRUE, the schedule

reports how many events,charges, accounts, and serviceswould have been processedinstead of reprocessing allqualifying events.

File Process StartDate

Date Reprocesses only events thatare associated with files thatcommenced processing on orafter this date.

File Process EndDate

Date Reprocesses only events thatare associated with files thatcompleted processing on orbefore this date.

Event Start Date Date Reprocesses only events with acharge start date on or after thisdate.

Event End Date Date Reprocesses only events with acharge start date on or beforethis date.

C Party Id Text Reprocesses only events withthe specified chargeable partyidentifier.

Tariff Text Tariff used to rate thenormalised events.

Event Type List Reprocesses only events thathave the specified normalisedevent type.

Event WhereClause

Text An SQL Where clause on theNORMALISED_EVENT table torestrict the error events to bereprocessed.

ReprocessEvent

Schedule Types


Parameter Type DescriptionMaximum Numberof Events

Integer The maximum number of eventsthat can be reprocessed. If theamount of error events based onthe above selection criteriaexceeds the specified number,they will not be processed.

Minimum EventStart Date

Date Reprocess only events with acharge start date after this date.

Schedule Types


This schedule type revokes a standard bill run, a quality assurance run, ora part thereof. The Revoke Bill Run schedule type allows the operator tospecify which operations within the specified bill run need to be revoked.

For example, the From Operation parameter could be set to 'RentalAdjustment' and the To Operation parameter could be set to 'ApplyInvoices'. This would mean that the operations 'Rental event generation(RGP)', 'Invoice/Statement generation (BGP)', and 'Invoice/StatementImage generation (IGP)' would also be revoked.

Server commandbill_run_execute -r


Parameter Type DescriptionBill Run ID List ID of already-scheduled bill run.

FromOperation

List Starting operation code of bill runto be revoked.

To Operation List Ending operation code of bill run tobe revoked.

PrerequisiteOperation

List Prerequisite billing operation. Ifthis operation lies outside of therange of the 'To' and 'From'operations, then only customernodes for this bill run which havefailed or are not yet up to thisspecified operation will be eligible.

CustomerBatch Size




ErrorThreshold

Integer Maximum number of customerswith errors. The operation will failif it reaches or exceeds thisnumber.


Revoke Bill Run

Schedule Types


NotesThe bill run is revoked if the schedule associated with the Bill Run ID isthe same as the customer’s schedule and the customers have:

a) successfully completed the To Operation and not past, orb) failed a revoke operation corresponding to the To Operation, orc) are not yet up to the To Operation, but have completed operations

greater or equal to the From Operation.

Schedule Types


This schedule type revokes a standard bill run, a quality assurance run, ora part thereof, for a specific customer on a bill run. The Revoke Bill Runfor Customer schedule type allows the operator to specify a specificcustomer, in addition to the operations within the specified bill run needto be revoked.

For example, the From Operation parameter could be set to 'RentalAdjustment' and the To Operation parameter could be set to 'ApplyInvoices'. This would mean that the operations 'Rental event generation(RGP)', 'Invoice/Statement generation (BGP)', and 'Invoice/StatementImage generation (IGP)' would also be revoked.

Server commandbill_run_cust -r


Parameter Type DescriptionBill Run Id Integer Identifier of the already-

scheduled bill run.


From Operation List Starting operation code of billrun to be revoked.

To Operation List Ending operation code of billrun to be revoked.

Revoke Bill Runfor Customer

Schedule Types


This schedule type revokes all normalised events, normalised errorevents, and charges associated with the file. The file remains in thearchive directory, and the unbilled amount of any accounts associatedwith the revokes changes is the updated.

Server commandrevoke_file



List List of the normalised event filesavailable.

Revoke EventFile

Schedule Types


This schedule type revokes all normalised events, normalised errorevents, and charges associated with the file. The file is moved to the datadirectory.

Server commandrevoke_file -f



List Available normalised event files.

ENM Process List ENM with the home directory asthe destination for the revoked file.


Schedule Types


This schedule type revokes invoice image settings; for example, deletesall invoice images for the last bill run in the specified bill cycle schedule.

Server commandbill_run_wrapper 40 40 40


Parameter Type DescriptionBill Run Id Integer Identifier of the bill run for which this

operation is being performed.

CustomerBatch Size

Integer Maximum allowable number of rootcustomer nodes to be processed bya single process at any given time.



ErrorThreshold

Integer Maximum number of customers witherrors. The bill run will fail once itreaches or exceeds this number.


Schedule Types


This schedule type revokes invoice images for a specific customer on abill run.

Server commandbill_run_cust_wrapper –r 40 40



scheduled bill run.



Schedule Types


This schedule type revokes invoice print settings and allows for a bulk re-print.

Server commandbill_run_wrapper 70 70 70




CustomerBatch Size




ErrorThreshold


Revoke InvoicePrint Settings

Schedule Types


This schedule type revokes invoice print settings. For example, it clearsthe print setting for all invoices on the specified schedule so that theentire bill run can be printed again.





CustomerBatch Size




ErrorThreshold


Revoke InvoicePrint Settingsfor Customer

Schedule Types


This schedule type revokes invoice settings. For example, it deletes allinvoices generated in the last bill run in the specified bill cycle schedule.

The Revoke Invoice schedule type automatically carries out the followingoperations:

• 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 wouldneed to be run as well (for example, Unapplying Invoices). Theadvantage of using the Revoke Invoices schedule type is that all revokeoperations are specified in one step.

Server commandbill_run_wrapper –r 10 40 10




CustomerBatch Size




ErrorThreshold


Revoke Invoices

Schedule Types


This schedule type revokes invoices and images, but keeps rental events(and adjustments), for a specific bill run.





CustomerBatch Size




ErrorThreshold



Schedule Types


This schedule type revokes invoices and images, but keeps rental events(and adjustments), for a specific customer.




scheduled bill run.


Revoke Invoices(keep Rentals)for Customer

Schedule Types


This schedule type revokes invoice images, invoice details, rental events,and rental adjustments, for a specific customer on a bill run. Forexample, it deletes all invoices generated in the last bill run in thespecified bill cycle schedule for the specified customer.

The Revoke Invoice for Customer schedule type automatically carries outthe 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 wouldneed to be run as well (for example, Unapplying Invoices). Theadvantage of using the Revoke Invoices for Customer schedule type isthat all revoke operations are specified in one step.




scheduled bill run.


Revoke Invoicesfor Customer

Schedule Types


This schedule type revokes rental events and adjustments for a specificbill run.





CustomerBatch Size




ErrorThreshold


Revoke RentalEvents

Schedule Types


This schedule type revokes rental events and adjustments for a specificcustomer on a bill run.

Server commandbill_run_cust_wrapper -r 10 10


Parameter Type DescriptionBill Run Id Integer Identifier of the already-

scheduled bill run.


Revoke RentalEvents forCustomer

Schedule Types


This schedule type revokes all normalised events, normalisation errorevents and charges, and recreates the original event file.

Server commandrevoke_file –r


Parameter Type DescriptionReprocessedFile

List File to have output revoked.

RevokeReprocessedFile

Schedule Types


This schedule type updates partitions to archive old data, and allocatespartitions for new data.

Server commandrotate_partitions


Parameter Type DescriptionTable topartition

List Table which is to be updated.

Schedule touse

List Schedule which is used toperform the partition maintenanceoptimiser.

Drop partitionsolder than

Integer Duration (in the selected units)that data is kept in the tablebefore being archived.

Units List Units for the duration that data iskept in the table before beingarchived.

Duration ofeach partition

Integer Duration of each partition (inselected units).

Units List Units for the duration of eachpartition.

Sort Partitionsolder than

Integer Duration (in the selected units)that data is kept in the tablebefore being sorted. Thisparameter is ignored if theaffected data is also set to be'dropped'.

Units List Units for the duration that data iskept before being sorted.

This script rotates a set of existing entries in the partition definition forthe specified <Table to partition>. The script’s three majortasks are:

1. Find any partitions associated with the <Table topartition> 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>.

Rotate Partitions

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 IDassociated with <task_queue_id>.

2. Checks to see if any partitions for the <Table topartition> exist where the TO_CHARGE_START_DATE orDESIRED_TO_CHARGE_START_DATE is greater than or equal tothe effective date. If none exist, than all partitions with anACTUAL_STATUS_CODE of 'Dropped' are found, ordered by theirpartition name. The partition with the maximumTO_CHARGE_START_DATE orDESIRED_TO_CHARGE_START_DATE is found. The droppedpartitions are then updated using the following method, untileither all dropped partitions are updated, or a partition is updatedwith a DESIRED_TO_CHARGE_START_DATE greater than orequal to the effective date.

• DESIRED_STATUS_CODE is set to 'Indexed'



• DESIRED_FROM_CHARGE_START_DATE is set to 1second after the greater of TO_CHARGE_START_DATEor DESIRED_TO_CHARGE_START_DATE

• DESIRED_TO_CHARGE_START_DATE is set toDESIRED_FROM_CHARGE_START_DATE plus<Duration of each partition><Units>minus 1 second


• ATLANTA_OPERATOR_ID is set to the operator IDassociated with the task’s ID.

3. If the sort duration and units have been specified, find allpartitions for the <Table to partition> that have:

• a TO_CHARGE_START_DATE which is less than or equalto the effective date minus <Sort Partitionsolder 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'




• ATLANTA_OPERATOR_ID is set to the operator IDassocoiated with the task’s ID.

NotesAll updates are performed as part of a single transaction. If an erroroccurs, all changes are rolled back.

If there are insufficient dropped partitions available to get a partition thatcovers <effective_date>, then an error is output and all changes arerolled back.

For efficient loading into new partitions, the indexes should be marked asunusable during the load. This should be performed automatically bySQL*Loader when run in direct mode. It can also be performed manuallyfor a partition by using the Partition Maintenance form to update thestatus of a partition. This improves performance if the import command(imp) is used to import data into a new partition. If an import is appliedacross multiple partitions (or the entire table), then the ata_dropcitcommand can be used to drop all indexes on the table prior to importingthe data. In this case, dbsync should be used to recreate the indexes.

Schedule Types


This schedule type creates and executes a standard bill run.

Server commandbill_run_execute


Parameter Type DescriptionBill Run Type List Type of bill run, which defines the

run’s accessible list of operations.

FromOperation

List Starting operation code of bill run.

To Operation List Ending operation code of bill run.

CustomerBatch Size




ErrorThreshold



Standard BillRun

Schedule Types


This schedule type renames all files that match the given file pattern inthe specified directory to <filename> YYYYMMDD where YYYYMMDD isthe task's effective date.

Server commandswitch_files


Parameter Type DescriptionDirectory Text Directory containing the files to be

processed.

File Pattern Text File pattern for files to be renamed.

Switch Files

Schedule Types


This schedule type de-allocates any credit payment and adjustmentamounts for a specific bill run.





CustomerBatch Size




ErrorThreshold


UnApply &DeallocateInvoices

Schedule Types


This schedule type de-allocates any credit payment and adjustmentamounts, and un-applies them, for a specific customer on a bill run.





CustomerBatch Size




ErrorThreshold


UnApply &DeallocateInvoices forCustomer

Schedule Types


This schedule type un-applies invoices for a specific bill run; the invoicesmust already be de-allocated.





CustomerBatch Size




ErrorThreshold


UnApply Invoices

Schedule Types


This schedule type un-applies invoices for a specific customer on a billrun; the invoices must already be de-allocated.





CustomerBatch Size




ErrorThreshold


UnApply Invoicesfor Customer

Schedule Types


This schedule type unarchives selected tables and other data.

Server commandclient_unarchive


Parameter Type DescriptionArchive filename

Text Name of the archive import file.

Import buffersize (in bytes)

Text Changes the default Oracle importbuffer size (in bytes).

Report missingdata?

[List] Select 'Yes' to report and view themissing data.

Unarchivemode

[List] Select the mode for handlingexisting data during unarchiving.

ArchiveFormat

[List] Select the archive data format.

Other archiveflags

Text Any other archive flags notsupported by prompts.

Unarchive

Schedule Types


This schedule type validates and updates the unbilled amount of anaccount.

Note: This script should only be run when there is no rating activity onthe system; otherwise, the account may be updated incorrectly.

Server commandupdate_unbilled_account


Parameter Type DescriptionAccountNumber

Text Account number to update.

NotesIf an account is specified, then the unbilled amount of that account isvalidated and updated. Otherwise, the unbilled amounts of all accountsare validated and updated.

Validation of an account involves examining all charges that referencethe account and adding together all the charge amounts (converted intothe currency of the account) where the charge has a tariff with anaccount_aggregate_ind_code = 1. This summed charge total isthen compared to the account unbilled amount. If the amounts differ thenthe account unbilled amount is updated by that difference.

After the database changes have been committed, all updated accountsare purged from the account cache.

Update AccountUnbilled

Schedule Types


This schedule type generates new charge categories for any services orcustomer nodes that need them. This schedule only needs to be run ifnew charge categories are assigned to products that are in use.

Server commandupdate_cc


Update ChargeCategories

Schedule Types


This schedule type validates and updates the unbilled amount of aninvoice.

Server commandupdate_unbilled_invoice


Parameter Type DescriptionInvoiceNumber

Integer Invoice number to update.

NotesIf an invoice is specified in the invoice number parameter then theunbilled amount of that invoice is validated. If the unbilled amount is notcorrect it is updated. Otherwise the unbilled amounts of all invoices arevalidated and updated.

Validation of an invoice involves examining all charges that referencethat invoice and adding together all the charge amounts (converted intothe currency of the invoice's account) where the charge has a tariff withan account_aggregate_ind_code = 1. This summed charge total isthen compared to the invoice unbilled amount. If the amounts differ thenthe invoice unbilled amount must be updated by that difference.

account_aggregate_ind_code maintains a running total of allunbilled charges for an account. These charges will not include billingdiscounts or any billing specific charges but can be used to give anindication of the customer's unbilled amount.

When the invoice is applied to the account, the unbilled amount in theaccount 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 AddCharges to Account in Real-time? check box selected. If this script isused, it can be run at any predetermined time and does not have tocorrelate with bill cycles because the unbilled amount is maintainedindependently of the invoiced amount. If used, this script should also berun after a rating engine crash.

Update InvoiceUnbilled

Schedule Types


This schedule type generates new empty derived attribute arrays for anyservices or customer nodes that need them. This schedule only needs tobe run if new derived attributes are assigned to products, service types, orcustomer node types that are in use.

Server commandupdate_list


NotesA 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 havethe derived attributes required by the product.

2. All customers and customer nodes are checked to ensure theyhave all the derived attributes required by their customer type.

3. All services are checked to ensure they have all the derivedattributes required by their service type.

Update Lists

Schedule Types


This type verifies that the UNINVOICED_IND_CODE (indicating whetheruninvoiced charges exist in the CHARGE table) is correct in theATLANTA_TABLE_PARTITION table for all charge table partitions withina calculated date range.

The calculated starting date is the schedule's effective date minus thespecified <No of Units><Units>. The end date is equal to the effectivedate.

If there are no longer any uninvoiced changes left in the partition, theUNINVOICED_IND_CODE is cleared. Because the biller automaticallyuses this code (no flags need to be set) to check which charge tablepartitions need to be scanned for unbilled charges, clearing the code forunnecessary scanning improves performance.

Frequency of usage for this schedule type depends on the bill cycle andpartition range. For example, for daily partitions with monthly billcycles, once per week should be sufficient.

Server commandupdate_partitions_uninvoiced -n


Parameter Type DescriptionNo Of Units Integer Number of units to use in the date

range calculation.

Units List The type of units to use in thedate range calculation ('Day's,'Months', or 'Weeks').

NotesFor each partition found, this function:

• Checks the CHARGE partition for any uninvoiced charges

• Updates theATLANTA_TABLE_PARTITION.UNINVOICED_IND_CODE asrequired

• Outputs a message to advise the date and time of completion ofthe task, with notification of any uninvoiced charges.

Verify ChargePartition

Schedule Types


This type verifies that the UNINVOICED_IND_CODE (indicating whetheruninvoiced charges exist in the CHARGE table) is correct in theATLANTA_TABLE_PARTITION table for all charge table partitions withinthe specified start and end dates.

If there are no longer any uninvoiced changes left in the partition, theUNINVOICED_IND_CODE is cleared. Because the biller automaticallyuses this code (no flags need to be set) to check which charge tablepartitions need to be scanned for unbilled charges, clearing the code forunnecessary scanning improves performance.

Frequency of usage for this schedule type depends on the bill cycle andpartition range. For example, for daily partitions with monthly billcycles, once per week should be sufficient.

Server commandupdate_partitions_uninvoiced


Parameter Type DescriptionStart Date Date Start date of the range to verify.

End Date Date End date of the range to verify.

NotesFor each partition found, this function:

• Checks the CHARGE partition for any uninvoiced charges

• Updates theATLANTA_TABLE_PARTITION.UNINVOICED_IND_CODE asrequired

• Outputs a message to advise the date and time of completion ofthe task, with notification of any uninvoiced charges.

Verify ChargePartition Range

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

Index

Account cache 1-8Apply Invoices 7-10Apply Invoices for Customer 7-11Apply Transactions 7-12Apply&Allocate Invoices 7-8Apply&Allocate Invoices for Customer 7-9Architecture

billing and rating 1-3billing engine 1-14Convergent Billing 5-2rating engine 1-7

Archiveschedule types 7-13

Balance Managementconcept 1-5

Batch Printing 4-1BGP (Bill Generation Process) 1-16BGP Hierarchy Passes

explanation 7-26Bill Generation Process (BGP)

description 1-16steps in billing 1-16

Bill Runconfiguration 3-7, 3-9, 3-10, 3-11correcting errors 3-15customer batch size 4-5Customer Batch Size 3-3INVOICE_PRINT 4-4modifying 3-11Number of Child Processes 3-4operations 3-5overview 3-2parameters 3-3perform an additional operation 3-11perform operations 3-5preparation 3-8print configuration 4-4print set up 4-5priority 3-7process example 3-4quality assurance 4-5reports 3-14revoke operations 3-5

schedule parameters 3-11schedule type 3-8server processes 3-6set up 3-8status of 3-5stopping 3-12task type 3-8tracking 3-5types 3-9, 3-10

Billingarchitecture 1-14correcting errors 3-15overview 1-14performing a bill run 3-8schedule types 3-17

Billing ProcessesBill Generation Process (BGP) 1-16customer hierarchies 3-20General Output Process (GOP) 1-18Invoice Generation Process (IGP) 1-17overview 3-1Rental Adjustment Mode (RGP) 1-16Rental Generation Program (RGP) 1-15trerodb 1-17trerwdb 1-17

Billing Schedule Typesfor bill runs 3-17for individual 3-19for individual customers 3-18

Billing Suppress 7-14Billing Task

preparation 3-8revoking 3-13

Billing Unsuppress 7-16Caches

account 1-8Customer Node 1-8Rating Subtotal 1-8Service 1-8

Chargesrecurring 1-13removing unwanted 2-12

Child Processes 3-4

Index

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

Complete Bill Run 7-17Complete Bill Run for Customer 7-18Configuring

bill run customer 3-7Context-sensitive Help xiiContract Cancel/Notify 7-19Conventions

document ixConvergent Billing

architecture overview 5-1Convergent Billing Architecture

three-tier 5-2Convergent Billing Processes

Balance Management 1-5Bill Generation Process (BGP) 1-16Event Normalisation (ENM) 1-9Event Rating (ERT) 1-6, 1-10Event Rating Broker (ERB) 1-7Event Rating Output (ERO) 1-11General Output Process (GOP) 1-18Invoice Generation Process (IGP) 1-17rating errors 1-12recurring charges 1-13rental adjustment mode (RGP) 1-15Rental Generation Program (RGP) 1-15trerate 1-5trerodb 1-5, 1-18trerwdb 1-17

Correctbilling errors 3-15corrupted events 2-9error events 2-9, 2-10rating errors 2-8wrong charges 2-11

Corrupted Eventscorrecting 2-9

Creatererating file 2-11table partitions 7-21

Create Partitions 7-21Customer Batch Size 3-3Customer Hierarchy

reporting level 3-20Customer Node cache 1-8Database Synchronisation 1-12Deallocate

invoices 7-80invoices for customer 7-81

Defineoutput method 4-13

Delete

schedule 6-6DIL Validation 7-23Document Images

printing 4-7Dunning Letters

generating 4-2, 7-24Duplicate event checking 1-10, 1-12ECP Command 7-25ENM See Event Normalisation (ENM) ProcessERB See Event Rating Broker (ERB) ProcessERO See Event Rating Output (ERO) ProcessError Events

assigning to rerating file 2-11correcting 2-9re-rating 7-47viewing 2-6viewing and correcting 2-10

Error Events (bulk)re-rate 7-48

Error FilesENM process 2-5

Error Messages xivErrors

correcting (billing) 3-15correcting (rating) 2-8

ERT See Event Rating (ERT) ProcessEvent File

revoke 7-62Event Normalisation (ENM) Process

count file 1-10description 1-7, 1-9error file 1-9status file 1-10tracer record 1-10

Event Rating (ERT) Processdescription 1-6, 1-7, 1-10errors in 1-12parallel tariffing 1-13recurring charges 1-13

Event Rating Broker (ERB) Processcaches 1-7description 1-7

Event Rating Output (ERO) Processdatabase synchronisation 1-12description 1-7, 1-11duplicate event checking 1-12

Eventsconcept 1-3removing unwanted 2-12types 1-3, 1-4

Events (bulk)

Index


re-rating 7-50Executing expressions 7-25Form Help xiFull Database Validation 7-27General Bulk Output By Task 4-2, 7-28General Bulk Output Process 4-2, 7-29General Output Process (GOP)

description 1-18output device 4-8, 4-9printing document images 4-7process 4-8processing 4-3schedule types 7-29using a schedule or task 4-2

Generatecustomer invoice image 7-31dunning letter 7-24invoice image 7-30, 7-32invoices reprint 7-34viewing image file 7-35

Helpcontext-sensitive xiierror messages xivform xionline x

IGP (Invoice Generation Process) 1-17Immediate Task

scheduling 2-3Incorrect Charges

correcting 2-11Invoice

generate customer invoice image 7-31generate image 7-30, 7-32print 7-38print customer invoice 7-39print image 7-33reprint generation 7-34templates 1-18view image 3-13, 7-35viewing data 3-13working with 1-18

Invoice Generationchecking results 3-13suppressing 3-14

Invoice Generation Process (IGP)description 1-17steps in billing 1-17

INVOICE_PRINT 4-4Modifying

bill run 3-11

Normalised Filesretrieving details 2-6

Online Help xOutput Device 4-8

examples 4-11, 4-12overview 4-9

Output Method 4-1components 4-8defining 4-13example 4-13

Output Method Type 4-1Output Method Types

searching 4-8Output Processing

configuring 4-8Output scripts 4-10Parallel Processing

support for 4-5Parallel Tariffing

description 1-13Partition Maintenance 7-36, 7-37Pipe/Concatenate

options 4-9Printing

bill run configuration 4-4bill run set up 4-5bulk invoices 4-5checking output 4-7configuring output 4-8customer invoice 7-39document images 4-7invoices 7-38overview 4-1preparation 4-7schedule parameters 4-2schedule processing 4-3schedule type 7-28scripts 4-10single invoices 4-6using bill runs 4-1, 4-4using schedules 4-2Using schedules 4-1

Purgeerror events 7-40events (non-error) 7-42files 7-43

Quality Assurance Bill Run 7-44Rate Files 7-45Rated and Reprocessed File

revoking 2-12

Index


Ratingarchitecture 1-7archive directory 2-2correcting errors 2-8directory structure 2-2errors 1-12managing files 2-1overview 2-1schedule types 2-12

Rating and Billingoverview 1-1

Rating ProcessesEvent Normalisation (ENM) 1-9Event Rating (ERT) 1-10Event Rating Broker (ERB) 1-7Event Rating Output (ERO) 1-11trerate 1-5trerodb 1-5

Rating Subtotal cache 1-8Rating Task

checking results 2-4data feed reconciliation report 2-7description 2-3error files 2-5log-out file 2-5notifying completion 2-4original file location 2-5parameters 2-3preparation 2-3running 2-3status and result 2-5unsuccessful 2-9view error events 2-6view normalised files and events 2-6

Re-analyse Tables 7-46Reconfigure Auditing 7-53Rental Generation Program (RGP)

description 1-15generating charges 1-13processing 1-15quality assurance mode 1-15rental adjustment mode 1-15, 1-16steps in billing 1-15

Report Reference Type (RRRT) 7-54Reporting Levels

billing 3-20Reprocess

error event 7-55event 7-57

Requirementsfor use of the document vii

Re-rateerror events 7-47error events (bulk) 7-48event file 7-52events (bulk) 7-50

Re-rate Fileassigning error events 2-11creating 2-11

Revokebill run 7-59billing task 3-13customer bill run 7-61event file 7-62file and move back 7-63invoice image settings 7-64invoice images for customer 7-65invoice print settings 7-66invoice print settings for customer 7-67invoice settings 7-68invoices (keep Rentals) 7-69invoices (keep rentals) for customer 7-70invoices for customer 7-71rental events 7-72rental events for customer 7-73reprocessed file 7-74

Rotatepartitions 7-75

RRRT See Report Reference Type (RRRT)Schedule Types

Apply Invoices 7-10Apply Invoices for Customer 7-11Apply Transactions 7-12Apply&Allocate Invoices 7-8Apply&Allocate Invoices for Customer 7-9Archive 7-13Billing Suppress 7-14Billing Unsuppress 7-16Complete Bill Run 7-17Complete Bill Run for Customer 7-18Contract Cancel/Notify 7-19Create Partitions 7-21description 7-1details 7-7DIL validation 7-23Dunning Letter Generation 7-24ECP Command 7-25Explain BGP hierarchy passes 7-26for bill runs 3-17for individual customers 3-18, 3-19Full Database Validation 7-27General Bulk Output By Task 7-28

Index


General Output Process (GOP) 7-29Generate Invoice Image for Customer 7-31Generate Invoice Images 7-30Invoice Generate Image 7-32Invoice Print Image 7-33Invoice Reprint Generation 7-34Invoice View Image 7-35Partition Maintenance 7-36, 7-37Print Invoices 7-38Print Invoices for Customer 7-39Purge Error Events 7-40Purge Events (non Error) 7-42Purge Files 7-43Quality Assurance Bill Run 7-44Rate Files 7-45rating 2-12Re-analyze Tables 7-46Reconfigure Auditing 7-53Report Reference Type(RRRT) 7-54Reprocess Error Event 7-55Reprocess Event 7-57requirements 7-1Re-rate Error Events 7-47Re-rate Error Events (bulk) 7-48Re-rate Events (bulk) 7-50Re-rate File 7-52Revoke Bill Run 7-59Revoke Bill Run for Customer 7-61Revoke Event File 7-62Revoke File and Move Back 7-63Revoke Invoice Images 7-64Revoke Invoice Images for Customer 7-65Revoke Invoice Print Settings 7-66Revoke Invoice Print Settings for Customer

7-67Revoke Invoices 7-68Revoke Invoices (keep Rentals) 7-69Revoke Invoices (keep Rentals) for

Customer 7-70Revoke Invoices for Customer 7-71Revoke Rental Events 7-72Revoke Rental Events for Customer 7-73Revoke Reprocessed File 7-74Rotate Partitions 7-75selecting criteria 2-13Standard Bill Run 7-78summary 7-2Switch Files 7-79UnApply Invoices 7-82UnApply Invoices for Customer 7-83

UnApply&Deallocate Invoices 7-80UnApply&Deallocate Invoices for Customer

7-81Unarchive 7-84Update Account Unbilled 7-85Update Charge Categories 7-86Update Invoice Unbilled 7-87Update Lists 7-88update partitions 7-37Verify Charge Partition 7-89Verify Charge Partition Range 7-89, 7-90

Schedulesdeleting 6-6description of terms 6-3frequency 6-5overview 6-2server tasks 6-1working with 6-5

Searchfor output method type 4-8

Serverprocesses 5-1Transaction Engine (TRE) 5-1

Server Commandsschedule types 7-7

Server Processesbill run 3-6

Server Tasksscheduling 6-1

Service cache 1-8Singl.eView Convergent Billing

architecture overview 5-1Standard Bill Run 7-78Stopping

bill run 3-12Suppressing

Invoice generation 3-14Switch Files 7-79Tables

unarchive 7-84Tariffing

parallel 1-13Tasks

resubmitting 6-5Transaction Engine (TRE)

Convergent Billing architecture 5-1TUXEDO

trerate 1-5trerodb 1-5, 1-18trerwdb 1-17

Index


UnApplyinvoices 7-80, 7-82invoices for customer 7-81, 7-83

Unarchiveselected tables 7-84

Updateaccount unbilled 7-85charge categories 7-86invoice unbilled 7-87lists 7-88

Update Partitions 7-36, 7-37Update Partitions Uninvoiced 7-89Verify Charge Partition 7-89Verify Charge Partition Range 7-89, 7-90View

error events 2-6, 2-10invoice data 3-13

500 system operations guide

Documents