Intec Singl.eView Billing Fundamentals

Intec Singl.eView Billing Fundamentals: Singl.eview three tier Architecture: Tier1 • Tier 1 is the interface of the ’outside’ world with Convergent Billing. Clients, remote hosts, and external applications enter, inspect, modify data, and initiate processes in Convergent Billing. Tier2 • Tier 2 consists of Convergent Billing’s expression-driven configuration, the Transaction Engine (TRE), and non-TRE Convergent Billing processes. Tier 2 manages transactions initiated from, and returns results to, the first tier, as well as managing all database access. Supported platforms for Convergent Billing are AIX, Solaris, and HP-UX (PA-RISC and IA64). Tier3 • The database tier in Convergent Billing consists of the Oracle database, which stores business, administrative, and configuration data used in Convergent Billing. Singl.eView Configuration Layers: Configuration elements are: • Convergent Billing core software, consisting of key functionality for customer care, rating, billing, and workflow. • Common framework processes, interfaces, and subsystems, consisting of a set of predefined solutions for common configuration requirements. • Market-specific solutions and preconfigured product sets, consisting of configuration that is common to a specific set of products or solution. • Client-specific business rules, consisting of a collection of billing rules that the service provider configures to align customer care and billing processing to reflect their own business requirements. Rating and Billing Overview: Rating and billing is divided into seven operations: • Balance management, which provides event authorization, advice of charge information, and customer credit reservations. • Event normalization, in which input event and transaction data is converted into a standard format for storage in the Convergent Billing database. • Event rating, in which the normalized event records are aggregated and rated (costed) by applying the appropriate tariffs. • Event output, in which the costed event records are stored in the Convergent Billing database. • Billing, in which the costed event records are aggregated, and additional charges and discounts can be applied (for example, for recurring events). • Invoicing, in which billing data is combined with customer detail records and incorporated into an invoice or statement image. • Invoice output, in which invoice and statement images are printed or converted for electronic distribution. The seven operations are carried out by the following three major components: • The trerate TRE server, which authorizes real-time events, handles credit checking, and passes completed events on to the rating engine to be stored in the database. • The rating engine, which combines normalization and rating. The rating engine is a series of pipelined processes, which primarily communicate using shared memory. Rating input is raw call (or ’event’) records; output is database records containing normalized events and charges rated against the events (costed events). • The billing engine, which passes information back to the rating engine for the generation of recurring charges and adjustments, calculates billing charges, generates invoice data, and creates the invoice images for printing. Billing operations include the selection, sorting, and output of invoices or statements to printers or other output devices. TRE Overview and Functionality: The Transaction Engine (TRE) forms the core of the application tier of the open, three-tier architecture of Convergent Billing that is based on Tuxedo middleware. The TRE provides: • Transaction management • Cache management • Connection authentication • Multiple client access • Asynchronous alerts • Comprehensive set of business services and functions (exposed using APIs). Convergent Billing Interfaces : Convergent Billing is able to interface in multiple ways with multiple external systems, including the following: • Siebel • Oracle Financials • SAP • Clarify • PeopleSoft • Various network switches in batch and real-time modes. Convergent Billing Data Model : The Convergent Billing data model has the following points: • Entity relationships are determined dynamically through the configured business rules. • Historical information is maintained for all entities (through the use of date ranging). • Interpretation of data in generic table columns is dependent upon configuration. The main database entities in the Convergent Billing data model are: • Accounts • Contacts • Customers • Payments • Products • Queries. Customizing Convergent Billing : • Reference Types Reference types are defined lists of items, and are referenced throughout Convergent Billing; many of the drop-down lists available on the customer care forms are defined as reference types. Reference types are associated with attribute types to include drop-down lists in new and customized fields. • Attribute Types Attribute types are the major building blocks for entity validation and define the attributes of a field. It overrides the field’s existing attributes, allowing the field to be customised. • Entity Validation Entity validation is the key to extensively configuring the customer care environment. Entity validation is used to customize and add fields to customer care forms, and add validation. Both attribute types and reference types are used in the definition of entity validation. • Derived Attributes Derived attribute variables return one or more values based either on an expression or a lookup of a table defined within the derived attribute. Derived attribute variables and derived attribute tables allow service providers to capture and store their business rules in a tabular format. Derived attributes are variables derived from one or more other variables, by using: • Simple expressions • Conditional evaluation (similar to functions) • Lists (tables) • Table look-ups. Product Data Model : 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. • Service A product must have at least one service. For example, a wire line or wireless telephony product might offer one or more different service types including voice or fax. • 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. • Product Groups Products can be grouped to allow an operator to locate related products more easily when assigning products to customers. • 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. 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. 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. • 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). Batch Rating Engine : Steps Used by Rating Engine The basic steps of input, normalizing, rating, and output are used by the rating engine and outlined in the following steps. • Normalising Before Convergent Billing can rate events, incoming events must first be normalised. Normalising converts an event to the Convergent Billing native event format and is executed by the Event Normalisation (ENM) process. The normalisation process validates the record, verifies its accuracy, and formats it for rating. Convergent Billing provides a mapping language called DIL (Data Interface Language) that allows event data in any incoming format to be mapped and converted into Convergent Billing normalised events. DIL can handle the mapping of events in both ASCII and binary formats. • Rating During rating, chargeable elements are used by the Event Rating (ERT) process to determine the tariff to be applied and calculated to derive an event charge. Output • After charges are generated by the ERT, the Event Rating (ERO) process takes and outputs the charges and associated normalised events from the event cache. Rating Processes There are basically five billing components that execute the rating functions in Singl.eView. They are as below: • Event Rating Broker (BKR) process • Event Normalisation (ENM) process • Event Rating (ERT) process • Event Rating Output (ERO) process • TRE Rating Server (trerate).

Big Data Learn Step by Step

https://www.mltut.com/how-to-learn-big-data-step-by-step/