11cref Us - Concepts Guide (Bill and Full) - R41

Highdeal Transactive R4.
1 (Bill and Full)
Concept Guide
Edition 1
Highdeal Solution
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
Table of Contents
Preface About the Highdeal Transactive Concepts Guide......................1
Readers 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-
ii
Concept Guide (Edition 1)

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
Highdeal Transactive R4.1 (Bill and Full)

iii
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
iv

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

vi

Preface
About the Highdeal Transactive 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
Readers Guide Documentation Overview Conventions
3 5 11
Preface

Preface
Readers 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 Chapter 2 Chapter 3
Highdeal Transactive Overview Price and Rate and Balance Management Concepts Products, Price and Charging Plans, Charges Price and Rate and Balance Management Concepts - Offers, Subscriber Accounts, Subscriptions, Shared Plans

Preface
Chapter
Name of chapter
Chapter 4 Chapter 5 Chapter 6
Bill, Settle & Report Concepts Accounts Receivable & Payable Concepts Price and Simulate - Simulation Process and Concepts

Preface
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.
Application Examples
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 rectoverso. Therefore, if they are printed on one side of the paper only, the guide may contain extra blank pages.

Preface
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.

Preface
End-user Documentation
The following documentations are dedicated to end-users and operators of graphical user interfaces of Highdeal Transactive:
Documentation
Description 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. Presents an overview of the main concepts and functions of the following Highdeal Transactive functional modules: Price & Rate Bill, Settle & Report Accounts Receivable & Payable
Concept Guide (*)
Highdeal Transactive Desktop Tool Online Help
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.
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. Allows Customer Support personnel to manage:
Highdeal Transactive Price and Simulate Online Help
Web Customer Care Online Help
Interactions with customers Customer information and contacts Subscriptions and Accounts Allows management of:
ARP Web Interface Online Help
Payments and Calls for Payment Payment lines Aging reports
Administration Documentation
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.

Preface
It includes the following:
Documentation
Description A complete reference and procedures for installing and deploying Highdeal Transactive on your platform. A complete reference and guide for administering, operating, and monitoring Highdeal Transactive. 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. Known guidelines and known best cases for finetuning your Highdeal Transactive platform. Known guidelines and best cases for fine-tuning your Oracle RDBMS platform for Highdeal Transactive. Known guidelines and use cases for fine-tuning your MS SQL Server RDBMS platform. Known guidelines and use cases for fine-tuning your MySQL RDBMS platform. A reference for known problems, troubleshooting (levels 0 and 1), and solutions for server log messages. It contains information about how to
Installation Guide
Administration & Maintenance Guide

Parameter Reference (online)
Highdeal Transactive Tuning Guidelines (*)
Oracle Tuning Guidelines (*)
MS SQL Server Tuning Guidelines (*) MySQL Tuning Guidelines (*) Troubleshooting Guide (*)
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.
Consult also the reference guides on page 9. They detail the usage and the maintenance of specific programs of Highdeal Transactive.

Preface
Programmer Documentation
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 xml troubleshooting your developments using the APIs of Highdeal Transactive
It includes the following:
Documentation
Description 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. Specifications of the Java APIs and XML schemas used in Highdeal Transactive: API operations API data models Error handling and Java exceptions management
Technical Reference Guide
APIs Reference (online Javadoc)
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 references for Highdeal Transactive and its elements in order to develop AML files. 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.
Database Structure Reference (online)
Connector Administration Tool Online Help
(*) Not included with the PRGA of Highdeal Transactive. Is delivered during the maintenance life.
For troubleshooting purposes, the developer can refer to the online API Specification Reference (Javadoc) that details the programming exceptions.
Reference Documentation
Highdeal Transactive includes several software components that are delivered with a reference documentation that is very useful for a large

Preface
audience from the end-users and administrators to the integrators and developers. This sub-set includes the following:
Documentation BART Reference Guide
Description A complete reference for this application software about the concepts (CDR, acquisition, batch rating), the architecture, the integration, the installation and the maintenance. A complete reference for this application software about the concepts (CDR, acquisition, batch rating), the architecture, the integration, the installation and the maintenance. A complete reference for this application software about the concepts, the architecture, the integration or the customization, the installation and the maintenance. A complete reference for this software about the concepts, the architecture, the integration, the installation and the maintenance.
Diameter Server Reference Guide
Web Customer Care Reference Guide (*)
Web Services Reference Guide (*)
(*) Not included with the PRGA of Highdeal Transactive. Is delivered during the maintenance life.
Documentation Updates 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 documentation@highdeal.com.
10

Preface
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:
Style/Symbol
GUI element
Meaning Indicates text or a button that appears in the graphical user interface Example: Click OK.
Code
Indicates code to be used in APIs, AML document templates, system command Example: public void Create(String ID) Indicates a menu choice
> Link
Example: Select File > Open means select the File menu, then select the Open choice on the File menu. Indicates an active link in PDF or online documentation
Abbreviations
The user reference guides contain the following abbreviations:
Abbreviation API CAT CRM CSR CSV ERP GUI IEC
Meaning Aplication Programing Interface Connector Administration Tool Customer Relationship Management Customer Service Representative Comma Separated Value Enterprise Resource Planning Graphical User Interface Import Export Connector (Framework+Toolset)

11
Preface
Pictographs
Some information may need your special attention. The following pictographs are designed to stress this information:
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
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.
12

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. This chapter contains the following sections:
Section
Page
Highdeal Transactive Functional Overview Stateless and Stateful Modes Module Interaction Graphical User Interface Overview Starting a Work Session
15 21 23 25 29
Chapter 1
14

Chapter 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 Bill, Settle and Report 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.

15
Chapter 1
Graphical User Interfaces
There are two kinds of graphical user interface (GUI) in Highdeal Transactive: one type for desktop applications and one type for Web-based applications:
The GUI for this type of application Is used with Desktop Tool Price and Simulate Desktop user interface Connector Administration Tool (CAT) of the Connector Framework and
Toolset
BART (Batch Acquisition and Rating Toolset)
Web Customer Care

Web-based user interface (Billing or Full Edition)
Accounts Receivable and Payable Web Interface
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
16

Chapter 1
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 Receivable and 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.
Connector Framework + 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 modules 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 Highdeal Transactive R4.1 (Bill and Full)
17
Chapter 1
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 (Batch Acquisition and Rating 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)
18

Chapter 1
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 SNMP Agent
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 Server Customization
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.

19
Chapter 1
20

Chapter 1
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 Stateless Mode
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 Rating Operations
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.

21
Chapter 1
22

Chapter 1
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 Product Revenue
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 Production Process
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.

23
Chapter 1
(*) 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.
24

Chapter 1
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 Desktop Applications
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 GUI Versions
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 Tree Representation
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 Work Session
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.

25
Chapter 1
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.
26

Chapter 1
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 Webbased 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

27
Chapter 1
28

Chapter 1
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.

29
Chapter 1
User Administration
In order to preserve the integrity of the system, Highdeal Transactive allows you to limit each users 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 Administrator User Administrator Customer Sales Representative (CSR)
Authorized domain All Users
Authorized action All actions Create and modify user password or roles Create and delete: Subscriber accounts Subscriptions Accesses Display:
Subscriptions
Products Pricing macros Translation tables Charges Offers Subscriptions Accesses
Marketing
Create, modify and delete: Offers Products Pricing macros Translation tables Charges Offers
30

Chapter 1
Role Account Manager
Authorized domain
Authorized action Create, modify and delete: Parties Postpaid Accounts Discount Templates Transaction Patterns Disputes Dunning Settings All Bulk operations of Bill, Settle and Report Edit, create, modify, and register payments Edit payment information / settings Edit Calls for Payment View Aging Reports View Account Create, modify, add and delete: Collection Files Dunning Steps
Bill, Settle and Report
Financial Administrator (*) Accounts Receivable and Payable
Collections Manager (*)
Accounts Receivable and Payable
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.

31
Chapter 1
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 objects 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
32

Chapter 1
Object name
Icon
Postpaid Account
Postpaid Account Partition Group
Pricing Macro
Product
Subscriber Account
Subscription
Translation Table
User
Offers, subscriber accounts and subscriptions cannot be used in stateless mode, but only in stateful mode.

33
Chapter 1
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 Catalog Directory
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.
34

Chapter 1
Catalog Management Tasks
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.

35
Chapter 1
36

Chapter 2
Price and Rate and Balance Management Concepts Products, Price and Charging Plans, 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 Representing Your Supply Chain Products and Services Account Balance Management Charges Price Plans, Charging Plans and Pricing Macros
39 41 45 51 53 63
Chapter 2
Price and Rate and Balance Management Concepts - Products, Price and Charging Plans, Charges
38

Chapter 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:
In order to build the pricing for your offer describe how to calculate a price describe which accounts to charge
Highdeal Transactive uses the charge concept price plan concept charging plan concept
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.

39
Chapter 2
40

Chapter 2
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 Supply Chain
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

41
Chapter 2
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 NWA ActiveWatch Acme Shipping Acmes five captains
Role Commissioned agent Service provider Client Subscribers
42

Chapter 2
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 companys own service to it before reselling it as a valueadded 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.

43
Chapter 2
44

Chapter 2
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.

45
Chapter 2
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
46

Chapter 2
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 Item Example
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

47
Chapter 2
Chargeable Item Properties

A chargeable item contains properties.
Chargeable Item Properties
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 Property Example
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.
48

Chapter 2
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 Telephone service
Chargeable item Call
User property Number called Call Duration
Property type Character string Number
Product in the GUI
The following illustration shows the Telephone Service product after its creation in Highdeal Transactive:

49
Chapter 2
50

Chapter 2
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).

51
Chapter 2
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.
52

Chapter 2
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

53
Chapter 2
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:
54

Chapter 2
Price and charging plans in the charge related to the familie Smiths offer
Relationships Between Charges, Products, Price Plans and 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.

55
Chapter 2
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 charges 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.
56

Chapter 2
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:
Product User Property Charge Type of Charge Price Plan Type of Rate
Training Module Module Code Purchase Module Master Module Download Use
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.

57
Chapter 2
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).
58

Chapter 2
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 Charge Example
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 customers subscription. The table below summarizes this example:
Product
Charge
Type of Charge
Price Plan
Type of rate in the Price Plan Recurring Recurring
Document
Document Subscription Sales Commission
Master Dependent
Customer Subscription Author Payment
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.

59
Chapter 2
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 Billed Commission
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.
60

Chapter 2
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 Charge Summary
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 Yes Yes No Yes Free Relationship type Partner Client n/a Client Free Adjust master transaction No Yes n/a No Free
Commission Sponsorship Discount Third PartyBilled Commission Other
Credit Debit Credit Debit Free

61
Chapter 2
62

Chapter 2
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

63
Chapter 2
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.
64

Chapter 2
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 and Rates
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 calllength 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 Tree Illustration
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:

65
Chapter 2
Tree Root Tree Branch - Usage Rate Three Types of Component Tree Leaf
66

Chapter 2
Price Plan Component Overview
Price Plan Components
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 Plan Components
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:
Type of rate Usage Recurring One-Shot
Activation Each usage Periodic Once only
Usage example Telephone call Monthly fees Administration fees
The one-shot rate component is activated on a subscription-related event.
Comparison Components
A Comparison evaluates a property in the rating context and, depending on the evaluation results selects a price plan branch. The rating context may

67
Chapter 2
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.
Operator Components
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.
Function Components
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.
68

Chapter 2
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.

69
Chapter 2
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 and Charging 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 Tree Example 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:
70

Chapter 2
Price and charging plans in the charge related to the familie Smiths offer

71
Chapter 2
Charging Plan Component Overview
Charging Plan Components
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 Charging Plan 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.
Charging 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 following table shows the different types and the relevant activation:
Type of Charging Usage Recurring One-Shot Default
Activation Usage Rate Recurring Rate One-Shot Rate Any Rate component
References Components
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
72

Chapter 2
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

73
Chapter 2
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.
74

Chapter 2
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 customers 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 a telephone 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

75
Chapter 2
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.
76

Chapter 2
Session-Based Rating and Reservation Overview

In Highdeal Transactive, two types of rating are provided: Prerating and postrating Session-based rating
Prerating and Postrating
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-based Rating
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 Services in 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 Reservation and Credit Control
A session-based rating is provided with counter reservation and credit control. The credit control is a mechanism which directly interacts in realtime 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 Sessionbased 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.

77
Chapter 2
In this case, a certain amount of monetary or non-monetary units is reserved on the subscribers 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-based Rating 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.
78

Chapter 2
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.

79
Chapter 2
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.
80

Chapter 2
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 Counter Example
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.

81
Chapter 2
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 sessionbased rating. See the chapter Session-Based Rating and Reservation Overview.
Transient Counter Example
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:
Session Step Start (method = reservation) (duration_quota = 3 min*) Update (method = confirmation) (duration_quota = 2 min) ---------------------------------(method = reservation) (duration_quota = 3 min Stop (method = confirmation) duration_quota = 1 min
Amount to cancel
Amount to confirm
Amount to reserve 3 x $0.20 = $0.60 call_duration = 0 min
- $0.60 (3 x $0.20) call_duration = 0 min ----------------------------
2 x $0.20 = $0.40 call_duration = 2 min ----------------------------------------------------3 x $0.20 = $0.60 call_duration = 2 min
- $0.60 (3 x $0.20) call_duration = 2 min
1 x $0.20 = $0.20 call_duration = 3 min
* duration_quota and call_duration are expressed in minutes (min).
82

Chapter 2
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:
Subscription $20 $40 $60 Call time 2 hours 5 hours 10 hours
Using these parameters, you can build specialized packages (call plans) where no other parameters are visible. For example, you can have a 2hour 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.

83
Chapter 2
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 Macro Characteristics
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.
84

Chapter 2
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.

85
Chapter 2
Pricing Policy: Application Example
Pricing Policy Example
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:
Question
Process Calculate the duration of the call in minutes, according to the difference between two dates Define the weekend period Compare the start date of the call to the weekend period Apply a linear function to the Call Duration property, with two possible constants (0.17 and 0.34)
Properties to use
Component family
Component
What is the duration of the call?
Call Start Date Call Stop Date
Operators
Duration
Did the call start during a weekend period?
Call Start Date
Comparison s
Date / Time slot
Which calculation formula?
Call Duration: Property generated by higher calculation
Functions
Linear
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.
86

Chapter 2
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.

87
Chapter 2
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
88

Chapter 2
4 Calculate the call duration and generate the Call Duration property by
using the Duration component..
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.
Date / Time Slot component

89
Chapter 2
7 Calculate the price of the call during the weekend in the weekend
branch by using the Linear Function component.
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
90

Chapter 3
Price and Rate and Balance Management 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: This chapter contains the following sections:
Section
Page
Offers Subscriber Accounts Subscriptions Shared Plans
93 113 123 141
Chapter 3
Price and Rate and Balance Management Concepts - Offers, Subscriber Accounts, Subscriptions, Shared Plans
92

Chapter 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

93
Chapter 3
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
94

Chapter 3
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:
Basic offer
Charges Equipment Rental
Rate used in the Plan Recurring Usage One-shot
Product
Fixed Telephone
Calls Installation
Telephone
Complex Offer Example
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:
Complex offer
Simple offer
Product
Fixed Telephone Telinter
Calls Installation
Telephone
Internet Access (usually this includes monthly fees in additon to the connection fee)
Connection
Internet
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:

95
Chapter 3
Fixed Telephone Simple Offer
Internet Access Simple Offer
Complex Offer structure
Telinter Complex Offer
96

Chapter 3
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
Describing Composition
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
Describing Organization
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

97
Chapter 3
the offer plays the role of master charge (in terms of triggering or calculation).
Link Between Structure 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 Creation Stages 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 Identifier
Complex offer Identifier Validity period Additional data (in any format) Offer and charge composition Offer subscription rules Organization: Charge interdependency 2 levels: Subscription and offer
General characteristics
Validity period Additional data (in any format)
Charge composition 2 Structure Organization: Charge interdependency 3 Setup Charge level
98

Chapter 3
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.
Secondary Characteristics
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

99
Chapter 3
If you choose the optional status, all actions related to this charge are desynchronized 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 Status Example
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 and Level
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:
100

Chapter 3
Charge Catalogue
Charge Subscription Sales Commission Type Master Dependent Plan rate Recurring Recurring
Offer Catalogue
Offer Composition Subscription charge Module Sales commission charge Role: Commission Level: Subscription Organization Master Dependent on the subscription Charge

101
Chapter 3
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 the Charges
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 Main Characteristics
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 Applying Values
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
102

Chapter 3
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 Main Characteristics 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 Monthly Module Subscription: Recurring Rate Monthly periodicity Main characteristics Master charge Parameter: Name: subscription fee Default value: $10 Master charge Document Download Document Download: Usage Rate Download Access: One-shot Rate Parameter: Name: download fee Default value: $1 / megabyte Master charge
Module Subscription
Membership Fee
Offers Catalogue
Offer Type of offer Composition Elements Main characteristics Subscription fee: not redefined Value applied: $10 Master charge Redefined subscription fee: $15 Master charge Redefined subscription fee: $17
Private Individual Module
Simple
1 charge
Module Subscription Charge Module Subscription Charge Module Subscription Charge
Company Module
Simple
1 charge
Organization Module
Simple
1 charge

103
Chapter 3
Offers Catalogue
Offer Type of offer Composition Elements 1- Access Fee Charge Document Download Simple 2 charges 2- Document Download Charge Main characteristics Master charge Master charge Download fee: not redefined Module Subscription master charge Subscription fee: not redefined Value applied: $17 Complete Organization Module 1- Membership Fee master charge 2- Document Download Offer 2- Document Download master charge Download fee: not redefined Value applied: $1 / MB
1- Organization Module Offer
Complex
2 simple offers
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.
Redefining Secondary 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 Status Example
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.
104

Chapter 3
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.

105
Chapter 3
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.
Redefining Organization
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.
106

Chapter 3
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 suboffers. 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.

107
Chapter 3
Accessing and Deleting 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.
108

Chapter 3
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 Module Subscription
Price Plan Recurring Rate
Main characteristics Master charge Parameter: Subscription price Dependent charge Parameter: percentage value Dependent charge Parameter: percentage value Master charge Master charge Master charge Master charge Master charge Parameter: fee amount
Module Commission
Recurring Rate
Module Discount Module Registration Fees Document Download Server Access Membership Fee Subscription Fee
Recurring Rate One-shot Rate Usage Rate Usage Rate One-shot Rate One-shot Rate

109
Chapter 3
Offers
Here is the catalog of proposed offers: Basic Offers

Offer Composition Elements Module Subscription Basic Module 3 charges Module Commission Registration Fee Basic Download Server Access 1 charge 2 charges Membership Fee Mandatory Document Download Server Access Status Mandatory Mandatory Mandatory Mandatory Mandatory
Basic Module simple offer
Basic Download simple offer
110

Chapter 3
Server Access simple offer
Complete Module complex Offer

Content Components Offer status Content Elements Module Subscription Basic Module Offer Mandatory by 5 3 charges Module Commission Module Registration Fee 3 suboffers and 2 charges Basic Download Offer Server Access Offer Module Discount Charge Subscription Fee Charge Optional 1 charge Document Download Server Access Optional 2 charges Membership Fee Charge activation Mandatory Mandatory Optional Mandatory Mandatory Optional
Optional
Optional

111
Chapter 3
Complete Module complex offer
112

Chapter 3
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

113
Chapter 3
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 Credit an 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.
114

Chapter 3
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 a Subscriber 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.

115
Chapter 3
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.
116

Chapter 3
State of a Prepaid Account
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.

117
Chapter 3
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.
118

Chapter 3
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.

119
Chapter 3
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.
120

Chapter 3
Subscriber Accounts
Each Atlantides employee is represented in Transactive by a subscriber account. For example, John Smiths 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 Smiths subscription, the charging mapping of the charge Calls shows the following links:
Charging reference
Charged account
Credit Limit Balance #1 -----------------------------
CompanyAccount IndividualAccount
Atlantide Individual
The amounts calculated in the price plans are charged to John Smiths 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

121
Chapter 3
122

Chapter 3
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

123
Chapter 3
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.
Subscription Example
Telcoserv proposes the following complex Telinter offer:
Complex offer
Simple offers
Subscription
Product
Telinter
Fixed Telephone Internet Access
Mandatory by batch of 4
Communication Installation
Telephone
Mandatory
Connection
Internet
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
124

Chapter 3
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.
Subscription Representation
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:
Subscription Structure
Techlingua subscription to the Telinter offer, containing 4 fixed telephone subscriptions

125
Chapter 3
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.
126

Chapter 3
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 the Structure
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.

127
Chapter 3
Saving a Subscription
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.
128

Chapter 3
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

129
Chapter 3
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 Normal Mode
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 in Customized 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:
Level
Action Suspend / Resume
Subscription
Freeze prices Cancel
Charge
Activate / Deactivate
Graphical Interface Actions
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 and Resuming 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.
130

Chapter 3
Subscription pricing automatically restarts on the planned resumption date.
Freezing Subscription 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.
Cancelling Subscriptions
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 and Deactivating 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 Mandatory Charges
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 Optional Charges
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.
Desynchronized Activation 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.

131
Chapter 3
Dates in Offers and Subscriptions
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.
132

Chapter 3
Offer Effective Date
Offer Expiration Date
Offer
Subscription Effective Date
Frozen Price Date
Unfrozen Price Date
Suspension Date
Resumption Date
Subscription Expiration Date
Subscription to Offer
Fixed prices Sub-offer Effective Date Sub-offer Expiration Date
Subscription to Sub-offer
Charge Effective Date
Charge Expiration Date
Activated charge of subscription
No usage or recurring rates
Fixed prices
No usage or recurring rates
Cancellation Date
Fixed price period Suspension period
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.

133
Chapter 3
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 Activated Charges
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.
Redefining Characteristics
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
Applying Redefinitions
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.
134

Chapter 3
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
CompanyAccount IndividualAccount
Atlantide Individual

135
Chapter 3
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 and Deleting Subscription Versions
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
136

Chapter 3
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.

137
Chapter 3
Subscriptions: Application Example
Subscription Example
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
Components
Number of subscriptions 10 1 5 1 1
Content 2 activated charges (instead of 3) 1 charge 1 activated charge (instead of 2)
Note Registration Fee charge not activated
Basic Module Offer Basic Download Offer Server Access Offer Module Discount Charge Subscription Fee Charge
Membership Fee charge not activated Activated charge with a rate of 5% (Parameter) Activated charge
Illustration
The illustration below shows the Techlingua subscription in the graphical interface:
138

Chapter 3

139
Chapter 3
140

Chapter 3
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

141
Chapter 3
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, suboffers, 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
142

Chapter 3
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 of Examples
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:

143
Chapter 3
Example Telephone Subscription Commission Received on Plan Internet Connection Shared Minutes Plan Favorite Numbers
Offer type Basic Basic Complex Complex Complex
Shared element Counter and parameter Parameter Counter Counter and parameter Translation table
Reason for sharing
To link variables
To meet the needs of customers organized by group
144

Chapter 3
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 (1st Method)
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:
Charge
Added Elements
Usage 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 Recurring Rate branch: resets C Usage Rate branch: updates the C counter based on call duration
Telephony
Credit Parameter (number of minutes prepaid monthly)
C Counter (number of
minutes consumed monthly)
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.

145
Chapter 3
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 (2nd Method)
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 Price depends on Psub parameter Resets the C-sub counter to the beginning of the period 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 Updates the C-call counter using the call duration
Subscription
1 Recurring Rate branch
P-sub parameter (number of minutes) C-sub counter (number

of minutes consumed)
Call
1 Usage Rate branch
P-call parameter (number of minutes)
C-call counter (number

of minutes consumed)
146

Chapter 3
Offer Description
Offer Shared elements created in the offer Implemented links P-Credit <-> P-sub (subscription used charge) P-Credit <-> P-call (Call used charge) C <-> C-sub (subscription used charge) C <-> C-call (Call used charge)
P-Credit parameter
Telephone subscription: usage of 2 charges Subscription Call (number of prepaid minutes)
C counter (number of
minutes consumed)
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 Psub 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:

147
Chapter 3
Method 1
Method 2
Telephone Subscription
Telephone Subscription
P-Credit
Credit C
Telephony Telephony Charge Charge
P-sub
P-call
C-sub Parameter Counter Charge Offer Subscription Charge Subscription Charge
C-call Call Charge Call Charge
link: is represented by
148

Chapter 3
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 Subscription Created elements Usage in the charge The subscription price depends on the P-sub parameter Within the agreed-upon plan P-call, the Call is free; outside this, calls must be paid for
P-sub parameter (plan type, in number of prepaid hours) P-call parameter (plan
Call
type, in number of prepaid hours)
Administrative fee Commission (dependent charge)
P-comm parameter (plan

type, in number of prepaid hours)
The amount paid depends on the P-comm parameter

149
Chapter 3
Offer Description
Offer Monthly plan: usage of 4 charges Subscription Call Administrative Fee Commission Shared element created in the offer Implemented links P-plan <-> P-sub (Subscription charge) P-plan <-> P-call (Call charge) P-plan <-> P-comm (Commission charge)
P-plan parameter (plan

type)
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, Pcall, and P-comm parameters becomes impossible.
Diagram
The following diagram illustrates the offer structure in the Commission Received on Plan example:
150

Chapter 3
1h, 2h or 4h in Subscription
Commission received on Plan
P-plan
P-sub
P-call
P-comm Administra Administra tive Fees tive Fees Charge Charge
Subscription Subscription Charge Charge
Call Charge Call Charge
Commission Commission Charge Charge
Parameter Counter Link: is represented by
Charge Offer Dependency between Charges
Commission received on Plan Offer

151
Chapter 3
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 Connection Counter
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.
152

Chapter 3
Group Connection Counter
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, Userscanc) 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 NumUsers(1) shared counter of the sub-offer The details are presented in the following table: Charge Catalogue
Charge Subscription Installation Cancellation Connection
Rate used Recurring One-shot One-shot Usage
Created elements
Usage in the charge Price depends on Users-
Users-sub
counter
sub Users-inst is incremented

by 1
Users-inst
counter
Users-canc
counter
Users-canc is decremented 1

153
Chapter 3
Offer Description
Offer Offer type Composition Shared element created in the offer Implemented links
4 charges Single Connection Subscription Basic Installation Cancellation Connection Group Connection Complex Single Connection offer
Num-Users(2) Num-Users(1)
counter
Num-Users(1) <-> Users-sub Num-Users(1) <-> Users-inst Num-Users(1) <-> Users-canc
counter
Num-Users(2) <-> Num-Users(1)
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 Userssub, Users-inst, and Users-canc counters becomes impossible.
Diagram
The following diagram illustrates the offer structure in the Group Connection complex offer example
154

Chapter 3
Modifiable Counter in the Subscription
Num-Users(2)
Group Connection
Simple Connection
Num-Users(1)
Users -sub Subscription Subscription Charge Charge
Users-inst
Users -canc Cancellation Connection Cancellation Connection Charge Charge Charge Charge
Installation Installation Charge Charge
Parameter Counter
Charge Offer
Group Connection complex Offer
Link: is represented by

155
Chapter 3
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 Plan Pricing
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 the Offer
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
156

Chapter 3
The details of the steps are presented in the following table: Step 1 Charge Catalogue
Charge Rate used Created elements
P-sub parameter (number of calling plan minutes)
Usage in the charge Price of the subscription depends on P-sub
Subscription
Recurring
C-sub counter (number of minutes consumed in the period) P-call parameter (number
Resets C-sub
of calling plan minutes)

P-res-call parameter
Calculation of the price of the calls (test of the C-call counter in relation to planned P-call plan) Calculation of the price of the calls (test of the C-res-call counter in relation to planned Pres-call plan) Calculation of the price of the calls (test of the C-call counter in relation to planned P-call plan) Update C-call counter Calculation of the price of the calls (test of the C-res-call counter in relation to P-rescall) Update C-res-call counter (if necessary)
(number of calling plan reserve minutes)
Call
Usage
C-call counter (number of
calling plan minutes consumed)
C-res-call counter (number of calling plan reserve minutes consumed)
Step 2 Individual Plan offer

Offer Composition
2 charges Individual Plan Subscription Call

157
Chapter 3
Step 3 Shared Plan (Individual Plan Offer)

Type of shared element created Name Meaning Implemented links
Parameter
P-ind
Number 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-ind
Number 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-shar
Number 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 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
Counter
C-shar
Number of shared plan minutes consumed
158

Chapter 3
Implementing Subscriptions
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 3 plans of 60 minutes 2 plans of 120 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:

159
Chapter 3
30, 60, 120 or 180 mn in the Subscription
30 or 60 mn in the Subscription
Shared Minutes Plan
P-shar
C-shar P-ind C-ind
Individual Plan
P-sub C-sub P-call P-res-call P-sub P-sub C-sub C-sub Subscription Subscription Charge Charge
C-call
C-res-call
Subscription Subscription Charge Charge
Parameter Counter
Charge Offer
Shared Minutes Plan complex Offer
160

Chapter 3
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 operators 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 Highdeal Transactive R4.1 (Bill and Full)
161
Chapter 3
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:
Needs and Means

Offer Need
The same discounts for all customers (emergency and information numbers) The same discounts for all customers (information service for the general public) Specific discounts for one customer: customer favorites The same discounts within each customer group (group favorites) The same discounts for all customer groups (professional information services) Specific discounts for the Basic Service sub-offer subscribers (consumption information service) Specific discounts for one member of one group (customized favorites)
Need N
1
Means
Structure
All Basic Plan Monthly Plan Basic Service
Discount Translation table
Call charge
Exceptions on the Discount Table
Basic Service offer Monthly Plan offer Customer subscription to the Basic Service offer Group offer Group customer subscription to the Group offer
Exceptions on the Discount Table Shared plan: sharing of the Discount Table
Exceptions on the shared Table
Group offer
Group
Basic Service sub-offer
Member subscription
Building the Catalogue
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:
162

Chapter 3
Step 1 Creating the Discount Translation Table

Input column (the number called) Output column (% of discount) Service
112 123
100 50
Emergency Telephone directory
Step 2 Creating the Call Charge

Charge Content Characteristic element Discount translation table Usage The price of a call is discounted if the called number is already in the Discount Table
Call
One usage rating branch
Step 3 Creating the Basic Service Offer

Offer Content Need N Action Location of the action (structure)
Basic Service
Call charge
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

Offer Content Need N Action Location of the action (structure))
Monthly Plan
Call charge
Redefine the Discount Table: add 2 information service numbers 456 -> 10% discount (traffic info) 868 -> 5% discount (weather)
Call used Charge

163
Chapter 3
Diagram
The following diagram illustrates the structure of the Basic Services and Monthly Plan offers:
Redefinition of the Discount Translation Table in the Call Used Charge
Redefinition of the Discoun Translation Table in the Cal Used Charge
456
20% 10% 456 10% 5%
Basic Service
868
Monthly Plan
Discount 112 123 100% 50%
868
Discount 112 123 100% 50%
Basic Service Offer
Monthly Plan Offer
Charge Offer
Translation Table
164

Chapter 3
Step 5 Creating the Group Offer

Offer Content Need N Action Location of the action (structure) Group offer Call used Charge in the Basic Service sub-offer Call used Charge in the Monthly Plan sub-offer
Define the shared element GroupDiscount (specific Discount Table instance) Link GroupDiscount to the Discount Table
4 Basic Service sub-offer Monthly Plan suboffer 5
Group
Link GroupDiscount to the Discount Table Redefine the GroupDiscount table: add 1 professional information service number 989 -> 10% discount (financial info) Redefine the Discount table: add one consumption information number 030 -> 50% discount (consumption info)
Group offer
Call used Charge in the Basic Service sub-offer
Group Offer Diagram
The following diagram illustrates the structure of the Group offer:

165
Chapter 3
989
10%
Redefinition of the Group Discount Translation Table in the Group complex Offer
Group Discount
Group Offer
456 868
20% 10%
456 868
10% 5%
Basic Service
Discount 112 123 100% 50% 030 50%
Monthly Plan
Discount 112 123 100% 50%
Charge Offer
Translation Table
Redefinition of the Discount Translation Table in the Used Charge of the Basic Service sub-Offer
Group complex Offer
Description of the Example
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:
166

Chapter 3
Customer
Need N
Action
Create a subscription for John Woods to the Basic Service offer
Location of the action (structure)
John Woods
Redefine the Discount table: add the 7 favorite numbers and the 20% discount Create the Group offer subscription with the following: 6 Subscriptions to the Basic Service sub-offer
Call activated charge in John Woods subscription
4
Language & Technology
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 Call activated charge in Mike Smiths subscription
Redefine the Discount table: add Mike Smithss 3 favorite numbers and the 20% discount

167
Chapter 3
Diagrams of the Subscriptions
The following diagrams illustrate the Submersions for John Woods, Languages & Technology, Employee 1, Employee 7, and Mike Smith.
John Woods Subscription
Redefinition of the Discount Translation Table in the Used Charge of the Basic Service Offer
456 868
20% 10% 1 20% 20% 20% 20% 20% 20% 20%
Discount 112 123 100% 50%
2 3 4 5 6
7 favorite numbers: redefinition of the Discount Translation Table in the Activated Charge
Call
John Woods Subscription
Activated Charge Subscription
Translation Table
168

Chapter 3
Group Discount Language & Technology Subscription

1 2 3 4 5 989 10% 6 7 8 9 10 20% 20% 20% 20% 20% 20% 20% 20% 20% 20%
10 favorite numbers: contents of the Group Discount shared Translation Table, which is defined in the Subscription
6 Subscriptions to the Basic Service subOffer
4 Subscriptions to the Monthly Plan sub-Offer
Redefinition of the Group Discount Translation Table in the Group Offer
Language & Technology Subscription

Activated Charge Subscription Translation Table
Agent 1 Subscription
Redefinition of the Discount Translation Table in the Used Charge of the Basic Service sub-Offer Redefinition of the Discount Translation Table in the Used Charge of the Basic Service Offer
030
50% 456 868 10% 5%
456 868
20% 10%
Discount 112 123 100% 50%
Redefinition of the Discount Translation Table in the Used Charge of the Monthly Plan Offer
Discount 112 123 100% 50%
Call
Call
Activated Charge Subscription
Translation Table

169
Chapter 3
Mike Smith Subscription
1 2 3
20% 20% 20%
3 favorite personal numbers: redefinition of the Discount Translation Table in the Call Activated Charge
456 868
10% 5%
Redefinition of the Discount Translation Table in the Used Charge of the Monthly Plan Offer
Discount 112 123 100% 50%
Call
Mike Smith Subscription

Activated Charge Subscription Translation Table
Results
The following table presents a summary of the discounts granted: Discounts Granted
Person(s) Number(s) 7 favorites 456 John Woods 868 112 123 030 989 10 favorites Employees 1 to 6 (Languages & Technology) 456 868 112 123 Discount 20% 20% 10% 100% 50% 50% 10% 20% 20% 10% 100% 50%
170

Chapter 3
Discounts Granted
Person(s) Number(s) 989 10 favorites Employees 7 to 9 (Languages & Technology) 456 868 112 123 3 favorite personal numbers 989 Mike Smith (Languages & Technology) 10 favorites 456 868 112 123 Discount 10% 20% 10% 5% 100% 50% 20% 10% 20% 10% 5% 100% 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:

171
Chapter 3
Observation Order of Translation Tables

Row 1 2 3 4 5 6 Location Subscription activated charge Sub-offer used charge Subscription Offer Basic Offer used charge Translation table Type Table redefinition Table redefinition Shared table content (specific instance) Shared table redefinition (specific instance) Table redefinition Table content
172

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. This chapter contains the following sections:
Section
Page
Creating the Bill, Settle and Report Environment Billing and Settlement Concepts Correcting Transactions Rerating Subscriptions Managing Disputes
175 177 201 203 207
Chapter 4
174

Chapter 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.

175
Chapter 4
176

Chapter 4
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

177
Chapter 4
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.
178

Chapter 4
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).
Relationships Between 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 companys organizational structure.

179
Chapter 4
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 Accounts Receivable Accounts Payable
a postpaid account calculates what the account holder owes the service provider the service provider owes the account holder
180

Chapter 4
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 Smiths 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).

181
Chapter 4
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.
182

Chapter 4
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

183
Chapter 4
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.
184

Chapter 4
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/Settlement Report 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/Settlement Report 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 and Customized 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: Highdeal Transactive R4.1 (Bill and Full)
185
Chapter 4
Activation Mode
Available for Invoice/settlement report calculation Invoice/settlement report generation
Description
Manual
The service provider manually activates each process The service provider defines a frequency and specifies the dates for the processes to be activated Available frequencies: daily, weekly, biweekly, monthly, bi-monthly, quarterly, semi-annual, annual Invoice/settlement report generation is activated at the same time as invoice/ settlement report calculation
Scheduled
Invoice/settlement report calculation Invoice/settlement report generation
Synchronized
Invoice/settlement report generation
186

Chapter 4
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 about Isolated 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 an Isolated 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

187
Chapter 4
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.
Icon to select transactions
Calculate Isolated Invoice window
3 Click the icon to select transactions. The Calculate Isolated Invoice

window opens.
188

Chapter 4
Icon to search for 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 Existing Isolated Invoice
Modifying an existing isolated invoice consists in: Adding transactions to or removing transactions from the isolated invoice Recalculating the isolated invoice

189
Chapter 4
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.
190

Chapter 4
Icon to add transactions
Icon to remove transactions
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.

191
Chapter 4
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.
192

Chapter 4
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).

193
Chapter 4
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/Settlement Report 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/Settlement Report Discount Characteristics
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.
194

Chapter 4
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 Report Discounts
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-Shot Discounts 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 Report Discount Characteristics
This table summarizes the types and characteristics of the different discounts available in Bill, Settle and Report:
Discount Types and Characteristics

Discount type Invoice/ Settlement Report Discount One-Shot Discounts Rebate Application Recurring Calculation Discount rules (percentage and threshold) Specified percentage Fixed amount Selection method Transaction filter Selection period Billing/settlement period Entire period Not applicable
Once Once
Transaction filter Not applicable

195
Chapter 4
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
Fedex Party window
196

Chapter 4
Discount Rule
Discount Template window
Sopreto Fedex Account Discount on Sopreto Invoice
Sopreto-Fedex Account window, Invoice/Settlement Report Discount tab

197
Chapter 4
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.
198

Chapter 4
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 AML report
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

199
Chapter 4
200

Chapter 4
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.

201
Chapter 4
202

Chapter 4
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 of Correction 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

203
Chapter 4
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.
As of September 5, the system should have contained the following values:
Object John Woods subscription Joan Woods subscription
Field Plan duration parameter: 2 hours Plan duration parameter: 1 hour
4 The selection rules for subscription to be rerated are as follows:
Main criteria John Woods subscription identifier Joan Woods subscription identifier
Start date September 5, 2002 September 5, 2002
5 To correct the system you must complete the two following actions:
Actions Change the parameter value: enter the correct value (2 hours) as of September 5, 2002 Change the parameter value: enter the correct value (1 hour) as of September 5, 2002
Where John Woods subscription Joan Woods subscription
6 The rerating process must be launched two times in succession:

The first time to rerate John Woods consumption The second time to rerate Joan Woods consumption
204

Chapter 4
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.

205
Chapter 4
206

Chapter 4
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.

207
Chapter 4
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: Bulk Operations
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 Bulk Operation 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
208

Chapter 4
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.

209
Chapter 4
210

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.
This chapter contains the following sections:
Section
Page
Accounts Receivable and Payable Module Payment Processing Aging Reports Collections and Dunning
213 219 233 243
Chapter 5
212

Chapter 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 Transactive Getting acquainted with the ARP module
2 Payment processing
Payment processing overview Call for payment management Payment information and service provider payment settings Payment terms management Payment entry Payment reconciliation
3 Aging reports
Aging reports overview Aging report configuration Aging steps
4 Collections and dunning

Collections and dunning overview Dunning plans Collection files Writing off bad debt

213
Chapter 5
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 of A/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
214

Chapter 5
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)

215
Chapter 5
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 Module Interfaces
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).
Accounts Receivable 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.
216

Chapter 5
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. ARP User Roles
Role Financial Administrator Description 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: Collections Manager Payment settings Payment information Calls for Payment Dunning settings
The user with this role is authorized to manage collection files.
International Use of A/R and A/P Processes
The Accounts Receivable and Accounts Payable processes are basically the same wherever you are in the world. However, some elements that may differ from one country to another can be handled by configuring the ARP module and by customizing the Web user interfaces. The table below lists elements that may be different. Elements of A/R and A/P that may differ from country to country
Element Payment Terms Description and how to handle the difference 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-ofsale 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

217
Chapter 5
218

Chapter 5
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

219
Chapter 5
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 Processing Terminology
The following table presents terms used in payment processing and a brief definition of each term. Payment Processing Terms and Definitions
Term Invoice/settlement report date Delay before call for payment Definition Date on which the invoice/settlement report is calculated. 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. Record that is associated with an invoice/settlement report. It is present during the complete payment process for the invoice/settlement report. Date that the call for payment is created. This date begins the time period that lasts until the payment due date.
Call for payment Call for payment date
220

Chapter 5
Payment Processing Terms and Definitions

Term Days until payment due Payment due date Collection grace period Payment collection date Net payment terms Definition Period of time after the creation of the call for payment but before the payment is due. Deadline for paying the invoice/settlement report. This is at the end of the days until payment due period. Grace period after the payment due date but before starting the collection process. Date after which the service provider will try to recover the overdue amount. Terms which specify the time period in which payment is required. (Please see the section titled Net Payment Terms for more information.) 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 reconciliation
A Look at Payment Processing
The following diagram illustrates the principal steps involved in payment processing.
Invoice Invoice calculation calculation date date
Call for payment date
Payment due date
Payment collection date
Delay before call for payment
Days until payment due
Collection grace period
Payment processing

221
Chapter 5
Call for Payment Management
Call for Payment Features
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 followup 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.
222

Chapter 5
Call for Payment Generation
An Administrator can define how a call for payment is generated by modifying the following settings in the config file of Highdeal Transactive:
If set to Manual Synchronized
then The call for payment is generated upon service provider demand, through the GUI. The call for payment is automatically generated in synchronization with invoice/settlement report calculation. 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).
Scheduled
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 Call for 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:
Invoice calculation date
Payment due date
Delay before call for payment
Days until payment due
Collection grace period
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.

223
Chapter 5
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.
224

Chapter 5
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.
Personalizing Payment 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.

225
Chapter 5
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 Delay before call for payment Days until payment due and end of month flag (EOM) Collection grace period Payment terms are explained in more detail in the following section.
Overview of Net Payment 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 Net EOM
Payment is due immediately upon receipt of the invoice/ settlement report. Payment is due by the end of the month of invoice/settlement report date For example: If the invoice/settlement report date is March 10th, then payment is due on March 31st
226

Chapter 5
The following table presents examples of Net terms that the Highdeal Transactive system handles. Examples of Net terms
If the term is
Net 10
then the payment is due 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.
Defining Net Payment Terms
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 provider, 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 payment terms, or defining new values for the payment terms.
Default Net Payment Terms
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 provider 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:
Net 10 Net 30 Net EOM 10 Net EOM 30 Net EOM 60 Net EOM 90
Net 60 Net 90

227
Chapter 5
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
228

Chapter 5
Payment Entry
Entering and Applying 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 payments 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.

229
Chapter 5
Payment Entry Process
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 reports Choose to apply all or part of the payment amount as an advance payment Add 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.
230

Chapter 5
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.

231
Chapter 5
232

Chapter 5
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

233
Chapter 5
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/R and A/P Aging Reports
The following table presents differences between aging reports for Accounts Receivable and for Accounts Payable. Differences between A/R and A/P aging reports
Accounts Receivable This aging report allows the service provider to see: whether and by how much its customers are behind in making payments The reporting is on the open invoices on Accounts between: one fixed service provider and the service provider's Clients Accounts Payable 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 settlement reports on Accounts between: one fixed service provider and the service providers Partners
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.
234

Chapter 5
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 Aging Report 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.
Name of report Summary or Detailed report Service provider and Effective date
Filter and Sort criteria, Zero-balance Accounts (or not)
Invoice information
Aging steps
Elements to be selected or defined when creating a new detailed aging report

235
Chapter 5
Aging Report Configuration 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 run The 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 Name State City Country Please note that at least one sort criterion must be selected.
236

Chapter 5
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 and Summary 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. Types of aging reports
Type Detailed Description The Detailed aging report shows one line per invoice/ settlement report, grouped and sorted according to the specified sort criteria. The Summary Aging Report aggregates the total balance due within each of the defined sort criteria ranges. Summary 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.
Invoice, Account, and Account 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).

237
Chapter 5
The following table presents a description of invoice/settlement report lines, account lines, and account set lines in an aging report: Aging Report Elements: Invoice/settlement report, Account, and Account Set Lines
Element Description 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. The Account line contains the following: Account line Account ID Customer (account holder) name Total amount (for the account) Total remaining amount to pay for each aging step period
Invoice/ settlement report line
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.
To better visualize invoice/settlement report lines, account lines, and account set lines, see the following illustration of an Accounts Receivable aging report.
238

Chapter 5
Invoice line Account line Account line
Account set line
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 Report Configurations
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 Aging Reports
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.

239
Chapter 5
Viewing Aging Reports
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).
240

Chapter 5
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: Default Aging Steps
The step 30 60 90 90+ is defined as 0 - 30 days 1 - 60 days 1 - 90 days 90 days or more
Aging Steps Characteristics 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.

241
Chapter 5
242

Chapter 5
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

243
Chapter 5
Collections and Dunning Overview
Collections and Dunning
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 and Dunning 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 customers debt to another dunning plan at a higher level, or Write off the collection file or call for payment as bad debt
244

Chapter 5
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
. Dunning Plan Dunning Step Definition Dunning Step Definition Dunning Step Definition Action Definition Delay Category
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

245
Chapter 5
Invoice calculation date
Payment due date
Dunning action
Dunning action
Delay Delay before Call for Payment Days until payment due Collection grace period
Delay
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.
246

Chapter 5
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

247
Chapter 5
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 the Collection 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.
Generating Collection 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.
248

Chapter 5
Collection File Working 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 Smiths 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.

249
Chapter 5
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 Collection Files
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.
250

Chapter 5
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 for Payment 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 Collection File 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 customers 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.

251
Chapter 5
252

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. This chapter contains the following sections:
Section
Page
Simulation Overview Steps in the Simulation Process Simulation Concepts
255 257 259
Chapter 6
Price and Simulate - Simulation Process and Concepts
254

Chapter 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
Simulation Components
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.

255
Chapter 6
Simulation Window
The following illustration is an example of the Simulation window after you create your product and price plan from the Elements tab.
Added product
Added price plan
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.
256

Chapter 6
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 the Simulation 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.

257
Chapter 6
258

Chapter 6
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

259
Chapter 6
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 Customer Profiles
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 Item Parameters
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 of Chargeable 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
260

Chapter 6
Chargeable Item Property 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 Distribution Properties
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 users understanding of the usage to be simulated. The following table provides more information:
If you have No statistical data to describe the usage that you want to simulate Statistical data
then Use constant values Choose the distribution type that is best adapted to the format in which your data is presented
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.

261
Chapter 6
A uniform distribution of values describes a range of n values with the same probability (p=1/n) of occurring.
Uniform distribution
Gaussian Lognormal Distribution
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
Customized Distribution 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
262

Chapter 6
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.

263
Chapter 6
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 Customer Profiles
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 Real Customer 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 Profile Regenerated 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 Traffic File 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.
264

Chapter 6
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 of Parameters
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 elements variability on the estimated income results.
Analyzing Sources of Revenues
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.

265
Chapter 6
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.
Applicable Parameters
The following table presents the simulation parameters to be applied for your simulation:
Parameter Simulation duration Number of iterations Number of customers Usage profile Number of telephone call occurrences Telephone call duration % of national prefix occurrences % of international prefix occurrences
Value 1 month 100 10 1 individual Between 2 and 4; period = day Average = 5; standard deviation = 2 Measured in time units of mins/secs 90 10
266

Chapter 6
In order to carry out further simulations, you can modify all of these parameters in the simulator at any time.
Modelled Customer Profile Simulation Results 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.

267
Chapter 6
268

Index
A
abbreviations 11 Access 129 Access chronology 129 Account Balance Management 113 Account Holder 178 account manager ARP user role 217 Accounts blocking 182 creating 181 types 180 unblocking 182 accounts 115 Accounts Payable 216 in Highdeal Transactive 181, 214 Accounts Receivable 216 in Highdeal Transactive 181, 214 Accounts Receivable & Payable 17, 211 acronym 213 module 17, 213 Accounts Recievable & Payable managing 213 Activation status 99 Active 117 Advance payments 229 agent 43 Aging 234 Aging Report report type 236 Aging Report configuration aging steps 236 creating new 235 effective date 236 filter criteria 236 Invoice information 236 name of the report 236 possible actions 235 running, modifying, deleting 239 storing 239 zero-balance Accounts 236 Aging Reports 234 A/P 234 A/R 234 configuration 235 detailed 237 differences 234 overview 234 storing 239 summary 237 viewing 240 Aging steps characteristics 241 default 241 rules 241 Alerts 116, 119 All Objects Catalogue Directory 34 American tax system 192 AML Reports 198 AML template for Invoices/Settlement Reports 216 ARP acronym 213 ARP module common features between A/R and A/P 214 interfaces 216 role of 216 user roles 217 ARP processes international use 217 ARP user interfaces 217 ARP user role account manager 217 financial administrator 217
B
Bad debt 251 write off Call for Payment 251 write off Collection File 251 Balance 116 balance 75 Balance Management 21 balances 115 BART 18 Bill, Settle & Report 17 Blocked 117 Bulk Operations 26
Bulk operations modifying payment information Bulk Processes 26
225
C
Calculation 59 Call for Payment 220, 244 date 220 deleting 222 elements of 222 features 222 generation settings 223 write off as bad debt 251 Call for Payment generation Manual 223 Scheduled 223 Synchronized 223 Catalogue 34 directory named All Objects 34 categories of customers dunning steps 245 Charge type 99 Dependent 99 Master 99 Chargeable Item 47 properties 48 Chargeable Items 260 default properties of 48 user properties 48 Charges 53 Dependent 59 main characteristics 99 Master 57 optional status example 100 role and level (example) 100 secondary characteristics 99 versions, accessing and deleting 56 Charges used characteristics of 99 Charging Components 72 Charging Plan Components 72 Components Overview 72 Charging Plans icon 69 Charging Tree 70 charging tree 72 Closed 117 code tax code 193
Collection File 244, 248 update example 250 update using bulk operation 250 Working View 249 write off as bad debt 251 Collection grace period 221 Collection Process 248 Collection File 248 example 249 launching 248 Collections and Dunning 244 process 244 Collections Manager 244 commitments 224 Comparison components overview 67 types 67 Concurrent Services 77 contacting Customer Support Services 8 correcting transactions 201 correction process rerating 203 cost entry 255 Costs in simulation process 257 Counter Reservation 77 Counters 99 Persistent 81 Transient 81 Creating Subscriber Accounts 115 Credit Control 77 Credit Limit Balances 119 CSR 229 Customer Profile 255 Customer Service Representatives (CSRs) 229 customized distribution 262 Cycle 185
D
Days until payment due 221 debt 244 Default aging steps 241 Default Charging 115 Default Payment Terms Payment Terms default 227 Definition of 180 Delay before Call for Payment 220 Dependent Charge 59 discount rule 194
270

discounts characteristics of 195 Invoice/Settlement Reports 194 types of 195 Dispute File 208 Dispute Memo 208 Disputes bulk operations 208 managing 207 overview 207 view 207 distribution customized 262 lognormal 262 types 261 uniform 261 Dunning plan 244, 245 Dunning settings 246 Dunning rule 244, 246 Activation threshold 246 Dunning plan reference 246 Escalation Threshold 246 Payer category 246 Dunning settings 246 Dunning step 245 Dunning steps 244
Highdeal 275 HTML report 199
I
interest on arrears 223 International use (ARP) 217 Invoice date 220 Invoice generation XML document 216 Invoice/Settlement Report Discounts applying 196 characteristics 194 example 196 Invoice/Settlement Reports discounts 194 numbering pool 216 Invoices/Settlement Reports AML template 216 default cycle 216 Isolated Invoices 187
L
Locked 117 lognormal distribution 262
E
Empty Limit 116 European tax system 192 Example 247 expiration schedule 117 EZTax Connector 19
M
Macros Pricing 84 mapping of charging references 114 Master Charge 57 Mode 21, 59 Modelled Customer Profile 260 multi-valued property 68
F
financial administrator ARP user role 217
G
Graphical User Interface, types
N
16
Net 10 example 227 Net 30 example 227 Net EOM 226 Net EOM 10 example 227 Net Payment Terms 226
Highdeal Transactive R4.1 (Bill and Full) (Bill and Full)
H
hierarchy 179 party roles within
179
271
Net payment terms defined 226 examples 227
221
O
Offers versions, accessing and deleting 108 one-shot discount 195 example of 195 one-shot discounts 195 Operators 68 types 68 optional status example 100 overdue payments 245 Owner 43
P
Parameters 99 Partial payments 229 Party Rating Context 178 relationships in hierarchy 179 roles 179 Sponsor 43 types of 178 Payment collection date 221 Payment due date 221 Payment entry 229 process 230 payment entry 229 CSRs 229 Payment information bulk operations 225 payment information 225 payment methods international differences 217 Payment Processing 220 diagram 221 overview 220 terminology 220 terms and definitions 220 terms defined 220 Payment reconcilation defining rules 231 Payment reconciliation 231 manual 231 payment reconciliation 221
Payment Settings personalizing 225 Payment term creating your own 228 Payment Terms defining 227 international differences 217 Payment terms managing 226 Payments advance 229 partial 229 Perimeter 31 Postpaid Account Links 118 Postpaid Account Partition Groups Postpaid Accounts 180 Postrating 75 Prepaid Accounts 116 Prerating 75, 185 Price & Rate 16 Price & Simulate 17, 255 Price Plan 67 components 67 Rating Context 74 Rating Tree 65 Price Plans 17, 64, 255, 257 icon 64 Pricing functions 68 Pricing Macro 67 Pricing Macros 84 and Price Plans 84 characteristics 84 icon 84 Pricing macros 99 Product 260 production process 23 Products 46, 257 icon 46 Profile Modelled Customer 260 Real Customer 264 properties Chargeable Item 48
183
R
Radius Server Customization Rates 67 activation 67 types of 67 usage examples 67 Rating Context 74
19
272

rating engine process 23 rating tree 64, 67 Real Customer Profile 264 characteristics of 264 creation of 264 rebate 195 example of 195 rebates 195 recharging constraints and tips 205 References Components 72 rerating constraints and tips 205 correction process example 203 Rescheduling a Call for Payment 223 Reset 119 Role 100
Subscriptions 123 customizing functions 129 versions, accessing and deleting
136
T
taxes American tax system 192 calculation process 193 choosing a system 192 European tax system 192 external calculation 192 internal calculation 192 tax code 193 tax rate 192 tax type 193 transactions correctiion process example correcting 201 correcting (constraints) 205 Transactive SNMP Agent 19 Translation Tables 99 Trigger 59
203
S
Service Provider 178 Session-based Rating 77 Setting Up Subscriber Accounts 115 Setting Up the Charging Mapping of Charges
135
Shared Plans 141 shared plans commission example 149 introduction to 141 overview 142 simulation 255 simulation process 255 steps in 257 SNMP 19 Splitters 68 Sponsor 43 State of a Prepaid Account 117 Stateful 21 Stateless 21 Subscriber Accounts Creating and Setting Up 115 Overview 114
U
uniform distribution 261 usage distribution properties usage traffic XML file 264 user roles ARP module 217
261
V
Value Added Reseller (VAR) Value Chain 41
43
W
Web Customer Care 18 Web Services 18 Working View Collection File 249
X
XML file
216
Highdeal Transactive R4.1 (Bill and Full) (Bill and Full)

273
documentation@highdeal.com
Highdeal Inc. North American Headquarters 286 Madison Avenue, Suite 502 New York, NY 10017 USA Phone: +1 (212) 419 0760 Fax: +1 (917) 591 0552 sales.us@highdeal.com
Highdeal S.A. EMEA Headquarters 11, avenue Delcass 75008 Paris France Phone: +33 (0)1 53 05 41 41 Fax: +33 (0)1 53 05 41 42 sales.fr@highdeal.com sales.uk@highdeal.com
www.highdeal.com

11cref Us - Concepts Guide (Bill and Full) - R41

Transféré par

Informations du document

Description originale:

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

11cref Us - Concepts Guide (Bill and Full) - R41

Transféré par

Droits d'auteur :

Formats disponibles

Highdeal Transactive R4.

1 (Bill and Full)

Concept Guide Edition 1

Highdeal Transactive Overview .................................................13

Price and Rate and Balance Management Concepts - Products,

Copyright 2008 Highdeal

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

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

Concept Guide (Edition 1)

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

Highdeal Transactive R4.1 (Bill and Full)

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

Concept Guide (Edition 1)

Accounts Receivable & Payable Concepts ...............................211

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

Highdeal Transactive R4.1 (Bill and Full)

Concept Guide (Edition 1)

About the Highdeal Transactive Concepts Guide

Readers Guide Documentation Overview Conventions

Copyright 2008 Highdeal

About the Highdeal Transactive Concepts Guide

Concept Guide (Edition 1)

About the Highdeal Transactive Concepts Guide

Purpose of this Guide

The chapters in this guide are presented as follows:

Chapter 1 Chapter 2 Chapter 3

Highdeal Transactive R4.1 (Bill and Full)

About the Highdeal Transactive Concepts Guide

Chapter 4 Chapter 5 Chapter 6

Concept Guide (Edition 1)

About the Highdeal Transactive Concepts Guide

Highdeal Transactive R4.1 (Bill and Full)

About the Highdeal Transactive Concepts Guide

Core Documentation Set

Concept Guide (Edition 1)

About the Highdeal Transactive Concepts Guide

Concept Guide (*)

Highdeal Transactive Desktop Tool Online Help

Highdeal Transactive Price and Simulate Online Help

Web Customer Care Online Help

ARP Web Interface Online Help

Payments and Calls for Payment Payment lines Aging reports

This sub-set includes all the necessary documentations for managing:

Highdeal Transactive R4.1 (Bill and Full)

About the Highdeal Transactive Concepts Guide

It includes the following:

Administration & Maintenance Guide

Highdeal Transactive Tuning Guidelines (*)

Oracle Tuning Guidelines (*)

Concept Guide (Edition 1)

About the Highdeal Transactive Concepts Guide

It includes the following:

Technical Reference Guide

APIs Reference (online Javadoc)

AML Reference Guide

Database Structure Reference (online)

Connector Administration Tool Online Help

Highdeal Transactive R4.1 (Bill and Full)

About the Highdeal Transactive Concepts Guide

Documentation BART Reference Guide

Diameter Server Reference Guide

Web Customer Care Reference Guide (*)

Web Services Reference Guide (*)