11cref us - concepts guide (bill and full) - r41

Highdeal Transactive R4.1

(Bill and Full)

Concept Guide

Edition 1

HighdealSolution

The Highdeal Transactive® solution is a registered trademark of Highdeal.

Copyright© 2008 Highdeal SA and Highdeal Inc. All rights reserved.

The contents of this document and related software are the property of Highdeal SA and Highdeal Inc. and are protected by copyright.

Any reproduction, in whole or in part, is strictly prohibited.

For additional copies of this document, please contact Highdeal.

Other Solutions Solaris®, MySQL®, the name Java, other designations for Java and the Java logos are trademarks or registered trademarks of Sun Microsystems, Inc. or its subsidiaries in the United States and other countries.

SPARC© is a registered trademark of SPARC International, Inc®.

Red Hat Enterprise Linux® is a registered trademark of Red Hat, Inc in the U.S. and other countries.

Linux® is a registered trademark of Linus Torvalds.

AIX® is a registered trademark of IBM Corporation.

HP-UX® is a registered trademark of the Hewlett-Packard Company.

Microsoft®, Windows®, Windows Server 2003®, Windows XP® and the Windows logo are trademarks or registered trademarks of Microsoft Corporation.

SQL Server™ is a trademark of Microsoft Corporation.

Oracle® is a registered trademark of Oracle Corporation and/or its affiliates. Other names may be trademarks of their respective owners.

EZTax® is a registered trademark of BillSoft, Inc.

Cryptix is a trademark of The Cryptix Foundation Limited.

Highdeal Transactive may include software developed by the Apache Software Foundation ASF (http://www.apache.org/).

Any brands, trade names or product names are trademarks or registered trademarks of their respective owners.

Concept Guide Edition 1

http://www.apache.org/

Table of Contents

Preface About the Highdeal Transactive Concepts Guide......................1

Reader’s Guide .............................................................................................3

Documentation Overview ..............................................................................5

Core Documentation Set ..........................................................................6

Conventions ..................................................................................................11

Chapter 1 Highdeal Transactive Overview.................................................13

Highdeal Transactive Functional Overview ...................................................15

Stateless and Stateful Modes........................................................................21

Module Interaction.........................................................................................23

Graphical User Interface Overview................................................................25

Starting a Work Session...............................................................................29

User Administration ..................................................................................30

Objects in Highdeal Transactive...............................................................32

Organizing Projects in a Catalog..............................................................34

Chapter 2 Price and Rate and Balance Management Concepts - Products,

Copyright© 2008 Highdeal

Price and Charging Plans, Charges ..........................................37

Creating Your Offer .......................................................................................39

Representing Your Supply Chain ..................................................................41

Price and Rate Actors ..............................................................................43

Products and Services ..................................................................................45

The Product..............................................................................................46

Chargeable Items .....................................................................................47

Chargeable Item Properties .....................................................................48

Product Example ......................................................................................49

Account Balance Management .....................................................................51

Charges.........................................................................................................53

Charge Overview......................................................................................54

Master Charge..........................................................................................57

Dependent Charge ...................................................................................59

Price Plans, Charging Plans and Pricing Macros ..........................................63

Price Plan and Rating Tree ......................................................................64

Rating Tree...............................................................................................65

Price Plan Component Overview .............................................................67

Charging Plan and Charging Tree............................................................69

Charging Tree ..........................................................................................70

Charging Plan Component Overview .......................................................72

Rating Context Overview..........................................................................74

Prerating, Reservation and Postrating Overview .....................................75

Session-Based Rating and Reservation Overview...................................77

Rerating....................................................................................................79

Counter Overview.....................................................................................81

Parameter Overview.................................................................................83

Pricing Macro Overview ...........................................................................84

Translation Table Overview......................................................................85

Pricing Policy: Application Example .........................................................86

Chapter 3 Price and Rate and Balance Management Concepts - Offers, Sub-

Concept Guide (Edition 1)iiCopyright© 2008 Highdeal

scriber Accounts, Subscriptions, Shared Plans.........................91

Offers.............................................................................................................93

Offer Overview .........................................................................................94

Creating Offers .........................................................................................97

Characteristics of Charges .......................................................................99

Setting Up the Charges ............................................................................102

Setting Up Sub-Offers ..............................................................................106

Making Changes in Offers........................................................................107

Offers: Application Example .....................................................................109

Subscriber Accounts .....................................................................................113

Subscriber Account Overview ..................................................................114

Creating and Setting Up Subscriber Accounts .........................................115

Prepaid Accounts .....................................................................................116

Postpaid Account Links ............................................................................118

Credit Limit Balances ...............................................................................119

Subscriber Accounts: Application Example..............................................120

Subscriptions.................................................................................................123

Subscription Overview..............................................................................124

Subscription Structure ..............................................................................127

Customizing Subscriptions .......................................................................129

Setting Up Activated Charges ..................................................................134

Setting Up the Charging Mapping of Charges..........................................135

Making Changes in Subscriptions ............................................................136

Subscriptions: Application Example .........................................................138

Shared Plans.................................................................................................141

Shared Plan Overview..............................................................................142

Example 1: Telephone Subscription.........................................................145

Example 2: Commission Received on Plan .............................................149

Example 3: Internet Connection ...............................................................152

Example 4: Shared Minutes Plan .............................................................156

Example 5 Favorite Numbers...................................................................161

iiiHighdeal Transactive® R4.1 (Bill and Full)Copyright© 2008 Highdeal

Chapter 4 Bill, Settle & Report Concepts ...................................................173

Creating the Bill, Settle and Report Environment ..........................................175

Billing and Settlement Concepts ...................................................................177

Bill, Settle and Report Actors ...................................................................178

Hierarchical Structures .............................................................................179

Postpaid Accounts....................................................................................180

Postpaid Account Partition Groups ..........................................................183

Cycle ........................................................................................................185

Isolated Invoices.......................................................................................187

Taxes........................................................................................................192

Discounts..................................................................................................194

Invoice/Settlement Report Discount Example ..........................................196

AML Reports ............................................................................................198

Correcting Transactions ................................................................................201

Rerating Subscriptions ..................................................................................203

Managing Disputes........................................................................................207

Concept Guide (Edition 1)ivCopyright© 2008 Highdeal

Chapter 5 Accounts Receivable & Payable Concepts ...............................211

Accounts Receivable and Payable Module ...................................................213

Accounts Receivable and Accounts Payable in Highdeal Transactive ....214

Getting Acquainted with the ARP Module ................................................216

Payment Processing ....................................................................................219

Payment Processing Overview ................................................................220

Call for Payment Management.................................................................222

Payment Information and Service Provider Payment Settings.................225

Payment Terms Management ..................................................................226

Payment Entry..........................................................................................229

Payment Reconciliation............................................................................231

Aging Reports................................................................................................233

Aging Reports Overview...........................................................................234

Aging Report Configuration ......................................................................235

Aging Steps ..............................................................................................241

Collections and Dunning ...............................................................................243

Collections and Dunning Overview ..........................................................244

Dunning Plans ..........................................................................................245

Collection Process....................................................................................248

Writing Off Bad Debt ................................................................................251

Chapter 6 Price and Simulate - Simulation Process and Concepts ..........253

Simulation Overview......................................................................................255

Steps in the Simulation Process....................................................................257

Simulation Concepts .....................................................................................259

Modelled Customer Profile Simulation .....................................................260

Real Customer Profile Simulation ............................................................264

Simulation Results....................................................................................265

Example of a Modelled Customer Profile Simulation ...............................266

Index..........................................................................................269

vHighdeal Transactive® R4.1 (Bill and Full)Copyright© 2008 Highdeal

Preface

About the HighdealTransactive Concepts Guide

This chapter describes the purpose and intended readers of the Highdeal Transactive Concepts Guide and presents an overview of the guides that make up the Highdeal Transactive product documentation set. In addition, this chapter presents the conventions and abbreviations used throughout the Highdeal Transactive documentation.

This chapter contains the following sections:

Section Page

Reader’s Guide 3

Documentation Overview 5

Conventions 11


About the Highdeal Transactive Concepts GuidePreface

Concept Guide (Edition 1)2Copyright© 2008 Highdeal


Reader’s Guide

Purpose of this Guide The Highdeal Transactive Concepts Guide presents a general overview of the concepts and functionalities of Highdeal Transactive and its modules:

Price and Rate

Balance Management

Bill, Settle and Report

Accounts Receivable and Payable (*)

Price and Simulate (*)

Connector Framework and Toolset (IEC) (*)

BART (Batch Acquisition & Rating Toolset) (*)

Web Customer Care (*)

Web Services (*)

StreamServe (*)

BillSoft EZTax Connector (*)

SNMP (*)

Diameter (*)

(*) All these modules are optional

You can use this guide as a reference when working with the software in order to understand the general concepts and functions of the software and its platform.

Anyone who will work with, install, or program Highdeal Transactive and any of its modules can benefit from this description of the concepts and structure of Highdeal Transactive.

Orientation The chapters in this guide are presented as follows:

Chapter Name of chapter

Chapter 1 Highdeal Transactive Overview

Chapter 2 Price and Rate and Balance Management Concepts - Products, Price and Charging Plans, Charges

Chapter 3 Price and Rate and Balance Management Concepts - Offers, Subscriber Accounts, Subscriptions, Shared Plans

3Highdeal Transactive® R4.1 (Bill and Full)Copyright© 2008 Highdeal


Chapter 4 Bill, Settle & Report Concepts

Chapter 5 Accounts Receivable & Payable Concepts

Chapter 6 Price and Simulate - Simulation Process and Concepts

Chapter Name of chapter



Documentation Overview

The user documentation set for the Highdeal Transactive software solution consists of printable PDFs and online Help. The main purpose of this technical documentation is to guide you through a work session and allow you to quickly master the various functional capabilities of the software suite, whether you are an end-user, administrator, integrator or developer.

Target Audience Each documentation is designed and written for specific reader(s) according on how he interacts with Highdeal Transactive.

ApplicationExamples

The task-oriented design of the documentation is complemented with a set of application examples. These examples not only illustrate the functionality of the software, but can also serve as a basis for customizing the existing configuration. The documentation set includes examples that are specifically designed to model product and pricing structures that are used in telecommunications, digital content or online service industries.

Please note that the PDF guides are formatted to be printed out recto-verso. Therefore, if they are printed on one side of the paper only, the guide may contain extra blank pages.



Core Documentation Set

The documentation set for Highdeal Transactive includes the following:

End-user documentation

Administration, installation & maintenance documentation

Integration & programmer documentation

Reference documentation

Release notes

Within each set, documentation is available in PDF format (compliant with Adobe Acrobat 5).

The PDF guides are available on CD-ROM and on the extranet site.

If you do not already have Adobe Acrobat Reader 5.0 (or later) installed, you can easily download it for free from the following site:

http://www.adobe.com/products/acrobat/readstep.html

The Highdeal Transactive installation CD-ROM contains a copy of Adobe Acrobat Reader in either French or English.


http://www.adobe.com/products/acrobat/readstep.html


End-userDocumentation

The following documentations are dedicated to end-users and operators of graphical user interfaces of Highdeal Transactive:

AdministrationDocumentation

This sub-set includes all the necessary documentations for managing: the installation, the configuration, the tuning, the maintenance, the troubleshooting and the monitoring of Highdeal Transactive.

Documentation Description

Concept Guide (*)

Presents a general overview of the concepts and functionalities of Highdeal Transactive. Anyone who will work with, install or integrate Highdeal Transactive can benefit from these descriptions.

Highdeal Transactive Desktop Tool Online Help

Presents an overview of the main concepts and functions of the following Highdeal Transactive functional modules:• Price & Rate • Bill, Settle & Report• Accounts Receivable & Payable

Includes a complete reference for using the components of price plans and charging plans.

Note: In addition, the online Help for the Desktop Tool features a tutorial and a glossary.

Highdeal Transactive Price and Simulate Online Help

Presents the simulator of Highdeal Transactive and how to do and to manage simulations to check and increase your profit. Includes a complete reference for using the components of price plans.

Web Customer Care Online Help

Allows Customer Support personnel to manage:• Interactions with customers• Customer information and contacts• Subscriptions and Accounts

ARP Web Interface Online Help

Allows management of:• Payments and Calls for Payment• Payment lines• Aging reports



It includes the following:

Consult also the reference guides on page 9. They detail the usage and the maintenance of specific programs of Highdeal Transactive.


Installation Guide A complete reference and procedures for installing and deploying Highdeal Transactive on your platform.

Administration & Maintenance Guide

A complete reference and guide for administering, operating, and monitoring Highdeal Transactive.

Parameter Reference (online) A complete reference for configuring the features of the Highdeal Transactive server (business level and system level). This reference is useful when installing, administering, monitoring, troubleshooting, integrating or programming with Highdeal Transactive.

Highdeal Transactive Tuning Guidelines (*)

Known guidelines and known best cases for fine-tuning your Highdeal Transactive platform.

Oracle Tuning Guidelines (*) Known guidelines and best cases for fine-tuning your Oracle RDBMS platform for Highdeal Transactive.

MS SQL Server Tuning Guidelines (*)

Known guidelines and use cases for fine-tuning your MS SQL Server RDBMS platform.

MySQL Tuning Guidelines (*) Known guidelines and use cases for fine-tuning your MySQL RDBMS platform.

Troubleshooting Guide (*) A reference for known problems, troubleshooting (levels 0 and 1), and solutions for server log messages. It contains information about how to contact Customer Support Services if you encounter technical difficulties using Highdeal Transactive.This document is available with the first upgrade release of Highdeal Transactive.

(*) Not included with the PRGA of Highdeal Transactive. Is delivered during the maintenance life.



ProgrammerDocumentation

This sub-set includes all the necessary documentations for managing the:integration of Highdeal Transactive in your global system,implementation of some services of Highdeal Transactive by programming your Java-based application or your application based on another technology that outputs xmltroubleshooting your developments using the APIs of Highdeal Transactive

It includes the following:

For troubleshooting purposes, the developer can refer to the online API Specification Reference (Javadoc) that details the programming exceptions.

ReferenceDocumentation

Highdeal Transactive includes several software components that are delivered with a reference documentation that is very useful for a large


Technical Reference Guide Describes the concepts behind Highdeal Transactive, the software architecture, the different rating processes, communication protocols, the APIs, the database schema, and an overview of how to work with AML templates.

APIs Reference (online Javadoc)

Specifications of the Java APIs and XML schemas used in Highdeal Transactive:• API operations • API data models • Error handling and Java exceptions

management

AML Reference Guide A complete description of AML (Aggregation Markup Language) used for building your reports by aggregating data from the Highdeal Transactive database

Database Structure Reference (online)

Database structure references for Highdeal Transactive and its elements in order to develop AML files.

Connector Administration Tool Online Help

Describes the use of the CAT (Connector Administration Tool) of the Connector Framework and Toolset commercial module of Highdeal Transactive that facilitates the integration of an import/export connector application.




audience from the end-users and administrators to the integrators and developers. This sub-set includes the following:

DocumentationUpdates and Errata

A new complete product documentation set is provided for each major or minor release of Highdeal Transactive.

The product documentation set is updated during the maintenance life of a main release of Highdeal Transactive. New publications of the online documentations are provided and synchronized with each maintenance release. New editions of each printable documentation are also published.

Between each edition of the printable documentations, documentation errata and documentation update sheets can be provided.

Documentation Fee The latest product documentation set is provided with the software. If a maintenance contract has been signed, the documentation update costs are included in the maintenance fee.

Feedback Please direct documentation feedback to [email protected].


BART Reference Guide A complete reference for this application software about the concepts (CDR, acquisition, batch rating), the architecture, the integration, the installation and the maintenance.

Diameter Server Reference Guide

A complete reference for this application software about the concepts (CDR, acquisition, batch rating), the architecture, the integration, the installation and the maintenance.

Web Customer Care Reference Guide (*)

A complete reference for this application software about the concepts, the architecture, the integration or the customization, the installation and the maintenance.

Web Services Reference Guide (*)

A complete reference for this software about the concepts, the architecture, the integration, the installation and the maintenance.




Conventions

This section presents the conventions and abbreviations used throughout the Highdeal Transactive documentation.

Basic Conventions The following styles are used when referring to certain parts of the interface and can be found in the text of this guide:

Abbreviations The user reference guides contain the following abbreviations:

Style/Symbol Meaning

GUI elementIndicates text or a button that appears in the graphical user interfaceExample: Click OK.

CodeIndicates code to be used in APIs, AML document templates, system commandExample: public void Create(String ID)

>Indicates a menu choiceExample: “Select File > Open” means “select the File menu, then select the Open choice on the File menu.”

Link Indicates an active link in PDF or online documentation

Abbreviation Meaning

API Aplication Programing Interface

CAT Connector Administration Tool

CRM Customer Relationship Management

CSR Customer Service Representative

CSV Comma Separated Value

ERP Enterprise Resource Planning

GUI Graphical User Interface

IEC Import Export Connector (Framework+Toolset)



Pictographs Some information may need your special attention. The following pictographs are designed to stress this information:

The screen captures used in the product documentation were made from Highdeal Transactive running on a Microsoft Windows platform. Therefore, the images in this documentation may differ from those found in Highdeal Transactive running on a UNIX platform. In the same way, the screens that you see may also differ depending on which configuration of Highdeal Transactive you are using.

Pictograph Meaning

Warning - Follow the instructions that are provided to avoid improper functioning of the software or loss of data

Tip - Follow this advice in order to speed up the procedure and make your work session more efficient

Note - Read this note for further explanation or important information about a function of the software

New - Draws attention to a new function of Highdeal Transactive


Chapter 1

Highdeal Transactive Overview

This chapter presents an overview of Highdeal Transactive, including a description of its functionalities and graphical user interface, as well as a brief explanation of its techincal composition.


Section Page

Highdeal Transactive Functional Overview 15

Stateless and Stateful Modes 21

Module Interaction 23

Graphical User Interface Overview 25

Starting a Work Session 29


Highdeal Transactive OverviewChapter 1



Highdeal Transactive Functional Overview

Highdeal Transactive enables e-businesses to achieve real-time and dynamic rating of services delivered and to compute what is due to the various parties involved in the supply chain according to an agreed, a value-based economic model.

Modules Highdeal Transactive consists of modules that integrate the key functions of pricing, rating, billing, accounts receivable and payable management, and customer care. These integrated functions support the strategic execution of business-to-business e-services. This level of integration enables service providers to implement price plans instantly, effect changes in real time, and roll out same-day services upon request.

The Highdeal Transactive modules are as follows:

Price and Rate

Balance Management


Accounts Receivable and Payable (*)

Price and Simulate (*)

Connector Framework and Toolset (IEC) (*)

BART (Batch Acquisition & Rating Toolset) (*)

Web Services (*)

Web Customer Care (*)

BillSoft EZTax Connector (*)

Transactive SNMP Agent (*)

StreamServe Reprint (*)

Radius Server Customization (*)

Diameter Server (*)

(*) All these modules are optional

A module can include one or several applications. For more information about these modules, consult the Installation Guide for details about the items you need to install and configure.

The graphical user interface of Highdeal Transactive is known more simply as the Desktop Tool.



Graphical UserInterfaces

There are two kinds of graphical user interface (GUI) in Highdeal Transactive: one type for desktop applications and one type for Web-based applications:

Price & Rate This module lets you implement and customize new services and pricing structures. Price and Rate also handles agreement management, dynamic pricing, product and promotional launches, and supports customized offers in real time.

Balance Management The Balance Management adds prepaid features to Highdeal Transactive and:

Manages the charging plans

Holds subscriber accounts

Controls the addition or deduction of monetary or non-monetary amounts from accounts

Performs credit reservation on accounts

Manages counters applicable for accounts

Manages credit limit balances, prepaid and postpaid accounts

The GUI for this type of application

Is used with

Desktop user interface

Desktop Tool

Price and Simulate

Connector Administration Tool (CAT) of the Connector Framework and Toolset

BART (Batch Acquisition and Rating Toolset)

Web-based user interface (Billing or Full Edition)

Web Customer Care

Accounts Receivable and PayableWeb Interface



Bill, Settle & Report This module is designed for accounting, finance and business analysts, as well as for Customer Support personnel. In addition to billing and account management, Bill, Settle and Report can do the following:

Produce Invoices and Settlement Reports

Feed actual billing data back to Price and Simulate or to other elements of your system (such as CRM applications)

Generate reports based on this data for statistical analysis

Provide a framework for managing customer disputes

For additional functions related to billing, settlement and account management, you can install the Accounts Receivable and Payable module along with the Bill, Settle and Report module. Note that Bill, Settle and Report can function with or without the ARP module.

Accounts Receivableand Payable

This module lets you manage your Accounts Receivable and Payable, including the management of:

Payment terms

Aging reports

Payment entry

Payment processing of Invoice and settlement reports

Collections and dunning for overdue Invoice amounts

This module provides a complete solution for customers who prefer to have these functions integrated with their billing and settlement operations rather than relying on an external accounting package.

Price and Simulate This module provides a simulation tool for marketing and pricing managers, forecasters, and business analysts. Equipped with a graphical user interface, the tool allows you to develop accurate price plans by verifying price plan income and profitability profiles. Simulation is carried out with the help of either statistical functions using generic market data or real data from business activities already in operation.

ConnectorFramework + Toolset

(IEC)

Highdeal has developed connectors with some of the most commonly used applications in the ERP, Mediation, and financial markets. In addition, Highdeal has an advanced system of Java / XML Web Services APIs and a toolset for developing integrations that streamline the connector extension process for those services not currently included in pre-built connectors.

The module’s network interface allows access to usage data records in the Price and Rate server. The integration tool is a graphical interface that enables the user to design readers, which can be plugged into the



connector framework. This facilitates the implementation of interfaces between Highdeal and third party software such as CRM, Provisioning, or General Ledger applications. The integration tool can do the following:

Provide a basis for communication between input files or an external database and the Highdeal database (in order to enrich the Highdeal database)

Export files to external databases according to information in the Highdeal database

BART (BatchAcquisition andRating Toolset)

The BART module allows to acquire CDRs (Consumption Detail Records) and organize them in groups according to predefined characteristics. The groups of CDRs are then rated in batches. Natively integrated within Highdeal Transactive software suite, the BART module is designed to optimize any batch rating with the Highdeal Transactive Rating server. BART provides the following functionnality:

Asynchronous acquisition and rating

Duplicate detection

Supervision

Erroneous CDR management

Rerating and roll-back

Web Services This module is a comprehensive set of simplified operations dedicated to customer provisioning and account follow-up. These operations allow partners and Highdeal consultants to integrate Highdeal Transactive with other systems such as CRM, order management application, and so on.

Web Customer Care This module is a standalone application dedicated to common customer support operations. It supplies a web-based, customizable application designed for offering to Customer Sales Representatives a customer centric solution able to manage:

- Subscriptions

- Customers

- Contacts

- Billing paramete rs configuration

- Accounts

- Payments (including customer Disputes)



EZTax Connector Highdeal Transactive provides a pre-integrated solution for calculating US taxes in real time.

This solution requires installing a server application on the machine that hosts BillSoft EZTax®. For each transaction rated by Highdeal Transactive, BillSoft EZ-Tax® is called in real-time to calculate the tax. Highdeal Transactive stores then the rated and taxed transactions in database for future billing or reporting.

Transactive SNMPAgent

Highdeal Transactive can be administered in a standard way through system management systems using SNMP. This makes it easier to integrate the system within a customer's information system.

Some administration functions are available through SNMP such as starting and stopping the server remotely, monitoring some system statistics, or reconfiguring the system.

StreamServeTM The Highdeal solution contains a native integration of the document edition tool, StreamServeTM. This tool converts all types of file formats and integrates any information handled by electronic distribution systems (for example, e-mails). StreamServeTM is used together with the Highdeal solution for editing invoices in a format specified by invoice printers (Postscript, PDF, and so on). Any kind of messages, logos or schemas may be added to the invoice. Any text label used in the invoice may be set up by StreamServeTM which supports all languages and alphabets.

Radius ServerCustomization

The RADIUS protocol authenticates and follows up accounting events for end-user service consumption. RADIUS is the acronym for Remote Access Dial In User Service. RADIUS is a fully specified authentication and accounting protocol.

Diameter Diameter, the successor to the RADIUS protocol, is a computer networking protocol for Authentication, Authorization and Accounting (AAA). Diameter Server is intended to receive CCRs (Credit Control Request) from a Diameter client and translate them into a suitable format for the rating engine. This server can be customized to deliver specific answers according to customers needs.



Stateless and Stateful Modes

Stateful and stateless are adjectives that describe whether a computer or computer program is designed to note and remember one or more preceding events in a given sequence of interactions with a user, another computer or program, a device, or other outside element. Stateful means that the computer or the program keeps track of interactions, usually by setting values in a storage field designated for that purpose. Stateless means that there is no record of previous interactions. Each interaction request is entirely processed from information that comes with it.

Stateless StatelessMode

Stateless rating is a service provided by Highdeal Transactive to your client application. The stateless rating feature means that during the rating process, the state of Highdeal Transactive does not change. In this mode, Highdeal Transactive does not use, modify or keep any data in its database after rating.

States of subscriptions, counters for example, are stored and maintained in an external system outside Highdeal Transactive. The rating engine runs as a basic ‘calculator’. This rating process corresponds to the 3GPP “Class A rating definition”.

In stateless mode, you cannot use objects such as offers, subscriptions and dependent charges.

Stateful Mode Highdeal Transactive maintains the states of subscriptions, parameters or counters for example, and updates counters when the rating is confirmed. In this mode, Highdeal Transactive uses, modifies or keeps data in its database after rating. Stateful rating corresponds to the 3GPP “Class B rating definition”.

In stateful mode, you can use any of Highdeal Transactive's objects.

Stateless RatingOperations

If you need a rating engine to calculate charges and rates without managing subscriptions and their context, Highdeal Transactive provides a set of stateless APIs allowing you to use the advanced capabilities of the Highdeal Transactive rating engine.



Module Interaction

The modules of Highdeal Transactive are designed for fast and easy pricing, rating, billing and settlement. Connectors between modules, as well as between Highdeal Transactive and any existing platform or infrastructure, allow for the continuous flow of information and work processes through the simple transfer of XML files.

Forecast ProductRevenue

Before going to market, you can use the Price and Simulate module to model your product and price plan so that you can forecast and test the revenue potential of different price parameters and service bundles. You can save and deploy simulated price plans at any time by exporting them into the production database used by Price and Rate.

The ProductionProcess

Once the system is in production, the rating engine does the following:

Receives information tickets (from mediation and collection systems) based on usage

Transforms information tickets into transactions (*) after calculating the amount based on service usage and identifying the account to be charged

Updates the balances of prepaid accounts

Sends transactions to Bill, Settle and Report for the generation of the invoice and report

To decrease volumes stored in the Bill, Settle and Report and prepaid databases and improve performance, Highdeal Transactive allows you to choose the content of the transactions through the use of a filtering mechanism.



(*) Transactions cannot be created in stateless mode.

Data Simulation When you want to create new Price Plans and Products, you can run simulations featuring a new Offer with the actual billing data in Price and Simulate. This helps you fine tune your business plan based on a real life scenario.

With Highdeal Transactive, you can mix real usage data with simulated usage data to create the exact scenario you want to test. If you do not use Bill, Settle and Report for your billing, you may also import usage data from another billing system.

In either case, the operation consists of sending a query to the database which specifies the usage data you require, transferring this information to an XML file, and then loading this XML file into Price and Simulate. You can repeat this process many times for new simulations.



Graphical User Interface Overview

The GUI of Highdeal Transactive is specially designed to be handled by persons directly involved in the process of planning, analyzing, testing and getting new business plans to market.

GUI for DesktopApplications

The GUI for desktop applications features object-oriented copy-paste methods for building price plans and product descriptions as well as visual representations that are easily interpreted and handled by the user.

Other Desktop GUIVersions

The GUI for desktop applications consists of four versions:

Desktop Tool

Price and Simulate

Connector Framework and Toolset

BART (Batch Acquisition and Rating Toolset)

Decision TreeRepresentation

A decision tree representation of the price plan provides a global view of your plan. This approach facilitates a deterministic approach to calculating transaction values and provides a visual representation of the price plan.

Intuitive WorkSession

When you manipulate objects, the GUI indicates the state of these objects in relation to the database. You know instantly if the object you are working on is:

A new object

An object that is already recorded in the base

An object that is in the process of being modified

The GUI also manages possible actions in the context of your rights as a user and your progress in the work session.

Possible Operations The GUI permits typical actions on objects, such as creation, content verification, modification and deletion. In addition, actions on objects can be by unit (a single object at a time) or bulk (multiple objects at the same time). In this way, a large number of repetitive operations of a similar nature, essential during bulk development or corrections, can be completed in a single action.



Bulk Processes Unlike bulk operations, you start bulk processes without selecting criteria like accounts or account holders but by selecting a date and/or a service provider. You can use bulk processes with the following:

Invoices (creation, edition)

Calls for payment (creation)

Collection files (update)

Bulk Operations You can use bulk operations to modify or delete objects in bulk with the following:

Subscriptions (all Desktop Tool modules)

Parties, Accounts, transactions, Account operations, Invoices, Settlement Reports and Disputes, as well as different types of discount (Bill, Settle and Report and Accounts Receivable & Payable only)

Collection Files (Accounts Receivable & Payable only)

Search and Filter The search and filter actions available to you in the Desktop Tool GUI are based on two types of search mechanism in the database. These mechanisms vary depending on the object. You can search for objects by using the following:

An object storage system called a catalog

Multicriteria filters that allow you to describe the characteristics of the objects for which you are looking

Bulk operations are always based on multicriteria filters.

User Access Control Highdeal Transactive allows you to track operations in the system and assign user rights according to authorized accesses.

Accesses and control rights can be restricted according to filters. For example, a list of authorized accesses can consist of geographical areas divided into two levels: the first level is made up of countries (United States, Canada, and so on), and the second level is made up of regions belonging to a country (Michigan, Ohio, and so on). The administrator can set up the filters in order to allow the user to work only with clients relating to a vendor assigned to a specific region.

User rights authorize users to carry out certain operations and correspond to the type of tasks to be performed by the user. The audit function allows you to monitor operations that are currently being carried out in the system.



The list of authorized accesses is customized and set up before installation of Highdeal Transactive. Ask your System Administrator for more information.

Web-Based GUI The Web-based GUI provides a customizable application allowing Customer Sales Representatives to focus on customer-centred business and simplify customer support operations. You can use the following Web-based GUIs:

The Web Customer Care application for managing:

Customers

Orders

Account operations

Disputes

The Web ARP application for managing:

Accounts

Payments

Payment information

Calls for payment

Collections files

Aging reports



Starting a Work Session

When you start a work session in Highdeal Transactive, your login and password identify you as a certain type of user. This gives you access rights to certain operations according to the role defined for you by the System Administrator. See the User Access Control section.

You can then begin working with the objects you define in Highdeal Transactive, and store them in the database.



User Administration

In order to preserve the integrity of the system, Highdeal Transactive allows you to limit each user’s range of action.

User Roles A user is any person who is authorized to work with Highdeal Transactive and who is assigned one or more roles in the organization. Roles are predefined levels of authorization that grant users specific access and control rights within the system. The various roles that are available and the level of authority associated with each is listed in the table below:

Role Authorized domain Authorized action

Administrator All All actions

User Administrator Users Create and modify user password or roles

Customer Sales Representative (CSR)

Subscriptions

Create and delete:• Subscriber accounts• Subscriptions• Accesses

Display:• Products• Pricing macros • Translation tables• Charges• Offers• Subscriptions• Accesses

Marketing

Offers

Create, modify and delete:• Products• Pricing macros • Translation tables• Charges• Offers



In Price and Rate configuration, Bulk Operations on Subscriptions are only available in the “Administrator” role.

In Bill, Settle and Report and Accounts Receivable and Payable configurations, Bulk operations on Subscriptions, Rerating, and Recharging functions are only available in the “Administrator” role.

(*) The roles “Financial Adminstrator” and “Collections Manager’ are only available if you have installed the Accounts Receivable and Payable module.

Perimeter settings You can define functional authorized accesses (‘regions’ for example: Michigan, Utah, and so on) based on filters in order to restrict access to a set of customers and their related data. When the authorized access policy is defined and imported into Transactive, you assign one user to one authorized access. A user can have several roles (Customer Sales Representative, Marketing, and so on) and can perform related tasks and the allocated authorized access The user will have access to all objects (Accounts Party information, Subscription details…) associated with a specific authorized access If no authorized access is assigned, the user has access to all information. Defining the authorized accesses is described in the Installation Manual.

Account Manager


Create, modify and delete:• Parties• Postpaid Accounts• Discount Templates• Transaction Patterns• Disputes• Dunning SettingsAll Bulk operations of Bill, Settle and Report

Financial Administrator (*)

Accounts Receivable and Payable

• Edit, create, modify, and register payments

• Edit payment information / settings

• Edit Calls for Payment• View Aging Reports• View Account

Collections Manager (*) Accounts Receivable and

Payable

Create, modify, add and delete:• Collection Files• Dunning Steps

Role Authorized domain Authorized action



Objects in Highdeal Transactive

Highdeal Transactive is an object-oriented software program. You can manipulate main objects in the menus of the main windows of the desktop applications of Highdeal Transactive. You can create, open or delete all objects from the File menu of the main window.

Each object is represented by a specific icon. This icon allows you to identify the object in lists and to identify the windows that display the object’s content.

The following table presents the main objects and their corresponding icons used in Highdeal Transactive:

Object name Icon

Access

Audit

Charge

Discount Template

Offer

Party



Offers, subscriber accounts and subscriptions cannot be used in stateless mode, but only in stateful mode.

Postpaid Account

Postpaid Account Partition Group

Pricing Macro

Product

Subscriber Account

Subscription

Translation Table

User

Object name Icon



Organizing Projects in a Catalog

Catalog A catalog is a file storage feature which allows you to organize your work more efficiently. For example, it allows you to save all of your created objects in project-related files, such as Web mail service, Telephone service, and so on. You can then file them in a catalog of your own.

Catalog Contents A catalog contains information about objects related to pricing and rating: Products, pricing macros, translation tables, charges, offers, and discount templates. It does not, however, contain information about subscriptions, parties, accounts, users or audits.

Catalog Creation A catalog is a file storage feature used by Highdeal Transactive to help you organize your work more efficiently. You create a catalog for each service provider.Once a party with a service provider role has been created in Highdeal Transactive, a catalog is automatically generated and that party is the catalog owner. A catalog can consist of one or more directory files, but only one catalog may exist per party.

Catalog Deletion You cannot delete catalogs from the Desktop Tool once created. Administrators can delete catalogs using APIs.To delete a catalogue, you must first delete the party which is the catalog owner.

All Objects CatalogDirectory

The product, charge, pricing macro, translation table, discount template, and offer objects created in the system are automatically saved in a specific catalog called All Objects. This catalog is divided into five directories (folders), with each directory corresponding to a type of object.

You can add folders to the catalog structure, but you cannot change the structure itself.

Access to Objects The created objects are saved in the catalog directories (folders) and can be displayed by selecting their owner from the drop-down list. The existing objects are represented by their icons, and they appear below the catalog root.



Catalog ManagementTasks

When managing the objects in your catalog, you can perform the following tasks:

Verify that the catalog exists

Create a new directory

Rename a directory or object

Copy a directory or object

Delete a directory or object

View an existing object and modify it

Export a pricing/rating object

The procedures for the above tasks are presented in the remainder of this section.


Chapter 2

Price and Rate and BalanceManagement Concepts -

Products, Price and ChargingPlans, Charges

This chapter presents the features and functions in Highdeal Transactive that help you build your product, price plan, charging plan and charges, and accurately model your value chain.

This chapter contains the following sections.

Section Page

Creating Your Offer 39

Representing Your Supply Chain 41

Products and Services 45

Account Balance Management 51

Charges 53

Price Plans, Charging Plans and Pricing Macros 63


Price and Rate and Balance Management Concepts - Products, Price and Charging Plans, ChargesChapter 2



Creating Your Offer

Offers cannot be used in stateless mode.

Highdeal Transactive allows you to represent your service offer by creating a product. This is the first step in building your offer in Highdeal Transactive.

Your product will serve as the basis for your price plan and charges.

Once you have created a product, you can create price and charging plans in charges. The following table presents which concepts Highdeal Transactive uses for which task:

The price plan specifies rating formulas for a product. For each chargeable item in your product, you can define the rate that will be applied. You do this by putting into place the pricing components with all of the appropriate parameters.

The charging plan defines which accounts will be charged for or refilled with the amount of the service calculated by the related price plan.

Products, price and charging plans, charges and offers are elements that are essential to your business plan because they represent the core of your activity. Surrounding this core, individuals and companies play a role in the creation and consumption of your service. These actors, also represented in Highdeal Transactive, are presented in the following section.

In order to Highdeal Transactive uses the

build the pricing for your offer charge concept

describe how to calculate a price price plan concept

describe which accounts to charge charging plan concept



Representing Your Supply Chain

Highdeal Transactive is designed specifically for the e-services market in that it is capable of representing some of the most complex supply chains. The basis for this adaptability is the identification of every actor in the chain, its role, and its relation to other actors in the chain.

Actors in the SupplyChain

The role of each actor in the Highdeal Transactive system is particularly important with relation to subscriptions and offers. Each actor may take on one or more roles in the value chain, defined by the actions that they perform in the transaction. More specifically, each actor can:

Use the service

Pay for the use of the service

Sell the service

Buy the service to resell it with value added

Receive a commission for the sale of the service to a third party

Pay for part of the service consumed by a third party (for example, sponsorship) as well as by other kinds of relationships (for example, client/partner)

Value Chain In the context of the e-services market and in Highdeal Transactive, supply chains are called value chains because the product or service being sold has value added to it at each step of the supply chain.

In Highdeal Transactive, a value chain is represented by a series of additional payments linked to a primary relationship between the service provider and end user, such as a client or partner. This series of additional payments can be made among the different actors involved in a business relationship.

In real terms, in the case of commissions and sponsorships, price plans, charging plans and parameters are included in ‘dependent’ charges. price plans and parameters determine what sum is paid while charging plans determine who pays it, and who receives it. These aspects are determined at the time a transaction is carried out by a client.

Value Chain Example ActiveWatch, a business-to-business Internet service proposes a certain amount of information, including extended weather forecasts, to its clients. ActiveWatch gets its weather content from the National Weather Association (NWA). ActiveWatch then sells this information to various clients who range from shipping companies to travel agencies. For



example, ActiveWatch has signed up a shipping company, Acme Shipping, with five captains who each have access to its weather service.

With each one of these customers, ActiveWatch signs an agreement with certain conditions, including a price plan. The conditions surrounding this agreement take into account the payment due to the NWA for the use of its content. The payment is in the form of a commission calculated on the sales of ActiveWatch.

The following table presents the role of each player in the above-mentioned value chain:

Player Role

NWA Commissioned agent

ActiveWatch Service provider

Acme Shipping Client

Acme’s five captains Subscribers



Price and Rate Actors

Many actors are involved in the financial and commercial transactions linked to your activity. Depending on the situation, these actors perform different activities and play different roles. In a sales context, they are product service providers, account holders, and resellers who are directly involved in activities. In Price and Rate, these different sales roles are referred to as owner and client/partner, which can represent agents or sponsors.

Owner An owner is an actor who sells a commercial offer or product. In other words, an owner is a service provider. This actor is the owner of a catalog, which includes products, charges, and offers.

Client A client is an actor who subscribes to the service consumed.

Partner A partner is an actor to whom the service provider makes a payment in the form of a transaction.A partner is an actor to whom the service provider makes a payment in the form of a transaction that is charged on an account payable. A settlement report is generated by the service provider. A partner is not necessarily the account holder.

Agent An agent is an actor who receives a commission payment. An agent may be a service provider who has sold a core product to a reseller. The reseller then adds the company’s own service to it before reselling it as a value-added product. This is the classic scenario of a Value-Added Reseller (VAR).

The agent may also be the author or creator of content for which a commission is due. In this scenario, the agent is a classified as a partner rather than a service provider.

Sponsor A sponsor is a client who pays for a part of a service consumed by another party.



Products and Services

This section describes the basic Highdeal Transactive concepts associated with products and includes a definition and examples of the following concepts:

Product

Chargeable item

User property

Default property

The section also includes an illustration of these concepts as they appear in the software GUI.



The Product

The product is a basic software concept that is embodied by an object in the database and displayed in a specific window in the GUI.

Product Products are hard goods, applications, or services that you can buy and sell.

In Highdeal Transactive, a product represents a service whose usage can be rated. This schematic view reflects the method for pricing the product. The service characteristics used to calculate a rate and an amount to be billed are therefore part of the product.

This representation of a product provides an overview of the creation of charges and price plans. A product is also made up of chargeable items that allow you to expand and develop a given plan.

This icon represents a product in the Highdeal Transactive GUI.

Product Examples Product examples include the following:

Internet press services

Online tutorials

Telephone calls



Chargeable Items

A product contains one or more chargeable items.

Chargeable Item In Highdeal Transactive, a chargeable item is described in a product. The chargeable item represents an action or usage consumes by the customer.

The chargeable item describes product usage and actions that are likely to be rated. These actions can be cost-generating or free of charge. You can define all chargeable items needed to calculate your product pricing in the software.

To describe the pricing method, a chargeable item contains a number of properties.

Chargeable ItemExample

By using an Internet press service, consumers can do the following:

View articles online

Download articles onto their computers

The Internet provider may decide to price its press service based on the action the consumer chooses. In order to do this, the provider needs to create a “press service” product in Highdeal Transactive that contains two chargeable items:

Article view

Article download



Chargeable Item Properties

A chargeable item contains properties.

Chargeable ItemProperties

Each Chargeable Item contains properties that describe each usage event for rating.

These properties provide the data and outline for building your price plans.

Properties Examples An Internet Press service supplier chooses to price article downloads according to document size. The “download an article” chargeable item will contain the “document size” property.

A telecommunications operator chooses to bill telephone calls according to the called number. The “telephone call” chargeable item will contain the “called number” property.

Default Properties Chargeable items contain default properties that are always present and you cannot modify them. The default properties are:

consumption date

user identifier

service identifier

purchase identifier

User Properties In addition to default properties, you can also create user properties. The software allows you to define the user properties that you need for your pricing system.

You can define these properties by assigning the following:

Name

Type (character string, number, or date)

Description

User PropertyExample

A Press supplier chooses to charge the viewing of online articles according to article categories, such as daily newspaper, weekly review, specialist review, and user property for the “viewed article” chargeable item. This property type is “character string.”



Product Example

Imagine that you are the telephone operator TelcoServ and you sell telephone calls to your customers. You decide to charge these calls based on call length, but you want to apply different rates for different geographical zones.

In Highdeal Transactive, the above example will look like this:

Product in the GUI The following illustration shows the Telephone Service product after its creation in Highdeal Transactive:

Product Chargeable item

User property Property type

Telephone service Call

Number called Character string

Call Duration Number



Account Balance Management

The account balance management adds prepaid features to Highdeal Transactive and:

Holds subscriber accounts

Controls the addition or deduction of monetary or non-monetary amounts from accounts

Performs credit reservation on accounts

manages counters applicable for accounts

Benefits They are the following:

Offer a single platform to manage balances for all subscribers, independent of their payment method.

Support subscriber groups with sets of interrelated prepaid/postpaid balances, for example, for families or corporate customers.

Enable flexible configuration of spending caps, allowances, credit limits and service-specific wallets.

Manage dynamic charging where the balances to be charged are determined per transaction at runtime.

Ensure real-time, online operation with high performance and high availability.

Subscriber accounts Creating a subscriber account is the first step before creating any subscriptions. For more information, refer to the chapter Subscriber Accounts.

The subscriber account contains all the accounts which are debited or credited when a service is consumed. The accounts are the following:

Prepaid accounts

Postpaid accounts

Credit limit balances

Charging policy The charging policy identifies the charged account that will be debited or credited with the amount of the price plan. The charging policy is mainly based on the charging plan (refer to the chapter Price Plans, Charging Plans and Pricing Macros) and the charging reference mapping (refer to the chapter Subscriptions).



Charging process Coming from an external system to be rated, prerated or reserved, a usage event is processed in the following order: Identification, rating and charging.

1 Identification: The subscriber account and the main activation charge are identified from the user identifier, the service identifier and the usage date which are properties contained in the chargeable items of a product.

2 Rating: The rating (plan) is carried out and the related transactions are created.

3 Charging: The charging plan is carried out through the charging reference mapping. If no charged account is found, the default charged account is used. The related balances are debited (credit limit balances and prepaid accounts). If no threshold is reached, transactions are completed with the amounts of the impacted balances, and then saved.

If some dependent charges exist, identification, rating and charging are repeated for each charge. When all the charges are processed, all the transactions are sent to the external system, your billing system or saved to a CSV file.



Charges

Charges are essential for pricing offers. To create your initial offer, you will need to predefine the charges associated with the usage of the product in the offer.

This section describes and illustrates information you need to create charges. The information is presented in the following order:

Charges overview

Master charges

Dependent charges and related concepts:

Commission

Sponsorship

Discount

Third Party Billed Commission

Other

Pricing application example



Charge Overview

Charge A charge is an amount linked to the usage of a service or product. The amount is calculated using a set of instructions described in a price plan that is contained within the charge.A charge always includes a unique price plan.A charge is made up of a price plan and a charging plan. The price plan is a set of intructions calculating the amount linked to the usage of a service while the charging plan defines which accounts will be charged for or refilled with the amount calculated by the price plan.

This icon represents a charge in the Highdeal Transactive GUI.

Charge Example TelcoServ offers a Family package allowing to charge calls to a family or individual account depending on call destinations. The family Smith subscribed to the Family package allowing Mr and Mrs Smith's calls to be charged to a postpaid account while their son's calls are charged to a prepaid account. When John calls his parents, calls are charged to the postpaid account.

According to the illustration below, the price plan calculates the price of each call. After calculation, the amount of the price plan is charged to the Family account (postpaid account) or the Individual account (prepaid account).

The price plan contains a rating branch made up of a Usage Rate component combined with a Flat Function component to calculate the price of each call.

The charging plan contains a Usage Charging branch. This branch includes test actions which answer the following questions:

What is the phone number?

What is the call destination (Family or Individual)?

What is the account to be charged for?

These actions and decisions are carried out by using components that belong to a number of families. The charging tree looks like this:



Price and charging plans in the charge related to the familie Smith’s offer

RelationshipsBetween Charges,

Products, Price Plansand Charging Plans

The main rules governing relationships between charges, products, and price and charging plans are the following:

Charges always contain a unique price plan and a unique charging plan.

A price plan describes amount calculations.

A charging plan describes which accounts will be debited or credited.

Several charge versions can coexist in the database (in order to take into account changes in amounts related to products, for example). You can consult these charges which are distinguished by their modification date.

One product may be subject to several independent amounts that apply to the same product. The amounts can be described in different price plans included in separate charges.

A charge may contain all product-related amounts because the price plan itself can include all the pricing rules for the product. However, the more complex the charge, the less reusable it is.

Reusing Charges Charges are essential for pricing offers and can be used in several offers that are related to the same product. Charges can be seen as small pricing blocks attached to a product or group of products that exist independently of offers. When creating offers, you choose the charges you need in order to build the offers.



Triggering Charges Calculations described in the price plan of a charge do not run permanently. The calculations are only conducted when prices plans are triggered by one of several events:

Arrival of a usage ticket following service usage

An event applying to the subscription (creation, cancellation, suspension, resumption) or a recurring event, depending on the offer

The triggering of another charge’s master charge

Charging plans are triggered by price plans.

Setting Up Charges By incorporating a charge into an offer, you can determine its function in the offer. In the context of the offer, this function constitutes an additional valid setup. You can also modify the charge. For example, if the price plan in a charge contains parameters or uses translation tables, you can modify these elements during the integration stage. You can also modify these elements in the subscription framework for a given customer.

When you modify and save a charge, you can access all previous versions

of it by clicking on the clock button on the toolbar. You can only delete a version by deleting all previous versions. You can delete all previous versions of a charge by modifying and saving your charge, then specifying an effective date earlier than the effective date of the original version. The same principle for modifying and deleting versions exists for offers, subscriptions, pricing macros and translation tables.

Charge Types A Charge may be a “master” or a “dependent” charge. The type is determined during the charge creation and cannot be modified at a later date.



Master Charge

Master Charge A “master” charge is a charge that is not synchronized with other charges. It is independent of other charges concerning its trigger mode and its calculation mode. It does not represent an associated cost such as commission paid on the sale of a product, sponsorship, or a derived cost such as a discount on a basic price (which varies depending on usage).

Example Learn.com offers its customers a range of online training materials. It buys tutorials from specialized authors, converts them into electronic format, and adapts them to e-learning. Customers can buy these training materials in modules and download them onto their computers. Costs may vary from module to module and can be determined by a module code. The “Purchase Module” charge is a master charge for the following reasons:

When a customer decides to buy a module, the cost self-triggers because it does not depend on any other event.

The price to be paid can be calculated in the price plan of the “Purchase Module” charge without requiring the intermediary calculation of another price plan. Customers choose their module when executing a download command: the module identifier or code is part of the rating context. Once the “Module Code” user property has been created in the product, this data may be used in the price plan of the “Purchase Module” charge to determine the price.

The table below summarizes this example:

Trigger Mode A master charge is triggered independently of other charges. If a customer decides to subscribe to a document consultation service, the corresponding “subscription” charge is triggered without depending on any other event. If the master charge has periodicity, this periodicity is not linked to any other charge.

Product Training Module

User Property Module Code

Charge Purchase Module

Type of Charge Master

Price Plan Module Download

Type of Rate Use



Calculation Mode A master charge contains the main price plan. The master charge can function using solely the property values of its rating context and does not require data calculated in another price plan. This charge represents a main amount that is agreed upon the product between the client and service provider.

Relationship Type The relationship type allows you to choose whether the relationship with the service provider will be with a client or with a partner.

Operation Type The operation type allows you to specify whether to credit or debit the actors (who will be either a client or partner, depending on the relationship type the user selects).



Dependent Charge

Dependent charges cannot be used in stateless mode.

Dependent Charge A “dependent” charge is a charge synchronized with another charge. The dependent charge uses either the trigger mode or calculation mode of the other charge, or uses both modes simultaneously.

A dependent charge may depend on another dependent charge. In this case, the links between charges are translated into a series of descending dependencies.

Dependent ChargeExample

Private individuals can subscribe to Learn.com, a company providing a range of online documents. Learn.com buys documents from specialized authors, to whom it pays royalties in the form of commissions on received income. Commissions may be represented by a dependent charge linked to the master charge in the customer’s subscription.

The table below summarizes this example:

Trigger Mode A dependent charge can only be triggered when another charge is triggered. For example, when a customer pays subscription fees, a commission must be paid to a third party. Therefore the “Customer Subscription” charge triggers the dependent “Sales Commission” charge.

Calculation Mode A dependent charge calculation can be linked to another calculation. The price plan of a dependent charge therefore depends on another price plan that is integrated in a different charge. This dependency may concern an amount that must first be calculated in the main price plan before it can be used by the dependent plan.

Product Charge Type of Charge

Price Plan Type of rate in the Price Plan

Document

Document Subscription Master Customer

Subscription Recurring

Sales Commission Dependent Author

Payment Recurring



Example Customers can download reference documents from Learn.com onto their computers. Downloading costs vary according to the module and document volume. Learn.com must pay the document authors a commission equal to 5% of sales. You need to know the download amount to determine the amount of commission to be paid.

Roles If a dependent charge is part of an offer, it is assigned one of the following roles:

Commission

Third party-billed commission

Sponsorship (charged on an account receivable)

Discount

Other

A dependent charge is assigned its role when it is used in an offer and not when it is created. This means that the same dependent charge may play different roles in different offers.

Like a master charge, a dependent charge can be linked to a subscriber account through the charging mapping of a subscription. In this case, the related prepaid account or postpaid account link is debited or credited depending on the role of the dependent charge.

Commission Commission, such as a sales commission, is an amount paid to a third party. A commission is charged to an account payable and is paid to a single agent designated as "client\partner" in the postpaid account link.

Third Party BilledCommission

A third-party billed commission is an amount paid to a third party, to be charged to an account receivable issued by the third party. This type of commission can be paid to a single third party designated as "service provider" in the postpaid account link.

An example of this scenario is a third party who sends an invoice to a service provider because it would rather produce its own bill than receive a settlement report from a service provider.

Sponsorship Sponsorship is an amount paid by a third party to promote the sale of a product. Because product consumption costs are shared between consumers and sponsors, the service provider is partly paid by its customers (consumers) and partly paid by its sponsors. Sponsorship may be paid by a single sponsor designated as "client" or "service provider" in the subscriber account.



In this case, the transaction is charged to an account receivable between the sponsor and the service provider.

Discount A discount is an amount to lower the amount paid by a customer.

“Other” A dependent charge can also be assigned a customized role, known as “Other.” In this case, you need to configure certain parameters when setting up the charge. You must decide whether:

The client or partner will be credited or debited.

A new transaction will be created: For example, a commission generates a new transaction because there is an actor but a discount does not create a new transaction.

The relationship type is client or partner, which means transactions will be charged on accounts receivable or on accounts payable.

The master transaction will be adjusted: For example, a sponsorship adjusts a master transaction because the dependent charges do not affect the revenue for the service provider. The revenue corresponds to the amount originally calculated by the master charge, and the final amount to be paid by the customer will be adjusted accordingly.

Dependent ChargeSummary

The following table summarizes the parameters and fields for the different roles assigned to a given dependent charge. Note that the only parameters and fields that the user is free to configure are the parameters for the “Other” role:

Dependent charge roles and their corresponding parameters

Operation Create new transaction

Relationship type

Adjust master transaction

Commission Credit Yes Partner No

Sponsorship Debit Yes Client Yes

Discount Credit No n / a n / a

Third Party- Billed

CommissionDebit Yes Client No

Other Free Free Free Free



Price Plans, Charging Plans and Pricing Macros

This section describes basic Highdeal Transactive concepts related to price plans and includes definitions and examples of the following concepts:

Price plan and rating tree

Price plan components overview

Charging plan and charging tree

Charging plan components overview

Rating context

Prerating, reservation and postrating

Session-based rating and reservation

Rerating

Counters

Parameters

Pricing macros

Translation tables



Price Plan and Rating Tree

Price Plan A price plan is a set of instructions that computes the amount of a charge. It is graphically represented in the software by a tree called a rating tree.

The price plan is an essential part of Highdeal Transactive. This template is a basic structure for the charges and pricing macros objects.

For example, product pricing is described in a price plan, which provides precise details of the payment terms as defined by the service provider for a specified product.

This icon represents the price plan of a charge in the Highdeal Transactive GUI.

Please note that the term “price plan” does not appear in the graphical interface. Therefore, it is important for you to be familiar with the icon and the concept that it represents.



Rating Tree

The rating tree is a decision tree that shows the price plan. This tree has a “root” and “branches” for the different rates. The “leaves” provide the amount to be paid.

Tree Branches andRates

The root of each branch shows a Rate, which can be one of several types. Rate types are linked to rate activation methods.

The rating tree can contain several Rates. Each Rate has its own decision tree.

You can create each rating branch using several components, which form nodes in the branch. The components are combined and applied to price plan variables, resulting in the final price shown at the end point on the branch (the leaves of the tree).

Rating Tree Example You are the telephone operator TelcoServ who sells telephone communications. You invoice your customers’ telephone calls on a call-length basis. If the call is made during the weekend, the price is $0.17 cents/minute. If the call is made during the week, the price is $0.34 cents/minute.

Your price plan will contain a “Usage Rate” type branch. This branch will include several actions which answer the following questions:

How long was the call?

Was the call made during the weekend period?

What is the price to be applied?

You carry out these actions and decisions by using components that belong to a number of families and that are available in Highdeal Transactive.

Rating TreeIllustration

To describe the pricing of the telephone calls in the previous Fixed Telephone offer, you first use a Usage-type Rate. You then add three types of components.

Your rating tree will look like this:



Tree Root

Tree Branch - Usage RateThree Types of

Component

Tree Leaf



Price Plan Component Overview

Price PlanComponents

Price plan components are calculation tools you use to create a price plan or pricing macro. Together the components make up a rating tree. You use the rating tree in a price plan to calculate the cost of a charge.

To create a rating tree, select a Rate component, add components from other families according to your price plan requirements, and end each branch of the tree with a Function component.

Families of Price PlanComponents

When creating your price plan, you will use several types of components. To create the root of the tree, you always use a component from the Rate family. You can then use a variety of components. You can then use a variety of components that are grouped into the following families:

Rates

Comparisons

Operators

Splitters

Functions

Rates Components Rate components are always found at the root of the rating tree of a price plan. There are several types of rate available, depending on the activation of the Usage Rate. The following table shows the different rate types and the relevant activation:

The one-shot rate component is activated on a subscription-related event.

ComparisonComponents

A Comparison evaluates a property in the rating context and, depending on the evaluation results selects a price plan branch. The rating context may

Type of rate Activation Usage example

Usage Each usage Telephone call

Recurring Periodic Monthly fees

One-Shot Once only Administration fees



include chargeable item properties, parameters, counters, or properties generated by another component.

Several types of Comparison are available, depending on the type of property used for the comparison. For example, you can use a Numbers Comparator to compare the value of a numerical property with a constant value, and you can use a Date / Time Slot Comparator to compare a date property type with time slots.

OperatorComponents

An Operator can do the following in the rating context:

Modify counter values

Introduce new properties resulting from the calculation

There are several types of Operator. For example, the Duration Operator calculates the duration between two dates. This results in a new “numerical” property type. Another Operator can update the counters (variables) defined in the price plan.

Operators allow you to create and use multi-valued properties of string or number type. A multi-valued property of string type represents a list of string values. For example, the multi-valued string “ImageType” contains the following list: image/jpeg:5000, image/gif:10000, image/eps:25000, image/pic:8000. A multi-valued property of number type represents a list of numerical values. For example, the multi-valued number “ImageSize” contains the following list: 5000, 10000, 15000, 20000.

Splitter Components A Splitter divides a number or a duration into two parts. Each of these parts, which is available on a different branch of a Splitter, is then precisely rated. Unlike Comparisons, the two parts are added together.

There are several types of Splitter. For example, the Number Splitter splits an existing property relative to a number, and the Time Slot Splitter splits a period relative to time slots.

FunctionComponents

A Function calculates an amount from rating context properties. The Functions make up the leaves of the rating tree and are used for calculations.

There are numerous Functions. The Flat Function, which calculates a fixed amount, is one of the simplest. The Linear Function calculates an amount using the formula ax + b. For example, the Linear Function calculates the price of a telephone call charged at 0.34 cents per minute.



Charging Plan and Charging Tree

Charging Plan A charging plan is a set of instructions that:

Charges the calculated amount of a price plan to an account

Or refills the account with the calculated amount of the price plan

A charging plan is represented by a charging tree whose leaves are external and internal references.

This icon represents the charging plan of a charge in the Highdeal Transactive GUI.

Please note that the term “charging plan” does not appear in the graphical interface. Therefore, it is important for you to be familiar with the icon and the concept that it represents.



Charging Tree

The charging tree is a decision tree that shows the charging plan. This tree has a “root” and “branches” for the different charging components. The “leaves” describe which accounts will be charged for or refilled with the amount calculated by the related price plan.

Tree Branches andCharging

Components

Charging components are always found at the root of the charging tree. A Charging component is activated by one or more Rate components.

The charging tree can contain several Charging components, in the branches of which you can insert Rate components. Each Charging component has its own decision tree.

You can create each charging branch by using several components, which form nodes in the branch. The components are combined and each branch is terminated with a component describing the account to charge for or refill with the amount of the price plan.

Charging TreeExample and

Illustration

TelcoServ offers a Family package allowing to charge calls to a family or individual account depending on call destinations. The family Smith subscribed to the Family package allowing Mr and Mrs Smith's calls to be charged to a postpaid account while their son's calls are charged to a prepaid account. When John calls his parents, calls are charged to the postpaid account.

According to the illustration below, the price plan calculates the price of each call. After calculation, the amount of the price plan is charged to the Family account (postpaid account) or the Individual account (prepaid account).

The price plan contains a rating branch made up of a Usage Rate component combined with a Flat Function component to calculate the price of each call.

The charging plan contains a Usage charging branch. This branch includes test actions which answer the following questions:

What is the phone number?

What is the call destination (Family or Individual)?

What is the account to be charged for?

These actions and decisions are carried out by using components that belong to a number of families. The charging tree looks like this:



Price and charging plans in the charge related to the familie Smith’s offer



Charging Plan Component Overview

Charging PlanComponents

Charging plan components are tools you use to create a charging plan. Together the components make up a charging tree. You use the charging tree in a charging plan to debit or credit an account with the amount calculated by the related price plan.

Families of ChargingPlan Components

When creating your charging plan, you will use several types of components. To create the root of the tree, you always use a component from the Charging family. You can then use a variety of components that are grouped into the following families:

Charging

Comparisons

Operators

References

Comparisons and Operators can both be used in pricing and charging plans.

ChargingComponents

Charging components are always found at the root of the charging tree. A Charging component is activated by one or more Rate components. The following table shows the different types and the relevant activation:

ReferencesComponents

In the charging plan of a charge, a reference defines which account will be charged for or refilled with a calculated amount of the price plan. Reference

Type of Charging Activation

Usage Usage Rate

Recurring Recurring Rate

One-Shot One-Shot Rate

Default Any Rate component



components make up the leaves of the charging tree. The following Reference components are available with Highdeal Transactive:

Default Reference

Internal Reference

External Reference

Refill



Rating Context Overview

A price plan receives input data which, in turn, is used to calculate a price.

Data Sources Data used to calculate a price comes from several sources and may be:

A direct result of usage, supplied by the chargeable item properties of a product

Calculated in the price plan from previous calculations produced by components

Provided through parameter and counter values

Issued from the offer or subscription

Additional rows in translation tables specified in offers or subscriptions

This data belongs to a larger ensemble: the rating context.

Rating Context The Highdeal Transactive rating system uses a set of data to complete its tasks. All of this data, for which the values vary over time, is referred to as the rating context. Data that is part of a rating context is also referred to, in more general terms, as rating context properties.

When you are at the stage of adjusting and finalizing your offer, you can doing a Trial Run on the price plan.



Prerating, Reservation and Postrating Overview

Basic rating simply consists of the rating of all events related to the consumption of a service. If your configuration of Transactive uses the prerating and postrating feature, you need to know how this rating mechanism differs from the basic rating.

Prerating It is an advanced feature that enables a service provider to prevent a customer's balance (*) going below 0 when a service is consumed. This is done by using a reservation mechanism. When Highdeal Transactive receives a ticket from the external mechanism, the prerating operation calculates an amount for that ticket request and transmits the result of the prerating operation to the system to request and reserve the consumption. The system verifies the amount against the customer’s balance. If the balance is sufficient, the consumption is allowed.

When the calculated amount is greater than the balance, the consumption is not allowed. If the system generates a new ticket request for a smaller consumption volume, the prerating function regenerates a total amount for the modified request. The system verifies if the customer balance is sufficient for the new requested consumption.

Example - making atelephone call

For long duration/large volume use, the prerating request is repeated towards the end of each allowed communication period in order to reserve more minutes.

A customer has $5 remaining in a prepaid account and wants to make a telephone call. A ticket is delivered by the system, which is calculated as a chargeable item according to subscription and charge fees.

The prepaid function calculates the amount of money required for a defined volume of consumption. If the balance is sufficient, the call is made. During the call, the system makes successive prerating requests in order to verify if the caller can continue the call. When there are insufficient funds for the requested volume, subsequent requests are generated for progressively decreasing amounts. This continues until there are insufficient funds to consume any service. The call is then terminated.

Postrating Postrating is the confirmation or the cancellation of a prerated event. If an event is canceled or modified, Transactive takes into account the impact this will have on other rated or prerated events by resetting subscription elements such as counters. The balance is updated accordingly.

After having been prerated, an event is postrated depending on the service delivery result:

Failed delivery: The postrating cancels the prerated event. If necessary, the rating engine takes into account the impacts on results



of other events already rated or prerated. In addition, the subscription context such as counter values are updated.

Successful delivery: The postrating confirms the prerated event. The price previously calculated is confirmed (*). The balance is updated accordingly.

Successful delivery but with modified conditions: The postrating confirms the prerated event with a new ticket. The balance is updated accordingly.

(*): Only if all the previous events have been confirmed.

A prerating event can be canceled if:

The service was not delivered to the customer's recipient.

In the case of session management (*), the system has prerated a 5 minutes session but the end user ends the call after 3 minutes.

(*): The Session-based Rating is recommended for session management.

Postrating Example A customer sends a multimedia file and is charged for the file reception (prerating). After several days have elapsed, Transactive receives information that the multimedia file was not received by the customer's recipient. During the postrating process, Transactive recalculates the prerating result and provides enough information to the external billing system in order to update the balance accordingly.



Session-Based Rating and Reservation Overview

In Highdeal Transactive, two types of rating are provided:

Prerating and postrating

Session-based rating

Prerating andPostrating

Highdeal Transactive allows you to reserve resource usage by using the prerating and postrating functionality; however, this functionality is especially suitable for the rating of events like SMS (Short Message Service) because such events do not depend on time. See the chapter Prerating, Reservation and Postrating Overview for more information.

Session-basedRating

Contrary to the prerating and postrating, the session-based rating is more suitable to handle a wide variety of rateable instances such as:

Rating of volume: video download, for example

Rating of time: telephone calls, for example

Concurrent Servicesin Real-time

The session-based rating is performed in real-time and is able to manage the reservation of units for many services at the same time. For example, while calling on a mobile phone, a client can download a video.

Counter Reservationand Credit Control

A session-based rating is provided with counter reservation and credit control. The credit control is a mechanism which directly interacts in real-time with a balance and controls or monitors the charges related to service usage. The credit control does the following:

Checks if credit is available on the balance

Reserves credit

Deducts the reserved credit from the balance when the service is completed

Refunds the balance with the reserved credit not used

How Does a Session-based Rating

Operate?

The session-based rating is well adapted for session-based services such as telephone calls for two reasons:

The amount of resources that a subscriber may consume cannot be a priori known.

Other services debit the same balances and counters at the same time; therefore, counters and monetary balance must be reserved in advance.



In this case, a certain amount of monetary or non-monetary units is reserved on the subscriber’s balance. Permission to use an amount of resources that matches the unit reservation is then allowed. When the granted units have been used or when a new, not yet authorised chargeable event occurs, a new request is sent for unit allocation. When resource usage has been executed, the actual amount of resource usage (used units) must be known so that reserved amounts can be credited to the subscriber's balance, assuring that the correct amount gets debited.

Session-basedRating Limitation

The session-based rating is subject to the following limitation:

Counter reset: Counters are reset at any time through recurring and one-shot rates; therefore, as the same counters are also used for unit reservation, inconsistent results can occur during a session-based rating. For example, if a unit counter is decreased at each reservation during a session-based rating, the same counter can be decreased or increased at any time by another process.



Rerating

You may need to rerate when exceptional mistakes or errors occur in offers, subscriptions, price plans, and so on, resulting in incorrect transactions stored in database. Highdeal Transactive allows rerating all usage events occurred within a default period of 40 days preceding the current date. This period can be changed by the administrator.

Only the subscriptions of type offline are rerated by BART.

The module BART is required for rerating offers, subscriptions, price plans, and so on.

Rerating example Pricing errors can lead to erroneous rating calculations. This situation can arise from an incorrect price plan, incorrect content in translation tables, incorrect use of translation tables or pricing macros, and so on. This results in incorrect transactions stored in the billing database.

The billing system is dedicated to removing the erroneous transactions.

Rerating process When an error is identified in the pricing process, the user can correct any offer by selecting a date within a period of 40 days preceding the current date. For example, if transactions were rated through a wrong offer or price plan, the rerating process allows rerating all the usage events from the selected date in the past and generating the new rerated transactions in the database.

The rerating process consists of three steps, performed in real time by Transactive Desktop Tool (steps 1 and 2) and performed in batch mode by the Transactive BART (step 3):

1 Selecting subscriptions to be rerated depending on a search filter (subscription, offer, an so on).

2 Restoring the selected subscriptions to the state they had on a specified date (rerating date) in the past.

3 Rating the usage events relating to each subscription.



The rerating process requires that Transactive server and Transactive BART run at the same time.

When an object is rerated (offer, translation table, and so on), the related subscriptions are first restored, and then rerated one after another. The rerating process is complete when all the subscriptions have successfully been rerated or not.

Restoring a subscription consists in restoring its counter values. When the subscription is rerated from a date in the past (rerating date), all the events (usage events, recurring costs, and so on) occurred between the rerating date and the current date are triggered again. New transactions are created, which can be used by the external billing system to recalculate invoices or settlement reports.



Counter Overview

Counter A counter is a variable defined in a price plan. Each counter has a name and an initial value that you assign when creating the price plan.

In a price plan, two types of counters can be created: persistent or transient.

Some counters, called “shared counters,” can be defined in commercial offers. For more information about this, please refer to the chapter titled Price & Rate Concepts - Offers, Subscriber Accounts, Subscriptions, Shared Plans.

Counter Function A counter can be used in usage rates, recurring rates, or one-shot rates; you can change its value regardless of the rate type. There is no limit to the number of counters you can create.

Persistent Counters When created, a persistent counter is saved to the database. The life-cycle of a persistent counter is linked to that of a subscription. Persistent counters created in a charge are visible and can be redefined in offers which the charge is added to. Counters introduce a new “numerical” Rating Property specific to each subscription, which you can retrieve via the calculation system.

Persistent counters are used in price plans. See the chapters Prerating, Reservation and Postrating Overview and Session-Based Rating and Reservation Overview.

Persistent CounterExample

As the telephone operator TelcoServ, you offer a package called Advantage. Customers pay a subscription fee of $35 and receive special rates for weeknight and weekend calls. Anyone subscribing to this offer receives 30 free minutes of call time. In order to include these minutes of usage as free of charge in your price plan, you create a counter that signals the rating engine when the 30 minutes have been used up. In this way, it can then start rating the usage.

Transient Counters Contrary to a persistent counter, a transient counter is not saved to the database but stored in internal memory. Transient counters created in a charge are not visible and cannot be redefined in offers which the charge is added to. However, transient counters can be shared by master and dependent charges.



The life-cycle of transient counters is linked to a rating session because the transient counters are created when the corresponding rating process starts, and they are deleted when the rating process stops.

Transient counters are mainly used in price plans intended for session-based rating. See the chapter Session-Based Rating and Reservation Overview.

Transient CounterExample

In a product called "Telephone Services", you charge the customer $0.20 per call minute. To compute the price of a telephone call, you create a price plan using the transient counter "call_duration" and the user properties "duration_quota" and "method". The user property "method" specifies if the duration quota is confirmed (updated) or reserved (not updated). The following table shows the session-based rating of a 3-minute call:

* duration_quota and call_duration are expressed in minutes (min).

Session Step Amount to cancel Amount to confirm Amount to reserve

Start(method = reservation)(duration_quota = 3 min*)

3 x $0.20 = $0.60call_duration = 0 min

Update(method = confirmation)(duration_quota = 2 min)----------------------------------(method = reservation)(duration_quota = 3 min

- $0.60 (3 x $0.20)call_duration = 0 min----------------------------

2 x $0.20 = $0.40call_duration = 2 min--------------------------- ---------------------------


Stop(method = confirmation)duration_quota = 1 min

- $0.60 (3 x $0.20)call_duration = 2 min




Parameter Overview

Parameter A parameter is a variable defined in a price plan. You can reuse a parameter in a charging plan. You assign a name, type, and default value when you create the parameter in the price plan.

Using a Parameter A parameter introduces a new numerical, date, or string type property to the rating context. You can:

Retrieve this new property using the calculation system

Redefine the parameter for each client as part of their agreement (contract)

Parameter Example TelcoServ proposes a certain number of call time (hours) for a given subscription. The price plan computes the corresponding subscription fee, which can also be a parameter. The call plan has two parameters: “call time” and “subscription.” These two parameters can vary, as shown below:

Using these parameters, you can build specialized packages (call plans) where no other parameters are visible. For example, you can have a “2-hour subscription” package in which the amount of call time is set to 2 hours and the cost of the subscription is $20.

Some parameters, called “shared parameters,” can be defined in commercial offers. For more information about this, please refer to the chapter titled Price & Rate Concepts - Offers, Subscriptions, Shared Plans.

“Subscription” “Call time”

$20 2 hours

$40 5 hours

$60 10 hours



Pricing Macro Overview

Pricing Macro A pricing macro is a tool you can use to optimize the creation and updating of price plans. A pricing macro is a small reusable module capable of retaining and applying a calculation formula. If your price plan has common calculation formulas, you can manage and maintain the price plan more easily by creating pricing macros.

This icon represents a pricing macro in the Highdeal Transactive GUI.

Pricing MacroCharacteristics

A pricing macro is very much like a price plan in that it is a group of components that:

Apply to properties

Are represented in the software as a rating tree

A pricing macro makes it easier to manage a section of a rating tree that is used in one or more price plans.



Translation Table Overview

Translation Table A translation table allows you to create properties that exist outside the rating context and that can be accessed by price plans. A translation table generates new properties from existing properties and allows you to search for a table of corresponding values.

This icon represents a translation table in the Highdeal Transactive GUI.

Example If your company TelcoServ wants to include a telephone zoning table in its price plan, you can define a very simple translation table. This table will contain lists of the following:

Telephone number prefixes in the “input” column

“Area Code IDs” and “Phone Type” values in the “output” column

Numerical properties that are used to calculate the price can also be output: a specific rate per minute, for example.



Pricing Policy: Application Example

Pricing PolicyExample

As the telephone operator TelcoServ, you create the service offer linked to the Fixed Telephone commercial offer. You decide to charge calls according to their duration and based on the following price scale:

$0.17/minute if the call starts during the weekend

$0.34/minute if the call starts during the week

The weekend begins on Friday at 7:00 p.m. and ends on Monday at 6:00 a.m.

To calculate the price of a call, you must:

Know the duration of the call

Know if the call started during the weekend

Specify the calculation formulas ($0.34/minute and $0.17/minute)

The following table presents the questions you need to ask along with the processes, properties, and components you need to use in order to complete this task:

In this example, Call Start Date and Call Stop Date are User Properties created in a product. For more information, see the Chargeable Item chapter.

Question Process Properties to use Component family

Component

What is the duration of the call?

Calculate the duration of the call in minutes, according to the difference between two dates

• Call Start Date• Call Stop Date

Operators Duration

Did the call start during a weekend period?

• Define the weekend period

• Compare the start date of the call to the weekend period

Call Start Date Comparisons

Date / Time slot

Which calculation formula?

Apply a linear function to the Call Duration property, with two possible constants (0.17 and 0.34)

Call Duration: Property generated by higher calculation

Functions Linear



To describe this pricing policy in Highdeal Transactive, you need to create the following elements:

a master charge called “Telephone Charges”

a price plan that is included in the “Telephone Charges” charge and that contains the following component types:

Usage (Usage Rate)

Operator (Duration)

Comparison (Date / Time Slot)

Function (Linear)

Steps Creating the telephone call pricing policy consists of the following steps:

1 Identify the charge.

2 Identify the price plan and choose the currency.

3 Add the Rate branch (Usage Rate component).

4 Calculate the call duration by using the Duration component and generate the Call Duration property.

5 Set up the calculation of the call duration: rounding mode, precision unit, and so on.

6 Define the weekend period and test the call start date by using the Date/Time Slot component.

7 Calculate the price of the call during the weekend by using the Linear Function component.

8 Calculate the price of the call during the week by using Linear Function component.

You finish your creation of the pricing policy by saving the charge ‘Telephone Charges’ in the database.

As the focus is on the price plan in this example, you save the charge ‘Telephone Charges’ with the default components of the charging plan.



The following illustrations correspond to the above-mentioned eight steps:

1 Identify the type of charge.

2 Identify the price plan and select the currency.

3 Add the Rate branch using the Usage Rate component.

Usage Rate component



4 Calculate the call duration and generate the Call Duration property by using the Duration component..

5 Set up the calculation of Call Duration.

6 Define the weekend period and test the Call start date date by using the Date / Time Slot component.

Duration component

Date / Time Slot component



7 Calculate the price of the call during the weekend in the weekend branch by using the Linear Function component.

8 Calculate the price of the call during the week in the “week” branch by using the Linear Function component.

Linear Function component

Linear Function component


Chapter 3

Price and Rate and BalanceManagement Concepts -

Offers, Subscriber Accounts,Subscriptions, Shared Plans

This chapter presents features and functions in Highdeal Transactive, and particularly in the Price and Rate and Balance Management module, that help you create and put your offer into production:


Section Page

Offers 93

Subscriber Accounts 113

Subscriptions 123

Shared Plans 141


Price and Rate and Balance Management Concepts - Offers, Subscriber Accounts, Subscriptions, Shared PlansChapter 3



Offers

Offers are implemented in Highdeal Transactive using the offers concept. You can create and set up offers once you have defined product-related charges.

This section describes and illustrates information you need to create offers. The information is presented in the following order:

Offers overview

Creating offers

Setting up charges used in offers

Setting up offers used in Subscriptions

Making changes in offers

Application example



Offer Overview

Offers cannot be used in stateless mode.

Offers An offer describes the way to sell one or more products. It contains agreement conditions (such as usage fees) and a validity period during which it can be subscribed to by the customer. There are two types of offer:

Simple offer

Complex offer, which is used to describe offers such as packages, options, business-to-business offers, and so on

An offer always contains at least one pricing condition (charge) or one offer.

This icon represents an offer in the Highdeal Transactive graphical interface.

Two Types of Offer A simple offer contains only charges associated with one or more products. You need to choose and set up these charges when creating a simple offer.

A complex offer is made up of charges and/or sub-offers. You can combine as many charges and sub-offers as you like, as well as add other complex offers. You will need to choose and set up charges and sub-offers when creating a complex offer.

Basic Offer Example The telephone operator Telcoserv proposes a “Fixed Telephone” offer, which is priced in one of three ways:

Telephone equipment, rented on a monthly basis

Telephone calls, charged per minute

Line installation, charged once



Each of these costs is represented by a charge applied to the Telephone Product. The basic Fixed Telephone offer is created using three charges as shown in the example below:

Complex OfferExample

The telephone operator Telcoserv also has an Internet Access basic offer that is charged on connection time. In combining this offer with the Fixed Telephone offer, Telcoserv is able to market the Telinter package, which is created as follows:

Representing Offers You create offers by using charges and/or sub-offers. This tree structure is graphically represented in the interface using a tree structure hierarchy. offer structures can be viewed in a specific window and are created dynamically as the tree grows. The following screen shots illustrate the Telinter offer:

Basic offer Charges Rate used in the Plan

Product

Fixed Telephone

Equipment Rental Recurring

TelephoneCalls Usage

Installation One-shot

Complex offer Simple offer Charges Product

Telinter

Fixed Telephone

Equipment Rental

TelephoneCalls

Installation

Internet Access (usually this includes monthly fees in additon to the connection fee)

Connection Internet



Fixed Telephone Simple Offer

Internet Access Simple Offer

Telinter Complex Offer

Complex Offer structure



Creating Offers

No matter what type of offer it is, you always define the following:

General characteristics (offer identifier, validity, and so on)

Offer structure

Setup

Offer Validity When you create an offer, you can specify its period of validity using two dates: the effective date and the expiration date. This period corresponds to the period during which it is possible to subscribe to an offer.

For a graphical representation of the terminology related to dates in Highdeal Transactive, see the ‘Customizing Subscription Functions’ section later in this chapter.

Defining Structure To define the structure of an offer, you need to describe:

Offer composition

Offer organization: component interdependency

DescribingComposition

It is very easy to describe the composition of an offer. For simple offers, you simply choose the charges relating to products included in the offer that you want to apply. You choose these from the catalogue of the service provider.

For complex offers, you select the offers and charges that make up your offer in the same way. Complex offers are very flexible. For example, when selecting offers, you can choose whether or not to integrate charges already incorporated in the offer. You can then add subscription rules.

Subscription Rules For each offer forming part of a complex offer, you need to indicate the subscription rules:

Offer status: mandatory or optional subscription

If necessary, detailed rules:

Minimum and maximum number of subscriptions

Subscription steps, if you want to impose multiple subscriptions by fixing a set number of subscriptions per batch

DescribingOrganization

You need to describe the organization of an offer if it contains dependent charges. To do this, you specify the dependence relationships between charges. For each dependent charge, you need to specify which charge in



the offer plays the role of master charge (in terms of triggering or calculation).

Link BetweenStructure and Setup

The offer structure directly relates to the type and degree of setup available. In the basic offer, you can set up charges, adapting them to the offer context. Charges can be set up in the same way for complex offers, regardless of their position in the offer tree structure. However, you can now make use of the offer and sub-offer level. These two setup types are explained in the following sections of this chapter.

Offer CreationStages Summary

Offers can be created in three main steps, each of which requires the definition of certain offer characteristics. The table below summarizes these three steps for a simple offer and for a complex offer.

Step Definition Simple offer Complex offer

1 General characteristics

Identifier Identifier

Validity period Validity period

Additional data (in any format)

Additional data (in any format)

2 Structure

Charge composition

• Offer and charge composition

• Offer subscription rules

Organization: Charge interdependency

Organization: Charge interdependency

3 Setup Charge level 2 levels: Subscription and offer



Characteristics of Charges

Charges have several types of characteristics. When you create a charge, you define main characteristics. After you create charges in your catalogue, you select them to create the offer. When you use these charges inside an offer, you give them secondary characteristics. This section describes the main and secondary characteristics.

Main Characteristics A charge has the following characteristics, which you define during its creation:

Charge type (master or dependent)

Parameters, if used

Counters, if used

Pricing macros, if used

Translation tables, if used

Of these characteristics, only the charge type is mandatory.

When the charge is included in an offer, parameters can be modified and translation tables can be extended.

SecondaryCharacteristics

A charge has secondary characteristics, which are defined when a charge is used in an offer:

Activation status

Relationship types

Operation types

Roles for dependent charges

Secondary charge characteristics are only valid in the offer to which they are assigned. If you reuse this charge in another offer, you can specify other secondary characteristics that are valid in this new offer.

Activation status When you select charges to build an offer, you can choose their status. This status may be mandatory or optional.

If you choose the mandatory status:

The charge will start automatically in the offer subscriptions

You will need to determine the setup and effective date of this charge at the time of subscription



If you choose the optional status, all actions related to this charge are de-synchronized from the main subscription, such as:

Manually including this charge in the subscription, where necessary

Determining the charge setup and effective date, where necessary

Removing this charge from the subscription

Optional StatusExample

The training organization Techlingua signs a contract with Learn.com for the complete Organizations Module, on which it is to receive a 5% discount on the subscription fee. Learn.com normally grants this type of one-shot discount to major customers and creates a dependent discount charge in the complete Organizations Module with optional status, while manually activating the discount charge in the Techlingua Subscription. This charge remains available “on request” in other subscriptions but will not start without being triggered.

Relationship Type The relationship type allows you to choose whether the relationship with the service provider will be with a client or with a partner.

Operation Type The operation type allows you to specify whether to credit or debit the client or the partner involved.

Role Only for dependent charges. You need to specify the role of a dependent charge in an offer as part of the integration process. This role may be a Commission, Third Party Billed Commission, Sponsorship, Discount, or “Other”. The role of a charge is only valid for offers for which it is created, which means a single charge can be used to calculate commission in one offer and sponsorship in another. However, there is an exception to this rule if you reuse a charge in a complex offer. If you need to use a sub-offer (in which the dependent charges have already been assigned roles) to build a complex offer, you cannot modify these roles.

Example of Role andLevel

Regarding the basic Module Offer, Learn.com sells training modules to customers and therefore has to pay commissions to authors in the form of sales Commission. Customers pay a monthly subscription fee and the company chooses to link the Commission calculation to these monthly subscriber payments. However, depending on the type of customer (private individual, company, association, and so on), commissions must be paid to different organizations.

The table below shows how the example works in Highdeal Transactive:



Charge Catalogue

Charge Type Plan rate

Subscription Master Recurring

Sales Commission Dependent Recurring

Offer Catalogue

Offer Composition Organization

Module

Subscription charge Master

Sales commission chargeRole: CommissionLevel: Subscription

Dependent on the subscription Charge



Setting Up the Charges

Setup may apply to charges only (for the simple offer) or to charges and sub-offers (complex offers) depending on the complexity of the offer. This section presents the setup for charges used in an offer.

Setup Concept Highdeal Transactive is a program that requires a high level of setup. The same high standard of quality is evident in all components and at all levels. What we refer to as setup is the highly developed functionality of offers and subscriptions. This means that you can define parameters in a specific context and redefine them in different contexts as many times as you like.

Setting Up theCharges

Having created your charge catalogue, you will need to select these charges to create the offer. When you use these charges within offers, you can simultaneously do the following:

Redefine some of their main characteristics

Assign secondary characteristics to them

Choices made concerning a particular offer only apply to this offer and may be different in another offer.

This dual control system is a function that exists in all offers, no matter how complex they are.

Redefining MainCharacteristics

When you incorporate a charge into an offer, and if the price plan in the charge contains “redefinable” parameters (“external visibility” option in GUI) or uses translation tables with the possibility of extension (“extension” option in the GUI), you can do the following:

Redefine parameter values

Define exceptions for translation tables

However, you cannot change the charge type.

Shared plans change the possibilities for redefining parameters in charges. For more information, please see the Shared Plans section of this chapter.

Rule for ApplyingValues

If you do not redefine the main charge characteristic of a basic offer, the initial values assigned when creating the charge will be applied. For complex offers, any existing values assigned at a lower level will be taken



into account. For multiple overlaps, the system uses the tree structure descending level by level. Starting from the highest level (complex offer) working towards the lowest level (charge), the system applies the first values encountered.

Redefining MainCharacteristics

Example

Learn.com has divided its customers into several sectors (private individuals, large companies, training organizations, associations, and so on) and wishes to propose several training offers adapted to these different sectors. The module Subscription fee varies according to these sectors. For the training organization sector, the company proposes a complex offer combining module and document download on request, on payment of a membership fee. In creating the price plan for the module Subscription charge, the Subscription fee parameter is added. You can then add other charges and offers as follows:

Charges Catalogue

Charge Price Plan Main characteristics

Module Subscription

Monthly Module Subscription:• Recurring Rate• Monthly periodicity

Master chargeParameter: • Name: subscription fee• Default value: $10

Document DownloadDocument Download: Usage Rate

Master chargeParameter:• Name: download fee • Default value: $1 / megabyte

Membership FeeDownload Access:One-shot Rate

Master charge

Offers Catalogue

Offer Type of offer

Composition Elements Main characteristics

Private Individual Module Simple 1 charge

Module Subscription Charge

Subscription fee: not redefinedValue applied: $10

Company Module Simple 1 chargeModule Subscription Charge

Master chargeRedefined subscription fee: $15

Organization Module Simple 1 charge

Module Subscription Charge

Master chargeRedefined subscription fee: $17



As far as complete Organization Modules are concerned, the subscription fee applied is the value assigned in the Organization Module Offer ($17), since:

The Organization Module Offer is a component of the complete Organization Module Offer

A subscription fee redefinition exists in the Organization Module Offer

However, the download fee is the default fee assigned in the document download charge as no redefinition has been given.

RedefiningSecondary

Characteristics

If you build a complex offer, you can also redefine certain secondary charge characteristics previously fixed in the offers that make up the complex offer. For example, you can redefine the status, the Service Provider, and the Client/Partner. Redefining the status is presented in the example below.

Redefining StatusExample

Learn.com has assigned mandatory status to the “Membership Fee” charge for the “Document Download” Offer. In building the complex “Complete Organizations Module” using the “Organizations Module” and the “Document Download” Offer to promote customer flexibility, the company can redefine the status of the “Membership Fee” charge as “optional.” Learn.com can thus exempt customers from membership fees. If the status is not modified, the system will apply mandatory status.

Document Download Simple 2 charges

1- Access Fee Charge Master charge

2- Document Download Charge

Master chargeDownload fee: not redefined

Complete Organization Module

Complex 2 simple offers

1- Organization Module Offer

Module Subscription master chargeSubscription fee: not redefinedValue applied: $17

2- Document Download Offer

1- Membership Fee master charge2- Document Download master chargeDownload fee: not redefinedValue applied: $1 / MB

Offers Catalogue

Offer Type of offer

Composition Elements Main characteristics



For multiple overlaps, like for main characteristics, the system uses the tree structure descending level by level. Starting from the highest level (complex offer) working towards the lowest level (charge), the system applies the first values encountered.



Setting Up Sub-Offers

Once you have created simple offers, you need to select them to build complex offers. If required, you can add charges or remove any existing charges from the offers you will use that are no longer relevant to the new offer. You then need to fix the basic offer subscription rules.

Sub-Offers Offers with other offers are called sub-offers. When you use sub-offers, you can redefine internal previously fixed organizations if they exist. Choices made concerning a specific offer are only valid for this offer and may be different for other offers.

This control system is a function that only exists in complex offers containing dependent charges, no matter what their position in the offer tree structure.

Offer Organization When creating a simple offer in your catalogue, you need to specify its composition and, if it contains dependent charges, its organization. This organization describes interdependency between charges.

RedefiningOrganization

When you incorporate an offer containing a dependent charge into another offer, the previously established dependency links will be transferred to the complex offer. If these links are not suitable or you need to create more links, it is possible to redefine them. Thus, you need to specify which charge plays the role of master charge in relation to the dependent charge.



Making Changes in Offers

Over time, the offers present in your catalogue will change and you will consequently need to modify them to bring them into line with your sales policy or to eliminate anomalies. You are free to make as many modifications as you like. This section presents the main offer modification rules, which concern the three key domains of pricing, offer structure, and setup.

Price Changes The pricing terms described in the charges can be revised over time. For example, the basic subscription price included in the subscription charge may change. Agreements already signed for offers containing this charge will be subject to these changes, with the exception of certain specific agreements, such as price freeze and assignment of specific Parameters (see the Subscriptions section in this chapter).

Pricing term changes may be pre-installed and saved: this will provide you with a list of charges.

Structure Changes The following actions can be used to modify an offer structure:

Composition: addition of charges and offers (sub-offers), integration of charges previously removed

Modification of subscription rules

Organization: changing charge interdependency links

You cannot delete charges or sub-offers.

However, subscriptions saved prior to these modifications will remain unchanged as these changes are not retroactive. The structure of certain subscriptions would no longer correspond to the current catalog of offers.

Setup Changes You can change the setup used to create an offer for charges and sub-offers. However, changes will not be reflected in existing subscriptions. About the main characteristics of charges used (Parameters, translation table), modifications will be reflected in current subscriptions, except for those with a specific setup. For example, if you have redefined the subscription price in a charge with a Parameter, the prices of all current and future subscriptions will be updated when you change these, except if a subscription has a fixed price.

However, in the case of secondary characteristics or the setup of sub-offers (dependency links), changes will not be applied to current subscriptions. These subscriptions may no longer correspond with the current catalogue of offers.



Accessing andDeleting Offer

Versions

When you modify and save an offer, you can access all previous versions

of it by clicking on the clock button on the toolbar. You can only delete a version by deleting all previous versions. You can delete all previous versions of an offer by modifying and saving your offer, then specifying an effective date earlier than the effective date of the original version.

The same principle for modifying and deleting versions exists for charges, subscriptions, pricing macros and translation tables.



Offers: Application Example

Products Learn.com sells subscriptions to training modules on the Internet. Its customers can also download module-enhancing documents onto their workstations and consult archives on its database server.

Offers and Pricing With a mixed customer base (private individuals and professionals), Learn.com may sell all of its services individually or combined in a comprehensive offer targeted at training organizations and companies.

Learn.com uses the following pricing system:

Module: pricing per subscription at a variable rate + module registration fees

Document: pricing based on download time

Server: pricing based on connection time + membership fee

Learn.com buys modules from authors, who it then pays by paying commission on sales to the professional bodies. The company can choose to exempt certain professional customers from registration and membership fees, grant them discounts on subscriptions, or even deduct subscription fees.

Charges Here is the catalog of proposed charges:

Charge Price Plan Main characteristics

Module Subscription Recurring RateMaster chargeParameter: Subscription price

Module Commission Recurring RateDependent charge Parameter: percentage value

Module Discount Recurring RateDependent chargeParameter: percentage value

Module Registration Fees One-shot Rate Master charge

Document Download Usage Rate Master charge

Server Access Usage Rate Master charge

Membership Fee One-shot Rate Master charge

Subscription Fee One-shot RateMaster chargeParameter: fee amount



Offers Here is the catalog of proposed offers:

Basic Offers

Offer Composition Elements Status

Basic Module 3 charges

Module Subscription Mandatory

Module Commission Mandatory

Registration Fee Mandatory

Basic Download 1 charge Document Download Mandatory

Server Access 2 chargesServer Access Mandatory

Membership Fee Mandatory

‘Basic Module’ simple offer

‘Basic Download’ simple offer



‘Server Access’ simple offer

‘Complete Module’ complex Offer

Content Components Offer status

Content Elements Charge activation

3 sub-offers and 2 charges

Basic Module Offer

Mandatory by 5 3 charges

Module Subscription Mandatory

Module Commission Mandatory

Module Registration Fee Optional

Basic Download Offer Optional 1 charge Document

Download Mandatory

Server Access Offer Optional 2 charges

Server Access Mandatory

Membership Fee Optional

Module Discount Charge

Optional

Subscription Fee Charge Optional



‘Complete Module’ complex offer



Subscriber Accounts

This section describes and illustrates the processes required to create and set up subscriber accounts. The topics related to subscriber accounts are presented in the following order:

Subscriber account overview

Creating and setting up subscriber accounts

Prepaid accounts

Postpaid account links

Credit limit balances

Application example



Subscriber Account Overview

In Transactive, a subscriber account is linked to a customer. Each existing subscription is related to one and only one subscriber account.

A subscriber account contains all the prepaid, postpaid account links and credit limit balances which are debited when the customer consumes services or credited when the customer makes refills.

Before creating subscriptions, you must create at least one subscriber account

How to Debit or Creditan Account

A subscriber account is linked to the charging plan of a charge through a mapping of charging references (*) located in subscriptions. When a customer subscribes to a charge in a subscription, the charging plan of the charge together with the charging mapping references specified in the subscription allow to identify which account of the subscriber account will be debited or credited with the amount calculated in the price plan.

(*): A relation between two sets in which one element of the second set is assigned to each element of the first set.

For more information about the mapping of charging references, refer to the chapter Subscriptions.

Example In Transactive, the rating process consists usually of two stages: a pricing process followed by a charging process. When a customer consumes a service, the pricing process calculates the corresponding fee while the charging process defines which prepaid or postpaid accounts will be debited with the fee. Credit limit balances can possibly be debited.



Creating and Setting Up Subscriber Accounts

When creating a subscriber account, you define the following:

The identifier of the subscriber account (mandatory)

The service provider (mandatory)

Additional information (optional)

A default charged account, which can be a prepaid or a postpaid account link (mandatory)

Prepaid accounts (optional)

Postpaid account links (optional)

Credit limit balances (optional)

Subscriptions (optional) which are linked to the subscriber account

Setting Up aSubscriber Account

In a subscriber account window, a subscriber account is graphically represented by a tree, which can consist of prepaid accounts, postpaid account links and credit limit balances, depending on the requirements of the subscriber account.

Setting up a subscriber account consists mainly in:

Adding accounts and balances to the subscriber account tree

Setting up each new account

Default Charging Once you have created one or more accounts for the subscriber account, you can define the default policy for the subscriber account by choosing the default account and the default credit limit balances to charge.

Subscriptions In the subscriber account window, you can create or open subscriptions relating to the subscriber account.



Prepaid Accounts

A prepaid account is a monetary counter associated to a currency. Funds are placed in the account before the service begins, and then the charges linked to the services consumed by the client are debited as necessary.

Balance The balance of an account is defined by a minimal value (Empty Limit). Depending on service providers' requirements, the Empty Limit is usually close to 0. Usage is rejected when the balance reaches the empty limit. However, if overspending (refer the note below) is authorized for specific usage, the Empty Limit is ignored, and the usage can be debited from the account even though the balance of the account is less than the empty limit.

Crediting a fee to a prepaid account consists in increasing the amount of its balance. Conversely, debiting a fee consists in decreasing the amount of its balance.

Components References include an option that authorizes overspending in charging plans

Prepaid accounts are credited by using refills through charging plans (refer to Charging Plan and Charging Tree) or manual refill procedures (Desktop Tool menus).

Empty Limit The minimal value of a balance ensures that the account is sufficiently funded to pay an account fee, for example, or to reserve money in order to limit the processing error of the vendor. When the Empty Limit is reached, usage/events are rejected.

Alerts Prepaid account balances can be connected to amount and expiration alerts:

Amount alerts: A notification (*) is sent to a dedicated system when the prepaid account is less than or equal to the threshold value of an alert. The currency used in alerts is that of the prepaid account.

Expiration alerts: An alert is triggered a number of days before or after one of the dates defined in an expiration schedule. For example, the alert "alert1_prepaid" is triggered two days before the prepaid account is locked in order to warn the user that the account is due to expire soon; and therefore, the user must refill the account.

(*): Customers are informed in real-time, for example, when they are making a phone call.



State of a PrepaidAccount

A Prepaid account can be:

Active: The prepaid account can be debited until the Empty Limit is reached. It can be refilled. If overspending is authorized, debiting is possible. You can block, lock or close an active prepaid account.

Blocked: The prepaid account is charged depending on how you configure the default or internal reference components in the related charging plan. The prepaid account can be refilled. If overspending is authorized, debiting is possible. You can reactivate, lock or close a blocked prepaid account.

Locked: The prepaid account is charged depending on how you configure the default or internal reference components in the related charging plan. Refills and overruns are authorized. If overspending is authorized, debiting is possible. You can reactivate, block or close a locked prepaid account.

Closed: The prepaid account is charged depending on how you configure the default or internal reference components in the related charging plan. Refills and overruns are forbidden. Once closed, you cannot change a prepaid account any more.

An expiration schedule allows you to schedule the states of a prepaid account.



Postpaid Account Links

A postpaid account link is a reference to a postpaid account inside Transactive. For more information on postpaid account links, refer to Account Types and Postpaid Accounts.

Unlike a prepaid account, the balance of a postpaid account link is not updated in real time; therefore, if you need to limit a subscriber's expenses in real time, you must use a credit limit balance.



Credit Limit Balances

A credit limit balance is a monetary counter associated to a currency and intended to limit the use of a service for a time period.

Alerts Credit limit balances can be connected to amount alerts. An alert is a notification sent (*) to a dedicated system when the amount of a credit limit balance is less than or equal to the threshold value of an alert.

(*): Customers are informed in real-time, for example, when they are making a phone call.

Reset Credit limit balances are reset manually or automatically to the value of the expense limit to be controlled. Each time a service is consumed, the credit limit balance is debited. When the balance is reset, it is credited with its credit limit. However, if the credit limit balance reaches the value of 0 before being reset, Transactive does not allow service consumption except if overspending is authorized.

Example A client wants to limit the consumption of a service SMS to $10 per month. The limit of the credit limit balance is set to $10. When the balance is reset every month, it is credited with $10.



Subscriber Accounts: Application Example

The following example is an offer proposed by the operator Telcoserv to one of its customers.

During the working days, the company Atlantide allows their employees to:

Call between 8:00 and 18:00, period during which calls are charged to Atlantide. Outside working hours, calls are charged to employees’ individual accounts.

Use email services which are charged to Atlantide if the total cost do not exceed $45 per month and per employee. For important business, employees are allowed to go beyond this threshold.

Other services are charged to each employee's account.

This application example requires the creation of a product, charges, offers, subscriber accounts and subscriptions. In this example, only charges, subscriber accounts and subscriptions are considered.

Charges For this example, the following charges are needed:

A charge for calls, in which the charging rule of the charging plan is the following: If the call start date is included in business hours, the call is charged to the Atlantide's account (reference ‘CompanyAccount’); otherwise, the call is charged to the employee's account (reference ‘IndividualAccount’).

A charge for emails, in which the charging rule of the charging plan is the following: Email services are charged to the Atlantide's account (reference ‘CompanyAccount’) if the total cost of these services do not exceed $45 per month and per employee. However, if an email is urgent, it is charged to the Atlantide's account, and overspending is authorized on a credit limit balance.

A charge for each of the other services that are charged to each employee's account.



Subscriber Accounts Each Atlantide’s employee is represented in Transactive by a subscriber account. For example, John Smith’s subscriber account contains:

A postpaid account named ‘Individual’, which is a postpaid account link referencing the postpaid account of the employee.

A postpaid account named ‘Atlantide’, which is a postpaid account link referencing the postpaid account of the company.

A credit limit balance named ‘Emails’ credited with $45 per month. The balance is debited each time an email service is consumed. An alert is sent when the threshold of $5 is reached.

The default account of the subscriber account John Smith is ‘Individual’.

Subscriptions In the charge of a subscription, a charging mapping describes the links between charging plan and subscriber account. For example, in John Smith’s subscription, the charging mapping of the charge ‘Calls’ shows the following links:

The amounts calculated in the price plans are charged to John Smith’s subscriber account through the related charging plans and Charging References:

The Charging Reference ‘CompanyAccount’ is linked to the postpaid account ‘TelcoServ’

The Charging Reference ‘IndividualAccount’ is linked to the postpaid account ‘Individual’

Charging reference Charged account Credit Limit Balance #1

Credit Limit Balance #2


CompanyAccount Atlantide --------------- --------------- ---------------

IndividualAccount Individual --------------- --------------- ---------------



Subscriptions

You can ensure the sale of your products by signing contracts with your customers. You can incorporate a contract into Highdeal Transactive using a subscription. When product-related offers are defined, you can save the contracts signed with your customers by creating and setting up subscriptions. This step will enable you to implement the exact requirements of your customers.

This section describes and illustrates the processes required to create and set up subscriptions. The topics related to subscriptions are presented in the following order:

Subscriptions overview

Subscription structure

Customizing subscription functions

Setting up activated charges

Setting up the charging mapping of charges

Modifying subscriptions

Application example



Subscription Overview

Subscriptions cannot be used in stateless mode.

Subscription A subscription:

Is related to one and only one subscriber account (See the chapter Subscriber Accounts)

Is an offer that is subscribed to by a customer as part of a contract

Before creating a subscription, you must create at least one subscriber account. Subscriptions relate to offers and take into account the specific needs of customers.

Like their associated offers, subscriptions are multi-level in organization.

This icon represents a subscription in the Highdeal Transactive graphical interface.

SubscriptionExample

Telcoserv proposes the following complex Telinter offer:

To equip two offices being refurbished, the company Techlingua subscribes to the Telinter offer with the following specifications:

4 Fixed Telephone subscriptions

2 Internet Access subscriptions

Complex offer

Simple offers Subscription Charges Product

Telinter

Fixed Telephone

Mandatory by batch of 4

Equipment Rental

TelephoneCommunication

Installation

Internet Access Mandatory Connection Internet



After negotiation, Telcoserv grants Techlingua the following:

5% discount for 1 year on equipment rental

Three-month gap between signing the contract and the first rental fee payment

The Techlingua subscription to the Telinter offer will take all of these parameters into account.

SubscriptionRepresentation

Subscription structure is similar to the structure of its associated offer. It may therefore contain several levels: root subscription, secondary subscription, and so on. This tree structure, which can be viewed in a specific window, is graphically represented in the interface and respects the tree structure hierarchy. The following illustration shows this graphic representation:

Techlingua subscription to the Telinter offer, containing 4 fixed telephone subscriptions

Subscription Structure



In relation to the setup for charges used, you can distinguish the charges activated and those not activated in this graphical tree structure. Moreover, in relation to subscription rules, you can distinguish confirmed subscriptions from those that are not confirmed. This representation dynamically changes as you advance through the process of saving a subscription.



Subscription Structure

No matter how complex an offer is, you always define the following when creating a subscription:

General characteristics (subscription identifier, validity, and so on)

Subscription structure

Subscription functions (such as access chronology, pricing, and third party payments)

Setup of activated charges

This section presents the subscription structure.

Subscription Validity When you create a subscription, you can specify the contract duration using two dates: the effective date and the expiration date. These dates indicate the subscription validity.

Defining theStructure

You define subscription structure along with offer structure. You need to save the subscriptions by doing the following:

Subscribe to optional offers

Indicate the number of subscriptions for each sub-offer subscribed to

Activate charges with optional status

Indicate the number of charges for each charge activated

Number of Charges For some customers, you may need to multiply certain charges that are present in the unit offer, as in the example below:

Learn.com proposes several training module offers charged by subscription. The company is in contact with the regional organization EcoDevCouncil, who sponsors a number of associations. This Sponsorship constitutes a variable percentage of training costs accumulated by the association. The company has adapted its offers to this clientele, with the Associations Module comprising two charges:

Training module subscription charge

Sponsorship charge to calculate the amount to be paid by EcoDevCouncil

Learn.com sells this offer to a large company, AMGen, which profits from double Sponsorship by EcoDevCouncil and a private foundation. The solution to this specific case is simple: the AMGen subscription comprises two Sponsorship charges instead of one.



Saving aSubscription

Due to identical subscription and offer structures, saving a subscription is easy. The subscription structure is created automatically if you choose the associated offer at the start of the subscription creation process. Each offer in the structure that contains an offer subscribed to has a corresponding subscription entity. To declare an optional offer as being subscribed to, you select the corresponding subscription and request the appropriate action. For mandatory offers, corresponding subscriptions are automatically declared “subscribed to”: simply specify the number.

The charges outlined in this offer are automatically implemented and you can therefore do the following:

Program mandatory charges to start

Activate optional charges when required

Choose the number of activated charges

Multiple Subscription If the offer subscribed to contains rules specifying the minimum subscription quantities, the structure will contain a specific element representing a group of subscriptions. This element is referred to as multiple subscription.



Customizing Subscriptions

This section presents the different ways in which you can customize subscription functions. The end of this section illustrates how periods of subscription suspension and frozen prices affect offers, sub-offers and activated charges.

Functions Subscription functions involve the following domains:

User identification: Access chronology

Pricing and dates management

Charging mapping

Access The user access specifies the identifier under which a customer consumes a product or service. This identifier enables the rating engine to identify the subscription and the charge within it for usage rating purposes.

In a subscription containing one or more charges, you can create one or more user accesses for each master charge. By creating more than one user access for the same customer, you allow the customer to use the product or service under various identities.

Access chronology Each unique user access that you create in the database is identified by the pair User Service Identifier/Service Identifier. Furthermore, Highdeal Transactive allows you to assign user accesses to subscriptions depending on time periods. The same user access can be divided chronologically into unique time periods. You are thus allowed to assign each time period of the same user access to a different or same subscription. For example, the user access USI1/SI1 is divided into two time periods:

First time period: From 01 January to 01 February

Second time period: From 01 February to an unspecified date

Each time period of the user access USI1/SI1 can be assigned to a different subscription.

Because user accesses are arranged into a chronological order, time periods cannot overlap but can be discontinuous. For example, the user access USI2/SI2 can be divided into third periods:

First time period: From 01 May to 01 June

Second time period: From 01 August to 01 September

Third time period: From 01 November to 01 December



The access chronology is optional. You can select a subscription and a charge without selecting a time period. This option means that the user access is assigned to the subscription for an unlimited time period.

You can create user accesses that are related to no subscriptions in order to keep user accesses for later use.

Access Example A customer wants to change a 5 free MMS plan into a 20 free MMS plan on January 1st. In this example, the price plan include the same service (MMS). Processing possible delayed MMS messages requires to divide the same user access into time periods. This case requires January 1st as the end date of the first user access while the start date of the second access is after January 1st.

Pricing in NormalMode

The pricing that is planned in the offer and the subscription is usually applied without interruption during entire period that the subscription is valid. The pricing ends on the subscription expiration date. This end date is a planned event that does not trigger any individual fee calculation.

Pricing inCustomized Mode

The classic pricing functioning can be interrupted during certain events, such as suspension of service, contract cancellation, and so on. You can adapt pricing functions to meet customer demands by using one of several means. You can act on a global customer subscription level or process one charge at a time. The table below lists the possible actions:

Graphical InterfaceActions

To program these pricing function modifications, you need to enter dates present in both the subscription and the charges. If you manually change subscription dates, your action is global. If you manually change charge dates, your action only affects this Charge.

Suspending andResuming

Subscriptions

In suspending a subscription offer or sub-offer, you can temporarily interrupt all existing prices. Usage and Recurring Rate calculations are stopped during this period. This system is useful for customers who do not use the service purchased for a fixed period; for example, when they are on holiday. When periodically interrupting costs, Prorata Rates may be applied if allowed for when setting up Recurring Rates in the price plan.

Level Action

Subscription

Suspend / Resume

Freeze prices

Cancel

Charge Activate / Deactivate



Subscription pricing automatically restarts on the planned resumption date.

FreezingSubscription Prices

By freezing a subscription price, you can guarantee your customer the stability of prices fixed during contract signature, for a given period. The prices outlined in the corresponding offers change to suit your needs but are not released to customers. At the end of the price freeze period, the updated prices are applied. You define the start and stop date of a price freeze period when creating a subscription.

CancellingSubscriptions

If a contract is unexpectedly terminated, you can cancel the subscription by manually changing the cancellation date. This cancellation is permanent. If you have included one-shot cancellation fees in the price plan for a charge, these are calculated.

This functionality can be useful to you each time a customer interrupts their contract before the normal stop date. For example, a customer may subscribe to an option, then decide to cancel it early.

Activating andDeactivating Charges

You can desynchronize the rating of a charge from the saving of a subscription by using the charge activation system. Desynchronization differs depending whether the charge is mandatory or optional. You can also deactivate a charge by programming a rating expiration date.

With the entire system, you can thus activate “special request” charges for a given period. You may find this method very useful when offering your customers individual discounts.

Activating MandatoryCharges

You need to determine the rating start date for mandatory charges when you save subscriptions, or program this date in advance. This way, you can satisfy customers who wish to apply certain charges at a later date, without further action on your part.

Activating OptionalCharges

For optional charges, you are free to choose any rating start date. You do not need to specify the date when you save the subscription and until you do specify the date, the charge will not be active. Optional charges can only be activated manually.

DesynchronizedActivation Example

The training organization Techlingua signs a contract with Learn.com for the complete Organization Module to start a new in-house training program. Techlingua wishes the subscription to start three months after signing the contract. To ensure this, you simply need to enter a “subscription” charge effective date in the Techlingua subscription. The date must be three months later than the effective subscription date.



Dates in Offers andSubscriptions

The following figure illustrates the main concepts linked to the management of dates presented in this section.

The figure shows a subscription to an offer and a sub-offer. It also shows an activated charge of a subscription which begins after the effective subscription date, as in the Techlingua example above.

During the subscription, several events occur:

A period of fixed (frozen) prices

A period of suspension for the sub-offer, then later for the offer itself

An early cancellation, which may or may not attract cancellation fees, depending on how your offer is set up

An “End Obligation Date” can also be specified for the offer. If the customer cancels the offer before this date, penalties will apply such as extra fees. Penalties will not apply if the customer cancels the offer after the End Obligation Date.



The Effective Date of the subscription is the date on which the subscription is activated. You can choose an Effective Date before the current date, provided that it is later than the Effective Date of the offer.

Offer Expiration Date

Offer Effective Date

SubscriptionEffective Date

Subscription Expiration Date

Sub-offer Effective Date

Sub-offer Expiration Date

Charge Expiration Date

Charge Effective Date

Frozen Price Date

UnfrozenPrice Date

SuspensionDate

Resumption Date

Cancellation Date

No usage or recurring rates

Fixed prices

Activated charge of

subscription

Subscription to Sub-offer

Subscription to Offer

Offer

No usage or recurring rates

Fixed prices

Fixed price period

Suspension period



Setting Up Activated Charges

In addition to customizing subscription functions, you can further adapt subscriptions to meet your customers’ needs by using a mechanism similar to the one you used for offers. This means setting up activated charges.

Setting Up ActivatedCharges

Creating a subscription gives you the same setup as defined in the corresponding offer. The setup for charges used in the offer are the same as the setup chosen in the offer. However, you can still redefine certain characteristics that will only be valid in the subscription. These characteristics form part of the charges activated in the offer.

This control system is referred to as setting up activated charges and is a function available in all subscriptions, no matter how complex they are.

RedefiningCharacteristics

When you create a subscription, and if an associated offer price plan contains “redefinable” parameters (“visible” option in the graphical interface) or counters, and if it uses translation tables, you can still do the following:

Redefine parameter values

Define exceptions for translation tables

Modify counter values

ApplyingRedefinitions

The following rules are the main application rules for redefining characteristics:

Redefined characteristics are valid only for the concerned subscription.

If you do not redefine these characteristics, it is the values applied in the general framework of the offer that will be used.

Shared plans change the redefinition possibilities of counters and parameters in activated charges. For more information, please refer to the Shared Plans section of this chapter.



Setting Up the Charging Mapping of Charges

This chapter is closely related to the chapter Subscriber Accounts.

In a charge of a subscription, you can assign an account and credit limit balances of a subscriber account to a reference of a charging plan. When a calculation is carried out in the price plan, the charging plan charges the calculated amount to the account, and optionally to the credit limit balances of the subscriber account according to the charging mapping.

If neither the reference defined in the charging plan nor its back-up reference is linked to an account in the subscription mapping, the charged account will be the default account of the subscriber account.

In a subscription, the charging mapping of a charge looks like the table below, in which you assign charging plan references to accounts and credit limit balances defined in the related subscriber account.

Charging reference Charged account Credit Limit Balance #1



CompanyAccount Atlantide --------------- --------------- ---------------

IndividualAccount Individual --------------- --------------- ---------------



Making Changes in Subscriptions

Eventually, subscriptions present in your system will change and you will consequently need to modify them either on request of your customer, as a result of changes to your sales policy, or to eliminate anomalies. This section presents the main subscription modification rules and concerns the four main principles of pricing, structure, function, and the setting up of integrated charges.

Price Changes Existing subscriptions follow changes made in the pricing terms linked to the offer. For example, the basic subscription price in the subscription charge may change and, in turn, affect signed offer contracts containing this charge. However, contracts with a current frozen price period or specific terms are not affected. As far as a frozen price is concerned, the updated prices are applied at the end of the freeze period. It is necessary to manually change the subscription values if specific subscription terms have been applied.

Structure Changes You can change the composition of a subscription by increasing the subscription quantities, by subscribing to optional offers, and by activating optional charges. However, you cannot remove subscriptions or charges after their expiration date. You therefore need to make changes to the subscription function.

Function Changes You can use one of the means below to change a subscription function:

Add or remove existing accesses (this concerns only the charges). Refer to access chronology, earlier in this chapter.

Change the charging mapping included in subscriptions

Modify certain choices such as expiration date, suspension date, resumption date and frozen price date.

However, you cannot change charges or subscription effective dates. If you need to change the stop date, you have to use cancellation dates.

Setup Changes If necessary, you can change the setup of activated charges (counters, parameters, translation tables).

Accessing andDeleting

SubscriptionVersions

When you modify and save a subscription, you can access all previous

versions of it by clicking on the clock button on the toolbar. You can only delete a version by deleting all previous versions. You can delete all previous versions of a subscription by modifying and saving your



subscription, then specifying an effective date earlier than the effective date of the original version.

The same principle for modifying and deleting versions exists for charges, offers, pricing macros and translation tables.



Subscriptions: Application Example

SubscriptionExample

Learn.com proposes a “Complete Module” complex offer, a combination of the “Basic Module,” “Document Download,” and Techlingua “Access Server” Offers (see application example of an offer in this chapter).

Techlingua wishes to subscribe to this offer but does not want to pay registration or membership fees. In addition, Techlingua requests a discount on the subscription fee. After negotiation, the following proposal is accepted:

10 “Basic Module” subscriptions, with no module registration fee

1 “Document Download” subscription

5 “Server Access” subscriptions, with no membership fee

5% discount on the subscription fee

Overall subscription fees fixed at $20

Illustration The illustration below shows the Techlingua subscription in the graphical interface:

Components Number of subscriptions

Content Note

Basic Module Offer 10 2 activated charges (instead of 3)

Registration Fee charge not activated

Basic Download Offer 1 1 charge

Server Access Offer 5 1 activated charge (instead of 2)

Membership Fee charge not activated

Module Discount Charge 1 Activated charge with a rate of 5% (Parameter)

Subscription Fee Charge 1 Activated charge



Shared Plans

Introduction Product pricing is described in charges, which contain the calculation algorithm of a price and all the elements useful for this calculation: counters, parameters, pricing macros, translation tables, and so on. These charges are then used in offers and activated in subscriptions.

Although pricing methods are essentially developed in charges, certain previously described functions permit you to modify some methods in the offers and subscriptions. This allows you to adapt the system to the commercial policy and demands of the customers. In this way, setting up the charges used in offers or setting up Activated charges in subscriptions permits you to modify parameters, counters and translation tables used in charges.

To improve the flexibility of the system, Highdeal Transactive provides an additional mechanism: shared plans. This mechanism makes pricing of offers more coherent and answers the specific needs of customers organized by group.

In This Section This section describes the basic concepts necessary for understanding shared plans in offers and subscriptions. These concepts are presented first in a general overview and then in the five application examples listed below:

Shared Plan Overview

Example 1: Telephone Subscription

Example 2: Commission Received on Plan

Example 3: Internet Connection

Example 4: Shared Minutes Plan

Example 5: Favorite Phone Numbers



Shared Plan Overview

Shared plans cannot be used in stateless mode.

Better reuse of charges leads to building independent modular charges, in order to later combine them freely in various offers. This organization can require forming links between certain pricing variables. In addition, the particular conditions granted to groups of subscribers assume an adapted management. To respond to these needs, Highdeal Transactive provides a specific mechanism called shared plans.

Shared Plans Shared plans insert additional elements in offers. These are referred to as ‘shared.’ They represent other elements, defined in the charges used inside offers. In this way, they play the role of several elements at the same time. The shared elements form connections between pricing variables that were initially separated. More concretely, if you attribute particular values to these shared elements, the values are grouped together in offers or subscriptions. These elements and values thus become available (that is to say, shared) for all offer components and corresponding subscriptions.

Objective The advantage of shared plans is two-fold:

First, shared plans facilitate the grouping of the pricing in an offer, by forming links between independent algorithms shared in several charges.

Second, shared plans simplify the management of particular conditions by permitting you to define values at one level of the offer structure or subscription, and to declare them 'shared.'

Therefore, these shared values do not need to be repeated to be accessible in the lower levels (used charges or activated charges, sub-offers, sub-subscriptions). The field of application of these values subsequently varies according to the level where they were defined.

What You Can Share It is possible to share the following chargeable items in offers and subscriptions:

counters

parameters

Translation table instances



Implementation The implementation of a shared plan is based on a catalogue of independent charges, which uses elements of a similar nature. These are the following types: counter, parameter, or translation table.

For example, a telephone subscription offer can be built based on three charges (subscription fee, call fee, administrative fee). In these generic charges, the subscription and call fees always depend on a 'number of call hours' payable in the basic price. The number of hours serves as a parameter in the two corresponding chargecharges. Placed in the context of the telephone subscription offer, this 'number of hours' parameter corresponds to a monthly plan of two, three, or four hours. In fact, this 'number of hours' parameter is unique, yet common to the whole of the pricing in the offer. It must therefore be shared.

The implementation of shared plans is carried out by creating the following:

In the offer, the shared parameter 'number of hours' (shared)

Two links, between this shared parameter and the corresponding parameters of two charges used: 'number of hours' (subscription) and 'number of hours' (calls)

Finally the 'number of hours' (shared) parameter represents the two initial charge parameters in the offer.

The implementation of the sharing of a counter or a translation table is carried out according to the same principle.

Specific Rules The sharing of a parameter or counter inside an offer changes the rules for setting up charges (described earlier in this chapter). A shared parameter can be redefined in an offer where it is declared or in a corresponding subscription, but the parameters that it represents are no longer modifiable locally in the charges used or activated charges. In the same way, a shared counter can be modified in a subscription related to the offer where it is declared, but counters that it represents are no longer modifiable in activated charges.

The sharing of a translation table does not change the possibility of redefining this table in the charges used and activated charges.

Overview ofExamples

To illustrate the shared plans mechanism, five examples are presented in the remainder of this chapter. These five examples are summarized in the following table:



Example Offer type Shared element Reason for sharing

Telephone Subscription Basic Counter and

parameterTo link variables

Commission Received on Plan Basic Parameter

Internet Connection Complex CounterTo meet the needs of customers organized by group

Shared Minutes Plan Complex Counter and parameter

Favorite Numbers Complex Translation table



Example 1: Telephone Subscription

Description The operator Telcoserv wants to sell the ‘Telephone subscription’ Offer. This offer proposes using a mobile phone and the billing of the offer is based on the following:

Monthly subscription fees

Cost of calls by the minute

The offer contains a monthly credit of prepaid call minutes in increments of 60, 120, or 180 minutes. The monthly subscription price depends on the monthly credit chosen by the customer.

Implementation (1stMethod)

Telcoserv can use an existing charge in its catalogue that links two types of Rates: Recurring and Usage. The price plan contains two main branches:

Pricing branch of Recurring Rate, which describes the calculation of subscription fees

Pricing branch of Usage Rate, which describes the calculation of call fees

The operator copies this existing charge and adapts the price plan in the following way:

If the operator builds the charge according to this method, then establishing sharing at the offer level does not make sense. This is because, through construction, the Credit parameter and the C counter are common to the two charge rates. The operator can build the offer by simply using the ‘Telephony’ charge without any specific action. The Credit parameter can be redefined freely in the ‘Telephony’ used charge.

Charge Added Elements Usage

Telephony

Credit Parameter (number of minutes prepaid monthly)

• Recurring Rate branch: The monthly price depends on the “Credit” parameter

• Usage Rate branch: If the number of minutes consumed during the month is less than the “Credit” parameter, consumption is free of charge, otherwise a price different from zero is applied

C Counter (number of minutes consumed monthly)

• Recurring Rate branch: resets C• Usage Rate branch: updates the C

counter based on call duration



Subscriptions related to the ‘Telephony’ offer can be adapted to what the customer chooses, in accordance with the parameter rules of the activated charges: redefining or modifying the Credit parameter and C counter.

Implementation (2ndMethod)

Tecoserv now wants to make its catalogue upgradeable: it wants to avoid creating too many charges but at the same time wants to stay flexible with respect to offer construction. To create the ‘Telephone Subscription’ offer, it is possible to do the following: create two independent charges, each possessing one parameter and one counter

Create the offer using these two charges

Create a parameter and a counter that are shared in the offer

Link the shared parameter to the two corresponding parameters of the charges

Link the shared counter to the two corresponding counters of the charges

In the end, the offer contains:

One sharedshared parameter representing the parameters of the two charges

One shared counter representing the counters of the two charges

You can modify these two elements by intervening at the highest level in the offer. The modifications are passed on to the represented elements.

The second method, detailed below, is a simple application of shared plans.

Charge Catalogue

Charge Content Created elements Usage in the branch

Subscription 1 Recurring Rate branch

P-sub parameter (number of minutes)

Price depends on P-sub parameter

C-sub counter (number of minutes consumed)

Resets the C-sub counter to the beginning of the period

Call 1 Usage Rate branch

P-call parameter (number of minutes)

If the number of minutes consumed is less than the P-call parameter, the consumption is free of charge; otherwise a price different from zero is applied

C-call counter (number of minutes consumed)

Updates the C-call counter using the call duration



In the subscriptions related to the ‘Telephone Subscription’ offer, the operator can redefine or modify the P-Credit parameter and the C counter, depending on customer needs. These changes will be passed on to the parameters and counters that they represent in the activated charges. On the other hand, all action in the activated charges that is applied to the P-sub and P-call parameters or to the C-sub and C-call counters becomes impossible.

Diagram The following diagram illustrates the structure of the ‘Telephone Subscription’ offer according to the two methods presented in the example:

Offer Description

Offer Shared elements created in the offer

Implemented links

Telephone subscription: usage of 2 charges • Subscription • Call

P-Credit parameter (number of prepaid minutes)

• P-Credit <-> P-sub (‘subscription’ used charge)

• P-Credit <-> P-call (‘Call’ used charge)

C counter (number of minutes consumed)

• C <-> C-sub (‘subscription’ used charge)

• C <-> C-call (‘Call’ used charge)



Charge

Offer

Parameter

Counter

link: ”is represented by …”

Telephone Subscription

‘Telephony’Charge

‘Telephony’Charge

Telephone Subscription

C

Credit

Method 1

C

‘Subscription’ Charge‘Subscription’ Charge ‘Call’ Charge‘Call’ Charge

C-sub C-call

P-Credit

P-sub P-call

Method 2



Example 2: Commission Received on Plan

Description The telephone operator Telcoserv would like to sell the ‘Monthly Plan’ offer. The operator proposes mobile telephone usage, based on three monthly calling plans with preset call times: 1 hour/month, 2 hours/month, and 4 hours/month. For each subscription to a plan, the salesperson receives a commission which varies depending on the plan that was sold. The offer is billed according to four types of charges:

Monthly subscription, which varies according to the plan that was sold

Call time (by the minute) outside the monthly call plan

Administrative fee

Commission, which varies according to the plan that was sold

The plan type is determined upon subscription (according to what the customer chooses) and is translated into parameters. This ‘plan type’ information is present in three charges. The shared plans mechanism makes it easy to work with this example.

Implementation The operator can build the ‘Monthly Plan’ offer in the following way:

Create four independent charges, three of which use the ‘plan type’ parameter to describe the rating

Create the offer using these four charges

Create a ‘plan type’ shared parameter in the offer

Link the shared parameter to the three corresponding parameters in the charges

The details are presented in the following table:

Charges Catalogue

Charge Created elements Usage in the charge

SubscriptionP-sub parameter (plan type, in number of prepaid hours)

The subscription price depends on the P-sub parameter

CallP-call parameter (plan type, in number of prepaid hours)

Within the agreed-upon plan P-call, the Call is free; outside this, calls must be paid for

Administrative fee

Commission (dependent charge)

P-comm parameter (plan type, in number of prepaid hours)

The amount paid depends on the P-comm parameter



In the subscriptions related to the ‘Monthly Plan’ offer, the operator gives the value of the plan chosen by the customer to the P-plan parameter. This value is passed on to the P-sub, P-call, and P-comm parameters. However, all action in the activated charges that is applied to the P-sub, P-call, and P-comm parameters becomes impossible.

Diagram The following diagram illustrates the offer structure in the ‘Commission Received on Plan’ example:

Offer Description

Offer Shared element created in the offer

Implemented links

Monthly plan: usage of 4 charges• Subscription• Call• Administrative Fee• Commission

P-plan parameter (plan type)

• P-plan <-> P-sub (‘Subscription’ charge)

• P-plan <-> P-call (‘Call’ charge)

• P-plan <-> P-comm (‘Commission’ charge)



Parameter

Counter

Charge

Offer

Link: « is represented by »

Dependency between Charges

Commission received on

Plan

‘Subscription’Charge

‘Subscription’Charge ‘Call’ Charge‘Call’ Charge

‘Commission’Charge

‘Commission’Charge

‘Administrative Fees’ Charge

‘Administrative Fees’ Charge

1h, 2h or 4h in Subscription

P-plan

P-sub P-call P-comm

‘Commission received on Plan’ Offer



Example 3: Internet Connection

Description The Telcoserv operator proposes a fast Internet connection to a clientele made up of various businesses. This is a high-performance, expensive connection. The operator decides to promote this product to business groups that are made up of a central management and various independent stores. The operator proposes varying the connection price depending on the number of stores that are connected. The more stores that subscribe to this service, the larger the discount is. In this way, the central management can suggest to stores who need an Internet connection that they subscribe to this product.

Commercial Offer Telcoserv sets up the corresponding commercial offer in the following way:

The ‘Single Connection’ offer is proposed to stores that are attached to the central management; each store chooses whether or not to subscribe

The ‘Group Connection’ offer, composed of the ‘Single Connection’ sub-offer, is subscribed to by the central management

Pricing The basic ‘Single Connection’ offer is billed based on the following fees:

Monthly subscription, the price of which varies according to the number of ‘user’ stores ($50 for 1 to 10 users, $40 for 11 to 20, $30 for more than 20)

Installation

Connection by the minute

Cancellation

To calculate the total number of ‘user’ stores and guarantee the coherence of the entire offer, it is necessary to do the following:

Create a counter in the basic ‘Single Connection’ offer (updates the number, choice of subscription price depending on its value)

Create a counter in the ‘Group Connection’ offer and link it to the previous counter (shares the total number of users among the subscriptions of ‘Single Connection’ sub-offer)

Single ConnectionCounter

This counter is updated during a subscription (increment of 1 in the calculation of installation fees) and during a Cancellation (decrement of 1), then tested during the calculation of the subscription fees. It is then used during the calculation of three types of fees. If the offer is divided, based on the four previous fee types, into four independent charges, then three distinct counters are present and must be reunited using a shared counter defined in the ‘Single Connection’.



Group ConnectionCounter

This shared counter is created in the ‘Group Connection’ offer, then linked to the ‘Single Connection’ sub-offer counter. The counter permits the total number of subscribers in all the subscriptions of the ‘Single Connection’ sub-offer to be combined. It therefore finalizes the calculation of the subscription fees based on the total number of users.

Implementation To implement this example, the operator builds the complex ‘Group Connection’ offer by doing the following:

Create four independent charges, three of which contain a counter representing the number of users (Users-sub, Users-inst, Users-canc)

Create the basic ‘Single Connection’ offer by using these four charges

Create a shared counter, Num-Users(1), in the ‘Single Connection’ offer

Link this shared counter to the three corresponding counters in the charges

Create the complex ‘Group Connection’ offer from the ‘Single Connection’ offer

Create a shared counter, Num-Users(2), in the ‘Group Connection’ offer

Link the Num-Users(2) shared counter of the main offer to the Num-Users(1) shared counter of the sub-offer

The details are presented in the following table:

Charge Catalogue

Charge Rate used Created elements Usage in the charge

Subscription Recurring Users-sub counter

Price depends on Users-sub

Installation One-shot Users-inst counter

Users-inst is incremented by 1

Cancellation One-shot Users-canc counter

Users-canc is decremented 1

Connection Usage



In the subscriptions related to the ‘Group Connection’ offer, the operator can modify the initial value of the Num-Users(2) counter. This value is passed on to the Users-sub, Users-inst, and Users-canc counters. However, all action in the activated charges that is applied to the Users-sub, Users-inst, and Users-canc counters becomes impossible.

Diagram The following diagram illustrates the offer structure in the ‘Group Connection’ complex offer’ example

Offer Description

Offer Offer type Composition Shared element created in the offer

Implemented links

Single Connection Basic

4 charges • Subscription• Installation• Cancellation• Connection

Num-Users(1) counter

• Num-Users(1) <-> Users-sub

• Num-Users(1) <-> Users-inst

• Num-Users(1) <-> Users-canc

Group Connection Complex

‘Single Connection’ offer

Num-Users(2) counter

• Num-Users(2) <-> Num-Users(1)



Parameter

Counter

Charge

Offer

Link: “is represented by …”

‘Group Connection’ complex Offer

Simple Connection



‘Connection’Charge

‘Connection’Charge

Users-sub

‘Installation’Charge

‘Installation’Charge

Users-inst

‘Cancellation’Charge

‘Cancellation’Charge

Users-canc

Group Connection

Modifiable Counter in the Subscription

Num-Users(1)

Num-Users(2)



Example 4: Shared Minutes Plan

Context Telcoserv is selling several types of calling plans for mobile telephones. Certain customers who are professionals subscribe to numerous monthly plans, designed for employees of the businesses. Depending on the activity of the employees, the calling plan minutes are often supassed or, on the other hand, the minutes are not used up. The company Learn.com would like to use a shared calling plan which would play the role of a reserve from which employees surpassing their regular calling plan minutes could take supplementary minutes.

Individual Pricing An employee's individual plan can contain 30, 60, 120, or 180 minutes. It is billed based on the following:

Monthly subscription fees, which vary depending on the plan chosen

Call fees

The presence of a shared plan changes the calculation mode for call costs. In absence of a reserve, a price by the minute is applied as soon as the number of minutes consumed individually surpasses the plan. In the case of a shared plan, if the number of minutes consumed from the reserve plan is below the reserve, the individual minutes that surpass it are charged to the reserve plan. As long as the reserve plan isn't used up, the calls made beyond the individual plans remain free of charge. When the reserve is used up, individual calls are billed by the minute.

Shared Minutes PlanPricing

The Shared Minutes Plan can contain 30 or 60 minutes. It is billed only according to the subscription fees because it is not used directly. The subscription fees vary according to the number of minutes chosen.

Implementing theOffer

To implement this example the operator builds the 'Shared Minutes Plan' offer by doing the following:

1 Create two independent charges: subscription and Calls

2 Create the 'Individual Plan' basic offer, destined for the employees, using these two charges

3 Create shared elements useful for the Individual Plan offer and link them to the corresponding elements

4 Create the 'Shared Minutes Plan' complex offer from the subscription charge and the 'Individual Plan’ offer

5 Create shared elements to consolidate the ‘Shared Minutes Plan’ offer and to link the corresponding elements



The details of the steps are presented in the following table:

Step 1 Charge Catalogue

Charge Rate used Created elements Usage in the charge

Subscription Recurring

P-sub parameter (number of calling plan minutes)

Price of the ’subscription’ depends on P-sub

C-sub counter (number of minutes consumed in the period)

Resets C-sub

Call Usage

P-call parameter (number of calling plan minutes)

Calculation of the price of the calls (test of the C-call counter in relation to planned P-call plan)

P-res-call parameter (number of calling plan reserve minutes)

Calculation of the price of the calls (test of the C-res-call counter in relation to planned P-res-call plan)

C-call counter (number of calling plan minutes consumed)

• Calculation of the price of the calls (test of the C-call counter in relation to planned P-call plan)

• Update C-call counter

C-res-call counter (number of calling plan reserve minutes consumed)

• Calculation of the price of the calls (test of the C-res-call counter in relation to P-res-call)

• Update C-res-call counter (if necessary)

Step 2 ‘Individual Plan’ offer

Offer Composition

Individual Plan2 charges • Subscription• Call



Step 3 Shared Plan (‘Individual Plan’ Offer)

Type of shared element created

Name Meaning Implemented links

Parameter P-indNumber of ‘Individual Plan’ minutes

Link between P-ind and the corresponding parameters of the 2 charges:• P-ind <-> P-sub

• P-ind <-> P-call

Counter C-indNumber of minutes consumed on the ‘Individual Plan’

Link between C-ind and the corresponding counters in the 2 charges:• C-ind <-> C-sub• C-ind <-> C-call

Step 4 ‘Shared Minutes Plan’ Offer

Offer Composition

Shared Minutes Plan

• ‘Individual Plan’ offer• ‘Subscription’ charge

Step 5 Shared Plan (‘Shared Minutes Plan’ Offer)

Type of shared element created

Name Meaning LInks implemented

Parameter P-sharNumber of shared plan minutes

Link between P-shar and the corresponding parameters in the ‘subscription’ charge and the ‘Individual Plan’ offer: • P-shar <-> P-sub

• P-shar <-> P-res-call

Counter C-sharNumber of shared plan minutes consumed

Link between C-shar and the corresponding counters in the ‘subscription’ charge and the ‘Individual Plan’ offer:• C-shar <-> C-sub• C-shar <-> C-res-call



ImplementingSubscriptions

The Language & Technology group subscribes to the 'Shared Minutes Plan' offer based on the following conditions:

10 individual plans divided into:

4 plans of 30 minutes



1 plan of 180 minutes

1 ‘Shared Minutes Plan’ of 60 minutes

The operator first creates the main subscription, then creates the 10 subscriptions, as follows:

The main subscription of Language & Technology, assigning it the value of 60 to the P-shar parameter

10 Subscriptions to the 'Individual Plan' sub-offer, with the corresponding values of the P-ind parameter: 30 (4 cases), 60 (three cases), 120 (two cases), 180 (one case)

Diagram The following diagram illustrates the structure of the ‘Shared Minutes Plan’ offer:



Parameter

Counter

Charge

Offer


‘Shared Minutes Plan’ complex Offer

IndividualPlan



‘Subscription’ Charge

‘Subscription’ Charge

Shared Minutes Plan

‘Call’ Charge‘Call’ Charge

30 or 60 mnin the

Subscription30, 60, 120 or 180 mn in the Subscription

C-shar

C-subC-sub

P-subP-subP-sub

C-sub

P-call P-res-call

C-call

P-shar

C-ind

P-ind

C-res-call



Example 5 Favorite Numbers

Context Telcoserv gives its customers discounts on the price of certain telephone calls when they are related to certain services (emergencies, finding information) or to specific personal numbers (favorite numbers). When the offer is related to individuals, the charge used and activated charge parameters make it easy to respond to needs. When the offer is related to groups of customers, the operator wants to compile a list of ‘favorite numbers’ shared by the entire group for which a 20% discount is granted. For example, the list of group numbers can consist of the ‘favorite numbers’ of a group. This type of list exists in all the groups, and its content is shared by all group members. However, it is different from one group to another. The shared plan mechanism is a way to provide a solution for this need.

Commercial Offer Telcoserv proposes the following three main telephone service offers:

‘Basic Service’ offer, intended for individual customers, personal or professional use

‘Monthly Plan’ offer, intended for individual customers, personal or professional use

‘Group’ complex offer, made up of two sub-offers: ‘Basic Service’ and ‘Monthly Plan’, intended for companies. Each company employee can subscribe to one of two sub-offers

The operator’s commercial policies lead him to propose discounts on telephone call prices at several levels:

For all customers: discounts on emergency and information numbers

For individual customers: discounts for all customers (informations services for the general public) or specific discounts for certain customers (favorite personal numbers)

For customers who are businesses (companies): identical discounts for all the companies (professional information services), specific discounts for each company (list of company employee numbers), and specific discounts for certain employees (favorite personal numbers)

Applying Discounts To apply discounts, the operator enters the corresponding information (called numbers and discount percentages) in a translation table called ‘Discount’. This translation table is used in the ‘Call’ charge, which serves as the base pricing module to the ‘Basic Plan’ and ‘Monthly Plan’ offers. The call price is therefore always calculated by taking into account the base price, the called number, and the discounts in the ‘Discount’ translation table.

Managing Discounts The commercial policy described previously demands a lot of flexibility in managing information about discounts. Shared plans applied to the



‘Discount’ Table, combined with redefinitions or ‘exceptions’ installed at various levels of the structure of the offers and subscriptions, facilitate this management. The following table regroups and specifies the means adapted to each type of need and the concerned structure:

Building theCatalogue

The operator builds his catalogue by successively creating the following:

1 The ‘Discount’ translation table

2 The ‘Call’ charge

3 The ‘Basic Service’ offer

4 The ‘Monthly Plan’ offer

5 The ‘Group’ offer, including the implementation of ‘Discount’ translation table

Building the catalogue is done by taking into account the needs described below; all actions that are needed in the offer-type structures are carried out. The details of the steps are presented in the following tables:

Needs and Means

Offer Need Need N°

Means Structure

AllThe same discounts for all customers (emergency and information numbers)

1 ‘Discount’ Translation table ‘Call’ charge

• Basic Plan

• Monthly Plan

The same discounts for all customers (information service for the general public)

2 Exceptions on the ‘Discount’ Table

• ‘Basic Service’ offer• ‘Monthly Plan’ offer

Basic Service

Specific discounts for one customer: customer favorites 3 Exceptions on the

‘Discount’ TableCustomer subscription to the ‘Basic Service’ offer

Group

The same discounts within each customer group (group favorites)

4Shared plan: sharing of the ‘Discount’ Table

• Group offer• Group customer

subscription to the ‘Group’ offer

The same discounts for all customer groups (professional information services)

5 Exceptions on the shared Table ‘Group’ offer

Specific discounts for the ‘Basic Service’ sub-offer subscribers (consumption information service)

6 Exceptions on the ‘Discount’ Table ‘Basic Service’ sub-offer

Specific discounts for one member of one group (customized favorites)

7 Exceptions on the ‘Discount’ Table Member subscription



Step 1 Creating the ‘Discount’ Translation Table

Input column (the number called)

Output column (% of discount)

Service

112 100 Emergency

123 50 Telephone directory

Step 2 Creating the ‘Call’ Charge

Charge Content Characteristic element

Usage

CallOne usage rating branch

‘Discount’ translation table

The price of a call is discounted if the called number is already in the ‘Discount’ Table

Step 3 Creating the ’Basic Service’ Offer

Offer Content Need N°

Action Location of the action (structure)

Basic Service ‘Call’ charge 2

Redefine the ‘Discount’ Table: add 2 information service numbers 456 -> 20% discount (traffic info) 868 -> 10% discount (weather)

‘Call’ used charge

Step 4 Creating the ‘Monthly Plan’ Offer


Action Location of the action (structure))

Monthly Plan ‘Call’ charge 2

Redefine the ‘Discount’ Table: add 2 information service numbers456 -> 10% discount (traffic info) 868 -> 5% discount (weather)

‘Call’ used Charge



Diagram The following diagram illustrates the structure of the ‘Basic Services’ and ‘Monthly Plan’ offers:

‘Call’ Charge‘Call’ Charge‘Call’ Charge‘Call’ Charge

Monthly Plan

Discount

Redefinition of the ‘DiscounTranslation Table in the ‘Cal

Used Charge

Basic Service

Charge

OfferTranslation Table

50%123

100%112

Discount

10%868

20%456

50%123

100%112

5%868

10%456

Redefinition of the ‘Discount’ Translation Table in the ‘Call’

Used Charge

‘Basic Service’ Offer ‘Monthly Plan’ Offer



‘Group’ OfferDiagram

The following diagram illustrates the structure of the ‘Group’ offer:

Step 5 Creating the ‘Group’ Offer



Group

• ‘Basic Service’ sub-offer

• ‘Monthly Plan’ sub-offer

4

Define the shared element GroupDiscount (specific ‘Discount’ Table instance)

Group offer

Link GroupDiscount to the ‘Discount’ Table

‘Call’ used Charge in the ‘Basic Service’ sub-offer

Link GroupDiscount to the ‘Discount’ Table

‘Call’ used Charge in the ‘Monthly Plan’ sub-offer

5

Redefine the ‘GroupDiscount’ table: add 1 professional information service number989 -> 10% discount (financial info)

Group offer

6

Redefine the ‘Discount’ table: add one consumption information number030 -> 50% discount (consumption info)

‘Call’ used Charge in the ‘Basic Service’ sub-offer



Description of theExample

The operator has a previous catalogue at his disposal and must satisfy new customers:

John Woods subscribes to the ‘Basic Service’ offer and would like to have a 20% discount on seven favorite numbers

The Language & Technology company subscribes to the ‘Group’ offer, for 10 employees, 6 of whom choose the ‘Basic Service’ sub-offer while the other 4 choose the ‘Monthly Plan’ sub-offer. The 10 employee numbers are group favorites; there is a shared 20% discount on these numbers. One of the 10 agents, Mike Smith, has chosen the ‘Monthly Plan’ sub-offer and would like to have 20% discount on a list of 3 favorite personal numbers.

The customer requests are integrated with the needs that were described beforehand (3, 4, and 7). The corresponding method is as follows:


Monthly Plan

Discount


Basic Service

50%123

100%112

Discount

10%868

20%456

50%123

100%112

5%868

10%456

Charge

OfferTranslation Table


50%030

10%989

Group Discount

Redefinition of the ‘GroupDiscount’ Translation Table in the ‘Group’

complex Offer

Redefinition of the ‘Discount’ Translation Table in the Used Charge of the ‘Basic

Service’ sub-Offer

‘Group’ complex Offer

‘Group’ Offer



Customer Need N°


John Woods 3

Create a subscription for John Woods to the ‘Basic Service’ offer

Redefine the ‘Discount’ table: add the 7 favorite numbers and the 20% discount

‘Call’ activated charge in John Woods’ subscription

Language & Technology

4

Create the ‘Group’ offer subscription with the following:• 6 Subscriptions to the ‘Basic

Service’ sub-offer • 4 Subscriptions to the ‘Monthly

Plan’ sub-offer

Enter the 10 favorite group numbers into the shared ‘GroupDiscount’ table and the 20% discount

Language & Technology subscription

7Redefine the ‘Discount’ table: add Mike Smiths’s 3 favorite numbers and the 20% discount

‘Call’ activated charge in Mike Smith’s subscription



Diagrams of theSubscriptions

The following diagrams illustrate the Submersions for John Woods, Languages & Technology, Employee 1, Employee 7, and Mike Smith.

Activated Charge

Subscription

Translation Table

50%123

100%112

Discount

10%868

20%456

‘John Woods’ Subscription

20%7

20%6

20%5

20%4

20%3

20%2

20%1

7 favorite numbers: redefinition of the

‘Discount’ Translation Table in the Activated

Charge

‘Call’

Redefinition of the ‘Discount’ Translation

Table in the Used Charge of the ‘Basic Service’ Offer

‘John Woods’ Subscription



Activated Charge

Subscription

Translation Table

‘Language & Technology’ Subscription

20%10

20%9

20%8

20%7

20%6

20%5

20%4

20%3

20%2

20%1

10 favorite numbers: contents of the

‘Group Discount’ shared Translation

Table, which is defined in the Subscription

‘Language & Technology’ Subscription

6 Subscriptions to the ‘Basic Service’ sub-

Offer

4 Subscriptions to the ‘Monthly Plan’

sub-Offer

‘Group Discount’

10%989

Redefinition of the ‘Group Discount ’ Translation

Table in the ‘Group’ Offer

Activated Charge

Subscription

Translation Table

50%123

100%112

‘Discount’

10%868

20%456

‘Agent 1’ Subscription

‘Call’


Table in the Used Charge of the ‘Basic Service’ Offer


50%030

Redefinition of the ‘Discount’ Translation Table in the Used Charge of the ‘Basic Service’

sub-Offer ‘Agent 7’ Subscription


50%123

100%112

‘Discount’

5%868

10%456

‘Call’


Table in the Used Charge of the ‘Monthly Plan’ Offer



Results The following table presents a summary of the discounts granted:

Activated Charge

Subscription

Translation Table

‘Mike Smith’ Subscription 3 favorite personal numbers: redefinition of

the ‘Discount’ Translation Table in the ‘Call’ Activated Charge


Table in the Used Charge of the ‘Monthly

Plan’ Offer

‘Mike Smith’ Subscription

50%123

100%112

‘Discount’

5%868

10%456

20%3

20%2

20%1

‘Call’

Discounts Granted

Person(s) Number(s) Discount

John Woods

7 favorites 20%

456 20%

868 10%

112 100%

123 50%

Employees 1 to 6 (Languages & Technology)

030 50%

989 10%

10 favorites 20%

456 20%

868 10%

112 100%

123 50%



Advantage of Sharing In the case of translation tables, numerous customer needs can be satisfied by combining the redefinition of tables in the charges used and activated charges and the sharing of tables. The sharing of tables especially facilitates managing information that is specific to a group. This is because it is not necessary to repeat this information in the internal subscriptions of the group. In the previous example, you can obtain the same results by sharing the ‘Discount’ table, provided that you enter the list of favorite numbers of the company 10 times (one entry in each sub-offer subscription). This method also requires repeating the updates of the list as many times as the list contains members.

Respecting a determined order, the calculation system uses the values of information which is redefined and shared in the offers and subscriptions. Once a correspondence with the observed table is found, the search stops. When table sharing and redefinitions are combined, it is especially necessary to keep in mind this order, as described in the following table:

Employees 7 to 9 (Languages & Technology)

989 10%

10 favorites 20%

456 10%

868 5%

112 100%

123 50%

Mike Smith (Languages & Technology)

3 favorite personal numbers

20%

989 10%

10 favorites 20%

456 10%

868 5%

112 100%

123 50%

Discounts Granted

Person(s) Number(s) Discount



Observation Order of Translation Tables

Row Location Type

1 ‘Subscription’ activated charge Table redefinition

2 Sub-offer used charge Table redefinition

3 Subscription Shared table content (specific instance)

4 Offer Shared table redefinition (specific instance)

5 Basic Offer used charge Table redefinition

6 Translation table Table content


Chapter 4

Bill, Settle & Report Concepts

This chapter presents the features and functions in Highdeal Transactive that help you manage your billing, invoicing, Settlement Reports and data analysis.


Section Page

Creating the Bill, Settle and Report Environment 175

Billing and Settlement Concepts 177

Correcting Transactions 201

Rerating Subscriptions 203

Managing Disputes 207


Bill, Settle & Report ConceptsChapter 4



Creating the Bill, Settle and Report Environment

Bill, Settle and Report is a billing and monitoring tool that is adapted to your products and price plans. When describing the relationship between actors in the business model, it can apply to either a single or a multi-vendor context.

Once customer transactions have been rated in Price and Rate and charged in Balance Management, then Bill, Settle and Report stores transactions either in the billing database or the prepaid database. Bill, Settle and Report also calculates and generates invoices/settlement reports for prepaid or postpaid accounts according to the parameters that you previously specified in the tool.

To start setting up the Bill, Settle and Report environment, you need to complete the following steps:

Describe the parties involved in the financial transactions

Create the necessary postpaid accounts between these parties

Define cycles required to generate Invoices/settlement reports

Define invoice/settlement report templates

This chapter describes concepts that will help you carry out these steps.



Billing and Settlement Concepts

This section defines the following concepts in the Bill, Settle and Report environment:

Parties, account holders and service providers

Hierarchical structures between parties

Pospaid accounts

Postpaid account partition groups

Cycles

Isolated invoices

Tax calculation

Discounts

AML reports on prepaid or postpaid accounts



Bill, Settle and Report Actors

Many actors, whether companies or individuals, are involved in financial and commercial transactions linked to your activity. These actors perform different activities and play different roles.

In a sales context, the actors are service providers and account holders who are directly involved in activities. In the context of billing and settlement, it is mostly account holders and service providers who are involved.

Party In the Highdeal Transactive database, a Party is a representation of an actor who participates in financial or commercial relations. Each party has a unique identifier in the Bill, Settle and Report system.

There are two types of party: companies and individuals. This distinction is important for the tax applied when billing.

This icon represents a party in the GUI of Highdeal Transactive.

Account Holder In Bill, Settle and Report, an account holder is a party (either an individual or a company) that receives invoices or settlement reports. In other words, the account holder is the one who either pays or receives payment for transactions generated during the consumption of the product.

Service Provider In Bill, Settle and Report, a service provider is a party (either an individual or a company) that issues invoices or settlement reports. The service provider receives payment for transactions generated during the consumption of the product.



Hierarchical Structures

Hierarchy A hierarchy represents the financial and commercial structure of one or more companies. This model allows you to group parties with the same characteristics while making a distinction among their different roles.

Roles Parties may have the following roles within a hierarchy:

Account holder

Service provider

Owner: This party delivers hard goods or services but is not directly paid for what it supplies. The owner is paired with another party, who acts as service provider and who will be paid for these supplied hard goods or services.

Client/Partner: This party is directly involved in the commercial relationship but is not directly the account holder. For example, a client consumes hard goods or services. This party is paired with another party who acts as the account holder for the transaction (that is, who will pay for the consumed hard goods or services).

RelationshipsBetween Parties

The different relationships between parties are included in the hierarchy as parent to child and child to parent. These relationships allow lower-level “child” parties to inherit specific information from the upper-level “parent” parties.

This system optimizes the management of party-related information, such as name, description, company, postal and email addresses. It also enables you to generate and produce invoices that are consistent with your company’s organizational structure.



Postpaid Accounts

Postpaid Accounts A postpaid account consists of a balance which reflects the financial relationship between the service provider and the account holder.

This icon represents an account in the GUI of Highdeal Transactive.

Account Types The following types of accounts are available:

Postpaid receivable

Postpaid payable

The following table presents the possible relationships:.

In the case of a postpaid account calculates what

Accounts Receivable the account holder owes the service provider

Accounts Payable the service provider owes the account holder



Accounts Receivable Accounts Receivable (A/R) involves the following:

Keeping track of the balance due to the service provider

Managing and reporting outstanding balances on invoices

Receiving and processing payments from account holders

Managing collection files and related dunning steps

Managing customer scoring for categorization purposes

Accounts Payable Accounts Payable (A/P) involves the following:

Managing payments, such as commissions, that are due to third parties (such as content supplier or reseller partners) who have been modeled in Highdeal Transactive (see the note below)

Managing and reporting outstanding balances on settlement reports to partners

Making and processing payments

The Accounts Payable features in Highdeal Transactive are designed solely for managing Accounts Payable for parties modeled in Transactive as part of the Transaction Network. The entry into the Transactive system of arbitrary supplier invoices/settlement reports (for example, for office supplies) is not supported. The service provider who is using Highdeal Transactive needs to have a separate Accounts Payable system for managing payment to other suppliers.

Account Example A company called Learn.com sells online training tutorials to individuals and companies. Anne Smith works for Technical Services Ltd., a customer of Learn.com. She receives authorization from the Training department (of Technical Services Ltd.) to subscribe to monthly IT tutorials. Learn.com issues invoices for Anne Smith’s tutorials to the Training department.

To record the number of tutorials bought by Technical Services Ltd., you need to create an account (in Bill, Settle and Report) between the following parties:

Learn.com (service provider)

Training department (account holder)

Account Creation You create accounts in manual mode and one at a time. From this stage onwards, you are free to set the account parameters (such as account type, currency, taxes, invoice/settlement report calculation and generation cycles).



Blocking Accounts You may choose to block an account. When an account is blocked, corresponding transactions are refused. If this takes place during the integration phase of Highdeal Transactive, this refusal may lead to the suspension of the service. In this case, the end user will not be able to access the service. Please note that in addition to being able to block an account, you can also unblock an account at any time.

Closing Accounts If necessary, you can close an account. This action is permanent: you cannot charge a closed account nor can you reopen it. The only operations that are possible on a closed account (postpaid type) are the creation and edition of the last Invoice/settlement report. Please note that the last invoice/settlement report is always created, regardless of the amount.



Postpaid Account Partition Groups

A postpaid account partition group (also referred as 'partition group' in this document) allows recording all information (parties, transactions, invoices, and so on) related to a postpaid account in one or more partitions of the same group. This feature reduces the time to retrieve and process any information related to a postpaid account. For example, to create invoices, Highdeal Transactive retrieves all necessary information from only the dedicated partitions relating to the same account.

When creating a postpaid account, you can partition accounts depending on the following options:

The Default option

The Default Groups

Your own groups

Default Option You select this option to let Highdeal Transactive manage the partition of postpaid accounts in the database. Each postpaid account created is assigned to the Default Partition Group. Transactive automatically assigns the postpaid account to a default group corresponding to the creation date of the postpaid account (refer to the default groups).

Example If you create a postpaid account the 15th of January, Highdeal Transactive records the postpaid account in the Default Group #15 of the database.

About default groups and your own groups:

You cannot delete a partition group.

You cannot delete a partition.

After you create and save a postpaid account, the postpaid account is assigned to a partition group. A postpaid account already assigned to an existing group can no longer be assigned to another group.

Default Groups When installing Highdeal Transactive, 30 static partition groups are created in the database. These groups represent the 30 days of a month. The group names are the following:

Default Group #1

Default Group #2

Default Group #3

...

Default Group #30



When creating a postpaid account, you assign it to the group corresponding to the creation date of the postpaid account or to any group according to your criteria.

Your Own Groups If the Default option and the default groups do not meet your needs, you can create additional groups if necessary, and then partition the postpaid accounts as you want.

Example For one of your postpaid accounts, invoicing requires to process several millions of transactions. You then choose to create and assign a partition group to this postpaid account.



Cycle

Cycle When working with accounts, you need to define cycles. A cycle allows you to obtain invoices/settlement reports on the basis of transactions carried out on the account. Each postpaid account has its own cycle. A cycle is divided into two separate processes:

Invoice/settlement report calculation

Invoice/settlement report generation

Invoice/SettlementReport Calculation

Process

When you calculate an invoice/settlement report, Bill, Settle and Report calculates the total sum of all transactions related to the account and the corresponding tax due on this amount. It then enters a debit operation for the account in the database. In Bill, Settle and Report, when the account is debited, it means that a debit operation (negative amount) linked to the account is created and the account balance is updated.

Invoice/SettlementReport Generation

Process

When an invoice/settlement report is generated, all of the information that the service provider wants to send to the account holder is retrieved and integrated in an XML document. In Bill, Settle and Report, this XML document is based on an invoice/settlement report template (AML template) predefined by the service provider. You can then send this document electronically or to a specialized software company (such as StreamServe) for the final printing of the invoice/settlement report on paper.

Default andCustomized Cycles

When you create a service provider in Bill, Settle and Report, a default cycle is always created. This cycle is automatically assigned to all new accounts of the specified service provider. Cycles can then be customized for each account.

Threshold Amount For each service provider, you can set a threshold amount beyond which invoice/settlement report calculation is activated. If the threshold amount is not reached, the calculation process is put on hold. When the threshold amount is reached, invoice/settlement report calculation is launched depending on the parameter settings. For a closed postpaid account, this threshold is ignored during the calculation of the last invoice/settlement report.

Activation Mode You can customize the activation of billing processes in several ways. You can use the manual mode and the scheduled mode to calculate and generate invoices/settlement reports, and the synchronized mode to generate invoices/settlement reports only. The following table describes these settings:



Activation Mode

Available for Description

Manual

• Invoice/settlement report calculation

• Invoice/settlement report generation

The service provider manually activates each process

Scheduled

• Invoice/settlement report calculation

• Invoice/settlement report generation

The service provider defines a frequency and specifies the dates for the processes to be activatedAvailable frequencies: daily, weekly, bi-weekly, monthly, bi-monthly, quarterly, semi-annual, annual

Synchronized • Invoice/settlement report generation

Invoice/settlement report generation is activated at the same time as invoice/settlement report calculation



Isolated Invoices

An isolated invoice is an invoice that aggregates one or more transactions selected by the user.

Transactions that are already included in an isolated invoice cannot be used in regular invoices. Refer to Restrictions about Isolated Invoices later in this chapter.

A regular invoice is different from an isolated invoice in that the regular invoice calculation is based on all transactions (*) that are created during a given period while the isolated invoice calculation is based on the transactions selected by the user.

(*): Except the transactions that are already included in an isolated invoice.

Regular invoices are created manually or from a billing cycle.

Restrictions aboutIsolated Invoices

In Highdeal Transactive, isolated invoices are subject to restrictions:

A transaction that is included in an existing invoice cannot be included in a new isolated invoice

A transaction that is included in an isolated invoice cannot be used to calculate a regular invoice

Transactions relating to invoice discounts cannot be included in an isolated invoice

Corrected transactions cannot be included in an isolated invoice

The creation date of an isolated invoice cannot be earlier than the creation date of the last regular or isolated invoice

Modifying or deleting an isolated invoice is allowed only if no regular invoice is created after the isolated invoice

An isolated invoice that is closed cannot be deleted, updated or modified

Calculating anIsolated Invoice

Calculating an isolated invoice consists in:

Adding transactions to the isolated invoice and removing transactions if necessary

Making the calculation from the transactions included in the isolated invoice



Steps The main steps to calculate an isolated invoice are the following:

1 Open an existing account.

2 From the menu bar in the main window, select Action > Calculate Isolated Invoice. The Calculate Isolated Invoice window opens.

Calculate Isolated Invoice window

3 Click the icon to select transactions. The Calculate Isolated Invoice window opens.

Icon to select transactions



Select Transactions window

4 Set up the criteria to search for transactions.

5 Click the icon to search for transactions, and then select the transactions to be added to the isolated invoice.

6 Click OK to validate and go back to the Calculate Isolated Invoice window.

7 In the Calculate Isolated Invoice window, select the date on which the isolated invoice is calculated, and then click OK to calculate the isolated invoice.

Modifying an ExistingIsolated Invoice

Modifying an existing isolated invoice consists in:

Adding transactions to or removing transactions from the isolated invoice

Recalculating the isolated invoice

Icon to search for transactions



Steps The main steps to modify an existing isolated invoice are the following:

1 Open an existing account.

2 From the menu bar in the main window, select Action > Modify Isolated Invoice. The Modify Isolated Invoice window opens.

Modify Isolated Invoice window

3 Select the isolated invoice to be modified.

4 Click OK to modify the isolated invoice. The Modified Isolated Invoice windows opens.



Modified Isolated Invoice window

5 Add or remove transactions by clicking the appropriate icon.

6 Click OK to modify the isolated invoice.

7 Because the isolated invoice has been modified, it must be recalculated. Refer to the chapter Calculating an Isolated Invoice.

Icon to add transactions

Icon to remove transactions



Taxes

Highdeal Transactive is flexible with respect to tax calculation. In the case of a European tax system, calculation can be carried out directly by Highdeal Transactive. In the case of an American tax system, calculation can be carried out by other kinds of software such as EZ Tax® by BillSoft® (for this system, Highdeal can provide the relevant rated connector). This section presents a brief overview of both options.

Choosing a System You choose only one tax system: It is not possible to use several systems at the same time. Highdeal Transactive is configured during installation to function according to the system you specify.

External Calculation If tax calculation is external, Highdeal Transactive functions in relation to a given software, to which it provides all the necessary data to be calculated. The appearance of the GUI (that is, the appearance of data presented in certain screens) varies depending on the software you choose.

Internal Calculation If tax calculation takes place within the Highdeal Transactive environment, Transactive calculates the taxes to be applied to the consumption of services. It then integrates the taxes into corresponding invoices/settlement reports, in accordance with European recommendations. Taxes using the VAT framework can be calculated at two places:

Prepaid accounts: Taxes are calculated each time a transaction is generated, and the account balance is decreased based on the amount including taxes.

Postpaid accounts: Taxes are calculated on each group of transactions which have the same tax code at invoice/settlement report creation, to avoid rounding errors.

There are three main concepts related to carrying out this calculation and preparing the invoices/settlement reports:

Tax rate

Tax code

Tax type

Tax Rate The tax rate varies according to the products consumed. In Price and Rate, the GUI permits you to choose the tax rate for each charge used in an offer. Eight options are available, including six rate values (ranging from “normal” to zero rate value) and the “no tax” option. Therefore, the transaction generated at the end of rating contains the calculated price of the consumption as well as the tax rate to be applied.



If the value of the tax rate is modified, the various rates and corresponding validity dates are retained through a system of chronology. The applied value is the one which is in effect at the consumption date

Tax Code The tax code is an account characteristic. It corresponds to:

The country code

The type (individual or company) of the two account owner parties

The tax code can be chosen manually in the GUI or determined automatically by Bill, Settle and Report using the account owner party characteristics.

Tax Type The tax type defines the liability mode for the tax. This, in turn, determines invoice/settlement report presentation with regard to tax amounts and included taxes. This is an account characteristic that you choose in the GUI and that has four possible options. It is useful during invoice/settlement report preparation.

Tax Calculation The calculation of the tax which is applied to a given consumption activity can be summarized in the following way:

1 Based on a ticket issued from a consumption activity, the Price and Rate module creates a transaction that contains the consumption price and the tax rate to apply.

2 The account to be charged is identified, and the tax code is extracted from this account.

3 The Bill, Settle and Report module calculates the tax amount based on the tax rate, tax code, and consumption date, and then updates this information in the database.

When assigning charges to an offer, you can designate the tax level, which is dependent on the value of the rating context. You can tax at the value taken from a translation table (for example, parameters or user properties).



Discounts

To keep your customers fully satisfied, you may want to offer them one-shot or regular discounts. Bill, Settle and Report provides several types of discount: invoice/settlement report discounts, Rebates and one-shot discounts. You can define discounts for one or more accounts.

A discount on a settlement report decreases the amount of the settlement report. This corresponds to a discount for the benefit of the service provider.

Invoice/SettlementReport Discounts

An invoice/settlement report discount generates one or several new transactions that contain a negative discounted amount. This amount is calculated from other transactions that belong to the same billing and settlement period.

This discount represents a reduction in the overall invoice/settlement report total and is applied to one or more invoices/settlement reports issued during a specified time period. The resulting transactions are taken into account in the current invoice/settlement report.

Invoice/SettlementReport DiscountCharacteristics

An invoice/settlement report discount has the following characteristics:

It is associated with a specified account

It is calculated at the time of invoice/settlement report calculation

It applies only to transactions in the concerned account

It is defined using discount rules and transaction filters

Discount Rules A discount rule consists of a percentage that is applied to any amount that equals or exceeds a certain threshold value.

Applying Invoice/Settlement Report

Discounts

Invoice/settlement report discounts are applied, based on the following:

Number of invoice/settlement reports (fixed beforehand): The discount applies to a defined number of invoice/settlement reports, starting on a specified date.

Time period: the discount applies to all invoice/settlement reports created over a specified time period.



For an invoice/settlement report that is subject to this type of discount, other authorized discounts (one-shot and rebates) are not taken into consideration.

Suspending/Reapplying Invoice/

Settlement ReportDiscounts

You can temporarily suspend and reapply invoice/settlement report discounts.

One-Shot Discount A One-Shot Discount generates one or several discount-type transactions of a negative amount. Such transactions are generated based on a percentage of the total amount. This percentage is applied to a set of selected transactions.

For example, you may want to offer a one-shot discount to a customer who is not satisfied with a service for which they have already received an invoice or settlement report, as in the case of a delivery problem.

Rebate Like a one-shot discount a rebate also generates one or several transactions of a negative amount. However, instead of basing this discount on a percentage, it is based on a fixed amount.

For example, a rebate could be an amount of $50 to be deducted from the next available invoice/settlement report.

Issue of One-ShotDiscounts and

Rebates

One-shot discounts and rebates are negative transactions that are taken into account in the next created invoice/settlement report.

Bill, Settle and ReportDiscount

Characteristics

This table summarizes the types and characteristics of the different discounts available in Bill, Settle and Report:

Discount Types and Characteristics

Discount type Application Calculation Selection method Selection period

Invoice/Settlement Report Discount

RecurringDiscount rules (percentage and threshold)

Transaction filter Billing/settlement period

One-Shot Discounts Once Specified

percentage Transaction filter Entire period

Rebate Once Fixed amount Not applicable Not applicable



Invoice/Settlement Report Discount Example

In a meeting with their customer Sopreto on August 20, Fedex agrees to grant a discount of 10%. This discount applies to all invoices/settlement reports over $150, from September 1 until October 15.

To apply this discount, Fedex must create:

A discount template, with a rule defining a $150 threshold and a percentage of 10% to be applied (see the illustration of the Discount Template window below)

The invoice/settlement report discount, to be included in the Sopreto -Fedex Account, in which the period of the discount is defined (see the illustration of the Sopreta-Fedex Account window later in this section).

Fedex Party window

Fedex Party



Discount Template window

Sopreto-Fedex Account window, Invoice/Settlement Report Discount tab

Discount Rule

Sopreto - Fedex

Account

Discount on Sopreto Invoice



AML Reports

You can create an AML report and quickly view the result in text or HTML. Once you have viewed the report, you can save the AML results file to disk or close the window.

To create an AML report, this functionality can use information related to any postpaid or prepaid transactions stored in the Billing database.

Once you have opened the Execute AML Report window, you can fill in the Basic context tab, and then the Advanced context tab if necessary.

Execute AML Report window

Parameter settings On the Basic context tab, you type the service provider associated with the report in the Vendor field and the account holder associated with the report in the Buyer field. In the fields From Date and To Date, you select the start date and the end date of the report time period. The Report filename field provides you with the list of default report templates, which are the following:

accountsReport.aml: Displays all the accounts for a vendor

grossSalesReport.aml: Displays the revenue that is produced by an offer

subscriptionsReport.aml: Displays all the subscriptions for a vendor

If your administrator has created a specific report template for a vendor, it appears in this list instead of the default templates. For more information, ask your administrator.



On the Advanced context tab, you can select other criteria based on the following:

Detailed information specific to the parties linked to the AML report that you want to update

Information that is characteristic of their hierarchy

The default output format of the report is text only; however, you can select the HTML output box to view the report in HTML.

Viewing an AMLreport

In the Execute AML Report window, click the Execute button to execute the AML report. When the AML report is displayed, click Save and close if you want to save it to a file.

HTML report for the Patterton vendor



Correcting Transactions

When the Highdeal Transactive system is running, certain irregularities may appear in pricing as well as in billing and settlement. These irregularities generally arise from incorrect modifications in the system and thus require correction. Transactive allows you to correct these irregularities manually.

Manual correction This method allows you to correct one transaction or a few transactions at a time. You can correct transactions not yet billed, or transactions charged in the last invoice or settlement report (as long as it is not closed). A correction generates a new transaction with details identical to the original, except that the transaction amount is the corrected amount.

Correction types There are three different ways in which you can correct a transaction:

Absolute adjustment: A fixed amount is added to or subtracted from the transaction amount to be corrected

Relative adjustment: A percentage is added to or subtracted from the transaction amount to be corrected

Cancellation: An amount equal to the entire amount of the transaction is subtracted from the transaction amount to be corrected

Correction methods When you correct a transaction, a new transaction is issued with the corrected amount. You can choose either to merge the old and new transactions or allow both to coexist in the database.

When transactions are merged, incorrect transactions are deleted from the database and replaced by transactions created by the correction process.



Rerating Subscriptions

You may need to rerate:

When you have made a change to an offer, subscription, pricing macro or translation table. For example, you made a change to a translation table that requires to modify all the subscriptions containing the translation table.

When transactions were created before a change was made. You can select transactions depending on your criteria, and then rerate the related subscriptions from a specified date.

When pricing errors can lead to erroneous rating calculations. This situation can arise from an incorrect price plan, incorrect content in translation tables, incorrect use of translation tables or pricing macros, and so on. This results in incorrect transactions stored in the Transactive database.

For more information, refer to the chapter Rerating.

Example ofCorrection Process

(Invoice Error)

During the verification of the last Invoices created for the month of September, the operator Telcoserv discovers an irregularity in John Woods’ invoice. This customer has a telephone plan with 2 hours of call time per month but the amount of his last bill was based on a 1-hour plan.

The total duration of his telephone calls for September came to 2 hours 10 minutes. Therefore, this customer would be expected to pay for 70 minutes of call time. This is an error, because with a 2-hour plan, he should only pay for 10 minutes. John Woods has used this plan for several months and this error has never occurred before.

The correction process is as follows:

1 The operator identifies the amount that is wrong.

2 John Woods subscribes to the Mobile Telephone Offer. In this plan, the duration is a parameter chosen by the customer and written into his subscription. Database observation provides the following information:

a. In John Woods’ subscription, the parameter value is wrong: It is one hour instead of two hours.

b. After searching in the Audit process data, a modification of John Woods’ subscription is displayed. It took place on September 5.

c. A search in the customer records clears up the error. Another customer named Joan Woods had asked for a change in her



plan, to limit it to 1 hour. This change was made by mistake in John Woods’ subscription on September 5.

d. Two subscriptions are therefore incorrect as of September 5. One field is involved in the two objects: the “plan duration” parameter value.

3 As of September 5, the system should have contained the following values:

4 The selection rules for subscription to be rerated are as follows:

5 To correct the system you must complete the two following actions:

6 The rerating process must be launched two times in succession: The first time to rerate John Woods’ consumptionThe second time to rerate Joan Woods’ consumption

Object Field

John Woods subscription “Plan duration” parameter: 2 hours

Joan Woods subscription “Plan duration” parameter: 1 hour

Main criteria Start date

John Woods subscription identifier September 5, 2002

Joan Woods subscription identifier September 5, 2002

Actions Where

Change the parameter value: enter the correct value (2 hours) as of September 5, 2002

John Woods subscription

Change the parameter value: enter the correct value (1 hour) as of September 5, 2002

Joan Woods subscription



To be sure that the rerating process functions successfully and runs smoothly, it is recommended that you keep in mind the following constraints and tips:

A subscription is of type online, offline or both. Only subscriptions of type offline are rated by BART.

Rerating an online subscription is not possible.

The best way to rerate subscriptions with a transaction search filter is not to filter transaction details.

You must use the rerating operation before sending your last invoice or settlement report.

Because the rerating operation can modify transaction amounts, Transactive automatically recalculates the last invoice or settlement report if necessary.

When subscriptions are being rerated, a progress bar in the confirmation dialogue box displays the progress of the rerating.

Rerating a large number of subscriptions can take a long time.

If the rerating of a subscription fails, a server log is written but the rerating continues.



Managing Disputes

Disputes Overview Occasionally, customers may dispute invoice amounts due from them. With Highdeal Transactive, you can manage customer disputes in the following ways:

Keep a dated and detailed history of the dispute

Track the status of the dispute, such as open or closed

Track the reasons related to the dispute

Track the amount in dispute

Choose whether to exclude the amount from collections processing while the dispute is ongoing

Create an action list that a Customer Service Representative (CSR) can take to resolve the dispute

Add memos

A dispute is always linked to an invoice by means of an invoice reference or operation ID.

The dispute feature of Highdeal Transactive is only available as part of the Web Customer Care tool.

Disputes View You can view a list of all disputes for a selected customer account or invoice on the Disputes tab of the Web Customer Care User Interface. You need to open an invoice to create a dispute related to this invoice.

Each disputed Invoice contains a drop-down list of actions to help resolve the dispute. These actions can be performed or triggered at any time.



Dispute File When a customer complains about an invoice, a dispute file is opened and managed. This dispute file contains detailed information such as:

The reason of the dispute

The action plan associated to the dispute

The disputed amount

The status of the dispute

The state of the dispute

A summary of the dispute management

Various dates related to the dispute

Every dispute file can be associated to a set of dispute memos containing additional information about the dispute history such as :

The type of dispute memo

The identifier of the user who created the dispute memo

The code of the action performed during the dispute

The state of the performed action

Each open dispute concerns a specified single invoice and contains a disputed amount which is ignored by the collection process if an unpaid call for payment exists for the related invoice.

Dispute Memo A dispute memo enables you to record optional extra information related to a dispute into a dispute file such as:

Description of the dispute at dispute file creation

Reason for closing a dispute

Actions to follow up a dispute

You can create several dispute memos for a dispute file. The most recent memo appears at the top of the dispute memo list.

Disputes: BulkOperations

You can use a bulk operation to perform the following:

Delete a set of disputes

Select a set of account holders and delete their related disputes.

Disputes BulkOperation Example

An Administrator wants to purge her database of disputes that have been settled more than three months ago. She archives this information using her archiving tool, and then chooses Bulk Operations>Delete Disputes from the



Tools menu of the Highdeal Transactive Desktop Tool. She selects the disputes that are closed and those where the last modification date was more than three months ago. These disputes are then removed from the database.


Chapter 5

Accounts Receivable &Payable Concepts

This chapter presents the concepts and functions in Highdeal Transactive that let you manage your Accounts Receivable and Accounts Payable.

Please note that this chapter is useful only if you have the Accounts Receivable and Payable module installed.


Section Page

Accounts Receivable and Payable Module 213

Payment Processing 219

Aging Reports 233

Collections and Dunning 243


Accounts Receivable & Payable ConceptsChapter 5



Accounts Receivable and Payable Module

The Accounts Receivable and Payable (ARP) module contains the Accounts Receivable (A/R) and Accounts Payable (A/P) features in Highdeal Transactive. This module provides a solution for customers who prefer to have these functions integrated with their billing and settlement operations rather than relying on an external accounting package.

‘”ARP” is the acronym for “Accounts Receivable and Payable.” These two terms are used interchangeably throughout this document. The same is true for the use of “A/R” for “Accounts Receivable” and “A/P” for “Accounts Payable.”

In this Chapter This chapter describes and illustrates information you need in order to manage your Accounts Receivable and Accounts Payable. The information is presented as follows:

1 Accounts Receivable and Payable (ARP) module Accounts Receivable and Accounts Payable in Highdeal TransactiveGetting acquainted with the ARP module

2 Payment processingPayment processing overviewCall for payment managementPayment information and service provider payment settingsPayment terms managementPayment entryPayment reconciliation

3 Aging reportsAging reports overview Aging report configurationAging steps

4 Collections and dunningCollections and dunning overviewDunning plansCollection filesWriting off bad debt



Accounts Receivable and Accounts Payable in Highdeal Transactive

This section describes Accounts Receivable and Accounts Payable with respect to Highdeal Transactive.

Accounts Receivable Accounts Receivable (A/R) involves the following:

Keeping track of balance due to the service provider

Managing and reporting outstanding balances on invoices

Receiving and processing payments from account holders

Managing collection files and related dunning steps

Managing customer scoring for categorization purposes

Accounts Payable Accounts Payable (A/P) involves the following:

Managing payments, such as commissions, that are due to third parties (such as content supplier or reseller partners) who have been modeled in Highdeal Transactive (see the note below)

Managing and reporting outstanding balances on settlement reports to partners

Making and processing payments

The Accounts Payable features in Highdeal Transactive are designed solely for managing Accounts Payable for parties modeled in Transactive as part of the Transaction Network. The entry into the Transactive system of arbitrary supplier invoices/settlement reports (for example, for office supplies) is not supported. The service provider who is using Highdeal Transactive needs to have a separate Accounts Payable system for managing payment to other suppliers.

Common Features ofA/R and A/P

Although Accounts Receivable and Accounts Payable consist of different processes because A/R deals with invoices and A/P with settlement



reports, they share most features, including:

Payment processing (invoice/settlement reports)

Payment terms management, such as specifying due dates for invoices in A/R or for settlement reports in A/P

The use of aging reports to view how late the payments are that are being received in A/R (invoices) or paid in A/P (settlement reports)



Getting Acquainted with the ARP Module

Role of ARP Module The Bill, Settle and Report module manages billing and invoicing for customers and settlement reports for partners. The Accounts Receivable and Payable module then manages the accounting processes that follow, including payments.

Please note that the ARP module works only in conjunction with the Bill, Settle and Report module. The Bill, Settle and Report module can work alone or with the ARP module.

ARP ModuleInterfaces

The interfaces for the ARP module are partly Web-based; however, some tasks are carried out in tabs of the account and party windows (Bill, Settle and Report module).

AccountsReceivable and

Accounts Payable

Accounts Receivable and Accounts Payable are accounts created in Bill, Settle and Report with the added attribute “receivable” or “payable,” respectively. They are not managed seperately, and this implies the following:

Invoice and settlement reports are created with the same numbering pool.

The default cycle defined by the service provider is the same for Accounts Receivable and Accounts Payable. This means that when a new A/R or A/P is created, the same cycle is set by default.

Example: As default settings, a service provider defines a monthly cycle with an AML template that corresponds to an invoice. If the user creates an Account Payable without modifying the default settings, the settlement report is generated with an invoice template. For this reason, the user must manually modify the AML template for Accounts Payable.

When an invoice/settlement report is generated, the information that the service provider wants to send to an account holder is retrieved and integrated in an XML file. In Bill, Settle and Report, this XML file is based on an invoice template (AML template) predefined by the service provider.



ARP User Roles For security reasons, it is necessary to define certain roles for users in order to manage various aspects of the ARP module. These roles are described below.

International Use ofA/R and A/P

Processes

The Accounts Receivable and Accounts Payable processes are basicallythe same wherever you are in the world. However, some elements thatmay differ from one country to another can be handled by configuring theARP module and by customizing the Web user interfaces. The table belowlists elements that may be different.

ARP User Roles

Role Description

Financial Administrator The user with this role is authorized to:• View aging reports• View certain account information• Register payments

Account Manager The user with this role is authorized to manage:• Payment settings• Payment information• Calls for Payment• Dunning settings

Collections Manager The user with this role is authorized to manage collection files.

Elements of A/R and A/P that may differ from country to country

Element Description and how to handle the difference

Payment Terms Different countries have different norms for payment terms. For example, Net 30 is the norm in the US, while variations between Net 30 and Net 90 are the norm throughout Europe, and in Italy it can be as high as Net 180 for some industries. To deal with this need, payment terms are fully configurable.

Payment Methods Different countries use different payment methods. For example, payment of bills in cash at local points-of-sale is very common in some countries. To deal with this need, payment methods at the level of the Web UI are configurable and are not hard-coded in the core product.

Localization and Internationalization of UI

Customizing user interfaces for different locales is managed in the Web framework



Payment Processing

Invoices and settlement reports are produced in the Bill, Settle and Report module. You can then use the payment processing feature of the ARP module to manage the payment and invoice/settlement report follow-up processes.

This section presents the payment processing feature as follows:

Payment Processing Overview

Call for Payment Management

Payment Information and Service Provider Payment Settings

Payment Terms Management

Payment Entry

Payment Reconciliation



Payment Processing Overview

The payment processing feature is an extension of payment entry as an Account operation, which can be performed in Bill, Settle and Report.

Using the payment processing feature, Highdeal Transactive allows you to manage:

Payments

Calls for payment

Call for Payment A call for payment is a record linked to the account operation of an invoice/settlement report. It tracks and updates payments and payment-related dates until complete payment.

You can enter payments, and do the following:

Modify due dates in a call for payment

Apply the payment across overdue invoices/settlement reports

Register the payment as an advance payment

You can manage payment settings for accounts by:

Configuring the call for payment, such as modifying the amount due or the payment collection date

Defining how a call for payment is generated

Payment ProcessingTerminology

The following table presents terms used in payment processing and a brief definition of each term.

Payment Processing Terms and Definitions

Term Definition

Invoice/settlement report date Date on which the invoice/settlement report is calculated.

Delay before call for payment

Delay (period of time) after the calculation date but before the call for payment is created. This serves as the time that the user can have to modify the invoice/settlement report.

Call for paymentRecord that is associated with an invoice/settlement report. It is present during the complete payment process for the invoice/settlement report.

Call for payment date

Date that the call for payment is created. This date begins the time period that lasts until the payment due date.



A Look at PaymentProcessing

The following diagram illustrates the principal steps involved in payment processing.

Payment processing

Days until payment due

Period of time after the creation of the call for payment but before the payment is due.

Payment due date Deadline for paying the invoice/settlement report. This is at the end of the “days until payment due” period.

Collection grace period

Grace period after the “payment due date” but before starting the collection process.

Payment collection date

Date after which the service provider will try to recover the overdue amount.

Net payment termsTerms which specify the time period in which payment is required. (Please see the section titled ‘Net Payment Terms’ for more information.)

Payment reconciliation

Payment reconciliation involves assigning a payment to an invoice/settlement report and adjusting an account balance to reflect transactions that have occurred since the reporting date.This can be compared to checking your bank statement against your own records.

Payment Processing Terms and Definitions

Term Definition

Invoicecalculation

date

Call for payment

date

Paymentdue date




Invoice calculation

date

Paymentcollection

date



Call for Payment Management

Call for PaymentFeatures

For each new calculated invoice/settlement report, the service provider can create and configure the call for payment. The call for payment includes the following:

Call for payment date, payment due date, and payment collection date

Amount due and/or remaining due

Type of call for payment, such as:

Payment from client

Payment to partner

Refund to client

Refund from partner

State of the payment – paid, partially paid, in dispute or in dunning

Status – active, locked or closed

Other information that is useful for the invoice/settlement report follow-up

The creation of a call for payment changes the related account operation status to “closed” to prevent recalculation of invoices/settlement reports. That is, once the call for payment is made, the invoice/settlement report is closed in Bill, Settle and Report. When this happens, no transaction from the corresponding invoice/settlement report can be modified after this point.

You can modify a call for payment but you cannot delete it. The only way to delete a call for payment is to delete the related account.



Call for PaymentGeneration

An Administrator can define how a call for payment is generated by modifying the following settings in the config file of Highdeal Transactive:

If you select either the Synchronized or Scheduled setting, the generation of collection files is synchonized with the generation of calls for payment.

Rescheduling a Callfor Payment

After an invoice has been created in the Bill, Settle & Report module, the invoice is sent to the Transactive ARP module when the delay before call for payment has expired. A call for payment is then created in Transactive ARP. See the illustration below:

Payment Processing

When a customer does not pay an invoice at the payment collection date, the invoice is turned into a debt that is placed for collection; however, the vendor can propose to the customer a new call for payment schedule to discharge the debt to which interest on arrears can be added (see the note later in this section). Interest on arrears is taken into account only on customer's next invoice. The vendor can delete a call for payment schedule at any time.

If set to then

Manual The call for payment is generated upon service provider demand, through the GUI.

Synchronized The call for payment is automatically generated in synchronization with invoice/settlement report calculation.

Scheduled

The Calls for Payment are generated periodically and automatically by the ARP scheduler, according to the “delay before Calls for Payment” setting (defined in payment information related to the Account).

Invoicecalculation

date

Call for payment

date

Paymentdue date

Paymentcollection

date




Invoice calculation

date



The rescheduling of the debt allows the vendor to split up the call for payment into new calls for payment called commitments. Every commitment is initialized with a new payment collection date and a new amount. The total amount of commitments is equal to the debt amount of the original call for payment. Besides, commitments refer to the same invoice than the original call for payment. Contrary to calls for payment, commitments can no longer be rescheduled.

When the payment collection date has expired, unpaid commitments are submitted to the collection process.

Interest on arrears is charged to the next invoice instead of being charged to the current one. Interest on arrears is calculated from a specific charge included in an offer. This charge is activated when a ticket is sent to the engine rating of Transactive. After the charge has been activated, a transaction including interest on arrears is generated through the rating engine, and then the transaction is stored into the Bill, Settle & Report module. This transaction is taken into account on the next invoice. The implementation of interest on arrears is made by your administrator. For more information, refer to your administrator.



Payment Information and Service Provider Payment Settings

When you create an account in Bill, Settle and Report, the ARP module is notified, and it creates the related payment information with default service provider payment settings.The payment processing feature allows management of:

Payment information

Payment settings for each service provider

For example, the call for payment date, payment due date, and payment collection date are calculated according to payment information.

PersonalizingPayment Settings

The service provider, however, can personalize payment settings that have been specified as default settings. For example, the vendor can define new payment terms or select default terms, and specify a list of authorized payment methods.

Bulk Operations Bulk operations are also available for modifying account payment information, but only at the API level.



Payment Terms Management

Net Payment Terms Net payment terms specify the time period in which payment is required.

Each Invoice/settlement report in the system can have payment terms associated with it. Payment terms allow you to do the following:

Specify the due dates for:

Invoices for Accounts Receivable

Settlement reports for Accounts Payable

Manage settings, including:



Days until payment due and end of month flag (EOM)


Payment terms are explained in more detail in the following section.

Overview of NetPayment Terms

Net payment terms are requests for payment within a specified time period. Late fees may be applied after this period has passed.

Net payment terms are based on “Net” and “Net EOM” concepts, as defined below:

Net Payment is due immediately upon receipt of the invoice/settlement report.

Net EOM Payment is due by the end of the month of invoice/settlement report dateFor example: If the invoice/settlement report date is March 10th, then payment is due on March 31st



The following table presents examples of Net terms that the Highdeal Transactive system handles.

Defining Net PaymentTerms

By default, when you define a new service provider, you should include at least one standard payment term, such as “Net 30.” Each payment term should have a meaningful name to identify it.

When setting up an account between an account holder and service pro-vider, a list of names of payment terms is presented. The default payment term specified in the service provider payment settings is automatically selected.

However, you have the option of choosing one of the other proposed pay-ment terms, or defining new values for the payment terms.

Default Net PaymentTerms

With respect to managing Net payment terms, you can select from default payment terms such as Net 30, Net 90, and Net EOM 10 for each service provider in the system and ultimately, for each account.

There are eight default payment terms that are available per service pro-vider in the system. These default payment terms can be used for each account and can only be redefined in the system configuration file. The eight default payment terms are as follows:

Examples of Net terms

If the term is then the payment is due

Net 10 Within 10 days from the date of the invoice/settlement report.For example, if the invoice/settlement report date is March 10th, then the payment is due on March 20th.

Net 30 Within 30 days from the date of the invoice/settlement report. For example, if the invoice/settlement report date is March 10th, then the invoice/settlement report is due on April 9th.

Net EOM 10 On the 10th of the month after the end of the month of the invoice/settlement report date. For example, if the invoice/settlement report date is March 10th, then the payment due on April 10th.

Net 10 Net EOM 10

Net 30 Net EOM 30

Net 60 Net EOM 60

Net 90 Net EOM 90



If you need a payment term other than one of the default terms, you can do one of the following:

Create your own payment term to use instead of one of the default terms

Modify the default list of terms by updating the server configuration file



Payment Entry

Entering andApplying Payments

Customer Sales Representatives (CSRs) or other staff can manually enter payments received from customers. The system recognizes that multiple invoices/settlement reports may be open and that the payment may need to be split across multiple invoices/settlement reports.

In addition, the system can manage partial payments and advance pay-ments in the following ways:

Payments may be received that only partially pay off an invoice/settlement report.

Advance payments may be received that do not apply to any invoice/settlement report but will later be assigned to invoices/settlement reports.

If a bounced check is provided when making a payment entry, you can delete the payment.



Payment EntryProcess

The following procedure summarizes the steps necessary for entering payments:

1 Select the service provider or enter invoice/settlement report ID.

2 Select the account holder for which the payment is to be applied.

3 Select the payment method, such as:

4 Select the payment date.

5 Enter the amount of the payment.

6 Select the payment type. A new window opens.

7 Decide which invoice(s)/settlement report(s) to apply the payment to and/or whether to use the payment as an advance payment. Then do one of the following:

Divide the payment amount received across several different open invoices/settlement reportsChoose to apply all or part of the payment amount as an advance paymentAdd payment information (card type, reference, payment date, transaction ID, and so on)

8 Click to apply the payment as configured. The payment is immediately applied to the account balance.



Payment Reconciliation

Payment reconciliation involves assigning a payment to an invoice/settlement report. It is the process of adjusting an account balance to reflect transactions that have occurred since the reporting date.

In Highdeal Transactive, this feature consists in mapping the received payments on existing calls for payment to reflect payments that have occurred since the initial call for payment. This mapping can be partial and addresses the following:

One call for payment

Several calls for payment

No calls for payment (if the payment is an advance payment)

Payment reconciliation is done manually. By default, the GUI proposes to reconcile payments with the oldest unpaid invoice/settlement report. If you agree to this, you click to enter the payment. If you do not agree to this, you can modify the reconciliation.



Aging Reports

The aging reports feature presents aggregated and detailed views of a service provider's Accounts Receivable and Accounts Payable. More specifically, this feature provides a way for building reports, called aging reports, that allow the service provider to list the overdue payments for different periods.

This section presents the following aspects of the aging reports feature:

Aging Reports Overview

Aging Report Configuration

Aging Steps



Aging Reports Overview

Aging Aging is the process of categorizing an account by the number of days it has been outstanding. For example, in the case of Accounts Receivable, an aging report allows a service provider to locate account holders who have overdue invoices/settlement reports and to see how late they are.

Aging Report An aging report is an aggregation of various data contained in the Accounts Receivable and Payable module. To create an aging report, you select an aging report template and the service provider. The template selects the parties (using the Find a Party filter window), chooses criteria to aggregate, and decides on several aging steps.

Differences in A/Rand A/P Aging

Reports

The following table presents differences between aging reports for Accounts Receivable and for Accounts Payable.

Otherwise, A/R and A/P aging reports are similar. For example, the type of selection criteria for defining report configurations and the overall format is basically the same for both types of report.

Differences between A/R and A/P aging reports

Accounts Receivable Accounts Payable

This aging report allows the service provider to see: • whether and by how much its

customers are behind in making payments

This aging report allows the service provider to see: • whether the service provider is

paying its partners on time or not

The reporting is on the open invoices on Accounts between: • one fixed service provider and the

service provider's Clients

The reporting is on the open settlement reports on Accounts between: • one fixed service provider and the

service provider’s Partners



Aging Report Configuration

You can create and save standard aging report configurations. Saved report configurations are available for all users of Highdeal Transactive. When selecting a report to run, you can do one of the following:

Create a new report configuration

Run one of the pre-existing report configurations

Modify one of the pre-existing report configurations

Delete an existing report configuration

Creating a New AgingReport Configuration

So that you can better understand aging reports and the various parts of the report, this section presents the elements to be selected or defined when creating a new aging report configuration. Please refer to the following illustration of a detailed aging report.

Elements to be selected or defined when creating a new detailed aging report

Name of report

Summary or Detailed report

Service provider and Effective date

Filter and Sort criteria, Zero-balance Accounts

(or not)

Aging stepsInvoice information



Aging ReportConfiguration

Process

1 Name of the report. Decide on the name of the standard report (in the text field). By default, the name contains the text “Aging Report”. The name appears at the top of the report output. If this report configuration is saved then:

The name will be used when presenting the list of pre-existing reports to runThe name needs to be unique

2 Invoice/settlement report information. Select whether to show information for overdue invoices/settlement reports only or for all invoices/settlement reports, that is, current invoices/settlement reports as well as those that are overdue. By default, information for all Invoices/settlement reports is shown.If the user selected to show all invoices/settlement reports, including those which are current, then a column called “Current” is displayed. It shows amounts that are not yet overdue.The “Total” column shows the total amount for the Accounts Receivable or Accounts Payable (current as well as overdue).

3 Effective date. Select the effective date of the report. By default this should be current date, meaning the date that this report configuration is run. However, the user can select any other fixed date in the past or the future. This allows the user to see what the aged balance would hypothetically be on the date given the current open invoices/settlement reports in the system.

4 Aging steps. Select the aging steps. Aging steps are shown as columns on the report. (See “Aging Steps” section for more information about configuring Aging steps and about default Aging steps.)

5 Report type. Select postpaid receivable Accounts or postpaid payable Accounts.

6 Zero-balance Accounts. Select whether to include accounts with zero balances. By default, Accounts with zero balances are not shown on the report.

7 Filter criteria. Select accounts using a party search filter on the account holder.

8 Sort criteria. Select up to three sort criteria for the report. The possible sorting criteria are as follows. All are in alphanumeric ascending order except where noted:

Party Organization NameStateCityCountry

Please note that at least one sort criterion must be selected.



9 Summary or Detailed report. Select whether to show a Summary Report or a Detailed Report. The default is a Detailed Report. (See the section “Summary and Detailed Aging Reports” for an explanation of these two types of reports)

Detailed andSummary Aging

Reports

You can select one of two types of aging report – “Detailed” or “Summary.” The “Detailed” type report is the default and is shown in the previous illustration. Both types are described in the following table.

Invoice, Account, andAccount Set Lines

In addition to the aging report elements described in the above sections, it is important to understand the following elements:

Invoice/settlement report lines

Account lines

Account set lines

Please note that in this section the aging report elements are described with respect to Accounts Receivable (invoices). However, the same configuration applies to aging reports for Accounts Payable (settlement reports).

Types of aging reports

Type Description

DetailedThe Detailed aging report shows one line per invoice/settlement report, grouped and sorted according to the specified sort criteria.

Summary

The Summary Aging Report aggregates the total balance due within each of the defined sort criteria ranges. For example, if the report is configured to sort based on country and state, then the report will contain sections for each country. Within those sections, with one line per state containing the total, there are the current and aged balances due for that country and that state.



The following table presents a description of invoice/settlement report lines, account lines, and account set lines in an aging report:

To better visualize invoice/settlement report lines, account lines, and account set lines, see the following illustration of an Accounts Receivable aging report.

Aging Report Elements: Invoice/settlement report, Account, and Account Set Lines

Element Description

Invoice/settlement report line

The invoice line contains the following:• Invoice/settlement report ID• Invoice/settlement report date• Invoice/settlement report due date• Invoice/settlement report amount (“Total” column)• Amounts not yet overdue (“Current” column)--this is only in

the Detailed-type Aging Report **• Remaining amount to pay (in the appropriate aging step

column)**Note: A Detailed Aging Report contains all the invoices/settlement reports and amounts due for each account – overdue amounts as well as amounts not yet overdue.

Account line

The Account line contains the following:• Account ID• Customer (account holder) name• Total amount (for the account)• Total remaining amount to pay for each aging step period

Account set line

The account set line is an aggregation of account lines according to sorting criteria. For each aging step, it presents the sum of the remaining amount(s) to be paid on the accounts.



Accounts Receivable aging report - Invoice, account, and account set lines

Running, Modifying,and Deleting a Report

Configuration

Once the report is available in the server, you can run the report. After the report is run and the results are displayed, you can do one of the following:

Save this report for future use (in HTML or CSV). If you have opened an existing report configuration for modification and changed the report name, then it is saved as a new report configuration.

Quit the report.

In the aging report, links are provided on account holder ID and invoice/settlement report ID fields. These link to detailed information on that account, and call for payment. In the above illustration, these links are blue and underlined.

Storing Aging ReportConfigurations

The service provider can store and manage different aging report configurations. This allows the service provider to store different configurations in their catalogue for reuse.

Storing AgingReports

The generated aging reports can be stored in HTML or CSV format. This allows the service provider to consult aging report results without having to regenerate the reports.

Invoice line

Account line

Account line

Account set line



Viewing AgingReports

The Financial Administrator can view the generated results in order to access overdrawn Accounts and can view the Account history.

Aging report results are based on XML-compliant formats (XML and HTML).



Aging Steps

Aging Steps You can run a set of aging reports using configurable aging steps (for example, “current,” 30, 60, 90, 90+). The reports have default aging steps but they can be changed and customized.

The number of aging steps is limited to 10. Thus, you can define up to 10 additional aging steps per installation of Highdeal Transactive.

Default Aging Steps Default aging steps are defined as follows and are available for all aging reports:

Aging StepsCharacteristics and

Rules

Aging steps have certain characteristics and rules:

An aging step definition must split the days from zero to infinity into a variable number of steps. You cannot create either overlapping steps or gaps between steps. The first (lowest) step must always contain zero and the last (highest) step must refer to infinity.

You can give a meaningful name to each aging step definition.

As an option, you can designate one of the defined aging steps as the default aging step for the system. aging reports will then offer the name of this default aging step when running aging reports. Otherwise, the user may select one of the other defined aging steps.

Default Aging Steps

The step is defined as

30 0 - 30 days

60 1 - 60 days

90 1 - 90 days

90+ 90 days or more



Collections and Dunning

The collections and dunning feature provides you with a process for recovering overdue payments or for writing off overdue payments as bad debt.

This section presents the following aspects of the collections and dunning feature:

Collections and Dunning Overview

Dunning Plans

Collection Process

Writing Off Bad Debt



Collections and Dunning Overview

Collections andDunning

Collections and dunning is the process of collecting payments which have not been made by the due date. A service provider can take an escalating series of actions from gentle reminder letters to restriction of service. These actions are called Dunning steps and are carried out according to a predefined Dunning plan.

Highdeal Transactive does not carry out the actions involved with recovering the overdue amount from a customer, such as sending the letters or generating the email. These actions can be performed by an external system integrated with Highdeal Transactive, such as the Connector Framework and Toolset which features open APIs.

Collections andDunning Process

1 A service provider sets a predefined dunning plan to apply to a customer in case a payment does not arrive by the due date.

2 If no payment arrives from the customer, a collection file is created and the dunning plan is applied using a dunning rule. The first dunning step is initiated by the Collections Manager.

3 If no payment continues to arrive, the Collections Manager ensures each dunning step of the dunning plan is carried out on the required date to recover the overdue amount.

4 When the last dunning step has been reached and the overdue amount exceeds the maximum (escalation) threshold, the service provider can either:

Transfer the customer’s debt to another dunning plan at a higher level, or

Write off the collection file or call for payment as bad debt



Dunning Plans

Dunning Plan A dunning plan is a plan used by a service provider to recover overdue payments. It consists of at least one dunning step.

Dunning Step A dunning step is one stage of a dunning plan.

A dunning step is described by a dunning step definition, which is defined by the Administrator in an XML Dunning Settings file. A dunning step definition consists of:

Action definition: the action to be carried out by the dunning plan

Delay: the delay allowed before the action is applied

Category: the operator who performs the action

.

Conceptual view of a Dunning plan

Different categories of customer require different dunning steps, depending on the quality of their commercial relationship with the service provider

Dunning Plan

Dunning Step Definition



Action Definition

Delay Category



Delay and Actions specified in a dunning Plan

Dunning Rule A dunning rule specifies the dunning plan to be applied for an account holder, and the parameters within which it operates. For example, the quality of the commercial relationship between a service provider and an account holder can determine the type of dunning plan chosen (lenient or strict) and the threshold above which the plan will be applied.

A dunning rule consists of four elements:

Payer category: defines the quality of the commercial relationship between the service provider and the account holder to which the dunning rule will be applied

Activation threshold: defines the due amount from which the dunning rule will be applied

Escalation threshold: defines the due amount from which the current dunning rule will no longer apply and will initiate another collection file based on another dunning plan

Dunning plan reference

Dunning rules are configured in the Desktop Tool.

Dunning Settings Dunning settings are created by the Administrator in an XML file to manage a dunning plan.

Invoicecalculation

date

Call for payment

date

Paymentdue date

Paymentcollection

date

Dunningaction

Dunningaction

Delay


Collection grace period Delay Delay before

Call for Payment



For every new service provider, the following stable parameters must be manually configured by the Administrator using the dset program in the bin folder of Transactive:

Action definition

Dunning step definition

Dunning plan

Payer category

Dunning settings are configured after you create a service provider party.

Example MusicNow, a service provider, wants to manage the dunning process for its customers who have not paid their invoices on time. The commercial relationship with some customers is very important to the service provider, so a dunning plan with very easy terms will apply to them. For other customers, a strict and more efficient dunning plan will apply. Therefore, there are two categories of customer: VIP and Regular.

For VIP customers, only reminder notices will be sent in the event of late payment.

For Regular customers, a reminder notice is to be sent first by email, then a warning notice sent by express mail. After this time, the service will be cut. The debt is then referred to a collection agency.

The Administrator of MusicNow enters the following information into Highdeal Transactive:

In the Payment Information tab of the Account window, specifies the collection grace period that defines days between payment due date and the date at which the collection processing should start

In an XML dunning settings file, creates new Payer Categories (VIP, Regular) and defines the actions to be used by a dunning plan

The Administrator then defines the dunning steps of the dunning plans that will apply to these customer classes. The dunning plans are called “VIP plan” and “Regular plan.”

Once the basic dunning elements are configured, the Administrator uses the Desktop Tool to create the following dunning rules in the Dunning Rules tab of the Account window:

For “VIP” customers, apply “VIP plan” once a high activation threshold has been reached

For “Regular” customers, apply “Regular plan” once a regular activation threshold has been reached



Collection Process

Collection File A collection file is a file that is created under the following conditions:

A customer does not pay an invoice at the collection date

The overdue invoice amount is greater than the activation threshold defined in the associated dunning rule

A collection file is only created if there is no active collection file already in existence for that customer.

A collection file lists each dunning step which will be applied by the dunning plan for the customer and enables you to track each step as it is carried out. Each collection file has only one service provider and account holder.

Launching theCollection Process

Once a dunning plan is applied, you can launch the collection process, which updates the following elements of the active collection file:

Amount due

Status of non-active dunning steps at their activation date

Resolution status if all dunning steps are completed, aborted or skipped

You can launch the collection process manually through the ARP Web Interface, or by using a bulk operation or process in the Desktop Tool.

The collection process closes the collection file when:

The invoice is paid

The updated amount due is less than the activation threshold

The updated amount due is greater than the escalation threshold

The next time the collection process is launched, if the amount due exceeds the escalation threshold specified in a dunning rule, the collection process generates a new collection file with a stricter dunning plan applied to it, depending on how your process is set up.

GeneratingCollection Files with

Calls for Payment

You can generate collection files whenever calls for payment are generated. To do so, an Administrator selects either the “Synchronized” or “Scheduled” call for payment generation settings in the config file of Highdeal Transactive. See the ‘Call for Payment Generation’ section in this chapter for more details.



Collection FileWorking View

The collection file Working View is a list of the collection files on a selected account with a service provider.

You can select whether you want to see all the collection files, only the active collection files, and/or only those with dunning steps to be performed.

Using the ARP Web Interface, you can use search criteria to access this list and track the dunning steps of each collection file. The Working View does not display dunning steps which have not yet been activated.

From the collection file Working View, you can perform the following actions:

Modify the contents of collection files

Store modifications to the collection files

View the corresponding call for payment for a collection file

Example Mr Smith is a customer of the service provider, MusicNow. He is classified in the “Regular” Payer Category.

An invoice is sent to Mr Smith on April 1st with the due date April 20th. The payment information for the service provider specifies a five day collection grace period. This means payment must be received by April 25th to avoid collection processing.

MusicNow does not receive Mr Smith’s payment by April 25th. The amount due by Mr Smith is greater than the activation threshold, so according to the corresponding dunning rule, a new collection file is created based on the dunning plan called “Regular plan”. The collection file lists the following dunning steps:

Send reminder notice - to be done after April 25th

Send warning notice - to be done after May 10th

Cut the service - to be done after May 25th

Send debt to a collection agency - to be done after June 10th

On April 25th, only the first step is marked “to be done,” while the other steps are marked “not yet active.”

The Collections Manager displays the collection file Working View to see which dunning steps must be performed on that day. She sends an email to Mr Smith, reminding him of the overdue amount, and then marks the dunning step as “Done.” She decides not to add a comment regarding this step.

When the Collections Manager displays the collection file Working View on May 10, the dunning step “Send warning notice” is marked “to be done.”



She sends a warning notice to Mr Smith by express mail then marks this dunning step as “Done.”

Mr Smith pays his overdue amount on May 14, and his payment is registered in Highdeal Transactive. When the collection process is next launched, the collection file is closed and the collection file for Mr Smith is no longer displayed in the collection file Working View.

Update CollectionFiles

You can use a bulk operation (*) to select a set of accounts using the party filter and launch the collection process for those accounts. For this reason, the process of updating collection files is also referring to as “launching the collection process.” The process creates, updates or closes collection files in a set of accounts.

(*) Or a bulk process using a reference date for selecting all the accounts whose collection date is earlier than the reference date. It is possible to combine a reference date with a service provider for selecting accounts.

Example A service provider regularly receives files from German banks listing the latest payments made by their customers. These payments are then registered in Highdeal Transactive.

Once all the payments have been stored in Highdeal Transactive, the Administrator decides to launch the collection process and close any collection files for customers who have just paid. The Administrator uses the bulk operation “Update Collection Files” and selects only German customers by using the account holders filter.



Writing Off Bad Debt

Bad debt refers to an outstanding customer debt which will be borne by the service provider. In Highdeal Transactive, you can write off the outstanding debt from one invoice or from the total amount due.

Write Off Call forPayment as Bad Debt

When an event such as an accounting mistake, a lost product or customer dispute occurs, a service provider may need to write off an invoice as bad debt. The service provider can use the ARP Web User Interface to write off the call for payment which corresponds to the outstanding amount as bad debt.

This action results in the following:

Closes the call for payment and assigns the status “Bad Debt” to it.

Updates the balance by creating a credit account operation with an amount equal to the amount due.

Write Off CollectionFile as Bad Debt

Occasionally, a service provider needs to close a customer account with amounts of one or more invoices outstanding. This can occur in the case of the unexpected death or disappearance of a customer, for example.

Service providers can abandon the dunning steps for a customer by using the ARP Web User Interface to write off the customer’s entire collection file as bad debt.

This action results in the following:

Closes the collection file and assigns the status “Bad Debt” to it.

Closes all calls for payment and changes their status from “In Dunning” to “Bad Debt”.

Updates the balance by creating a credit account operation with an amount equal to the amount due.


Chapter 6

Price and Simulate -Simulation Process and

Concepts

This chapter presents an overview of the simulation process and related concepts that help you manage the simulation of your Offer.


Section Page

Simulation Overview 255

Steps in the Simulation Process 257

Simulation Concepts 259


Price and Simulate - Simulation Process and ConceptsChapter 6



Simulation Overview

Price and Simulate This module provides a simulation tool for marketing and pricing managers, forecasters, and business analysts. Equipped with an intuitive GUI, the tool allows you to develop accurate price plans by verifying price plan income and profitability profiles. Simulation is carried out with the help of either statistical functions using generic market data or real data from business activities already in operation.

Simulation The simulation produced by the Price and Simulate module

Calculates the profitability of price plans by simulating consumer usage

Predicts the contribution that a particular type of user or consumption pattern makes to the forecasted revenue

The module presents this information in the form of statistical analysis reports that are easy to read and to manipulate. These reports may also be exported via CSV files and stored locally.

Simulation Object The simulation process calculates the profitability of potential price plans based on one or more sub-component objects. This process is based on the simulation object which is the primary object in the Price and Simulate module. The simulation object contains several components and is represented in the GUI by a specific window. This window displays

All of the parameters required in the simulation

The results provided at the end of the process

SimulationComponents

In order to execute a valid simulation, you need to include at least one product, one price plan, and one customer profile (real or modeled). However, depending on the complexity of the business activity you are simulating, you can also use the other Highdeal Transactive - Simulation objects as sub-components in your simulation. For example, you use a cost entry when a payment is made to a third party (either a supplier or a commissionee) as part of the value chain of your offer.



Simulation Window The following illustration is an example of the Simulation window after you create your product and price plan from the Elements tab.

Simulation Window

Once you have defined the product, you can do the following:

1 At first, if you need pricing macros or translation tables, create them by using the Costs tab.

2 You can then add a cost entry to simulate a value chain. To do this, use thee Shared Objects tab.

3 At last, before launching your simulation, you must create customer profiles by using the the Customer Profiles tab.

This window also allows you to launch the simulation as well as view and analyze the results of the simulation. To do this, use the Control tab.

Added product

Added price plan



Steps in the Simulation Process

The simulator calculates the commercial profitability of your price plan based on either modelled consumer usage, as in the case of a modelled customer profile, or on actual usage data, as in the case of a real customer profile.

Steps in theSimulation Process

The steps for performing a simulation are as follows:

1 Define the product that represents the service you want to provide to your customers, along with each of its items, including chargeable Items and properties.

2 If necessary, include any shared objects such as pricing macros or translation tables.

3 Define the price plan for which you want to test profitability.

4 Add costs to the simulation, if you want to simulate a value chain business scenario. Using costs, you can represent:

A third party commission payment Payment to a supplier Both types of payment simultaneously

5 Define product usage characteristics using modelled or real customer profiles. You can use usage data from Bill, Settle and Report to create real customer profiles.

6 Run your simulation and view the results.

7 Analyze the results in the simulator. You can save and reproduce these results by using Microsoft Excel spreadsheets.

8 Save your simulation configuration in an XML file for future modification or simulation.

All of these steps are fully described in the chapters that follow in this guide.



Simulation Concepts

This section defines the concepts necessary to build a simulation and provides an example of a modelled customer profile simulation.

These topics are discussed in the following order:

Modelled customer profile simulation

Real customer profile simulation

Simulation results

Example of a modelled customer profile simulation



Modelled Customer Profile Simulation

In order to complete its calculations, the simulator takes into account the following:

Chargeable items of your product

Modelled customer profile

Chargeable item parameters

Chargeable item properties

You can use the following statistical distributions to help you to generate your simulation: uniform, lognormal, or customized.

Modelled CustomerProfiles

A modelled customer profile defines the average usage of a group of account holders with similar consumer habits. A modelled customer profile can be generated in which consumers buy either all or some of the chargeable items defined as part of the product.

A modelled customer profile is characterized by the following:

Number of consumers

Chargeable items consumed by the average consumer (type and quantity)

You can describe modelled customer profile characteristics using absolute values or statistical parameters (average, standard deviation).

Chargeable ItemParameters

Each chargeable item associated with a modelled customer profile should be parameterized. This consists in defining the following for the chargeable item:

The number of occurrences

The values of the properties

Number ofChargeable Item

Occurrences

You must define the number of times a chargeable item is consumed by a hypothetical consumer during the simulation. This number is referred to as the number of Item occurrences. Statistical distributions can be used to help generate the number of occurrences.

The number of chargeable item occurrences is defined by:

Distribution type: constant or variable (uniform, lognormal, or customized)

Value or the number of values according to the chosen distribution type

Period: daily, weekly, monthly, and so on



Chargeable ItemProperty Parameters

A chargeable item can consist of one or more user properties of numerical, string or date type. In a simulation, you often need to analyze the results when you vary the user property values of chargeable items. These values can be constant or variable. When the values are variable, you can choose among several types of statistical distribution to generate them.

The value of a “numeric” property or a “date” property can be either constant or variable. When it is variable, it follows uniform, lognormal, or customized distribution rules. In the latter case, you must specify a set of possible values with their associated probabilities.

For a “character string” property, you need to define the statistical distribution used to generate chargeable item properties.

Example If the “character string” property represents a telephone number prefix, you may want to simulate a constant usage of 20% international calls (prefix property value: 00) and 80% mobile calls (prefix property value: 06).

Usage DistributionProperties

You can choose from the following distribution types:

Uniform

Gaussian lognormal

Customized

The decision to introduce variables into the simulated profile and to choose a lognormal or uniform distribution is based on the user’s understanding of the usage to be simulated. The following table provides more information:

Uniform Distribution In this case, the number of chargeable item occurrences varies between a minimum value x and a maximum value y, as defined by the user. Each simulation takes into account a number of different chargeable items extracted from a uniform distribution with a minimum x and maximum y value.

If you have then

No statistical data to describe the usage that you want to simulate Use constant values

Statistical dataChoose the distribution type that is best adapted to the format in which your data is presented



A uniform distribution of values describes a range of n values with the same probability (p=1/n) of occurring.

Uniform distribution

Gaussian LognormalDistribution

In this case, the number of chargeable item occurrences varies according to a distribution with an average value m and a standard deviations. Each time you carry out a simulation, a number of different chargeable items extracted from a lognormal distribution are taken into account.

Gaussian distribution

CustomizedDistribution of

Occurrences Number

This is used to describe rating element usage variations over a fixed period (day, week, month, or year).

A customized distribution of occurrences number allows the user to describe variations in the number of occurrences of a chargeable item over a period of time which is independent of the simulation duration.

For this pre-defined period of time (daily, weekly, monthly, or yearly), the user can describe variations in the number of occurrences on a smaller time scale. For example, if the temporal series possesses a daily



periodicity, the user can define the number of occurrences consumed every half hour.

Customized distribution

This representation is particularly adapted for the simulation of price plans involving chargeable items that are valued on a time slot basis.



Real Customer Profile Simulation

In order to complete its calculations, the simulator can generate chargeable items based on information stored in XML files stored in a database. This information consists of transaction details that result from actual rated consumer usage.

Real CustomerProfiles

A real customer profile defines the actual usage of one or more real consumers who have consumed one or more chargeable items.

Creation of a RealCustomer Profile

In order to create a real customer profile, data relating to real customer usage must first be exported from the database to an XML file that represents this usage traffic.

This can be accomplished by using an AML request, which rebuilds a description of the usage data by using the transaction information that is stored in the Highdeal Transactive database. The new real customer profile can therefore be associated with this XML file, which contains data that describe the usage generated by the profile.

You can create a real customer profile by using data exported from your legacy system to a usage traffic XML file that is compliant with Highdeal Transactive definition.

Real Customer ProfileRegenerated by the

Simulator

Real customer profile characteristics are defined by the user during the creation of the usage traffic XML file using Highdeal Transactive. These characteristics consist of the following:

Start and end dates, which represent the duration periods of the transactions

A specific consumer or all consumers who have generated transactions between the dates specified

Transaction criteria related to offers created in Price and Rate

XML Usage TrafficFile Format

The usage traffic XML file includes a root element that is usageReport. It includes several usage elements. The usage element represents a real usage transaction related to a consumption and includes all the mandatory properties (in property elements).

The file format is described in the Price and Simulate online Help system.



Simulation Results

Once you have successfully defined the simulation parameters and run the simulation, you can then view and analyze the results. When you have finished your analysis, you can save the results as a .CSV text file. You can retrieve and make further analysis of this results file by using Microsoft Excel.

The simulator displays three types of results:

Income: for each type of rate in the price plan

Distribution: statistical description of the total income

Contribution: analysis of generated income of consumers and Chargeable Items

One-shot rates are used in the simulation tool, but only one-shot rates that can be triggered by subscription events. However, if a price plan uses an anniversary day or date of signature of a contract, the simulator takes the start date of the simulation as the date of signature.

Xi represents the income calculated for the ith iteration

Variabilities ofParameters

If you have introduced a source of variation in the simulation parameters, you can observe--in a graphical format in the Distribution tab--the impact of this element’s variability on the estimated income results.

Analyzing Sources ofRevenues

If you have defined more than one client profile (modelled or real) in the simulation parameters and/or more than one chargeable item in the product, you can graphically view and analyze the relative contribution of each of these sources of income to the net income figure. A contribution is expressed as a percentage.

Contributions may be analyses for the following relationships:

Chargeable items to the usage income

Customer profiles to the usage or recurring income

Customer profile to the income generated by each chargeable item

Chargeable item to the usage income of a customer profile

If a specified income is NULL, then no contributions are computed and displayed.



Example of a Modelled Customer Profile Simulation

Description You are a telephone operator selling calls to customers. You bill the calls based on call length only. However, you apply different rates by using prefix codes and based on whether the calls are national or international.

In Highdeal Transactive you have:

Your “telephone” product

The “telephone call” chargeable item

The “prefix of the number called” User Property

The “Call duration” User Property

The price plan, used to calculate call length and containing different rates to be applied (depending on the prefix of the number called)

You choose to simulate your price plan, based on the following statistical information:

“Individual” customers who make between two and four calls per day on average, with an average call length of 5 plus-or-minus 2 minutes

90% of calls are national

You have ten customers and you would like to calculate the revenue for your offer at the end of a month.

ApplicableParameters

The following table presents the simulation parameters to be applied for your simulation:

Parameter Value

Simulation duration 1 month

Number of iterations 100

Number of customers 10

Usage profile 1 “individual”

Number of “telephone call” occurrences Between 2 and 4; period = day

“Telephone call” duration Average = 5; standard deviation = 2 Measured in time units of mins/secs

% of “national” prefix occurrences 90

% of “international” prefix occurrences 10



In order to carry out further simulations, you can modify all of these parameters in the simulator at any time.

Modelled CustomerProfile SimulationResults in the GUI

Once you have applied the above parameters and run a simulation in Highdeal Transactive - Simulation, the results are displayed in the GUI. The following illustration shows the distribution results for the modelled customer profile example (viewed on the Distribution tab).

Distribution Results of a modelled customer profile Simulation

You can also view the results as a pie chart on the Contribution tab or as a table on the Income tab.


Index

Aabbreviations 11Access 129Access chronology 129Account Balance Management 113Account Holder 178account manager

ARP user role 217Accounts

blocking 182creating 181types 180unblocking 182

accounts 115Accounts Payable 216

in Highdeal Transactive 181, 214Accounts Receivable 216

in Highdeal Transactive 181, 214Accounts Receivable & Payable 17, 211

acronym 213module 17, 213

Accounts Recievable & Payablemanaging 213

Activation status 99Active 117Advance payments 229agent 43Aging 234Aging Report

report type 236Aging Report configuration

aging steps 236creating new 235effective date 236filter criteria 236Invoice information 236name of the report 236possible actions 235running, modifying, deleting 239storing 239zero-balance Accounts 236

Aging Reports 234A/P 234A/R 234configuration 235detailed 237differences 234overview 234storing 239summary 237viewing 240

Aging stepscharacteristics 241default 241rules 241

Alerts 116, 119All Objects Catalogue Directory 34American tax system 192AML Reports 198AML template

for Invoices/Settlement Reports 216ARP

acronym 213ARP module

common features between A/R and A/P 214interfaces 216role of 216user roles 217

ARP processesinternational use 217

ARP user interfaces 217ARP user role

account manager 217financial administrator 217

BBad debt 251

write off Call for Payment 251write off Collection File 251

Balance 116balance 75Balance Management 21balances 115BART 18Bill, Settle & Report 17Blocked 117Bulk Operations 26


Bulk operationsmodifying payment information 225

Bulk Processes 26

CCalculation 59Call for Payment 220, 244

date 220deleting 222elements of 222features 222generation settings 223write off as bad debt 251

Call for Payment generationManual 223Scheduled 223Synchronized 223

Catalogue 34directory named All Objects 34

categories of customersdunning steps 245

Charge type 99Dependent 99Master 99

Chargeable Item 47properties 48

Chargeable Items 260default properties of 48user properties 48

Charges 53Dependent 59main characteristics 99Master 57optional status example 100role and level (example) 100secondary characteristics 99versions, accessing and deleting 56

Charges usedcharacteristics of 99

Charging Components 72Charging Plan

Components 72Components Overview 72

Charging Plansicon 69

Charging Tree 70charging tree 72Closed 117code

tax code 193

Collection File 244, 248update example 250update using bulk operation 250Working View 249write off as bad debt 251

Collection grace period 221Collection Process 248

Collection File 248example 249launching 248

Collections and Dunning 244process 244

Collections Manager 244commitments 224Comparison components

overview 67types 67

Concurrent Services 77contacting Customer Support Services 8correcting transactions 201correction process

rerating 203cost entry 255Costs

in simulation process 257Counter Reservation 77Counters 99

Persistent 81Transient 81

CreatingSubscriber Accounts 115

Credit Control 77Credit Limit Balances 119CSR 229Customer Profile 255Customer Service Representatives (CSRs) 229customized distribution 262Cycle 185

DDays until payment due 221debt 244Default aging steps 241Default Charging 115Default Payment Terms

Payment Termsdefault 227

Definition of 180Delay before Call for Payment 220Dependent Charge 59discount rule 194


discountscharacteristics of 195Invoice/Settlement Reports 194types of 195

Dispute File 208Dispute Memo 208Disputes

bulk operations 208managing 207overview 207view 207

distributioncustomized 262lognormal 262types 261uniform 261

Dunning plan 244, 245Dunning settings 246

Dunning rule 244, 246Activation threshold 246Dunning plan reference 246Escalation Threshold 246Payer category 246

Dunning settings 246Dunning step 245Dunning steps 244

EEmpty Limit 116European tax system 192Example 247expiration schedule 117EZTax Connector 19

Ffinancial administrator

ARP user role 217

GGraphical User Interface, types 16

Hhierarchy 179

party roles within 179

Highdeal 275HTML report 199

Iinterest on arrears 223International use (ARP) 217Invoice date 220Invoice generation

XML document 216Invoice/Settlement Report Discounts

applying 196characteristics 194example 196

Invoice/Settlement Reportsdiscounts 194numbering pool 216

Invoices/Settlement ReportsAML template 216default cycle 216

Isolated Invoices 187

LLocked 117lognormal distribution 262

MMacros

Pricing 84mapping

of charging references 114Master Charge 57Mode 21, 59Modelled Customer Profile 260multi-valued property 68

NNet 10

example 227Net 30

example 227Net EOM 226Net EOM 10

example 227Net Payment Terms 226

271Highdeal Transactive® R4.1 (Bill and Full) (Bill and Full)


Net payment terms 221defined 226examples 227

OOffers

versions, accessing and deleting 108one-shot discount 195

example of 195one-shot discounts 195Operators 68

types 68optional status

example 100overdue payments 245Owner 43

PParameters 99Partial payments 229Party

Rating Context 178relationships in hierarchy 179roles 179Sponsor 43types of 178

Payment collection date 221Payment due date 221Payment entry 229

process 230payment entry 229

CSRs 229Payment information

bulk operations 225payment information 225payment methods

international differences 217Payment Processing 220

diagram 221overview 220terminology 220terms and definitions 220terms defined 220

Payment reconcilationdefining rules 231

Payment reconciliation 231manual 231

payment reconciliation 221

Payment Settingspersonalizing 225

Payment termcreating your own 228

Payment Termsdefining 227international differences 217

Payment termsmanaging 226

Paymentsadvance 229partial 229

Perimeter 31Postpaid Account Links 118Postpaid Account Partition Groups 183Postpaid Accounts 180Postrating 75Prepaid Accounts 116Prerating 75, 185Price & Rate 16Price & Simulate 17, 255Price Plan 67

components 67Rating Context 74Rating Tree 65

Price Plans 17, 64, 255, 257icon 64

Pricing functions 68Pricing Macro 67Pricing Macros 84

and Price Plans 84characteristics 84icon 84

Pricing macros 99Product 260production process 23Products 46, 257

icon 46Profile

Modelled Customer 260Real Customer 264

propertiesChargeable Item 48

RRadius Server Customization 19Rates 67

activation 67types of 67usage examples 67

Rating Context 74


rating engineprocess 23

rating tree 64, 67Real Customer Profile 264

characteristics of 264creation of 264

rebate 195example of 195

rebates 195recharging

constraints and tips 205References Components 72rerating

constraints and tips 205correction process example 203

Rescheduling a Call for Payment 223Reset 119Role 100

SService Provider 178Session-based Rating 77Setting Up

Subscriber Accounts 115Setting Up the Charging Mapping of Charges 135Shared Plans 141shared plans

commission example 149introduction to 141overview 142

simulation 255simulation process 255

steps in 257SNMP 19Splitters 68Sponsor 43State

of a Prepaid Account 117Stateful 21Stateless 21Subscriber Accounts

Creating and Setting Up 115Overview 114

Subscriptions 123customizing functions 129versions, accessing and deleting 136

Ttaxes

American tax system 192calculation process 193choosing a system 192European tax system 192external calculation 192internal calculation 192tax code 193tax rate 192tax type 193

transactionscorrectiion process example 203correcting 201correcting (constraints) 205

Transactive SNMP Agent 19Translation Tables 99Trigger 59

Uuniform distribution 261usage distribution properties 261usage traffic XML file 264user roles

ARP module 217

VValue Added Reseller (VAR) 43Value Chain 41

WWeb Customer Care 18Web Services 18Working View

Collection File 249

XXML file 216

273Highdeal Transactive® R4.1 (Bill and Full) (Bill and Full)


[email protected]

Highdeal Inc.North American Headquarters

286 Madison Avenue, Suite 502

New York, NY 10017 – USAPhone: +1 (212) 419 0760

Fax: +1 (917) 591 [email protected]

Highdeal S.A.EMEA Headquarters 11, avenue Delcassé75008 Paris – France

Phone: +33 (0)1 53 05 41 41Fax: +33 (0)1 53 05 41 42

[email protected]@highdeal.com

www.highdeal.com

http://www.highdeal.com

11cref us - concepts guide (bill and full) - r41

Documents