Geneva Product Overview

Geneva Product Overview Release 5.3

Copyright © 1999–2005 Convergys. All rights reserved. Convergys refers to Convergys Corporation or any of its wholly owned subsidiaries. Release 5.3.18. Document version 4. Convergys, the Convergys logo, Atlys, Catalys, Geneva, Cygent, Infinys, and Wizard are trademarks and/or registered trademarks of Convergys in the United States and/or other countries, including but not limited to in Chile, China, Costa Rica, Guatemala, and Honduras, where Convergys and Atlys are re gistered trademarks, in Chile, China, and Costa Rica, where Catalys is a registered trademark, in Chile, Costa Rica, Guatemala, and Honduras, where Infinys is a registered trademark, and in Chile, where Geneva and Wizard are registered trademarks. Parts of the described systems may be covered by one or more issued or pending U.S. or other patents, including but not limited to U.S. Patent 6,396,913, U.S. Patent 6 ,438,512, U.S. Patent 6,611,898, and U.S. Patent 6,658,099. All other trademarks not owned by Convergys that appear in this document are the property of their respective owners, who may or may not be affiliated with, connected to, or sponsored by Convergys or its subsidiaries. Every effort has been made to ensure that the information contained in this document is true and correct at the time of going to press. However, the products and specifications and content in general described in this document are subject to continuous development and improvement, and Convergys is entitled to change them at any time. Convergys cannot accept liability for any loss or damage of any nature whatsoever arising or resulting from the use of or reliance on information or particulars in this document. Convergys does not warrant that the material contained in thi s documentation is free of errors. Any errors found in this document should be reported to Convergys in writing. The information in this document is confidential and meant for use only by the intended recipient and only in connection with and subject to the terms of its contractual relationship with Convergys. It is the sole property of Convergys or its subsidiaries. Acceptance and/or use of any of the information contained in this document indicates agreement not to disclose or otherwise make available to any person who is not an employee of the intended recipient, or to any other entity, any of the information contained herein. This documentation has the sole purpose of providing information regarding a Convergys software product or service and shall be disclosed only to those individuals who are employees of the intended recipient who have a definite need to know. Any entity or person with access to this information shall be subject to to this confidentiality statement. No part of this publication may be reproduced or transmitted in any form or by any means for any purpose without the express written permission of Convergys. If you have received this document via e-mail in error, please send the e-mail to the originator, indicating that you received it in error. If you have received a hard copy of this document in error, mail this document in its entirety to Convergys Corporation, 201 East Fourth Street, Cincinnati, Ohio USA 45202.

Table of Contents About This Document ....................................................... ............................................................................................................................ ..................................................................... xiii Document Conventions........................................................................................................................xiii Characters Versus Bytes ........................................................ .................................................................................................................... ............................................................ xiv Spelling and Terminology........................................................... ......................................................... xiv 1

Overview Overview .............. ..................... .............. ............. ............. .............. ............. ............. ............. ............. .............. .............. ............. ............. .............. .............. ............ ............ ............. ............. ..........1 ...1 Audience .................................................................... ............................................................................ 1 Before You Begin...................................................................................................................................1

2

What is Geneva? Geneva? ............. ................... ............. ............. ............. ............. ............. .............. ............. ............. ............. ............. ............. ............. ............. ............. .............. ............. ............3 ......3 What is Geneva’s Key Benefit?..............................................................................................................5 How Can Geneva Be Used?..................................................................................................................5 Within an Integrated Architecture ........................................................ .................................................................................................... ............................................ 5 As a Standalone Product ............................................................... .................................................. 7 Within a Multiservice Environment ...................................................................... ............................ 7 Alongside Legacy Systems ........................................................... ................................................ 10 Billing Multiple Service Providers ........................................................ .................................................................................................. .......................................... 10 In Multinational Environments .......................................................... ....................................................................................................... ............................................. 11 For Wireless Telephony.................................................................................................................12

3

Concepts...... Concepts............. ............. ............. ............. ............. ............. ............. ............. ............. ............. ............. ............. ............. ............. ............. ............. ............. ............ ............ ............. ............15 ......15 Customers............................................................................................................................................15 Accounts ................................................................. ............................................................................. 15 Products...............................................................................................................................................15 Events .............................................................. .................................................................................... 16 Rate Plans............................................................................................................................................16 Rating Catalogs....................................................................................................................................16 Price Plans...........................................................................................................................................17 Billing Catalogs ............................................................. ....................................................................... 17 Rating...................................................................................................................................................17 Billing....................................................................................................................................................17 Budget Centers .................................................................... ................................................................ 17 Invoices................................................................................................................................................18 Statements...........................................................................................................................................18 Customer Reports................................................................................................................................18 Itemization............................................................................................................................................18 Discounts ...................................................................... ....................................................................... 18 Filters .................................................................. ................................................................................. 19 Packages ......................................................................... .................................................................... 19

Confidential and Proprietary

i

Geneva Product Overview

Subscriptions........................................................................................................................................19 Contracts..............................................................................................................................................19 Bonus Schemes...................................................................................................................................19 Loyalty Points.......................................................................................................................................20 Calling Circles ............................................................... ....................................................................... 20 Payments and Refunds........................................................................................................................20 Budget Payment Plans.........................................................................................................................20 Convergent Prepay ................................................................. ............................................................. 21 Service Providers.................................................................................................................................21 Deposits ........................................................................ ....................................................................... 21 Currencies............................................................................................................................................21 Disputes and Adjustments ............................................................ ....................................................... 21 Tax .......................................................................... ............................................................................. 22 4

System Elements Elements ............. .................... ............. ............. .............. .............. .............. .............. ............. ............. ............. ............. .............. ............. ............. ............ ........... ............. .........23 ..23 User Applications ................................................................. ................................................................ 23 System Configuration .......................................................... .................................................................................................................... .......................................................... 23 Product Configuration....................................................................................................................24 Bill Renderer..................................................................................................................................24 Billing Catalog Maintenance ....................................................... .......................................................................................................... ................................................... 24 Rating Catalog Maintenance ...................................................... ......................................................................................................... ................................................... 25 Customer Account Maintenance ......................................................... ................................................................................................... .......................................... 26 Accounts Receivable .................................................................. ................................................... 26 Batch Payment Entry.....................................................................................................................27 System Monitor..............................................................................................................................27 Configuration Data Transfer ....................................................... .......................................................................................................... ................................................... 27 Rejected Event Maintenance.........................................................................................................27 Product and Pricing Edits Transfer................................................................................................28 System Processes ........................................................... .................................................................... 28 Billing Engine.................................................................................................................................29 Bill Data Writer...............................................................................................................................29 Bill Formatting Engine ......................................................... ................................................................................................................... .......................................................... 30 Bill Product Charge Deleter ........................................................ ........................................................................................................... ................................................... 30 Debt Escalation Engine .................................................................... ............................................. 30 Dunning Letter Engine...................................................................................................................31 Accruals Extract Generator ........................................................... ................................................ 31 Outbound Message Dispatcher .................................................. ................................................... 31 Active Rating Engine .................................................................. ................................................... 31 Accounting Data Writer........................... ................................................................. ...................... 32 Invoice Number Generator ..................................................................... ....................................... 32 Denormalized Count Updater ................................................................. ....................................... 32 Task Master...................................................................................................................................32 Test Rating Daemon......................................................................................................................33

ii


Table of Contents

Additional Billing Processes ................................................................ .......................................... 33 Managed File Processes .................................................................. ............................................. 33 Additional Rating Processes............................. ............................................................................. 35 Event Processes............................................................................................................................35 Archive and Delete Processes ............................................................... ....................................... 37 Mandate Instruction Interface Processes ................................................................... ................... 39 Payment Request Interface Processes ......................................................................... ................ 40 Customer and Account Processes ................................................................................ ................ 41 Cache Processes ................................................................ .......................................................... 42 5

Functional Features...........................................................................................................................43 Rating...................................................................................................................................................43 Override Pricing of Events.............................................................................................................45 External Rating Algorithms ............................................................................................................ 46 Full Pre-Authorization of Charge ......................................................................... .......................... 46 Rating Catalog...............................................................................................................................47 Rating Catalog Publishing ............................................................................................................. 48 Event Import ........................................................... ....................................................................... 48 Pre-Rated Event Import.................................................................................................................49 Rate Plans .............................................................. ....................................................................... 49 Geographic Rating.........................................................................................................................52 Time-Based Rating........................................................................................................................53 Modifiers .............................................................. .......................................................................... 53 Quantity or Volume Rating ............................................................................................................ 54 Rating Rules .............................................................. .................................................................... 55 On-Net and Off-Net ....................................................................................................................... 58 Prices.............................................................................................................................................58 Duplicate Events............................................................................................................................59 Rejected Events .................................................................. .......................................................... 60 Actions and Thresholds ................................................................................................................. 60 Message Interface to Rating..........................................................................................................60 Carrier-Grade Message Queue Interface ................................................................................... ...61 Caches ................................................................... ....................................................................... 61 Domains and Domain Routing.......................................................................................................62 Prioritization of Rating Jobs...........................................................................................................62 Tax Overrides on Events ..................................................................... .......................................... 62 Tax on Prepaid Events .................................................................. ................................................ 63 Unloading of Costed Events ................................................................ .......................................... 63 Test Event Facility .................................................................. ....................................................... 63 Rerating Requests.........................................................................................................................63 Rating Partial Events ........................................................... .......................................................... 64 Multiple Event Types ........................................................... .......................................................... 65 Redirecting Events ................................................................. ....................................................... 65


iii


Convergent Billing................................................................................................................................65 Billing Catalogs..............................................................................................................................67 Billing Catalog Publishing .............................................................................................................. 68 Prices.............................................................................................................................................68 Discounts.......................................................................................................................................73 Products .................................................................... .................................................................... 86 Packages.......................................................................................................................................87 Subscriptions ................................................................. ................................................................ 88 Market Segments ................................................................ .......................................................... 89 Bonus Schemes .................................................................. .......................................................... 89 Loyalty Points ................................................................ ................................................................ 91 Multiple Currencies........................................................................................................................91 Payment Methods and Discounts..................................................................................................93 Aggregate Pricing ....................................................................... ................................................... 94 Budget Payment Plans and Discounts ................................................................ .......................... 94 Revenue Codes.............................................................................................................................95 Provisioning Systems .................................................................................................................... 96 Import and Export of Configuration Data....................................................................................... 96 Customer and Account Maintenance ...................................................................... ...................... 98 Customer Hierarchies....................................................................................................................98 Accounts.................................................................... .................................................................. 100 Contacts .................................................................... .................................................................. 101 Customer Products and Packages ................................................................................ .............. 102 Split Product and Subscription Charging.....................................................................................102 Customer Product Status ................................................................. ........................................... 102 Contracts .......................................................................... ........................................................... 103 Nominated Events ...................................................................... ................................................. 103 Cost Centers................................................................................................................................103 Payment Details .................................................................. ........................................................ 104 Rated Events ................................................................. .............................................................. 104 Bills ......................................................................... ..................................................................... 104 Disputes and Adjustments...........................................................................................................107 Payments and Refunds .................................................................... ........................................... 109 Loyalty Points ................................................................ .............................................................. 109 Customer Notes...........................................................................................................................109 Deletion of Customer Data ............................................................... ........................................... 110 Tax...............................................................................................................................................110 Language.....................................................................................................................................113 Billing ................................................................... ........................................................................ 114 Billing Single Accounts ................................................................................................................ 114 Billing Customer Account Hierarchies ................................................. ........................................ 115 Billing Windows ............................................................. .............................................................. 117 Product End Dates ........................................................... ........................................................... 117

iv


Table of Contents

Control Over Which Accounts are Billed ................................................................. .................... 118 Bill Suppression...........................................................................................................................118 Bill Cancellation and Rebill .......................................................................................................... 118 Test Bill Run .................................................................. .............................................................. 118 Bill Styles .......................................................................... ........................................................... 118 Bill Data Customization ............................................................................................................... 119 Invoice Total Rounding................................................................................................................119 Event Subtotals ................................................................... ........................................................ 119 Marketing Messages ........................................................... ........................................................ 119 Bill Inserts ............................................................... ..................................................................... 119 Copy Bills.....................................................................................................................................120 Bill Formatting..............................................................................................................................120 RTF Formatting ............................................................. .............................................................. 120 Interface to Third-Party Formatting..............................................................................................121 Payments and Collections..................................................................................................................121 Balance Forward Accounting.......................................................................................................121 Open Item Accounting ............................................................ ..................................................... 121 Bill Receivables ................................................................ ........................................................... 122 Payments.....................................................................................................................................123 Payment Requests ................................................................. ..................................................... 123 Automatic Payment Authorization Instructions ........................................................... ................. 123 Bank Accounts, Payment Systems, and Payment Methods........................................................124 Lockbox and Other Electronic Payments .................................................................................... 124 Matching Automatic Payments to Invoice Numbers .................................................................... 124 Manual Payments........................................................................................................................124 Failed Payments..........................................................................................................................125 Refunds ............................................................... ........................................................................ 126 Suspense Account.......................................................................................................................126 Budget Payment Plans ........................................................... ..................................................... 126 Prepaid Accounts ................................................................ ........................................................ 127 Suspended Accounts...................................................................................................................128 Conditional Settlement ........................................................... ..................................................... 128 Aging Receivables......................................................................... .............................................. 130 Payment Due Days......................................................................................................................131 Total Receivables ................................................................ ........................................................ 131 Net Receivables ..................................................................... ..................................................... 131 Aging Receivables and Budget Payment Plans ............................................................... ........... 132 Collections ........................................................................ ........................................................... 132 Credit Classes ............................................................... .............................................................. 132 Collections Schedules and Actions ............................................................................................. 132 Dunning Notices .................................................................. ........................................................ 133 Interfacing to External Systems...................................................................................................133 Accounts Receivable .................................................................. ................................................. 134


v


Revenue Assurance .................................................................................................................... 134 Reporting............................................................................................................................................135 Scheduled Reports ........................................................... ........................................................... 135 Financial Reports.........................................................................................................................135 Management Reports ............................................................. ..................................................... 136 Catalog Reports...........................................................................................................................137 Rating Catalog Reports .............................................................. ................................................. 137 Billing Catalog Reports ............................................................... ................................................. 138 Product Configuration Reports .................................................................................................... 138 System Monitor Reports .............................................................................................................. 139 Configuration Data Transfer Reports...........................................................................................139 Product and Pricing Edits Transfer Reports ................................................................................ 139 System Configuration Reports.....................................................................................................139 Ad Hoc Reporting and Analysis........................................................... ........................................ 140 Interconnect Accounting Agreement..................................................................................................140 Interconnect Billing ........................................................... ........................................................... 140 Interconnect Accounting ...................................................................... ........................................ 141 6

System Administration and Maintenance......................................................................................145 Archive and Delete............................................................................ ................................................. 145 Rated Events ................................................................. .............................................................. 145 Rejected Events .................................................................. ........................................................ 145 Bill Images .............................................................. ..................................................................... 146 Other Data ................................................................. .................................................................. 146 Backup and Recovery........................................................................................................................146 Oracle ............................................................... ........................................................................... 147 Managed Files ........................................................... .................................................................. 147 Installation and Configuration.............................................................................................................148 System Configuration .................................................................................................................. 148 Data Migration Utility .............................................................. ..................................................... 149 Upgrades ................................................................... .................................................................. 149 Catalog Maintenance ......................................................................................................................... 149 Catalog Life Cycles......................................................................................................................150 Parallel Development ............................................................. ..................................................... 152 Scheduling and Monitoring.................................................................................................................152 Task Master.................................................................................................................................153 External Schedulers ...................................................................... .............................................. 154 System Monitor............................................................................................................................154 Scheduling Geneva System Processes ...................................................................................... 154 Stopping and Pausing Geneva System Processes ..................................................................... 155 Monitoring Current System Processes ............................................................................. ........... 155 Investigation of Past System Process Activity.............................................................................156 Jobs and Managed Files ............................................................................................................. 156

vi


Table of Contents

7

Security.............................................................................................................................................157 Password Access Control ............................................................. ..................................................... 157 Business Roles ................................................................ .................................................................. 157 User Application Access..............................................................................................................158 Data Partitioning .......................................................................................................................... 158 Transaction Limits..............................................................................................................................159 Catalog Partitioning............................................................................................................................159 Price Plan and Package Availability...................................................................................................160 Server, Client, and LAN Security ....................................................................................................... 160 Audit Trails .................................................................... ..................................................................... 160 Partitioning Catalogs by Invoicing Company......................................................................................161

8

System Architecture ........................................................................................................................163 User and System Processes Functionality.........................................................................................164 Application Architecture ..................................................................................................................... 165 High Availability..................................................................................................................................166 Third-Party High Availability ............................................................. ........................................... 166

9

External Interfaces...........................................................................................................................169 Public Schema .............................................................. ..................................................................... 169 Oracle Stored Procedures..................................................................................................................169 Enhanced Care APIs..........................................................................................................................170 File-Based Interfaces ........................................................................ ................................................. 170 Plug-In Interfaces...............................................................................................................................171 Breakout Objects................................................................................................................................171 Interfacing with Other Systems .......................................................................................................... 172 Customer Care ................................................................. ........................................................... 172 Provisioning Systems .................................................................................................................. 173 Event Sources ........................................................... .................................................................. 173 External Formatting Engines ............................................................... ........................................ 174 Finance Systems ........................................................................ ................................................. 174 Tax Packages..............................................................................................................................175

10 Requirements ...................................................................................................................................177 Hardware Requirements ............................................................... ..................................................... 177 Server ............................................................... ........................................................................... 177 Client ................................................................... ........................................................................ 178 Software Requirements......................................................................................................................178 Server ............................................................... ........................................................................... 178 Client ................................................................... ........................................................................ 178 11 Documentation Set ..........................................................................................................................181 Documents Provided..........................................................................................................................181 Overviews....................................................................................................................................182 Concept Guides...........................................................................................................................182


vii


User Application Documentation ................................................................................................. 184 System Administration Documentation........................................................................................186 Interface Documentation ............................................................................................................. 187 Change Documentation...............................................................................................................189 How to Use the Documentation ......................................................................................................... 190 Initial Installation .......................................................................................................................... 190 Upgrading ............................................................... ..................................................................... 191 Day-To-Day Operation ................................................................................................................ 192 Processing...................................................................................................................................193 Integration....................................................................................................................................198 A

Distributed Revenue Processing............................................................ ....................................... 199 Geneva Enterprise Edition ................................................................................................................. 200 Geneva Enterprise Edition Within Documentation .................................................................. ....200 Event Database..................................................................................................................................200 Remote Rating Hosts.........................................................................................................................201 Domains and Domain Routing ........................................................................................................... 202 Shared Cache .................................................................. .................................................................. 203

viii


Table of Figures Figure 1

An Overview of the Billing Process ............................................................ ............................... 4

Figure 2

Geneva as Part of an Integrated Solution ............................................................ ..................... 6

Figure 3

Geneva as a Standalone Solution.............................................................................................7

Figure 4

Distinct, Single-Service, Systems .............................................................. ............................... 8

Figure 5

Geneva Within a Multiservice Environment .............................................................................. 9

Figure 6

Use of the Active Rating Engine. ............................................................................................ 44

Figure 7

Pre-Authorization of Events .................................................................................................... 47

Figure 8

Multiple Event Sources/Types.................................................................................................51

Figure 9

Event Time and Charge Segment Fragmentation...................................................................56

Figure 10 Aggregate Events............................................. ....................................................................... 64 Figure 11

Delta Events............................................................................................................................65

Figure 12 Customer Hierarchy Billing......................................................................................................66 Figure 13 Example Price Plan Hierarchy ................................................................................................ 70 Figure 14 Example Child Price Plan........................................................................................................71 Figure 15 Parametric Price Breakpoints..................................................................................................72 Figure 16 Example: Product Hierarchy with Transfer of Discounts.........................................................80 Figure 17 Bonus Schemes ............................................................ .......................................................... 90 Figure 18 Multiple Currency Discounting ................................................................... ............................. 93 Figure 19 Import and Export of Geneva Configuration Data ................................................................... 97 Figure 20 Example Customer Hierarchy .................................................................... ............................. 99 Figure 21 Family Scenario, Summary Statement for Many Accounts...................................................107 Figure 22 Tax Inclusive Rating and Billing .............................................. .............................................. 112 Figure 23 Discounts on Sets of Events ............................................................ ..................................... 115 Figure 24 Discounts in a Hierarchy ....................................................................................................... 116 Figure 25 Family Scenario, Prepay and Postpaid Accounts. ................................................................127 Figure 26 Catalog Life Cycle ................................................................ ................................................. 151 Figure 27 Parallel Maintenance of a Geneva Catalog...........................................................................152 Figure 28 Task Master Context Diagram .............................................................................................. 153 Figure 29 Assignment of Business Roles...................................................... ........................................ 158 Figure 30 Geneva Optional Components..............................................................................................163 Figure 31 Geneva Application Architecture...........................................................................................166 Figure 32 Geneva Documentation Set ....................................................................... ........................... 181


ix


Figure 33 Geneva Documentation Relevant to the Initial Installation of Geneva .................................. 190 Figure 34 Geneva Documentation Relevant to Upgrading Geneva...................................................... 192 Figure 35 Geneva Documentation Relevant to the Basic Day-To-Day Operation of Geneva...............193 Figure 36 Geneva Documentation Relevant to the Basic Day-To-Day Operation of Geneva – Rating ..................................................................... .............................................. 194 Figure 37 Geneva Documentation Relevant to the Basic Day-To-Day Operation of Geneva – Billing ...................................................................... .............................................. 195 Figure 38 Geneva Documentation Relevant to the Basic Day-To-Day Operation of Geneva – Finance.................................................................................................................197 Figure 39 Geneva Documentation Relevant to Integrating Geneva with Any Third-Party System ....... 198 Figure 40 Geneva Distributed Revenue Processing ............................................... .............................. 199 Figure 41 Example Architecture for Separate Event Database on Remote Machine ........................... 201 Figure 42 Example Rating Architecture for Remote Rating Hosts ........................................................ 202 Figure 43 Example Rating Architecture for Multiple Rating Hosts Showing Domaining ....................... 203 Figure 44 Example Rating Architecture for Multiple Rating Hosts Showing Domaining and Caches...........................................................................................................................204

x


Table of Tables Table i

Document Conventions...........................................................................................................xiii

Table ii

Symbols and Graphics ............................................................ ................................................ xiii

Table 1

Viable Marginal Single Set Discount Application/Aggregation Level Combinations ............... 82

Table 2

Viable Non-Marginal Single Set Discount Application/Aggregation Level Combinations ....................................................................... ................................................... 83

Table 3

Viable Marginal Double Set Discount Application/Aggregation Level Combinations.............. 83

Table 4

Viable Non-Marginal Double Set Discount Application/Aggregation Level Combinations ....................................................................... ................................................... 84

Table 5

Viable Marginal Bonus Scheme Discount Application/Aggregation Level Combinations ....................................................................... ................................................... 84

Table 6

Viable Non-Marginal Bonus Scheme Discount Application/Aggregation Level Combinations ....................................................................... ................................................... 85

Table 7

Example Language Setups ........................................................... ........................................ 113

Table 8

Example Settlement Buckets ................................................................................................ 130

Table 9

Example Settlement Payment Buckets.................................................................................130


xi


xii


About This Document This chapter describes the conventions, symbols, and terminology used in this documentation.

Document Conventions Table i and Table ii describe conventions used to help you recognize instructions, system messages, and other special information in this document. Document Conventions

Table i Convention

Description

Andale Mono

Computer input and output text.

blue

Linked cross-references to chapters, sections, and other reference points.

blue italics

Linked cross-references to other documents.

bold

Figure and table information in captions; names of window components such as command buttons, option buttons, text boxes, check boxes, drop-down lists, group boxes/panels, and menu options; directory paths and names; file names and suffixes; parameter names; permission and user IDs; script names; server names; and tab and subtab names. Note: Values that are not window components, such as values in a drop-down list or a view-only value for a text box, are shown in normal text.

CAPITALS

Key names, key combinations, and database table and column names.

italics

Word emphasis when defining a term and nonlinked cross-references to other documents.

“Quotation Marks”

References to chapter titles and section titles.

strikethrough

Items such as function arguments that have been removed between releases.

Symbols and Graphics

Table ii Symbol/ Graphic

>

Description A menu path to a window. For example: Billing > Cycle activities > Cycle initiation


xiii


Table ii Symbol/ Graphic

Symbols and Graphics (continued)

Description An information note. Information notes help you select options, make decisions, or understand the indirect results of a particular action. A warning note. Warning notes tell you that the action you are about to perform could create an undesirable change or condition. However, you can continue the process or select other alternatives. A critical note. Critical notes tell you that the action you are about to perform will cause the system to lose all or part of its data or to shut down. You should contact a system administrator or the Help desk.

GEE

A note relating to functionality that is available only in the Geneva Enterprise Edition.

Characters Versus Bytes Geneva supports multibyte character sets. As a consequence, the maximum length of an entry field is typically given in bytes rather than in characters. The number of characters that can fit in a field will depend on their size in bytes. For example, non-accented, English, alphabetical characters usually require one byte, whereas accented characters and simple Chinese characters usually require two or more bytes.

Spelling and Terminology The English version of this documentation uses U.S. English spellings. For example, the documentation uses the words check rather than cheque, net rather than nett, and catalog rather than catalogue. In addition, this documentation uses U.S. English terminology. For example, it uses the terms dunning notice rather than dunning letter, final bill rather than termination bill, and price plan rather than billing tariff . If any U.K. English equivalents of U.S. English terminology are used, they are referenced in the Glossary .

xiv


1

Overview This document describes the functional scope and detail of each component of Geneva. The reader should be able to use this manual to: y

Become familiar with the concepts underlying the Geneva rating and billing system.

y

Understand how to integrate Geneva into specific business processes.

y

Choose how Geneva will be integrated with other corporate business systems.

y

Derive a strategy for migration and implementation.

Audience This manual should be studied in detail by business analysts and those concerned with the business and technical implementation of the Geneva rating and billing system. It can also be of help to any organization that needs to verify the suitability of Geneva as a rating and billing system for its specific needs.

Before You Begin This is the first guide that should be read in the Geneva documentation set, therefore there are no prerequisites.


1


2


2

What is Geneva? Geneva is a convergent rating and billing system which delivers active revenue management. It is designed to work with a range of goods and services, typically those delivered online, in any industry in which usage is metered and events are billed. For example: y

Telephony services.

y

Online services such as Internet, pay-per-view TV, video on demand, and application service provision.

y

Utility usage such as electricity, water, and gas.

y

Data services providing: o

Usage charging based on data volume or usage type.

o

Tiered pricing for different quality of service levels.

y

Content-based services in which events are priced according to the value of the information received.

y

Financial services, such as payment processing or trading.

y

Support for wholesale, retail, business and residential, and value-chain billing.

The types of charges that Geneva bills include: y

Periodic charges, such as telephone line rental and cable TV subscriptions.

y

Non-recurring costs, such as connection fees.

y

Metered usage, such as electricity supply.

y

Events, such as telephone calls and pay-per-view TV selections.

Geneva allows a Geneva operator to bill any combination of different products and services, whether or not they are related. They may be billed on a single, consolidated bill or on separate bills depending on the Geneva operator’s (and the customer’s) preference. However, Geneva is not simply an accounting and invoicing system. Geneva is designed to support advanced and sophisticated marketing strategies for selling a range of goods and services. The emphasis is on clear and simple mechanisms to: y

Reduce customer churn, for example via loyalty point schemes, bonus schemes, and limited period discounts.

y

Increase product sales by broadening and deepening the market, for example by permitting the packaging of unrelated products to help cross-selling and by allowing price plans targeted at particular markets to be produced, thus supporting market micro-segmentation.

y

Communicate effectively with customers, for example by allowing Geneva operators full control over the appearance and content of the bills produced.


3


y

Allow new products and services to be introduced to the marketplace rapidly and efficiently.

Figu Figure re 1 summarizes the billing process.

Mediation

Event rating

Convergent billing

Mediation systems deliver unrated events from the services provided.

This process determines the ‘basic’ cost for individual events, including some types of discount.

This process determines all the charges charge s to be made for the account plus one-off and periodic usage-based discounts for collections of events that have occurred over the period. Free bonus events may be calculated and allocated here giving further discounts due to account activity over previous bills.

Bill formatting

This process deals with the presentation of the bill information in the require required d format.

Mr A N Other 123 Nowhere Road Nowhere AA6 6AA

A range of templates can be used to determine the selection of informatio information n presented presente d and its layout.

Bill output

The bill itself. Geneva provides the means to output this in the print format of your choice. In addition, it provides a version for on-screen viewing in case of queries. T ot al ca cas s h

Total cash Checks h To ta l ca s

C he c c k ks s

$

$

C h e c k s h s h s a l c a t a o t T o

$

k s c k c C h e C h

$

Figure 1

4

An Overview of the Billing Process


2 – What is Geneva?

What is Geneva’s Key Benefit? Geneva’s key benefit is its flexibility. Today’s Today’s market is changing rapidly and service providers are finding that in order to compete they are having to adapt their business models to offer an ever increasing range of products and services to their customers. Geneva provides the means to add: y

New products and services with no software changes involved and no new modules required. The only changes are to Geneva configuration settings.

y

Variant price plans offering discounts, bonus scheme membership, or loyalty p oint options which may be targeted at, and have particular appeal to, a particular segment of the market.

y

Packages combining either related or unrelated products and services. Research has shown that packaging together a selection of products and services typically reduces churn by by around 35 percent. percent.

y

Extra products and services when additional, chargeable facilities become available.

y

Additional service offerings to aid expansion into other markets.

These features allow service providers to make their product offering attractive to a wider customer base, to retain their valuable customers, and to increase their revenue per customer. Geneva is independent of the service delivery technology. This means that additional products and services can be added in data, without changes to the software. Geneva is today billing for voice, data, Internet, In ternet, mobile, VAS, GPRS, financial transactions, and gas and electricity supplies with a single adaptive Active Rating Engine and a single billing engine. The Geneva user applications allow a llow these changes to be made ma de simply and efficiently, hence reducing the time to market. In addition, they also allow existing items to be discontinued to avoid complicating the options available and confusing the customer with too many choices.

How Can Geneva Be Used? Geneva can be deployed in many different ways. The following sections provide a few examples.

Within an Integrated Architecture Geneva can be used as a best-of-breed billing component in an overall integrated architecture, alongside other products or in-house systems. For example, within a telephony company, Geneva might occupy a position as shown in Figu Figure re 2.


5


Network management Fraud IP and switched networks

Mediation

Workflow

Trouble ticketing

Customer relationship management

Sales force automation

Provisioning

Order management

Campaign management

Sales scripting

Geneva

Inventory management

Sales order processing

Web self-care

Event rating

Convergent billing

Queries and adjustments

Payments Sales processing Scripting

Interconnect accounting

Multi-party billing

Accounts receivable

Automated payments

Data warehousing

Figure 2

Finance and accounting system

Geneva as Part of an Integrated Solution

Geneva is a modular, open system which provides an extensive range of application programming interfaces (APIs) so that it can be integrated with other systems. For example: y

Geneva can be interfaced with the accounting system of your choice for general ledger maintenance.

y

Geneva can be interfaced with an independent, best-of-breed, customer relationship management package to provide further furth er customer facing functionality.

y

Geneva provides a breakout mechanism to allow information to be retrieved from external systems such as stock control databases.

This means that for each area of the overall system, a Geneva operator can choose the component that is most appropriate for their requirements. In this scenario, Geneva can be used in one of the following ways:

6

y

Built into a new system as the billing component of choice.

y

Slotted into an existing system in place of a billing engine that is proving to be too inflexible, insufficiently scalable or too expensive to maintain to meet the company’s current or future requirements.



As a Standalone Product Geneva can be used as a standalone product. This is a solution for smaller companies and new entrants to the market, particularly those whose customers are mainly businesses, who do not often require the scripted sales-or ientated customer care facilities or specialized management functionality of the residential supplier. Where appropriate, Geneva can be used in this situation with the mediation and provisioning system provided by the network supplier (for example, the switch manufacturer) or independent multivendor network management and mediation systems as shown in Figu Figure re 3.

K R O W T E N

Network management and provisioning

Even Ev entt ra rati ting ng

Conv Co nver erge gent nt bi bill llin ing g

Y Y Y Y

Mediation

Geneva

Y

Payments Accounts rec. Y Collections Y

Y

Disputes and adjustments Bill queries and requests Payments and payment history Unbilled event viewing Customer accounting: > Product registration > Package registration > Price plan subscription

Interaction boundary

Figure 3

Geneva as a Standalone Solution

Geneva provides a comprehensive set of account management user applications (as shown in Figu Figure re 3). These can be used without any additional systems or complemented by additional systems if required, to provide a fully-functional customer management and rating and billing system.

Within a Multiservice Environment Geneva can be used as the central billing component, where a number of separate services are typically being supplied using different delivery technologies, in order to provide convergent billing. Geneva does not follow the restrictive and inflexible end-to-end Customer Care and Billing (CCB) model of traditional packages and systems. It recognizes that service providers operating in many industries need to supply an ever-increasing range of online products and services to remain competitive. Traditionally, Traditionally, this would be done via many distinct single-service systems as shown in Figu Figure re 4.


7


Bill K R O W T E N

Customer Care and Convergent Billing (System 1) Totalcash Checks

$

Bill K R O W T E N

Customer Care and Convergent Billing (System 2) Totalcash Checks

$

Bill K R O W T E N

Figure 4

Customer Care and Convergent Billing (System n) Totalcash Checks

$

Distinct, Single-Service, Systems

However, distinct single-service systems, or systems with separate modules for each type of service, do not allow true convergence. In fact, they are far from ideal, because they are:

8

y

Expensive – when the product range is extended to provide a new and separate service, a complete new CCB system will often need to be added to meet pressing time scales or extensive changes made to the existing systems.

y

Inflexible – inter-system communication is often not available or is expensive and error-prone, so cross-product discounts and packages are not possible.

y

Customer-hostile – a separate account with a separate credit limit is required for each service and separate bills are generated. An integrated, single view of the customer is very difficult to achieve for the customer service representative (CSR), finance, and management reporting functions.

y

Prone to errors – data often has to be keyed in several times, which ma y lead to errors and inconsistencies in the information held.

y

Slow to change – before new services can be launched, new CCB systems have to be tested and commissioned and customer account data must be migrated or re-entered.



The Geneva approach is to use: y

Multiple mediation and provisioning systems where necessary to provide multiservice vendor capabilities.

y

A single, consolidating, billing and customer care system comprised of Geneva and an appropriate, additional, customer relationship management package if necessary.

Figure 5 illustrates this.


Network 2

Mediation


1

GENEVA

Network 2

Total cash Checks

$

Mediation


1

Network n

Mediation

Figure 5

Geneva Within a Multiservice Environment

This approach has a number of advantages. It is: y

Cost-effective – each time the service range is extended, Geneva is simply configured to support the new services.

y

Flexible – sophisticated packages and discounts are supported easily.

y

Customer-friendly – a consolidated customer view is provided both for the customer service representative and, if required, for the bill.

y

Less open to error – customer data only needs to be entered once so inconsistencies cannot occur.

y

Quick to change – the addition of new products or price plans to Geneva is a rapid process that enables new services to be launched efficiently.


9


Thus, the Geneva solution allows new services to be quickly, easily, and cheaply integrated into the existing architecture.

Alongside Legacy Systems Operators who are moving to Geneva from an existing rating and billing system have various options available to them, ranging from modifying the legacy environment to starting again from scratch. As an example, consider an operator who is currently using a system for mobile telephony. Such systems are typically designed for voice telephony and are not well suited to billing for data and content. Thus, the operator has decided to use Geneva for this side of its business. The operator can: y

Introduce Geneva to bill for content and data, leaving the legacy system to bill for circuit-switched voice and Short Messaging Service (SMS). This is a low risk approach, but does not provide convergent billing.

y

Introduce Geneva to bill voice, data, and content for customers who take these combined services leaving the existing system to bill for voice-only customers. This is relatively low risk, and provides true convergent billing for customers who need it. It also provides a gradual migration path to using Geneva for billing all customers. However, if the take-up of new services by consumers is rapid, large numbers of customers may have to be migrated quickly to Geneva.

y

Introduce Geneva for rating data and content, and for convergent billing of customers who take voice, data, and content services. Rated voice calls for these customers would be fed to Geneva for billing. Again, this option is relatively low risk and offers the benefits of true convergent billing for customers who need it.

y

Migrate all customers to Geneva. Although much higher risk, this approach provides the simplicity and operational effectiveness of a single, convergent rating and billing system for all services. It may be viable for smaller operators with a reasonable time frame in which to complete migration.

Billing Multiple Service Providers A Geneva operator may wish to bill on behalf of one or more service provider s. For example, there may be situations where:

10

y

Products supplied by another service provider are offered transparently under the Geneva operator’s brand name. Customers pay the Geneva operator, who in turn pays the service provider.

y

The Geneva operator provides billing services for a number of small e-commerce companies – the companies sell products to end customers and possibly manage their own collections, but billing (and possibly receivables management) is provided through the Geneva operator.



Geneva provides extensive support for multiple service providers: y

Service providers can offer branded offerings to customers within Geneva. Thus, providers can outsource their billing needs to the Geneva operator. Payments can be made by the customers directly to the service provider(s), or via the Geneva operator.

y

Multiparty billing can be used, where several parties pay or are paid for a single event. For example, a transaction made by one customer may be brokered by another. The first party would pay for the transaction while the second party would be paid a broker’s fee. This mechanism can support other models, such as premium rate telephony content provision or sales commissions.

y

Rated events can be dispatched to a service provider, allowing them to monitor customer usage or to bill their customers directly. Products in such cases are assigned to the service provider and charged using two price plans – one for the service provider and one for the service provider’s customer. The service provider is invoiced for the entire charge and can in turn invoice their customers (optionally using only charges generated by the customer price plan).

y

If a single Geneva installation is being used to service multiple service providers, the price plans available are restricted. The Geneva operator can control user access so that price plan information is only visible to specific service providers.

In Multinational Environments Geneva is designed to work seamlessly in environments where the Geneva operator has customers in more than one country. Geneva allows you to: y

Create price plans in any currency. For each product it is possible to define multiple price plans, one for each currency. These price plans are independent of each other, allowing you the flexibility to price the same product differently in different currencies.

y

Levy the appropriate national and regional taxes on products, based on a nominal contracted point of supply and invoicing company, or a tax discount.

y

Use multiple languages. Geneva allows you to set labels in different languages for items (products, packages, price plans, etc.). These labels are used: o

o

In the user applications – when a language is chosen in a user application, the item labels defined for that language are used within lists, display fields, etc. This applies to: –

Accounts Receivable

–

Batch Payment Entry

–

Customer Account Maintenance

On bills, dunning notices, and reports – if a customer has a preferred language, the appropriate templates and item translations will be used when producing bills, dunning notices, and reports for that customer. The item labels and bills produced may be in a different language to the user application itself.

y

Use multibyte character sets.


11


y

Configure and use multiple automatic payment systems within and across countries, for example, BACS-Germany, BACS-France, BACS-UK.

y

Use international standard address formats. These are pre-defined within Geneva.

For Wireless Telephony Geneva provides native support for third generation mobile telephony billing, including: y

TAP3. Geneva supports the TAP3 GSM/GPRS standard, including:

y

o

Home network customers making roamed calls on other networks – Geneva can take TAP3 files imported from a TAP clearing house, validate them (according to GSM standard TD.57), and convert them to Geneva events. These events are then rated and billed as normal. Optionally, the Special Drawing Rights (SDR) prices provided by the foreign network operator can be used. The import process creates reconciliation events against each foreign network operator’s account: these can be cross-checked against bills received from the foreign network for roamed calls.

o

Foreign network customers making roamed calls on the operator’s network – roamed usage is recorded by the mediation process as normal, and accepted by Geneva. This usage is then charged to the correct foreign network operator account via a partial match of the International Mobile Subscriber Identity (IMSI) against a generic event source for the foreign operator (since the first five numbers in an IMSI uniquely identify a network operator). Roamed event files are exported as TAP3 files and dispatched to the foreign network.

Integrated Subscriber Identity Module (SIM) and resource management. Geneva includes an integrated Resource Management System. This integrates the Geneva user applications with a breakout interface to a stock control system. Features include:

y

o

The ability to define stock allocation centers (either physical inventory locations or logical groupings of products such as vanity numbers) and the movement of stock between them.

o

Management of resources defined entirely in data, allowing a wide range of items to be controlled.

o

A quarantine facility for returned stock (for example, returned Mobile Station International ISDN Number [MSISDN] from a terminated account).

Real-time rating discounts. Events can be discounted immediately when they are received in Geneva. This provides additional support for mobile billing, as:

y

12

o

Unbilled usage can be accurately reported immediately.

o

Usage queries such as event cost or amount of bundled free usage left can be answered immediately. For example: –

How much did that last WAP download cost?

–

How many free minutes do I have left this month?

Prepay accounts.



Geneva supports both prepay and postpaid accounts. Prepay accounts are accounts in which the customer pays in advance for the service. Accounts are created as either prepay or postpaid and Geneva provides support for: o

Price plan prices quoted inclusive of tax.

o

Authorization by Geneva of events before they take place.

o

Statements detailing usage, top-ups, and tax collected within a given period, as and when required.


13


14


3

Concepts This chapter defines a number of terms which are used within Geneva and which have specific meanings. A knowledge of these terms is required to fully understand the functionality of the applications.

Customers A customer is a person who, or company which, holds the contract for services and is legally obliged to settle the invoices. A customer takes packages and products that are billed on one or more accounts. A customer may be related to other customers to form a customer hierarchy of any depth and breadth.

Accounts The invoiceable entity. A single customer may have one or more accounts. Each Geneva account uses open item or balance forward accounting.

Products A product is an item that the customer can purchase or lease. It may be a real object (such as a telephone), a service that is delivered (such as telephone line rental) or something more abstract (such as a discount or service level agreement). Products are the items or services that are charged for on invoices. A product can be sold under any number of price plans and offered as a bundle with other products as part of a package. A product can have initiation charges, periodic charges, and termination charges associated with it. A product can also define the source of chargeable events. The purchase of one product may depend upon the purchase of another product. For example, the call barring product cannot be purchased without the line rental product: y

A main product that may be purchased without any dependencies is referred to as a parent product .

y

A related product whose purchase is dependent upon another product is re ferred to as a child product .

Geneva also supports parametric products. A parametric product is a product that can have a quantity associated with it. This allows an account to take, for example, 200 Centrex lines or a 14 mile leased line (where leased line is sold by the mile) and have it treated as a single item.


15


Some products may be event generators (where an event is any measure of usage of a service – see "Events," page 16 for more details). For example, a telephone line rental product generates telephone call events, a GPRS product generates wireless Internet access events, and an e-commerce product may generate item purchase events. Multiple event sources can be listed for a single product. This allows, for example, a single product to be sold which consists of two mobile handsets with combined talk time. Groups of related products may be organized into product families. For example, a telephony product family could contain line rental, call barring, and any other fixed line telephony products. These groupings are optional and are determined by the Geneva operator.

Events An event is any measure of usage of a service which is typically captured electronically by a network. Events are chargeable items that typically appear as line items on a detailed invoice. They are instances or measurements of the usage of a service or product. Event records may be presented to Geneva already rated or may be rated by the rating process. Geneva also allows a stream of partial event detail records that describe an event while it is in progress. These partial events are required to ensure an accurate, evolving picture is maintained for long duration events. Each event can have a number of attributes. For example, an item purchase will have attributes which describe the provider, item purchased (including the price), location of the purchaser, delivery method, etc. An Internet access will have a time, duration, volume of data downloaded, and site accessed. These attributes allow the event to be rated, that is, to have its basic price determined using a particular rate plan. Rating can be carried out by the Active Rating Engine or by third-party engines. When the Active Rating Engine is used for rating events, a rate plan is needed in the rating catalog for that event type. In addition, each price plan for an event-generating product needs to specify the rate plan to be used for rating events generated by that product. As part of the rating process, events may be redesignated to a different account (the destination account). When each event is rated, the Active Rating Engine can reguide events to the destination account dependent on whether the event satisfies the event guiding rule.

Rate Plans A rate plan defines all the rules and parameters for Geneva to be able to determine a price in a particular currency for a single event, such as a pay-per-view event, home shopping selection, etc.

Rating Catalogs Geneva rate plans are designed and stored in a catalog. This rating catalog is a collection of pricing models and parameters that are used by the rating process to price events.

16


3 – Concepts

The rating design catalog is a copy of the rating data used in the live system. This is used to author changes to the catalog. Once complete and checked, the catalog is published by an authorized user. The publishing process copies the rating design catalog information into the live system and makes it available to the rating process.

Price Plans A price plan is a set of prices for the products within a product family. A product may have any number of price plans. Price plans can be arranged as hierarchies so that prices are inherited and modified from one level in the hierarchy to lower levels. A hierarchy begins with a root price plan that must have absolute prices.

Billing Catalogs Geneva price plans are designed and stored in a catalog. This billing catalog is a collection of pricing models and parameters that are used by the billing process to price events. The billing design catalog is a copy of the billing data used in t he live system or it can be a new catalog. This is used to author changes to the catalog. Once complete and checked, the catalog is published by an authorized user. The publishing process copies the billing design catalog information into the live system and makes it available to the billing process.

Rating Rating is the calculation of one or more prices to a single event. Events must be rated before they are billed. It is at this point that any rating time discounts are calculated and applied.

Billing Billing is the aggregation of all non-recurring, periodic, and chargeable events, account by account, and the calculation of all outstanding charges and available discounts and bonuses. The output from billing is a stream of tagged bill data that can be used to create a bill on paper, disk, or any other media.

Budget Centers A budget center is a reporting entity within a single account. It allows the apportionment of an invoice to different budgets within a single account. Budget centers are used to provide a summary of usage and product charges for selected products.


17


Invoices An invoice is a legal document demanding payment for one or more products and their associated usage events for a single account. A statement may accompany an invoice.

Statements A summary of account transactions (such as payments, invoices or refunds) for a single account.

Customer Reports A customer report is a summary of the charges for a number of customer accounts. It may contain a range of information from a single line, account status summary through to every event generated by any event source in the customer/account hierarchy. Customer reports are typically used to summarize usage for corporate customers across a number of accounts within a customer hierarchy. Usually, the content and presentation of customer reports is agreed on a customer to customer basis. Geneva allows any number of different reports to be defined and registered in the database as required. Customer reports may be written as custom reports by the Geneva operator, their systems integrator, or by Convergys.

Itemization An itemization is a detailed breakdown of one or more items of the invoice, such as a list of telephone calls.

Discounts Discount schemes can be constructed in Geneva to reward or penalize particular patterns of usage. A discount scheme can be devised independently of any particular price plan or product, and can be introduced to and discontinued from any price plan over time. Discounts apply to aggregated usage of a particular event type. T he discount scheme can use a filter to act on a subset of events. Discounts can be positive or negative (surcharge) absolute currency values or percentage values. Discounts are applied in threshold bands. Thresholds can be measured on cost or any other measure of usage such as duration. Discounts may be applied either at rating time or at billing time. The benefits of real-time discounting in rating include: y

18

Immediate, accurate representation of the unbilled usage. This is important both for the Geneva operator (view of exposure) and for the customer (view of collections).


3 – Concepts

y

Support for real-time WAP queries (for example, to ask about the cost of a download) or in mobile environments (for example, to ask how many free minutes are remaining).

Filters A filter selects a subset of events based on the value of an attribute of the events, or part of an attribute of the events, for discounting purposes. Values to match can be single values or lists of values. Filters may be combined to form composite filters, where the resultant set of event records is selected on values in more than one attribute.

Packages A package is a group of products marketed together as a bundle with special discounts. Packages comprise one or more mandatory products and any number of optional products.

Subscriptions A subscription is a group of products and/or packages that can be treated as a single unit for the purposes of bill presentation, discounting, and financial reporting. The subscription charges are configurable and not dependent on the products and packages within the subscription. Billing time discounts can be applied based on the product/packages within the subscription or on the number of subscriptions.

Contracts Contracts may be defined for customer accounts. A contract allows a customer to receive preferential rates in return for committing to take a product for a specific length of time, with a possible penalty charge for early termination of the product. The contract terms may be extended beyond their stipulated end time (that is, renewed). Any products taken under a contract must be associated with a price plan that has a term.

Bonus Schemes Usage (or a filtered subset of usage) of any product can be measured on a cumulative basis over any period and rewarded with free usage of the same product or another product by creating a bonus scheme.


19


Loyalty Points A loyalty point scheme accumulates points to reward product purchases and service usage. Points are accrued on an account and reported on bills. The points can then be redeemed against items in a catalog, air miles, monetary credits, etc.

Calling Circles Calling circles define a relationship between users, who are modeled as members and non-members of a calling circle. Using this system a call made by a member of the circle to another member could be priced using a different rate to that applied to a non-member making the call. Calling circles can span networks and a single circle can include both mobile and fixed-line users.

Payments and Refunds Each physical payment requires a payment method. Payment methods typically include cash, check, etc. In addition, Geneva can automatically generate payment requests for payment methods that support automatic transfers of cash (for example, direct debit, credit card). Payments made by these methods are automatically collected from the customers. Geneva records and maintains the payment details for each customer account. Payments received can either be allocated to invoices according to the age of the receivable, with the oldest invoice being created first (balance forward accounting) or allocated to specific invoices (open item accounting). A refund is defined as monies paid back to the customer, either automatically (such as direct deposit) or interactively (such as by sending a check). All refunds that have been made may be viewed in the Geneva user applications.

Budget Payment Plans Budget payment plans allow customers to pay a regular amount periodically towards their bills rather than paying each bill separately. The plan specifies the payment method to be used (typically direct debit) and the rules for calculating the payments. The amount being paid is reviewed periodically and adjusted according to the current outstanding balance and expected spend over the coming review period.

20


3 – Concepts

Convergent Prepay Accounts in Geneva may be defined as either prepaid or postpaid. Geneva offers prepaid services with exactly the same services available as for postpaid. With prepay a customer can interrogate an account balance at any time and control spending by making incremental additions to their account balance in the form of top-ups.

Service Providers Service providers can offer branded offerings to customers within Geneva. Thus, providers can outsource their billing needs to the Geneva operator. Payments can be made by the customers directly to the service provider(s), or via the Geneva operator. Service providers are defined within Geneva as invoicing companies.

Deposits Deposits are amounts of money held against an account in parallel with the account balance, usually to offset possible failure to return equipment, non-payment of bills, etc. A deposit can be applied as an account payment, or can be increased by having account payments transferred to it. A deposit has no effect on the account balance until it is applied, either manually or automatically. The full deposit can be auto-applied to the account balance when the account is terminated.

Currencies Geneva supports multiple currencies in a single installation. For example, it allows the Geneva operator to bill a number of customers, some of whom are in France, some in Brazil, some in Canada, etc. and use the appropriate currency. It also allows the Geneva operator to bill customers who themselves have branches in different countries.

Disputes and Adjustments A dispute is a record of a query about an amount of money on an account. Normally, a dispute will be recorded when a customer queries some aspect of their bill. An adjustment is a method of crediting or debiting an account with an arbitrary amount of money. Adjustments can be lodged against either an account as a whole or against a particular rated event on that account. If a dispute is accepted an adjustment is created to credit the account with the disputed amount.


21


Tax Geneva supports multiple taxation models, for example, VAT/GST, U.S. tax, and Brazilian tax. Geneva’s internal tax mode is VAT/GST. U.S. Tax and Brazilian Tax are supported externally via third-party tax packages. Using GLOBA L tax mode enables VAT/GST tax and a third-party tax to be configured in the same instance of Geneva. The taxation model Geneva is using can affect the appearance of some screens in the user applications and some of the functionality. The Geneva documentation set describes Geneva’s functionality if the internal tax model (that is, the VAT/GST tax model) is being used – changes in functionality when using a third-party taxation model are detailed in the relevant integration guide, for example, the Geneva Vertex Integration Guide for U.S. tax.

22


4

System Elements

User Applications The user applications are all PC-based programs and provide the user interface to Geneva. Each user application is supplied with full help. For installations of Geneva using multiple languages, the Geneva user applications can display translated item labels, for example, product names, event discounts, etc. if such translations have been provided.

System Configuration System Configuration is used to configure operational aspects of the system. A brief selection of items which it may be used to configure is given below: y

Event details, including event types, event file details, the bindings used to format data imported or exported from the Active Rating Engine, event revenue mapping details, and multiparty event details.

y

Customer and contact types.

y

Currencies and conversion rates.

y

Bill formatting details, including bill formatters, itemization orders and overrides, bill inserts, handling codes, and event summaries.

y

Finance and billing details, including adjustment types, service providers, exceptional bill conditions, revenue codes, and termination reasons.

y

Tax details, including invoicing company and contracted p oint of supply details, tax types, tax codes, and invoice registers.

y

Payment details, including payment systems and methods, payment failure codes, and any holding accounts.

y

The aging of receivables process, including payment due days, dunning models (both account level and invoice level dunning models are supported), the collections schedule (defining a sequence of actions to be taken at different ages of receivables), holiday profiles, and dunning notice templates (which can be separately configured for each language in use).

y

External interface details, including the provisioning systems available for use in dealing with service requests and the formats for data export via the Accounting Data Writer.

y

The languages defined in the system and the item labels to be used for each active language.

y

Managed file details, including file group and file type details.


23


y

Access control details, including management of Geneva users (creating new users, assigning them business roles, controlling user accounts, and setting their passwords), defining business roles, and data permissions.

Product Configuration Product Configuration provides a simple interface through which to create and configure products, product hierarchies, and subscription types. Using it, the Geneva operator can: y

Create products, product families, and subscription types and view the product hierarchy within each product family.

y

Define a unique set of attributes and event source labels for each product or product family.

y

Assign provisioning systems to products.

Bill Renderer The Bill Renderer is an optional component of Geneva. It takes the RTF files produced by the Bill Formatting Engine and the Dunning Letter Engine and renders them as Microsoft Word files. A separate launcher is provided to enable multiple instances of the Bill Renderer to be run simultaneously, either on the same machine or on different machines, to reduce the time taken in processing. The Bill Renderer: y

Reads the RTF files and control documents produced by the Bill Formatting Engine and the Dunning Letter Engine.

y

Produces individual Microsoft Word documents for each original RTF file.

y

Produces one consolidated Microsoft Word document, suitable for printing, for each group of RTF files.

Billing Catalog Maintenance Billing Catalog Maintenance is used for creating and modifying billing catalogs. It is a powerful application, designed for use by a senior price plan designer, which provides a simple-to-use interface for setting up the packages, price plans, discounts, and bonus schemes in a particular currency to be made available for sale to customers. It allows the price plan designer to:

24

y

Create price plans and prices and view the price plan hierarchy.

y

Create packages.

y

Create and link discounts and filters.

y

Create bonus schemes.

y

Copy catalogs from one currency to another.


4 – System Elements

When the catalog is complete, it can be promoted to test status for checking and then published to the live status so its products and price plans, etc. are available for selling to customers and billing accounts. Catalog promoting and publishing is carried out within Billing Catalog Maintenance. However, for security reasons, only users with the appropriate business role may promote or publish a catalog.

Rating Catalog Maintenance The Active Rating Engine and associated Rating Catalog Maintenance are optional components of the Geneva system. The Active Rating Engine provides a flexible and powerful general-purpose rating capability, able to rate many different types of event-based services such as telephone calls, Internet access, home shopping and pay-per-view selections, utility meter readings, and financial transactions. Rating Catalog Maintenance is a powerful application, designed for use by a senior rate plan designer. It can be used to view, create, and modify the rules and data, that is, the rate plans, for pricing individual events. For example, for a telephony rate plan a Geneva operator can address the full range of standard telephony rating requirements, including: y

Time of the call.

y

Duration of the call.

y

Number dialed.

y

Distance between the origin and destination of the call.

y

How the event was connected.

y

Whether the recipient was also on the caller’s network.

y

Whether the call was in a local calling area.

Alternatively, for a video conferencing rate plan, it can cover: y

Time of conference.

y

Duration of conference.

y

Average quality of service achieved during the conference.

When the catalog is complete it can be promoted to test status for checking and then published to the live status so its rate plans are available for use by the Active Rating Engine. As with billing catalogs, Geneva supports the use of multiple live rating catalogs per pricing currency in use in the system. The catalogs exist independently of each other, and can be edited, published, etc. as individual items. Ratings catalogs in one currency can also be copied into another if required. Catalog promoting and publishing is carried out within Rating Catalog Maintenance. However, for security reasons, users require a higher access level to carry out these operations.


25


Customer Account Maintenance Customer Account Maintenance is used for creating, modifying, and viewing customers and accounts. It provides the functionality to set up and maintain all customer and account data and will typically be used by administrative staff to: y

Record and modify customer details.

y

Record and modify product and service profiles for customers.

y

Record and modify basic account billing information.

y

View bills and rated events.

y

Record adjustments and disputes.

y

Request interim bills.

y

Enter, view, and cancel physical and account payments, refunds, payment requests, and refund requests.

y

View an account’s collections record.

y

Record loyalty point adjustments and redemptions.

Accounts Receivable Accounts Receivable allows you to see the legal or net receivables across a range of accounts within a specified currency. The accounts can be selected by: y

Amount of receivables being greater than a given threshold.

y

Amount of receivables older than a particular age being greater than a given threshold.

y

All accounts for a single customer.

y

All accounts for a customer hierarchy.

y

All accounts with active disputes.

y

All accounts on open item accounting with unallocated cash.

y

All accounts with collections actions which are held for review.

In addition, the Geneva operator can view disputes and adjustments across a range of accounts. The disputes and adjustments can be selected by: y

Transaction status (Pending, Accepted, Rejected, Cancelled, etc.).

y

The user who created the dispute or adjustment.

y

The date the transaction was entered.

y

Transactions entered for a particular customer type.

y

26

Adjustments within a certain range of values.



Batch Payment Entry Batch Payment Entry provides a rapid method of entering batches of physical payments which all have the same type and currency. These will typically be check payments. Validations are made on the total number of checks entered and total amount of the batch. Once the physical payments are entered, they are automatically applied as account payments (if possible).

System Monitor System Monitor provides a user interface for controlling the Task Master (see "Task Master," page 32). Commands available from System Monitor include: y y

Halting the Task Master. Altering the periodic schedule.

y

Creating schedules.

y

Requesting status information.

y

Changing the status of jobs in bulk.

y

Starting volume processing applications on demand. System Monitor and the Task Master can run any third-party UNIX package, such as a report writer or customer script, if required.

Configuration Data Transfer Configuration Data Transfer allows authorized users to import and export sets of table values. This process can be used to transfer configuration data between different Geneva instances, such as from a test system to a live system. The data files that are transferred consist of either the entire contents of each table (or set of tables), or just the differences between the table values and the values in an existing export file. The application also allows the import of any files created by other Configuration Data Transfer applications on any other Geneva system, provided the table definitions are identical.

Rejected Event Maintenance Rejected Event Maintenance supports the viewing, interrogation, modification and resubmission of rejected events that are stored in the database. Rejected events are displayed and managed via a tree structure. The levels comprise a top level summary, a rejection category level (for examp le, cost code 0121 not found) and then the list of events within that category. This allows the Geneva operator to select a subgroup of events to work with.


27


The Geneva operator can perform a number of tasks at each level, such as: y

Viewing rejected events.

y

Modifying an event.

y

Test rating an event.

y

Posting internal/uncosted.

Rejected Event Maintenance can be used by the Geneva operator to change the reject status, for example from Rejected to Post Internal . The user can also change the reject status from its new status value back to Rejected , providing an effective way of managing rejected events. Additionally, users can test rate an event and validate the new values that will be passed back to the Active Rating Engine, as well as providing the functionality to force the supporting rating engine to recache. If a user cannot fix an event it is possible to discard it in a way that the Active Rating Engine will ignore it in the future. Geneva can optionally keep a record of all events going into and out of the Active Rating Engine for revenue assurance. This could then be used by the Geneva operator to determine reject rates.

Product and Pricing Edits Transfer Product and Pricing Edits Transfer enables any changes made to products or billing/rating catalogs to be exported from one instance and imported into another. This application includes the functionality to: y

Export differences. This entails outputting all the details needed to reproduce every change to products or catalogs since either creation or the last exported XML file.

y

Import differences. This entails using the exported XML file to replicate changes on another system, or in another design catalog on the same system.

y

Record differences. This could entail, for example, recording the changes made to a design catalog on a separate system to the live catalog.

y

Resolve conflicts. This may be necessary if changes are proposed that are incompatible with the database.

System Processes The volume processing applications are all UNIX-based programs. They perform the volume processing activities of Geneva. The main volume processing applications are described individually at the start of this section. The additional volume processing applications are described in functional groups at the end of this section. The operation of the Geneva volume processing applications is described in detail in the Geneva System Processes Guide .

28



Billing Engine For each customer account, the Billing Engine uses the live billing catalog to: y

y

Calculate any early termination surcharges and periodic, non-recurring, suspension, suspension periodic, reactivation, refund, and termination charges (taking into account any specified contract terms, override product pricing, etc.) and prorate them as necessary. Aggregate the events generated by the account.

y

Calculate discounts on products and events, using filter s to select them.

y

Process any unbilled disputed events (events that a customer disputes before they appear on a bill) together with any associated approved adjustments.

y

Calculate any applicable discounts, using filters to select them.

y

Handle bonus schemes by performing the following actions at the appropriate times: o

Rerating of events to take into account any free event thresholds that apply.

o

Calculating the usage for the current period.

o

Converting the usage into bonus units.

o

Calculating the free event thresholds for the next redemption period.

y

Select the marketing messages for the account.

y

Calculate and apply appropriate tax charges.

y

Check if thresholds have been reached and, if they have, take appropriate actions.

y

Generate an invoice number or create a placeholder to be replaced by the Invoice Number Generator.

y

Select the marketing messages and bill inserts that are appropriate.

y

Generate any required summary statements.

y

Generate any required copy bills.

y

Generate payment requests.

y

Generate budget center reports.

y

Generate accounting information, including spend by revenue code.

y

Store enough information for the Bill Canceller to unwind the bill being produced, irrespective of the tax regime.

y

Write the bill’s optical character recognition (OCR) reference to BILLSUMMARY.OCR_NUM if OCR is configured.

y

Output the PREPAY tag to bill data. This has a value of T (true) if the account is prepay, otherwise it is F (false).

Bill Data Writer The Bill Data Writer performs the task of reading the bill data from the database and writing it to a file in the managed file area.


29


To do this, the Bill Data Writer takes the text representation of bills and dunning notices produced by the Billing Engine and Dunning Letter Engine. From these, it generates a text file containing a concatenation of the data of many single bills which is stored in the managed file area. It then records a job in the database with a job identifier for the appropriate application.

Bill Formatting Engine Geneva allows the bill formatting stage to be undertaken by one of the following: y y

The Bill Formatting Engine. A third-party document formatting package.

The Bill Formatting Engine is appropriate for print volumes of up to approximately 100,000 residential bills per month. For larger volumes, or for large-scale business billing, third-party packages which support volume printer formats such as Xerox metacode or IBM AFP are usually required. The selection of an appropriate package depends on many factors, including the technology used by the selected fulfillment house. If large-scale corporate bills with large numbers of itemized events are produced, it may be more appropriate to produce electronic bills. This can be done by using the Bill Data Writer to export the data to a file, where it can be edited via the Managed File Modifier (or user-defined custom scripts). Geneva allows different formatting engines to be used to format the bills of different accounts. For example, one customer could be billed using the Bill Formatting Engine and another by a third-party engine in order to receive their bill by e-mail. The Bill Formatting Engine combines the bill data managed file produced by the Data Writer (see also "Bill Reissuer," page 33) with a rich text format (RTF) bill template, which can be specific to the account and produces a formatted bill in RTF.

Bill Product Charge Deleter The Bill Product Charge Deleter deletes BILLPRODUCTCHARGE records. Records can be deleted for: y

A specified account.

y

All accounts within a specified customer account hierarchy.

y

All accounts in the system.

Debt Escalation Engine The Debt Escalation Engine ages collections. It creates collections action requests where appropriate and writes these requests to the database.

30



Dunning Letter Engine The Dunning Letter Engine takes the records created by the Debt Escalation Engine and the customer details in the database. It then outputs the information content of the dunning notice as a database record, ready for formatting by the Bill Data Writer.

Accruals Extract Generator The Accruals Extract Generator collates earned but unbilled accruals information and uses it to populate entries in the ACCRUALS table. The ACCRUALS table is used when exporting information to third-party systems. Information collated includes: y

y

Costed events that were created prior to the earned but unbilled accruals dat e and are unbilled or were billed after it. Adjustments, which may have a positive or negative effect on unbilled income.

y

Product initiation charges unbilled at the earned but unbilled accruals date.

y

Product final charges unbilled at the earned but unbilled accruals date.

y

Periodic product charges unbilled at the earned but unbilled accruals date.

For periodic product charges, the amount recorded should be prorated to reflect the number of unbilled days between the last bill (or since the product was started) and the earned but unbilled accruals date.

Outbound Message Dispatcher A Geneva operator can invoke specific actions when account monetary thresholds are crossed. This involves sending a message to notify an external system that an external action is required. The Outbound Message Dispatcher provides a link between the Account Action APIs and the Outbound Message Library fo r messages to be passed to any external system. It can be run as a continuous process with a maximum run time, or with a configurable polling delay.

Active Rating Engine The Active Rating Engine is an optional component of Geneva which can be used to rate individual events for a wide range of different event-based services. The Active Rating Engine can run in one of three modes: y

Standard file-based mode – in which event information arrives in the for m of database entries and managed files. The Active Rating Engine runs until there are no more jobs.

y

Daemon file-based mode – in which event information arrives in the form of database entries and managed files. The Active Rating Engine runs continuously as a daemon.

y

Real-time mode – in which event information arrives via a TCP/IP socket interface. The Active Rating Engine runs continuously, as a daemon.


31


Geneva operators can also create their own customized rating input plug-ins. These let Geneva communicate with the wide variety of messaging systems that are available. The Active Rating Engine calculates the basic cost of individual events according to one or more rate plans. It then loads this information into the database in a format acceptable by either the Billing Engine or Customer Account Maintenance (for online viewing). If a third-party rating engine is being used or if prerated events are being received from a partner company, then these can also be imported into Geneva.

Accounting Data Writer A Geneva operator may wish to export data from within Geneva for use by external systems. The Accounting Data Writer is an optional component of Geneva that provides an easy-to-use interface for the export of accounting and invoice data. The Accounting Data Writer takes accounting and invoice data from the database, exports it as an ASCII text file (preformatted for import into Microsoft Excel) and maintains an audit trail tracking data exports.

Invoice Number Generator The Invoice Number Generator is an optional component of Geneva. It is only required if invoice numbers are being assigned sequentially across multiple accounts. The Invoice Number Generator finds invoices awaiting invoice numbers and assigns them numbers based on the appropriate invoice register.

Denormalized Count Updater The Denormalized Count Updater calculates the various denormalized counts from scratch. It would typically be used in three scenarios: y

Following initial migration to a new schema.

y

Following bulk data import via the File-based Database Updater, during which dynamic count updating has been turned off.

y

On an ad hoc basis at any time to correct the counts.

Task Master The Task Master is a background server process that runs continually, managing the starting and stopping of the Geneva volume processing applications. It can be used to automate all volume processes.

32



The Geneva volume processing applications can be chained together as sequences of processes, for example, to import events and then rate them or to bill accounts and then format the bills. This chain can be controlled by the Task Master System Monitor and the Task Master can run any third-party UNIX package, such as a report writer or customer script, if required. If a Geneva operator requires alternative and more sophisticated scheduling functionality, the Task Master can be replaced by an external scheduler. This provides a large Geneva operator with: y

A single view of all processes, such as from the same application, showing revenue assurance, provisioning, CRM, etc.

y

Additional scheduling functionality.

Test Rating Daemon When designing a rate plan, it is useful to be able to see it in action. The Test Rating Daemon is an optional component of Geneva that costs sample events according to a chosen rate plan, but does not make any changes to the database.

Additional Billing Processes A number of processes are provided to perform other actions o n bill data.

Bill Canceller The Bill Canceller cancels the most recent bill generated for one or more specified accounts. Only the most recent bill produced for an account can be cancelled.

Bill Reissuer The Bill Reissuer finds any bill reissue requests and locates the relevant database record produced by the Billing Engine. It generates a text file concatenating the data, saves the file into the managed file area and records a job with an identifier for the appropriate application. This mirrors the functions of the Bill Data Writer.

Managed File Processes Geneva operates in a managed environment in order to protect the information on which it acts. A number of processes are provided to handle the files in this managed area.


33


Managed File Importer The Managed File Importer is used to import external files that are to be acted upon, for example event files, into the managed file area. The Managed File Importer looks in a directory, defined by an application parameter, for any files which have been placed there, and, if it finds one, moves it into the managed file area. It then records a job in the database with a job identifier stating which Geneva process should handle it.

Managed File Exporter In addition to importing files into the managed file area, Geneva may also need to export files from this area. The Managed File Exporter is used to export files, for example, bill data files for formatting by a third-party formatting package, so that they are available to external applications. The Managed File Exporter moves files from the managed file area to a directory. It can move files within either: y

An individual file group (that is, a collection of file types).

y

All file groups.

Each file group defines the path name of the directory to which the files are to be moved.

Managed File Modifier The Managed File Modifier is responsible for giving external processes access to Geneva’s managed files. These processes can be used, for example, to customize bill data prior to it being formatted or manipulate files of events before rating. The Managed File Modifier takes a managed file, runs a customized script on it and produces a replacement managed file.

File-based Database Updater If processing is carried out by an external system, information needs to be transferred back from that system into the Geneva database in order to keep the database up to date. For example, if bill formatting is carried out by a third-party formatting package, this package must supply information about the accounts successfully handled so that Geneva knows the correct status of the bill and also where the bill image is stored. The File-based Database Updater performs the necessary changes to the database when it is supplied with a file of information of the correct format in the managed file area. The File-based Database Updater performs database modification tasks taking its input data from managed files. In particular it updates account information to:

34

y

Confirm that formatting requests have been processed by an external system.

y

Specify which bill inserts the account should receive when billed.



y

Insert payment entries for check payments made via a Lockbox service.

y

Enter failed direct debit payment details.

Settlement Period Manager This is required if the conditional settlement functionality is being used. The Settlement Period Manager generates and manages settlement period data, which is used when assigning charges to settlement buckets. It ensures that the correct number of settlement period records are available for use and deletes out-of-date settlement bucket data.

Settlement Period Payment Allocator This is required if the conditional settlement functionality is being used. Payments are allocated to bill receivables using Customer Account Maintenance. The Settlement Period Payment Allocator, which monitors settlement payment records, is then run. This daemon process performs the necessary allocation of payments to settlement buckets. See "Conditional Settlement," page 128 for further details.

Additional Rating Processes Discount Usage Manager The Discount Usage Manager updates rating discount usage records in the database.

Event Processes Event Writer The Event Writer is used to propagate event information within Geneva. The most common use of the Event Writer is when separate Event and Geneva databases are in use on different machines. When the Event Writer is in use, applications do not directly write to the event database (primarily the COSTEDEVENT and REJECTEVENT tables). Rather, requests are placed in a queue, and the Event Writer reads these requests and updates the event database as required.

Real-time Duplicate Preventer The Real-time Duplicate Preventer is an optional plug-in to the Active Rating Engine. It identifies duplicate events arriving within a Geneva operator configurable period.


35


Real-time Duplicate Check Maintainer The Real-time Duplicate Check Maintainer deletes old events from specified duplicate check tables.

Duplicate Event Identifier The Duplicate Event Identifier records all events that are duplicates within the accounts being searched and accordingly adjusts the billing status of any account found to contain duplicates.

Duplicate Event Remover The Duplicate Event Remover removes the duplicate events identified by the Duplicate Event Identifier and sets the billing status of the account to indicate that it is ready to be billed again.

Event Unloader The Event Unloader removes a selection of rated events from the database and updates the revenue assurance totals appropriately. The events to be removed can be selected by a variety of different conditions. If the exact condition required is not provided by default, then customized routines can be used (a stored procedure is provided to help with this). Unloaded events can be reloaded via the Task Master.

Rejected Event Input The Rejected Event Input plug-in selects any rejected events that need rating from the REJECTEVENT table and presents them to rating. The plug-in is also used to perform the batch resubmitting of rejected events. The main process contains two transactions: y

Selecting and updating the rejected event records that are to be presented to the Active Rating Engine. The results are returned to the plug-in during the pre-commit function.

y

Updating or deleting the records depending on whether an audit is being kept. This delete/update is committed by the Rating Engine.

It is possible for multiple Rejected Event Input plug-ins to run simultaneously alongside each other. To enable the multiple processing, a RANDOM_HASH is added to each REJECTEVENT table by the Active Rating Engine to allow segregation of the work between multiple plug-ins.

36



To ensure that each Rejected Event Input plug-in does not significantly change the transaction process of the rating engine it does not hold a transaction open for the whole time rating is processing the events.

Rejected Event Modifier The Rejected Event Modifier plug-in is used to automatically perform functionality similar to that available within the Rejected Event Maintenance user application. For example the plug-in is able to: y

Change the status and categorization of an event or events.

y

Manipulate an event returning edited data that may be used when the event is presented back to the Active Rating Engine (a user will have the chance to change this data before it is processed).

y

Modify the event, for example, by changing the event source.

y

Change the rejected event status to Discarded so that events that have been through the rejected event mechanism several times will be discarded at a later date. The rejected event modifier plug-in is called before any event is inserted into the REJECTEVENT table.

Archive and Delete Processes A number of processes are provided to assist with the archiving and deletion of records within the Geneva database.

Event Archiver Events comprise the vast majority of Geneva’s data storage requirements. Consequently, the backing up, archiving and deletion of events are performance-critical activities for which Geneva provides specialized volume processing applications. The Event Archiver determines which billing run(s) events should be archived for. This is based on the current date and a Geneva system parameter which specifies how long events should be kept after being billed. For each billing run to be archived it creates an ASCII archive file in a directory, defined by a Geneva system parameter and an archive record(s) in the database.

Event Deleter The Event Deleter deletes all events that have been arch ived, and have been successfully backed up after the archive. (This condition ensures that there is a backup of the archive file in case the archive file becomes lost or corrupted outside of the Geneva managed file area.)


37


Rejected Event Archiver and Deleter The Rejected Event Archiver and Deleter process performs all archiving and deletion of records within the REJECTEVENT table. The basic function of this volume processing application is to: y

Select a number of rejected event records of the status Processed , Discarded , or Filtered whose reject status is longer ago than the specified system parameter.

y

Output events to a specified directory for archiving.

y

Delete records from the table.

This process is able to run in parallel, splitting the work by using the same RANDOM_HASH as used by the Rejected Event Input plug-in. See "Rejected Event Input," page 36 for further details.

Bill Data Deleter The Bill Data Deleter deletes all bill data, budget center report data and dunning notice data that is older than a certain specified age, defined by a Geneva system parameter, has been archived, has been successfully backed up after the archive, and has no o utstanding formatting requests (for example, bill reissue requests).

Terminated Account Deleter The Terminated Account Deleter deletes all data relating to accounts that are terminated, have an invoicing company that permits terminated account deletion, were terminated more than a specified time period ago (defined for each invoicing company), and have a balance of zero. Optionally, it can also delete customer data. This can occur if the customer’s invoicing company permits customer data deletion and the last account for the customer has been deleted.

Customer Notes Deleter The Customer Notes Deleter deletes customer notes that are older than the value specified by the system parameter SYScustomerNoteKeepDays. If the value of the parameter is null, no deletion of customer notes will take place. The Customer Notes Deleter allows the deletion of notes for one specific customer only and provides the ability not to delete customer notes for which there is an action defined and for which the action has not been completed.

38



Managed File Deleter The Managed File Deleter deletes all managed files that have been backed up, are not in use by any jobs, and have not been used for a particular number of days (as defined by a Geneva system parameter). Optionally, it also deletes the managed file data and log data from the database.

Orphan Managed File Deleter The Orphan Managed File Deleter deletes all managed files that are not referenced anywhere in the database.

Process Log Deleter All processes started by the Task Master deposit their log files in a common area (specified by a Geneva system parameter). The Process Log Deleter deletes log files that are in this common area and are at least a particular number of days old (as defined by another Geneva system parameter). The Process Log Deleter will also remove the corresponding database entries. The process logs are not automatically archived by Geneva. If required, these can be done using standard operating system utilities.

Service Request Deleter The Geneva provisioning interface allows products to be designated as provisionable. When a provisionable product is modified, a service request will be created and passed to the provisioning system. The Service Request Deleter deletes service request records that have been provisioned and are at least a particular number of days old (as defined by a Geneva system parameter).

Mandate Instruction Interface Processes Geneva supports the processing of automatic payment collections and refunds on bank accounts after the customer has signed the appropriate payment authority. If a payment method requires payment authorization information to be submitted to the payment authority (typically a bank), the automatic payment authorization interface processes provide a mechanism through which this can happen. The interface consists of two separate components.


39


MI Write Some payment methods require payment authorization instructions to be sent to the payment authority some days before a payment authorization may be used for collecting payments. For example, a direct debit payment authorization requires a direct debit instruction to be sent to the bank before any direct debits can be collected. MI Write reads payment authorization instruction requests from the database. It then prepares data for submission to the payment authority and outputs a file containing the data.

MI Complete When a payment authorization request file, produced by MI Write, is submitted to the payment authority, a message is returned to say whether or not the submission was successful. MI Complete should be run after the response is received, to confirm or cancel the payment authorization instructions. MI Complete either confirms the payment authorization instructions by activating the payment authorizations or cancels the original payment authorization instruction request by undoing the database changes performed by MI Write for the payment authorization.

Payment Request Interface Processes Geneva supports a generic payment request interface for exporting electronic payment requests. This interface produces standardized files, which can then be post-processed to format them for any desired payment system, for example, Banks Automated Clearing Services (BACS) and Barclays International Direct Debit (BIDDS) systems. The payment request interface consists of two separate components, PR Write and PR Complete.

PR Write The Geneva billing process generates payment requests. The P R Write process produces a generic payment request file (PRF) containing a record for each outstanding payment request. The number of managed files is determined by the number of currencies, payment systems, optional payment methods, and holding accounts. PR Write reads payment requests from the database. It then prepares data for submission to a post-processor, outputs a file containing the data and creates jobs for PR Complete and the Managed File Exporter to export the file, or Managed File Modifier to customize files for a particular format (for example, BACS).

40



PR Complete When a payment request file, produced by PR Write, is submitted to the external payment authority, a message is returned to say whether or not the submission was successful. PR Complete should be run if the submission was successful, to confirm or cancel the payment requests. PR Complete confirms the payment requests by adding the appropriate payments to the database or cancels the payment requests by undoing the database changes performed by PR Write for the payment requests.

Post-Processors Payment request files are produced in a standardized format. Befo re they are submitted to the external payment authority, they will need to be p rocessed into a suitable format.

Customer and Account Processes It is occasionally necessary to change customer/account reference numbers. Making these changes can be very demanding on system resources as these numbers are referenced at multiple locations throughout the database. For example, changing the number of an account with events billed against it also requires changing the records for those billed events. Specialized volume processing applications enable this processing to be scheduled at appropriate times (for example, times of low system usage such as at night).

Account Number Modifier If an account has just been created via Customer Account Maintenance, the account number can be changed within the application. Otherwise, the Account Number Modifier volume processing application must be run to change the number. The Account Number Modifier searches through the database for every reference to a specific account number and changes each instance found to a specified new number.

Customer Reference Modifier Similarly, customer reference numbers can be modified immediately upon creation. Otherwise, the Customer Reference Modifier volume processing application must be run to change the number. The Customer Reference Modifier searches through the database for every reference to a specific customer reference number and changes each instance found to a specified new number.


41


Cache Processes Cache Loader The Cache Loader process builds and refreshes the in-memory caches used by the Active Rating Engine. It can be run in parallel with itself and any other process that uses the in-memory caches. The Cache Loader determines which rating host it is running on. Each Cache Loader instance uses this information to determine which customers and accounts should be loaded into the caches by each process according to the domains that have been associated with the rating host. Once a Cache Loader instance has compiled a list of the caches that it is required to populate on the particular rating host, it bulk loads data from the database into the cache instances.

Cache Manager A single Cache Manager process manages all caches on a given rating host. As account, customer, and product related data is updated within the Geneva database via the user applications or APIs, messages are generated and sent to the Cache Manager. The Cache Manager retrieves these messages and updates all the cache instances on its host that are impacted by the change. In this way the cached copies of data that the Active Rating Engine uses for event processing reflect the changes made in the Geneva database.

Event File Distributor If domaining is enabled, the Event File Distributor acts as a merge/split process for rating input files. The Event File Distributor process determines which domain group each event belongs to and creates one managed file per domain group.

42


5

Functional Features

Rating Geneva event rating provides a flexible and powerful general purpose rating capability, able to rate many different types of event-based services such as telephone calls, Internet access, home shopping, and pay-per-view selections. In Geneva, rating an event is the process of calculating a price for a single event in isolation from all other events. The Active Rating Engine can be used in three ways: y

It can be scheduled to run at a given time, at which point it will rate all the events that are waiting and then terminate.

y

It can be scheduled to start at a given time, and to run continuously for a given period, during which it will poll at configurable intervals to see if there are any more event files waiting. Thus if a suitable number of instances of the application are run and set to poll, say, every second, event files will be rated as soon as they arrive, hence providing real-time rating.

y

It can be scheduled to start at a given time and to run continuously for a given period. Real-time rating is offered via a TCP/IP socket interface between the Active Rating Engine and, for example, a mediation and e-commerce system.

Geneva also provides a Test Rating Daemon (a daemon is an applicat ion which runs in the background checking periodically to see if there are any tasks for it to perform). This can be given the attributes of any event and a rate plan and it will calculate the basic price for that event, without updating the database. An application programming interface (API) is provided to this application so that it can be accessed from external systems, thus allowing, for example, a caller to be informed of the cost of the call they have just made. The actual rating of the event can then be performed whenever is convenient.


43


Scheduled

File-based real-time

Event-based real-time

Figure 6

Use of the Active Rating Engine.

In addition, Geneva maintains unbilled subtotals for each event source whose usage is assigned to an account. These subtotals are updated immediately when events are priced and can be used to show the current situation for an account via a report. Alternatively, they can be used by system integrators to trigger customer service representative activity or a bill request, etc. when a certain credit limit is reached. Unlike rating engines from other manufacturers, Geneva is not limited to one particular type or class of event, such as telephony CDRs or data service data records (SDRs). Geneva allows the Geneva operator to define any number of events in data. The Geneva operator may define all the event attributes for each event type and instruct Geneva as to their meaning. Events represent an occurrence of something such as a telephone call, a selection of a movie, purchase of goods, access of a web site or other service, transfer of data, delivery of an SMS or paging message or use of a toll road. Geneva allows these and as many others as are required to be defined in data, associated with products, and then rated and billed. For example, for a telephony rate plan you can address the full range of standard telephony rating requirements, including: y

Time of the call.

y

Duration of the call.

y

Number dialed.

y

How the event was connected.

y

Whether the recipient was also on your network.

Alternatively, for a pay-per-view cable TV system, it can cover:

44

y

Time of viewing.

y

Duration of viewing.

y

Type of program watched.


5 – Functional Features

Geneva rating allows up to four different prices to be calculated and saved per event, each using a different Geneva rate plan. This allows the Geneva operator to calculate and store a retail price, competitor price, an internal cost, and an external cost per event if required. Geneva also supports supplementary rate plans. Some of the more complex products being offered over IP networks require more than one measure of volume, referred to as multiple scalars . For example, a Geneva operator might want to charge for: y

The duration for which a connection is made to transfer some data

y

Plus the volume of data transferred as measured in kilobytes

y

Plus the value of the data transferred

For example, the pricing structure could be set up as follows: Attribute A: Duration

28 cents per minute, plus

Attribute B: Volume

5 cents per KB, plus

Attribute C: Value

2 percent of the value (expressed as 2 cents per dollar, where the volume units are dollars).

For each event, the price to the customer is determined to be: P = (A x p 1) + (B x p2) + (C x p3) Where: y

P = total rated price.

y

pn= prices for different methods of charging.

A rate plan may have many supplementary prices. These supplementary prices can be of a different type and therefore use different attributes of the event as the volume measure. The total price of the event is the price according to the base price plan plus the price(s) of the event on the supplementary price plan(s).

Override Pricing of Events If required, the prices defined in a rate plan can be overridden (in the same way as price plan product charges can be overridden). Override pricing allows event charges, as defined in the standard price plan, to be edited for an individual customer. The set of events to which the overrides apply can be defined in terms of a combination of rating attributes. For example, a customer could negotiate a lower rate for daytime telephone calls to the U.S. or for all off-peak calls to Italy.


45


External Rating Algorithms To allow all possible rating calculations, a mechanism has been supplied for the Geneva operator to cost an event using a plug-in to the Active Rating Engine. The Geneva operator is responsible for ensuring that the plug-in will be able to rate these events and for the performance of the plug-in. A rate plan can be configured to use the rating cost plug-in. Within this rate p lan, the Geneva operator will not be able to add rating elements or specify a default cost band, banding model, modifier group or default event class. It will still be possible to define internal, external, competitor, and supplementary rate plans that may be a Geneva rate plan or a external (plug-in) rate plan.

Full Pre-Authorization of Charge Geneva allows you to pre-authorize single events such as content download or an m-commerce transaction. These events can be delivered (and authorized) as either complete events or as a stream of partial events. The authorization usually includes a credit check against the account balance considering all previous authorizations. Third parties that are integrated with an operator’s network and rating and billing system can obtain, via the network, authorization for a particular transaction. This is applicable to some types of events (such as the purchase of airline tickets), but not for others (such as WAP access to a local entertainment guide). Third-party systems typically send a message asking for authenticated and authorized spend of a defined amount. Geneva responds with the authorization, providing a unique authorization identifier. A record of the pre-authorized event is held in the database and allocated against the customer’s product and account, influencing their spending limits. A real event will arrive some time later (possibly for a different amount) and Geneva allocates it against the pre-authorized event and adjusts, if necessary, any financial totals. Geneva will also time-out pre-authorized events according to operator-defined configuration. Convergent prepay allows events to be pre-authorized before they are allowed to take place. Full authorization requires that a price is calculated, a credit check performed and, if the event is authorized, some resources are reserved. At some time later the actual event arrives and the charge for the event is taken from the available funds. In Figure 7, steps 1 and 2 show that there may be a delay between these two processes. During this delay, other demands may be made on the account.

46



1. Rate and authorize

2. Rate and commit

Figure 7

Pre-authorization of Charge 1. Authorization request with credit check and pre-allocation 2. Rate and commit billable event later, and free any remaining pre-allocated funds

Geneva Database

Pre-Authorization of Events

Rating Catalog To rate an event, some combination of the event attributes, together with some rating rules, are used to calculate a price for the event. The collection of rules and parameters for how to rate a given event type in a particular currency are defined in a rate plan. A rate plan defines all the rules and parameters for Geneva to be able to determine a price in a particular currency for a single event, such as a pay-per-view event, home shopping selection, etc. (rate plans are used by the Active Rating Engine, which is an optional part of Geneva). Geneva holds rate plans within the rating catalog . Geneva allows many different event types to be defined, and allows many different rate plans to be defined for each event type and held in a single rating catalog. This allows multiple rate plans to be defined for a single event type (for example, telephony) allowing the Geneva operator to define a plan for rates such as telephone calls for business, standard residential, and low user. Rate plans provide the mechanism to determine and record the price of an event. As a single event type may have many different rate plans, the price plan (see "Billing Catalogs," page 67) allows a valid rate plan to be selected for a given product on a given price plan. Date and time periods for which an entry is valid are held against every aspect of the rating catalog. This means that changes such as price, geographic model or time rate diary changes all have a validity period. Many of the records within the rating catalog are historied . This means that the catalog may be edited ahead of time to reflect the price changes that are planned. Geneva will then use the correct pricing rules for the date and time of the event. Geneva allows many different rating catalogs to be defined (one for each pricing currency) and held within a single Geneva database simultaneously. At any one time: y

There may be one live rating catalog per currency and invoicing company combination.

y

There may be any number of design rating catalogs. A design catalog is a collection of Geneva rate plans that are still being constructed. These can be rate plans that are being developed for a future campaign, “what if” analysis, or as fast-track implementations of a future price plan to respond to a competitor’s price plan changes. Multiple design catalogs can be developed simultaneously, with the changes (deltas) all being applied back to a master design catalog (see "Parallel Development," page 152).


47


y

There may be any number of test rating catalogs. A test catalog is a collection of Geneva rate plans that are being tested for completeness, integrity, and correctness.

y

There may be any number of superseded rating catalogs. A superseded catalog is the collection of Geneva rating catalogs that have been live but have now been replaced by a new live catalog.

Rating catalogs are created and maintained using a specialized application called Rating Catalog Maintenance. This provides a graphical user interface to manipulate rate plans. Rating Catalog Maintenance allows multiple rate plans to be in design and test status at the same time. This allows the Geneva operator to consider rate plans well ahead of publication, yet provides the ability to make more minor modifications as required, perhaps on a more regular or reactive basis. Rating Catalog Maintenance implements the Geneva rating catalog life cycle (see "Catalog Life Cycles," page 150). Geneva provides mechanisms for exporting and importing rating catalogs between different instances of a Geneva database. This allows catalogs to be designed, refined, and tested in a test system, and then imported into the live system for publication (see "Rating Catalog Publishing," page 48) to the live catalog.

Rating Catalog Publishing Once a rate plan has been entered, assessed, and tested, it is ready to be published. Rating catalog publishing: y

Checks the candidate rating catalog for completeness, correctness, and integrity against the live catalog.

y

Produces a detailed report of the rating catalog compared with the current live catalog.

y

Registers the new catalog as the live catalog (if it is legitimate to do so).

y

Registers the old catalog as superseded.

The catalog publishing function is available via Rating Catalog Maintenance. If you are using more than one live catalog per currency, the published catalog will be tested against the live catalog that corresponds to the appropriate currency and invoicing company combination.

Event Import Geneva allows any combination of pre-rated and unrated events to be loaded into Geneva for consolidation onto a convergent invoice. Rating input plug-ins provide the mechanism by which events are input into the Active Rating Engine. There are three different mechanisms for importing events via a rating input plug-in: File-based Rating Input Plug-in

48

This plug-in allows the Active Rating Engine to receive events from managed files.



Customized real-time rating input plug-in

This Geneva operator customized plug-in provides a mechanism by which Geneva can be integrated to receive events from any external mediation system in real-time. The published plug-in interface allows the Geneva operator to create their own input plug-ins. For example, a Geneva operator might want to use Oracle Advanced Queuing or MQSeries.

Socket-based Rating Input Plug-in.

This plug-in allows the Active Rating Engine to perform real-time rating by communicating with a suitable mediation system using a specific message protocol over a TCP/IP socket-based interface.

Pre-Rated Event Import Geneva allows both pre-rated and unrated events to be imported into the Geneva database. Pre-rated events could be imported from an existing legacy system, from a third-party service provider such as a mobile operator, or from a specialized third-party event rating engine such as a call detail record (CDR) rating engine.

Rate Plans Geneva allows any number of different rate plan types to be defined. A rate plan type is a classification of rate plans into logical groups. Typically, these groups will relate to different event types. For example, if the Geneva operator is delivering fixed line telephony, mobile telephony, and Internet (by usage), then they might define three distinct rate plan types, one for each type of service. There need not, however, be a one-to-one relationship between service delivery technology and rate plan type. The Geneva operator might subdivide further and have one rate plan type for retail events and another for interconnect events. As outlined in "Rating Catalog," page 47, a combination of the event attributes, together with some rating rules, are used to calculate a price for the event. There are five broad aspects (or dimensions) of event attributes which can b e used to determine a price or rate for an event: y

Geographic or network related. The event may have information relating to the start point and end point geography of the event. This is used widely in telecommunications events, and can include location on a user-definable grid (with distance between the two points automatically calculated, that is, V-H rating [X-Y rating]), a regional segmentation model allowing for concepts such as local calling areas (including multiple independent regional segmentations), or a combination of both. For example, the start and end geographic points of a residential telephone call, the start and end network nodes of an interconnect telephone call record, or the start and end access points to a highway road system.


49


y

Time aspects. Many events have start times and duration attributes, for example, a telephone call, a movie selection, or an Internet connection. A basic weekly timetable can be set up with special case overrides established for particular dates to cover bank holidays, etc.

y

Classes of event, for example, a measure of the quality of service for video conference rate plans and viewing of film premieres/football matches for pay-per-view rate plans. For many events there are different classes of event that are priced differently such as direct-dialed telephone calls versus operator-connected. Access of a data service may retrieve different classes of information, such as copyright information and non-copyright. Event class can be defined in terms of customer/ account/subscription/product attributes as well as event attributes, f or example, a road toll might depend on the type of vehicle (for more information see "Modifiers," page 53).

y

Some measure of the volume or quantity of the event. For d ata services, this might be the number of MB transferred, the number of virtual circuits used, or the number of recipients of a group call. For telephony, the volume is typically the duration of the call. For home shopping, the unit price may come down depending on the number of units purchased. The whole event can be priced using a particular rate that depends upon the total volume or by using different rates as the volume exceeds particular thresholds.

y

Costing rules. Control is provided over the fragmentation of the event if it spans time or volume boundaries. For example, you can fragment in one time period then price and add to the fragment in another period or price the whole event according to the rules that are defined for the start of the event. Control is provided over the scaling and rounding when calculating the price for the event. A number of defaults can be defined so that, where advantageous, the rate plan can be defined in terms of exceptions to the default case.

In addition, pricing can depend on: y

Whether the event is entirely on-net or not. For example, a telephone call or video conference between users on the same network can be priced differently to a telephone call or video conference between users on different networks.

y

Whether or not unit based charging is to be used and the rounding and scaling rules for costs and measurements. For example, prices for events could be rounded up to the nearest cent, rounded down to the nearest tenth of a cent or not rounded at all.

A Geneva rate plan allows rules and parameters to be configured independently for any combination of the above within a single rate plan. This provides great flexibility in terms of the rating rules that can be defined and applied. For each combination of factors, the price can include: y

A charge rate (or unit rate and duration if unit based charging is bein g used).

y

A fixed charge per event.

y

Minimum and maximum charge limits (thresholds).

Loyalty points can be allocated in terms of: y

50

A loyalty point rate.



y

A fixed number of points per event.

Geneva can calculate and apply up to four rates (that is, prices) to a single event, for example, for retail, wholesale, competitor, and internal cost prices. The total spend can then be used to determine whether the customer qualifies for a usage discount (where applicable). It is possible to define whether the output of the Active Rating Engine is to be priced event fragments or priced events. This is configurable at the event type level, for example, retail call detail records are typically output as priced events whereas interconnect call detail records might typically be output as priced event fragments. At product registration time a rate plan should be defined for each event source/event type combination for products for which it is possible to generate more than one type of event. It is still possible to have multiple combinations of event source/event type. Figure 8 illustrates this.

Rate plan A

Event source 1

Multiple event sources

Event type 1 Rate plan B

Event source 2

Multiple event types

Event type 1

Rate plan M

Event type 2

Rate plan N

Event type 1

Rate plan J

Event type 1

Rate plan K

Event type 2

Rate plan L

Event source 1

Event source 1

Multiple event sources and event types Event source 2

Figure 8

Multiple Event Sources/Types

Each rate plan can also have nominated supplementary rate plans. These are secondary rate plans that are applied to the event in addition to the basic rate plan, that is, the components are added together. In addition, each supplementary rate plan can itself have supplementary rate plans, though only the first 35 supplementaries can be reported on. This allows extreme flexibility in rating, for example, by supporting rating on multiple volume scales such as rating a data transfer on connection duration, volume of data transferred, and monetary value of the data.


51


When adding a rate plan to a product it is only possible to add: y

A tax inclusive rate plan if the product is attached to a tax inclusive account.

y

A tax exclusive rate plan if the product is attached to a tax exclusive account.

When defining the price plans for a product, all defined price plans must be either all tax inclusive or all tax exclusive as defined by the tax status of the product’s owning account. If required, the prices defined in a rate plan can be overridden (similar to overriding price plans). Override pricing allows the price charged for events generated by a product to be edited for an individual customer. These overrides can be quite specific, for example, a customer could negotiate a lower rate for daytime telephone calls to the U.S. You do not have to explicitly specify that a rate plan can be overridden (as you do with price plans). Override rating is controlled by a system parameter; either any rate plan can be overridden, or none can.

Geographic Rating Within any single rate plan, Geneva allows any number of cost bands to be defined. These represent different geographic categories such as Local, Long Distance, and International for a residential telephony. Geneva then allows a geographic “A to B” matrix to be defined. Logically, this is a large matrix defining how to recognize points A and B, then which cost band they are in. Geneva allows a default band to be defined, so only the exceptions need be entered. Instead of requiring the cost band for every point to be defined to/from every other point, Geneva allows groupings ( cost groups) to be defined. Thus, a Cost Group Region A might be defined which is comprised of points A1, A2, etc. Similarly for Region B. Then, instead of defining A1 to B1, A1 to B2, etc., Geneva allows Region A to Region B to be defined and vice versa. This can greatly reduce the amount of geographic data that is required for some types of geographic models. For example, New York can be defined as a cost group. Within New York, you can define Manhattan (numbers starting with 214) and Brooklyn (numbers starting with 347). Boston can be another cost group comprising a number of subregions. Then, you can define New York-Boston and Boston-New York if it is different from the default case. In another example, a delivery company can price events in terms of delivery distance. In this case, they can define cost bands of 100 miles or less, 101 through 250 miles, 251 through 500 miles, and 501 miles or more. A model will then require every separately identified town (identified by a unique name or ID, such as a ZIP code) t o be referenced to every other town. In this scenario, some grouping may still be possible but it is not as useful. The default case (such as 251 through 500 miles) still reduces the number of cross-references that would be required.

52



V-H Rating In some countries, calls can be priced according to the calculated distance between the source and destination. In a Cartesian geographic model, also called V-H (vertical-horizontal) model or an X-Y coordinate model, every cost code has two coordinates associated with it. It is possible to use these coordinates to determine the distance between the two points. The distance can be used to assign the call to a particular cost band such as less than 10 miles or 50 to 100 miles.

Time-Based Rating Within a single rate plan, Geneva allows any number of time rates to be defined. These represent a classification of the time of the event (or fragments of the event). For exam ple, you can define Cheap Rate, Business Rate, and Weekend, or Peak Rate and Off-Peak. Any number of time rate diaries can also be defined. A time rate diary is the collection of rules that define how to categorize the event (or event fragment) into the appropriate time rate. The time rate diary defines the start and end points (in terms of day of the week and time of day) that define each time rate. For example, the following three time rates might combine to form one time rate diary: y

Business rate – applies 8:00 A.M. through 8:00 P.M. Monday through Friday.

y

Cheap rate – applies 8:00 P.M. through 8:00 A.M. Monday through Friday.

y

Weekend rate – applies all day Saturday and Sunday.

Any number of time rate diaries can be defined and used within a single rate plan. A different rate plan can be used for different classes of the event. For example, in a telephony billing scenario, you could use one time rate diary called North America for calls to Canada and the U.S. and a different time rate diary for calls to Europe. (In this example, the price varies based on the combination of time rate diary and cost band.)

Modifiers A rate plan modifier is a means of adding flexibility to the costing of events. More specifically, it allows the event class to influence the way in which the event is costed. An event class is a group of events that are subject to the same charging method. Rate plan modifiers are used to select the events that are contained within an event class. Geneva allows any number of event classes to be defined for a rate plan. The types of attributes that can be used as modifier attributes to determine the event class are: y

A single event attribute

y

Multiple event attributes

y

Customer attribute(s)

y

Account attribute(s)

y

Subscription attribute(s)

y

Product attribute(s)


53


y

Parametric quantity of product

Simple relational or comparative modifiers may select events according to the relationship between a modifier attribute and some pre-defined value, or according to the relationship between two modifier attributes. That relationship may be defined by any of the following operators: y

Less than

y

Greater than

y

Equal to

y

Greater than or equal to

y

Less than or equal to

y

Not equal to

y

Starts with less than

y

Starts with greater than

y

Starts with equal to

y

Starts with greater than or equal to

y

Starts with less than or equal to

y

Starts with not equal to

Modifiers can be simple (compare a modifier attribute with a pre-defined value or another modifier attribute) or complex (compare two or more existing simple modifiers, within the same modifier group, using the AND, OR, or NOT, logical operators) and can be assigned priorities. For example, a telephony company might price direct-dialed, operator-connected, and charge phone card events differently. A dispatch company might charge dispatches according to a classification of premium, first, and second class delivery. A data services company might classify their events as copyright and non-copyright. A road toll event might classify the different types of vehicle, etc. A complex modifier would allow, for example, a defined Quality of Service (such as a data download rate) to be offered with the price of the events depending on whether the Quality of Service was achieved. Geneva allows any number of such classifications to be defined. Specifying any number of match conditions for each of the classes that are defined derives event classes. As always in Geneva, there are no limitations on the number of each class and the number of match conditions. All the rules are entered by the user applications and held in data.

Quantity or Volume Rating Geneva allows the quantity or volume of an event to alter the pricing of that event. Within Geneva, any number of pricing breakpoints (known as charge segments) may be defined for specified quantities of the item to be priced.

54



For example: y

A data retrieval event may record the transfer of a quantity of data, measured in megabytes. Geneva would allow, for example, 0-5 MB, 5-10 MB, 10+ MB breakpoints to be defined and for these to then be priced differently. This allows large data transfers to be priced at a different price per MB than smaller transfers.

y

In telephony terms, the quantity is essentially the duration of the telephone call. Ag ain, any number of breakpoints may be defined and the price varied accordingly. This allows you to create price plans such as calls over 30 minutes priced at 50 percent off.

y

In a home shopping scenario, the event may represent a purchase of a product. The quantity can then be used to provide a price per unit purchased structure, so that 50 units are priced at one rate, whereas 51 through 100 are at another, etc. Geneva allows rules to be specified regarding charge segments so that the price can be marginal or non-marginal. For example, in the data access example for an 8 MB download, this can be priced as 5 MB at one rate and 3 MB at the another rate or it can price all 8 MB at the second rate. See "Rating Rules," page 55 for more information.

Rating Rules Geneva allows the Geneva operator to define the rules for scaling, rounding, and fragmentation independently within a given rate plan.

Scaling Units and Rounding Geneva allows the Geneva operator to specify the scaling and ro unding rules that Geneva should apply to charge segments. This allows the following to be defined: y

Rounding rules. These can be round up, round down or round to the nearest .

y

Rounding units. For example, to a single MB, to 5 MB.

For example, if an event type is defined for telepho ny, the charge segments will be related to the duration of the telephone call. In most cases, therefore, this will be a measure of duration of the call measured in seconds, as per second billing is now fairly standard. You can define rounding to the nearest second, or round up or down to the nearest 5 seconds, etc. For a data download, the charge segments may be measured in MB. You can then charge rounding up to the nearest 1 MB, or rounding down in increments of 10 MB, etc.

Price Units and Rounding In terms of charge segments, Geneva allows the Geneva operator to specify the scaling and rounding rules that Geneva should apply to the price. This allows the following to be defined: y

Rounding rules. These can be round up, round down, or round to the nearest .


55


y

Rounding granularity. Geneva carries currencies to a tent h (0.1) of the minor currency. Geneva’s rounding rules allow rounding to a tenth of the minor currency, to the minor currency itself, to every 10 minor currency units, etc. The scaling is applied in conjunction with the rounding rules.

Fragmentation Clearly, an event may span any number of the breakpoints that can be defined, as outlined in "Time-Based Rating," page 53 and "Quantity or Volume Rating," page 54. The simple case for this is illustrated in Figure 9:

Off-peak rate

Peak rate A Charge segment 1

B Charge segment 2

Time

C Charge segment 3

Event Figure 9

Event Time and Charge Segment Fragmentation

The event qualifies to be priced in three charge segments: y

If charge segment fragmentation is set, then the event will be split into three fragments as shown in the figure above and each priced or rated separately and then added together.

y

If charge segment fragmentation is not required, the maximum qualifying segment (in this example, charge segment 3) is used for the whole event.

This gives marginal or non-marginal pricing of charge segments. Marginal and non-marginal pricing is often referred to as tiered and non-tiered pricing in telecommunications applications. Independently, you can fragment on the basis of time. In the example in the figure above, the event spans both peak and off-peak time rates. Geneva allows fragments to be created and priced separately, or if required, for no fragmentation to take place. In this case, the first time rate will be used for the whole event. Geneva allows charge segment and time rate fragmentation to be assigned independently. If both are selected, then for the above example, four fragments will be produced and calculated accordingly. They would be:

56

y

Charge segment 1, Peak rate.

y

Charge segment 2, Peak rate for the portion of segment 2 that lies wholly within the peak rate time period (that is, A to B).

y

Charge segment 2, Off-peak rate for the portion of segment 2 that lies wholly within the off-peak time period (that is, B to C).



y

Charge segment 3, Off-peak rate.

There may be any number of time rates and charge segments crossed by a single event. Geneva allows this and will fragment the event into the required number of distinct fragments, price each fragment separately, and then add them up. The Active Rating Engine can output either priced events or priced event fragments to the COSTEDEVENT table according to the event type configuration. If the output is event fragments, they are sequenced starting from 1. The scaling attribute (such as duration or number of units used) output on each event fragment is the attribute used to calculate the price of the event fragment. Thus, the sum of the scaling attributes of the event fragments equals the scaling factor of the event. For example: Units used

1000

Fragment on charge segments (boundary at 250 units): Frag 1

250 units

Frag 2

750 units

The Billing Engine outputs the event fragment number in the bill data. Unfragmented events do not have an event fragment number.

Unit-Based Charging Geneva supports unit-based charging. This is typically used in older telephony pricing models. A unit is an amount of time that the customer receives for a defined price. The amount of time provided per unit will typically vary with any or all of the other dimensions of the rating model, for example with the time rate, event class, and geography. For example, a legacy telephony pricing model for a unit priced at 5 cents per unit could provide: y

5 minutes of local call time during off-peak time .

y

2 minutes of local time during peak time .

y

2 minutes of national call time during off-peak time .

y

1 minute of national call time during peak time.

Geneva allows such legacy telephony unit-based pricing models to be defined if required.


57


On-Net and Off-Net Geneva allows telephony and data services that are supplied on-net to be priced differently from those that are off-net . On-net typically means that the delivery of th e event was achieved without involving a third-party to help deliver the service, whereas off-net means the opposite. Geneva determines whether an event is on-net or off-net by establishing whether the destination attribute is owned by another account that is resident in the Geneva database. For example, in telephony, a cable company could deliver calls from one cable telephone user to another in the same or interconnected area at a different price to ones made to a non-cable customer. This is typically done as there is a greater margin in on-net calls and some of this may be given to the customer as a price reduction or additional loyalty points. Within Geneva, the on-net and off-net attribute is a logical differentiation of even ts into two groups. It need not be strictly on-net; it might reflect events which involve partner or affiliated companies rather than on-net services in the strict technological sense. Equally, Geneva allows the on-net/off-net distinction to be used to partition the event set into two logically distinct groups relating to destination if required. It can be used to make a binary distinction between two different classes of events in addition to any of the ones above (such as geography or time). For example, a package dispatch company could charge deliveries of parcels to destinations that were also customers at a different rate to destinations that were not direct customers of the dispatch company. The Active Rating Engine and rate plan fully support interconnect rating models. See "Interconnect Accounting Agreement," page 140 for more information.

Determining On-net and Off-net Status When using on-net and off-net functionality, you can match on the event source label or the event source of the related product. Additionally, on-net status can be determined by a partial or an exact match.

Prices Geneva allows any number of rate plans to be defined for a given rate plan type. For example, if the application is telephony, one might have a single rate plan type, but many different price plans such as Residential, Standard Business, and International Business. For each rate plan, for a specified date (that is, they can change over time), Geneva then allows the pricing rules for the event to be defined. Geneva allows:

58

y

The geographic match conditions to be defined (partial or exact match).

y

The default cost band to be defined (the default geographic cost band).

y

The default event class grouping to use.

y

The default event class to assume.



y

Additional rate plans that should be used to calculate the extra optional prices for the event. Geneva allows four prices to be calculated and saved using Geneva rate plan per event. If this is required, then the other rate plans are also recorded in the main rate plan.

Geneva rate plans allow prices to be defined for the default cases and for exceptions to the default cases. For any combination of geography, time, event class, charge segment, on-net or off-net, and for a specified date, Geneva rating allows the following to be specified: y

If unit-based charging is being used, the unit duration can be specified.

y

The charge rate per unit of time, and the unit of time to be used (such as seconds).

y

A fixed charge (such as calls cost 10 cents each plus a duration derived charge).

y

A minimum charge (such as no call costs less than 1 cent).

y

A maximum charge (such as no call costs over 50 cents).

y

A fixed number of loyalty points (if Geneva loyalty points are being used).

y

A variable number of loyalty points to calculate based on the duration.

Duplicate Events Occasionally, unbilled events and partial events may be presented to the Active Rating Engine that are identical to other billed or unbilled events or partial events. This might occur, for example, as a result of the failure of the m ediation system’s filtering mechanism, or a repetition of all or part of an event file being passed to the system for rating. Geneva can optionally detect and remove duplicate events in three ways: y

As they are presented to the system. Incoming events are checked against a database of previously loaded events. Any events that are duplicates of those in the database are discarded as “filtered” and can optionally be archived and deleted.

y

At billing time. If a duplicate event is detected on a bill, the Billing Engine marks the bill as unbillable. Volume processing applications are run for the detection and subsequent removal of duplicate events on unbillable accounts. An audit trail is created for all deleted duplicate events.

y

At any time on rated events. Volume processing applications are run for the detection and subsequent removal of duplicate events on all accounts.

Geneva provides event checking functionality through the Real-time Duplicate Preventer plug-in to the Active Rating Engine, the Duplicate Event Identifier, and the Billing Engine. The Real-time Duplicate Preventer plug-in compares events as they are presented to the Active Rating Engine with events received during a time period configurable by the Geneva operator, for example, an event may be compared with events received in the previous two days. Duplicates are thus prevented from entering the rating process. In cases where events presented to the system are from outside the time window of the Real-time Duplicate Preventer plug-in, duplicates can be identified prior to billing by the Duplicate Event Identifier and removed by the Duplicate Event Remover. This assumes that the Geneva operator is using real-time duplicate prevention.


59


Rejected Events Geneva can reject events for several reasons: y

The event is invalid. For example, the file format of the event file is invalid.

y

The event cannot be guided to an account. For example, if the event source for the event does not exist within the Geneva database.

y

The event cannot be rated. For example, due to an unrecognized area code.

y

The event has been filtered. This is when a duplicate is detected as the event is presented to Geneva (that is, in the early stages of rating).

The first three types of rejected events can be managed using Rejected Event Maintenance. This allows individual events to be edited and test rated. The following functions can be performed on individual and multiple events: y

Resubmit Event. The event(s) will be rated again.

y

Post Event Internal. The event(s) will be rated again. If the event cannot be rated successfully, it is rated against an internal account and, if successfully rated, written to that account.

y

Post Event Uncosted. The event(s) will be rated again. If the event fails, the event will be rated against an internal account. If this fails, the event is written to an internal account as uncosted.

y

Discard. The event will not be rated again and will be written off externally.

Filtered events, discarded events, and rejected events that have been successfully resubmitted can optionally be archived and deleted. A revenue assurance report can provide the detail required to calculate the reject rate (as required by regulatory bodies).

Actions and Thresholds Geneva provides the facility for operators to define actions that will be automatically initiated when, for example, the available credit, unbilled usage or remaining usage for an account reaches a certain level. An action might be a low credit warning and request for payment when the account balance reaches a pre-determined level. Specified actions are initiated automatically in real-time once a threshold is reached. The actions that are available are either internal to Geneva (such as creating a payment request) or performed by an external system (such as sending a user an SMS message).

Message Interface to Rating The Active Rating Engine can be run as a daemon process; a message interface provides events directly from mediation to rating via a configurable socket interface. Messages are passed out in a standard format and will contain the following information: y y

60

A receipt upon receiving an event(s). Once events are written to the database, the rated price(s) of the event(s).



This interface is not a supported interface and is included for reference only.

Carrier-Grade Message Queue Interface Geneva can support a carrier-grade message queue interface as an input to rating. This is via a customized plug-in to Geneva rating. Geneva supports this plug-in option in addition to the two input options that are integral to Geneva; file-based (including a daemon process) and real-time (socket). Geneva supports a mechanism whereby a custom rating plug-in can be developed that integrates with a reliable, real-time, messaging system – no such plug-ins are provided with the product. The only input option that is integral to Geneva (and supported) is the file-based mechanism. Additionally, if custom event preprocessing is required, this can be programmed into the rating input interface.

Caches The performance and scalability of the Active Rating Engine can be improved via the use of shared caches, especially where many rating processes are in use on one rating host. Database-aware, persistent caches store the majority of the data that the Active Rating Engine reads to rate an event. These caches can be populated before rating begins via a new volume processing application, the Cache Loader, which builds and refreshes the in-memory caches used by the Active Rating Engine. The Cache Loader can be scheduled to run in advance of the rating process to ensure the cache is prepopulated. The caches are automatically synchronized with the Geneva database when a change is made to the data stored in the cache (for example, customer, account, product, and event attributes, rate plans). Refreshment of the cache does not interfere with the rating process. If required data does not exist in a cache, the Active Rating Engine retrieves the data from the database and inserts that data into the cache for future use. A new volume processing application, the Cache Manager, manages the activation, deactivation, and statistics relating to the operation of all the caches on a given rating host. Caches are especially effective when multiple Active Rating Engines are running on a single rating host and sharing a single cache, as more information can be cached when multiple rating processes run concurrently. The reduction in memory requirements resulting from multiple Active Rating Engines sharing a cache is considerable. Another advantage of the shared caches approach is the consistency of updates to data across Active Rating Engines, as all the Active Rating Engines on a rating host will have access to the most up-to-date information at the same time. There are seven different cache types that can be utilized by a rating host: y

Event Guiding cache

y

Customer Attribute cache

y

Account Attribute cache

y

Product Attribute cache

y

Discount Scope cache

y

Customer Filter Element cache

y

Domain cache


61


Domains and Domain Routing GEE

This section describes features which are only available if you have a Geneva Enterprise Edition license.

Domains are logical groups of accounts, and thereby event sources, that share a common rating architecture. Geneva processes each domain on a designated rating host. The primary advantage of domaining is scalability. By breaking the account base into multiple pieces the workload can be optimally distributed across hardware resource. Caches are needed to efficiently implement domaining. It is necessary to divide event data into multiple streams in order to: y

y

Reduce the amount of account data that needs to be stored in the cache for each Active Rating Engine to a subset of data corresponding to the rating host’s domain(s). Ensure that the information in a distributed rating environment is only cached in one place.

See Appendix A, "Distributed Revenue Processing," for more information.

Prioritization of Rating Jobs The Geneva operator can prioritize streams of processes so that higher priority jobs take precedence over those with a lower priority. This is particularly important in the area of real-time event processing. Real-time event processing reduces the amount of revenue tied up in unrated events and provides the customer with an up to the minute view of their event spend.

Tax Overrides on Events Geneva, in its core tax functionality, allows taxes to be applied to events according to their event type. Some Geneva operators operate in markets which, in various tax jurisdictions, require taxes to be applied according to criteria outside the scope of Geneva. There are situations where it is necessary to apply different taxes to events of the same event type. For example: y

Electricity suppliers must charge different tax depending on the level of usage – the de minimus rule.

y

Premium rate calls are taxed at a higher rate than standard calls.

y

Roamed international calls are exempt from tax.

Tax overrides are marked on an event prior to rating and determine the taxes to be applied to the event at bill time, overriding any taxes that the Billing Engine would otherwise apply.

62



Tax on Prepaid Events Geneva supports the configuration of tax inclusive as well as tax exclusive rating and price plans. With the potential for the use of multiple services in the prepay environment, it is necessary for the tax to be calculated at the time of use as the rate applicable may not be known until that time. A different tax or taxes may be applicable for each usage event. Rating and price plans defined with taxes already included can be useful in this scenario to show the user the true cost (price plus tax) of items or services selected by the user. Tax inclusive pricing is not supported if you are running a U.S. tax model.

Unloading of Costed Events There are several reasons why users of Geneva may want to undo the rating or loading of some events. For example, there may be an error in the price plan or events may have been loaded against the wrong account. Geneva allows users to unload events. All event unloading functionality is available as volume processes via System Monitor. Events may be selected for unloading according to user-defined categories or parameters, for example, by date and time range, event source, or account. Once the events have been extracted, the user can then decide to rerate those events or cancel the job altogether. An audit trail is generated to track the removal of events from the system.

Test Event Facility Geneva provides a test event facility in Rating Catalog Maintenance which allows the Geneva operator to check the charge for a call without real events being rated. This is very useful for testing new price plans or for checking discrepancies and investigating customer disputes as it allows the Geneva operator to test rate a call without billing. When values for the attributes of an event type are provided, the Active Rating Engine will rate this as an event according to the applicable price plan, providing details of the fragmentation used and the calculation of the event price, that is, it will output the call rate together with details of how the call rate was arrived at. The resulting costed event is not used for billing purposes.

Rerating Requests A product instance’s account number can be changed retrospectively. It cannot be changed for a time period for which a bill has been issued. However, if the account number of the product is changed retrospectively (for the current system date or previously), a rerating request will be generated. Rerating requests are not processed automatically. If a product has no associated events, no rerating request will be generated.


63


Rerating requests can be viewed and marked as processed in System Monitor. Additionally, rerating requests can be filtered by account number, rerating request status, and time period for which the request is active.

Rating Partial Events Modern real-time convergent mediation devices can provide a stream of partial event detail records that describe an event while it is in progress, rather than after the fact. These partial events can be either aggregated by the mediation device prior to delivery or aggregated within the rating and billing system. If partial events are aggregated within the rating and billing system, the customer’s balance can be maintained during events that occur across multiple services. Partial events are required to ensure an accurate, evolving picture is maintained for long duration events. This allows operators to monitor whether a customer is remaining within their account balance or credit limit during such events. Examples of long duration events are: y

GPRS or 3G mobile. A connection may be open for many hours during which time various downloads may take place. Pricing may be based on some combination of duration and data volume downloaded.

y

Internet download. These events may last several hours, so waiting for the end of the event before pricing involves the risk that a customer may have far exceeded their credit limit or prepay balance.

y

Gaming sessions. Incremental micro-payment expenditure during the course of a game (such as the purchase of more lives) results in a single final total billable amount for the game.

y

Remote access server connection. Connection to a remote network could produce partial events every six minutes.

The Geneva operator is able to specify that a particular event type can support partial events in addition to complete events. For example, a pay-per-view sports event may be classed as a complete event, and a data download classed as being made up of partial events. For events supporting partial event types, the type of partial event that is expected is specified either as delta or aggregate. Aggregate events describe everything that has happened since the initiation of the event and so give an aggregated or cumulative view of events so far.

1 2 3 Figure 10 Aggregate Events

64



Delta events describe the changes which have occurred since the last partial event. Hence a delta event is the difference between the last event and the current situation.

1

2

Figure 11

3

4

5

6

Delta Events

Multiple Event Types You can associate more than one event type with a single product within Geneva. Events produced by such a product will be rated using a different rate plan depending on their event type. For example, a single GPRS device might produce both mobile telephony and data download events. Each of these events would have a different event type and would be rated using a different rate plan (for example, voice based on seconds duration, or download based on MB).

Redirecting Events Events may be redesignated to another account by the Geneva oper ator based on a set of account-specific rules. These rules are defined in terms of the event attributes. For example, a customer has a handset that is registered with their employer, but they are also able to use the same handset for personal use. Whether the employer or the employee gets charged depends on the time of day of the usage or whether the user dials a special code. Usage is rated based on the originating account’s price plan or on another price plan that is defined as part of the guiding rule. In addition, you can output the name and number of the originating account and the originating event source number on the bill. When an event has been rated against the price plan of the originating event source, it can only redesignate that event to an account that has the same tax inclusive or exclusive status (that is, an event rated on a tax inclusive price plan must be redesignated to a tax inclusive account and vice versa).

Convergent Billing At the heart of Geneva is a truly convergent billing engine. The billing process gathers together all information relating to an account (or a collection of related accounts which are part of a customer hierarchy); the products, price plans, discounts, packages, bonus schemes, and rated events (the measured usage of each product), and calculates the charges due. The billing process also calculates and apportions tax, and assigns charges to the relevant revenue codes for use by the accounting system.


65


Geneva is a truly convergent system; any number and combination of products and services can be consolidated onto a single bill, regardless of the type of product and market segment. In addition, Geneva can produce a single statement for both prepay and postpay services. The postpay charges can be summarized on an invoice while the prepay usage can be summarized in a statement of usage and payment top-ups. Geneva supports residential, small-medium enterprise (SME), and corporate billing environments. It has been designed to operate efficiently on any mix of residential, SME, and corporate accounts. It is also able to undertake wholesale billing – the invoicing of a few customers and accounts that potentially have considerable numbers of products and very high numbers of events. A residential customer can take any number of products and services, regardless of their location. The customer can then choose to have these services billed together or on different accounts. In either case, package discounts r ewarding their loyalty can still be given. In the SME and corporate billing environments, Geneva allows both the structure of the organization and its billing requirements to be modeled. Any depth and breadth of hierarchy can be defined with invoices produced at any point. Usage based discounts can be based on the spend of individual products, packages, accounts or even the spend of the entire corporate hierarchy. The resulting discounts can then be credited to the earning account or sent to another account in the hierarchy. Figure 12 illustrates this.

Head Office account

Head Office Account A

usage discount

Account B usage discount

Regional Office 1

Budget Center 1

Regional Office 2

Budget Center 2

Budget Center 3

Budget Center 4

Figure 12 Customer Hierarchy Billing

66



Billing Catalogs As with rating, Geneva stores all data and rules pertaining to the billing process in a special area of the Geneva database called the billing catalog . A billing catalog is a collection of packages, price plans, and discounts for a particular currency, that is, everything to do with products, pricing, and how the items will be billed in that currency. The Geneva operator may limit the availability of product/price plan combinations to certain groups of customers. Customers may be allocated ma rket segments based on, for example, business roles or geographical differences. The products and price plans available to the customer can be limited based on the market segment of the customer. Each item in the billing catalog has a start and end date so that it can be introduced and withdrawn from the market on specific dates. Date and times are held against every aspect of the billing catalog to specify the period for which the entry is valid. Therefore, product availability changes, price plans, discounts, and packages, etc. all have a validity period. The records within the billing catalog are all historied – the catalog may be edited ahead of time to reflect the price changes that are planned. Geneva will then use the correct product pricing rules for a particular date and time. This also means that superseded elements of the catalog are preserved should there be any need to have recourse to historical prices or if, as in the case of services rated using meter readings (electricity, water, and gas), rating may take place at a later date than the occurrence of the events themselves. Billing catalogs exist for each pricing currency in an installation of Geneva. Multiple catalogs for the same currency may also be managed in a single Geneva installation. Each catalog holds the charging information to be applied to accounts that use that currency. These catalogs exist independently of each other. However, a catalog in one currency can be copied into another currency if required. Cross-currency price plans are thus extremely flexible. See "Multiple Currencies," page 91 for details of how Geneva handles currencies. Geneva allows many different billing catalogs to be defined and held within a single Geneva database at one time. The billing catalog is able to handle very large catalogs, for example, a catalog can contain 100,000 price plans, 100,00 packages, and millions of prices. At any one time: y

There may be one live billing catalog for each currency and invoicing company combination. Each currency may also have one live billing catalog that is not associated with an invoicing company.

y

There may be any number of design billing catalogs. A design catalog is a collection of Geneva price plans and packages that are still being constructed. For example, these may be billing catalogs that are being developed for a future campaign, “what if” analysis, and as fast-track implementations of a future price plan to respond to a competitor’s price plan and product changes. Multiple design catalogs can be developed simultaneously, with the changes (deltas) all being applied back to a master design catalog (see "Parallel Development," page 152).

y

There may be any number of test billing catalogs. A test catalog is a collection of Geneva price plans that are being tested for completeness, integrity, and correctness.

y

There may be any number of superseded billing catalogs. A superseded catalog is the collection of Geneva billing catalogs that have been live, but have now been replaced by a new live catalog.


67


Billing catalogs are created and maintained using a specialized user application called Billing Catalog Maintenance. This provides a graphical user interface to manipulate billing catalogs. Billing Catalog Maintenance allows multiple catalogs to be in design and test status at the same time. This allows the Geneva operator to consider price plan and package changes well ahead of publication, yet provides the ability to make more minor modifications as required, perhaps on a more regular or reactive basis. Billing Catalog Maintenance implements the Geneva billing catalog life cycle (see "Catalog Life Cycles," page 150 for more information). Geneva provides mechanisms for exporting and importing billing catalogs between different instances of a Geneva database. This allows catalogs to be designed, refined, and tested in a test system, and then imported into the live system for publication (see "Billing Catalog Publishing," page 68) to the live catalog.

Billing Catalog Publishing Once a billing catalog’s data has been entered, assessed, and tested, it is fit to be published . Billing catalog publishing: y

Checks the candidate billing catalog for completeness, correctness, and integrity against the current live catalog.

y

Produces a detailed report of the billing catalog compared with the current live catalog.

y

Registers the new catalog as the live catalog (if it is legitimate to do so).

y

Registers the old catalog as superseded.

The catalog publishing function is available from Billing Catalog Maintenance and Rating Catalog Maintenance. If you are using more than one live catalog per currency, the published catalog will be tested against the live catalog that corresponds to the appropriate currency and invoicing company combination.

Prices A price plan defines the prices in a particular currency for one or more products from a single product family. When defining a price plan, th e user must specify whether it is tax inclusive or not. Tax inclusive accounts are only able to take products on tax inclusive price plans and vice versa. The following types of prices can be specified:

68

y

The initiation charge, such as an installation charge.

y

The periodic charge, such as a line rental charge. This may be billed in advance or in arrears. If it is billed in advance, it may be defined as being refundable so that it is refunded for part periods if the customer cancels part way through a prepay period. In addition, the product charge can be prorated which means that for a part period (such as the part of a month when you start or end the service), the cost will be calculated proportionately. Periodic charges for additional products, subscription for which commences mid billing period, are synchronized with the cycle of the account using the prorating mechanism.



y

The final charge which may be, for example, an equipment removal charge or a penalty for terminating the agreement.

y

The suspension charge which may be, for example, a charge to keep services active while they are suspended or a charge to reactivate the service after suspension. If multiple charges of any type (initiation, periodic, or final) are required for a single product, this can be set up in Geneva by defining the requisite number of child products with the associated charges defined or a parametric product. Geneva can track the changes to product charges and prorate them if a price plan’s details change during a bill period. This behavior is configurable for each individual price plan.

For parametric products, different prices can be defined for different quantities of the product so that, for example, if the customer purchases eight they are charged price A per unit, if they purchase 80 they are charged price B per unit, etc. These prices can be specified relative to each other, for example, the price per unit for 50 through 100 being 10 percent less than that for 1 through 49 units. In addition, the prices can be marginal or non-marginal : y

A marginal price is one that is applied only to the number of products that exceed the threshold. Using the example above, if 80 were purchased, 49 would be at price A and the remaining 31 would be at the reduced price.

y

A non-marginal price is one that is applied to all the products when the threshold has been exceeded. In the example, this would mean that all 80 were at t he reduced price.

In the telecommunications industry, such pricing is often referred to as tiered and non-tiered . A price can also be defined for a zeroth instance of a product to support pricing structures such as $1000 + $50 per item. The Geneva price plan system is hierarchical and may extend to any depth. The Geneva price plan is genuinely inheriting – only the differences (deltas) are saved in the Geneva database and Geneva derives the prices required at bill time. This reduces the amount of price plan maintenance dramatically and allows derivative, variant price plans to be created and maintained with the minimum of overhead. Figure 13 shows, from left to right, an example of a possible hierarchy for a standard telephony service and standard cable service.


69


Business Electricity Supply

Standard Electricity Supply

High Use Residential Electricity Supply

Low Use Business Gas Supply

Standard Gas Supply

Residential Gas Supply

Figure 13 Example Price Plan Hierarchy

A Geneva price plan may be derived from another price plan in the hierarchy. A price plan may be: y

A root price plan which defines the basic prices for all the products within a family. There must be one (although there may be many) root price plans for a product family. The product prices must be defined as absolute values. Typically these are the list prices for the products on offer.

y

A child price plan – if a different but related set of prices are required for a product family, you do not need to enter them all again; you can create a child price plan instead. This, by default, has the same prices as the price plan from which it is derived (its parent price plan), that is, it inherits its prices from its parent. You only need to enter explicitly any prices that are different on the child price plan.

Prices for the child price plans may be:

70

y

Set explicitly.

y

Inherited from a parent price plan.

y

Inherited from its parent with a percentage modifier (for example, +10 percent or -20 percent).

y

Inherited from its parent with a relative modifier (for example, +$3.00 or -$1.00).

y

Defined as a null charge (will not appear on the bill, whereas 0.00 will appear as a zero priced item).

y

Not set – the product will not be available for sale.



Figure 14 shows an example child price plan for three non-parametric products. The Line Rental product has two related, subsidiary products called Call Waiting and Call Barring:

Residential POTS

Line Rental Installation -5% (19.75) Rental -5% (10.24) Termination (15.62)

Call Waiting Installation Rental Termination

+1.00 +1.00

Call Barring (6.00) (4.00) 0.00

Installation Rental Termination

-2.50 -1.00

(2.50) (0.50) 0.00

Figure 14 Example Child Price Plan

For each product, the first column of figures specifies the prices entered for the child price plan, in this example the prices are to be inherited with either a percentage modifier (such as -5 percent) or a relative modifier (such as +1.00). The second column of figures gives the resulting prices for the child price plan calculated from the root price plan prices. For example, the Call Waiting product when priced according to the root price plan has an installation price of 5.00, thus the child price plan price for Call Waiting, given the relative modifier of +1.00, is 6.00. A key point to remember is that Geneva saves only the deltas for such relative price modifiers; it does not create copies. This means that maintenance of the price plans is reduced considerably, as a change at the top of the price plan hierarchy will be inherited by lower price plans and modified as instructed. Depending on the business requirements, any number of child price plans can be created below a root price plan. Each of these child price plans can then be a parent to any number of subsequent child price plans. The shape of the resulting hierarchy is specified by two attributes: y

Depth – the number of price plan levels.

y

Width – the number of price plans at each level.

This will be a compromise between: y

Minimizing the duplication of price plan information (a deep and narrow hierarchy).

y

Minimizing the complexity of the price plan structure (a shallow and wide hierarchy).

There are no limits on the size (depth and width) of the price plan hierarchy. The lowest level child price plans may be so specific that they define product prices for a single customer, for example, if a large corporate customer has negotiated a special price plan by virtue of buying in bulk. In practice, it is unlikely that you will need more than four or five levels.


71


For products that are event generating (for example, telephone calls are events that relate to a telephone line, pay-per-view movie selections r elate to a set-top box, data downloads relate to a data service of some sort, etc.), Geneva records the Geneva rate plan(s) that should be used to rate the events for that product within the price plan. For more information on rate plans see "Rate Plans," page 49. The pricing for a product within a price plan refers to all aspects of how that product is priced: its initiation charge, periodic charge and period, termination charge, the loyalty points and the discounting that is to apply. There may be any number of discounts (see "Discounts," page 73) registered against a single event product within a price plan. For a parametric product, there may be a different pricing for each quantity breakpoint that is defined, including different discounts at those quantity breakpoints. Figure 15 illustrates this.

Centrex product (Standard price plan)

Zeroth unit

1-19 lines

20-49 lines

Initiation charge: $10,000 Periodic charge: $1,000 Final charge: $0

Initiation charge: $5 Periodic charge: $10 Final charge: $0

Initiation charge: -10% ($4.50) Periodic charge: -10% ($9.00) Final charge: $0

No event discounts

No event discounts

10% off long distance calls

50+ lines Initiation charge: -0.50 ($4.00) Periodic charge: -1.50 ($7.50) Final charge: $0 15% off long distance calls 10% off international calls

Figure 15 Parametric Price Breakpoints

Price plans can be defined as supporting override pricing . Price plans that allow override pricing allow the price charged for products to be edited when a customer takes the product. This supports situations where customers can negotiate preferential charges/ prices. Any element of the price (initiation, periodic, suspension, or final charge) can be overridden. For each product price (as defined in the billing catalog), the Geneva operator can define whether the standard prices may be overridden at product registration time. If so, they can define the limits of such overrides. These may be relative percentages, relative monetary amounts or absolute monetary amounts. When adding a price plan to a product, it is only possible to add a: y

Tax inclusive price plan if the product is attached to a tax inclusive account.

y

Tax exclusive price plan if the product is attached to a tax exclusive account.

Price plans can also be defined as supporting contracts Contracts allow products to be offered on a special price plan for a contracted period, usually to give the customer a discount for agreeing to take a product for a particular length of time. Once the period ends, the contract can be extended or allowed to lapse (in which case the product reverts to the standard price plan). Contracts can be either: .

y

72

Fixed – the price is fixed at the start of the period.



y

Variable – the contract price fluctuates in line with any changes to the standard price

plan. Contracts can also include penalty charges for terminating the contract early (which may be obtained from an external system via breakout if required). The charges include both fixed and multiplied penalty components. The fixed component is a flat amount charged for termination of a contract. The multiplied component is a fixed charge multiplied by the number of periods remaining on the contract at the termination point. Geneva makes it possible to (optionally) prorate the multiplied component of early termination surcharges. In addition, the price plan includes details of the loyalty points associated with the product. The root price plan may simply be a set of prices that a Geneva operator wishes to have as list prices. However, it can instead be specified to be a set of competitor’s prices, creating child price plans that inherit and modify those prices in order to keep them relatively priced. Another alternative is to set a root price plan to contain cost prices and then create child price plans that inherit and modify those prices to give the margin required.

Discounts All discounts alter (most commonly to reduce) the price to be paid for a set of products or events on a particular bill. Discounts are defined for each price plan and are assigned to products. Discounts can apply to: y

All charges generated by a product.

y

Event charges only (a charge discount ).

y

Product charges only (a product discount ).

Charge discounts can be attached to a particular product if one of the following is true: y y

The product itself generates events. An ancestor of the product generates events.

If a pricing structure is required in which the prices change with volume , then there are two basic approaches that can be adopted: y

Base prices can be set for individual events and then the events can be aggregated and discounts applied at particular threshold levels.

y

The events can be priced in aggregation using thresholds.

Events from more than one event source, or p roducts from more than one account, can be combined when: y y

Calculating the level of discount to be applied. Applying the calculated discount.

The usage can be accumulated over: y

Products (event contributions only).

y

Packages.


73


y y

Accounts. Customers (but not if the discount is to be performed during rating).

For example, an account level discount can be set up so that the calls made from all the telephone lines taken on an account will be added together when determining the level of the event discount but where the discount is applied only to the events generated by the product with the discount attached. In addition, products and events of more than one type can be combined when: y y

Calculating the level of discount to be applied. Applying the calculated discount.

Thus the following discounts are possible: y

Five percent off all fixed and mobile telephony calls if the total Internet spend exceeds $10.

y

20 percent off all events in March if the total telephony spend (including line rentals) during that month exceeds $20. This works regardless of the currencies of the accounts. When accumulating over accounts with different currencies, the total contribution for each account is converted to the currency of the discount and these contributions are summed. Similarly, any resulting discount is then applied to the appropriate accounts, converting any monetary amounts using the exchange rate in effect at the nominal bill date.

Discount Applications In Geneva, events can be discounted either during the rating process or the billing process: y

Discounts that apply to a single event and can be determined by the attributes of an event in isolation can be performed during the rating process by the Active Rating Engine. These are referred to as rating time discounts . Only one type of rating time discount exists, the rating discount .

y

Discounts that are determined by performing calculations for a set of events can be applied at billing time by the Billing Engine. These are referred to as billing time discounts. They can be: o

Pre-itemization discounts – carried out at bill time, before itemization. They modify

the price of each event to which they apply to determine a rerated price. o

Post-itemization discounts – carried out at bill time, after itemization. They leave

the event prices unmodified. o

Banded discounts – carried out at bill time, after itemization. They leave the event

prices unmodified. o

Tax discounts – carried out at bill time, after itemization.

o Aggregate pricing discounts – carried out at bill time, after itemization.

74



Filters Discounts may optionally use a filter to select a subset of events for the product, package, account, and customer account hierarchy. A filter is a powerful, data-driven mechanism for selecting a subset of events, in a particular billing period, to which a discount is applied. For example (for telephony events), filters can be used to select: y

All local calls.

y

All international calls.

y

All calls to a specified city.

y

All calls which take place on a particular day.

y

All calls within a specified customer hierarchy.

y

All calls to a defined set of numbers (where the set of numbers is defined f or each account individually).

There are five different types of filters: y

Global filters apply across all accounts in the same way. These require a series of

match conditions for the product attribute or event attribute. For example, if the attribute being used is the event date, the following types of match conditions could be set: o

On February 20, 2001

o

On or after January 1, 2001

Alternatively, if the attribute is the product age, the match conditions might be: o y

All products older than 12 months.

Account Specific filters differ from account to account. The values that make up the

filter definition need to be defined for each account. You should specify the maximum number of filter values to be allowed in Max Values. The actual values used for each account will be defined when a product generating appropriate events is added to an account. For example, a discount that allows a customer to pick five telephone numbers to attract discounts would be account specific and the matching telephone numbers would be set up with Customer Account Maintenance for each account. However, the numbers do not have to be specified exactly – a starts with operator exists to allow ranges of numbers (or other values) to be se lected. This could be used, for example, to allow calls to business partners with blocks of telephone lines to be discounted easily. y

Highest Usage filters are applied at bill time by grouping events by the chosen

attribute (such as dialed number) and then selecting the highest n groups by expenditure. The maximum number of filter values allowed is defined as part of the filter. This could be used to set up a dynamic discount on a customer’s favorite telephone numbers; the filter would pick up the destination numbers that the user had spent the most money calling and apply the discount to them. You should specify the maximum number of filter values in Max Values. y

Composite AND filters combine a number of previously defined filters. They select the

calls that fall in the intersection of a set of chosen filters. y

Composite OR filters combine a number of previously defined filters. They select the

calls that fall into any of the set of chosen filters.


75


Composite filters can contain other composite filters. Thus they can be used to build up very specific filters if required. For example, they can be used to define sets of events composed of different event types. For video conferencing events, filters may be used to select events based on the quality of service, for example: y

All video conferences which fail to achieve an average bandwidth of 256 KB/s.

For ADSL circuit products, filters may be used to select, for example: y

All circuits of 1000 units or larger.

y

All circuits with periodic charges of $125.00 or more.

y

All circuits on an annual contract.

When defining a discount, it is possible for the user to define two filters associated with the discount: y

The filter used to choose the set of products or events that are used for calculating the level of discount to be applied (the assessment set, used for thresholding).

y

The filter used to choose the set of products or events which will actually be discounted (the discounted set).

For example, by using different filters the following discounts can be set up: y

10 percent off gas bills if electricity usage exceeds $20.

y

Fifteen percent off mobile voice calls if more than 100 MB of data is transferred via GPRS in a given month.

y

10 percent off national calls if international call spend exceeds $20.

Discount Sets Discounts can be specified to be single set or double set : y

A single set discount is a simple discount where the discounting set is the same as the assessment set. Typical examples are “10 percent off if you spend over $20” or “$10 of calls free each month.”

y

A double set discount is a more sophisticated discount where the discounting set is not the same as the assessment set. Typical examples are “10 percent off fixed-line calls if more than $20 spent on mobile calls,” “10 percent off international calls if more than two hours spent on Internet access,” or “10 percent off ADSL circuits if more than 10 phone lines taken.”

Discount Options Discounts can be specified to be marginal or non-marginal : y

76

A marginal discount is one which is applied only to the portion of the set of products or events that exceed the threshold. For example, the first 100 KB of a data download at normal rate and then 10 percent off the price of the remainder of all data downloads.



y

A non-marginal discount is one which is applied to the whole set of products or events after the threshold has been reached/exceeded. For example, 10 percent off the price of all pay-per-view events when two premium channels are taken.

In the telecommunications industry, such discounts are often referred t o as tiered and non-tiered . For example: y

The first 100 minutes at normal rate and then 10 percent off the price of the remainder of the calls is a marginal discount.

y

10 percent off the price of the whole set of calls when their total duration is longer than 100 minutes is a non-marginal discount.

Discount Steps and Thresholds Once the subset of events that qualify to be used for assessing the discount has been determined (using filters), the size of the discount needs to be defined. This is done by defining a number of discount steps and thresholds. Discount steps allow the size of the discount to be changed when particular thresholds are reached. For example, the discount for telephony events could depend upon the total number of minutes spent calling with 10 percent off after 100 minutes and 20 percent off after 200 minutes. Any number of steps can be defined and a wide range of product or event attributes can be used in specifying the threshold values (including all the user-defined event attributes and the first six user-defined product attributes). The size of the discount can be given as either a percentage or an absolute amount. Each discount has a discount period associated with it. This is the length of time for which the “numbers” associated with a discount are meant to apply. The discount period affects: y

The length of time over which a threshold value is meant to be exceeded.

y

The frequency with which an absolute discount is meant to be applied.

For example, if the bill period is three months and the discount period is one month then each bill covers three discount periods. Thus if the discount offers 10 minutes of calls free, this 10 minutes will be awarded (non-transferably) each month giving a maximum of 30 minutes of free calls in the bill period. By combining discount filters and discount steps, a Geneva operator can define event discounts. For example: y

First five minutes of call time to Australia free, then the call is charged at the normal price.

y

$2 off all long distance calls if the total cost exceeds $50.

y

10 percent off the first 100 minutes, 20 percent off the second 100 minutes, 30 percent off the third 100 minutes for calls to a defined set of numbers.

y

50 percent off the first ten video conferences that miss the 256 KB/s target quality of service level, all subsequent video conferences missing the 256 KB/s target quality of service level will be free.


77


y

y

First 100 MB of data transferred free, next 100 MB of data transferred at the normal price, remainder at 50 percent discount. All shopping purchases costing over $60 get free postage and packaging.

Proratable Discount Thresholds It is possible to specify the period of a discount to be any multiple of days, weeks or months through Billing Catalog Maintenance and to mark a discount as having proratable thresholds. If a discount has proratable thresholds and the customer is eligible for the discount for a part period, the thresholds will be prorated. For example, if a customer has signed up for the “15 minutes free” price plan halfway through the month, they would receive 7.5 minutes free. In addition, an account does not have to receive the discounts that it has earned itself – they can be passed on to any selected account. Thus for a company customer hierarchy, all of the branches could pass on their discounts to a single account at the head office or any single office. Alternatively, discounts can be shared between two different accounts; the recipient account and its parent account. This may be useful if, for example, a business landlord wishes to pass one discount on to their tenants, but retain another for themselves. Different event types can be mixed when determining the usage towards a discount. Thus, the following discounts are possible: y

Five percent off all fixed and mobile telephony calls if the total spend exceeds $10.

y

20 percent off all events in March if the total spend during that month exceeds $10.

Parametric Discount Thresholds Discounts can be structured with parametric thresholds. For example, a company can sell products with a bundled discount (ten minutes of free talk time per handset) where the talk-time goes across handsets. Thus if a customer buys four handsets, they receive 40 minutes of free talk time to share between the handsets. In this case, the user could define a discount with the following structure: y

Up to ten minutes – 100 percent discount.

y

Over ten minutes – zero percent discount.

y

Marginal.

y

Parametric thresholds.

y

Product aggregation level.

This discount is then attached to the price plan for the handset parametric product for any quantity over one.

78



Volume Product Discounting In many business billing scenarios, products are charged on the basis of subscription only with no usage element, such as leased lines or ADSL circuits. Geneva’s discounting capabilities provide flexible discounting functionality driven by product contributions. Geneva operators are able to reward customer loyalty by offering volume discounts on product subscription charges. The qualification criteria can be defined in terms of a volume threshold. This volume can be: y

Volume or number of a product (by cost).

y

Monetary value of charges.

y

Product age in months.

y

Product attribute (such as bandwidth or ZIP code).

It is also possible to define the contributing charge using any combination of: y

Charge type (such as initiation or periodic).

y

Charges relating to a particular product or group of products.

Charges can be aggregated at the customer, package, account, or product level. The discount takes the form of a percentage or a fixed amount.

Rating Discounts Discounts that only assess on event charges can be applied when the event is rated, rather than when the bill is generated. Rating discounts support real-time discounting, allowing customers quick feedback on the discounted cost of events. Feedback to customers can include: y

The net cost of an event (including discounts) on request.

y

The amount of free usage remaining in the current discount period.

y

Whether the customer might be better off moving to a rate plan with a different discounting structure.

The range of discounts that can be applied at rating are: y

Free usage discounts such as 30 minutes of free mobile call time per month.

y

Discounted usage discounts such as 10 percent off the first 20 MB of traffic each week.

y

Flat rate percentage discounts such as 15 percent off all international calls.

y

Flat rate discounts such as one cent off every MB of download.

A maximum discount amount can also be applied, for example, 10 cents off every call up to a maximum of $20.


79


Geneva gives you the flexibility to configure the following rating discount features: y

Free usage and discounted usage discounts can be configured to carry over free/ discounted usage into the next discount period (subject to a configurable maximum amount). Whether late events can be included or not is configurable by the Geneva operator.

y

Where more than one rating discount is applied to a product, the order in which the discounts apply can be specified.

y

A key requirement for prepay and postpay accounts is the ability to share usage bundles across both types of accounts, allowing a single usage bundle to be shared across a whole family or business. Additionally, these whole family discounts are likely to reduce customer churn. With regard to flat amount discounts, Geneva supports a safety net for the Geneva operator to ensure that customers cannot be discounted to the extent that it becomes a credit to the user, that is, it will not be possible to discount an event such that it becomes a negative charge.

In addition to discounts applied at account and product level, discounts may also be applied at customer or package level.

Post-Itemization Discounts Post-itemization discounts can be attached to a product, package of products, an account, a customer, a customer subhierarchy or even a whole customer account hierarchy under a particular price plan provided that the product itself generates events, or an ancestor of the product generates events. Post-itemization discounts cannot be marginal. If the product itself does not generate events, then a ny discounts that are defined for it will be applied to the events generated by its parent. If the parent does not generate events, then the discounts will pass to its parent, etc. For example, consider the product hierarchy shown in Figure 16.

Line Rental (Generates telephone call events)

Voice Mail (Generates voice mail events)

Premier Voice Mail

Call Barring

Call Barring Plus

Figure 16 Example: Product Hierarchy with Transfer of Discounts

80



In the hierarchy shown in Figure 16, the following could (for example) apply: y

All products can have discounts applied to them because all are either event generators or have ancestors who are event generators.

y

Events generated by the line rental product will be subject to the discounts on the line rental, call barring and call barring plus products (depending on the aggrega tion level).

y

Events generated by the voice mail product will be subject to the discounts on the voice mail and premier voice mail products (depending on the aggregation level).

Banded Discounts Banded discounts are billing time discounts and are therefore calculated by the Billing Engine. They are a hybrid of marginal and non-marginal discounts, with some differences from each. Unlike marginal discounts, they are not calculated on a per event basis. Unlike non-marginal discounts, instead of only applying the discount of the highest step reached to the total cost, each step’s percentage discount is applied in proportion to that step’s share of the overall cost. As banded discount calculat ion is performed using proportions of cost (the discount per account is the ratio of the cost of events from that account to the total event cost over all accounts, multiplied by the total discount earned by all accounts), the order in which events occur or are processed by Geneva is not relevant. Although it is possible for a banded discount to be given to a single account nominated by the customer, the default behavior of a banded discount is to apportion the discount amount to all relevant accounts based on the contribution of each account to the total discount amount. Any changes in bill periods result in suitable proration of the banded discount’s thresholds. Banded discounts are considered to be a discount application even though they are a specific type of post-itemization discount.

Tax Discounts Tax discounts provide the option of setting up tax amounts as a discount in Geneva. Tax discounts are set up and calculated as normal discounts. They differ from other discounts in that: y

The discount generated is treated as a tax amount. Other taxes are not applied to it, and it is counted under a tax revenue code.

y

Details of the tax discount are output as part of the bill data.

Discount Summary Discounts are a complex area involving discount applications, types, options, and aggregation levels. This section describes the availability of these discounts. Discount applications can be: y

Rating.

y

Pre-itemization.

y

Post-itemization.


81


y y y

Tax. Aggregate pricing. Banded.

Discount types can be: y

Single set.

y

Double set.

y

Bonus scheme.

Discount options can be: y

Marginal.

y

Non-marginal.

Discounts can be aggregated at various levels: y

Event source (not available for discounts that incorporate product charges).

y

Product (that is, product instances).

y

Package (not available for pre-itemization or tax discounts).

y

Subscription (that is, all products under the subscription).

y y

Account. Customers. There are three possibilities: o

Single customer – excludes any other customers in the same hierarchy.

o

Customer hierarchy – includes all customers lower down in the same billing hierarchy.

o

Whole customer hierarchy – includes all other customers in the billing hierarchy, lower down or higher up.

The viable combinations of these are given in Table 1 to Table 6: Table 1

Viable Marginal Single Set Discount Application/Aggregation Level Combinations

Rating

PreItemization

PostItemization

Tax

Aggregate Pricing

Banded

Event source Product Package Subscription Account Single customer

82



Table 1

Viable Marginal Single Set Discount Application/Aggregation Level Combinations (continued)

Rating

PreItemization

PostItemization

Tax

Aggregate Pricing

Banded

Customer hierarchy Whole customer hierarchy

Table 2

Viable Non-Marginal Single Set Discount Application/Aggregation Level Combinations

Rating

PreItemization

PostItemization

Tax

Aggregate Pricing

Banded

Event source Product Package Subscription Account Single customer Customer hierarchy Whole customer hierarchy

Table 3

Viable Marginal Double Set Discount Application/Aggregation Level Combinations

Rating

PreItemization

PostItemization

Tax

Aggregate Pricing

Banded

Event source Product Package Subscription


83


Table 3

Viable Marginal Double Set Discount Application/Aggregation Level Combinations (continued)

Rating

PreItemization

PostItemization

Tax

Aggregate Pricing

Banded

Account Single customer Customer hierarchy Whole customer hierarchy

Table 4

Viable Non-Marginal Double Set Discount Application/Aggregation Level Combinations

Rating

PreItemization

PostItemization

Tax

Aggregate Pricing

Banded


Table 5

Viable Marginal Bonus Scheme Discount Application/Aggregation Level Combinations

Rating

PreItemization

PostItemization

Tax

Aggregate Pricing

Banded

Event source

84



Table 5

Viable Marginal Bonus Scheme Discount Application/Aggregation Level Combinations (continued)

Rating

PreItemization

PostItemization

Tax

Aggregate Pricing

Banded

Product Package Subscription Account Single customer Customer hierarchy Whole customer hierarchy

Table 6

Viable Non-Marginal Bonus Scheme Discount Application/Aggregation Level Combinations

Rating

PreItemization

PostItemization

Tax

Aggregate Pricing

Banded



85


Products Geneva supports the following features of products: y

Products can be parametric. A parametric product is a product that can have a quantity associated with it. This allows an account to take, for example, 200 Centrex lines or a 14 mile leased line (where leased line is sold by the mile) and have it treated as a single item.

y

Products can generate events. For example, an electricity meter product generates meter readings and a share dealing account generates stock folders.

y

A single product can generate events of more than one type, for example, a WAP telephone may generate both call events and download events.

y

Products have a status associated with them, which may influence the product’s behavior or its charging. A product may be Pending, Suspended, Active, or Terminated. Active products are those in use. The status of Pending is used in exceptional cases where the lead time to activation is an extended period. Not all products, therefore, go through a Pending status. A product may be Suspended, for example, if a customer defaults on payment of an invoice, the Geneva operator may wish to suspend service for the customer until they have paid. Alternatively, a customer may know that they will not be using a service for some time, for example, working abroad for a long period. The customer may wish to recommence the service on their return. The Geneva operator is able to suspend the service until required by the customer.

y

Discounts may be set up to alter the price to be paid for a set of products, events, or both on a particular bill. Discounts are defined in Billing Catalog Maintenance and are attached to particular product/price plan combinations. An account does not have to receive the discounts that it has earned itself – they can be passed on to any nominated account. Thus for a company customer hierarchy, all of the branches could pass on their discounts to a single account at head office.

y

Similarly, the charges generated by a product can be passed on to nominated accounts. In the above example, all of the branch accounts could pay for usage incurred on a product, while a capital expenditure account at head office was invoiced for the initiation charges and an overheads account at head office was invoiced for the periodic charges.

Defining Products and Product Hierarchies A product is an item that the customer can purchase or lease. It may be a real object, such as a telephone, a service that is delivered such as telephone line rental or something more abstract such as a discount or service level agreement. The purchase of one product may depend upon the purchase of another product. For example, a call barring product cannot be purchased without a line rental product. A main product which may be purchased without any dependencies is referred to as a parent product . A related product whose purchase is dependent upon another product is referred to as a child product .

86



Groups of related products are organized into product families. For example, a telephony product family could contain line rental, call barring and any other fixed line telephony products. Some products generate events (for example, a telephone line rental product generates telephone call events). Multiple event sources can be listed for a single product. This allows, for example, a single product to be sold which consists of two mobile handsets with combined talk time. Geneva also supports parametric products. A parametric product is a product that can have a quantity associated with it. This allows an account to take, for example, 200 Centrex lines or a 14 mile leased line (where leased line is sold by the mile) and have it treated as a single item.

Defining Custom Product Attributes Each event type has up to 36 different attributes allowing the capture of relevant information about individual events (duration, location, geographic distance, scale, etc.). In a similar manner, each product can have up to twelve custom attributes. These product attributes allow information about individual products to be held, where the relevant information differs between types of product. This is useful where multiple kinds of product are being provided to the same customer, and different kinds of information must be recorded for each type of product. For example: y

A mobile telephone may have attributes recording its International Mobile Subscriber Identity (IMSI) number and Mobile Station International ISDN Number (MSISDN).

y

A pay-TV product may have an attribute recording its set-top box number.

y

A book may have an attribute recording its International Standard Book Number (ISBN).

Event Source Breakout Objects Values for certain product attributes may be brought in from an external system such as a stock control database. Product Configuration allows you to configure how such breakout data will be obtained.

Packages A package is a defined group of products that are sold together as a marketing bundle, often at preferential unit prices for each product when compared to its price outside the package. A package may consist of technologically related products. For example, you may create a telephony package that consists of line rental together with all the related products or a cable TV sports package that contains all the sports channels. Alternatively, a package may be a marketing bundle of unrelated products (such as cable TV rental plus telephone line rental) or parametric products.


87


Packages consist of one or more mandatory products together with zero or more optional products. A package may have multiple instances of the same product and these may be priced differently. It is possible to include parametric products in packages of products. When defining a package, it must be defined as being e ither tax inclusive or tax exclusive. Products within a package can only be split between accounts that are owned by the same customer that are of the same tax status. A package has its own set of prices; both standalone prices and package prices for each component product of the package can be defined. These comparison prices are available for output on the bill, so the customer can be reminded of the savings made by subscribing to the package. The term prices refers to all aspects of product pricing in Geneva. Initiation, periodic, termination plus discounting, bonus schemes, and loyalty points. Thus a package need not necessarily cost less but might, for example, confer more loyalty points. The customer can choose to have individual products within a package billed on separate accounts. In addition, the package discount obtained by taking a product within a package as opposed to on its own can be allocated to any account. Similarly, the charges generated by packaged products can also be passed on to other accounts in the same way as standalone products.

Subscriptions A subscription is group of products and/or packages that are sold together as a marketing bundle. The Geneva operator is responsible for defining and managing any rules for the selection of subscription content either by using a third-party external system (for example, a customer relationship management system) or through the use of appropriate business processes. An example of a rule for subscription content could be that the subscription must contain one handset, one line rental, and over $30 of monthly product fees. A subscription is different from a package in that a package is an offer that is made by the operator to its customers; it has a defined set of contents each at a defined price, whereas subscriptions are defined within Geneva as a sub-account grouping, linking a set of products and packages together for the purposes of bill presentation, discounting and financial reporting. A subscription, unlike a package, can have an associated periodic charge. Adding and modifying subscriptions in Geneva is similar to adding and modifying products of a product family. Deleting a subscription causes all packages and products taken under that subscription to be deleted as well. Geneva also allows the moving of a subscription to another account, resulting in packages and products under that subscription also being moved to the new (destination) account. However, an account can only be moved within the current customer hierarchy.

88



Subscription prices (initiation, periodic, and termination) are configurable and not dependent on the products and packages within the subscription. Discounts can be applied based on the products and packages within the subscription and on the number of subscriptions. Each Geneva operator can associate their required bill styles to the subscription type product family, using Product Configuration.

Market Segments Geneva allows you to cater for market segments in billing catalogs – specific price plan and package combinations for specific customers. For example, you can configure a package based on region (for example, a customer in one city is charged a different price plan than one in another city) or based on customer loyalty (for example, based on length of subscription or good payment record). Customers can optionally be assigned to a market segment which can restrict the price plans and packages available to that customer.

Bonus Schemes A bonus scheme is a method of giving the customer free usage (events) of a product, where the amount of free usage is determined by the prior usage of one or more products over a period of time (such as the previous year). They are designed to be a flexible customer retention mechanism, primarily for the residential/domestic marketplace. There are a number of constituent parts that make up a bonus scheme system: y

Usage monitoring – In order to determine the number of bonus points earned, the

customer’s usage of the specified product has to be measured over a particular period. A usage type is defined to specify:

y

o

What type of event is to be monitored (for example, telephone calls or pay-per-view events).

o

What attribute is being used to measure the event (for example, cost or duration).

o

Which events qualify for accumulation (which filter, if any, is to be applied).

Bonus unit accrual – When each periodic bill is produced, the qualifying usage (as

measured above) is converted into bonus units. The conversion details defined for the bonus scheme specify the amount of usage required to earn one bonus unit. y

Bonus unit redemption – Periodically (the period being specified as part of the bonus

scheme definition), the bonus units are redeemed and turned into a threshold value (the amount of free events allowed before charges are made). This comprises both of the following: o

The standard threshold (free events allocated regardless of usage)

o

The threshold per bonus unit (free events allocated for each bonus unit earned)

The number of free events is divided evenly between the bills produced during the redemption period.


89


There are three different products that play a part in bonus schemes: y

A customer participates in a bonus scheme if they purchase a qualifying product/price plan combination that has a bonus scheme attached.

y

Products with monitored usage may be different to the product that was purchased to qualify for the scheme (the qualifying product/price plan combination).

y

Furthermore, product/price plan combinations with discounted events (to create free events) may be different to both of the above.

Figure 17 illustrates the bonus scheme process.

Earn For each nominated event product: Over the defined period. Use a filter to get usage subset (usage measured by any attribute such as cost or duration). Add up the qualifying usage. Convert to bonus units using the defined exchange rate. ! !

! !

For example, accrue bonus units: 1 unit per 5 minutes of international call time, plus 2 units per $1 spent calling international friends and family numbers, plus 4 units per pay per view movie selected. !

!

!

Redeem

Accumulate Accrue bonus units over the defined period. Show bonus units earned and accrued on each bill.

Convert to free usage: Apply to a defined product X units free, plus Convert bonus units to further free usage. Spread equally over the bills for a defined period. To a class of events (defined by a filter). Free usage explicitly shown at zero cost. !

!

!

!

!

Example 1: Get 10 minutes free local calls per bonus unit. Credited over next 3 bills. Example 2: Get $1 of calls to friends and family numbers free per 10 bonus units. !

!

!

Figure 17 Bonus Schemes

Bonus schemes are powerful and flexible customer retention mechanisms. A well-designed scheme will reduce churn by offsetting or overlapping the earning and redeeming periods, so that the customer will either be still enjoying the free use of a product or, by the time the free-use period has completed, will have earned or nearly earned another segment of free use. For example, a customer may be offered a deal whereby if they take out a standard subscription to the Internet, they will be offered two hours of free telephone calls for every $50 spent on cable TV pay-per-view selections. In this example, all three products are different. Alternatively, the customer may be offered a deal whereby if they take a line rental product under a particular price plan, they will be offered $10 of free calls for every three hours of international calls. In this example, all three products are the same. A Geneva account can become a member of more than one bonus scheme (by purchasing two or more products that qualify for different schemes).

90



Loyalty Points For each product and price plan combination, the loyalty points to be awarded can be specified. Three values can be given: y

The initiation points are the loyalty points to be awarded at initiation.

y

The periodic points are the loyalty points to be awarded for each period.

y

The event point rate is the number of loyalty points awarded per cost of events generated by the product.

Geneva accrues the loyalty points against customer accounts alongside the financial details and these may be summarized on the Geneva bill. Adjustments can be made to the current total, for example to add points for introducing a friend as a potential new customer. In addition, a table of redemption options can be set up and the customer can choose to redeem part or all of their balance against the items available.

Multiple Currencies Geneva allows all price calculation (rating and billing) to be performed in any currency within a single instance. Most major world currencies are predefined in the system and additional currencies can be added as required. Each installation of Geneva can select the currencies that the Geneva operator supports and can, where necessary, adjust the conversion rates in force at a given time (that is, conversion rate histories can be held). Conversion rules (for example, rounding methods) can be set for individual currencies. Each defined currency can be marked as being one or both of: y

A pricing currency – a currency in which price plans can be defined, that is, a currency in which charges can be made.

y

An information currency – a currency in which bill data can be output for comparison purposes.

Billing and rating catalogs are defined for each pricing currency. These contain the price plans available to accounts in that currency. Accounts use currencies as follows: y

Each account is in a single (pricing) currency. The account will only be able to use price plans defined for the account currency. All transactions on the account must be in the account currency.

y

Each account can optionally have an information currency specified. Bill data will also be output in this currency (for comparison purposes).

y

Physical payments can be made in any of the currencies currently available in the system. When a physical payment in one currency is applied as an account payment to an account in a different currency, the resulting account payment will be for the converted amount in the account currency.


91


y

When a conversion such as the above is made to an open item account, the (converted) account payment is checked against outstanding invoices as usual. If the converted payment does not match an outstanding invoice, but is within a user-defined tolerance, the payment will be allocate d to the invoice and the difference written off. This is to allow for rounding errors in currency conversion.

Accounting Currency Each account must have its own accounting currency. This determines the currency used for all transactions on the account. An account may then be registered against price plans from the catalog of its own currency. There should be one live rating and billing catalog for every pricing currency being used in Geneva. To simplify the process of creating multiple currency-specific catalogs, it is possible to make a copy of an existing catalog in a different currency. For example, the Geneva operator may wish to create a euro price plan based on a U.S. dollar price plan. This process will convert all monetary amounts in the catalog using the current exchange rate. The Geneva operator may then edit the converted amounts if required.

Information Currency and Payments Geneva allows the total amount on the invoice to be shown in an information currency as well as the pricing currency. In order to facilitate the processing of payments made in a currency other than the pricing currency, the Geneva operator may define a currency conversion tolerance for each pricing currency. Whenever a payment is taken in a currency other than the accounting currency of the account and the converted amount is within the currency conversion tolerance of a single invoice, Geneva will automatically create a currency conversion write off for the difference. This write off and the incoming payment are both automatically allocated to the matching invoice so that the invoice is cleared. This applies to open item accounts only.

Multiple Currency Discounting Not only can basic pricing be performed in multiple currencies, but so can Geneva’s rich cross-service discounting. Customer level discounts, for example, may be offered even though the accounts to which the discount applies may be in different currencies. When thresholding on cost across currencies, the t otal contribution for each account is converted to the currency of the discount and these contributions are summed. The resulting discount is then applied to the contributing accounts, converting any monetary amounts using the exchange rate in effect at the nominal bill date. Similarly, donated discounts are also supported. A discount may be redirected to an account of a different currency using the exchange rate in effect at the time of the donation. Figure 18 shows this process.

92



Step 1: Foreign exchange all contributory spend for discount assessment. Head Office € Fixed foreign exchange international call spend

Floating foreign exchange international call spend Regional Office A £

Branch 1 £

Regional Office B $

Floating foreign exchange $ to €

Branch 2 £

Branch 3 $

Branch 4 $

Step 2: Foreign exchange pro rata discount back to earning accounts. Step 3: Foreign exchange earned discount to nominated receiving account. Head Office € Fixed foreign exchange € to £

Floating foreign exchange discount in $ to € Regional Office B $

Regional Office A £ Floating foreign exchange € to $

Branch 1 £

Branch 2 £

Branch 3 $

Branch 4 $

Figure 18 Multiple Currency Discounting

Payment Methods and Discounts Each physical payment requires a payment method. Payment methods typically include cash, check, etc. In addition, Geneva can automatically generate payment requests for payment methods that support automatic transfers of cash (for example, direct debit, credit card). Payments made by these methods are automatically collected from the customers. Geneva allows any number of payment methods to be defined and, optionally, a discount may also be associated with that payment method and applied to the total bill value. The Geneva operator can then enter the acceptable payment methods such as check, cash, and direct debit.


93


Payment method discounts provide a whole bill discounting mechanism. Payment method discounts may be specified as a percentage or a fixed amount and may have any number of steps and thresholds defined. Multiple payment methods can be set up in Geneva, including details such as holding bank accounts, notification delays and whether or not refunds can be made. This allows the Geneva operator to partition the payment methods by payment system, payment authority, etc. Geneva supports a generic payment interface. Geneva exports payment requests in a standardized format, which can then be run through a post-processor to format them for a particular payment interface. Through this, multiple payment systems can be used in a single installation of Geneva.

Aggregate Pricing Geneva provides aggregate pricing discounts. This includes the ability to support the following aggregate pricing discounts: y

Marginal and non-marginal.

y

Single-set and double-set.

y

Customer-level (single customer, customer billing subhierarchy, and whole customer billing hierarchy).

For these discounts, the proportions to be applied to the discount set for each pricing band are based on contribution to assessment set across accounts (via filters on event charges). Aggregated charges are based on the contribution for each combination of: y

Total contribution across accounts to band (as compared to all bands).

y

Volume of threshold attribute (such as number of calls or number of minutes) for the account.

y

Aggregate price for the threshold band as defined in the price plan.

Budget Payment Plans and Discounts A budget payment plan allows a customer to pay a regular amount every month (or other period) towards their bills, rather than paying each bill separately. The plan specifies the payment method to be used (typically direct debit) and the rules for calculating the payments. The amount being paid is reviewed periodically and adjusted according to the current outstanding balance and expected spend over the coming review period. A damping factor may be used in this calculation to prevent unnecessarily large changes to the amount being paid. The expected spend may also be adjusted by a percentage to allow for price changes. Unscheduled reviews will be triggered at billing time if the amount outstanding on the account exceeds a specified multiple of its credit limit.

94



A budget payment plan may also have discounts associated with it – any account on the budget payment plan will receive the discount against each invoice. The discount may be specified as a percentage or a fixed amount. The level of discount may also be specified to depend on the invoice value.

Revenue Codes The use of revenue codes allows enormous flexibility in partitioning revenue by source. Revenue codes can be assigned to any source of revenue, including: y

Product charges (initiation, periodic, and final).

y

Taxes.

y

Adjustments.

y

Discounts, including package discounts.

y

Events.

The revenue codes assigned to a single class of events can be subdivided by the attributes of the individual events. For example, for the event type “Telephone calls”, you could configure different revenue codes for the following types of events: y

National, off-peak calls.

y

National, peak rate calls.

y

International, off-peak calls.

y

International, peak rate calls.

Geneva revenue codes are free text and may be structured to represent a revenue code hierarchy. All products for a particular product family might have the same revenue code or individual revenue codes might be used. The Geneva financial day books then summarize and pass summary ledger information out in reports, summarized by revenue codes. For all revenue records billing will maintain date range information, the applicable tax code and a transaction count for each revenue code/date range combination.

Revenue Classification by Product Charge Geneva supports the association of a revenue code at the charge type level per price plan and per product. Product charge types include initiation, periodic, and termination charges.

Revenue Classification of Usage Charges Geneva allows the classification of usage revenue by a configurable set of event attributes such as cost band and time rate. A mapping of a combination of event attributes to a revenue code is referred to as an event revenue mapping . A number of these are required to complete the mapping of attribute combinations to revenue codes. This set is referred to as an event revenue mapping set . The Billing Engine must use an event revenue mapping set when generating bill details entries so that usage revenue is grouped against the appropriate revenue code.


95


The event revenue mapping set and its constituent event revenue mappings is definable by the Geneva operator. Configuration of event revenue mapping is supported by System Configuration.

Revenue Classification of Discounts Geneva also supports revenue classification by discount and package discount, thus making it possible for the Geneva operator to report discount revenue separately. For example, consider the following package discount: y

Comparison price plan A has product X at $10 – revenue code 99.

y

Package price plan B has product X.

y

Package price plan B has the package discount ($2).

y

User chooses to assign the base price ($10) to revenue code 31 and the package discount (-$2) to revenue code 32.

Revenue Code

Price ($)

Product X basic price on comparison price plan A

99

10

Product X basic price on package price plan B

31

10

Product X discount amount on package price plan B

32

-2

Product X price on package price plan B

8

Billing must report the comparison price plan price ($10) against the package price plan revenue code (31) and the package discount amount (-$2) against the package discount revenue code (32).

Provisioning Systems Individual products can be linked with provisioning systems, so that a change to the product in Geneva (for example, when a customer stops taking the product) can trigger a service request in the provisioning system (for example, sending a request to have the product physically disconnected on site).

Import and Export of Configuration Data A Geneva operator can maintain two instances of Geneva, a live system and a test system, where the test system is used to test new configurations before they are implemented into the live system. The live system contains a copy of the configuration data held in the test system. Figure 19 shows the Geneva update cycle.

96



Export table sets

Live system (original configuration)

Test system (original configuration)

Reconfigure and test

Test system (new configuration) Compare table sets exported from live system and current table set in test system

Live system (new configuration)

Export table sets differences

Identify differences between original and new configuration

Figure 19 Import and Export of Geneva Configuration Data

Geneva provides a user application (Configuration Data Transfer) that allows the Geneva operator to import and export comprehensive Geneva configuration data including product information, thereby ensuring consistency between and accuracy of systems, catalogs, and products. Geneva supports this process by: y

Providing the facility to import and export data from any user selected configuration table to and from a given instance of a Geneva database.

y

Allowing the import and export of sets of tables that are logically related (where sets may be either pre-defined or configurable) to and from a given instance of a Geneva database.

y

Generating and displaying a difference list based on a comparison of the data contained in the existing system and the data being imported. The user is given the opportunity to accept or reject (en masse) the changes that the import will impose on the system.

y

Maintaining an audit trail of the exports and imports that have been performed on the database, detailing: o

Date/time of export/import.

o

Tables exported/imported.

o

Source of exported/imported file.


97


o

User who performed export/import. Export and import between Geneva versions is only supported where there have been no schema changes to the tables being imported/exported.

The configuration data consists of pre-defined and user-defined sets of Geneva tables (a table set consists of one or more Geneva tables). The data file imported/exported consists of either the entire contents of the table sets or the differences between the current contents of the table sets and the contents of previous version of these tables. It is therefore possible to export and import all tables that relate to a particular aspect of Geneva configuration as a set, for example, all information relating to price plans can be transferred between Geneva databases by using the billing and rating catalog export/ import functionality alongside the product set export/import. This facility supports the maintenance of two instances of Geneva; a live system and a test system. The Accounting Data Writer provides an alternative, highly customizable means of exporting data from the Geneva database. This exports accounting, invoice, and payments information, as well as data on earned but unbilled accruals from the database in a standardized, customizable format, suitable for use by third-party applications such as Microsoft Excel.

Customer and Account Maintenance Geneva provides a flexible set of tools and capabilities to model the Geneva operator’s customers and their accounts. Geneva does not prescribe structures for customers, the relationships between customers and their accounts. All information relating to a customer (their contact details, their accounts, etc.) is fully historied over time. This means that Geneva always has the correct details for billing at a given date. Customer Account Maintenance is able to work effectively with large numbers of event sources and events associated with a single product. For example, you can have 100,000 event sources and millions of priced events. The facilities outlined in the following sections are a summary of the customer and account handling capabilities of Geneva. Functions to enter and maintain such data are available through a Geneva user application. They are also available through the API set so that the Geneva data may be entered and maintained in an integrated environment by a customer care package or legacy system.

Customer Hierarchies Geneva allows corporate customers to be modeled as a hierarchy of related customer organizations. There are no restrictions on the number of companies that may be related in a hierarchy nor on the depth or width of the hierarchy.

Customers A customer is either an individual or a company who purchases products.

98



Geneva stores a range of mandatory and optional customer information, such as customer reference number, name, whether they are a domestic or corporate customer, tax details, and contact information. In addition, Geneva allows the Geneva operator to define an additional customer table with whatever additional customer data that the Geneva operator requires. This information can then be entered and maintained using Geneva user applications and APIs. In some countries, it is common practice to use and retain two surname entries per customer. This second surname is used in addition to and in the same way as one surname is used in other countries. Geneva supports the use of two surnames by allowing you to input, store and output data into customer name fields via the contact attribute in bill data. Additionally, you can search for customers using any field entry. The customer structure is hierarchical and may extend to any depth. Figure 20 shows a possible hierarchy for a company.

Head Office

Regional Office 1

Branch 1

Regional Office 2

Branch 2

Branch 3

Branch 4

Figure 20 Example Customer Hierarchy

Geneva is totally flexible, so with this company structure, you might opt to have: y

y

All seven entities as separate customers, with: o

All four Branches receiving invoices.

o

Regional Office 1 receiving an invoice for its services and a report for itself and Branches 1 and 2.

o

Regional Office 2 receiving an invoice for its services and a report for itself and Branches 3 and 4.

o

Head Office receiving an invoice for its services and a report for itself, Regional Offices 1 and 2, and Branches 1 through 4.

The Head Office and Regional Offices as separate customers, with: o


Each Branch receiving a usage report.

99


y

o

Regional Office 1 receiving a single invoice for its services and those of Branches 1 and 2.

o

Regional Office 2 receiving a single invoice for its services and those of Branches 3 and 4.

o

Head Office receiving an invoice for its services and a report for itself and the Regional Offices.

Just the Head Office being a customer, with: o

Each Branch receiving a usage report.

o

Regional Office 1 receiving a usage report for itself and Branches 1 and 2.

o

Regional Office 2 receiving a usage report for itself and Branches 3 and 4.

o

Head Office receiving an invoice for all services with a breakdown of the spend by Regional and Branch Office.

There is, of course, no restriction on the geographical location of the branches, etc. For example, Head Office could be in the United States and the Branches in Germany, Great Britain, Australia, and Brazil. The bills and reports would automatically be provided in the appropriate language and using the appropriate currency.

Calling Circles Calling circles define a relationship between users who are modeled as members and non-members of the calling circle. Within this model, a call made by a member of the circle to another circle member is charged using a different rate than that applied to a non-member making the same call. The relationship between the calling parties (full, none) is determined by the combination of caller identifiers (which may be CLI or IMSI/MSISDN). Calling circles can span networks and a single circle can include both mobile and fixed-line users.

Accounts An account is the entity that is invoiced. Geneva stores a range of mandatory and optional account information, such as account number, contact information, and bill period. In addition, Geneva allows the Geneva operator to define an additional account table with whatever additional account data that the Geneva operator requires. This information can then be e ntered and maintained using Geneva user applications and APIs. A customer may have all the items that they purchase placed on a single account so that they receive a single, convergent invoice (bill) for all services. Alternatively, the customer can have them spread across several accounts in which case they will receive several invoices.

100



The account invoice period determines how often an invoice is produced. The products that are invoiced have a periodic charge period – this may be different from the account invoicing period. Geneva allows the account invoice period to be any day of the month, including the days at the end of each month that vary from month to month. Each account can have a number of budget centers defined for it. Geneva supports the concept of account status. The status of the account determines whether bills can be produced for the account, and which bill types it can produce. An account can be: y

Pending.

y

Live.

y

Awaiting final bill.

y

Suspended.

y

Terminated.

y

Internal.

In the case of a suspended account, all billing activity on the account is halted. However, charges on the account can continue to accrue over the suspension period, although they will not be billed until the account is transitioned to the Live or Awaiting final bill status.

Budget Centers A budget center is a subset of products registered against a single account. Each account can have a number of budget centers defined for it. Each item taken by a customer may be allocated to a budget center, so that when the account is billed, the budget center receives a report on the items, invoiced to the account, which are allocated to that particular budget center. Budget centers may be hierarchical, with each budget center receiving details of its expenditure and a summary of the expenditure of the budget centers beneath it in the hierarchy. This allows a large company to be invoiced centrally with many levels of reporting to regional office, area office, or branches. It is also possible to create summaries of spend by arbitrary groupings of budget centers, as well as the groupings defined by the hierarchy. So, for example, a company can obtain functional summaries (such as by sales, marketing, production, and distribution departments) as well as geographical summaries (su ch as by branch office).

Contacts A contact is a person with whom the provider has contact. For example: y

A customer has a statement contact, that is, a person to whom statements regarding their accounts are sent.

y

An account has a billing contact, that is a person to whom invoices are sent.


101


y

A budget center has a reporting contact, that is, a person to whom reports regarding budget center spend are sent.

y

A product has a product contact, that is, a person to whom correspondence relating to the product is sent.

y

Account hierarchies have a statementing contact, that is, a contact that receives a cross-account summary.

In multiple-language installations of Geneva, a contact language can be specified for each contact. When a bill, dunning notice, or report is produced for the contact, the item labels from the specified language will be used.

Customer Products and Packages A single Geneva customer may subscribe to or purchase any number of Geneva products and packages. Each product, whether a standalone product or a constituent part of a package, must be registered against one of the custo mer’s accounts. All products that are registered to a single account are billed at the same time – when the account is invoiced. A package (a mandatory set of products on a special package price plan) can be split over several of the same customer’s accounts. This allows the benefit of the package price to be realized by the customer, but for them to receive separate invoices if that is desired.

Split Product and Subscription Charging There are basic elements of a product change and a subscription charge; initiation, periodic and termination charges. Geneva allows any of these various elements to be invoiced to different accounts within a customer hierarchy. For example, Geneva allows a single product to be registered to a customer with the periodic charges being invoiced to one account and the initiation/termination charges going to a different (capital expenditure) account. When registering a product or subscription to a customer, the Geneva operator may opt to split the static product/subscription charges on a percentage basis between some or all of the accounts in the customer hierarchy. With products, unlike static product charges, usage charges must all be allocated to a single (owning) account as it is not possible to split ownership of an event source. Discounts are redirected from the account that is invoiced, which is not necessarily the account that owns the product or subscription. That is, discounts are redirected according to the configuration of the account to which the charges have been allocated. The redirection configuration of the owning account is irrelevant.

Customer Product Status Products can be created as active products, that is, they are taken by customers and therefore in use from the point of creation. Products can be pending only in exceptional circumstances, for example, where the lead time to activation is an extended period. Not all products go through the pending status.

102



Products can be suspended . During a suspension period, you can determine if periodic fees should continue to be charged or select a different periodic charge. For example, a customer who is moving abroad for six months would like to suspend their service until they return. When the customer returns, the product’s status can be amended to active (that is, it can be reactivated ). This allows the Geneva operator to resume the customer’s service, without losing customer information.

Contracts It is increasingly common for price plans to have a minimum contract period associated with them. For example, the longer the contracted commitment, the cheaper the deal. If the customer then elects to terminate service prior to the normal contract renewal time, they may incur a penalty. Potentially, the customer could be liable for the periodic charges for the remainder of the contract and an additional charge for early termination. At the customer level, the Geneva operator can define any number of contracts. Contracts are umbrella entities under which one or more products may be purchased. When the termination of a contracted product is requested and early termination surcharges are applicable, the user will be warned that the early termination will incur penalties and will be given the option to: y

Apply early termination charges and proceed with the termination.

y

Reject early termination charges and proceed with the termination.

y

Cancel the termination.

Nominated Events Geneva allows discounts to be defined that are, in part, customer-specific . That is, the general mechanism is defined within the billing catalog, but some customer-specific details are needed. For example, a frequent call discount can be specified which allows each customer to specify a limited number of telephone numbers which they wish to nominate which will be discounted. These numbers are known as nominated events. Geneva nominated events are completely independent of the delivery technology. Hence a pay-per-view product might allow certain TV shows to be nominated, a telephone service product allows telephone numbers to be nominated, an Internet product will allow web sites to be nominated, or a data services product will allow specified data sources to be nominated.

Cost Centers A cost center is a customer-nominated classification of events for a single product. If the customer chooses, Geneva will detail the use of an event product by customer-nominated cost center.


103


For example, for a telephony product, you might nominate a dialed prefix of 1 for business calls, 2 for home calls and 3 for calls made by children. Geneva will then provide summaries on the bill of calls divided by these groupings, providing the customer uses the additional cost center numbers when dialing.

Payment Details Geneva records and maintains the payment details for each customer account. Such information is fully historied. Payment details include: y

y y

y

Automatic bank payment request details, such as direct debit authorizations. Customer bank account details, bank codes, and account codes are maintained. Credit card payment details. Automatic check payments, such as payments made through a banking system Lockbox interface. Budget payment plan details, such as payment plan name, payment day, review period, and threshold.

Failed payments such as direct debit authorization payment failures and check presentation failures are also recorded.

Rated Events Geneva records all rated events in a rated event area of the Geneva database. These are organized by customer account. Geneva retains re tains events that have been invoiced and those that have yet to be invoiced in this area of the database. Rated events that have been invoiced may be held online for a period specified by the Geneva operator, then archived and deleted. Geneva user applications allow the rated events to be viewed, ordered and searched for by a range of different criteria. All events for an account are available, thus pay-per-view movie events are viewable through the same screen as telephone calls, data accesses or Internet usage.

Bills Geneva bills customer accounts according to the bill period of the account. When an account becomes billable, the Billing Engine accesses all information relating to that account and generates an invoice. At the same time, Geneva will also produce a statement of account and put this information out in a section of the bill data. Bill summary records, raw unformatted bill data and (optionally) WYSIWYG bill images are all held within the Geneva database. The Geneva user applications and SQL-level APIs provide user access to this bill data. Geneva allows any number of different bill image styles to be held online. Geneva user applications will launch the correct bill viewing program by image type.

104



Geneva invoices may include icons, graphics and color if required. Many different invoice formats are supported – individual customers may m ay have a customer-specific invoice style if required. Geneva provides support for an unlimited number of marketing messages on a single bill. These may be defaults for the bill or customer-specific messages. Geneva also provides capabilities for marking accounts to include an unlimited number of bill inserts for a definable period and conditional on the invoice amount. Additionally, you can output discount information applied to events. For example, you can indicate the number of events related to a particular usage such as “20 minutes of free telephone calls in May.” May.” Geneva supports the following bill types: y

Initiation bills – these may be requested when an account is opened to cover initiation charges.

y

Periodic bills – these are produced at regular intervals depending on the bill period specified for the account.

y

Final bills – these may be requested when an account is terminated to bill all outstanding charges that are due.

y

Post-final bills – these are extra bills produced to cover receivables which appear unexpectedly on accounts that have already had final bills produced.

y

Interim bills – these are extra bills which contain any usage charges (that is, charges for events) due for the account since the last bill generated. They may be requested, for example, because the customer has asked for an extra bill to check their usage or because a customer has exceeded their credit limit.

y

Credit notes – these are extra bills which contain all adjustments in the customer’s favor generated since the last bill. Credit notes are normally issued to undo a previously invoiced item, for example, for goods that are returned or not supplied. A credit note is a VAT document in the same way that an invoice is.

y

Budget center reports – these contain the same data as bills, but are sent out for information rather than as a request for payment. Budget center reports allow the creation of systems where entities within an account (budget centers) can receive reports detailing their individual spend, while an overall invoice for the account is sent to the account contact.

Credit notes, interim, final, and post-final bills may be generated on demand. Final bills may also be requested automatically au tomatically for n days after the termination date, where n is configurable. This is an optional system parameter and if not set, bills will not be requested automatically. Instead, they must be requested manually. In addition to the normal production bills, Geneva can also produce: y

Test or What if? bills – these are handled like normal n ormal bills but the database is left unchanged. They can be useful, for example: o

After After makin making g signif significan icantt change changes s to the the billin billing g catalo catalog. g.

o

Afte Afterr maki making ng cha change nges s to bil billl temp templa late tes. s.

o

To look look at at prob proble lem m acco accoun unts ts..


105


y

Exceptional bills – these are bills where the bill data fails certain checks that Geneva performs on it. These checks involve testing the total being billed to ensure that it is within certain user-defined limits. Such bills are useful for working out why the data is out of range: o

It may be that that the data is genuine genuine and the the user has simply simply been using the service services s provided far more heavily than normal.

o

Alternatively Alternatively,, it could could be be a “rogue” “rogue” bill bill due due to incorre incorrect ct prices prices in price plans, incorrect event data, etc. Exceptional bills are not “produced” as the other bill types are, but rather are “detected” by Geneva.

y

Reissued bills – bills reissued because the customer has mislaid or not received the original.

y

Summary statements – a summary statement produced during billing that details all the expenditure at and below that point in the hierarchy. hierarchy. For this approach, the following should be defined: o

A statem statement enting ing cont contact act that that will will rece receive ive the stat stateme ement. nt.

o

A sta state teme ment ntin ing g cur curre renc ncy y.

Although a summary statement is not itself an invoice or a request for payment, a single mailing (including a combination of summary statements and bills) can be sent to the statementing contact for all accounts which belong to a billing hierarchy. Figu Figure re 21 illustrates this.

106



Sharron

Prepay Account

Dad

Mum

Micky

Postpaid Account

Jack

Prepay Account

Bill

Total cash Checks

$

Figure 21 Family Scenario, Summary Statement for Many Accounts

Along with their bill, the parents (the statementing contact) have requested that they receive a statement that details the activity on their three children’s accounts. All this information (three account bills and a statement) can be combined in a single monthly mailing.

Disputes and Adjustments A dispute is a record of a query about an amount of money on an account. Normally, Normally, a dispute will be recorded when a customer queries some aspect of their bill. Disputes can be raised: y

Against an invoice on an account.

y

Against a particular rated event on the account. For example, if a customer customer disputes a particular pay-per-view TV event due to a power cut.


107


Disputes follow a progression of being raised and investigated (during which the dispute status is pending ) and then either accepted (dispute status accepted ) or rejected (dispute status rejected ). There is also a dispute status of cancelled which is used when a dispute is entered in error, for example against the wrong account. Collections actions are not escalated while amounts have a dispute status of pending, but the collections are aged during this period. Disputed events are not included in collections calculation until they are billed. After this, the collections are aged as normal. An adjustment is a method of crediting or debiting an account with an arbitrary amount of money. Adjustments can be lodged against either an account as a whole or against a particular rated event on that account. If a dispute is accepted, an adjustment is created to credit the account with the disputed amount. This adjustment is then coupled to the dispute history. Once the adjustment has been entered (adjustment status pending approval) it can be approved (adjustment status approved) by a privileged user. Approval will happen automatically if: y

The adjustment is for an individual event.

y

Optionally – whenever an adjustment is entered (controlled via a system parameter).

Adjustments can also be rejected or cancelled in the same manner as disputes (adjustment status rejected or cancelled). However, adjustments can also be created without an initial dispute progression if this is appropriate. For example, to rectify billing mistakes where the customer has been undercharged. Adjustments do not affect the balance of an account until they are approved. Adjustments with a status of pending approval do not affect billing or collections. The size of adjustment which a Geneva user is authorized to make can be defined for each individual user. Disputes and adjustments that are made for tax inclusive accounts are assumed to be inclusive of tax. The gross amount is entered and will be available for output on the bill.

Transaction Approval Mechanism A two stage mechanism is available for processing disputes and adjustments whereby they can be first keyed by an operator and then passed to an authorized user for approval before they are committed to the customer’s account. Access to the approval function is limited to privileged users only. The Geneva operator may insist that all transactions be approved separately by another user or only in cases where the amount of the transaction exceeds the user’s transaction limit. If the amount falls within the user’s permitted transaction limit, the adjustment may be approved automatically (subject to the auto approval system parameter being activated).

108



Payments and Refunds On an account by account basis, Geneva provides facilities to: y

Enter and view payments.

y

Enter and view physical payments (such as credit card and direct debit payments).

y

Enter and view account payments.

y

View automatic payment requests that have been generated by the system (such as direct debit payment requests or credit card payment requests).

y

View failed payments.

y

View the refunds made and refunds requested.

Loyalty Points Geneva accrues the loyalty points against customer accounts alongside the financial details and these may be summarized on the Geneva bill. Loyalty points can be awarded for each product instance registered to a customer account. Loyalty points can be credited for: y

Product initiation.

y

Periodic subscription (periodic charges) of a product.

y

Usage of a particular product; the events generated by a particular product.

Adjustments can be made to the current loyalty point total, for example to add points for introducing a friend as a potential new customer. In addition, a table of redemption options can be set up and the customer can choose to redeem part or all of their balance against the items available.

Customer Notes Geneva allows you to enter notes that can be used to add further information to a customer account such as a reminder to follow up on a customer query. For example, a customer telephones a call center and speaks to a customer service representative (CSR) regarding a query about a bill or payment. The CSR can enter notes via Customer Account Maintenance about the interaction with the customer to aid future interactions with that customer, which may involve different CSRs.


109


Deletion of Customer Data Data In some countries, the law requires that all customer related data for terminated customers be deleted after a specific period of time. Geneva supports the optional (at the invoicing company level) deletion of customer related data for customers with terminated accounts using a configurable time period after the customer’s account has been terminated.

Tax Geneva provides a high degree of control over how tax is charged, including the ability to bill across multiple, non-overlapping tax jurisdictions, and support for European tax law as defined in the 6th E.U. Tax directive. Therefore: y

Geneva supports tiered taxes/duties (including VAT); both percentage and fixed-rate taxes are supported.

y

The tax rate for a product can vary depending on where the product is being supplied to the customer.

y

Tax behavior during tax rate changes (for example, optional prorating, rounding behavior) can be configured for individual taxes.

Geneva allows invoicing in multiple tax jurisdictions, across multiple countries, issuing separate invoices (with separate VAT VAT registrations) for each country. The combination of contracted point of supply and invoicing company is used to calculate the tax that should be paid upon a charge.

Invoicing Company Each account is owned by a single invoicing company. The invoicing company refers to the part of a Geneva operator that is legally operational within a single tax jurisdiction, including any service providers operating in that jurisdiction. Geneva requires an invoicing company for each tax jurisdiction that the Geneva operator is registered in, whether that is via subsidiaries or by multiple registrations. Each account must be assigned to an invoicing company. VAT VAT registrations are made for individual invoicing companies within the system. When accounts are billed, the invoicing company’s VAT VAT registration number is included in bill data.

Contracted Point of Supply The contracted point of supply only applies to the VAT/GST tax model.

The contracted point of supply is the area where the product is considered to be supplied to the customer. Within a single tax jurisdiction the tax set for a product may vary depending upon the contracted point of supply. For example, a telephone line rental in Madrid is subject to 17 percent pe rcent VAT VAT, but in Gran Canaria it is subject to zero percent, whereas in Melilla (Spanish North Africa) it is subject to four percent . The contracted point of supply is often geographic, but need not be related to the address to which the services

110



are delivered. For a mobile telephone, for example, the contracted point of supply is usually determined from your home address, regardless of where you use the telephone. In the case of business telephony services delivered to a number of sites over a wide area, the contracted point of supply for each service may be a different address. An example of a non-geographic contracted point of supply is supply of services from one department of a company to another (internal supply) where typically no tax is applicable. Each customer product is invoiced under a contracted point of supply. The Geneva operator can change the default contracted point of supply of an account at any time, except when the account is awaiting termination or has been terminated.

Tiered Duties/Taxes Duties/Taxes Applied to Single Product For a given product being invoiced under a given contracted point of supply, multiple duties and/or taxes may apply. apply. These may be percentage or monetary (such as 5 percent or $10) and may apply to either the pre-tax amount or to the amount inclusive of duties/ taxes levied so far.

U.S. Tax Model Geneva provides tax calculations for other tax models by integrating with one or more third-party tax package(s). Refer to the r elevant integration overview guide, for example, Geneva Integris Integration Guide for Brazilian tax, for more information. A key challenge when billing customers in the United States is the complexity of the tax system. Products and services are subject to a range of different taxes, payable to different authorities. There are approximately 70,000 communities in the U.S. capable of levying taxes. These communities define nearly 400,000 different tax rates and application rules that are dynamic, changing monthly. Given the specialized nature of U.S. taxation, Geneva provides U.S. tax calculation by integrating with a third-party tax package. Currently Curre ntly,, Geneva provides integration with Vertex. Geneva provides comprehensive user application support for the categorization of all charges according to their transaction and service type. The billing process constructs a neutral data structure of transactions with the required information to pass to the tax package. Additionally, you can run a U.S. style taxation model and a VAT/GST VAT/GST taxation taxation model in the same instance of Geneva. Tax information used during billing depends on the tax regime being used by the invoicing company under which an account is registered. For example, a company that sells goods and services in the United States has a subsidiary company that is registered to collect tax in the U.K. for the goods and services it will supply to the U.K. The company can run all of its invoicing function out of its U.S. office, from a single instance of Geneva and is able to produce legal invoices including tax for both its U.S. clients and its U.K. clients.


111


Tax Overrides Certain customers may be eligible for exceptional taxation treatment such as customer or product exemptions, additional taxes and special discounts. Geneva allows you to set the amount of a tax (or duty) to apply on an invoice according to the level of spend for certain charges (product and usage). In particular, Geneva supports Italian stamp duties; Stamp Duty on Contract and Stamp Duty on Invoice. Tax rates on events can be overridden on an event-by-event basis if required. This allows the tax calculation for the event to be specified by an external system or pre-processor prior to import into Geneva if required. Thus, different tax rates can be levied on events of the same type. For example, tax overrides can be used in situations where: y

Standard rate telephone calls are taxed at 10 percent, but premium rate calls are taxed at 20 percent. percent.

y

Usage tax on electricity consumption depends on the amount of usage.

Tax Inclusive Price Plans Accounts, rate plans, and price plans can all be defined as either tax inclusive or tax exclusive. In the case of prepay mobile telephony, when prepay vouchers are sold, their precise future use is unknown. Taxation Taxation must therefore be undertaken at the time of use. A different tax or taxes may be applied to each event.

Postpay

NET PRICE

GROSS PRICE Calculate applicable taxes

TAX GROSS PRICE Calculate the tax that was applied

Prepay Rating

NET PRICE

Billing

Figure 22 Tax Inclusive Rating and Billing

Tax inclusive price plans are available to both prepay and postpaid accounts.

112



Language Geneva allows Geneva operators, wishing to sell services to customers with different languages, to define a product (or other entity) once and then name it in several different languages. This ability to name entities in many languages is provided not only for products but also for product families, price plans, discounts, bonus schemes, packages, etc. Furthermore the Geneva operator may specify translations for all configuration data that can appear on a bill, budget center report, or dunning notice. When creating a product in Geneva, the operator should use an internal language. For any other languages that are required, a mapping of this internal name to a language name can be used. Thus, the Geneva operator may define the intern al language name for a product as “Telephone”. The German language mapping of this is “Telefon”. The default language may be set to be the internal language. This enables single-language instances to use the internal language as their own, and avoid the need to provide translations. Where a Geneva installation is set up initially on t he basis that it will have a multilanguage customer base, some operators will choose to use the internal language to store item codes for many entities rather than entering more ordinary values. This helps to identify products in any language. For example, a product may be defined in the internal language as TEL001. Then this product may be defined in other languages, so TEL001 may be variously TEL001 Téléphone, TEL001 Telefono, TEL001 Telefon, TEL001 Teléfono in French, Italian, German and Spanish respectively. Table 7

Example Language Setups Internal Language

Default Language

Translations

Single language scenario

German

German

NONE

Two language scenario

German

German

French

ITEM CODE

English

English, German, French, Spanish

Multilanguage scenario

Geneva users are able to select the language they wish to work in from a top level menu in the user applications. For example, a multilingual customer services representative may wish to view a customer’s products in the customer’s language. In addition to the Western European character set (for example, French), Geneva supports: y

Languages that use non-Western European character sets but use single byte left-to-right characters (for example, Croatian).

y

Limited enablement of languages that use single byte right-to-left character sets (for example, Arabic).


113


Multibyte Character Sets Geneva allows you to modify and present data in geographic markets where the full range of required characters for a given language is supported by multibyte character sets (for example, Simplified Chinese). This data takes many forms such as customer names, addresses, purchased products and recorded usage. Presentation of this data can be via bills, on-screen to customer care representatives or through self-care applications.

Billing Geneva provides a fine degree of control over how customers are billed. The products taken by the customer (and the charges generated by those products) can be: y

Registered against a single account in which case they will be billed together.

y

Registered against separate accounts in which case they may be billed independently.

y

Registered against separate accounts and billed together.

Distinct billing, hierarchy billing, and convergent billing are supported. Geneva is able to generate bills for future charges further than one bill period in advance, for example, to produce a bill on August 19 for a rental charge due for September 1 through September 30. Geneva allows operators to recognize both future (not yet billed) and past (already billed) product detail changes and to charge accordingly. For example, if an in advance, proratable, product terminates partway through the bill period Geneva can recognize this and prorate the charge accordingly. The billing process also takes into account product detail changes which occur during the billing period of interest and calculates charges accordingly. The Geneva user applications support the viewing of bill images to allow details to be checked on screen if required. When copy bills are being produced (possibly in different languages), the bill image that can be viewed is the master bill. The Geneva user applications also allow the user to request that a bill be reissued (for example, when a customer loses their original bill). Reissued bills can be sent to any contact for the account, and will contain all the information included on the original bill. In addition, reminders can be sent out if bills are not paid on time – this is part of the collections process described in "Collections," page 132.

Billing Single Accounts The Billing Engine bills collections of billable accounts. For a single billable account, it uses the live billing catalog to undertake the following: y

y

114

Calculate any periodic, non-recurring, and final charges for the account and prorate them as necessary. Aggregate the events (such as telephone calls) generated by the account.



y

Calculate discounts on a set of events (relating to individual products, to collections of packaged products, and for the whole account), using filters to select them. Figure 23 illustrates this.

For the selected product, package or discount

Apply filters

Calculate discount

Apply discount back to the account

For each usage discount Figure 23 Discounts on Sets of Events

y

Manage bonus schemes by performing the following at the appropriate times: o

Rerating of events to take into account any free event thresholds that apply.

o

Calculating the usage for the current period.

o

Converting the usage into bonus units.

o

Calculating the free event thresholds for the next redemption period.

y

Select the marketing messages for the account.

y

Generate automatic payment requests (such as direct debits).

y

Generate accounting information.

It then records the information content of the bill as a database record within the Geneva database. Geneva bill data is organized as a tagged data record that can be exported as a tagged ASCII file for processing by a printing bureau using standard document formatting packages.

Billing Customer Account Hierarchies If a corporate customer hierarchy is to be billed together, then Geneva will bill the set of accounts that are related by the customer hierarchy as one set. In such circumstances, all the accounts are billed at the same time and all accounts have the same bill period. Customer hierarchy billing applies the same sequence of actions as for a single account. A number of extra actions take place prior and subsequent to the actions within a single account. In summary, billing a hierarchy works as follows: y

Geneva identifies the set of accounts related by the customer hierarchy.

y

The Billing Engine then traverses the customer account hierarchy from the top downwards, calculating totals of event spend by discount category. For example, if there is a corporate-wide discount assigned to a company in the hierarchy (for example, one that relates to all international telephone traffic), then a total is calculated for all international calls made by all the relevant pr oducts of each account. There may be any number of customer discounts that are to be accrued through all or part of the corporate hierarchy.


115


y

The discount due because of customer-level discounts is then calculated. For example, all international calls may come to $50.38. This may then qualify for 25 percent discount. The 25 percent is then calculated for each of the qualifying accounts. This may be apportioned to the earning account or may be redirected to a nominated account higher up the account hierarchy.

y

The single account actions summarized in "Billing Single Accounts," page 114 are also undertaken for each account, from the bottom of the customer account hierarchy upwards through to the top.

Figure 24 illustrates the application of Geneva discounts – an extension of the single account discounting mechanism – through a customer account hierarchy.

Attribute usage discount to nominated account Select all customers in the selected hierarchy

Select all accounts for each customer

Select all products for which a discount applies

Calculate total discount applicable

Calculate discount for usage for each account Owning account

Apply filters

Calculate discount

For each usage discount As for a single account

Figure 24 Discounts in a Hierarchy

Invoice Numbering Geneva supports three invoice numbering systems, which can be easily integrated into a number of other mechanisms. The systems are: y

Account-based invoice numbering – invoice numbers are allocated sequentially within each account. Invoice numbers are independent across accounts.

y

Sequential invoice numbering – invoice numbers are allocated sequentially across multiple accounts.

y

Custom invoice numbering – invoice numbers are allocated via a customizable application programming interface (API). This supports other invoice numbering mechanisms.

If sequential invoice numbering is in use, an invoice register is used to allocate th e invoice numbers across accounts. Invoice registers are assigned to each invoicing company. More than one register can be used at a time and each register can be reset if required. Thus, invoice numbers can be sequential for all accounts within one or more invoicing companies, if required.

116



Service Providers Geneva can bill where the operator is not the only service provider. Products and services can be supplied transparently as part of the Geneva operator’s offerings, or under the providers’ own brand name(s). Either the service provider or the Geneva operator owns the credit risk. Payments can be collected and collections chased by either the Geneva operator or the service provider. Geneva Service Provider Dispatch allows rated events generated by the service provider’s customers to be passed directly to the service provider for them to invoice. The products supplied to the end customers are assigned to the service provider, who is invoiced for the usage. Service providers are modeled within Geneva as invoicing companies. This allows company details (including VAT registration) to be individually defined, and the service provider can be billed or refunded like any other customer. Service providers can own holding accounts into/from which automatic payments can be made.

Billing Windows When you configure an invoicing company, you can specify a billing window. This allows you to generate bills for a specific period of time beyond the regular billing period. Thus, Geneva operators can bill customers in advance for any future charges. This window can be defined by the number of days, weeks, or months. You can also specify if billing should synchronize with a particular date (for example, always bill from the 5th of the month to the 4th inclusive) or with the next bill date for the account. This functionality does not change the definition of the tax point date, only the definition of the date on which a charge becomes due (billable).

Product End Dates Geneva provides the ability to set an end date for a product to a date earlier than the last bill date – any amount invoiced for that period is refunded on the next bill. Thus, if you realize that you should have terminated a product two months ago, corrective invoicing can be activated. Optionally, if a product has an end date within the bill in advance period, the advance charge can be prorated. Geneva recognizes that the product has ended and proceeds to bill to that point. In the event that customer product details relating to charges already billed for are found, Geneva refunds and recharges as appropriate using the updated product details.


117


Control Over Which Accounts are Billed Geneva affords the user full control over which accounts or customers are billed when the billing process is run. It is possible to run the billing process and restrict it to bill only those customers or accounts that fall into a user-definable cate gory, such as accounts belonging to a particular credit class or accounts formatted with a particular bill style.

Bill Suppression Geneva can stop bills for zero monies being sent out by suppressing bills for accounts with zero activity. An account has zero activity during a bill period if it has no product charges, event usage, discounts applied, or adjustments applied. A user-definable Bill Suppression plug-in allows Geneva users to determine the algorithm used to suppress bills.

Bill Cancellation and Rebill Geneva allows cancellation and subsequent rebill of the last bill for an account. Bills can be cancelled either for a single account or for an entire billing hierarchy. However, this cancellation is limited to the most recent bill produced – earlier bills cannot be cancelled.

Test Bill Run Geneva provides the user with a facility to perform test bill runs which produce formatted bills but leave the database unchanged. The ability to perform a “what if” bill run is particularly useful to the Geneva operator, for example, in situations where significant changes have been made to the billing catalog or to the bill templates. The test bill run generates the bills in the normal way, writes the bill data out to the user definable test bill directory and leaves the database unchanged. The Billing Engine outputs a tag in the bill data to indicate that the bill data is test. The test formatting run processes all bill data files in the test bill data directory and formats them with the correct template for each bill. The bills can then be analyzed.

Bill Styles Geneva allows the creation and maintenance of multiple bill styles. The availability of products is restricted to those products associated with the bill style of the account. The Billing Engine will output the bill style information in the bill data along with the bill content information.

118



Bill Data Customization In cases where additional information is required on the b ill that is not contained within the standard bill data as output by the Billing Engine, rapid customization may be carried out within the Geneva managed file environment. Modifications made by customizations do not override the original bill data; instead it is possible to audit the progress of bill data through the system using System Monitor.

Invoice Total Rounding Geneva operators adopt various strategies in order to ensure they receive maximum revenue for their services as quickly as possible. One such strategy is to round invoice amounts in order to simplify the amount due and to aid customers with payment. For example, in some countries small coins are scarce and customers frequently pay their bills in cash over the counter. In order to make such payments simple, a Geneva operator may charge their customers an integer amount in whole currency units, such as $511 rather than $511.45 or $512 rather than $511.55. The rounded amount is stored in the Geneva database (against a particular revenue co de, if required) as the “real” invoice total, so that the rounded total rather than the unrounded total is displayed in user applications and reports and used for account balance calculation and collections purposes.

Event Subtotals Geneva calculates and outputs event-related subtotals to display on the customer’s bill. These subtotals can be calculated using minor currency and the tenth of a minor currency.

Marketing Messages Geneva provides support for an unlimited number of marketing messages to be defined and output on a single bill. Default messages for the bill may be defined which will be used unless expressly overridden, in which case a customer-specific message will be output.

Bill Inserts Geneva supports the inclusion of bill inserts by third-party bill formatters if required. These can be set up to only be sent if: y

The bill is of a particular type.

y

The bill is sent between certain dates.

y

The bill is between certain monetary limits.

y

They have not been sent more than a fixed number of times before.


119


Copy Bills Geneva allows you to: y

Send copies of a bill to any number of additional parties for information purposes. These are referred to as copy bills.

y

Resend a bill to support situations where the customer did not receive or lost their original bill. These are referred to as reissued bills.

Copy bills are produced at the same time as the master bill as part of the same bill run. It may be in a different language to the master. Reissued bills are repeat versions of the master bill, produced on request at a later date. For both reissued and copy bills, it is possible to nominate a contact, bill style, and bill handling code.

Bill Formatting Geneva allows the bill formatting stage to be undertaken by one of the following: y y

The Bill Formatting Engine. A third-party document formatting package.

RTF Formatting The Bill Formatting Engine is appropriate for print volumes of up to approximately 100,000 residential bills per month. For larger volumes, third-party packages that support volume printer formats such as Xerox metacode or IBM AFP are recommended. The selection of an appropriate package depends on many factors, including the technology used by the selected fulfillment house. Geneva allows different formatting engines to be used to format the bills of different accounts. For example, one customer could be billed using the Bill Formatting Engine, another by a third-party engine in order to receive their bill by e-mail. The Bill Formatting Engine produces a formatted bill in RTF from the following inputs: y

Structured text representation of a bill (tagged ASCII bill data) produced by the Billing Engine.

y

Rich Text Format (RTF) bill template, which can be specific to the account if required.

Bill Templates The layout and structure of a bill is completely flexible and may be changed by the Geneva operator. Bill templates can be chosen based on: y

120

Bill style – allowing different templates to be used for different customers or classes of customer.



y

Bill type – allowing different templates to be used for the different types of bill (initiation, periodic, final, etc.).

y

Language – allowing different templates to be used for different languages.

y

Payment method – allowing different templates to be used for different payment methods (direct debit, check payments, etc.).

Interface to Third-Party Formatting Third-party document formatting packages are typically used to format and print large volumes of documents such as residential bills. These typically use specialized high-volume printing protocols such as IBM AFP and Xerox metacode. There are a number of specialized print formatting packages available which support these high-volume formatting protocols. For larger print volumes and/or situations where the bill rendering is being undertaken by a third-party, Geneva allows the tagged bill data to be exported as a consistent, ordered set of ASCII data files with a control file. This process can be automated within Geneva. After a successful bill generation run, the tagged bill data can be exported, ordered by various criteria, from the system and transferred to the third-party formatting system or fulfillment house. If required, Geneva can also reimport viewable images of the bills that the external formatting system has produced. Geneva user applications will then be able to launch the correct viewing programs to help resolve billing queries by giving access to the bill image.

Payments and Collections Geneva provides a full range of payments and collections functionality. Geneva provides two different accounting methods (the Geneva operator decides which accounting method will be used on an account by account basis): y

Balance forward, which supports budget payment plans.

y

Open item, which allows payments to be allocated to individual invoices.

Balance Forward Accounting Using this method, if a number of invoices are outstanding, payments received are allocated to invoices according to the age of the receivable, with the oldest invoice being created first.

Open Item Accounting This method allows payments to be allocated to specific invoices. This can either be done manually or via the volume processing applications. In the latter case the system will search for an invoice matching the payment. Where this does not exist, the payment will


121


be flagged to be resolved manually. Daybook and receivables reports and online screens will show unallocated payments. Where a payment cannot be allocated it is held against the account as unallocated cash. Open item accounting is particularly useful when dealing with payments from business customers. It has the advantage that where several invoices are involved, a payment which does not relate to the oldest invoice will not be allocated incorrectly across several invoices.

Bill Receivables Geneva allows the Geneva operator to allocate payment to a whole invoice, or alternatively, calculate separate subtotals on a bill for different types of charge (depending on the service and who has provided it), and allocate payments to these subtotals (bill receivables) instead. All charges within Geneva (for example, events and initiation charges) have a receivable class. A bill receivable is the total of all charges having the same receivable class on an invoice. A bill receivable is treated as a separate item for billing and payment purposes. If payment is allocated to a whole invoice all charges are deemed equally important when it comes to receiving payments from the customer, only the age of receivables is relevant. However, by dividing a bill total into separate bill receivable amounts, it is possible to assign a different priority when it comes to allocating a customer's payment. There are four possible options for payment allocation: y

No payment allocation.

y

Payment allocation to receivable class only.

y

Payment allocation to bill only.

y

Payment allocation to bill and receivable class.

The following are business scenarios in which different charges may have a different priority or be treated differently when it comes to allocating a customer's payment: y

Partial Withdrawal of Service.

y

Regulated Service Provider Relationship.

y

Contractual Service Provider Relationship.

Priority Payment Allocations for Bill Receivables Geneva can use an optional receivable class priority to automatically allocate payments against bill receivables. In this case, the bill receivable with the highest receivable class priority is allocated payment first. If the bill receivable spans multiple invoices, the oldest bill receivable is paid first. If an invoice contains more than one receivable class with the same payment priority, a payment is prorated across the bill receivables for these receivable classes.

122



Payments Geneva provides a comprehensive set of alternative methods for the input of payment details: y

Individual entry, for “one-time” payments.

y

Batch entry, for rapid entry of checks, etc.

y

Electronic file transfer, for details from Lockbox services, etc.

y

Automatic payments via payment requests, such as direct debit and credit card payments.

Payments can be credited to an account’s: y

Balance – to reduce the receivables on the account.

y

Deposit – to increase the deposit held.

Monies can be transferred between the balance and deposit at any time in an account’s life cycle. Geneva can calculate separate subtotals on a bill for different types of charge and allocate payments to these subtotals (bill receivables).

Payment Requests Geneva supports a standard payment request format (PRF) for all the payment requests it generates. This PRF is flexible enough to support all forms of electronic payment request including direct debit, credit cards, and debit cards. Geneva then interfaces with any bank solution by employing a post-processor that converts Geneva’s payment request data files to the format required by the third-party application prior to import. Geneva uses a volume processing application called PR Write to produce files containing payment/refund requests for export. Once a file has been successfully exported PR Complete will create the corresponding payments (and refunds) in the database. PR Complete will reset the payment request to awaiting processing in case of the export failing.

Automatic Payment Authorization Instructions Geneva supports the capture of automatic payment authorization details via Customer Account Maintenance. The capture of automatic payment authorization details may optionally automatically trigger the generation of a request to submit an automatic payment authorization instruction. This facility is configurable at the payment method level. As for payment requests, Geneva supports a single file format for the import and export of automatic payment authorization instruction data.


123


Bank Accounts, Payment Systems, and Payment Methods The Geneva operator may have multiple bank accounts into which it will receive payment. These bank accounts are referred to as holding accounts. Geneva supports multiple holding accounts per instance. Capture of holding bank details is done via System Configuration. Geneva supports multiple payment systems (such as BACS and BIDDS) within a single instance in order to enable a Geneva operator to function across countries from the same instance of Geneva. Geneva supports the association of multiple payment methods per account such as direct debit or credit card. Each payment method can be associated with a holding account and a payment system. The default payment method is that held in the account details record.

Lockbox and Other Electronic Payments Geneva provides a generalized, automated electronic payments interface. This allows payment files to be imported and allocated against the re levant accounts. Like all Geneva volume processing applications, this can be scheduled to run automatically or on demand as required. Any type of electronic payment can be processed through this file-based interface. For example, Lockbox, standing orders, bank Giro payments, and post office payments.

Matching Automatic Payments to Invoice Numbers Geneva allows you to match payments by invoice number and allocate payments that are automatically entered to intended invoices. For example, Geneva generates an invoice requesting payment, the customer receives the invoice and submits a payment, then the payment received is automatically allocated to the correct invoice. If a payment is less than or equal to the invoice amount, the entire payment is allocated to the invoice. If the payment is greater than the invoice amount, the excess is categorized as unallocated. This functionality does not apply to balance forward accounts.

Manual Payments Geneva provides user applications to allow individual payments to be recorded for a selected customer and account.

124



Geneva also provides a manual volume processing payment mechanism that allows batches of check payments with an associated checksum total to be entered.

Physical and Account Payments Geneva’s payment model differentiates between a physical payment and an account payment: y

Physical payments – these are physical transfers of money between a customer and the Geneva operator, either automatically (for example, collection by direct debit) or interactively (for example, by the customer sending a check).

y

Account payments – these are the application of funds to an account within Geneva.

Each physical payment must be applied. When a physical payment is applied, one or more account payments are created and lodged against the customer’s account(s). Refunds to the customer ’s account(s) are applied in the same way. Each physical payment creates at least one account payment. However, account payments can be created independently of physical payments. An account payment can also be the result of transfers of cash between accounts, application of a deposit or a manual write off of receivables. The Geneva operator can match payments by payment value or by invoice number. One physical payment may create several account payments if it is manually applied. In the case of a customer hierarchy, for example, a single payment made by the customer to the Geneva operator may be applied to any of the customer’s accounts within the hierarchy. It is even possible for account payments across multiple accounts to be in different currencies and have different payment classes.

Deposits When a customer pays a deposit to the Geneva operator, the physical payment is allocated to the customer’s account with a payment class of “deposit” and held until such time as it gets applied to the account balance. The deposit has no effect on the account balance until it is applied. Cash can be applied from the deposit a s an account payment to the balance, or transferred from the account balance (unallocated cash for open item accounts) to the deposit. This allows for a variety of deposit handling systems. For example, deposits can be applied as payments after a trial period, or deposits can be increased to cover extra liability when a customer takes additional products on an account. The application of a deposit may be either manual or automatic. A user with appropriate privileges may manually apply part or all of the current deposit to the account balance at any time. Alternatively, the full deposit may be auto-a pplied to the account balance when the account is terminated.

Failed Payments Geneva provides a generalized, automated failed payments interface.


125


Files of failed payments can be imported through the standard Geneva im port mechanism and registered against the appropriate accounts. Like the payment interface, any type of electronic failed payment can be processed, such as BACS failures, rejected credit card payments, and returned checks.

Refunds Geneva provides a standard mechanism for making refunds. A refund is defined as monies paid back to the customer, either automatically (such as direct deposit) or interactively (such as by sending a check). All refunds that have been made may be viewed in the Geneva user applications. Additional refunds may be entered and any refund details entered in error can be cancelled. Geneva also provides the capability to make refund requests. The system will support the automatic generation of electronic refund requests by the billing process. This automatic generation of refunds is optional and configurable at the payment method level. The Geneva operator may define maximum and minimum limits for the automatic generation of a refund request. Geneva user applications provide screens to review, edit, and cancel refund requests that have not yet been processed.

Suspense Account Geneva allows an account to be set up and nominated as the suspense account for payments. If payments cannot be registered against their true account for any reason, they will be loaded and registered against the nominated suspense account. Authorized Geneva users may then investigate the payment and rectify the situation once the true destination account is identified.

Budget Payment Plans A budget payment plan allows a customer to pay a regular amount every month (or other period) towards their bills, rather than paying each bill separately. The plan specifies the payment method to be used (typically direct debit or credit card) and the rules for calculating the payments. The amount being paid is reviewed periodically and adjusted according to the current outstanding balance and expected spend over the coming review period. A damping factor may be used in this calculation to prevent unnecessarily large changes to the amount being paid. The expected spend may also be adjusted by a percentage to allow for price changes. Unscheduled reviews will be triggered at billing time if the amount outstanding on the account exceeds a specified multiple of its credit limit. A budget payment plan may also have discounts associated with it – any account on the budget payment plan will receive the discount against each invoice. The discount may be specified as a percentage or a fixed amount. The level of discount may also be specified to depend on the invoice value.

126



Prepaid Accounts Prepay services in the telecommunications market were originally targeted at credit-challenged customers. As a result, the services that are currently offered with prepay are fairly limited (such as voice and SMS only). Geneva’s convergent prepay allows the same services to be available whether a customer pays in advance or receives an invoice later on – thus, prepaid or postpaid becomes a payment choice rather than a difference in service. Even if all accounts are set as prepaid, it is still necessary to run the billing process to: y

Update revenue totals.

y

Calculate tax and update tax totals.

y

Optionally produce prepay statements.

Both prepay and postpay customers can interrogate their balance whenever they like and use this information to control their spending. Actions triggered by the crossing of balance thresholds can prompt the customer to review usage levels. Additionally, prepay customers can make incremental additions to their available balance in the form of top ups. A key feature of prepay is the ability to produce a single bill/statement for both prepay and postpaid services. The postpaid part may be an invoice while the prepay part is a statement of usage and payment topups.

Example Figure 25 shows a family scenario in which both prepaid and postpaid accounts are mixed.

Credit/Debit Card Dad Lisa

Chris Postpaid Account Payment Interface

$ Top-Up

Fiona

Balance Query

Mum Prepay Account

Prepay Account

$ Non-recurring Transfer

$ Monthly Payment

Figure 25 Family Scenario, Prepay and Postpaid Accounts.


127


In this example Lisa and Fiona share an account that is credited on a monthly basis by their parents. The monthly payment is added to the parent’s postpaid invoice. Chris tops up his own prepay account using his debit card and occasionally has a non-recurring top up from his parents. All of the prepay account holders can query their available balance.

Suspended Accounts Accounts can be suspended so that if, for example, a customer moves abroad for six months and wants to recommence service upon their return, the account can then be reactivated. A bill can be sent to cover any remaining charges and no other bills are generated until the customer’s account is made active. An account suspension can be: y

Open-ended from now.

y

From now until a specified date.

y

Open-ended from a specified date.

y

Within a specified date range.

Account suspension also defines a period for which billing will not be performed (although a periodic charge can still accrue). For information about suspending products, see "Customer Product Status," page 102.

Conditional Settlement A merchant can supply services for which the Geneva operator bills the customer and collects payment. Geneva allows for the settlement of monies owing to merchants conditional on the customer having paid for the merchant’s services. Geneva provides the data to enable conditional settlements with merchants. Geneva does not provide the processes to carry out the merchant settlement. To administer conditional settlement a Geneva operator can classify merchant products into receivable classes. All revenue including discounts and adjustments can be allocated to the appropriate receivable class. This allows the revenue for a particular merchant to be monitored and reported on. The agreement between the Geneva operator and the merchant specifies a calendar that schedules settlement periods which defines a period of time for which the settlement amounts agreed for the merchant’s services will be reported on and settled. The customer spend (including disputes and adjustments) during a settlement period is termed a settlement bucket . The settlement bucket contains information on: y

Amount spent by the customer over the settlement period (including any discounts but excluding any taxes applied by Geneva).

y

Any outstanding disputes.

y

Any adjustment made. The use of settlement periods allows bucket totals to be managed in agreed timeframes, instead of bill sequence.

128



Each settlement bucket has a corresponding settlement payment bucket . It is this settlement payment bucket that payments are allocated to when a customer pays their bill. The payments for each of the buckets are settled in chronological order, in other words when a customer pays their bill the oldest settlement bucket with monies owed is allocated payment first, then when the corresponding settlement payment bucket is fully paid, the next bucket is used. A settlement bucket is full (that is, paid up) when the amount in the corresponding settlement payment bucket is equal to the amount in a settlement bucket (including disputes and adjustments). The settlement bucket and settlement payment bucket information can then be exported to external systems such as general ledger applications or data analysis applications. Payment to the merchant will be made on the content of the settlement payment buckets only (that is, only after the customer has paid the Geneva operator). Geneva also manages the settlement buckets so that following the application of “late” charges or “late negative” charges payments are re-allocated effectively. At the end of the settlement period the Geneva operator can pr ovide a report to the merchant indicating the value of the settlement bucket, that is, the amount of events billed to customers that month, the product charges, adjustments, and any disputes. This report can then be used as the basis for settlement. Geneva operators may require support with regard to managing settlement relationships between themselves and merchants. The following business models are supported by Geneva using a combination of multiparty events and settlement buckets: y

Bank model – Geneva operator operates as a “payment method” for transactions involving the merchant’s services. Thus, the merchant offers a service, and defines the pricing including tax.

y

Wholesale model – Geneva operator purchases products/services from the merchant at a wholesale rate. In this model the Geneva operator only purchases from the merchant when the consumer purchases, therefore minimizing risk for the Geneva operator.

Example Consider the following scenario: y

The merchant provides a service and agrees to a settlement calender that specifies monthly settlement periods starting on the first of the month.

y

The customer takes this service on January 1 and is billed quarterly on the 20th of the month (starting March 20). A direct debit pays the bill in full on the 14th of t he following month.


129


Table 8 describes the customer spend on the merchant product over six months and how that spend is allocated to settlement periods: Example Settlement Buckets

Table 8

Settlement Bucket 1

Settlement Bucket 2

Settlement Bucket 3

Settlement Bucket 4

Settlement Bucket 5

Settlement Bucket 6

Dates

Jan 1-Jan 31

Feb 1-Feb 28

Mar 1-Mar 31

Apr 1-Apr 31

May 1-May 31

Jun 1-Jun 30

Spend

$30

$25

$40

$40

$25

$35

The settlement payment buckets are empty until payments are allocated following payment. A bill of $85 is sent on March 20 and another for $105 on June 20. It should be noted that these bills do not represent three settlement periods as these are completely independent of the billing period. After the direct debit pays the bill in full on the 14th of the month, the payments are allocated by Geneva to the settlement payment buckets as shown in "Example Settlement Payment Buckets," page 130. Example Settlement Payment Buckets

Table 9

Settlement Payment Bucket 1






April 14

$30

$25

$30

-

-

-

July 14

-

-

$10

$40

$25

$30

Note that $5 is outstanding on settlement payment bucket 6. The next payment will be applied to this bucket first.

Aging Receivables The Geneva receivables aging process is closely related to the collections process (see "Collections," page 132). Receivables aging: y y

Ages the receivable for each account. Checks the collections schedule to see if any collections actions are now due and, if so, creates the necessary action requests.

The collections schedule for an account is determined by the credit class that the account has been assigned. Collections schedules are discussed in "Collections Schedules and Actions," page 132. Additionally, receivables aging can take holidays into account. For example, if a collections schedule determines an action that will occur on a holiday, the action date can be incremented to the next non-holiday day.

130



Geneva distinguishes between total and net receivables. Both forms are calculated and held by Geneva.

Payment Due Days Payment due days are used to calculate the payment due date shown on a customer's bill. Payment is shown as being due n days from the bill production day (where n is configurable), or n days from the end of the month of the actual bill date (wher e, again, n is configurable). This makes it possible to define a payment date as being, for example: y

Due 7 days from the end of the month.

y

Due 25 days from the date of the invoice.

Geneva allows you to set up payment delay day schemes and provides a mechanism to allow a choice of when the collections process starts. For example, in some countries, an invoice amount is considered as receivables the day after the invoice is produced. In other countries, an invoice amount is considered as receivables the day after the payment due date, set as a number of days after the invoice is produced. These payment due days are negotiated with each customer as part of the payment terms. The payment due days can be specified in number of days or they can be specified using formats such as “the end of month in which the invoice is sent, plus n calendar days.” In some countries, state and local holidays must be taken into account when calculating payment due dates. Geneva allows the operator to set up holiday profiles in which particular dates, for example, January 1, are nominated as holiday dates and certain days are nominated as weekend days, for example, Sunday. Days set up in a holiday profile can then be excluded when calculating the payment due date.

Total Receivables The total receivables for a particular account is the total amount owed by the owner of that Geneva account, regardless of any current disputes.

Net Receivables Net receivables are the amount of monies owed for a particular account that can legitimately be chased for that account. This is given by: The total receivables minus pending disputes minus adjustments in the customer’s favor not yet billed minus payments already scheduled for automatic collection.


131


Aging Receivables and Budget Payment Plans Accounts paying by budget payment have a different definition of net receivables to other accounts as it is the expected budget payment that creates the net receivables, rather than the invoices. The net receivables for budget accounts is the difference between the expected budget payments and the actual payments. This is summarized at the account level and translated into a number of complete payments in arrears for re porting purposes. The calculation of the total receivables and associated age of receivable(s) is the same for budget accounts.

Collections The collections process ages the collections for an account, checks the collections schedule to see if any actions are now due and, if so, creates the necessary action requests. Geneva supports dunning (receivables chasing) both at the invoice level where receivables are chased on an invoice by invoice basis or at the account level whereby all overdue amounts for an account, across several invoices, can be handled by a single dunning action. For example, where that action is to send a dunning notice, the dunning process will output data to the dunning notice relating to all the receivables for an account. The dunning model to be used for an account will be assigned on the basis of its credit class. The association of dunning model with credit class is managed via System Configuration. A collections schedule provides a flexible means to define mandatory and optional actions that will occur once the receivable has reached a defined age and exceeds a specified amount. The actions may be Geneva actions or may be undertaken by an additional integrated system.

Credit Classes All Geneva accounts must be assigned to a credit class. Geneva allows any number of credit classes to be defined. The credit class defines whether an account uses invoice or account level dunning and which collections schedule is to be applied to the account, should its owner fail to make the (undisputed) payments that are due. Using this approach, the customer database can be segmented, so that different receivables chasing regimes may be defined and assigned to different classes of customer.

Collections Schedules and Actions The collections schedule specifies the series of stages that make up the collections process. For each stage, it covers: y

132

The effective age that the receivables have to be for an action to take place. The effective age of receivable is calculated by taking the actual age of receivable (the number of days between the bill date and today’s date) and subtracting a number of



modification days. The number of modification days can be set up for individual bills thus allowing you to relax or tighten the collections action depending on individual circumstances. y

The holiday profiles to be applied to aging of receivables. Geneva allows the operator to specify whether any holiday days that fall after the collections start date and before the date on which age of receivables is calculated should contribute to the actual age of receivables. In the event that the collections date falls on a holiday day it is possible to extend the collections action to the next non-holiday day.

y

The action to be taken. This might be an action that Geneva is to perform, for example sending out a dunning notice. As with bills, the form and content of the dunning notices may be defined by the Geneva operating company (see "Dunning Notices," page 133). Alternatively, it can be a request for a system that is integrated with Geneva to perform an action, such as requesting customer services to telephone the customer.

y

Whether or not the action is mandatory. If an action is mandatory, subsequent actions cannot take place until this one has been performed. The action may be realized by Geneva itself or a third-party system that has been integrated using the Geneva collections schedule APIs.

y

The minimum receivables amount below which the action will not take place.

For account level dunning, the collections action to be taken is dictated by the collections trigger for the account, that is, the oldest collections over the minimum chase amount for the relevant collections stage. The receivables against which the collections action resides is known as the collection trigger and is identified as such on the dunning notice. If an account on the open item accounting method has unallocated cash, collections actions will be held for review. They can subsequently be cancelled or approved.

Dunning Notices In the early stages of the collections process, the action will typically be to send a number of dunning notices – reminder letters and requests for payment. Geneva allows any number of dunning notice templates to be defined. Each collections schedule will specify which one to use at various stages of the collections process.

Interfacing to External Systems After a number of dunning notices have been sent at various stages, other actions are typically scheduled. For example, you can specify that a customer services representative (CSR) should telephone the customer to ask why they have not paid. Such an action can be requested and achieved by integrating the Geneva action request with the outbound work queue for a class of CSR. Even later in the process, you can set an action for the provisioning system to redirect the customer’s outbound telephone service to the Geneva operator’s help desk.


133


Accounts Receivable Accounts Receivable provides the user with a company-wide view of receivables across all Geneva accounts. It allows the Geneva operator to assess the total of all receivables across all accounts by a range of criteria: y

Outstanding receivables on accounts exceeds a specified amount.

y

Oldest element of receivables exceeds a specified number of days.

y

Outstanding receivables which are older than a specified number of days exceeds a specified amount.

y

All accounts for a single customer.

y

All accounts for a customer hierarchy.

y

All accounts with active disputes.

The information retrieved may be sorted as required and is available: y

On screen for interactive analysis.

y

As electronic files for further analysis with standard financial assessment and manipulation tools.

y

As paper reports.

Using the company-wide view of receivables, and by selecting the required criteria, the Geneva operator can identify individual accounts that have contributed to that receivable’s position. A comprehensive summary of each account’s receivables is provided with the ability to drill down to view the account details and even the invoice by invoice breakdown if required.

Revenue Assurance Geneva provides event revenue assurance safeguards to help the Geneva operator to minimize revenue loss due to faulty business processes and systems. Geneva maintains, per account and invoice combination, a running total of both the number and value of unbilled events. When events are loaded into Geneva, they have to be registered against totals for the relevant account and invoice combination. When this is done, the unbilled count is incremented, as is the total unbilled value. When accounts are billed, the number of events and their value is deducted from the respective running totals. If the counter does not return to (logical) zero in either case, then Geneva will post a warning message to the billing log files for that billing run and this will be indicated in System Monitor. The counters may not return to zero under certain account set up conditions if a billing run is delayed – Geneva allows for these situations and only posts warnings for true revenue assurance exceptions. Also, Geneva can optionally keep a record of all events going into and out of the Active Rating Engine(s).

134



Reporting Each of the Geneva user applications provides access to a number of standard reports. Geneva reports are produced using Seagate Crystal Reports. As Geneva is an open system and provides a published schema, additional user-written reports may be added and configured to appear within the Geneva applications. Geneva reports allow output to be directed to hardcopy, various standard file formats or to the screen. Geneva does not mandate that Seagate Crystal Reports is used for reports written by the Geneva operator. Other standard reporting tools may be used if preferred.

Scheduled Reports There are two main aspects to the scheduling requirements of reports within Geneva; those involving large volumes of data and/or complex reporting requirements. For complex reporting requirements, Geneva splits the reporting into two parts. The first derives and calculates the data and stores it in the Geneva Oracle database. These operations are complex and require significant processing. Such activities are an integral part of Geneva, are provided as standard volume processing applications, and may be scheduled to run as frequently or infrequently as required through System Monitor and Task Master. Aging of receivables falls into this category; the receivables on all Geneva accounts is aged regularly (scheduled as required) and run on the server machine. The second part of the complex report is the presentation of the information. This is undertaken by Seagate Crystal Reports, which runs on a client PC under Microsoft Windows 2000 or Microsoft Windows XP. Seagate Crystal Reports itself provides scheduling capabilities. If required, reports such as those provided with Geneva and others added to the set can be scheduled to run at defined times, so that the report output is produced for printing/display at a later time. Geneva allows these capabilities and those of other, comparable reporting packages to be used.

Financial Reports The reports provided that detail the financial aspects of Geneva include: y

Customer Information.

y

Customer Product Price Overrides.

y

Customer Event Price Overrides.

y

Contract Terms.

y

Contract Summary.

y

Aged Debt Analysis (30, 60, 90 days, etc.).

y

Account Balance.

y y

Sales Daybook. Account Payments Daybook.


135


y

Account Payments Statement.

y

Linked Payments Statement.

y

Physical Payments Daybook.

y

Physical Payments Statement.

y

Accruals.

y

Accruals Summary.

y

Prepayments.

y

Prepayments Summary.

y

Revenue Daybook.

y

Revenue Daybook by Account.

y

Revenue Daybook by Customer.

y

Revenue Summary.

y

IAA Report.

y

Adjustments Daybook.

y

Adjustment Summary by Adjustment Type.

y

Adjustment Summary by Revenue Code.

y

Disputes Daybook.

y

Dispute Summary by Revenue Code.

y

Rating Revenue Assurance.

y

Open Item Account Statement (this report provides a one page statement for each customer detailing invoices issued and payments received).

All reports that involve presentation of currency amounts are partitioned by currency. It is possible to produce each report for a single user-specified currency or for all currencies.

Management Reports Geneva provides summary informational reports relating to customers, accounts, their products and services, and their historic spend. Individual accounts, customers, customer hierarchies, and the complete customer base can be reported. Inevitably, specific management reporting requirements will require extensions and/or additions to these reports. Geneva allows additional reports to be written and configured to appear on the reporting menus of the user applications – which ones and which users have access to them may be configured on a report by report basis.

136



Catalog Reports Geneva provides two different classes of report for each of the rating and billing catalogs. These are used as an integral part of the design process fo r the data relating to billing and rating. They allow: y

Details of the (rating or billing) catalog for a user-supplied date to be displayed.

y

Details of the changes to a (rating or billing) catalog between two user-supplied dates.

Geneva also produces a Catalog Validation Report. This provides details of any errors encountered by the validation process for a billing or rating catalog.

Rating Catalog Reports This section lists the reports that have been developed to complement Rating Catalog Maintenance. In general, there are two types of reports: y

Detail reports that define the attributes in force on a specific date.

y

Change reports that define the changes in attributes between two dates.

The rating catalog reports summarize, for a given date, the rating catalog information in the following areas for a single rate plan or for a whole rating catalog (that is, many rate plans): y

Cost Group Definition Details.

y

Cost Group Definition Changes.

y

Cost Group Cross Reference Details (shows the cost code group and cost band associations in operation on a given date for a specified combination of rating catalog, rate plan type, and cost group).

y

Cost Group Cross Reference Changes.

y

Ungrouped Cost Code Details.

y

Ungrouped Cost Code Changes.

y

Time Rate Diary Details.

y

Time Rate Diary Changes.

y

Event Class Details.

y

Event Class Changes.

y

Charge Segment Details.

y

Charge Segment Changes.

y

Costing Rules Details.

y

Costing Rules Changes.

y

Tariff Details.

y

Tariff Details Changes.

y

Tariff Bases (displays price plan details applicable on a given date, for specified combinations of rating catalogs, price plan types, and price plans).


137


y

Tariff Bases Changes.

y

Tariff Summary (displays a summary of price plans for given rating catalogs and rate plan types).

y

VH Band Map (shows the values of configured distance bands and their corresponding cost bands).

Billing Catalog Reports This section lists the reports that have been developed to complement Billing Catalog Maintenance. In general, there are two types of reports: y


y


The billing catalog reports summarize, for a given date, the billing catalog information in the following areas for a specified billing catalog: y

Tariff Hierarchy.

y

Tariff Hierarchy Changes.

y

Discounts.

y

Packages.

y

Packages Changes.

y

Bonus Schemes.

y

Redemption Options.

y

Redemption Option Changes.

y

Payment Methods (and associated discounts).

y

Payment Method Changes.

y

Budget Payment Plan Details (and associated discounts).

y

Budget Payment Changes.

y

Revenue Codes.

Each report allows subsets of the information to be output. These reports are available for all billing catalogs, including the live catalog.

Product Configuration Reports This section lists the reports that have been developed to complement Product Configuration. In general, there are two types of reports: y


y


Geneva provides the following product configuration reports: y

138

Packages.



y

Package Changes.

y

Product Hierarchy Details.

y

Product Hierarchy Changes.

System Monitor Reports This section lists the reports that have been developed to complement System Monitor. The reports provided include: y

Duplicate Event.

y

Duplicate Event Summary.

y

Service Request.

y

Terminated Accounts.

y

Accounts.

Configuration Data Transfer Reports This section lists the reports that have been developed to complement Configuration Data Transfer. The reports provided include: y

CDT (Configuration Data Transfer) History.

y

CDT (Configuration Data Transfer) Table Sets.

Product and Pricing Edits Transfer Reports This section lists the reports that have been developed to complement Product and Pricing Edits Transfer. The reports provided include: y

History of Edits.

y

History of Exports.

y

History of Imports.

y

Details of Import Edits.

y

Conflicts in Import Edits.

System Configuration Reports This section lists the reports that have been developed to complement System Configuration. The reports provided include: y

Business Roles.

y

Site Sequences.


139


Ad Hoc Reporting and Analysis Geneva allows any standard RDBMS reporting tools to be used. This allows sets of data to be extracted from the Geneva database for further analysis. The needs of one Geneva operator versus another cannot be predicted – Geneva allows full read access by the Geneva operator to their information for manipulation and interpretation. CSV, text, common spreadsheet formats, hardcopy, etc., are all supported.

Interconnect Accounting Agreement Interconnect billing is often used to describe two separate activities: y

Interconnect billing – the production of invoices to send to an interconnect partner relating to incoming interconnect call detail records (CDR).

y

Interconnect Accounting Agreement (IAA) – the reconciliation of invoices coming from an interconnect partner which relate to outgoing CDRs.

Both are supported by Geneva.

Interconnect Billing Geneva supports pricing of all incoming and outgoing interconnect CDRs as well as invoicing of inbound interconnect CDRs. Both cascade interconnect billing and account reconciliation are supported:

140

y

The Active Rating Engine and rate plan design utility fully support interconnect rate plan models such as the BT EBC network interconnection model. The Active Rating Engine can be used to rate all interconnect CDRs. Th is allows an interconnect price to be determined for both incoming and outgoing interconnect CDRs on the basis of the incoming or outgoing trunk interconnect route that carries the call.

y

To use Geneva to support interconnect billing, two separate accounts should be configured for each cascade interconnect partner; one each for incoming and outgoing CDRs. Geneva can then be used to rate all interconnect CDRs and register them against an appropriate account, for example, against BT-Inbound and BT-Outbound.

y

Geneva has been designed to accommodate large volumes of event data registered to a single customer account, as found in interconnect billing situations. The Geneva architecture allows swift access to the events asso ciated with a single account and allows sets of related events to be entered and removed in blocks.

y

Geneva can be used to invoice interconnect partners for delivery of inbound interconnect CDRs using the standard Geneva invoicing capabilities. A special invoice format can be defined and configured if required.

y

For reconciliation purposes, Geneva can generate the interconnect reports that are needed for the outbound interconnect CDRs. These reports summarize the time and cost by dialed destination. Interconnect events can be configured so that they are fragmented at rating time by time rate boundaries – this allows reconciliation down to the number of call minutes for each time rate. These reports can be saved as CSV files of IAA reconciliation data for use by other standard financial packages if required.



Interconnect Accounting Geneva provides reports facilitating reconciliation of outbound interconnect CDRs, that is, CDRs for which an invoice will be received. The formats of the reports are configurable and analyses are possible using a variety of factors such as call type, destination, cost band, and duration. Data can also be formatted for use by standard financial packages if required. A Geneva operator should configure two Geneva accounts for each cascade interconnect partner. One each for incoming and outgoing CDRs. Geneva can then be used to rate all interconnect CDRs and to register them against an appropriate account. The reports can then be run against each nominated outbound interconnect account. Once the reconciliation has been performed and is accepted, the outbound account can be invoiced and written off (as it is not invoiceable – it represents detailed CDR data relating to what the interconnect partner is going to invoice the Geneva operator). The Geneva operator may use the outbound IAA report data to reconcile the invoice they receive from their interconnect suppliers. At rating time, the Active Rating Engine can be configured to save event fragments for interconnect events. An event fragment will be written to the Geneva database for each time rate boundary that the event crosses. This allows reconciliation down to the number of call minutes for each time rate. The Geneva IAA report will allow the user to specify: y

Account number.

y

Start date.

y

End date.

The Geneva IAA report is flexible, and allows summaries to be produced of the events and event fragments for the nominated account. For example: For an account over a specified time period, summarize: y

Number of calls.

y

Duration of calls.

y

Value of calls.

By: y

Call type.

y

Destination.

y

Time rate.

Or: For an account over a specified time period, summarize: y

Number of calls.

y

Duration of calls.


141


y

Value of calls.

By: y

Call type.

y

Cost band.

y

Time rate.

Geneva has been designed to accommodate large volumes of event data registered to a single customer account, as found in wholesale and interconnect billing situations. The Geneva architecture allows swift access to the events associated with a single account, and allows sets of related events to be entered and removed in blocks. If required, the Geneva IAA reports may be used to create CSV files of IAA reconciliation data for use by other standard financial packages, such as spreadsheets, as part of the reconciliation process. For example, and to be taken solely as an illustration of the type of content (not presentation) that the report may include: Event type:

Outgoing interconnect calls

Account number:

1726385

Customer:

XYZ Telecom

Period:

1.1.2002 through 1.31.2002

Date:

1.1.2002 through 1.31.2002

Call Type

Cost Band

Time Rate

Number of Calls

Duration

Cost

Direct dial

Local toll

Daytime

17263

224:32:42

1423.436

Evening

18725

942:32:53

4623.426

Weekend

18372

1423:42:35

5565.818

SUBTOTAL

54360

2590:48:10

11612.680

Daytime

8964

134:02:19

785.392

Evening

12593

769:12:51

2637.917

Weekend

7666

812:56:38

3342.991

SUBTOTAL

29223

1716:11:48

6766.300

83583

4306:59:58

18378.980

Long Distance

SUBTOTAL

142



Call Type

Cost Band

Time Rate

Number of Calls

Duration

Cost

Operatorconnected

Local toll

Daytime

21543

318:24:09

2153.648

Evening

19834

1003:38:37

5186.537

Weekend

9928

687:13:53

2956.915

SUBTOTAL

51305

2009:24:39

10297.100

51305

2009:24:39

10297.100

134888

6316:24:37

28676.080

SUBTOTAL TOTAL


143


144


6

System Administration and Maintenance

Archive and Delete A number of processes are provided to assist with the archiving and deletion of records within the Geneva database.

Rated Events Events comprise the vast majority of Geneva’s data storage requirements. Consequently, the backing up, archiving, and deletion of events are performance-critical activities for which Geneva provides specialized volume processes. Geneva provides an event archiver which: y

Determines which day(s) events should be archived. The criterion for event deletion is n days after the event was billed, where n is a user-configurable system parameter. Geneva can also support early deletion of events (on demand deletion).

y

For each day to be archived it: o

Creates an ASCII archive file in a directory, defined by a Geneva system parameter. One file is created per day to be archived.

o

Creates archive record(s) in the database.

Geneva also provides an event deletion process. The Event Deleter deletes all events that fulfil the following criteria: y

The event has been archived.The event has been successfully backed up after the archive. This ensures that there is a backup of the archive file in case the archive file becomes lost or corrupted outside of the Geneva managed file area.

Rejected Events All rejected events, other than filtered events, are managed using Rejected Event Maintenance. Rejected events having the following status can optionally be archived and deleted using a specialized Geneva volume process: Processed


The event has been resubmitted and successfully reprocessed.

145


Discarded

The event has been discarded within Rejected Event Maintenance.

Filtered

The event was rejected as being a duplicate when Geneva started rating the event. These events cannot be seen within the Rejected Event Maintenance.

Rejected events can also be deleted n days after the event was last rejected (events can be reprocessed and rejected again), where n is a user-configurable system parameter.

Bill Images Bill images are the second largest consumers of space within Geneva. The amount of space consumed, however, varies significantly from case to case. For example, corporate and small-medium enterprise (SME) bills are usually not invoiced in detail, whereas residential/domestic bills often have full detail of all the individual events (such as telephone calls). Secondly, the amount of data is highly dependent upon the formatting solution being used. Geneva allows bill images to be held online, typically as files on a shared file server, to enable viewing via an appropriate program. References to bill image files may be imported into the Geneva database. When required, Geneva will launch the correct bill viewing program, providing a bill image exists. The Geneva operator is free to determine the location of bill images and how often and when they should be archived and deleted. Standard file mechanisms may be used for these functions.

Other Data Geneva retains all other data such as customer data, account data, and billing records online indefinitely. This data is extremely small in comparison to other data types. Old customer data and accounts do not affect the performance of Geneva. If preferred, old data may be archived from Geneva using database scripts.

Backup and Recovery Geneva may be configured in a number of ways including, if required, the use of mirrored disks. If separate dual-ported and mirrored disks are deployed, then backup may be undertaken from the second machine once the mirror is broken. On completion of the backup, the disk mirror is reconnected to the main machine and the disks resilvered. All such standard approaches to platform failure and the use of the additional machines and disks for backup may be used with Geneva. To this extent, Geneva is a standard application hosted on a standard platform allowing the use of standard backup mechanisms.

146


6 – System Administration and Maintenance

For a single machine installation, backup has to be undertaken at some point during each calendar day. This will typically be during the night, after the event rating and bill generation has taken place. The backup functionality is comprised of standard RDBMS and file backup mechanisms; consequently, it can be run at the same time as other volume processing applications are running (such as rating or collections). This is not typically recommended however, for performance reasons. Equally, the operator has the choice of full or incremental backups. As is always the case with such a choice, it is a trade off between speed of backup (where incremental backups are faster) against speed of restore in the event that it is needed (where full backups are significantly faster). As Geneva can be used as a key component of a full customer care services function, the ongoing availability of Geneva is extremely important, so the cost of a full backup during the night is a small price to pay for shortened restore times if such action is needed. Backing up of the Geneva Oracle database and Geneva managed file area should be carried out using standard Oracle administrator utilities and operating system routines.

Oracle Geneva provides complementary support to the Oracle and third-party backup processes by allowing the user to: y

Register the start of a backup.

y

Confirm the successful completion of a backup, and optionally to immediately run a post backup task (the archive/deletion processes).

y

Cancel an unconfirmed backup.

y

Record the recovery of the database using a particular backup.

y

Record free form notes against a backup log at any time (such as to store a tape number).

Managed Files Managed files are configured in System Configuration. Via the user interfaces, you can configure: y

File groups.

y

File types.

y

File subtypes.

y

File type and file subtype relationships.

y

File type and file group relationships.

The Geneva managed file system generates administration data in the Geneva database in order to control and log the transfer of files. Once the jobs that use the managed files are completed, the managed files are deleted from the system. The associated administration data in the database are then no longer necessary and are removed from the database.


147


The Geneva managed file system also holds transient data such as events. You can delete managed files that: y y y

Have been backed up. Are not in use by any job. Have not been used for a number of days, defined by a system parameter.

References to deleted managed files and managed files from which there are no references in the database can also be removed, as accumulation of unnecessary data can affect the performance of your system. Geneva holds file reference information within the Geneva Oracle RDBMS for each managed file; this ensures that Geneva always acts on a consistent and integral set of information. This means that the files and their associated content, although not held within the RDBMS, are referenced securely. As the Geneva information resides across the Oracle database and the managed file space, it is necessary to back up the Geneva Oracle database and the managed file space as a consistent and associated pair. This provides an integral set of backed up information. Geneva carries information in the Oracle database to ensure that the database and managed files do not get out of step. The Geneva database is always the definitive definition of the state of the data. Even if backups are not taken at the same time, Geneva will resolve inconsistencies between the managed file set and the database. It is possible for an orphaned managed file to exist without a database record – this is an acceptable situation and Geneva provides utilities to remove these orphaned files. It is not possible to have legitimate managed files that have no corresponding Geneva database record. Standard UNIX or file server backup tools should be used to backup the managed file space immediately after the database backup. Conversely, to restore a complete and integral Geneva system from a backup means that both the Geneva RDBMS backup and the associated managed file space backup must both be restored.

Installation and Configuration System Configuration Geneva provides installation scripts to set up the Geneva database. Country and locale information must be supplied at installation time. Further scripts are provided to set up examples of Geneva static reference data, UNIX environment variables, etc. Scripts are also provided to set up example transaction limits, for example. These may be used as is or adapted to meet the specific requirements of the prospective Geneva operator. Geneva also provides System Configuration. This is a graphical user application that allows the Geneva operator to configure and set some of the various parameters associated with the Geneva installation.

148



Example templates are also provided for each bill type, credit notes, and dunning notices.

Data Migration Utility In instances where it is necessary to transfer bulk data into Geneva, it is both time-consuming and wasteful of resources to have to enter the data manually. To simplify this process a utility is provided within Geneva which loads appropriately formatted data directly into the relevant Geneva tables. The File-based Database Updater enables the loading of data from various sources into Geneva using a specified intermediary data format. This functionality is included in the core product and the Geneva operator will be able to facilitate the import of external data via System Monitor using the File-based Database Updater functionality.

Upgrades Geneva releases always provide an upgrade script to migrate the schema and all data from the previous release to the new release. The upgrade scripts may be used in sequence if required. Geneva APIs are backwards-compatible with previous releases wherever possible and in the majority of cases.

Catalog Maintenance Catalogs in Geneva are not standalone entities. A catalog refers to a number of objects contained elsewhere in the Geneva schema. These objects include: y

Products.

y

Tax codes.

y

Revenue codes.

y

Event definitions.

y

Rate plans.

Geneva's catalogs contain all of the rate plan and price plan information for the products that have been defined in Geneva. A separate catalog may be defined for each invoicing company/currency combination. This means that the rate plans and price plans for each invoicing company/currency may be defined and managed independently. Catalogs progress through a life cycle as they are developed. Where they are within the life cycle is indicated by the state of the catalog.


149


Catalog Life Cycles A billing or rating catalog can exist in a number of states: Design

Catalogs in this state are editable in Billing Catalog Maintenance or Rating Catalog Maintenance.

Test

This state is used for testing new price plans and rate plans. Geneva validates a catalog to ensure that the data in the catalog meets certain tests.

Rejected

Catalogs enter this state if they are discarded, either directly from the design state or from the test state.

Deleted

This state is for catalogs that are no longer required – that is, those that have previously been rejected or superseded.

Live

Billing catalogs in this state are used by Customer Account Maintenance and the Billing Engine to maintain and bill products. Rating catalogs in this state are used by the Active Rating Engine to rate events.

Superseded

Live catalogsenter this state when they are replaced by a new version

Figure 26 shows the transitions between these states in the catalog life cycle.

150



Create, import or copy

Design

Demote

Reject

Promote

Test

Reject

Rejected

Publish

Live

Delete

Deleted

Delete

Supersede

Superseded

Figure 26 Catalog Life Cycle

For each currency, several billing/rating catalogs can exist in parallel. Each will have a status, which indicates where they are in the catalog life cycle. Several design catalogs may exist at any one time. Any of these can be edited within Billing Catalog Maintenance or Rating Catalog Maintenance, depending on the catalog type. When a design catalog is felt to be complete, it can be promoted, that is, converted from design to test state. From the test state, a catalog can be rejected completely, demoted back to the design state for further work, or published, that is, converted from test to live state. A catalog must be live, before it can be used to sell products to customers, bill customers, or rate events. Live catalogs may be viewed within Billing Catalog Maintenance (for billing catalogs) or Rating Catalog Maintenance (for rating catalogs); however, they cannot be altered. Only one live billing catalog per currency for each invoicing company may exist within the database. Therefore, when a test catalog is published, any existing live catalog for that currency and invoicing company is superseded.


151


Parallel Development Geneva’s rating and billing catalogs (and product configuration) can be edited by multiple users in parallel (using either the Geneva user applications or the Geneva stored procedures to perform the required edits). This means that the definition and maintenance of products and prices can be maintained by multiple, independent groups according to a Geneva operator’s business process (for example, a large Geneva operator may have several individuals or departments that are responsible for the maintenance of different components of the rating or billing catalog). Geneva manages the integrity of the pricing information by r equiring that all updates to the catalogs be performed on a design copy of a live catalog. Each user maintains their own design catalog, any changes to which are captured in delta files. Those delta files can then be applied back to a design copy of the live catalog (which may then be published). Figure 27 shows how this works in practice. Deltas must be applied to a design copy of a rating or billing catalog (that is, changes can not be applied directly to the live catalogs).

Live catalog

Design catalog (User 1)

Delta file (User 1)

Design catalog (User 2)

Delta file (User 2)

Design catalog (Master)

Live catalog

Figure 27 Parallel Maintenance of a Geneva Catalog

Management of parallel catalog development is achieved via Product and Pricing Edits Transfer. This includes the resolution of conflicts arising between either: y y

A delta and the catalog into which it is being merged. The deltas being merged with a catalog and other deltas that have been applied to the catalog since the baseline to which the new deltas refer was created.

Scheduling and Monitoring All Geneva volume processes are run on the UNIX server machine(s). The information relating to the scheduling, sequencing, and number of these processes is held in the Geneva database. Control of all Geneva processes, and additionally any third-party processes such as scripts, reports, and other programs, is provided by a master Geneva

152



process known as the Task Master. The user application that schedules volume processes for execution by the Task Master, and assesses their success or failur e after they have run, is called System Monitor.

Task Master Geneva contains a number of volume processing applications each designed to perform a particular job or task. The Task Master is a background server pro cess that runs continually, managing the starting and stopping of the Geneva volume processing applications. This can be used to automate all Geneva volume processes. They can be chained together as sequences of processes, for example, to import events and then rate them, or to bill accounts and then format the bills. The Task Master can execute tasks either interactively on demand or according to a pre-defined schedule: y

Schedules are ideal for tasks such as billing that you want to perform on a regular basis. When a schedule for them has been defined, they will be executed automatically at the appropriate times.

y

The interactive method is suited to irregular tasks, for example, an extra one-time run of the Billing Engine after a hardware problem caused a scheduled run to fail.

Figure 28 shows the relationship between the Task Master, System Monitor, Oracle RDBMS, and the client/server platforms.

Commands, data requests

Task Master

Arguments

PC

User commands

System Monitor

Response, status

Real-time status display Log review and reports

Read

Progress messages

Read

Edit

Read/ write

PM.log

Log data

Log files Child processes

Completion Status

Manipulate

UNIX/NT server

Schedule data

Billing data Oracle database

Figure 28 Task Master Context Diagram

The Task Master communicates with its child processes (the Geneva volume processes such as the Billing Engine) in a number of ways, as appropriate to the volume and importance of the information concerned.


153


External Schedulers A scheduler external to Geneva can be used to schedule and manage the ru nning of the Geneva volume processing applications. The external scheduler can undertake one of the following tasks: y

Interface directly to the volume processing applications using standard command line protocols (process definition, process plans, and tasks are defined by the external scheduler).

y

Pass process requests to Task Master via APIs (process definition, process plans and tasks are defined by System Monitor).

System Monitor System Monitor is a PC-based user application that provides a user interface for controlling the Task Master. Commands available from System Monitor include: y

Halting the Task Master.

y

Altering the periodic schedule.

y

Requesting status information.

y

Assessing the success/failure information from schedules that have been executed.

y

Drilling down to the details of the individual tasks to access the information, warning, and error messages that were recorded.

y

Starting volume processing applications on demand.

In addition, System Monitor and Task Master can run any third-party UNIX package, such as a report writer or customer script, if required. System Monitor may be used to create tasks that can either be run interactively when required or may be scheduled to be run to a particular timetable. Any of the volume processing applications that are part of Geneva can be included in a sequence and thus be launched or scheduled for launch from System Monitor. In addition, it is normally possible to adapt Geneva to allow external applications and SQL scripts to be included in tasks and thus scheduled alongside the Geneva volume processing applications.

Scheduling Geneva System Processes Geneva runs volume processing applications using three mechanisms known as Schedules, Tasks, and Process Plans: y

Schedules A schedule provides a timetable of when tasks are due to start, accurate to the nearest minute. Executing a schedule consists of executing each task that makes up the schedule in sequence, so long as the tasks complete successfully. A schedule will be stopped if it exceeds a specified maximum run time.

154



A schedule may be defined in terms of combinations of: o

The days of the week.

o

The days or day ranges (such as 2nd to 12th) of the month.

o

The months of the year.

Tasks A task may be run: o

Individually using a direct command from System Monitor.

o

As part of a sequence of tasks that make up a schedule.

Executing a task consists of executing each process plan that makes up the task in sequence. A task may stopped if it exceeds a configurable end time (for example, 8:00 A.M.) or a specified maximum run time. y

Process plans A process plan defines the volume processing application to be run and how it will be run in terms of any parameters to be passed, maximum run time, number of processes to be created and run at the same time, etc. These numbers can be specified using System Monitor.

Geneva allows any number of schedules, tasks, and process plans to be defined. Individual schedules (which use tasks and process plans) may then be either active or inactive.

Stopping and Pausing Geneva System Processes System Monitor allows the Geneva user to stop and pause running tasks without loss of data. Tasks can be stopped conveniently (after the current unit has been processed) or immediately (the current unit will have to be reprocessed). Paused tasks can be resumed at any point, though a paused task will be stopped if the length of the pause exceeds a configurable time period. Tasks, schedules, and process plans that exceed specified time limits will stop conveniently.

Monitoring Current System Processes System Monitor provides a scrollable calendar for monitoring planned schedules, currently executing volume processing applications and volume processing applications that have already run as constituent parts of schedules. Day at a view, week at a view, and month at a view summaries are provided. Geneva allows the scale of the calendar views to be altered if required. The current time is indicated on the calendars, and currently executing volume processing applications are displayed by name. The duration that they have been executing is also shown using a Gantt style bar chart. The inter-relationship between tasks (such as predecessor or successor) is also shown.


155


Investigation of Past System Process Activity Geneva allows the details of a volume processing application run to be investigated. A summary of the key statistics, such as number of records processed and number of errors, is provided. Volume processing applications that ran successfully are identified and distinguished from those that experienced problems using color on the Gantt bars of the calendars. If required, Geneva allows the user to drill-down to a specific run on a specific task within a schedule. This will provide structured access to the log files produced by the volume processing application. Color is used to distinguish warning and error records from informational records for Geneva volume processing applications.

Jobs and Managed Files Geneva processes large volumes of data in ASCII files as input, processes the data, and periodically generates large volumes of data for delivery, often as further files, to a nominated party. The three principal examples of such volume data pr ocessing are: y

In – the unrated (and pre-rated) events.

y

Out – the formatted or unformatted invoice data.

y

Out – deletion (typically archive) of rated events from the system.

Geneva undertakes the volume input, output, and processing of file-based data using two related mechanisms – jobs and managed files. A job is the process (work) that needs to be undertaken on the data set, where the data set is the set of data delivered into or exported from Geneva. Geneva operates in a managed environment in order to protect the information on which it acts. Data that is to be processed by Geneva must first be imported into the Geneva managed environment. Most of the data that Geneva has to process is delivered as AS CII files. Geneva imports the external files that are to be acted on (such as unrated event files) into the Geneva managed file area as managed files. Geneva carries information about the managed files in the Oracle database. Validity information is held to ensure that the database and file are held as a consistent and managed pair. In addition to importing files into the managed file area, Geneva may also need to export files from this area. For example, bill data files for formatting by a third-party formatting package, so they are available to external applications. Geneva pr ovides an export facility to export files in a controlled way from the managed file system. The managed file mechanism is used for all import and export of volumes of data to/from Geneva via ASCII files.

156


7

Security Geneva provides the ability to control user access to user applications, data, and catalogs.

Password Access Control The Geneva user password is used to login to Geneva user applications and to allow access to the Oracle database through the Geneva user applications. When a Geneva user is created in System Configuration, a password is entered for the user. On creation, the following are configured: y

Whether the Geneva user is forced to change their password on first login.

y

The Oracle Profile to be associated with this user. This Profile is used to define password functionality such as the number of login attempts before lockout, when the password must be changed, and when the password is available to be reused.

y

Whether the password is to be hashed (encrypted) before it is used to access the Oracle database.

Business Roles Access to user applications is managed by business roles. Access to report data is limited and transaction limits set in a similar manner as deemed appropriate. Where there are a group of users who are to be assigned the same level of authority when using Geneva, it would be cumbersome to set up each Geneva user’s functional access independently. Instead, the Geneva operator is able to configure a set of business roles in System Configuration and then simply assign a business role(s) to a Geneva user on creation or modification. Every user may be assigned any number of business roles. These business roles confer user application functional access permissions and transaction limits. Figure 29 illustrates this.


157


Geneva users

Business roles

Mary Jones

Sally Williams

Customer service representatives

Bob Smith

Marketing administrators

Joe Bloggs

Billing administrators

Figure 29 Assignment of Business Roles

User Application Access Each business role carries its own set of user application access permissions. There are three levels of functional access control: y

View (collection of tabs, rating and billing catalogs).

y

Tabs.

y

Functional points (buttons representing business transactions, such as Add, Modify, and Delete).

For example, a customer service representative (CSR) may have access to Customer Account Maintenance and may view tabs within the Account Setup view only. At the finest level, the CSR may be allowed to create a dispute but not accept it.

Data Partitioning Geneva provides the ability to bill customers on behalf of many different companies in many different currencies, tax jurisdictions, and countries. Users can have their access to customer data restricted dependent on the business role assigned to the user. For example, a Geneva operator may want to implement data partitions so that: y

Users with a “UK CSR” business role can only see customers in the U.K.

y

Only users with a “UK Supervisor” business role can see sensitive customer records.

The basis on which customer and account data is partitioned is determined by a permission ID which is stored as part of the customer data. The permission ID is an abstract partitioning which can be mapped to whatever customer attribute the Geneva operator may choose to filter on. In order for a user to be able to view a customer’s data, the user’s business role must have the permission ID that matches the permission ID for that customer.

158


7 – Security

Transaction Limits Each user of Geneva can have different transaction limits imposed on the size of various (financial) transactions that they are allowed to make in addition to those imposed by business roles. The transactions include creating and modifying: y

Account balance adjustments.

y

Loyalty point adjustments.

y

Refunds.

y

Payment and refund requests.

y

Collections schedule modification days.

y

Budget payment plan financial modifications.

Catalog Partitioning Catalog partitioning allows multiple rating and billing catalogs for the same currency to be managed independently in a single Geneva instance. It also limits access to the catalogs for Geneva users and customers. This allows service providers to manage their own price plans, customers, and catalogs. Additionally, pan-national providers can offer localized services (such as one service per country) using the same currency. For example, multiple live catalogs are useful for providers that use the euro as its main currency and have customers in several non-European countries. Geneva allows catalogs to be partitioned at the invoicing company level. For situations in which branded resellers act as channels for the Geneva operator’s services, this allows service providers to access and manage their price plans without affecting the remainder of the catalogs. Geneva users linked to a particular invoicing company may only select catalogs associated with that invoicing company. It is possible to have separate live catalogs for each combination of invoicing company and currency. Catalog partitioning has the following effects: y

Geneva users can be associated with an invoicing company in System Configuration. The Geneva user can then only view and create billing and rating catalogs associated with the same invoicing company. Geneva users who have no associated invoicing company can view and create all rating and billing catalogs.

y

Accounts have associated currencies and, optionally, invoicing companies. Only those billing and rate plans for rating and billing catalogs with the same currency and invoicing company will be available to the account. If an account is not associated with an invoicing company, the only price and rate plans available will be those in rating and billing catalogs that are not associated with any invoicing company and have the same currency as the account.


159


Price Plan and Package Availability Geneva provides a flexible means of limiting the availability of products (within price plans) and packages to customers using market segments: y

Products within a price plan and packages can be linked to market segments. The choice of market segments available to be linked to the product or package is dependent on the invoicing company that owns the billing catalog.

y

Customers can be linked to a single market segment. The choice of market segments available to the customer is dependent on the invoicing company linked to the customer.

If market segments are used, the customer can only take products (within price plans) and packages that are linked to the customer’s market segment. If a market segment is not selected for the customer, the customer can only take products (within price plans) and packages that are not linked with any market segment.

Server, Client, and LAN Security Geneva runs on PC clients, a UNIX server, an Oracle RDBMS, and a LAN network operating system. Each of these components has its own concept of users and passwords. Geneva does not address issues relating to the UNIX server, the PC client, and network operating system passwords and security – these are standard UNIX, LAN/ PC security, and administrative issues and are outside of the scope of Geneva. Geneva is simply hosted on these technologies. Full use may be made of the security regimes provided by the UNIX server, the LAN, and the client PCs.

Audit Trails Geneva provides a comprehensive financial audit trail. This is implemented using standard Oracle mechanisms. As standard, to limit the audit trail data volumes, Geneva only creates audit trail information when the data entry or edit has a direct financial implication. This will then record the date/time of the edit, the value before and after, the user name of the person making the edit, and various other aspects of the record that were affected. The Geneva audit trail mechanism is completely general purpose however. It can be extended using standard Oracle features, without needing a release of Geneva, so that additional types of entry and edit are recorded in the audit trail if this is required (subject to adequate disk space provision being made). Audit trail is a separate and distinct mechanism from entity historying. Geneva provides extensive entity historying (such as custom ers, accounts, and rating and billing catalogs). Historying records a start and end date/time for the entity in question. For example, a customer database record might hold their name, address, telephone number, etc. In Geneva, this is historied. This means that if any aspect of that database record changes (such as an address or contact telephone number change), the date/time of that change will be recorded on the first database record and a successor database record created for the new address.

160


7 – Security

The Geneva audit trail mechanism creates an entry in an audit trail table, recording the user who made the edit and what they did. An audit trail is kept whenever Geneva exports customer or general ledger information. The transactions that are audit trailed as standard within Geneva include creating or modifying: y

Credit classes, credit limits, and deposits.

y

Account balance and loyalty point adjustments.

y

Age of receivable modification days.

y

Disputes and adjustments.

y

Payments, failed payments, and payment requests.

y

Refunds and refund requests.

y

Budget payment plan financial modifications.

y

Reprocessing of rejected event files.

y

Removal of failed events.

y

Modification or deletion of customer/account numbers.

Partitioning Catalogs by Invoicing Company Geneva allows you to create multiple billing and rating catalogs for the same currency to be managed independently within a single instance of Geneva. To do this, you associate invoicing companies with specific catalogs. This functionality allows service providers to have some independent control over their catalogs and can access and manage their price plans, catalogs, and customers. The Geneva operator would deliver the service and own the infrastructure involved, and also restrict user access to specific catalogs.


161


162


8

System Architecture Geneva is comprised of two main components which can be used together or separately within a best of breed solutions architecture. The Optional Geneva components are: y

Geneva rating.

y

Geneva billing.

y

Geneva Enhanced Care APIs.

The Geneva components may be integrated with other packages, or software developed in-house, using the Geneva APIs. Additionally, multiple Active Rating Engines can be used. Geneva rating can be used to rate some classes of event, while third-party packages can be used to rate other classes. Geneva billing can then be used to consolidate all events onto a single invoice and store all billing information in the Geneva database. Integration options using the Geneva rating and billing components, together with the principal processes are illustrated in Figure 30:

Any combination of:

Any combination of:

Mediation system

Geneva rating

Geneva formatting engine

Mediation system

In-house rating engine

Pre-rated events

Geneva event loader

(for example, from mobile provider partners)

Event rating and loading

Event acquisition

Key: Geneva component

Third-party or in-house system

Geneva convergent billing

Third-party formatting engine Geneva bill data export

Billing and discounting

External bill formatting (such as Print Bureau)

Bill formatting

Geneva CRM system Geneva ECA CRM system

Figure 30 Geneva Optional Components


163


User and System Processes Functionality Geneva employs a client/server architecture. Unfortunately, these terms are commonly used to describe both the hardware and software aspects of the system without distinction. Geneva provides both interactive and volume processing functionality on a client/server architecture: y

Hardware: Some machines act solely as hardware clients – in which case they run

client software. Geneva hardware servers host both RDBMS database server software and Geneva volume processing applications software. y

Software: Client software (principally) provides business functionality – presentation

and application functionality in the OSI 7-layer model. This may be user-related functionality provided via a graphical user interface-based program or volume processing functionality that runs automatically and implements other business functions. The inclusion of Geneva Enhanced Care APIs means that Geneva provides a multitier architecture, thereby extending the client-server architecture by introducing an application server (middle) tier between the client and server. This is usually both another physical machine and a software layer that runs on it. For the software layer, both a commercial application server and Geneva application code are employed. The following terms are used as defined in this document: y

Client : The client computer (hardware). For Geneva, this is a PC.

y

Server : The server computer (hardware). For Geneva, this is a UNIX machine. Server

should be taken to mean a computer running UNIX and hosting the database engine. It may be a small, workstation size machine scaling right through to a Symmetric Multiprocessing machine. y

Database engine : The RDBMS software which runs on the server. Geneva employs

the Oracle RDBMS. y

User application : The software which provides the business functionality which runs

on the client and interacts with the user via a graphical user interface. y

Volume processing application : The software which provides the business

functionality which runs automatically without user interaction. For Geneva this runs on a server class of machine. It may be the same physical machine as the database engine or it may be other physical machine(s). The Geneva philosophy is to use and allow the use of industry-standard packages wherever possible. Proprietary interfaces between clients and data, clients and server, or autonomous processes are not employed. The Geneva philosophy is to allow and to encourage best of breed tools to be used and this is largely the choice of the end customer.

164


8 – System Architecture

Application Architecture Geneva provides a range of functional capabilities, delivered on a client/server platform. Some aspects of the functionality are provided by user applications, others by volume processing applications. The user applications allow various categories of Geneva data to be entered and maintained, subject to authorization of that user’s privileges and an audit trail of their actions. The broad categories of Geneva function/data are: y

y

y

System set up data. Such data is typically set up once and rarely changed. It allows the Geneva operator to configure Geneva for their specific business environment. Administrative functions. A suite of applications that allow authorized financial personnel to chase and recover receivables and make payment entries. Expert and privileged business analysts and marketing personnel are also able to define the set of products and services that the Geneva operator delivers to the market and which Geneva is to bill. Other administrative functions include routine, day-to-day administrative tasks such as scheduling volume processing applications, investigation and correction of problems, or setting up of collections schedules. Customer application functions. A suite of applications that allow users to enter, access, and update customer and account data. This includes setting up new accounts, registering products and services, making bill adjustments, and bill viewing.

The volume processing applications are automatic processes that undertake the volume processing functions of Geneva. These may be scheduled to run as frequently or infrequently as required. These processes undertake such activities as rating , billing , formatting , archiving , and calculating age of receivables . The Geneva audit and security regime overlays all functions and data provided by the user applications, Enhanced Care APIs, and volume processing applications. Geneva has been designed to be used in a best of breed, integrated environment. By definition, it is designed to work with other systems and to accept and make available data that needs to be common to one or more systems. Geneva is truly open – all data is made available by secure mechanisms which preserve and maintain the coherence and integrity of the data. Geneva provides a public schema and PL/SQL APIs. Figure 31 illustrates the complete application architecture.


165


User applications

User applications

User applications


Billing Catalog Maintenance

System Configuration

Customer hierarchy maintenance

Packages, products and services

Disputes and adjustments

Bill viewing

Payments

Bonus schemes and loyalty points

System Monitor

Accounts Receivable Total receivables

Chargeable receivables

Rating Catalog Maintenance

Receivables by customer

Disputed receivables

Rejected Event Maintenance

Batch Payment Entry Product Configuration

Product and Pricing Edits Transfer

Configuration Data Transfer

Third-party systems

Security

Stored procedures Public views Enhanced Care APIs

Geneva database

APIs

Access control

Audit trail

Task Master Third-party rating

Event loading

Event rating

Convergent billing

Geneva and third-party formatting

Lockbox

Reports

Age of receivables and collections

Archive and delete

Interface to financial systems

CD ROM E-mail Paper

Figure 31 Geneva Application Architecture

High Availability The architecture of Geneva is suited to operation within high availability environments where system downtime needs to be minimized for critical functions. High availability configurations are optional, and dependent on the operator’s own availability strategy. For more information on high availability with Geneva Distributed Revenue Processing, see "High Availability," page 166.

Third-Party High Availability Third-party industry-standard high availability strategies and technologies can be employed with Geneva to achieve the following:

166

y

Disk redundancy, using RAID.

y

Machine redundancy and failover.

y

Clustering.

y

Disaster recovery.


8 – System Architecture

Convergys have experience of operating Oracle Real-time Application Clustering (RAC) in order to boost the availability of key Geneva applications and data, using fast process restarts with seamless failover and zero data loss, for example, in order to allow the Active Rating Engine to run continuously. Convergys can work with customers on a consultancy basis to develop a tailored high availability solution using Oracle Real-time Application Clustering, and can advise on other high availability solutions. Convergys-generated high availability solutions are supported as part of the support and maintenance agreement. Please contact your Convergys support representative for more information.


167


168


9

External Interfaces Geneva was designed to be the best of breed convergent rating and billing system. Unlike legacy systems and first generation billing packages, it does not provide a delivery-specific, end-to-end system. Geneva is intended to work with other best of breed packages to deliver superior functionality and tremendous flexibility. Consequently, Geneva is designed to integrate with other packages that have a similar philosophy. To make this as easy as possible, a range of application programming interfaces (APIs) are needed. Very high level interfaces allow quick integration with high-level functions. It is often necessary to complement such APIs with lower level functions, however, as flexibility and fine control of fun ctions and data is often required. Geneva provides two levels of interactive APIs and a third for integration with other systems where a high volume interface is required.

Public Schema At the lowest level, Geneva provides a fully documented public schema. This provides read-only access to the main Geneva tables for reporting and analysis.

Oracle Stored Procedures At a higher level, Geneva provides a comprehensive set of Oracle SQL store d procedures. These are routines rout ines that can be used to store, modify, and delete data within the Geneva database. They provide an easy-to-use interface to Geneva and protect external programs from changes to the database schema structure. In addition, they perform all the checks required to verify that data updates are consistent with any integrity and security constraints that may be in force. The procedures are loaded as part of the installation procedure. Any Oracle enabled application can update Geneva directly in a controlled fashion, without the need for language specific wrappers. Geneva stored procedure APIs provide access to complex data structures in a controlled and easily understood way. Application-level Geneva actions can be undertaken within a wider business framework, controlled throughout by standard Oracle transaction control mechanisms. Access to Oracle stored procedures is available from customer care packages and all modern development languages through ODBC, BDE, and Oracle interfaces. Most current Windows programming technologies, such as those employed by modern customer care packages, are able to use Oracle stored procedures directly. Indeed, language-specific APIs such as DLLs are often more troublesome to use than using stored procedures or public views.


169


Language-specific interfaces, such as C may be used if require d. C programs can use the Oracle SQL stored procedures or public views. The Oracle Pro*C interface can be used as a direct C programming interface.

Enhanced Care APIs Geneva Enhanced Care APIs (ECA) EJBs are the primary Geneva integration point for third-party applications. These, like Oracle stored procedures (see "Oracle Stored Procedures," page page 169 169) are database access APIs. However, unlike Oracle stored procedures, Enhanced Care APIs are part of a highly scalable, three tier architecture. Enhanced Care APIs can be used as an alternative to Oracle stored procedures for integration purposes, for example, integrating Geneva with customer relationship management (CRM) systems. EJBs are accessed directly via Java. This may be either within the J2EE container (for example, from a web application), or external to the J2EE container from a remote client. J2EE containers typically provide many other indirect ways of bridging to other integration technologies. For BEA WebLogic this includes WebService, JCOM, Corba, and Tuxedo. It is highly likely that ECA will provide WebService wrappers in a future release. Geneva Enhanced Care APIs are currently only available for customer related data (for example, customer and account details, products taken by customers).

File-Based Interfaces Geneva operates in a managed environment in order to protect the information on which it acts. In order to achieve this, any files that are passed to Geneva from outside the Geneva managed environment must be presented in a formal way which allows them to be registered into the managed environment. Geneva defines: y y

An import file format. The protocol for importing files into the managed environment.

y

A mechanism for importing files.

y

An export file format.

y y

Protocols for exporting files out of the managed environment. A mechanism for exporting files.

Geneva transfers files in groups. Each group of files is transferred as a single unit and the transfer of the files either entirely succeeds or entir ely fails and has to be done again. This process is managed by a control file that lists all of the files to be transferred. The Geneva file-based interface is used to import event files, bills and bill data, bill insert files, and a number of other high-volume Geneva entities.

170


9 – External Interfaces

Plug-In Interfaces Geneva operators can create their own interfaces to specific parts of Geneva by creating customized plug-ins. A number of plug-in interfaces are available for configuring Geneva to interface with external systems. Creating a customized plug-in requires the implementation of the appropriate interface. The plug-ins that are available for customization are: y

Bill suppression plug-ins These let Geneva operators suppress bills that meet particular criteria. Suppressed bills are never issued.

y

Customized rating input plug-ins. These let Geneva operators define their own methods for receiving events from mediation systems (as opposed to using the supplied File-based Rating Input Plug-in or the Socket-based Rating Input Plug-in). In this way it is possible to feed events into the Active Rating Engine using, for example, Oracle Advanced Queuing or MQSeries.

y

Outbound message plug-ins. These let Geneva operators pass information from Geneva to an external messaging system, for example Oracle Advanced Queuing.

y

Rating cost plug-ins. These let Geneva operators cost events using customized algorithms.

y

Rejected event modifier plug-ins. These let Geneva operators automatically modify rejected events (for example, to discard events which have already been rejected three times).

Breakout Objects There are a number of places in Geneva where information needs to be entered which relates to the product being sold or to whom it is being sold. In order to avoid having to manually enter pieces of information that would typically be obtained from other systems such as customer credit score, Geneva provides a generic mechanism for breaking out of Geneva to retrieve information from external sources such as stock control databases. These interfaces are written in high-level languages such as Delphi or Visual Basic. Geneva does not specifically include these interfaces, but full interface specifications and sample Visual Basic code are provided.

Example As explained in "Defining Custom Product Attributes," page age 87, 87, attributes may be defined that are specific to the type of product. Geneva allows the attribute values to be returned from other systems via the breakout mechanism. When the user accesses Customer Account Maintenance and views the Attributes tab, a form is displayed showing the extra attributes named for that product and buttons to retrieve (Get (Get)) values, as configured in Product Configuration.


171


For example, the first and fourth field can be entered directly into Customer Account Maintenance as text. The second and third fields are retrieved from stock as a pair using the nominated breakout component and using the button displayed.

Interfacing with Other Systems Figu Figure re 2 provides a context diagram for Geneva in a telecoms application in relation to other business systems. Although a few of the systems are specific to the telecoms context, it provides a useful general model for the position of Geneva in respect of other information systems to deliver and support usage-based services to a customer. There are a small number of major systems which may require some integration with Geneva; the extent and manner of the integration will vary significantly from case to case, with business objectives, customer and usage volumes, market segment, finance, etc. The main systems are discussed further below. The same principles and techniques are however applicable to other systems which might be identified on a case by case basis.

Customer Care In many situations, customer care functionality and its integration with other systems will be as important as flexible billing. There are two main aspects of customer care: y

The provision of customer service representative (CSR) functionality such as work queues, inbound and outbound telephone queues, sales, and prospecting capabilities. Fulfillment of promotional literature, reminders, support for team working, remote sales support, etc. are also provided. There is a vast spectrum of functionality directly related to the sales and prospecting process, followed by support of that customer and resolution of their problems and queries once they become a customer. This illustrates the central issue, which must be addressed by the second aspect of customer care functionality.

y

Integration capabilities. As is illustrated above, the very natur e of the role requires that the CSR has access to a wide range of information and functionality. Inevitably, Inevitably, this information and functionality is resident in a number of systems. Modern customer care packages provide customer-facing technology together with the ability to integrate and share information with other systems. Customer care packages allow you to put separate packages together to form a complete business solution.

The Geneva customer care interface is one of its most important features. Geneva provides a significant amount of customer care functionality relating to the areas that are addressed by Geneva (rating and billing). Integration is possible at three different levels, as appropriate to the situation. These are public views direct to the published schema and the SQL stored procedures. Geneva provides customer care functions which give secure, controlled, and audit-trailed access to the following types of billing related information: y

Identifying the customer and/or account by a range of criteria.

y

Display and navigation of the customer hierarchy.

y

172

Adding new or editing existing customers and their details.



y

y

Display and navigation of a single customer’s accounts, products, budget centers, packages, etc. Ability to register new and make edits to existing products and packages for a specified customer account.

y

Editing account details, such as contact details, bill period, bill date, and payment details.

y

Viewing of historic bill summaries and WYSIWYG bill images.

y

Registering disputes, queries, and refunds.

y

Making adjustments.

y

Registering bill requests.

y

Recording customer account-specific discount details, such as family and friends numbers.

y

Manipulating loyalty points for a customer account.

Provisioning Systems Geneva provides a mechanism for finding the information that is needed to provision services and sends it to other, integrated systems. It will also provide a feedback loop, so that when the provisioning actions are taken, this fact may be recorded in the Geneva database. Once a provisioning system is defined for a product, then whenever Customer Account Maintenance or APIs are used to register or terminate an existing product, a provisioning service request will be created and written to the SERVICEREQUEST table. The Geneva provisioning interface will provide a set of APIs to read service requests and write back status information. It will then be an integration task to use the Geneva service provisioning APIs with the provisioning system they choose.

Event Sources Event import is arguably the most important interface. Without usage records (events), Geneva can only bill non-recurring and periodic charges. In data services and telecoms, a mediation device will retrieve the usage records as CDRs and SDRs from the network equipment periodically. For utility billing, usage records are metered readings taken either by manual reading or remotely, potentially by a third-party, preprocessed into a standard format and then entered into Geneva as events. The event import interface is a high-volume interface. Geneva uses a file-based import mechanism for events. It provides a defined file format and protocol for importing event files securely and reliably into Geneva. The format is ASCII-based and configurable – Geneva can be instructed as to the exact format of the files. Files may be imported as frequently or infrequently as required; even per minute if necessary. If real-time rating is required, the Geneva import interface and Active Rating Engine can be configured to run continuously.


173


Geneva allows prerated events to be imported and registered against accounts, as well as events for which the event price is also to be determined. Unrated and prerated events can be mixed within a single import file. Prerated events may originate from a third-party rating engine, from an existing heritage system or indeed may be low-volume events which have been generated by a specially written in-house system. For example, the Geneva operator may charge for callouts of service personnel. A separate staff diary scheduling system may take care of which technician attends and a simple extract process could generate a Geneva event with a price for such callouts. Equally, Geneva could price the callouts on the basis of the duration of the site attendance, number of personnel or grade of staff.

External Formatting Engines Once usage information is in Geneva, the events can be rated and the account can be billed. The bill information then needs to be formatted and presented in the format required for that customer. This can be done by the Geneva RTF formatting engine, or a third-party, external formatting engine can be used. Most volume printing is undertaken by specialist printing houses that use specialized equipment for bill formatting and rendering, as high-volume printing devices use specialized print formatting protocols such as IBM AFP and Xerox Metacode. Geneva allows bill data (a superset of the content of the bill) to be exported from Geneva in ASCII files. The standard Geneva file export mechanism is used for this purpose. Geneva also provides a defined protocol for reimporting viewable images for bills that are formatted externally.

Finance Systems Geneva operators wishing to manage their accounting from an external finance system need to be able to export sets of customer account data and invoice data. In addition to Geneva’s public views and reports which can be used to provide information for the accounts interface, Geneva also provides a formal export process with audit trail and tidemarking.

Customer Account Data The third-party finance application to which data is being exported should have an account structure which corresponds to that in Geneva so that accounts can be directly updated by the data coming in from Geneva. Within Geneva a customer may have a number of accounts which exist within a customer hierarchy. However, since it is unlikely that the third-party application will be equipped to model customer hierarchies, the Geneva account data is exported at the account level, but will contain some customer-related information. Geneva’s export file format allows for the export of a customizable set of customer and account attributes.

174



Invoice Data The export of Geneva invoice data supports the identification of all invoices generated within a given date range. The invoice data provides both summary and detail records. The summary record summarizes revenue by account number and bill sequence. The detail record provides a breakdown of revenue by date range, revenue code, and tax code. These different record types must be exported to separate files.

Audit Information Geneva retains audit information in order that export activities may be traced and reconciled. Invocation of an export will check parameters against this audit trail and give warnings in the event of duplication (such as overlapping dates). Additionally, check totals are calculated where appropriate to assist with reconciliation between export and import, such as the number of customer accounts whose details were exported, or the number of invoice detail records exported.

Tax Packages Geneva’s internal tax mode is VAT/GST. However, U.S. Tax and Brazilian Tax are supported externally via third-party tax packages.These third-party tax packages are detailed in the relevant integration guide, for example, the Geneva Vertex Integration Guide for U.S. tax and the Geneva Integris Integration Guide for Brazilian tax.


175


176


10

Requirements

Hardware Requirements Server The systems supported for the server components are as follows: y

Servers manufactured by the following vendors, running the following operating systems: o

o

IBM: –

AIX 5.1 (with 64-bit application environment enabled).

–

AIX 5.2 (with 64-bit application environment enabled).

HP (Itanium-based servers are not supported): –

o

HP-UX 11i (64-bit PA-RISC, also known as HP-UX 11.11).

Sun SPARC-based servers (Intel-based servers are not supported): –

Solaris 8 (64-bit) (also known as Solaris 2.8). To ensure that Cache Manager works correctly the latest Solaris 8 patch bundle with the shared library file /user/lib/sparcv9/libCstd.so.1 must be installed. The two Sun patch numbers that relate to this library file are PatchID# 108434-15 and PatchID# 108435-15.

– o

Solaris 9 (64-bit).

Compaq: –

Tru64 v5.1a (64-bit).

–

Tru64 v5.1b (64-bit).

y

Minimum of 1 GB free disk space.

y

Geneva Distributed Revenue Processing is supported on all server types with the Geneva Enterprise Edition license. Geneva Distributed Revenue Processing describes any multimachine configuration of Geneva. It is only supported for multiple servers of the same type.


177


Client The minimum requirements for each client PC that will be running the Geneva user applications is as follows: y

Minimum Pentium 2 PC.

y

Minimum of 500 MHz.

y

Minimum of 128 MB RAM (256 MB recommended).

y

Hard disk space depends on the subset of applications to be run. The requirement for all of the applications is 90 MB.

y

Minimum 17 inch monitor with a minimum of 1024 x 768 resolution and a minimum 64 K colors.

Software Requirements Server The following software is required on the server(s) that will be running Geneva: y

Oracle Server 9.2 (64-bit). A minimum patch level of Oracle release 9.2.0.4 (64-bit) is required for Geneva 5.3IN.

y

A suitable file sharing mechanism to allow UNIX generated files to be accessed on PCs. It is important that the file sharing mechanism chosen is configured to respect the case of existing file names.

y

Perl 5.005.

y

BEA WebLogic server 7.0 or 8.1 is required if the Geneva Enhanced Care APIs are employed.

The following are installed on the server(s) with Geneva: y

Rogue Wave Edition 4.1.

y

Open SSL 0.9.7a.

Client The following are required on each client PC that will be running the Geneva user applications: y

178

Windows 2000 with Service Pack 2, Windows 2000 Server, Windows XP Professional, or Windows 2003 (Standard and Enterprise editions).


10 – Requirements

y y

Oracle Net Client 9i (Release 2). Adobe Acrobat Reader 5.0 or later is required to access the documentation. The Acrobat Reader+Search version is required to use the searchable index.

y

Microsoft Word 2000, XP, or 2003 is required for the Bill Renderer and to preview bills.

y

Crystal Reports release 8.5 is required for creating custom reports.

Microsoft Internet Explorer 5.x or later is required to allow access to the HTML help.


179


180



Overviews Geneva Product Overview This guide provides a high level introduction to Geneva, covering: y y

A description of Geneva's key features and how they can be used. The concepts used within Geneva.

y

A description of the components of the system.

y

An introduction to the system architecture.

Glossary This guide defines the common terms used throughout the Geneva system.

Concept Guides Customers and Accounts Concept Guide This guide looks at the two Geneva concepts of customers and accounts and provides details on budget centers and customer hierarchies.

Products and Catalogs Concept Guide This guide covers the setting up of products and the management and contents of billing and rating catalogs.

Events and Rating Concept Guide This guide covers events and the rating process. It includes the configuration of events, the methods of costing an event, the assignment of events to accounts, and the actions of the wide range of plug-ins available for use with the Active Rating Engine.

Billing Concept Guide This guide covers the production of bills including the modes of billing, types of bills that can be produced, the suppression of bills, the grouping of the information, and the formatting of the bill data. In addition, it describes how charges are calculated during the billing process.

182


11 – Documentation Set

Tax Concept Guide This guide covers concepts that are common to all tax systems plus those that are specific to VAT/GST. For details that are specific to the third-party tax systems with which Geneva integrates, see the relevant integration guides, for example, the Geneva Vertex Integration Guide for U.S. tax on telecommunication products.

Discounts Concept Guide This guide examines how to create and use discounts on events and products. It covers the different options available when setting them up and provides examples showing the results of using them.

Payments Concept Guide This guide provides an overview of how Geneva handles payments and refunds. It covers: y

Physical and account payments.

y

Payment methods.

y

Budget payment plans.

y

Payment requests and automatic payment authorizations.

y

Failed and cancelled payments.

y

Deposits and allocation of account payments.

y

Convergent prepay.

Finance Concept Guide This guide examines the financial aspects of Geneva. It covers: y

Revenue codes.

y

Revenue assurance.

y

Contracts.

y

Disputes and adjustments.

y

Financial reporting.

Credit Control Concept Guide This guide examines how Geneva handles credit control and collections. It covers: y

Collections actions and schedules.

y

Dunning process.

y

Credit terms.


183


Import and Export of Data Concept Guide This guide looks at how data can be output from and input to the Geneva database. It covers: y

Managed files.

y

Legacy system data.

y y

Accounting data. The import and export of configuration data between Geneva databases to keep two or more instances in step.

Distributed Revenue Processing Concept Guide This guide provides an overview of how to run Geneva in a distributed environment, using multiple machines to improve performance and balance load. It covers: y

Separate event databases.

y

Caching.

y

Domain routing. Some of the Distributed Revenue Processing functionality requires a Geneva Enterprise Edition license.

Other Geneva Concepts Guide This guide provides details of general Geneva concepts. For example: y y y

Auto-generated references. Rounding. Actions and thresholds.

User Application Documentation Reports Guide This guide provides an introduction to using the Geneva reports, details of how to link your own reports into the system, and provides descriptions of all available standard reports.

System Configuration Help This Help file describes the use of System Configuration. This application is used to set up information required by various parts of the Geneva system.

184



Product Configuration Help This Help file describes the use of Product Configuration. This application is used to create and modify products and product families.

Billing Catalog Maintenance Help This Help file describes the use of Billing Catalog Maintenance. This application is used to create and maintain the catalogs which contain the packages, price plans, discounts, and bonus schemes that will be applied when charging accounts for services and events.

Rating Catalog Maintenance Help This Help file describes the use of Rating Catalog Maintenance. This application is used to create and maintain the rating catalogs on which the Geneva rating process is based.

Batch Payment Entry Help This Help file describes the use of Batch Payment Entry. This application provides an efficient interface for entering large numbers of payments of the same type.

Customer Account Maintenance Help This Help file describes the use of Customer Account Maintenance. This application is used for creating, modifying, and viewing records relating to customers and the accounts that they own.

Accounts Receivable Help This Help file describes the use of Accounts Receivable. This application allows the user to see the receivables, disputes, and adjustments across a range of accounts.

System Monitor Help This Help file describes the use of System Monitor. This application allows the user to schedule, execute, and monitor the volume processing applications.

Rejected Event Maintenance Help This Help file describes the use of Rejected Event Maintenance. This application allows the user to manage rejected events.


185


Configuration Data Transfer Help This Help file describes the use of Configuration Data Transfer. This application allows the user to import and export sets of configuration table data.

Product and Pricing Edits Transfer Help This Help file describes the use of Product and Pricing Edits Transfer. This application allows the user to export and import the edits made to products and catalogs.

System Administration Documentation System Planning Guide This guide provides background information on the software and hardware environment required for supporting installations of the Geneva software.

Installation Guide This guide provides instructions for installing a new installation of Geneva. It covers: y

Installing the database schema.

y

Installing the user applications.

y

Installing the documentation.

Configuration Guide This guide provides instructions for configuring a new installation of Geneva. It covers: y

Static and sample data.

y

System and invoicing company parameters.

y

Table configuration.

y

Languages and currencies.

y

Environment variables.

y

Oracle sequences.

System/Invoicing Company Parameters This HTML document provides comprehensive information about the Geneva system parameters and invoicing company parameters.

186



Administration and Maintenance Guide This guide provides details on the day-to-day running of the system, including: y

Database administration.

y

Security management.

y

File administration.

y

Planning and scheduling.

y

System monitoring.

System Processes Guide This guide describes all the UNIX-based components of Geneva. For each it provides: y

A description of what it does.

y

The inputs it requires.

y

The outputs it produces.

y

How it can be run.

Interface Documentation File/Message Queue Interfaces This HTML document provides details on how external files may be passed to and from the Geneva managed environment. It covers: y

Import file formats.

y

Export file formats.

In addition, it covers: y

Message queue message formats.

y

Product and pricing edits transfer file formats.

Plug-In Interfaces This guide provides details on the Active Rating Engine plug-in interface. It covers: y

The rating input plug-in interface.

y

The outbound message plug-in interface.

y

The rating cost plug-in interface.

y

The rejected event modifier plug-in interface.

y

Customizing plug-ins.


187


Breakout Objects This guide provides details on the breakout interface available for configuring Geneva to interface with external systems.

Bill, Statement, and Dunning Data Templates Guide This guide describes the construction of bill, statement, and dunning notice templates.

Bill and Statement Data This HTML document provides a Backus Naur Form (BNF) description of the statement, bill, and budget center data together with details of the individual tags.

Dunning Data This HTML document provides a Backus Naur Form (BNF) description of the dunning data together with details of the individual tags.

Stored Procedures This HTML document provides an overview to the Geneva stored procedures and a link to the stored procedure definitions.

Stored Procedure Definitions This HTML document provides comprehensive information about the Geneva stored procedures.

Enhanced Care APIs This HTML document provides an overview to the Enhanced Care APIs and a link to the package and method definitions.

Enhanced Care APIs JavaDocs This HTML document provides comprehensive information about the Geneva Enhanced Care APIs.

188



Geneva Public Schema This HTML document provides comprehensive information about the Geneva public schema and contains links to the Geneva entity relationship diagrams. These diagrams, provided as separate PDFs, show the relationship between tables in the main functional areas of the Geneva Public Schema. The diagrams are as follows: y

Account Data.

y

Bill Cancellation.

y

Bill Generation and Formatting.

y

Billing Catalog.

y

Customer and Product Data.

y

Collections and Aging of Receivables.

y

Payments, Requests, and Adjustments.

y

Rating.

y

Rating Catalog.

y

Reports.

y

Security and Archiving.

y

Tax.

y

Work Management and Operations.

Change Documentation New Features This HTML document highlights new features in the latest release of Geneva.

Upgrade This guide describes the upgrade process to this release from the previous one.

Release Changes This HTML document describes the changes to the system between this release and the previous one.

Problems Resolved This HTML document describes the problem reports that have been resolved in this release.


189


How to Use the Documentation The following section provides documentation flows to help you organize everything you will need to install or upgrade to Geneva 5.3 and customize the installation or upgrade to suit your business needs. If you are installing Geneva for the first time, see the section "Initial Installation," page 190. If a previous release of Geneva already exists, see the section "Upgrading," page 191. Even though you may not need to use all of the guides, it is still recommended that you have all of them on hand for the setup, installation/upgrade, and configuration process. These lists aid in the upfront planning and familiarize you with the flow of the documentation. Dotted lines in the documentation flow diagrams indicate optional documentation.

Initial Installation Figure 33 shows the order in which the documentation should be read when installing Geneva for the first time.

~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~~ ~ ~ ~

~ ~ ~ ~

~ ~ ~ ~ ~ ~ ~ ~ ~

~ ~ ~~ ~ ~ ~

~ ~ ~ ~

Geneva Output Data Product Changes Overview

~ ~ ~ ~ ~

~ ~ ~ ~

~ ~ ~ ~

~ ~ ~ ~ ~ ~ ~ ~ ~

~ ~ ~~ ~ ~ ~

~ ~ ~ ~

~ ~ ~ ~

Output Data Glossary Changes

Output Data System Changes Planning

Output Data Installation Changes

System Configuration ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~~ ~ ~ ~

I

~ ~ ~ ~

Distributed Output Data Revenue Changes Processing ~ ~ ~~ ~ ~ ~

?

~ ~ ~ ~ ~

~ ~ ~~ ~ ~ ~

System/ Invoicing Company Parameters

~ ~ ~ ~

Output Data Configuration Changes

~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~~ ~ ~ ~

~ ~ ~ ~

Output Data Other Geneva Changes Concepts

Figure 33 Geneva Documentation Relevant to the Initial Installation of Geneva

190




Ensure that you read this guide to become familiar with all the features available with Geneva. This guide contains a high level description of each Geneva component. In addition, it provides flow information for using the Geneva documentation. Glossary

The Glossary should be read in conjunction with the Geneva Product Overview (and all other Geneva documentation) to enable understanding of any Geneva terminology. Geneva Distributed Revenue Processing Concept Guide

This guide explains how to run Geneva in a distributed environment, using multiple machines to improve performance and balance load. Some of the Distributed Revenue Processing functionality requires a Geneva Enterprise Edition license. Geneva System Planning Guide

Once the main concepts are understood and you have decided what features you are going to include in your system (for example, whether you have a Geneva Enterprise Edition license or not), this guide provides details of the hardware and third-party software that is required for a Geneva system to be installed. Geneva Installation Guide

This guide should be referred to during the actual installation of Geneva to ensure the database schema, user applications, documentation, etc. are correctly installed and are ready to be configured. Geneva Configuration Guide

Once Geneva has been installed it requires configuration. This guide provides details on how the system configuration can be achieved. Other Geneva Concepts Guide

Information regarding further issues necessary for the use of the system are provided in this guide, for example, explanations of the different rounding rules, actions and thresholds functionality, and the autogeneration of reference numb ers. Geneva System Configuration Help

Part of the initial configuration and customization of Geneva can be performed using System Configuration. This Help file details the screens and options available within System Configuration and is a useful tool in completing the system setup of Geneva. Geneva System/Invoicing Company Parameters Interactive

To assist the integration, comprehensive information about the Geneva system parameters and invoicing company parameters is given in this HTML document.

Upgrading Figure 34 shows the order in which the documentation should be read when upgrading Geneva for a major release.


191


I

New Features

Release Changes

I

Problems Resolved

I

~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~

~ ~ ~ ~

Output Data Upgrade Changes

Figure 34 Geneva Documentation Relevant to Upgrading Geneva

Geneva New Features

All the new features and functionality that become available by upgrading to Geneva release 5.3 are detailed in this HTML document. Read it first to gain an understanding of the differences in the new release of Geneva. Geneva Release Changes

Any changes that have been made to the documentation, system parameters, tables, etc. since Geneva release 5.2 are detailed in this HTML document. It gives explicit information concerning all the technical changes that have been implemented so that customization work, training, etc. can be planned. Geneva Problems Resolved

Issues that have been identified and resolved since Geneva release 5.2 are detailed in this HTML document, together with the solutions applied. Geneva Upgrade Guide

You are now ready to begin the upgrade procedure. Follow the procedures set out in this guide to upgrade from an earlier release of Geneva to release 5.3.

Day-To-Day Operation Figure 35 shows the order in which the documentation should be read when running Geneva on a day-to-day basis.

192



~ ~ ~ ~ ~

~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~

~ ~ ~ ~

~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~~ ~ ~ ~

~ ~ ~ ~

Administration Output Data and Changes Maintenance

Output Data System Changes Processes

?

System Monitor

Figure 35 Geneva Documentation Relevant to the Basic Day-To-Day Operation of Geneva

Geneva Administration and Maintenance Guide

Details pertaining to the general day-to-day operation of Geneva can be found in this guide, including file and database maintenance. Geneva System Processes Guide

Once the generics of the day-to-day operation of Geneva are understood, the specifics of each of the individual volume processing applications are detailed in this guide. Each volume processing application and plug-in is described along with exactly how to run it. Geneva System Monitor Help

Most of the volume processing applications described in the Geneva System Processes Guide can be scheduled, executed, and monitored via the System Monitor. This Help file provides detailed information about the use of System Monitor and should be used in conjunction with the user application itself.

Processing The use of Geneva can be split into rating, billing, and finance. The documentation flow for each of these modules follows.

Rating Figure 36 shows the order in which the documentation should be read when rating events.


193


Output Events Data and Changes Rating

~ ~ ~ ~ ~

~ ~ ~ ~ ~ ~ ~~ ~ ~ ~

~ ~ ~ ~

Output Data Tax Changes

~ ~ ~ ~ ~

~ ~ ~ ~ ~ ~ ~~ ~ ~ ~

~ ~ ~ ~

?

Rating Catalog Maintenance

~ ~ ~ ~ ~

~ ~ ~ ~ ~ ~ ~~ ~ ~ ~

~ ~ ~ ~

Output Data Products and Changes Catalogs

~ ~ ~ ~ ~

~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~

~ ~ ~ ~

Pre-rating

Output Data Discounts Changes

Rating

?

Rejected Event Maintenance

Post-rating ~ ~ ~ ~ ~

~ ~ ~ ~ ~ ~ ~~ ~ ~ ~

~ ~ ~ ~

Output Data Reports Changes

Figure 36 Geneva Documentation Relevant to the Basic Day-To-Day Operation of Geneva – Rating

Geneva Events and Rating Concept Guide

Before performing any actual rating, the way in which events are configured and handled need to be understood. This guide contains all the fundamental information required. Geneva Tax Concept Guide

Any tax implications concerning the rating of events need to be fully understood so that legal issues do not arise. These should be considered and any problems re solved before any rating is performed. Geneva Products and Catalogs Concept Guide

The rating catalog needs to be managed so that the correct rate plans are applied to events. This guide contains generic catalog maintenance information and should be read before altering the rating catalog. Geneva Rating Catalog Maintenance Help

Altering the rating catalog is carried out via Rating Catalog Maintenance. This Help file provides detailed information about the use of Rating Catalog Maintenance and should be used in conjunction with the user application itself.

194



Geneva Discounts Concept Guide

If you want to apply rating time discounts to events then the rules governing these need to be thoroughly understood in order to avoid over- or under-discounting. This guide details all the necessary rules and provides configuration advice for optimal performance. Geneva Rejected Event Maintenance Help

After rating has been performed, there may be events which the Active Rating Engine has not been able to rate. These rejected events require investigation and correction in order to be processed, which is carried out via Rejected Event Maintenance. This Help file provides detailed information about the use of Rejected Event Maintenance and should be used in conjunction with the user application itself. Geneva Reports Guide

This guide details how to produce any required reports after the rating process has been completed.

Billing Figure 37 shows the order in which the documentation should be read when billing charges.

Output Data Billing Changes

~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~

~ ~ ~ ~

Output Data Tax Changes

~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~

~ ~ ~ ~

?

Configuration Data Transfer

?

Billing Catalog Maintenance ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~

~ ~ ~ ~

?

Product and Pricing Edits Transfer

?

Output Data Products and Changes Catalogs

~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~

~ ~ ~ ~

Output Data Discounts Changes

Product Configuration

?


~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~

~ ~ ~ ~

~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~

~ ~ ~ ~

Output Data Customers and Changes Accounts


Figure 37 Geneva Documentation Relevant to the Basic Day-To-Day Operation of Geneva – Billing


195


Geneva Billing Concept Guide

The production of bills including billing modes, bill types, the suppression of bills, and the formatting of the bill data are detailed in this guide. Geneva Tax Concept Guide

Any tax implications concerning the billing of charges need to be fully understood so that legal issues do not arise. These should be considered and any problems re solved before any rating is performed. Geneva Products and Catalogs Concept Guide

The billing catalog needs to be managed so that the correct price plans are applied to charges. This guide contains generic catalog maintenance information and should be read before altering the billing catalog. Geneva Configuration Data Transfer Help

The rating and billing catalogs need to be maintained by the billing department. To facilitate this, this Help file provides detailed information a bout importing and exporting sets of configuration data and should be used in conjunction with the user application itself. Geneva Product and Pricing Edits Transfer Help

In addition to Configuration Data Transfer, changes made directly to the rating and billing catalogs and product configuration can be imported and exported directly via Product and Pricing Edits Transfer to allow parallel maintenance of the rating and billing catalogs. This Help file provides detailed information about performing these imports/exports and should be used in conjunction with the user application itself. Geneva Billing Catalog Maintenance Help

Altering the billing catalog is carried out via Billing Catalog Maintenance. This Help file provides detailed information about the use of Billing Catalog Maintenance and should be used in conjunction with the user application itself. Geneva Product Configuration Help

The products, subscriptions, and packages available to customers need to be maintained to ensure new offerings are ready to be taken and expired offerings can no longer be taken. This is carried out via Product Configuration. This Help file provides detailed information about the use of Product Configuration and should be used in conjunction with the user application itself. Geneva Discounts Concept Guide

If you want to apply billing time discounts to the charges then the rules governing these need to be thoroughly understood in order to avoid over- or under-discounting. This guide details all the necessary rules and possible discount types. Geneva Customers and Accounts Concept Guide

This guide looks at customers and accounts and gives details on budget centers and customer hierarchies. It is important to be fully familiar with these concepts before setting up customers in Customer Account Maintenance.

196



Geneva Customer Account Maintenance Help

Before billing can take place, the accounts to be billed, the products being taken by those accounts, and the price plans the products are taken under need to be set up (and managed) via Customer Account Maintenance. This Help file provides detailed information about the use of Customer Account Maintenance and should be used in conjunction with the user application itself. Geneva Reports Guide

This guide details how to produce any required reports after the billing process has been completed.

Finance Figure 38 shows the order in which the documentation should be read when dealing with the financial aspects of Geneva.

~ ~ ~ ~ ~

~ ~ ~ ~ ~ ~ ~~ ~ ~ ~

~ ~ ~ ~

?

Accounts Receivable

?

Batch Payment Entry

~ ~ ~ ~ ~ ~ ~ ~ ~

~ ~ ~~ ~ ~ ~

~ ~ ~ ~

~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~~ ~ ~ ~

~ ~ ~ ~

~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~~ ~ ~ ~

~ ~ ~ ~

Output Data Finance Changes

Output Data Credit Control Changes

Output Data Payments Changes


Figure 38 Geneva Documentation Relevant to the Basic Day-To-Day Operation of Geneva – Finance

Geneva Finance Concept Guide

The financial aspects of Geneva are covered conceptually in this guide. It should be read before any action concerning finances is undertaken so that Geneva’s approach to topics such as contracts and disputes are fully understood. Geneva Credit Control Concept Guide

This guide contains conceptual information concerning the methods by which Geneva progresses through the dunning and collections processes. It should be read before embarking on any recovery action.


197


Geneva Accounts Receivable Help

Receivables, disputes, and adjustments across a range of accounts can be viewed and altered via Accounts Receivable. This Help file provides detailed information about the use of Accounts Receivable and should be used in conjunction with the user application itself. Geneva Payments Concept Guide

The way in which Geneva handles and processes payments is covered in this guide. Familiarity with the topics covered will assist in understanding Geneva’s payment allocation techniques, etc. Geneva Batch Payment Entry Help

Large numbers of payments of the same type can be entered into Geneva via Batch Payment Entry. This Help file provides detailed information about the use of Batch Payment Entry and should be used in conjunction with the user application itself. Geneva Reports Guide

This guide details how to produce any required financial reports.

Integration Figure 39 shows the order in which the documentation should be read when integrating Geneva with any third-party system.

~ ~ ~ ~ ~

~ ~ ~ ~ ~ ~ ~~ ~ ~ ~

~ ~ ~ ~

Output Import Data and Changes Export of Data

I

ALL interfaces

I

ALL schemata

Figure 39 Geneva Documentation Relevant to Integrating Geneva with Any Third-Party System

Geneva Import and Export of Data Concept Guide

This guide covers aspects of Geneva such as legacy system data and the import/ export of configuration data. It is essential to read this guide before attempting any third-party integration. In addition to a complete understanding of the way in which Geneva operates, it is recommended that all the interactive and schemata documents are read when integrating Geneva with a third-party system. There are a variety of different ways in which Geneva can be integrated with other products and the interface documents cover each of the different types of interface in detail.

198


A

Distributed Revenue Processing This section describes features which are only available if you have a Geneva Enterprise Edition license.

GEE

Geneva Distributed Revenue Processing provides the operational environment to support the central management of a multimachine configuration of Geneva. Geneva Distributed Revenue Processing provides the following key benefits: y

Cost-efficient scalability.

y

Reduced hardware costs.

y

Reduced database license costs.

y

High system availability.

Figure 40 shows the general architecture of systems using Geneva Distributed Revenue Processing. In this model, instances of the Active Rating Engine run on remote servers, while all other volume processing applications run on the same machine as the Geneva database.

Active Rating Engine

Task Master

Host 2

Volume processing applications


Geneva database

Host 3 Host 1 LAN

Figure 40 Geneva Distributed Revenue Processing

The improved efficiency and performance that Geneva Distributed Revenue Processing provides lets Geneva operators introduce new services that place much higher demands on the rating process, for example providing pre-authorization for m-commerce transactions, and immediate pricing for new prepaid services.


199


Geneva Enterprise Edition The Geneva Enterprise Edition provides features available to address the requir ements of large Geneva operators with respect to performance, scalability, robustness, and cross-functional integration. Geneva Enterprise Edition functionality cannot be used without a Geneva Enterprise Edition license (as opposed to a Geneva Standard Edition license). The Geneva Enterprise Edition provides the following functionality: y

Multimachine implementation of Geneva Distributed Revenue Processing.

y

Split database using a separate events database.

Geneva Enterprise Edition Within Documentation Geneva Enterprise Edition functionality is described throughout Geneva documentation preceded by the following disclaimer:

GEE

This section/chapter/appendix/documentation describes features which are only available if you have a Geneva Enterprise Edition license.

Event Database GEE


Geneva’s COSTEDEVENT table is a very large table that stores all live events within the Geneva system. However, since this table does not need to be constantly available, it can be stored in a separate database or remotely on a separate machine. This significantly reduces the size of the machine needed to host the core Geneva system and in turn reduces deployment costs. When the COSTEDEVENT table is stored in a separate database (or remotely) it is essential that Geneva has immediate access to the table. Oracle provides a number of ways of linking the data between the two databases: y

A separate connection to a second database.

y

An Oracle database link between the two databases.

y

Using a messaging system to move the events between the two systems. The COSTEDEVENT table, when it is being stored separately to the rest of the Geneva schema, is stored in the event database. Other tables that are closely related to COSTEDEVENT should also be moved over to the event database to reduce network traffic and reduce the storage space for the Geneva database.

200


A – Distributed Revenue Processing

If a Geneva event database is being used, events that have passed through the Geneva rating process are passed to a persistent Oracle queue. If the event database is available, these events can be loaded into the event database. If the event database is unavailable, these events are effectively buffered until the event database is again available. User applications, stored procedures, and volume processing applications attempting to access an unavailable event database will return an error. Figure 41 shows an example configuration for a separate event database being run on a remote machine.

MACHINE X

MACHINE Y

DATABASE LINKS

GENEVA DATABASE

EVENT DATABASE QUEUES

Figure 41 Example Architecture for Separate Event Database on Remote Machine

For example, a Geneva system requiring high availability can maintain parallel versions of the Geneva database on separate machines with a single instance of the event database on another machine. This will allow constant Geneva availability if machines become unavailable (for example, for maintenance): y

If the machine containing the main Geneva database requires maintenance, the parallel version of the Geneva database can be used. Events are passed to the event database as usual.

y

If the machine containing the event database is offline for maintenance, events are buffered on the machine containing the main Geneva database until the event database is available.

Geneva ensures that performance is not degraded when COSTEDEVENT is on a separate machine. Having a separate event database is completely independent of remote rating hosts, domains, and caches as described in the remained of this Appendix.

Remote Rating Hosts In a Geneva Distributed Revenue Processing configuration, a Geneva installation may be divided across a number of physical machines, by distributing Active Rating Engines across separate machines from the Geneva database server. Figure 42 illustrates this. This strategy allows a Geneva operator to minimize the effect of the failure of any single


201


machine in the installation, by allowing the work to be distributed (or redistributed) to othe r machines. For example, failure to a single machine used as a rating host will not affect the ability of other rating hosts to continue processing in the normal way. Active Rating Engine availability can therefore be increased by the deployment of multiple rating hosts.

GENEVA DATABASE

Rating Host Active Rating Engine


LAN

Account, bundle totals

Costed events

Rating Host Active Rating Engine


LAN

Figure 42 Example Rating Architecture for Remote Rating Hosts

Refer to the Geneva Distributed Revenue Processing Concept Guide for more details on specific Geneva Distributed Revenue Processing configurations for high availability.

Domains and Domain Routing GEE


Domaining allows Geneva to route events to a particular rating host dependent on the domain associated with each event via the event source. This means that specific machines can be dedicated to process certain subsets of the customer base. Streaming events into groups that correspond to a subset of the customer information allows a collection of machines with reduced memory requirement to handle a large customer b ase and high event volume that would otherwise require one or more machines with a higher specification. Streaming events in separate domains is achieved via the Event File Distributor. Figure 43 shows domaining with two rating hosts, each serving a single domain.

202


A – Distributed Revenue Processing

GENEVA DATABASE

Rating Host (Domain A) Events for domain A



LAN

Event File Distributor

Account, bundle totals

Costed events

Rating Host (Domain B) Events for domain B

Domain information



LAN

Domaining information

Figure 43 Example Rating Architecture for Multiple Rating Hosts Showing Domaining

The Active Rating Engine utilizes a high throughput stream, where events do not require responses and can therefore be grouped up into large batches so that a greatly increased number of events can be processed every second. The efficiency of domaining is greatly enhanced via the implementation of caches. For more information on caches see "Shared Cache," page 203.

Shared Cache Multiple Active Rating Engines running on the same machine (rating host) can share a single multiprocess cache, thereby allowing more information to be cached where multiple rating processes run concurrently. Figure 44 shows domaining with two rating hosts, each with its own cache, and each serving a single domain.


203

Geneva Product Overview

Recommend Documents