Business Case

  • November 2019
  • PDF

This document was uploaded by user and they confirmed that they have the permission to share it. If you are author or own the copyright of this book, please report to us by using this DMCA report form. Report DMCA


Overview

Download & View Business Case as PDF for free.

More details

  • Words: 4,409
  • Pages: 27
ODS – Requirements Definition

INDEX 1.Purpose of the Document.................................................................................3 2.Business Case...................................................................................................3 3.Operational Data Store Functional Requirements.........................................4 3.1.Data Synchronization ...................................................................................4 3.2.Reporting.......................................................................................................5 3.3.Key Performance Indicators (KPI) Tracking..................................................5 3.4.Business Rules and Triggers........................................................................5 3.5.Intelligence Reinserts....................................................................................5 3.6.De-duplication ..............................................................................................6 3.7.House-Holding...............................................................................................6 3.8.Ad Hoc/Miscellaneous...................................................................................6 4.Business Requirements....................................................................................6 4.1.ODS Information Requirements....................................................................6 4.2. Data Synchronization...................................................................................8 4.3.Reporting.......................................................................................................9 4.4.Business Rules and Triggers......................................................................10 4.5.Key Performance Indicators Dashboards...................................................10 4.6.Ad Hoc/Miscellaneous.................................................................................11 5.Source Analysis & Data Requirements.........................................................14 5.1.Master Data Requirements.........................................................................14 5.2.Exchanged Data..........................................................................................24 5.3.Data Not Exchanged...................................................................................24 Customer Account Balance & Unbilled Information.......................................24 Invoice Details.....................................................................................................24 Inventory..............................................................................................................26 Prepaid Customer details...................................................................................26 Appendix 1...........................................................................................................26 1.1.1.Operational...............................................................................................26

1. Purpose of the Document The purpose of the document is to present business requirements for ODS implementation in Abc Inc. 2. Business Case Abc Inc has grown at a scorching pace since its inception. Company has implemented and stabilized its business over this growth period. Operational systems and Decision Support System were implemented to support the wireless and wire-line business and tightly integrate OSS- BSS operations. Appendix 1 details the current architecture. The customer base, product/service offerings and sales and service network is expanding steadily with network services reaching over 5000 cities across India in phase II of expansion that is targeted to be complete by the end of this fiscal year. The increasing complexity of business, brought about by growth in all aspects of business and specific constraints of conducting business in India where personal identification using SSN (as in US) and services like Equifax for credit rating check do not exist, pose great challenges. The business activity needs real time observation, detection and action on exceptions. The dynamic nature of business, in high growth phase of telecom market in India, demands ability to respond to events in near real time. This ability is the business differentiator from competition in terms of customer service as well as protection from revenue leakage and prospective fraud. Abc Inc needs following to become the company that ‘follows the Customer’ rather than a company that is ‘chased by Customer’: 1. Ensuring vital, relevant, and timely information is available to the right people at the right time in form of reports and real-time dashboards. 2. Creating an ‘always-on ‘ business rules engine that captures process drift and corrects it or assigns correction responsibility by providing required input to relevant owners of process. 3. Effectively leveraging existing infrastructure and extending the value of operational systems

Process Drift is the inability of defined business processes to serve customers during their entire lifecycle association with ABC and prevent fraud/revenue leakage effectively due to non-availability of correct, decentralized, timely, synchronized single view of customer, service, channel and inventory. The near real time business activity monitoring consists of managing following event related activities in Abc Inc. Event Absorption Collection and integration of events from multiple applications Event Processing and Filtering Analyze real-time events in context and business rules Report Irregularity Event Action, Delivery, and Display System Alerts key decision makers Auto-action on defined events 3. Operational Data Store Functional Requirements ODS will be designed and implemented in ABC to prevent process drift by integrating and synchronizing customer related events, on real time basis, occurring in multiple systems engaged in serving various aspects of customer interactions. ODS will serve following by creating a single repository of data from multiple systems: 1. Revenue Assurance 2. Operational Line Managers 3. Back Office Operations 3.1. Data Synchronization ODS will become the single point of synchronization for multiple instances of same data stored in multiple systems. The operational systems, meant for capturing customer events and serving customers, will be notified of the occurrence of de-synchronization of data. Revenue assurance team will regain synchronization by reconciling data amongst the systems on a regular basis. The synchronization process will be formalized by introduction of ODS as an outside sync-check system.

The back-end processes that are a primary cause of de-synchronization of data will also be standardized as ODS team will be a part of all the backend processes happening in operational systems. Non-standard processes of transferring data will need to be standardized to the extent possible so as to make sure that data exchange between systems is defined, in specific format and with defined personnel accountability. 3.2. Reporting ODS leads to creation of single view of business and improving the spread of information availability throughout the organization across all levels with relevant real time and correct information without affecting performance of native systems. Various pre-defined reports will be generated and made available on the web from ODS to keep free flow of information in need to know environment. 3.3. Key Performance Indicators (KPI) Tracking Real time tracking of KPI, up to the minute customer net adds, payment collections, etc., on dashboards that are available on thin client interface to management users and decision makers across the organization in a secure environment will be possible with the ODS reporting architecture. 3.4. Business Rules and Triggers Application of business rules on a real time basis to generate intelligent triggers for action to be performed by process owners and Revenue Assurance. For example, creation of Trouble Ticket (TT) for a customer acquired within past thirty days triggers the revenue assurance team to track the customer closely to make sure that complaint does not result in loss of customers and payments associated with them. 3.5. Intelligence Reinserts Reinserts in native systems is an important way of making the customer facing organization informed and empowered to meet the ‘almost impossible to meet’ demands of customer and also treat each customer as unique keeping track of unique customer related information. Generating intelligence and making it available to customer facing team, based on the analysis of information being received in ODS, leads to richer customer experience. It makes the organization ‘chase the customer’ and not the other way

round. For example, a customer service agent can be informed based on the analysis of the calling pattern and invoice amounts that a customer might be better off with the new plan being launched so that the same calling pattern generates less invoice amount for the customer. This presents cross-selling and Up-selling opportunities.

3.6. De-duplication Same customer existing in multiple instances creates potential problems for the organization. In order to ‘Know the Customer’, de-duplication activity leads to better service to customers and also leads to prevent fraudulent customers from creating multiple instances of fraud that are detected over a period of time. 3.7. House-Holding Householding will be performed on ODS by grouping customers on the basis of their addresses and treating them as a group in order to maximize customer satisfaction with service, improve the effectiveness of marketing campaigns and at the same time reducing cost of campaigns and services. House-holding also leads to ‘know the customer’ for the front sales and service team and increases sensitivity to customer issues to improve the impact of transaction on related customers. 3.8. Ad Hoc/Miscellaneous ODS offers miscellaneous benefits of being able to satisfy the need to analyze customer related data based on unique needs of the business users. In order to support instantaneous information or analysis requirement, the business users need not start a search for data from scratch. A managed ODS production environment will help business to be able to utilize data in the ODS on as-needed basis and also increase scope of data stored in ODS. 4. Business Requirements The following sections define the business requirements for activities of ODS. 4.1. ODS Information Requirements ODS will capture following events and data on real time or with one day latency depending on the business requirement and availability:

Customer Acquisition Customer Name Service Details Multiple Address Details Multiple Service Location Multiple Contact Details Scheme/Handset/Promotion/Discount Details Misc. CAF details including CIOU Corporate Wireless Order Management Order details Order Tracking Details through Clarify/SAP/PG/Clarity/ADC Usage Details CDR Summary Dashboard MACD All Provisioning MACD’s All Non Provisioning MACD’s Billing Latest Invoice Details Customer Account Balance Unbilled Amount Payment Payment Details against invoice Location and User ID Collection Payment Status Collection Errors Adjustment Adjustment details Authorization details Suspend/Terminate/Reactivate Service Status of Customer Handset return status on termination Payment details Reason for Suspend/Termination Fraud Credit Control Data Dunning Actions covered

Customer Service Interaction Trouble Tickets and their status Inventory and Logistics Count at WH/CDC/OTC/Partners Count of Equipment type In transit Inventory Count of Provisioned (Prepaid/Post Paid)/non-provisioned handsets 4.2. Data Synchronization Business needs data de-synchronization status between the following systems: 1. 2. 3. 4. 5.

Clarify ADC PhoneGen HLR SAP

Following data de-synchronization need to be reported: 1. MDN-MIN Mismatch in PhoneGen/ /HLR 2. CAF – MDN – MIN – RSN combination Mismatch in Clarify/PhoneGen/ADC 3. Customer Status (Active/Suspended/Terminated) Mismatch in ADC/PhoneGen/Commverse-IN/Clarify 4. MDN active Status Active in both Commverse-IN and ADC 5. Service Status ILD/NLD Mismatch in Clarify/ADC/PhoneGen/Clarity/HLR 6. Tariff Plan Mismatch in Clarify/ADC/PhoneGen

4.3. Reporting Revenue Assurance CAF – Logged in but not fulfilled CAF-OTAF Gap for Pre-Paid and Post Paid Amount paid and Payable not equal at the time of customer acquisition report Address Verification (AV) Status and its aging Monitor ILD/NLD activation Customer Name changes Report Customer Address change and new AV status Adjustments tracking based on: First 30 days of customer Based on Value Based on User ID and IP address Frequency of Adjustments Daily Customer Acquisition Report By Pre-Paid/Post Paid By OTC/SDCA/Circle/DAKC By Channel Partner (If available) Payment Collection Report By Circle By OTC Voucher Sales to Distributors By Type and Tariff Voucher Reconciliation Voucher issued Vs Vouchers used

Sales Channel Performance By Region By Circle/Dealers/Distributors/OTC Promotion/Sub promotion tracking Corporate Wireless Order Tracking Cross Selling Corporate Customer (Services/Products) report Active post paid customers not paid for last 30-60-90 days Pre Paid usage patterns based on voucher usage Inventory (Un-provisioned/Provisioned – Prepaid/Post Paid) By Warehouse/CDC/Dealer/OTC By Handset Type By City/Location Monitor Customer Payment Check/Card/Cash by town Tracking AV By Agency By Town Tracking additions to following Customer List VIP/Employee/Corporate/Consumer 4.4. Business Rules and Triggers Trouble Tickets generated within 30 days of fulfillment First bill generation Trigger Bills Returned Trigger Customer Address change Trigger Customer Name changes Trigger New Customer tracking in first 30 days TBD More than one payment made in less than 10 days 4.5. Key Performance Indicators Dashboards Net Payment Received Status for the day

By Circle By OTC (Drill-Down) Net Customer Acquisitions for day By Prepaid/Post Paid/FWP Type By DAKC/Circle/OTC By Tariff plan/Handset Type TIBCO Messages Type (Received by ODS) and message status in Target Systems Existing Customer Count By Pre/Post Paid Type By Tariff plan type By Outstanding Bill amount Range By Corporate/Consumer/PCO Fraud Actions Forced Migration To Prepaid Bill Suppression TT/MACD status in different systems TT related provisioning MACD (e.g. ILD activation) status in Clarity/PG/ADC/CLFY (If done on Clarity, provisioning is effective but could then fail in PG or ADC)

4.6. Ad Hoc/Miscellaneous Retrieving individual consumer customer profile on the basis of: MDN MIN RSN Service Status, Billing Status, Tariff Plan details, Contact details, etc. Retrieving individual/corporate customer information on the basis of: GAN CAN BAN MDN MIN RSN

Service Status, Billing Status, Tariff Plan details, Contact details, BAN Details, Service Locations, etc. All retrievals will be linked to OMNIDOCS for referring to the original scanned CAF.

5. Source Analysis & Data Requirements 5.1. Master Data Requirements Each master will have at least code & description attributes. Some of them might have additional attributes. Entity Name

Entity Definition

Source System ADC

ACCOUNT TYPE MASTER

This entity describes type of ledger account in billing system. E.g. ADVANCE A/C HANDSET DEPOSIT A/C INVOICE A/C

ADD PROOF TYPE MASTER

Lookup for proof type for address verification. CLFY Customer is supposed to provide proof of address when acquired or whenever address is changed. E.g. Ration Card Telephone/Electricity Bill Credit Card/Bank Statement Photo Id issued by any institution

ADDRESS TYPE MASTER

Lookup for type of Type Of Address. E.g. 1-Billing 2-Shipping 3-Service 4-Corporate Address 5-Registered Address Also See ADDRESS_MASTER.

CLFY

ADDRESS VERIFICATION STATUS

Lookup for status of address verification process. E.g. Correct, Pending, Wrong

CLFY

ADJUSTMENT STATUS MASTER

Indicates the status of the adjustment. Possible values are: 0 = Entered 1 = Applied 3 = Future Dated.

ADC

ADJUSTMENT TYPE MASTER

Type of adjustment that has been entered. If ADC the adjustment isassociated with a batch, this adjustment type defaults to theadjustment type of the batch.e.g. 100001 - Late Fees Waiver100025 - Misc Credit Notice100024 Misc Debit Note100002 - Non-sufficient funds fee100029 - Transfer from Invoice to Invoice100003 - Transfer from Deposit to Invoice100022 - Transfer from Invoice to DepositRefund DepositTransfer from Suspense AccountDebt Write-offDeposit PrincipleInterest on Deposit Service TaxTax Deduction at Source

BANK BRANCH MASTER

Lookup for different branches of a bank.

BANK MASTER Lookup for Banks. BILL SCHEDULE MASTER Lookup for Bill Schedule (Bill Cycle). BILLING ACCOUNT STATUS MASTER DEFINES STATUS OF THE BILLING ACCOUNT E.g. 1=PROSPECT 2=CREDIT CHECK REQUIRED 3=ACTIVE 4=CANCELLED 5=BLACK-LISTED

SAP SAP ADC

BILLING NODE TYPE MASTER

Lookup for the type of billing account. In ADC ADC it is defined as Billing Priority. At lease one account in hierarchy should be Invoice Node. E.g. 1 = Invoice 2 = Statement 3 = No Reporting.

BUSINESS LINE MASTER

Lookup for category of Business Line. E.g. 1-WIRELESS 2-WIRELINE 3-NETWAY

CLFY

CARD TYPE MASTER

Lookup for the type of credit/debit card.E.g. Credit-VisaCredit-MasterDebit-VisaDebitMasterATM

ODS Admin will define.

CASE CONDITION MASTER

This entity describes condition of the case.

CLFY

CASE FUNCTIONAL AREA

This entity describes functional area related to the case.

CLFY

CASE MEDIUM MASTER

This entity describes how the complaint was CLFY received. E.g. phone, email, fax.

CASE STATUS MASTER

This entity describes status of the case. E.g. Open Closed

CASE SUBTYPE MASTER

This entity describes the sub-type of case. CLFY E.g. ILD activation, Wrong Bill, MDN change etc.

CASE TYPE MASTER

This entity describes the type of case. E.g. Trouble ticket, MACD etc.

CBOC CDC

Lookup for CBOC. SAP Lookup for City Distribution Centers (CDC) of SAP ABC. Lookup for MACD Reason. ODS Admin Facility status change could be initiated by will customer or internal system. define.

CHANGE REASON

CLFY

CLFY

E.g. IDL could be deactivated due to nonpayment of bill. Sample values of Change Reason:

CIOU MASTER CIRCLE MASTER

CITY MASTER CONTACT TYPE MASTER

-No Bill Payment -Credit Limit Over -Dunning -Customer Request Lookup for CIOU that is assigned to serve customers. Lookup for Abc Inc Circles.

CLFY

For prepaid operations each Circle is treated as Service Provider. Lookup for cities. CLFY Lookup for Roles that are assigned to CLFY customer contacts. E.g. 1-Billing & Service Contact 2-Billing Contact 3-Service Contact

CORPORATE HIERARCHY LEVEL

This entity describes information about corporate hierarchy.Currently only Group & Customer Account is identified.e.g.Group AccountCustomer AccountHO-Head OfficeRO- Regional OfficeSO-Sales OfficeBO- Branch Office

ODS Admin will define.

COUNTRY MASTER

Lookup for Countries.

CREDIT RISK CATEGORY MASTER

Lookup for Credit Risk Category. E.g. 1-HIGH 2-MEDIUM 3-LOW (Default)

ODS Admin will define. ODS Admin will define.

CRM CUSTOMER IDENTIFIER MASTER

Lookup for type of customer.

CLFY

Customer type is used for CRM purpose to identify a customer. E.g. Abc Inc Consumer = 1000009 Abc Inc Consumer Advanced = 1000221 Abc Inc Enterprise NA = 1000006 Abc Inc Enterprise RA = 1000008 Abc Inc Enterprise SE = 1000003 Abc Inc PCO Local = 1000010 Abc Inc PCO STD ISD = 1000011 Abc Inc SAX Franchisee = 1000103 Abc Inc Service Provider = 1000012 Abc Inc Corporate Advanced = 1000422 CUG MASTER

Lookup for Closed User Group (CUG).

CURRENCY MASTER

Lookup for Currency.

CUSTOMER CATEGORY MASTER

E.g. INR USD Lookup for Customer Category. Non-Corporate customer is same as individual customer. E.g. Corporate-1 Non Corporate-2

ODS Admin will define. ODS Admin will define.

CUSTOMER STATUS MASTER

Lookup for Status of Customer.

CUSTOMER SUBCATEGORY MASTER

Status is maintained for Customer Account, Billing Account & Service Node. E.g. ACTIVE- 3 CANCELLED-4 BLACK LISTED- 5 Lookup for sub-category of corporate customers. E.g. IndividualPartnership firm Government Department Trust Pvt. Sector Company Public Sector Company

ODS Admin will define.

CLFY

EQUIPMENT STATUS

Lookup for the status of equipment during the ODS life cycle of customer. Admin E.g. will New define. Refurbished Upgrade-New Upgrade-Refurbished Returned Returned Damaged Lost Or Stolen Not Returned

FACILITY MASTER

Lookup for the facilities. A service can be associated with zero, one or many facilities. Facility can be associated with zero or one service. Association between Service & facility is not defined. Two categories of facilities exist. 1.Network 2.Non Network E.g. of facilities. LOCAL (N/W) ICLD( N/W) NLD (N/W) ILD (N/W) ITEMISED_BILLING (Non N/W) Facilities that are turned on or off using STAR feature will not be tacked as they are directly changed at HLR.

PG

ID PROOF TYPE MASTER

Lookup for ID Proof.

CLFY

E.g. PAN Card Passport Ration Card Driving License Voter ID Card INITIATOR SYSTEM

Lookup for ABC Systems. Ee.g. ADC SAP CLFY PG COMM-IN OPS STAR FRAUD

ODS Admin will define.

INVENTORY CATEGORY MASTER

This entity describes category of inventory.

ODS Admin will define.

E.g. 1-Normal Stock 2-Transit Stock 3-Staging Sock 4-Returns Stock MATERIAL CATEGORY CODE

Lookup for category of material. E.g. Prepaid Postpaid

ODS Admin will define.

MATERIAL HOLDER TYPE MASTER

Lookup for type of ABC location. E.g. 1-Warehouse 2-CDC 3-CBOC 4-OTC 5-WW-POS 7-Distributor-POS 8-Dealer-POS 9-Agent-POS 10-Channel Partner-POS 11-DAE-POS

ODS Admin will define.

MATERIAL MASTER

Lookup for the type of equipment/material required for the service.

SAP

In case of CDMA voice handset is required for service. E.g. LG2130

MATERIAL STATUS MASTER

Lookup for Material Status. E.g. Provisioned Non Provisioned General

ODS Admin will define.

MATERIAL TYPE MASTER

Lookup for type of material/equipment. E.g. Handset Voucher

ODS Admin will define.

ORDER LINE STAGE MASTER

Lookup for Order Line Fulfillment Stage. E.g. Fulfilled Bulk Order Request to SAP Pick Process in SAP Create Customer in Clarity Provisioning in PG Lookup for OTC (Code for Counter). Lookup for Category of Payment. E.g. Initial Payment Bill Payment Activation Charge Termination Fee Postpaid to Prepaid Migration

OM

PAYMENT STATUS MASTER

Lookup for status of payment (collection). E.g. Accepted Rejected

ADC

PAYMENT TYPE MASTER

Lookup for type of payment. E.g. Cash Cheque Credit Card Debit Card Direct Debit Electronic Clearance Service DD/Banker's Cheque

ODS Admin will define.

PINCODE MASTER POS

Lookup for PINCODE. Lookup of Point of sell.

CLFY SAP

OTC PAYMENT CATEGORY MASTER

SAP ADC

PRINT STACK MASTER

Lookup for Print Stack. E.g. HARDCOPY = 1 SOFTCOPY = 2 EMAIL = 3 WEB = 4 OTHERS = 5 Currently Print Stack is Hard Coded in Data Exchange.

ADC

PRODUCT MASTER

Lookup for Products sold by ABC. Product consists of multiple services. E.g. RIM (Post paid)- 1000042 FWP- 1000527 TIBCO Keeps ADC code mapping for exchange. Also see SERVICE TYPE MASTER.

CLFY

QUEUE MASTER

This entity describes details about different queues to which cases are assigned.

CLFY

RATE PLAN CHARGE ATTRIBUTES

This entity describes charge attributes associated with rate plan. E.g. Club Charges Monthly Charges Activation Charges Contract Months Recharge Limit (For prepaid voucher) Max call duration (For prepaid voucher)

ADC

RATE PLAN MASTER

Lookup for the Rate Plans of services offered ADC by ABC. E.g. EC145 for Voice, RW-100 for R-Connect Free services might not have any Rate Plan. Rate Plan is same as Tariff Plan for Voice Services, other services offered in product could have different rate plans. In some cases default rate plans for services are attached with main service. e.g. EC149 for Voice Service has default rate pale for RConnect & no rate plan for R-World service. For Customers requiring Rate Plans other than default rate plans MACD is performed to change the rate plan. For corporate customers exchanged XML has tags related to rate plans for different services in Product Array.

RATE PLAN TYPE MASTER

Lookup for Rate Plan Type Code.

ADC

E.g. 1-Tariff Plan (Also known as COS- Class of Service for Prepaid) 2-CUG Rate Plan 3-F&F Rate Plan

REJECTION REASON MASTER

Lookup for payment rejection reason. ADC E.g. 1 Missing signature 2 Inadequate funds 3 Credit limit exceeded 4 Undated cheque 5 Signature not matching 6 Stale or time barred cheque 7 Cheque without branch name/Account no 8 Correction not attested 9 Words-Figures differ 10 Payment stopped by drawer 11 Account closed 12 Post Dated cheque 13 Second signature required 14 Drawer Deceased

SDCA MASTER SERVICE NODE STATE MASTER

Lookup for SDCA. Lookup for the status of Service Node. E.g. Idle Active Inactive Retired Expired Terminated Re-Activated Suspend Also See SERVICE NODE DETAILS.

CLFY ODS Admin will define.

SERVICE TAX STATUS MASTER

Lookup for Service Tax Status. E.g. SERVICE TAX FULL RATE= 1 SERVICE TAX EXEMPT= 2

ODS Admin will define.

SERVICE TYPE MASTER

Invoice Node should have Service Tax Status. Lookup for the type of services offered by ABC. E.g. CDMA VOICE R-World R-Connect LEASED LINE Non-Network

SEVERITY LEVEL MASTER

ODS Admin will define.

Lookup for level of severity of case. E.g. High, Medium, Low. Lookup for different States of a Country. E.g. Maharashtra Gujarat

CLFY

TDS TAX STATUS MASTER

Lookup for TDS TAX Status. E.g. TDS FULL RATE=1 TDS TAX EXEMPT"= 2 TDS TAX RELAXED = 3 Invoice Node should have TDS Tax Status.

ODS Admin will define.

TREATMENT CATEGORY

Lookup for treatment category. E.g. VIP Employee General

ADC

STATE MASTER

CLFY

VOUCHER TYPE MASTER

WAREHOUSE

This entity describes different types of vouchers sold by ABC. E.g. 1-Prepaid voucher 2-ILD Voucher 3-NLD Voucher Lookup for ABC Warehouses.

SAP

SAP

5.2. Exchanged Data 5.3. Data Not Exchanged Customer Account Balance & Unbilled Information Name ACCOUNT ID BILLING ACCOUNT NO CUSTOMER ACCOUNT NO ACCOUNT BALANCE AMOUNT UNBILLED_AMOUNT

BALANCE_DATE CREDIT LIMIT ACCOUNT_ACTION_CODE ACCOUNT_ACTION_DATE PROMO BALANCE AMOUNT PROMO BALANCE EXP DATE LAST_RECHARGE_DATE ACCOUNT_TYPE_ID

Definition Billing Account No. of customer. System generated no. is assigned as BAN for postpaid/prepaid individual customers. System generated customer account no. Total amount that has been rated by the usage based on tariff. This amount + Account balance gives the total amount to be paid by the customer at any point of time. Credit Limit of customer. Default Null. Code that indicates action taken in relation to unbilled amount for an account. Date and time at which the account_action_code was last set or cleared Promotional balance for prepaid customers. Expiry date of promotional balance for prepaid customers. For prepaid customer this field indicates last recharge date. ACCOUNT TYPE IDENTIFIER E.g. ADVANCE A/C HANDSET DEPOSIT A/C

CURRENCY CODE

Invoice Details Name INVOICE NO CUSTOMER ACCOUNT NO BILLING ACCOUNT NO BILL_RUN_ID INVOICE DATE PERIOD FROM DT PERIOD TO DT

Definition Unique identifier that defines a particular customer node invoice. System generated customer account no. Billing Account No. of customer. System generated no. is assigned as BAN for postpaid/prepaid individual customers. Unique identifier of the bill run that generated the account.

Name INVOICE_AMOUNT STATEMENT_AMOUNT

BALANCE_FORWARD ACCOUNT_BALANCE

SUPPRESS_IND_CODE

ORIGINAL_PAYMENT_DUE_DATE PAYMENT_DUE_DATE EARLY_PAYMENT_DATE CURRENT_DUE TOTAL_PAYMENTS

TOTAL_ADJUSTMENTS

EARLY_PAYMENT_DISCOUNT

APPLIED_IND_CODE

LATE_PAYMENT_CHARGE PREVIOUS DEUS MONTHLY CHARGES OTHER PLAN CHARGES ADMIN CHARGES SERVICE CHARGES OIC CHARGES SERVICE TAX TOTAL CHARGES ACCOUNT ID INVOICED_ACCOUNT_ID

Definition Total amount of charges that are associated with the invoice, excluding the balance forward. Total amount of charges that are associated with the statement. This column can only contain a value if INVOICE_AMOUNT is 0. This amount comes for a child customer in case of a corporate customer. Invoice is generated for Corporate Parent, however statement is generated for each of its child Balance on the account prior to the application of the invoice. Account balance after this invoice was generated. Note: This is normally equal to INVOICE_AMOUNT + BALANCE_FORWARD, unless the invoice is a statement associated with an account other than the prime account, in which case it should be equal to STATEMENT_AMOUNT + BALANCE_FORWARD. This flag is set to 1 if this invoice has been marked to be suppressed. This column is set using the Invoice Type expressions. This column is not applicable and cannot be set for statements or Quality Assurance invoices. Date that the invoice was originally due to be paid. Date that the invoice is due to be paid. This is normally the same as ORIGINAL_PAYMENT_DUE_DATE, but can be updated by operators with appropriate security privileges. Date for payment to receive an additional discount. This discount has already been incorporated into the INVOICE_TOTAL. Total payments made on the account between the issuing of the previous invoice and the invoice. The payments are not recorded against the invoice. This amount is usually shown on the invoice, and is calculated by the billing engine. Total adjustments made on the account between the issuing of the previous invoice and this invoice. The adjustments are not recorded against the invoice. This amount is usually shown on the invoice, and is calculated by the billing engine. Early payment discount that applied for the invoice (if any). This is derived by the billing engine (based on the INVOICE_TYPE table), and can be re-derived based on details in the CHARGE table. This amount would have been already incorporated into the INITIAL_DUE calculated for the account. This column is set to 1 (TRUE) when the invoice has been applied to the account by the apply_invoices script as appropriate. Once an invoice has been applied, it cannot be modified in any way (except for flagging it for re-print). Any account corrections must be made using adjustments, which appear on the next invoice run for the customer.

Monthly charge for CUG. Other plan charges for CUG. Administrator Recurring Charges for CUG Service Charges for CUG. Offnet Inter-Operator Charges for CUG.

Unique identifier of the account to which the invoice is applied. Account into which all charges associated with the invoice have been calculated and applied. This column can only contain a value if INVOICE_AMOUNT is 0 and STATEMENT_AMOUNT is not null. If this column is null and STATEMENT_AMOUNT is not null, this record is a statement for an 'Other Account'.

Name IMAGE_GENERATED_IND_CODE

Definition This is the Account Id of Parent of Corporate Customer. This value will come in case this is the record for the child. This column is set to 1 (TRUE) when all invoice images are generated for the invoice, resulting in one or more rows existing in the INVOICE_CONTENTS table for the invoice. This is set by the IGP.

Inventory Name INVENTORY HOLDER MATERIAL CODE MATERIAL CATEGORY CODE MATERIAL QTY INVENTORY DATE ORIGINATOR ID DISPATCH DATE SCHEDULED DELEVIRY DATE NEW REFURBISHED FLAG INVENTORY CATEGORY CODE

Definition Warehouse, CDC, OTC, Channel Partner

Prepaid Customer details From Clarify & Comm-In system Appendix 1 Current Architecture 1.1.1.Operational Current operational architecture consists of following systems in the New Architecture. Earlier architecture having RECON is not considered for the current design. Following components are part of this architecture. − Selectica − Clarity − SAP − Clarify − ADC − Phone Gen − Comverse IN − Portals − TIBCO EAI − SOTAS − Interconnect − Mediation − DSS

WIRELINE APPLICATION ARCHITECTURE

Related Documents

Business Case
May 2020 13
Business Case
November 2019 13
Business Case Outline
June 2020 4