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. Clarify
2. ADC
3. PhoneGen
4. HLR
5. 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
ACCOUNT TYPE MASTER This entity describes type of ledger account ADC
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. CLFY

E.g.
1-Billing
2-Shipping
3-Service
4-Corporate Address
5-Registered Address
Also See ADDRESS_MASTER.

ADDRESS VERIFICATION STATUS Lookup for status of address verification CLFY

process.
E.g. Correct, Pending, Wrong

ADJUSTMENT STATUS MASTER Indicates the status of the adjustment. ADC

Possible values are:
0 = Entered
1 = Applied
3 = Future Dated.
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. SAP

BANK MASTER Lookup for Banks. SAP

BILL SCHEDULE MASTER Lookup for Bill Schedule (Bill Cycle). ADC
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

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

E.g.
1-WIRELESS
2-WIRELINE
3-NETWAY

CARD TYPE MASTER Lookup for the type of credit/debit card.E.g. ODS
Credit-VisaCredit-MasterDebit-VisaDebit- Admin
MasterATM will
define.

CASE CONDITION MASTER This entity describes condition of the case. CLFY

CASE FUNCTIONAL AREA This entity describes functional area related CLFY
to the case.
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. CLFY
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. CLFY
Trouble ticket, MACD etc.

CBOC Lookup for CBOC. SAP

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

E.g. IDL could be deactivated due to non-

payment of bill.

Sample values of Change Reason:

-No Bill Payment

-Credit Limit Over
-Dunning
-Customer Request
CIOU MASTER Lookup for CIOU that is assigned to serve
customers.
CIRCLE MASTER Lookup for Abc Inc Circles. CLFY

For prepaid operations each Circle is treated

as Service Provider.
CITY MASTER Lookup for cities. CLFY
CONTACT TYPE MASTER 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 ODS
corporate hierarchy.Currently only Group & Admin
Customer Account is identified.e.g.Group will
AccountCustomer AccountHO-Head define.
OfficeRO- Regional OfficeSO-Sales
OfficeBO- Branch Office

COUNTRY MASTER Lookup for Countries. ODS

Admin
will
define.
CREDIT RISK CATEGORY MASTER Lookup for Credit Risk Category. ODS
E.g. Admin
1-HIGH will
2-MEDIUM define.
3-LOW (Default)
CRM CUSTOMER IDENTIFIER Lookup for type of customer. CLFY
MASTER

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

Admin
E.g. will
INR define.
USD
CUSTOMER CATEGORY MASTER Lookup for Customer Category. ODS
Admin
Non-Corporate customer is same as will
individual customer. define.
E.g.
Corporate-1
Non Corporate-2
CUSTOMER STATUS MASTER Lookup for Status of Customer. ODS
Admin
will
Status is maintained for Customer Account, define.
Billing Account & Service Node.
E.g.
ACTIVE- 3
CANCELLED-4
BLACK LISTED- 5
CUSTOMER SUBCATEGORY Lookup for sub-category of corporate CLFY
MASTER customers.
E.g.
IndividualPartnership firm
Government Department
Trust
Pvt. Sector Company
Public Sector Company

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

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

Ee.g. Admin
ADC will
SAP define.
CLFY
PG
COMM-IN
OPS
STAR
FRAUD

INVENTORY CATEGORY MASTER This entity describes category of inventory. ODS

Admin
E.g. will
1-Normal Stock define.
2-Transit Stock
3-Staging Sock
4-Returns Stock

MATERIAL CATEGORY CODE Lookup for category of material. ODS

E.g. Admin
Prepaid will
Postpaid define.
MATERIAL HOLDER TYPE MASTER Lookup for type of ABC location. ODS
E.g. Admin
1-Warehouse will
2-CDC define.
3-CBOC
4-OTC
5-WW-POS
7-Distributor-POS
8-Dealer-POS
9-Agent-POS
10-Channel Partner-POS
11-DAE-POS

MATERIAL MASTER Lookup for the type of equipment/material SAP

required for the service.

In case of CDMA voice handset is required

for service.
E.g.
LG2130
MATERIAL STATUS MASTER Lookup for Material Status. ODS
E.g. Admin
will
Provisioned define.
Non Provisioned
General

MATERIAL TYPE MASTER Lookup for type of material/equipment. ODS

E.g. Admin
Handset will
Voucher define.

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

PAYMENT STATUS MASTER Lookup for status of payment (collection). ADC

E.g.
Accepted
Rejected

PAYMENT TYPE MASTER Lookup for type of payment. ODS

E.g. Admin
Cash will
Cheque define.
Credit Card
Debit Card
Direct Debit
Electronic Clearance Service
DD/Banker's Cheque

PINCODE MASTER Lookup for PINCODE. CLFY

POS Lookup of Point of sell. SAP
PRINT STACK MASTER Lookup for Print Stack. ADC
E.g.
HARDCOPY = 1
SOFTCOPY = 2
EMAIL = 3
WEB = 4
OTHERS = 5
Currently Print Stack is Hard Coded in Data
Exchange.

PRODUCT MASTER Lookup for Products sold by ABC. Product CLFY

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

QUEUE MASTER This entity describes details about different CLFY

queues to which cases are assigned.

RATE PLAN CHARGE ATTRIBUTES
This entity describes charge attributes ADC
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)
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 R-
Connect & 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 Lookup for SDCA. CLFY
SERVICE NODE STATE MASTER Lookup for the status of Service Node. ODS
E.g. Admin
Idle will
Active define.
Inactive
Retired
Expired
Terminated
Re-Activated
Suspend
Also See SERVICE NODE DETAILS.

SERVICE TAX STATUS MASTER Lookup for Service Tax Status. ODS
E.g. Admin
SERVICE TAX FULL RATE= 1 will
SERVICE TAX EXEMPT= 2 define.

Invoice Node should have Service Tax

Status.
SERVICE TYPE MASTER Lookup for the type of services offered by ODS
ABC. Admin
will
E.g. define.
CDMA VOICE
R-World
R-Connect
LEASED LINE
Non-Network

SEVERITY LEVEL MASTER Lookup for level of severity of case. CLFY

E.g. High, Medium, Low.
STATE MASTER Lookup for different States of a Country. CLFY
E.g.
Maharashtra
Gujarat

TDS TAX STATUS MASTER Lookup for TDS TAX Status. ODS
E.g. Admin
TDS FULL RATE=1 will
TDS TAX EXEMPT"= 2 define.
TDS TAX RELAXED = 3
Invoice Node should have TDS Tax Status.

TREATMENT CATEGORY Lookup for treatment category. ADC

E.g.
VIP
Employee
General
VOUCHER TYPE MASTER This entity describes different types of SAP
vouchers sold by ABC.
E.g.
1-Prepaid voucher
2-ILD Voucher
3-NLD Voucher
WAREHOUSE Lookup for ABC Warehouses. SAP

5.2. Exchanged Data

5.3. Data Not Exchanged

Customer Account Balance & Unbilled Information

Name Definition
ACCOUNT ID
BILLING ACCOUNT NO Billing Account No. of customer.
System generated no. is assigned as BAN for
postpaid/prepaid individual customers.
CUSTOMER ACCOUNT NO System generated customer account no.
ACCOUNT BALANCE AMOUNT
UNBILLED_AMOUNT 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.
BALANCE_DATE
CREDIT LIMIT Credit Limit of customer.
Default Null.
ACCOUNT_ACTION_CODE Code that indicates action taken in relation to unbilled amount
for an account.

ACCOUNT_ACTION_DATE Date and time at which the account_action_code was last set
or cleared
PROMO BALANCE AMOUNT Promotional balance for prepaid customers.
PROMO BALANCE EXP DATE Expiry date of promotional balance for prepaid customers.
LAST_RECHARGE_DATE For prepaid customer this field indicates last recharge date.
ACCOUNT_TYPE_ID ACCOUNT TYPE IDENTIFIER
E.g.
ADVANCE A/C
HANDSET DEPOSIT A/C

CURRENCY CODE

Invoice Details

Name Definition
INVOICE NO Unique identifier that defines a particular customer node
invoice.
CUSTOMER ACCOUNT NO System generated customer account no.
BILLING ACCOUNT NO Billing Account No. of customer.
System generated no. is assigned as BAN for
postpaid/prepaid individual customers.
BILL_RUN_ID Unique identifier of the bill run that generated the account.
INVOICE DATE
PERIOD FROM DT
PERIOD TO DT
Name Definition
INVOICE_AMOUNT Total amount of charges that are associated with the invoice,
excluding the balance forward.
STATEMENT_AMOUNT 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_FORWARD Balance on the account prior to the application of the invoice.
ACCOUNT_BALANCE 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.
SUPPRESS_IND_CODE 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.
ORIGINAL_PAYMENT_DUE_DATE Date that the invoice was originally due to be paid.
PAYMENT_DUE_DATE 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.
EARLY_PAYMENT_DATE Date for payment to receive an additional discount. This
discount has already been incorporated into the
INVOICE_TOTAL.
CURRENT_DUE
TOTAL_PAYMENTS 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 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 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.
APPLIED_IND_CODE 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.
LATE_PAYMENT_CHARGE
PREVIOUS DEUS
MONTHLY CHARGES Monthly charge for CUG.
OTHER PLAN CHARGES Other plan charges for CUG.
ADMIN CHARGES Administrator Recurring Charges for CUG
SERVICE CHARGES Service Charges for CUG.
OIC CHARGES Offnet Inter-Operator Charges for CUG.
SERVICE TAX
TOTAL CHARGES
ACCOUNT ID Unique identifier of the account to which the invoice is
applied.
INVOICED_ACCOUNT_ID 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 Definition
This is the Account Id of Parent of Corporate Customer. This
value will come in case this is the record for the child.
IMAGE_GENERATED_IND_CODE 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 Definition
INVENTORY HOLDER Warehouse, CDC, OTC, Channel Partner
MATERIAL CODE
MATERIAL CATEGORY CODE
MATERIAL QTY
INVENTORY DATE
ORIGINATOR ID
DISPATCH DATE
SCHEDULED DELEVIRY DATE
NEW REFURBISHED FLAG
INVENTORY CATEGORY CODE

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