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

Project: Document scope: File:
0764 IPX Voice GBS 0764 IPX Voice 220-00 (System Specifications) V1-30 2012-043-0262.doc
Page: 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: Date: Status:
1.30 2012-043-20276 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 the payment of damages. 2010, TATA communications or its affiliates. All rights reserved.
Page: Page 2 of 41
..................................................................................................................................................................................................1 1. DOCUMENT CONTROL..................................................................................................................................................3 1.1 1.2 1.3 1.4 VERSION HISTORY...........................................................................................................................................................3 REVIEW HISTORY............................................................................................................................................................3 FINANCIAL CONTROL REVIEW HISTORY...........................................................................................................................4 REFERENCED DOCUMENTS..............................................................................................................................................4
2. INTRODUCTION..............................................................................................................................................................4 2.1 CONTEXT ..............................................................................................................................................................................................4 2.2 SUMMARY OF SOLUTION.................................................................................................................................................5 2.3 SCOPE.............................................................................................................................................................................6 2.4 ASSUMPTIONS.................................................................................................................................................................6 2.5 INTENDED AUDIENCE......................................................................................................................................................7 2.6 ACRONYMS AND 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 DATA DESCRIPTION........................................................................................................................................................34 4.2 DATA MODEL AND STRUCTURE......................................................................................................................................35 4.3 DATA CONVERSION........................................................................................................................................................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 INTEGRATION WITH TROUBLE TICKET SYSTEM...............................................................................................................38 6. HANDLING OF NON-FUNCTIONAL REQUIREMENTS..........................................................................................38 6.1 PERFORMANCE .............................................................................................................................................................38 6.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
Page: 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 1.0 1.1 1.2 1.3 Date 2012-03-22 2012-03-23 2012-03-27 2012-04-02 Initial Version Incorporated review comments from Nirjhar/Ranga Incorporated Michels Review comments 1. Removed SEBS6530 changes 2. Change Rate entry Og_Offer_Id LOV source value from CMS_CUSTOMER to BUS_REL_OPTN_MAP [Date format is yyyy-mm-dd.] Description of Changes Made by Thiru K/Andrews Thiru K/Andrews Thiru K/Andrews Thiru K
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
Page: 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. 2. 0764 IPX Voice-110-00 (High Level Architecture-GBS) V3 0 2012-02-13.docx 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 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. Currently this MPLS traffic is tagged to service VTSPRMX. For this service prices are being provided by PULSE and Costs are being provided by Reflex and GTM. GTM provides USA termination rates where as reflex provide rest of the world costs. With this current set-up, it is difficult to provide more visibility to MPLS traffic. The main goal of this project is to provide more intelligent call routing features by segregating the MPLS customer traffic 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 by minute. 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
Page: Page 5 of 41
goal, we are going to offer 3 MPLS counterpart services for each VTS services [MPLVTS, MPLPREM and MPLPREF]. 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 a supplier. 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 of Cascade agreement, TCL will charge both usage and Transit fee from the customer. Cascade or Direct agreement 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 be involved in maintaining the VDT prices, to maintain the syncornization between costing and pricing rates, a new alarm 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_ID detail 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 VTS services VTSPREM, VTSPREF and VTS respectively to segregate the MPLS traffic. 2. These MPLS counterpart VTS services will receive rates from Pulse and reflexes as VTS services. 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 a profile, 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) flag in product and profile tables. 6. Product Screen will be changed to have Direct Agreement flag to identify the products which can have direct/cascade aggrement 7. A new grouping flag will be added for Payable profiles. If it is set we can have multiple CMS_Ids for same profile. 8. A new column Og_Offer_Id will be added in RATE_CASE tables to store outgoing CMS information.
Page: Page 6 of 41
Rating Module 9. For Direct agreement traffic, payable part of the call will be discarded with No rating for Direct agreement. 10. For receivable part rating, rate will be identified by matching the OG_CMS_ID from Rate_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_Id needs 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 in Rate per Minute column. New Alarm: 13. A new alarm will be generated when Receivable cost is not covering the Payable cost for VDT services.
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 receivable rates. 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 minute column. 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 for maintaining 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 Rate upload 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 MPLVDT services. 8. Since there is a dependency with Dept. Billing project which opens up receivable part scope to store multiple CMS_Ids, it has to be deployed affront to this project.
Page: 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 types of readers: Architect/Tech Lead (Reviewer) Background and required level of understanding o o Has a very good technical background of the areas of subject matter (there can be more than one). 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 why he/she scored in a certain way. The alignment with the HLA is the responsibility of the architect.
Subject Matter Expert (SME) Background and required level of understanding o o Has a very good technical background of the corresponding subject matter (which might only cover a part of the System Spec content). Should be able to fully understand that part of the document which deals with the design related to his/her subject matter.
Purpose of reading the document 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 Background and required level of understanding o o o Has a very good technical background of the corresponding subject matter. Developer should be familiar with that part of the document which he/she has to implement. Developer Lead should be able to fully understand the whole document; even if he/she is only responsible for implementing a part of the design.
Purpose of reading the document o Uses the design description of this document to implement the part of the design he/she is
Page: Page 8 of 41
responsible for. Tester Background and required level of understanding o Tester should be able to fully understand the document.
Purpose of reading 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 System
Billing
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.
Page: 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 VVPN
Pricing System Voice Virtual
Pricing application provides receivable rate to GBS 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.
Private Network
CDR
Call Report
Detail
Records containing detailed information about a call at network level.
Page: 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 Payable rates 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 are stored in GBS with rate type: = 1. These usage rates cover both termination and transit fee. GBS have flexibility to store transit fee rates [rate type: =3] and per call rates [rate type: =2]. But Rate per call and transit fee rates can 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 being handled 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 showed under one column Rate by Min in invoice and Call detail report. Customer doesnt have flexibility to view the termination and transit fee separately. Mapping Screen: After the 783 Departmental Billing project the value Y for INVCE_GRPNG_FL field is possible only for the 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. For payable INVCE_GRPNG_FL should be always N
Page: 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 find the 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).
Page: Page 12 of 41
3.1.1
Data Flow Diagram:
1- SECS system sends the new supplier creation , close supplier, change in the product or organization or billing entity or cms cust id , upgrade or downgrade of the product transaction to Reflex/GTM 2- Supplier submits the rate-sheets for Non-USA supplier in Reflex and USA supplier rate sheets in GTM. 3- Reflex/GTM system process and send supplier rate-sheets to GBS system 4- 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.
Page: Page 13 of 41
3.2 TO-BE
3.2.1
Context Diagram:
Page: 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 MPLS counterpart VTS services will be created [MPLVTS, MPLPREF and MPLPREM]. MPLS counter-part VTS services 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 so Call_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 a customer to a particular profile. Customer and Supplier can have either Direct or Cascade agreement between them. Direct Billing: An agreement is in effect between the customer and the supplier. For TCL point of view, we will not expect to pay anything to the supplier for the calls and we will receive a transit fee from the customer that will represent 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 the customer a termination fee that should normally cover the costs to the supplier plus a transit fee that will represent 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 will have 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:
Page: Page 15 of 41
Call 1 2 3 4 5
IC admin A A B B B
IC CLLI Serv VDT VDT MPLVDT MPLVDT MPLVDT
IC Serv
RTE In serv VDT VTS MPLVDT VTS VTS
IC CMS Id 111 111 222 222 222
OG admin C C D GHI JKL
OG CLLI Serv VDT VTS MPLVDT VTS VTSPREF
OG Serv
RTE Out Serv VDT
OG CMS id 331 335 444 6789 7890
Serv Abbr VDT VDT MPLVDT MPLVDT MPLVDT
Rte In Serv FIN VDT VTSPREF MPLVDT MPLPREM MPLPREM
Inputed Serv VDT VDT MPLVDT MPLVDT MPLVDT
Not VDT Not in (VDT, MPLVDT) Not in (VDT, MPLVDT)
Not VDT MPLVDT Not in (VDT, MPLVDT) Not in (VDT, MPLVDT)
In the above examples, GBS will search for VTS route in services in the SL_XREF and will find an active entry with a MAP_SERV_FL = Y. From there, GBS will be using the contracted service associated to the inbound CMS id which will drive to VTSPREF / MPLPREM and therefore using the prices provided by Pulse. In other words, 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 information and 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 for the 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 of this project payable product scope will be opened to have multiple Cms ids for same product.
Page: Page 16 of 41
To identify the CMS link to a direct agreement, a new field DIRCT_AGRMT_FL will be added in BUS_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: 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. 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.
UPGRADE-DOWNGRADE: Upgrade-Downgrade action is not applicable for VDT products as this is only applicable for VTS products.
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. please choose 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:
Page: Page 17 of 41
Consolidation is not possible for the VDT product since consolidation is only possible for the services which have 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 products which 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 or more business relation(s) associated to this product) will be thrown. The field will be added as mentioned in the image below
Page: 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. The Receivable rates for VDT (MPLVDT) will always entered manually through rate upload or Rate entry. A new column Og_Offer_Id will be added in RATE_CASE table to store the supplier information which hold the agreement with the customer. All VDT(MPLVDT) receivable rates should have Og_Offer_Id tagged.
Page: 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 are entered in a excel file and uploaded through the screen SERM0208. The rates will be first entered into temp table RATE_ULOAD_TMP and later processed using RATE_ULOAD_PACK. Following are the changes to be done in Screen and SQL file: 1. 2. Change the CSV file Template format to include Og_Offer_Id. In screen SERM0208, populate the Og_Offer_Id information into RATE_ULOAD_TMP table along with other columns.
3. In Serm_0208.sql file, CR_RATE_ULOAD_RJCT cursor will be changed to select Og_Offer_Id information from 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 to be 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 with OG_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
Page: Page 20 of 41
with * c. BUILD_RATE_CASE_ACCES_KEY and BUILD_RATE_CASE_ACCES_KEY_PART Function which generates 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 the population 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 receivable rates:
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] and 2 [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_CUSTOMER BUS_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.
Page: 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 costs are not covering our prices. This activity is currently handled by reflex and pricing. Due budget constraint since PULSE is not going to make changes to handle VDT supplier rates, a alarm needs to be generated from GBS when 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 and the data which need to goes into the report will be inserted into this table first. Report will be then printed from 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 USA termination rates, we will be able to compare the rates only when they become effective. GTM doesnt send the 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 level rate then it should be displayed under DNIS column in Alarm report.
Page: Page 22 of 41
Appworx module SERM_CHN_VDT_ALARM_REP will be created newly. This job will be scheduled to run at 12:00 hours EST every day. The job is being scheduled at 12:00 hours to give time for rate integration process to integrate new rates for that day. Appworx module SERM_CHN_VDT_ALARM_REP will be calling the chain SERM_CHN_VDT_ALARM_REP under the 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 costing rates not covered by pricing rates. Also creates a csv file with same information inserted into the table and written into Alarm 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 from CONFG_PARM table. PRCSS_NM := SERM0220, PARM_NM := REMOTE_DIR and the directory path will be /SERM/gbsprd/VDT_Alarm
Page: 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) as below:
SELECT DISTINCT rate_plan.og_offer_id, rate_case.cntry_dest FROM serm.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_ID AND RATE_CASE.RATE_CASE_NO = RATE.RATE_CASE_NO aND RATE.RATE_STAT = 'APP' AND RATE_CASE.RATE_CAT <> 'ER' and incom_type='R' and RATE_PLAN.SERV_ABBR in(VDT, MPLVDT) and effct_clos_dt>=sysdate
2. As we have the list of supplier CMS_IDs which are mapped to receivable rates, now we have to identify the amount we are paying for those suppliers for the same service. This is identified by selecting the payable rates belonging to the CMS_IDs and country we identified in previous query. Since the payable rates will be mostly 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 FROM serm.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' and incom_type='P' and RATE_PLAN.SERV_ABBR in(VDT, MPLVDT) and rate_plan.cpny_id=bro.cpny_id and rate_plan.org_no=bro.org_no and rate_plan.prdct_no=bro.prdct_no and brom.cpny_id=bro.cpny_id and brom.org_no=bro.org_no and brom.optn_rel_no=bro.optn_rel_no And brom.cms_cust_id = :og_offer_id defined on the customer price And rate_case.cntry_dest = :cntry_dest on the customer price and effct_clos_dt>=sysdate And rate_amt > 0 Oder by RATE_CASE.CNTRY_DEST, RATE_CASE.DEST_CCRN, RATE.RATE_EFFCT_DT;
Page: Page 24 of 41
Rate amount should be greater than zero because we want to compare the cascade supplier rates. In case of 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 dont have 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 Feb 1st To Feb 28 countr y FCE CCRN 331 rate 5 Cur US D Typ e 1 CMS 2000
If Receivable rates are:
Org_n o 10 10 10
From Jan 1st Feb 1 Feb 16
To 2999 Feb 15 2999
countr y FCE FCE FCE
rate 5 1 2
Cur US D US D US D
Typ e 1 3 3
Outgoing CMS 2000 2000 2000
First Transit fee will be retrived as: Org_n o 10 From 1 Feb To 28 Feb countr y FCE rate 5 Cur US D Typ e 1 Outgoing CMS 2000
Different periods need to be considered when summing up Transit and Termination fee. For example here Receivable rates will be splitted into 2 records since Transit fee rate have 2 periods [01-Feb to 15-Feb] and [16Feb-28-Feb]
Org_n o
From
To
countr y
terminatio n
transi t
Tota l
Cur
Outgoing CMS
Page: Page 25 of 41
10 20
Feb 1st Feb 16st
Feb 15th Feb28th
FCE FCE
5 5
1 2
6 7
US D US D
2000 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 Feb 1st Mar 1st
To Feb 28 2999
countr y FCE FCE
CCRN 331 331
rate 5 8
Cur US D US D
Typ e 1 1
CMS 2000 2000
For the customers, we have those prices:
Org_n o 10 10 20 20 20 30
From Jan 1st Jan 1st Jan 1st Feb 16th Jan 1st Jan 1st
To 2999 2999 Feb15t h 2999 2999 2999
countr y FCE FCE FCE FCE FCE FCE
Rate 5 1 5 8 1 5
Cur US D US D US D US D US D US D
Typ e 1 3 1 1 3 1
Outgoing CMS 2000 2000 2000 2000 2000 2000
Page: Page 26 of 41
30 40 40
Jan 1st Jan 1st Jan 1st
2999 2999 2999 FCE
1 5 1
US D EU R EU R
3 1 3
2000 2000 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 10 20 20 30 40 From Feb 1st Feb 1st Feb 16th Feb 1st Feb 1st To Feb 28th Feb15th Feb 28th Feb 28th Feb 28th countr y FCE FCE FCE FCE FCE termination 5 5 8 5 5 transit 1 1 1 1 1 Tota l 6 6 9 6 6 Cur US D US D US D US D EU R Outgoing CMS 2000 2000 2000 2000 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 is covering the 8 USD cost assuming the conversion EUR->USD is over 1,25 Org_n o 10 20 30 40 From Mar 1st Mar 1st Mar 1st Mar 1st To 299 9 299 9 299 9 299 9 countr y FCE FCE FCE FCE terminatio n 5 8 5 5 transi t 1 1 1 1 Tota l 6 9 6 6 Cur US D US D US D EU R Outgoing CMS 2000 2000 2000 2000
Page: 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 direct agreement, if the Direct agreement Flag is set to Yes in CPNY_ORG_STRUC_SEBS for IC part of the call, 2. In Rating, changes needs to be done to compare CDRV field FACTR_APPL_BASIS_1 with OG_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 from CPNY_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 process simultaneously. There will be two rate segments in memory at a time. One will be completely loaded and for other loading will be in progress. Once the later one is completely loaded first segment will be de-referenced and new 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.
Page: Page 28 of 41
In WriteRateLoadLog (), details of the rate being loaded will be written to a output file. Add OG_FFER_ID parameters 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 fields FACTR_APPL_BASIS_1column to choose the receivable rate specific to outgoing CMS_ID. This comparison mapping 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 and CDRV_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 characteristic no 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 rate will 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 configuration needs 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 have CD_FACTRE_APPL_BASIS_1 value as T. This is just a piloting activity,
3.3.1.3 Invoice Modifications:
Page: 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 table SEBS6442_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 and existing 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 and MTH_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), DECODE( cs.rate_appl_unit_meas_t2, 'SEC', (cs.rate_amt_t2 / cs.rate_appl_basis_t2 * 60), 'MIN', (cs.rate_amt_t2 / cs.rate_appl_basis_t2 * 1), DECODE( cs.rate_appl_unit_meas_t3, 'SEC', (cs.rate_amt_t3 / cs.rate_appl_basis_t3 * 60), 'MIN', (cs.rate_amt_t3 / cs.rate_appl_basis_t3 * 1), 0))) RATE_BY_MIN,
The RATE_BY_MIN value needs to be selected as two columns TRANSIT_FEE and TERMN_FEE. The query will 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, 'SEC', (cs.rate_amt_t1 / cs.rate_appl_basis_t1 * 60), 'MIN', (cs.rate_amt_t1 / cs.rate_appl_basis_t1 * 1), DECODE( cs.rate_type_t2, 1, DECODE( cs.rate_appl_unit_meas_t2,
Page: Page 30 of 41
'SEC', (cs.rate_amt_t2 / cs.rate_appl_basis_t2 * 60), 'MIN', (cs.rate_amt_t2 / cs.rate_appl_basis_t2 * 1), DECODE( cs.rate_type_t1, 3, DECODE( cs.rate_appl_unit_meas_t3, 'SEC', (cs.rate_amt_t3 / cs.rate_appl_basis_t3 * 60), 'MIN', (cs.rate_amt_t3 / cs.rate_appl_basis_t3 * 1), 0))) TERMN_FEE, DECODE( cs.rate_type_t1, 3, 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)), DECODE( cs.rate_type_t2, 3, DECODE(cs.rate_appl_unit_meas_t2, 'SEC', (cs.rate_amt_t2 / cs.rate_appl_basis_t2 * 60), 'MIN', (cs.rate_amt_t2 / cs.rate_appl_basis_t2 * 1)), DECODE( cs.rate_type_t3, 3, DECODE(cs.rate_appl_unit_meas_t3, 'SEC', (cs.rate_amt_t3 / cs.rate_appl_basis_t3 * 60), 'MIN', (cs.rate_amt_t3 / cs.rate_appl_basis_t3 * 1), 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 1 if 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 2 is 1 then Termination fee = rate amount 2 if Rate type 3 is 1 then Termination fee = rate amount 3 if Rate type 1 is 3 then Transit fee = rate amount 1 if Rate type 2 is 3 then Transit fee = rate amount 2 if Rate type 3 is 3 then Transit fee = rate amount 3 3. Insert command in the procedure will be changed to insert into SEBS6442_CDRV_MTH_SUM_TEMPtable with 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
Page: 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 =ZZA from 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 two lines[ one for TRANSIT FEE and another for TERMINATION FEE]. All the records after RATE_TIME_SLICE have to increment the COL_NO value by 1. After changes records in CDR_FMT_DTL for format ZZA will look as below:
Page: 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 the comparisons 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. The file is in a comma separated format (csv) and available information that could populate on the report need to be program. This list of different CDR document available could be retrieved from table DOC_FMT with the call_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 programs to generate them:
select * from doc_fmt where call_dtl_fl='Y';
Page: Page 33 of 41
DOC_FMT_ID INTNL_DESC
IMAGE_OR_REC FILE_FMT WEB UA1 TG1 TG2 WEB TG1 TG2 TG3 TG3 TG4 TG5 VSI VSO
PGM_NM SEBS6526 SEBS6446_SORT SEBS6446_SORT SEBS6446_SORT SEBS6446_SORT SEBS6446_SORT SEBS6446_SORT SEBS6446_SORT SEBS6446_SORT SEBS6530 SEBS6446_SORT SEBS6446_SORT SEBS6446_SORT
520 Not Invoiced Call Detail for WEB daily - flat file R 515 Invoiced Call detail for ITFS with SAC - flat file R 507 Invoiced Call detail for retail - flat file 508 Invoiced Call detail for wholesale - flat file 509 Invoiced Call Detail for WEB - flat file 510 Declared Call detail for retail - flat file 511 Declared Call detail for wholesale - flat file 513 Payable Call Detail for declaration 514 Payable Call Detail for invoiced traffic 518 Invoiced Call detail for wholesale - flat file 519 New CDR for Ivroy R R R R R R R R R
600 Invoiced Call detail for Geneva (INBOUND - R 800) 601 Invoiced Call detail for Geneva (OUTBOUND - R IDDD)
*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 the table 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 and Termination Fee. SEBS6520 Processes: SEBS6521, SEBS6522, SEBS6523, SEBS6525 and SEBS6526 query the record from CDRV_CDR_PRIOD and generates Call detail Report. All there reports needs to be changed to display Transit and Termination fee separately as explained previously. Query on CDRV_CDR_PRIOD needs to be changed on all the above SEBS652X programs to select rate_type and populate 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 this changes 512/518 document will show Transit and Termination fee separately.
Page: 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. It sorts based on fields. This field numbers passed to SORT function needs to be incremented by 1 based Termination and 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:
Page: Page 35 of 41
S EQ_NO 1 7 10 39 51 51 58 59 60
PRICG_SL_ID
S ERV_ABBR 1 VTS 7 VTS MD
ROUTG_SL_ID ROUTG_S L_NMROUTE_SRVE R_ID 1 Budg et 7 Mobile Direct 10 Prime 9 Preferred 10 Prime 10 Prime 9 Preferred 1 Budg et 11 7 10 9
COMMT
MAP_S ERV_FL Y N Y Y Y Y Y Y N
10 VTS PREM 9 VTS PREF VTS PRMX MPLPRE M MPLPRE F MPLVTS VDT
10 Prime over IPX 10 Prime over MPLS Preferred over 9 MPLS Budg et over 11 MPLS Used for inputed service Used for inputed service MPLSbased customers
61
MPLVDT
The VTSPRMX will only disappear (terminated and not deleted) when all MPLS customers implemented in the 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 DIRCT_AGRMT
Data type VARCHAR2(1)
DEFAU LT N
A trigger will be created for AFTER UPDATE statement to validate when the DIRCT_AGRMT flag is changed from Y to N there is no mapping in BUS_REL_OPTN_MAP for this product with direct agreement flag as Y.
Page: Page 36 of 41
2. BUS_REL_OPTN_MAP:
COLUMN
DIRCT_AGRMT_FL
DEFAU LT N
A trigger will be created for AFTER UPDATE or INSERT on this table to check DIRCT_AGRMT_FL is set to Y for only the products which have DIRCT_AGRMT := Y in product table. 3. CPNY_ORG_STRUC_SEBS
COLUMN
DIRCT_AGRMT_FL
DEFAU LT N
4. SECS_MAPPING VIEW
COLUMN
DIRCT_AGRMT_FL
Mapping column BUS_REL_OPTN_MAP.DIRCT_AGR MT_FL
5. Following table will be created to store Rates details for which Cost is not covered in Pricing VDT_ALARM_REP
COLUMN SYS_REQST_NO SUPP_CMS SUPP_CPNY_ID SUPP_SECS SUPP_PRDCT_NO SUPP_SERV_ABBR CNTRY_ABBR COST SUPP_CUR SUPP_DEST_CCRN SUPP_RATE_EFFCT_FRO M SUPP_RATE_EFFCT_TO CUST_CMS CUST_CPNY_ID CUST_SECS CUST_PRDCT_NO CUST_SERV_ABBR RECVBL_TERMN_FEE
Data type Number(10) Number(6) VARCHAR2(5) Number(6) NUMBER(7) VARCHAR2(7) VARCHAR2(3) Number(11,4) VARCHAR2(3) VARCHAR2(30) DATE DATE Number(6) VARCHAR2(5) Number(6) NUMBER(7) VARCHAR2(7) Number(11,4)
DEFAU LT
Page: Page 37 of 41
RECVBL_TRANSIT_FEE PRICE CUST_CUR CUST_CONV_RATE CUST_RATE_EFFCT_FRO M CUST_RATE_EFFCT_TO ALARM_DT REC_CREAT_USER REC_CREAT_DT LAST_UPDT_USER LAST_UPDT_DT
Number(11,4) Number(11,4) VARCHAR2(3) NUMBER(11,4) DATE DATE DATE VARCHAR2(8) DATE VARCHAR2(8) DATE
USER SYSDA TE USER SYSDA 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 by Og_Offer_Id at the time of the deployment, a * will be append to the current Rate_Case_Access_Key field in table RATE_CASE. In PRODUCT table, existing records will be set with DIRCT_AGRMT column as N. Only new services VDT 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 by CPNY_ID.
Page: 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 are inserted.
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 Performance
Rate tables queries in new alarm process should be proper indexes and should not consume much time.
Page: Page 39 of 41
6.1.1
Response time
The new Appworx module SERM_CHN_VDT_ALARM_REP should be completed 1 hour to compare Pricing and costing rates for current and future periods.
6.1.2
Capacity
New module SERM_CHN_VDT_ALARM_REP should be able to handle any number of rates.
6.1.3
Scalability
New table SERM_VDT_ALARM_REP can be monthly partitioned considering long run.
6.2 Reliability
New module SERM_CHN_VDT_ALARM_REP should not abort. All error should be handled internally.
6.3 Security
Security applicable to existing module is applicable to the new module SERM_CHN_VDT_ALARM_REPalso.
6.4 Manageability
Not Applicable
6.4.1
Installation and Deployment
As part of this project Oracle Forms, Report, Delphi screen, UNIX components will be deployed. But these are existing components and list of impacted components will be shared during deployment plan review.
6.4.2
Upgrade
Not required.
Page: Page 40 of 41
6.4.3
Configuration
Table configurations are mentioned in Data description section.
6.4.4
Retention, Archive and Backup Strategy
To remove data more than 3 months for table SERM_VDT_ALARM_REP, following configuration will be added in COFG_PARM table. PRCSS_NM;= MONTH_TO_KEEP_BY_TABLE and PARM_NM:=SERM_VDT_ALARM_REP
6.4.5
Performance Management
Not applicable as we dont expect any performance load on the system due to this project.
6.4.6
Troubleshooting
Please refer failure handling
6.4.7
Other Maintenance Activities
Not Applicable
7. Development Tools and Technologies

Type of Component (DB, AS, GUI, Integration, ) Technology used for Component; also version (e.g.: Oracle 11g) Oracle 10.2.0.4 Delphi2010 Dev tools to be used (e.g. Eclipse 3.3) Dev test systems to be used
DB GUI
N/A Delphi 2010
N/A Windows XP and below operating system and BDE 5.0 Appworx
Appworx(Third Party Tool,GUI to launch jobs)
Appworx 6
Appworx
Page: Page 41 of 41
AS
Pro*C
Pro*C /Forte Developer 6.0 as compiler sqlplus/unix
Appworx
AS
PL/SQL
Appworx
8. Test Aspects
Create new supplier mapping transactions from SECS with direct and cascade agreement and then receive the Reflex VDT rate-sheet for the CMS defined as Cascade agreement. Process the rate sheet in GBS and verify the rates. For Direct agreement, set the direct agreement flag to Yes in the Mapping, No SECS_TRX should be created. Traffic on the supplier under Direct agreement should have the supplier discard while the traffic on the same supplier under the Cascade agreement will be rates using the Costs of Reflex. For the customer part, the prices should be set by outgoing CMS (Direct or Cascade). Create new supplier transactions in SECS for MPLS services and then received the rates from Reflex Create new customer transactions in SECS for MPLS services and then received the rates from Pulse Set-up manually VDT prices link to their specific cost sheets by the og_offer_id Process VDT traffic and make sure the appropriate sheets is used based on the og_offer_id (factr_appl_basis_1) When Rte in serv abbr is VDT or MPLVDT. Process VDT traffic when Rte in serv_abbr is not VDT or MPLVDT. Set-up VDT prices that doesnt cover the costs and make sure those entries are present in the Alarm report. Trial when supplier is cascade, trial when supplier is cascade, trial when costs are provided by GTM Check the invoice and declaration CDR reports whether both Termination and Transit fees columns are coming. In Alarm report, following things needs to be tested All CCRN payable rates for a supplier is compared with country level receivable rates. Different period in payable / receivable side needs to be correctly compared. While selecting receivable rates both usage and transit fee needs to be compared FTP process needs to be validated Mailing process needs to be validated
9. Open Issues
ID Description Raised by whom, when Responsible person Status resolve

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

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

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

Uploaded by

Copyright:

Available Formats

Project: Document scope: File:

220-00 System Specifications

Version: Date: Status:

1.30 2012-043-20276 Final

Project: Document scope: File:

Project: Document scope: File:

1.2 Review History

Project: Document scope: File:

off version 1.0. Signature is an attached email received from a reviewer]

1.3 Financial Control Review History

1.4 Referenced Documents

Project: Document scope: File:

2.2 Summary of Solution

Project: Document scope: File:

Project: Document scope: File:

2.5 Intended Audience

Project: Document scope: File:

2.6 Acronyms and Terminology

Tata communications Ltd

Billing and Invoicing system for Voice Switched Services

Rate Management System Rate management system.

Multiprotocol Label Switching

Project: Document scope: File:

Internetwork Packet Exchange

Pricing System Voice Virtual

Records containing detailed information about a call at network level.

Project: Document scope: File:

Project: Document scope: File:

Overview of current Send paid Rating:

Project: Document scope: File:

Data Flow Diagram:

Project: Document scope: File:

Project: Document scope: File:

VTS MPLS service:

VDT (MPLVDT) Service:

Project: Document scope: File:

IC CLLI Serv VDT VDT MPLVDT MPLVDT MPLVDT

RTE In serv VDT VTS MPLVDT VTS VTS

IC CMS Id 111 111 222 222 222

OG admin C C D GHI JKL

OG CLLI Serv VDT VTS MPLVDT VTS VTSPREF

RTE Out Serv VDT

OG CMS id 331 335 444 6789 7890

Serv Abbr VDT VDT MPLVDT MPLVDT MPLVDT

Rte In Serv FIN VDT VTSPREF MPLVDT MPLPREM MPLPREM

Inputed Serv VDT VDT MPLVDT MPLVDT MPLVDT

Not VDT Not in (VDT, MPLVDT) Not in (VDT, MPLVDT)

Not VDT MPLVDT Not in (VDT, MPLVDT) Not in (VDT, MPLVDT)

Project: Document scope: File:

Project: Document scope: File:

Project: Document scope: File:

3.3 DES.0.4- CPNY_ORG_STRUC_SEBS population:

Project: Document scope: File:

Project: Document scope: File:

Following is the change in the Rate upload template:

Project: Document scope: File:

Project: Document scope: File:

Project: Document scope: File:

Project: Document scope: File:

If Receivable rates are:

From Jan 1st Feb 1 Feb 16

To 2999 Feb 15 2999

countr y FCE FCE FCE

Outgoing CMS 2000 2000 2000