It uses a three-tier architecture, which provides the system with the ability to adapt to the changing business needs

of clients. 1 Tier 1 Interface 2 3 Tier 2 Application Tier 3 Database

Customer Data Model

A customer is a person or organization that uses, or intends to use, one or more of an organizations products. In Convergent Billing, the customer is the centre of all relationships with other entities. Each customer component or entity is defined or configured using the Convergent Billing client GUI. The Customer Hierarchy form can be used for an overview of customer. The Convergent Billing data model for the customer is displayed in the below Figure

Entities that comprise the customer data model are described in the following sections.

Accounts
Each customer must have one primary account, the invoice account, which is the account to which invoiced amounts, payments, and adjustments are posted. If the customer is part of a customer hierarchy, each customer node is identified as an invoice, statement, or no reporting node. Each customer has a defined preferred currency that is used to choose the default display currency for financial information. Additional accounts, referred to as secondary accounts, may also be assigned to customers, depending on their requirements. Examples of secondary accounts include: Deposit accounts, for recording customer deposits held Loyalty accounts, for recording loyalty or frequent user points. Each account has an account type that defines the different types of accounts to which charges are applied. The account type defines whether the account is an asset or a liability, its currency, and the aging criteria. Note: Account types are used in the definition of other elements in Convergent Billing, including charge categories, payment types, adjustment types, and customer types. Table: Account

Billing Details
Multiple invoice formats of a customers billing data allow targeting specific information to the invoice recipient. Billing details include a bill run suppression flag, bill cycle configuration, and status of each bill run. Table: CUSTOMER_NODE_BILL_RUN, INVOICE, CUSTOMER_NODE_HISTORY

Contacts
Details about any person or organization that may need to be contacted during the normal course of business can be recorded. Contact details are stored in person records. Table PERSON_HISTORY, ADDRESS_HISTORY

Contracts
A contract is a legal agreement between a customer and the organization. The agreement specifies terms and conditions for products and services purchased by the customer, over a specified period. Contracts can either be applied to an individual service or applied to all of the qualifying services on a customer node. A service qualifies for a contract if it meets the criteria that are defined by the contract type. A contract type defines the category under which a contract is recorded, and determines the products and companion products used for the contract. Contract types can also be used to define various default values (for example, duration, grace periods, account manager, or the renegotiation period).

Customer Hierarchy
In a business environment, there may be relationships between a head office and several branch offices that need to be reflected in Convergent Billing. Relationships can be displayed in a customer hierarchy where the head office is the parent customer, and all of the branch offices are child customers. Child customers can also be parent customers for further child customers. The Convergent Billing customer hierarchy functionality allows the creation of a billing structure that reflects the organizational structure of a customer. A customer hierarchy enables multiple billing or reporting points. For each point or level in the hierarchy, the customer can decide which level receives an invoice or statement (or neither). A customers hierarchy is graphically represented using the Customer Hierarchy form. Note: Not applicable for Talk Talk.

Customer Type
A customer can have only one customer type. The choice of customer type affects what data needs to be captured for the customer. Defaults, information capture, data entry rules, and business rules are all configured by customer type. Example customer types are Residential and Small/Medium Business. CUSTOMER_NODE_TYPE_ID 9000073 9000075 9000076 9000077 9000078 CUSTOMER_NODE_TYPE_NAME Residential Corporate Employee Supplier Affiliate

Table CUSTOMER_NODE_TYPE

Invoice Format
Different service providers may have several different invoice layout designs, each for different customer requirements. The selection and sequence of data may be different for each invoice format. Table: INVOICE_FORMAT, INVOICE_FORMAT_HISTORY, CUSTOMER_NODE_INV_FORMAT

Lists
Lists of information, defined using derived attribute tables can be maintained for any aspect of a customer relationship (for example, invoice media).
select * from derived_attribute_history where lower(description) like '%invoice%option%' and sysdate between EFFECTIVE_START_DATE and EFFECTIVE_END_DATE select REFERENCE_TYPE_ID,TYPE_LABEL,DESCRIPTION from reference_type where reference_type_id IN (9000175,9000176)
REFERENCE_TYPE_ID 9000175 9000176 TYPE_LABEL CPW_INV_MEDIA CPW_INV_LAYOUT DESCRIPTION How the invoice is to be delivered How the invoice is presented

select reference_code, abbreviation from reference_code where reference_type_id = 9000175

REFERENCE_CODE 101 102 ABBREVIATION Paper Email

select a.ACCOUNT_NAME, rc.ABBREVIATION, cnda.effective_start_date, cnda.effective_end_date from customer_node_da_array cnda, account a, reference_code rc where a.ACCOUNT_NAME = '1000008805' and cnda.customer_node_id = a.CUSTOMER_NODE_ID and sysdate between cnda.effective_start_date and cnda.effective_end_date and cnda.derived_attribute_id = 9000098 and rc.reference_type_id = 9000175 and rc.reference_code = cnda.result1_value

Products
When a customer is created, the operator assigns products to that customer. More details can be found in later section.

Queries
Customer queries are used to record a diverse range of activities. The query subsystem in convergent Billing performs the roles of a notation system and an activity tracking system. There are no limits to the number of customer queries that can be created for a customer.

Product Data Model

The Convergent Billing product data model represents a product as a set of component definitions that, collectively, form the framework for a product. Figure below displays Convergent Billing classes in a base product instance using UML notation.

Each product definition component is defined or configured using the Convergent Billing client GUI. Convergent Billing provides a set of comprehensive facilities and features for the quick and easy definition of all components required for both the following base and companion product definitions: Base product, which is a combination of service types, equipment types, tariffs, subtotals, facility groups, and derived attributes required to deliver a competitive product offering. A product is the only entity sold to a customer. Companion product, which is a product used to add tariffs, subtotals, and derived attributes to an existing base product. Companion products allow an alternative costing regime to be applied to an existing product. A companion product cannot exist in isolation; it must be associated with an existing base product. The TalkTalk Package is implemented as a Base Product with a number of Services and Companion Products as shown in Figure 1. The quantity of components permitted is indicated by the numbers in the diagram and will be enforced by Singl.eView.

Guide Points
To be added subject to Change Request

service Mobile CLI

0.. 5

service Base Service

0..* 1

companion product Supplementary Service

Features

service Fixed Line CLI

base product Talk Talk

0.. 1

0..*

companion product Discount

Options
0.. 1 0..*

service IPTV CPWN ID

companion product Bundle

companion product Wholesale Line Rental

0.. 1

0.. 1

0.. 1

0..*

companion product Talk Talk Mobile

0..1

0.. 1

companion product Carrier Pre-select

companion product Broadband

companion product IPTV

Figure 1 TalkTalk Product Model

Talk Talk Products

select product_id, product_name, companion_ind_code from product_history where sysdate between effective_start_date and effective_end_date PRODUCT_ID 9000094 9000095 9000097 9000098 9000101 9000102 9000103 9000166 22240043 PRODUCT_NAME TalkTalk BB CPS TTM Supplementary Service Discount Bundle WLR IPTV COMPANION_IND_CODE 0 1 1 1 1 1 1 1 1

The Base Product shall be configured as follows: 1. 2. The Product name is TalkTalk. As a minimum it will have a single Service. 1. 2. 3. Its Service Type shall be Base Service. The TalkTalk Package may have a number of other Services.

Either zero or more Fixed Line CLI Service Type

4. A number of Companion Products may be added to the Base Product instance. The permitted quantities are shown in Figure 1. The Companions represent the TalkTalk Products, and their associated Discounts, Bundles and Supplementary Services. 5. All Companions are compatible with each other.

Product Model Entities

Entities that comprise the product data model are described in the following sections.

Equipment
A product may have one or more pieces of equipment. Equipment can be a physical piece of equipment (for example, a telephone) or conceptual (for example, a telephone number). Equipment can be reused for allocation to multiple services. N/A for Talk Talk.

Service
A product must have at least one service. For example, a wireline or wireless telephony product might offer one or more different service types including voice or fax. A service might have one or more pieces of equipment.
select pst.PRODUCT_ID, ph.PRODUCT_NAME, st.SERVICE_TYPE_ID, st.SERVICE_TYPE_NAME from product_service_type pst, service_type st, product_history ph where sysdate between pst.effective_start_date and pst.effective_end_date and pst.SERVICE_TYPE_ID = st.SERVICE_TYPE_ID and ph.PRODUCT_ID = pst.PRODUCT_ID and sysdate between ph.effective_start_date and ph.effective_end_date
PRODUCT_ID 9000095 9000095 9000103 9000103 9000097 9000097 9000102 9000102 22240043 22240043 9000101 9000101 9000098 9000098 9000094 9000094 9000094 9000094 PRODUCT_NAME BB BB Bundle Bundle CPS CPS Discount Discount IPTV IPTV Supplementary Service Supplementary Service TTM TTM TalkTalk TalkTalk TalkTalk TalkTalk SERVICE_TYPE_ID 9000105 9000106 9000105 9000106 9000105 9000106 9000105 9000106 9000105 22240024 9000105 9000106 9000107 9000105 9000105 9000106 9000107 22240024 SERVICE_TYPE_NAME Base Service Fixed Line CLI Base Service Fixed Line CLI Base Service Fixed Line CLI Base Service Fixed Line CLI Base Service IPTV Base Service Fixed Line CLI Mobile CLI Base Service Base Service Fixed Line CLI Mobile CLI IPTV

9000166 9000166

WLR WLR

9000105 9000106

Base Service Fixed Line CLI

Base Service
The Base Service shall be created automatically on creation of the Package (i.e. TalkTalk Base Product). It will be the first Service of the Base Product and must exist for the lifetime of the Product. The Service Name of the Base Service has the following properties: It must be unique amongst all Services. It cannot be updated.

Fixed Line CLI

The Fixed Line CLI Service shall be added automatically depending on the following Companion Products: Wholesale Line Rental; or, Carrier Pre-select.

IPTV
The IPTV Service (TVOD) shall be added automatically depending on the IPTV Companion Product

Facility Groups
A facility group is a collection of one or more service options (also referred to as facilities, features, supplementary services, or value-add services). The group is associated with a specified service and defined as part of a product. A facility group must contain at least one facility, and can also contain details of compatible facility groups.

Product Groups
Products can be grouped to allow an operator to locate related products more easily when assigning products to customers. A product group simply defines the products displayed as a group to an operator and appears on a separate tab on the Customer Hierarchy form.

Costing Components
Additional entities are required to calculate a products charges. Costing components include: Tariffs, which specify charges for the product (and the rules for applying them). Charge categories, which define the account types and GL codes to which charges are posted. Charge categories are specified as part of the tariff definition. Subtotals, which define variables that aggregate (total) values stored for subsequent use. Payment items, which are expressions to generate charges when the product is sold to a customer.

Tariffs

Tariffs specify the charges and benefits applied to events, and the rules for applying them, to calculate cost information for inclusion on an invoice or statement. The term tariff is typically used to mean any calculation applied to an event that results in cost information (charges or benefits). Tariffs can be used to determine: Whether to apply a charge Amount of the charge Allocation of the charge to the appropriate accounts and GL codes. Tariffs can also be used to generate events (for example, rental events). Because tariffs can result in both positive and negative values being billed to a customer, the following terms are used to differentiate between the different types of tariffs: Usage tariff, which calculates the charges owed by a customer for use of services, equipment, and facilities. Discount tariff, which reduces the amount owed by a customer. Recurring tariff, which calculates a recurring charge, such as a rental. Tax tariff, which calculates the amount of tax paid to a government department. Comparative tariff, calculates the amount a customer would have had to pay if they had been using an alternative rating program, such as a special volume user program or a competitors product. Tariff definitions include: Basic properties (depending on the tariff type) The tariffs charge expression The structure of an optional tariff table, in which values for the conditions and charges are entered into the tariff table. The process for calculating a tariff is displayed in below Figure.

Charge Categories A charge category identifies the default account type and general ledger (GL) code to which a calculated tariff charge or benefit is allocated. For services, the charge category also identifies a specific account number. The association between a tariff and a charge category is specified when the tariff is defined, and is referred to as the tariff/charge category pair. When the rating or billing engine processes an event, it looks up the details of the event for the customer node. The rating or billing engine then identifies the applicable tariffs for calculating the value of each charge or benefit, and uses the appropriate charge category instance to identify the account and optional GL code. The rating and billing engines guide charges based solely on the charge category instances for customers and services or the tariff override expressions. By default, the charge category associated with a tariff is used each time that tariff is used. Tariff override expressions, if specified, can bypass charge category guiding. A charge record in the CHARGE table consists of charge category instance information and tariff charge calculations and override expressions.

Charge categories allow guiding to a To account, From account, To GL code, and From GL code. The account type specified in a charge category definition is translated to the actual account number and stored in the charge category instance (which is created when the product instance is created). Charge category overrides are only processed when creating charge category instances. Charge categories instances can be modified and split for individual customers and services. Subtotals A subtotal contains calculated values (such as aggregated cost totals) that are stored and subsequently used as variables in the rating (and billing) process. A subtotal defines one or more subtotal terms that are aggregated using the method specified by the associated aggregation function. Individual costed data records (billing data) often need to be aggregated so that totals for a particular service, customer node, or customer can be displayed on the customers invoice. In large organizations, several levels of aggregation may be required to give a full breakdown of the total charges into charges for specific departments or specific types of service. Event and charge details also need to be aggregated so that accurate calculations can be made for real-time services. Credit monitoring of post-paid customers requires real-time access to the

customers account information, including the account balance, unbilled usage amounts, and credit limit.

PRODUC T_NAME

DEFAULT _INVOICE _TXT

BILLABLE _IND_CO DE

CHARGE_CATEGORY _NAME

BB BB BB BB

MRC Charge Wholesale Product Charge Wrapped Connectio n Discount Itemised Connectio n Discount

0 0 0 1

GL Deferred GL Deferred GL Reportable GL Reportable

BB

Connectio n Charge

GL Reportable

BB BB

Connectio n Charge MRC Charge

1 1

Non-GL Reportable GL Deferred

BB

Cancellati on Charge

GL Reportable

DESCRIPTION This tariff generates MRC events for TT products, and rate the events for Wrapped mode for GL extract. Generates wholesale recurring charge for each product Rates the wrapped discount charges for a package Rates the itemised connection discount charges for a package Generates an event with details of connection charge and all applicable discounts. Creates nonbillable charges for the connection fees. Calculates the final wrapped charge based on the unbilled charges created from the other connection tariffs Rates itemised recurring charges Generates an event with details of a disconnection charge. Creates a billable charge for the disconnection fee.