0764 IPX Voice 220-00 (System Specifications) V1-3 2012-04-02

7/27/2019 0764 IPX Voice 220-00 (System Specifications) V1-3 2012-04-02

1/41

Project:Document scope:File:

0764 IPX Voice Page:GBS0764 IPX Voice 220-00 (System Specifications) V1-30 2012-043-0262.doc

Page 1 of 41

220-00 System Specifications

IPX Voice

GBS

0764 IPX Voice 220-00 (System Specifications) V1-30 2012-023-2026.doc

Version: 1.30Date: 2012-043-20276Status: Final

This document and its contents are the property of TATA communications or its affiliates. This document contains confidential proprietary information. The reproduction,distribution, utilization or the communication of this document or any part thereof, without express authorization is strictly prohibited Offenders will be held liable for thepayment of damages.

2010, TATA communications or its affiliates. All rights reserved.


2/41



Page 2 of 41

..................................................................................................................................................................................................1

1. DOCUMENT CONTROL..................................................................................................................................................31.1 VERSION HISTORY...........................................................................................................................................................3

1.2 REVIEW HISTORY............................................................................................................................................................3

1.3 FINANCIAL CONTROL REVIEW HISTORY...........................................................................................................................4

1.4 REFERENCED DOCUMENTS..............................................................................................................................................4

2. INTRODUCTION...................................................................................................................................................... ........4

2.1 CONTEXT

..............................................................................................................................................................................................4

2.2 SUMMARYOF SOLUTION.................................................................................................................................................5

2.3 SCOPE.............................................................................................................................................................................6

2.4 ASSUMPTIONS.................................................................................................................................................................6

2.5 INTENDED AUDIENCE......................................................................................................................................................72.6 ACRONYMSAND TERMINOLOGY......................................................................................................................................8

3. DESIGN DESCRIPTION.................................................................................................................................................10

3.1 AS-IS ...........................................................................................................................................................................10

3.1.1 Data Flow Diagram:..............................................................................................................................................12

3.2 TO-BE..........................................................................................................................................................................13

3.2.1 Context Diagram:..................................................................................................................................... ......... ....13

3.2.2 VTS MPLS service:................................................................................................................................... ......... ....14

3.2.3 VDT (MPLVDT) Service:..................................................................................................................................... ..14

3.3 DES.0.4- CPNY_ORG_STRUC_SEBS POPULATION:....................................................................................................18

4. DATA SPECIFICATION.................................................................................................................................................34

4.1 DATADESCRIPTION........................................................................................................................................................34

4.2 DATAMODELANDSTRUCTURE......................................................................................................................................35

4.3 DATACONVERSION........................................................................................................................................................37

4.3.1 Condition of existing system data......................................................................................................................... ...37

4.3.2 Conversion strategy................................................................................................................................................37

4.3.3 Conversion rules description..................................................................................................................... ......... ....38

5. FAILURE MANAGEMENT............................................................................................................................................38

5.1 FAILURE ANALYSIS.......................................................................................................................................................38

5.2 INTEGRATIONWITH TROUBLE TICKET SYSTEM...............................................................................................................38

6. HANDLING OF NON-FUNCTIONAL REQUIREMENTS....................................................................... ........ ........ ...38

6.1 PERFORMANCE .............................................................................................................................................................386.1.1 Response time................................................................................................................................................... .....39

6.1.2 Capacity .................................................................................................................................................... ......... ..39

6.1.3 Scalability........................................................................................................................................................... ...39

6.2 RELIABILITY..................................................................................................................................................................39

6.3 SECURITY......................................................................................................................................................................39

6.4 MANAGEABILITY...........................................................................................................................................................39

6.4.1 Installation and Deployment................................................................................................................................ ...39

6.4.2 Upgrade................................................................................................................................................ .......... ......39

6.4.3 Configuration.........................................................................................................................................................40

6.4.4 Retention, Archive and Backup Strategy................................................................................................................ ..40

6.4.5 Performance Management............................................................................................................................. ........40

This document and its contents are the property of TATA communications or its affiliates. This document contains confidential proprietary information. The reproduction,distribution, utilization or the communication of this document or any part thereof, without express authorization is strictly prohibited Offenders will be held liable for the

payment of damages.



3/41



Page 3 of 41

6.4.6 Troubleshooting.................................................................................................................................................... .40

6.4.7 Other Maintenance Activities..................................................................................................................................40

7. DEVELOPMENT TOOLS AND TECHNOLOGIES........................................................................................... ........ ..40

8. TEST ASPECTS...............................................................................................................................................................41

9. OPEN ISSUES....................................................................................................................................................... ......... ..41

1.Document Control

1.1 Version History

Version Date Description of Changes Made by

1.0 2012-03-22 Initial Version Thiru K/Andrews

1.1 2012-03-23 Incorporated review comments from Nirjhar/Ranga Thiru K/Andrews

1.2 2012-03-27 Incorporated Michels Review comments Thiru K/Andrews

1.3 2012-04-02 1. Removed SEBS6530 changes

2. Change Rate entry Og_Offer_Id LOVsource value from CMS_CUSTOMER toBUS_REL_OPTN_MAP

Thiru K

[Date format is yyyy-mm-dd.]

1.2 Review History

Version Date Reviewer Signature

[Version includes all previous versions. Merge the version cell when there is more than one reviewer.

Reviewer includes name and title. It is possible that say version 1.1 was reviewed only by a subset of version

1.0 reviewers.

This will depend on the nature and the magnitude of the changes between versions. For instance the addition of

a performance requirement in version 1.1 may not require the review of the Security Manager who has signed


payment of damages.



4/41



Page 4 of 41

off version 1.0.

Signature is an attached email received from a reviewer]

1.3 Financial Control Review History

Version Date Reviewer Signature

[Approval is required for any project that may affect the financial control. If not required, leave the table empty.]

1.4 Referenced Documents

Following documents were referenced to prepare this document:

1. 0764 IPX Voice-110-00 (High Level Architecture-GBS) V3 0 2012-02-13.docx

2. 0764-IPX Voice-110-00 (High Level Architecture) V1 4 20120229.docx

2.Introduction

2.1 Context

Current Situation:

MPLS is a standards-approved technology for speeding up network traffic flow and making it easier tomanage. MPLS involves setting up a specific path for a given sequence of packets, identified by a label put ineach packet, thus saving the time needed for a router to look up the address to the next node to forward thepacket to.

Currently this MPLS traffic is tagged to service VTSPRMX. For this service prices are being provided byPULSE and Costs are being provided by Reflex and GTM. GTM provides USA termination rates where as reflexprovide rest of the world costs. With this current set-up, it is difficult to provide more visibility to MPLS traffic. Themain goal of this project is to provide more intelligent call routing features by segregating the MPLS customertraffic on top of the actual IP/Data/signaling offerings.

In invoice customer doesnt have option to see the Usage and transit fee information separately from Rate byminute.

Cost and Price synchronization is being currently handled by Pulse and Reflex.

Objective:

As part of this project, we are adding flexibility in TCL network to segregate the MPLS traffic. To achieve this


payment of damages.



5/41



Page 5 of 41

goal, we are going to offer 3 MPLS counterpart services for each VTS services [MPLVTS, MPLPREM andMPLPREF].

To simulate VVPN(Voice virtual private network), we are going to define a new service VDT along with the

corresponding MPLS counterpart which will make TCL to act as a transit for a customer to send all traffics to asupplier. The customer and supplier can have either Direct or Cascade agreement. In case of Direct agreement,supplier will pay directly to the customer and TCL will charge only transit fee to the customer. In case ofCascade agreement, TCL will charge both usage and Transit fee from the customer. Cascade or Directagreement information needs to be stored along with the profile information in SECS.

VDT or MPLVDT receivable rates will be entered into GBS through manual entry. As pulse will not beinvolved in maintaining the VDT prices, to maintain the syncornization between costing and pricing rates, a newalarm will be generated in GBS to compare whether receivable rates cover the payable rate amount.

MPLS counterparts for VTS services will continue to receive rates from GTM and reflex.

Also payable profile scope will be opened to have multiple CMS_Ids for same profile. The outgoing CMS_IDdetail will be stored in a new RATE_CASE column Og_Offer_Id for VDT or MPLVDT. Og_Offer_Id will be used

in rating to choose correct rate.

2.2 Summary of Solution

MPLS counterparts for VTS:

1. MPLS counterpart services such as MPLPREM, MPLPREF, and MPLVTS will be created for VTSservices VTSPREM, VTSPREF and VTS respectively to segregate the MPLS traffic.

2. These MPLS counterpart VTS services will receive rates from Pulse and reflexes as VTSservices.

New VDT Service:

3. A new service VDT will be defined along with its MPLS counterpart MPLVDT.

4. To manage two different agreements [Direct or Cascade] for VDT or MPLS VDT service for aprofile, payable profiles will be opened to have multiple CMS_Ids for same product.

5. Direct and Cascade agreement information will be managed by adding DIRCT_AGRMT(Y/N) flagin product and profile tables.

6. Product Screen will be changed to have Direct Agreement flag to identify the products which canhave direct/cascade aggrement

7. A new grouping flag will be added for Payable profiles. If it is set we can have multiple CMS_Idsfor same profile.

8. A new column Og_Offer_Id will be added in RATE_CASE tables to store outgoing CMSinformation.


payment of damages.



6/41



Page 6 of 41

Rating Module

9. For Direct agreement traffic, payable part of the call will be discarded with No rating for Directagreement.

10. For receivable part rating, rate will be identified by matching the OG_CMS_ID fromRate_Case.og_offer_id with CDRV.FACTOR_APPL_BASIS_1

Rate Integration

11. As VDT traffic will be uploaded only Rate upload or Rate entry. New Rate identifier Og_Offer_Idneeds to be added in Rate integration process and Rate manual entry.

Invoice & CDR Report

12. Invoice and Call Detail Reports will be changed to show Usage and Transit fee information inRate per Minute column.

New Alarm:

13.A new alarm will be generated when Receivable cost is not covering the Payable cost for VDTservices.

2.3 Scope

1. Changing SECS screen to hold Direct/Cascade agreement details.

2. Opening up Payable profiles scope to hold multiple CMS_IDs

3. Managing outgoing CMS_ID information in new column RATE_CASE.Og_Offer_Id for receivablerates.

4. Applying receivable rates based on outgoing CMS_ID in rating module.

5. Invoice and CDR changes to segregate Usage and transit fee charges in Rate per minutecolumn. Declaration report changes will not be covered as part of this project.

2.4 Assumptions

1. No Impact on Costing or GTM feed for payable rates due to change in payable product scope formaintaining multiple CMS_Ids for same profile.

2. No change in pricing feed to populate OG_OFFER_ID.

3. PULSE and Reflex system will send the rates for MPLVTS, MPLPREF and MPLPREM services.

4. VDT or MPLVDT service receivable rates will be entered only manually either through Rateupload or Manual Rate Entry.

5. VDT or MPLVDT service payable rates will be received from reflex applications.

6. VDT or MPLVDT receivable rates will have OG_OFFER_ID always tagged to them.

7. Alarm to compare payable and receivable rates will be generated only for VDT and MPLVDTservices.

8. Since there is a dependency with Dept. Billing project which opens up receivable part scope tostore multiple CMS_Ids, it has to be deployed affront to this project.


payment of damages.



7/41



Page 7 of 41

9. The invoice changes involved in this project will be applicable to all services and customers.

2.5 Intended Audience

This section describes who potential readers of this document are. By default there are the following three typesof readers:

Architect/Tech Lead (Reviewer)

Background and required level of understanding

o Has a very good technical background of the areas of subject matter (there can be more than

one).

o Should be able to fully understand the complete document.

Purpose of reading the document

o Has to understand the complete content of the document to ensure the design specified is in

line with the architecture decisions in the HLA. Has to score it properly and to justify whyhe/she scored in a certain way.

o The alignment with the HLA is the responsibility of the architect.

Subject Matter Expert (SME)


o Has a very good technical background of the corresponding subject matter (which might only

cover a part of the System Spec content).

o Should be able to fully understand that part of the document which deals with the design

related to his/her subject matter.


o Has to understand the content of the document to ensure the design specified is in line with

whatever concerns his subject matter in this context.

Developer


o Has a very good technical background of the corresponding subject matter.

o Developer should be familiar with that part of the document which he/she has to implement.

o Developer Leadshould be able to fully understand the whole document; even if he/she is only

responsible for implementing a part of the design.


o Uses the design description of this document to implement the part of the design he/she is


payment of damages.



8/41



Page 8 of 41

responsible for.

Tester


o Tester should be able to fully understand the document.


o Uses the design to create test strategy and test plan.

2.6 Acronyms and Terminology

Terms and acronyms used in this document are defined in the following table.

Term/Acronym Full Name Description

TCL Tata

communications

Ltd

GBS Global BillingSystem

Billing and Invoicing system for Voice Switched Services

SERM Rate

Management

System

Rate management system.

MPLS Multiprotocol

Label Switching

MPLS is a standards-approved technology for speeding up

network traffic flow and making it easier to manage. MPLS

involves setting up a specific path for a given sequence of

packets, identified by a label put in each packet, thus saving

the time needed for a router to look up the address to the next

node to forward the packet to. MPLS is called multiprotocol

because it works with the Internet Protocol (IP),

Asynchronous Transport Mode (ATM), and frame relay

network protocols.


payment of damages.



9/41



Page 9 of 41

Term/Acronym Full Name Description

IPX Internetwork

Packet

Exchange

IPX is a networking protocol from Novell that interconnects

networks that use Novell's NetWare clients and servers. IPX is

a datagram or packet protocol. IPX works at the Network

layer of communication protocols and is connectionless (that

is, it doesn't require that a connection be maintained during an

exchange of packets as, for example, a regular voice phone

call does).

PULSE Pricing System Pricing application provides receivable rate to GBS

VVPN Voice Virtual

Private Network

The acronym VVPN stands for Voice Virtual Private

Network. The VPN is somehow used to link international

offices as if there were on-net expanded to any

inbound/outbound agreement where the TCL network is only

used for transit with a hard patch routing.

CDR Call Detail

Report

Records containing detailed information about a call at

network level.


payment of damages.



10/41



Page 10 of 41

3.Design Description

3.1 AS-IS

MPLS Traffic:

MPLS traffic is currently being received from RETR tagging to the service VTSPRMX. Receivable and Payablerates are received for VTSPRMX from Pulse and Reflex applications respectively as any other VTS services.With this current set up, it is difficult to have more visibility or segregate the MPLS service.

Managing Rates:

GBS receives rates from following applications:

1. Receivable Rates are being sent by Pulse.

2. GTM sends the USA termination payable rates.

3. Reflex sends the rest of the world Payable Rates.

Rates received from Pulse, GTM and Reflex applications are usage rates with per minute scale. These rates arestored in GBS with rate type: = 1. These usage rates cover both termination and transit fee. GBS have flexibilityto store transit fee rates [rate type: =3] and per call rates [rate type: =2]. But Rate per call and transit fee ratescan be entered into GBS only through manual rate upload or manual rate entry process.

Sending amendments to the customers on price increase because of our cost increase is currently beinghandled by synchronization between Pulse and Reflex which is completly out of scope for GBS.

Invoice or CDR:

If a customer have both termination and transit fee applicable, then both these fees will be summed up showedunder one column Rate by Min in invoice and Call detail report. Customer doesnt have flexibility to view thetermination and transit fee separately.

Mapping Screen:

After the 783 Departmental Billing project the value Y for INVCE_GRPNG_FL field is possible only for theincome type R. This validation is done based on the configuration in confg_parm (prcss_nm = CUS_PROFand parm_nm = INCOM_TYPE_INVCE_GRPNG_FL. For payable INVCE_GRPNG_FL should be always N


payment of damages.



11/41



Page 11 of 41

Overview of current Send paid Rating:

Suppose the following call:

Origin country Canada Destination country India

The switch belongs to Teleglobe Canada

On the CDRV well see:

Orgin_cntry_abbr = CDZ

Dest_cntry_abbr = IND

Swtch_admin_abbr = TCL

Og_stwch_admin_abbr = TCL

Ic_link_admin_abbr = BELL (carrier of Canada)

Og_link_admin_abbr = AIRTEL (carrier of India)

The origin admin (OA) of that call is BELL

The route in admin (RI) of that call is BELL

The route out admin (RO) of that call is AIRTEL

FACTR_APPL_BASIS_1 = BELL_CMS_ID

BELL is Receivable Part

AIRTEL is Payable Part.

Currently we choose the receivable rate only based on (CPNY/ORG_NO/PRDCT_NO) of customer. After findthe rates we may choose on based on following priority DEST_ID/CCRN/CNTRY

As part of DEPT BILLING, Incoming CMS_ID will also be considered for choosing the receivable rates.

As part of this project, We will pick the receivable rate based on the supplier we are paying also for VDT service(CPNY,ORG_NO,PRDCT_NO,OG_CMS_ID).


payment of damages.



12/41



Page 12 of 41

3.1.1 Data Flow Diagram:

1- SECS system sends the new supplier creation , close supplier, change in the product ororganization or billing entity or cms cust id , upgrade or downgrade of the product transaction toReflex/GTM

2- Supplier submits the rate-sheets for Non-USA supplier in Reflex and USA supplier rate sheets inGTM.

3- Reflex/GTM system process and send supplier rate-sheets to GBS system4- Market manager submits the price sheets in Pricing.5- Pricing sends the receivable rate sheets to GBS.6- RETR sends the traffic to the GBS in the form of the CDRV binary file.7- GBS rates the traffic with payable and receivable rates.8- DW receives the rated CDRV from GBS and produces margin reports.


payment of damages.



13/41



Page 13 of 41

3.2 TO-BE

3.2.1 Context Diagram:


payment of damages.



14/41



Page 14 of 41

3.2.2 VTS MPLS service:

To segregate the MPLS traffic from VTS traffic and provide more clear visibility them, three new MPLScounterpart VTS services will be created [MPLVTS, MPLPREF and MPLPREM]. MPLS counter-part VTSservices will continue to receive rates from Pulse and Reflex applications as existing VTS services.

There is no change in GBS functionality to manage these 3 new services.

These MPLS counterpart VTS services will have a mapping service flag in SL_XREF will be set to YES soCall_Id process will be retrieving the contracted service associated to the inbound CMS_ID.

More detailed explanations on SL_XREF configuration is given in 3.2.3

3.2.3 VDT (MPLVDT) Service:

Voice Direct Traffic service is being added in TCL to provide VVPN like flexibility. TCL will transit all traffic from acustomer to a particular profile. Customer and Supplier can have either Direct or Cascade agreement betweenthem.

Direct Billing: An agreement is in effect between the customer and the supplier. For TCL point of view, we willnot expect to pay anything to the supplier for the calls and we will receive a transit fee from the customer that willrepresent the margin

Cascade Billing: There is no known agreement between the customer and the supplier. For TCL point of view,this will be business as usual as we will pay the supplier for terminating the call and we will received from thecustomer a termination fee that should normally cover the costs to the supplier plus a transit fee that willrepresent the margin

VDT payable rates will be received from GTM and Reflex which doesnt require any change in GBS.

VDT receivable rates will have the following characteristics:

1. Receivable Rates will have specific supplier id associated to it. Supplier ID information will be stored in new

RATE_CASE table column Og_Offer_Id.

2. It can have two types of rates [Usage or Transit]. Usage rates will have rate_type:=1 and transit rates willhave rate_type:=3

3. Rates will be at destination country level only.

VDT and MPLVDT will have mapping service flag as N. We will not derive any services for VDT or MPLVDT,we will continue to use the service from meditaion

Below is the example of behavior for new services in call id process:


payment of damages.



15/41



Page 15 of 41

Call IC admin IC CLLI Serv IC Serv RTE In serv IC CMS Id OG admin OG CLLI Serv OG Serv RTE Out Serv OG CMS id Serv Abbr Rte In Serv FIN Inputed Serv

1 A VDT VDT 111 C VDT VDT 331 VDT VDT VDT

2 A VDT VTS 111 C VTS Not VDT Not VDT 335 VDT VTSPREF VDT

3 B MPLVDT MPLVDT 222 D MPLVDT MPLVDT 444 MPLVDT MPLVDT MPLVDT

4 B MPLVDT VTS 222 GHI VTSNot in (VDT,

MPLVDT)

Not in (VDT,

MPLVDT) 6789MPLVDT MPLPREM MPLVDT

5 B MPLVDT VTS 222 JKL VTSPREFNot in (VDT,

MPLVDT)

Not in (VDT,

MPLVDT) 7890MPLVDT MPLPREM MPLVDT

In the above examples, GBS will search for VTS route in services in the SL_XREFand will find an active entrywith a MAP_SERV_FL = Y. From there, GBS will be using the contracted service associated to the inboundCMS id which will drive to VTSPREF / MPLPREM and therefore using the prices provided by Pulse. In otherwords, the yellow Route In services provided by mediation will turn into the green financial route in services.

Following are the detailed overview of the changes to manage VDT (MPLVDT) service in GBS:

3.2.3.1 SECS:

SECS Business relations ship and Product screens needs to be changed to maintain direct agreement informationand also to open up scope for payable products to have multiple CMS_Ids.

3.2.3.1.1 Business relationship product screen

AS-IS:

After the 783 Departmental Billing project the value Y for INVCE_GRPNG_FL field is possible only forthe income type R. This validation is done based on the configuration in confg_parm (prcss_nm =CUS_PROF and parm_nm = INCOM_TYPE_INVCE_GRPNG_FL.

While creating a new business relationship product, if we try to give Y for INVCE_GRPNG_FL for

payable, it will throw an error.

While updating a business relationship product, for the Payables, the INVCE_GRPNG_FL will be read

only.

TO-BE:

For IPX, for income type P also, INVCE_GRPNG_FL can be Y.

So in BeforePost function the validation will be removed and the configuration in confg_parm will be

removed which is currently done for the Receivables

And during edit, the INVCE_GRPNG_FL will be enabled for Payables also.

3.2.3.1.2 Business Relationship and Mapping Screen:

In Department billing project, scope is opened to have multiple Cms ids for same receivable product. As part ofthis project payable product scope will be opened to have multiple Cms ids for same product.


payment of damages.



16/41



Page 16 of 41

To identify the CMS link to a direct agreement, a new field DIRCT_AGRMT_FL will be added inBUS_REL_OPTN_MAP table. In the screen this field will be added as a Check Box. The possible values are Y(Checked)/N (Unchecked). This can be set to Y, only when that product has the DIRCT_AGRMT as Y.

NEW:

While creating a new mapping, the DIRCT_AGRMT flag will be set to N initially.

If the prdct_no have the DIRCT_AGRMT flag as Y in PRODUCT table, only then the column

DIRCT_AGRMT_FL will be editable. Otherwise user cannot set the value as Y.

There will be a validation to validate the DIRCT_AGRMT_FL in Before Post function.

When the DIRCT_AGRMT_FL is set, SECS_TRX will not be created for this action code.

User will be able to create multiple mapping, when they set the INVCE_GRPNG_FL as Y in Business

Relationship Product screen. So no code change is required for this.

CLOSE:

While closing the mapping, we have the check the DIRCT_AGRMT_FL for that mapping.

If that flag is set to Y, then we should not create any transaction in SECS_TRX table.

If the flag is N, then we have to create a transaction in SECS_TRX table.

UPGRADE-DOWNGRADE:

Upgrade-Downgrade action is not applicable for VDT products as this is only applicable for VTSproducts.

CORRECTION:

CORRECTION cannot be done on the products which has the PRODUCT.DIRCT_AGRMT as Y. In

this case, an error will be thrown You cannot perform the CORRECTION on this product no. pleasechoose different action code

And also user cannot change the DIRCT_AGRMT_FL alone from N to Y or vice versa. Here also

error will be thrown.

In the above cases, user has to CLOSE the current mapping and open a NEW mapping.

CONSOLIDATION:


payment of damages.



17/41



Page 17 of 41

Consolidation is not possible for the VDT product since consolidation is only possible for the services whichhave the map_serv_fl as Y. So no change is required for this.

3.2.3.1.3 Product Screen

A new tab Direct Billing Agreement will be added in product screen which help us to identify the productswhich can have direct billing agreement.

Four New products will be created as part of this project:

VDT Receivable

VDT Payable

MPLVDT Receivable

MPLVDT Payable

Screen changes:

We need to add a new flag to identify the products which can have the Direct Billing Agreement.

So in Product table one new column DIRCT_AGRMT will be added. This can have the value of Y or

N.

One check box will be added in the screen to manage this column.

During insert, the value N (Unchecked) will be populated as default. If the user wants to change the

value to Y, he can check the check box.

During edit, User can edit the DIRCT_AGRMT column from N to Y at any time.

But they can update from Y to N only if there is no action Business Relation Option for that.

If they tried to update the DIRCT_AGRMT from Y to N and there is a Business Relation Option for

that product, then error (Modification is not allowed on this column from Y to N as there are one ormore business relation(s) associated to this product) will be thrown.

The field will be added as mentioned in the image below


payment of damages.



18/41



Page 18 of 41

3.3 DES.0.4- CPNY_ORG_STRUC_SEBS population:

The appworx chain SECS_CHN_ORG_STRUC_SEBS is used to remove the records from

CPNY_ORG_STRUC_SEBS table and again populate it from SECS tables.

This chain was scheduled to run every day.

This shell uses the database procedure SECS_0801 procedure to populate the records.

A change is required in the procedure to populate the BUS_REL_OPTN_MAP.DIRCT_AGRMT_FL in

CPNY_ORG_STRUC_SEBS table.

3.3.1.1 SERM

Due to budget constraints PULSE is not doing any changes to send the Receivable rates with Og_Offer_Id. TheReceivable rates for VDT (MPLVDT) will always entered manually through rate upload or Rate entry. A newcolumn Og_Offer_Id will be added in RATE_CASE table to store the supplier information which hold theagreement with the customer.

All VDT(MPLVDT) receivable rates should have Og_Offer_Id tagged.


payment of damages.



19/41



Page 19 of 41

3.3.1.1.1 Rates upload:

Manual Rate upload is used to enter large amount of rates into SERM rate tables. Rate to be uploaded areentered in a excel file and uploaded through the screen SERM0208. The rates will be first entered into temptable RATE_ULOAD_TMP and later processed using RATE_ULOAD_PACK.

Following are the changes to be done in Screen and SQL file:

1. Change the CSV file Template format to include Og_Offer_Id.

2. In screen SERM0208, populate the Og_Offer_Id information into RATE_ULOAD_TMP table along withother columns.

3. In Serm_0208.sql file, CR_RATE_ULOAD_RJCT cursor will be changed to select Og_Offer_Id informationfrom RATE_ULOAD_TMP table.

4. In Serm_0208.sql file, changes will be done to include Og_Offer_Id information also while writing error log.

Following are the changes to be done in RATE_ULOAD_PACK:

5. Cursor C_RATE_ULOAD which selects the records from RATE_ULOAD_TMP table to process needs tobe changed, to select OG_OFFER_ID column also.

6. In SERVICE_CHRTC table, OG_OFFER_ID will be configured with service characteristic number as 69.

Same service characteristic number will be re-used inside RATE_ULOAD_PACK.7. OG_OFFER_ID column is mandatory field for VDT[MPLVDT], which can be validated by configuring in

SERVICE_CGS for service grouping no 1[SR-Usage] and 2[SR-SurCharge].

8. OG_OFFER_ID characteristic values are:

A_TblId (69) := 'NONE';

A_ChrtcNm (69) := OG_OFFER_ID;

A_FldType (69) := 'N';

A_TblColNm (69) := NULL;

9. Modify the gch_DefinedCaracteristic variable to include the 69 chrtc no for OG_OFFER_ID.

10. Modify the gn_NbField field value to 22

11. For logging error messages A_FieldNameWarning array variable needs to be initialized withOG_OFFER_ID also.

12. A Validation can be added to check whether the VDT(MPLVDT) rates are always country level[i.e.DEST_ID/DEST_CCRN/DEST_LATA/DEST_OCN will be NULL].

13. Rate Case Access Key Generation:

a. OG_OFFER_ID will be added as part of Rate_Case_Access_Key.

b. It will be added at the end of the Rate_Case_Acces_Key string. All existing records will be appended


payment of damages.



20/41



Page 20 of 41

with *

c. BUILD_RATE_CASE_ACCES_KEY and BUILD_RATE_CASE_ACCES_KEY_PART Function whichgenerates Rate case access key needs to be altered to append OG_OFFER_ID information also in

rate access key for all new records inserted into RATE_CASE table:||NVL(P_OG_OFFER_ID, *) will be added in those functions to generate rate case access key.

Following is the change in the Rate upload template:

Rate upload.xls

Rest of the changes done in RATE_ULOAD_PACK as part of Rate Integration process will handle thepopulation of OG_OFFER_ID into Rate tables.

3.3.1.1.2 Rate integration [RATE_ULOAD_PACK]:

Following are the changes to be done in rate integration process with respect to VDT or MPLVDT receivablerates:

3.3.1.1.3 Rate Management Screen Changes

Rate Manual Entry screen SERM02300 will be changed to enter rate with OG_OFFER_ID

Following are the specifications of the changes:

1. OG_OFFER_ID will be entered only for Receivable rates and the Service grouping no 1[SR-R-Usage] and2 [SR- R-Transit].

2. When the service is VDT and Incom_Type is R, OG_OFFER_ID is mandatory column.

3. To enter value for OG_OFFER_ID, it can show the LOV value from CMS_CUSTOMERBUS_REL_OPTN_MAP table. Only Payable VDT/MPLVDT mappings will be queried.

4. OG_OFFER_ID will be used for validating duplicate rate.

5. OG_OFFER_ID will be added in Rate Detail Block section.


payment of damages.



21/41



Page 21 of 41

3.3.1.1.4 Alarm

GBS is not really into the business of sending amendments to customer to increase our prices when our costsare not covering our prices. This activity is currently handled by reflex and pricing. Due budget constraint sincePULSE is not going to make changes to handle VDT supplier rates, a alarm needs to be generated from GBSwhen the prices are not covering the costs and sent to market manager.

Following are the features of this report:

1. A new table SERM_VDT_ALARM_REP will be created in GBS which will have same column as report andthe data which need to goes into the report will be inserted into this table first. Report will be then printedfrom this table.

2. This report needs to be generated daily once.

3. The output file will be generated in CSV file format.

4. Only VDT (MPLVDT) rates will be considered for generating the report.

5. Report will be empty when all VDT rates prices cover the costs.

6. Only current and future rates will be considered for comparison. In case GTM maintains the USAtermination rates, we will be able to compare the rates only when they become effective. GTM doesnt sendthe future rates.

7. Alarm report will be Report will be FTPed to NT drive.

8. Alarm report will be sent in mail to Market manager.

9. Always Payable Rates will be entered at CCRN level, but incase if there is a DEST_ID /LATA-OCN levelrate then it should be displayed under DNIS column in Alarm report.


payment of damages.



22/41



Page 22 of 41

Appworx module SERM_CHN_VDT_ALARM_REP will be created newly. This job will be scheduled to run at 12:00hours EST every day. The job is being scheduled at 12:00 hours to give time for rate integration process to integratenew rates for that day.

Appworx module SERM_CHN_VDT_ALARM_REP will be calling the chain SERM_CHN_VDT_ALARM_REP underthe same

Following are the steps involved in the module:

Step 1: Call the new SQL file serm0220.sql which inserts into SERM_VDT_ALARM_REP table when there is costingrates not covered by pricing rates. Also creates a csv file with same information inserted into the table and written intoAlarm file. Alarm file name will be as follows: VDT_ALARM_REP_{ALARM_DATE_YYYYMMDD}.csv

Step 2: FTP transfer program which transfers the csv report into NT drive. FTP path will be identified fromCONFG_PARM table. PRCSS_NM := SERM0220, PARM_NM := REMOTE_DIR and the directory path will be/SERM/gbsprd/VDT_Alarm


payment of damages.



23/41



Page 23 of 41

Step 3:. Mail the csv report to market manager. Mail Ids will be configured in CONFG_PARM .PRCSS_NM=SERM0220 PARM_NM=MAIL_TO.

SERM0220.SQL:

Following is the algorithm to be followed

1. Indentify the distinct OG_OFFER_IDs which is part of the price sheets for services (VDT and MPLVDT) asbelow:

SELECT DISTINCT rate_plan.og_offer_id, rate_case.cntry_dest

FROMserm.RATE_PLAN, serm.RATE_CASE, serm.RATE

where RATE_PLAN.CPNY_ID = RATE_CASE.CPNY_ID

AND RATE_PLAN.RATE_PLAN_NO = RATE_CASE.RATE_PLAN_NO

AND RATE_CASE.CPNY_ID = RATE.CPNY_IDAND RATE_CASE.RATE_CASE_NO = RATE.RATE_CASE_NO

aND RATE.RATE_STAT = 'APP'

AND RATE_CASE.RATE_CAT 'ER'

andincom_type='R'

andRATE_PLAN.SERV_ABBR in(VDT, MPLVDT)

andeffct_clos_dt>=sysdate

2. As we have the list of supplier CMS_IDs which are mapped to receivable rates, now we have to identify theamount we are paying for those suppliers for the same service. This is identified by selecting the payablerates belonging to the CMS_IDs and country we identified in previous query. Since the payable rates will bemostly present at CCRN level, we have to select DEST_CCRN also:

SELECT

RATE_PLAN.PRDCT_NO, RATE_CASE.CNTRY_DEST, RATE_CASE.DEST_CCRN, RATE.EFFCT_START_DT,

RATE.EFFCT_END_DT, RATE.RATE_AMT, RATE.RATE_CUR

FROMserm.RATE_PLAN, serm.RATE_CASE, serm.RATE, bus_rel_optn bro, bus_rel_optn_map brom

where RATE_PLAN.CPNY_ID = RATE_CASE.CPNY_ID

AND RATE_PLAN.RATE_PLAN_NO = RATE_CASE.RATE_PLAN_NO

AND RATE_CASE.CPNY_ID = RATE.CPNY_ID

AND RATE_CASE.RATE_CASE_NO = RATE.RATE_CASE_NO

aND RATE.RATE_STAT = 'APP'

AND RATE_CASE.RATE_CAT 'ER'

andincom_type='P'

andRATE_PLAN.SERV_ABBR in(VDT, MPLVDT)

andrate_plan.cpny_id=bro.cpny_id

andrate_plan.org_no=bro.org_no

andrate_plan.prdct_no=bro.prdct_no

andbrom.cpny_id=bro.cpny_id

andbrom.org_no=bro.org_no

andbrom.optn_rel_no=bro.optn_rel_no

Andbrom.cms_cust_id = :og_offer_id defined onthe customer price

Andrate_case.cntry_dest = :cntry_dest onthe customer price

andeffct_clos_dt>=sysdate

Andrate_amt > 0

Oder by RATE_CASE.CNTRY_DEST, RATE_CASE.DEST_CCRN, RATE.RATE_EFFCT_DT;


payment of damages.



24/41



Page 24 of 41

Rate amount should be greater than zero because we want to compare the cascade supplier rates. In caseof direct supplier we dont have to compare their rates with receivable rates.

If there are no records selected from this query then all those suppliers have direct agreement and we donthave to proceed further.

3. If there are rates identified in previous query then corresponding receivable rates needs to be identified.Transit and Termination rates have to be queried separately to group the costs for different periods.

Example from if payable rate is

From To countr y

CCRN rate Cur Type

CMS

Feb 1st Feb 28 FCE 331 5 USD

1 2000

If Receivable rates are:

Org_no

From To countr y

rate Cur Type

OutgoingCMS

10 Jan 1st 2999 FCE 5 USD

1 2000

10 Feb 1 Feb

15

FCE 1 US

D

3 2000

10 Feb 16 2999 FCE 2 USD

3 2000

First Transit fee will be retrived as:

Org_no

From To countr y

rate Cur Type

OutgoingCMS

10 1 Feb 28

Feb

FCE 5 US

D

1 2000

Different periods need to be considered when summing up Transit and Termination fee. For example hereReceivable rates will be splitted into 2 records since Transit fee rate have 2 periods [01-Feb to 15-Feb] and [16-Feb-28-Feb]

Org_no

From To countr y

termination

transit

Total

Cur OutgoingCMS


payment of damages.



25/41



Page 25 of 41

10 Feb 1st Feb 15th FCE 5 1 6 USD

2000

20 Feb 16st Feb28th FCE 5 2 7 US

D

2000

Vice-versa splitting of periods needs to be considered during development.

Final Alarm will have the look as given below:

Alarm.xlsx

To give more understanding to developers how Price/Cost will be compare, below is an example:

For the supplier, we have those costs

From To countr y

CCRN rate Cur Type

CMS

Feb 1st Feb28

FCE 331 5 USD

1 2000

Mar 1st 2999 FCE 331 8 USD

1 2000

For the customers, we have those prices:

Org_no

From To countr y

Rate Cur Type

OutgoingCMS

10 Jan1st

2999 FCE 5 USD

1 2000

10 Jan

1st

2999 FCE 1 US

D

3 2000

20 Jan1st

Feb15th

FCE 5 USD

1 2000

20 Feb16th

2999 FCE 8 USD

1 2000

20 Jan1st

2999 FCE 1 USD

3 2000

30 Jan1st

2999 FCE 5 USD

1 2000


payment of damages.



26/41



Page 26 of 41

30 Jan1st

2999 1 USD

3 2000

40 Jan

1st

2999 FCE 5 EU

R

1 2000

40 Jan1st

2999 1 EUR

3 2000

Processing 5 costs on France 331 from Feb 1st Feb 28th

The following prices will be build and all Prices will cover the 5 costs

Org_n

o

From To countr

y

termination transit Tota

l

Cur Outgoing

CMS


2000

20 Feb 1st Feb15th FCE 5 1 6 USD

2000

20 Feb16th

Feb 28th FCE 8 1 9 USD

2000


2000

40 Feb 1st Feb 28th FCE 5 1 6 EU

R

2000

Processing 8 costs on France 331 from March 1st 2999

The following prices will be build and all Prices in Red will not cover the 5 costs. The 6 EUR for SECS#40 iscovering the 8 USD cost assuming the conversion EUR->USD is over 1,25

Org_no

From To countr y

termination

transit

Total

Cur OutgoingCMS

10 Mar 1st 2999

FCE 5 1 6 USD

2000

20 Mar 1st 2999

FCE 8 1 9 USD

2000

30 Mar 1st 2999

FCE 5 1 6 USD

2000

40 Mar 1st 2999

FCE 5 1 6 EUR

2000


payment of damages.



27/41



Page 27 of 41

3.3.1.2 SEBS

Following are the overview of changes that needs to be done in SEBS:

1. Call Id process needs to be changed to discard the traffic with the comment No rating for directagreement, if the Direct agreement Flag is set to Yes in CPNY_ORG_STRUC_SEBS for IC part of thecall,

2. In Rating, changes needs to be done to compare CDRV field FACTR_APPL_BASIS_1 withOG_OFFER_ID from rate.

3.3.1.2.1 Call Id Process [0301] Process Changes:

Following are the changes needs to be done to discard direct agreement profile traffic in Call ID process:

1. Load DIRECT_AGREEMT_FL from CPNY_ORG_STRUC_SEBS:

Currently CPNY_ORG_STRUC_SEBS table is already being loaded into memory

The Cursor CrsCpnyOrgStrucSebs, needs to be changed to load direct agreement flag also.

2. In SEBSM0301_SetCallPartInfo (), if the Income type is P then use COMPANY, ORG_NO, PRDCT_NO,FACTR_APPL_BASIS_1 and GMT_ANSW_DT_TIME to retrieve corresponding profile fromCPNY_ORG_STRUC_SEBS Obcm memory table.

3. If Direct Agreement Flag is set then discard the Call Part with D. Error code will be set to 3015330199.Error field will be set with Company and CMS information.

3.3.1.2.2 Rating [0403]

3.3.1.2.2.1 Rate Segment Loading:

Rates from SERM will be loaded into memory segment which will be used by rating and re-rating processsimultaneously. There will be two rate segments in memory at a time. One will be completely loaded and forother loading will be in progress. Once the later one is completely loaded first segment will be de-referenced andnew set of rates will be starting to load into new segment.

Changes will be done in rate loading process to load rates with OG_OFFER_ID information also.

Following are the changes to be incorporated:

1. In sebsc0403_RSearch.pc: RC_CURSOR cursor rates which need to be loaded into memory are selected.This cursor will be changed to select OG_OFFER_ID column.

2. Add OG_OFFER_ID column as part of Rate case acces key preparing function.


payment of damages.



28/41



Page 28 of 41

In WriteRateLoadLog (), details of the rate being loaded will be written to a output file. Add OG_FFER_IDparameters also to write into the log.

3.3.1.2.2.2 Traffic Rating:

In Rating, Og_Offer_Id from RATE_CASE table will be compared with the CDRV fieldsFACTR_APPL_BASIS_1column to choose the receivable rate specific to outgoing CMS_ID. This comparisonmapping needs to be done in RATNG_CRITR_MAP table.

Record needs to be added in the following tables:

1. RATNG_CRITR_MAP: A record will be inserted to map that FACTR_APPL_BASIS_1 of CDRV andCDRV_SUM will be compared with OG_OFFER_ID with Prefix and Suffix flag as N.

2. In SERVICE_CHRTC_GROUP table, record will be inserted for VDT(MPLVDT) for service characteristicno 69.

3. Also SERVICE_CGS configuration is mentioned in Rate integration process

Based on these configurations, in CdrvCmp function the comparision will automatically happen and correct ratewill be retrieved.

No specific changes are required for re-rating by call or Sum or re-cycling.

More details about configuration is given in Data section.

3.3.1.2.2.3 Summation or Error Summation

CD_FACTR_APPL_BASIS_1 is already present in SUM_PARM /SEUM_PARM_ERR tables. Just configurationneeds to be added for VDT(MPLVDT) services to use FACTR_APPL_BASIS_1 as part of summation criteria.For that when new records are inserted for VDT (MPLVDT) in SUM_PARM/SUM_PARM_ERR they will haveCD_FACTRE_APPL_BASIS_1 value as T.

This is just a piloting activity,

3.3.1.3 Invoice Modifications:


payment of damages.



29/41



Page 29 of 41

3.3.1.3.1 101/201/301 Attachments

SQL procedure SEBS6442_INS_CDRV_MTH_SUM_TEMP inserts the record into the tableSEBS6442_CDRV_MTH_SUM_TEMP which will be used by sebs6442.rdf to generate 101/201/301 reports.

1. In table SEBS6442_CDRV_MTH_SUM_TEMP, a new column TRANSIT_FEE needs to be added andexisting column RATE_BY_MIN will be changed to TERMN_FEE.

2. In procedure SEBS6442_INS_CDRV_MTH_SUM_TEMP, the select query on CDRV_SUM andMTH_SUM needs to be changed as below:

Current query is as below:

DECODE( cs.rate_appl_unit_meas_t1, 'CALL', cs.rate_amt_t1 / cs.rate_appl_basis_t1,

DECODE( cs.rate_appl_unit_meas_t2, 'CALL', cs.rate_amt_t2 / cs.rate_appl_basis_t2,

DECODE( cs.rate_appl_unit_meas_t3, 'CALL', cs.rate_amt_t3 / cs.rate_appl_basis_t3, 0)))

RATE_BY_CALL,

DECODE( cs.rate_appl_unit_meas_t1,

'SEC', (cs.rate_amt_t1 / cs.rate_appl_basis_t1 * 60),

'MIN', (cs.rate_amt_t1 / cs.rate_appl_basis_t1 * 1),







0))) RATE_BY_MIN,

The RATE_BY_MIN value needs to be selected as two columns TRANSIT_FEE and TERMN_FEE. The querywill be changed as below:

DECODE( cs.rate_type_t1, 2, cs.rate_amt_t1 / cs.rate_appl_basis_t1,

DECODE( cs.rate_type_t2, 2, cs.rate_amt_t2 / cs.rate_appl_basis_t2,

DECODE( cs.rate_type_t3, 2, cs.rate_amt_t3 / cs.rate_appl_basis_t3, 0)))

RATE_BY_CALL,

DECODE( cs.rate_type_t1, 1, DECODE( cs.rate_appl_unit_meas_t1,





payment of damages.



30/41



Page 30 of 41






0))) TERMN_FEE,



'MIN', (cs.rate_amt_t1 / cs.rate_appl_basis_t1 * 1)),

DECODE( cs.rate_type_t2, 3, DECODE(cs.rate_appl_unit_meas_t2,


'MIN', (cs.rate_amt_t2 / cs.rate_appl_basis_t2 * 1)),

DECODE( cs.rate_type_t3, 3, DECODE(cs.rate_appl_unit_meas_t3,



0)))) TRANST_FEE,

Current logic to calculate the rate by minute

if Unit of measure 1 is MIN or SEC then rate by Minute = rate amount 1if Unit of measure 2 is MIN or SEC then rate by Minute = rate amount 2

if Unit of measure 3 is MIN or SEC then rate by Minute = rate amount 3

Should be change by:

if Rate type 1 is 1 then Termination fee = rate amount 1



if Rate type 1 is 3 then Transit fee = rate amount 1



3. Insert command in the procedure will be changed to insert into SEBS6442_CDRV_MTH_SUM_TEMPtablewith TRANSIT_FEE and TERMINATION_FEE instead of just RATE_BY_MIN.

4. sebs6442.rdf will be changed to display RATE_BY_MIN as two column TRANSIT_FEE and


payment of damages.



31/41



Page 31 of 41

TERMINATION_FEE. The attachment will look like blew after the changes:

3.3.1.3.2 Electronic Invoice Attachment (551)

Electronic Attachment 551 is generated using the Pro*C program sebs6560. It refers to the FILE_FMT =ZZAfrom CDR_FMT_DTL table.

In CDR_FMT_DTL, current configuration for file_fmt ZZA is as below:

The RATE_TIME_SLICE record represents RATE_BY_MIN column. So it needs to be converted into twolines[ one for TRANSIT FEE and another for TERMINATION FEE]. All the records after RATE_TIME_SLICEhave to increment the COL_NO value by 1.

After changes records in CDR_FMT_DTL for format ZZA will look as below:


payment of damages.



32/41



Page 32 of 41

Following changes needs to be done in Pro*C program:

1. In sebs6561_GetPtCdrDtaField(), Remove the comparison for RATE_TIME_SLICE and add thecomparisons for TERMINATION_FEE and TRANSIT_FEE

2. Change CDRV_CDR_PRIODSUM query to retrieve Transit fee[Rate type: 3] and Termination Fee[Rate

Type 2] Seperately as explained in previous sections.

3. If Rate_type_Tx = 1 then

Populate Rate_Amt_Tx in Termination fee

Else if Rate_type_Tx=2 then

Populate Rate_Amt_Tx in Base_Amt_Per_Unit

Else if Rate_Type_Tx=3 then

Populate Rate_Amt_Tx in Transt fee

4. Also changes should be done to print the new columns.

3.3.1.3.3 Call Detail Report:

This report is used to send the customer the complete inventory of the CDR that was billed on the invoice. Thefile is in a comma separated format (csv) and available information that could populate on the report need to beprogram. This list of different CDR document available could be retrieved from table DOC_FMT with thecall_dtl_fl=Y

Each CDR will have its own format as mentioned for 551 attachment in the table CDR_FMT_DTL.

Following are the different CDR reports and their corresponding File formats and their corresponding programsto generate them:

select * fromdoc_fmtwhere call_dtl_fl='Y';


payment of damages.



33/41



Page 33 of 41

DOC_FMT_ID INTNL_DESC IMAGE_OR_REC FILE_FMT PGM_NM

520 Not Invoiced Call Detail for WEB daily - flat file R WEB SEBS6526

515 Invoiced Call detail for ITFS with SAC - flat file R UA1 SEBS6446_SORT

507 Invoiced Call detail for retail - flat file R TG1 SEBS6446_SORT

508 Invoiced Call detail for wholesale - flat file R TG2 SEBS6446_SORT

509 Invoiced Call Detail for WEB - flat file R WEB SEBS6446_SORT

510 Declared Call detail for retail - flat file R TG1 SEBS6446_SORT

511 Declared Call detail for wholesale - flat file R TG2 SEBS6446_SORT

513 Payable Call Detail for declaration R TG3 SEBS6446_SORT

514 Payable Call Detail for invoiced traffic R TG3 SEBS6446_SORT

518 Invoiced Call detail for wholesale - flat file R TG4 SEBS6530

519 New CDR for Ivroy R TG5 SEBS6446_SORT

600 Invoiced Call detail for Geneva (INBOUND -800)

R VSI SEBS6446_SORT

601 Invoiced Call detail for Geneva (OUTBOUND -IDDD)

R VSO SEBS6446_SORT

*Removed the CDR docs from above list which doesnt have RATE_TIME_SLICE in CDR_FMT_DTL.

PGM_NM column represents the executables which are used to generate the corresponding call detail reports.

FILE_FMT column represents the format of columns which will be used and that can be identified by querying thetable CDR_FMT_DTL table using FILE_FMT.

All the above formats needs to be changed in CDR_FMT_DTL to display Rate by Minute as Transit fee andTermination Fee.

SEBS6520 Processes:

SEBS6521, SEBS6522, SEBS6523, SEBS6525 and SEBS6526 query the record from CDRV_CDR_PRIOD andgenerates Call detail Report. All there reports needs to be changed to display Transit and Termination fee separatelyas explained previously.

Query on CDRV_CDR_PRIOD needs to be changed on all the above SEBS652X programs to select rate_type andpopulate Rate by Call, Termination fee and Transit fee based on that.

Also each record file write program needs to be changed to print Termination and Transit fee separately.

SEBS6526 file_fmt is WEB which doesnt require any configuration change in CDR_FMT_DTL table.

SEBS6530:

SEBS6530 process also needs to be changed to show termination and transit fee separately.

SEBS6530 file_fmt is TG4 , which needs to converted as explained for ZZA 551 document. As part of thischanges 512/518 document will show Transit and Termination fee separately.


payment of damages.



34/41



Page 34 of 41

SEBS6446_SORT:

Sebs6446_sort is a shell program which is used to sort the records in call detail report for TG1 and TG2 format files. Itsorts based on fields. This field numbers passed to SORT function needs to be incremented by 1 based Terminationand transit fee numbers for TG1 and TG2.

TG1 sorting order should be changed as:

sort $file_name -o $file_name -t';' -k 1,1 -k 15,15 -k 16,16 -k 24,24 -k 25,25

TG2 sorting should be changed as:

sort $file_name -o $file_name -t';' -k 1,1 -k 13,13 -k 14,14 -k 22,22 -k 23,23

4.Data Specification

4.1 Data description

No change in external data sources. Only GBS internal Tables will be changed as part of this project.

Impacted Tables are explained in below section.

Following are the configurations that need to be added as part of this project:

1. PRODUCT:

New MPLS VTS products and VDT products needs to be configured in Product table.

2. SL_XREF:

SL_XREF is materialized view from OPSPRD. The configuration in SL_XREF will be changed as below:


payment of damages.



35/41



Page 35 of 41

SEQ_NO PRICG_SL_ID SERV_ABBR ROUTG_SL_ID ROUTG_SL_N ROUTE_SRVER_ID COMMT MAP_SERV_FL

1 1 VTS 1 Budget 11 Y

7 7 VTSMD 7 Mobile Direct 7 N

10 10 VTSPREM 10 Prime 10 Y

39 9 VTSPREF 9 Preferred 9 Y

51 VTSPRMX 10 Prime 10 Prime over IPX Y

51 MPLPREM 10 Prime 10 Prime over MPLS Y

58 MPLPREF 9 Preferred 9

Preferred over

MPLS Y

59 MPLVTS 1 Budget 11

Budget over

MPLS Y

60 VDT

Used for inputed

service N

61 MPLVDT

Used for inputed

service

MPLS based

customers N

The VTSPRMX will only disappear (terminated and not deleted) when all MPLS customers implemented inthe ECD phase will have been converted to the new services.

3. SERVICE_CGS:

New configurations will be inserted for new services will be entered to for OG_OFFER_ID.

4. RATNG_CRITR_MAP:

4. Record needs to be inserted for new services in SERVICE_BY_PRODUCT and SERVICE_BY_GROUP.

4.2 Data model and structure

Following Tables will be changed as part of this project:

1. PRODUCT:

COLUMN Data typeDEFAULT

DIRCT_AGRMT VARCHAR2(1) N

A trigger will be created for AFTER UPDATE statement to validate when the DIRCT_AGRMT flag ischanged from Y to N there is no mapping in BUS_REL_OPTN_MAP for this product with directagreement flag as Y.


payment of damages.



36/41



Page 36 of 41

2. BUS_REL_OPTN_MAP:


DIRCT_AGRMT_FL VARCHAR2(1) N

A trigger will be created for AFTER UPDATE or INSERT on this table to check DIRCT_AGRMT_FL is set to Yfor only the products which have DIRCT_AGRMT := Y in product table.

3. CPNY_ORG_STRUC_SEBS


DIRCT_AGRMT_FL VARCHAR2(1) N

4. SECS_MAPPING VIEW

COLUMN Mapping column

DIRCT_AGRMT_FL

BUS_REL_OPTN_MAP.DIRCT_AGRMT_FL

5. Following table will be created to store Rates details for which Cost is not covered in Pricing

VDT_ALARM_REP

COLUMN Data type

DEFAU

LTSYS_REQST_NO Number(10)

SUPP_CMS Number(6)

SUPP_CPNY_ID VARCHAR2(5)

SUPP_SECS Number(6)

SUPP_PRDCT_NO NUMBER(7)

SUPP_SERV_ABBR VARCHAR2(7)

CNTRY_ABBR VARCHAR2(3)

COST Number(11,4)

SUPP_CUR VARCHAR2(3)

SUPP_DEST_CCRN VARCHAR2(30)SUPP_RATE_EFFCT_FROM DATE

SUPP_RATE_EFFCT_TO DATE

CUST_CMS Number(6)

CUST_CPNY_ID VARCHAR2(5)

CUST_SECS Number(6)

CUST_PRDCT_NO NUMBER(7)

CUST_SERV_ABBR VARCHAR2(7)

RECVBL_TERMN_FEE Number(11,4)


payment of damages.



37/41



Page 37 of 41

RECVBL_TRANSIT_FEE Number(11,4)

PRICE Number(11,4)

CUST_CUR VARCHAR2(3)

CUST_CONV_RATE NUMBER(11,4)CUST_RATE_EFFCT_FROM DATE

CUST_RATE_EFFCT_TO DATE

ALARM_DT DATE

REC_CREAT_USER VARCHAR2(8) USER

REC_CREAT_DT DATESYSDA

TE

LAST_UPDT_USER VARCHAR2(8) USER

LAST_UPDT_DT DATESYSDA

TE

Monthly partition will be created on Alarm date.

4.3 Data conversion

Following Existing table data needs to be converted:

In RATE_CASE table, Rate case acces key column needs to change to include the Og_Offer_Id in the

key part. All the existing data of RATE_CASE table needs to be updated. Since no rates will exists byOg_Offer_Id at the time of the deployment, a * will be append to the current Rate_Case_Access_Keyfield in table RATE_CASE.

In PRODUCT table, existing records will be set with DIRCT_AGRMT column as N. Only new servicesVDT and MPLVDT will be set to Y

In BUS_REL_OPTN_MAP table, existing records will be set with N for DIRCT_AGRMT_FL.

In CPNY_ORG_STRUC_SEBS table, existing records will be set with N for DIRCT_AGRMT_FL.

SL_XREF table conversion already mentioned in Data description section.

4.3.1 Condition of existing system data

All the existing records will be converted for all tables mentioned in Data Conversion section.

4.3.2 Conversion strategy

Since RATE_CASE table is very huge, conversion script need to be prepared to convert records byCPNY_ID.


payment of damages.



38/41



Page 38 of 41

4.3.3 Conversion rules description

Data Conversion should be done on those existing tables before any new product/service records areinserted.

4.3.3.1 Common specifications

During USA Back Office Deployment, RATE_CASE table update took around 5 hours. So enough time

should be planned for data conversion and RATE_CASE table conversion can be started earlier.

4.3.3.2 Flat files specifications

Alarm for VDT/MPLVDT service Prices not covered by Cost will look as below:

Alarm.xlsx

5.Failure Management

5.1 Failure Analysis

Failure handling of the new alarms process will be set in Appwork as any other chains.

5.2 Integration with Trouble Ticket System

All APPWORX modules developed in this project will be changed to report ticket when there is abnormal

termination.

6.Handling of Non-Functional Requirements

6.1 Perform

0764 IPX Voice 220-00 (System Specifications) V1-3 2012-04-02

Documents

Transcript of 0764 IPX Voice 220-00 (System Specifications) V1-3 2012-04-02