Arbor

The Steps for Test Cases execution for Arbor are divided into following sub sections:

1) Verify the Customer and the MSISDN exists in Arbor DB and are valid.
2) Verify that the Price Plan attached in Clarify to the MSISDN gets Activated/De-activated
to the same MSISDN in Arbor also.
3) Verify that the Discounts attached in Clarify to the MSISDN gets Activated/De-activated to
the same MSISDN in Arbor also.
4) Performing the Sample Billing for the Account for next billing cycle
5) Generate the invoice in DOC1 to verify that the Price Plan and discounts are correctly
applied.

The above sub sections are described with detailed Steps below:

 Verify the Customer and the MSISDN exists in Arbor DB and are valid.
The following steps are executed for the verifications:

Step 1: Run the following query in the CATALOG database in FACTT_MS to verify that the
Customer Account as specified in the Clarify exists in Arbor:

select account_no from EXTERNAL_ID_ACCT_MAP where external_id = '09521907'

where value of External ID is the Clarify Account No.

If the query doesn’t retrieve any value, the Account is not present in Arbor. If the Account No. is
returned by query, the account exists in Arbor DB. Take a note of this account_no.

Step 2: Run the following query in the CATALOG database in FACTT_MS to verify that the
Customer Account as specified in the Clarify exists in Arbor:

select * from EXTERNAL_ID_EQUIP_MAP where external_id = '661301928'

where value of External ID is the MSISDN no.

If the query doesn’t retrieve any value, the MSISDN is not present in Arbor. If the query returns a
row, verify that the MSISDN is active on the same account as retrieved in Step 1. Take a note of
subscr_no and server_id field. The server_id will provide the Customer Database to which the
Account belongs as the Customer Database to which the Account belongs will be always
server_id-2. For example, if the value of server_id retrieved is 17, then Customer Database to
which the Account belongs is 17-2=15.

 Verify that the Price Plan attached in Clarify to the MSISDN gets
Activated/De-activated to the same MSISDN in Arbor also.
The following steps need to be executed:

Step 1: Login to the MIDDLET_MS DDBB using username PPR_BATCH and password as
psbatch and run the following query:
select * from x_mapping where cla_id in ('<Name of the Price Plan in Clarify>')

Take a note of arb_id and arb_type values retrieved from the query.
Step 2: Based on the Customer Database where the account reside in FACTTxx_MS DDBB,
where xx is 01 if the Account resides in Customer Database 15 to 20 or the value of xx is 03 if the
account resides in Customer Database 1 to 14.

If arb_type is product, then run the following query to verify that the Price Plan is active for the
MSISDN or not else Go to Step 3:

select P.element_id,product_active_dt, product_inactive_dt, D.description_text

from PRODUCT P, PRODUCT_ELEMENTS PE, DESCRIPTIONS D
where P.parent_subscr_no= <Value of subscr_no retrieved from Step 2 in “Verify the Customer and the MSISDN
exists in Arbor DB and are valid“ section>
and P.element_id = PE.element_id
and PE.description_code=D.description_code
and P.element_id in (<Value of arb_id retrieved in previous step>)

If we need to verify that the Price Plan is active for the Account, verify that the Activation Date is
correctly applied and Inactive Date is Null. If we need to verify that the Price Plan is deactivated,
verify that the Activation date and Deactivation Date is correctly shown.

Go to “Verify that the Discounts attached in Clarify to the MSISDN gets Activated/De-
activated to the same MSISDN in Arbor also” section

Step 3: If arb_type is ppkg, then run the following steps of queries to verify that the Price Plan is
Active/Inactive.

select PC.package_id, PC.component_id, PCM.member_id, PCM.member_type

from PACKAGE_COMPONENTS PC, PACKAGE_COMPONENT_MEMBERS PCM
where package_id in (<Value of arb_id retrieved in Step 1>)
and PC.component_id=PCM.component_id

Take a note of the member_id value retrieved in this query where the value of member_type is 1.

Now run the following query:

select P.element_id,product_active_dt, product_inactive_dt, D.description_text
from PRODUCT P, PRODUCT_ELEMENTS PE, DESCRIPTIONS D
where P.parent_subscr_no= <Value of subscr_no retrieved from Step 2 in “Verify the Customer and the MSISDN
exists in Arbor DB and are valid“ section>
and P.element_id = PE.element_id
and PE.description_code=D.description_code
and P.element_id in (<Value of member_id retrieved in previous step>)

If we need to verify that the Price Plan is active for the Account, verify that the Activation Date is
correctly applied and Inactive Date is Null. If we need to verify that the Price Plan is Deactivated,
verify that the Activation date and Deactivation Date is correctly shown.
 Verify that the Discount attached in Clarify to the MSISDN gets
provisioned to the same MSISDN in Arbor also.
The following steps need to be executed for verifications

Step 1: Login to the MIDDLET_MS DDBB using username PPR_BATCH and password as
psbatch and run the following query:
select * from x_mapping where cla_id in ('<Name of the Discount in Clarify>')

Take a note of arb_id and cla_id values retrieved from the query.

Step 2: Based on the Customer Database where the account reside in FACTTxx_MS server,
where xx is 01 if the Account resides in Customer Database 15 to 20 or the value of xx is 03 if the
account resides in Customer Database 1 to 14.
Run the following query to verify that the discounts are Active/Inactive

select CC.contract_type, CC.contract_level, D.description_text,CC.start_dt, CC.end_dt

from CUSTOMER_CONTRACT CC, CONTRACT_TYPES CT, DESCRIPTIONS D
where CC.parent_subscr_no=<Value retrieved from Step 2 in “Verify the Customer and the MSISDN exists in
Arbor DB and are valid“ section>
and CC.contract_type=CT.contract_type
and CT.description_code=D.description_code
and CC.contract_type in (<Value of arb_id retrieved in Step 1>)

If we need to verify that the Discount is active for the Account, verify that the Activation Date is
correctly applied and Inactive Date is Null. If we need to verify that the Discount is deactivated,
verify that the Activation date and Deactivation Date is correctly shown.

 Performing the Sample Billing for the Account for next billing cycle
Once the Price Plan and Discount verification is done, we need to run the sample billing for the
next billing cycle to validate the change in the Price Plan and the Discount reflect in the Invoice
correctly. Following steps are performed for the same:

Step 1: Based on the Customer Database where the account reside in FACTTxx_MS DDBB,
where xx is 01 if the Account resides in Customer Database 15 to 20 or the value of xx is 03 if the
account resides in Customer Database 1 to 14. Check the billing cycle to which the account has
been billed using the following query

select account_no, to_date, from_date, format_status, prep_date, bill_ref_no, prep_error_code,

process_num from BILL_INVOICE
where account_no= <Value retrieved from Step 1 in “Verify the Customer and the MSISDN exists in Arbor DB and
are valid“ section>
and prep_status = 1 and prep_error_code = NULL and process_num = '1'

Take a note of to_date and from_date fields to find if the billing cycle for the account is the current
billing cycle or not. The billing cycle is the current billing cycle if the account has been billed till the
current month. For example, if the account is billed on 1 st of every month and we execute the
above query on 29th Oct, then the current billing cycle for the account will have from_date as 1 st
Sept and to_date as 31st Oct.

Step 2: If the billing cycle for the account as retrieved from previous step is not the current billing
cycle, we need to bring the account to current billing cycle. But if the billing cycle is the current
cycle, Go to Step 5. To bring the account to current cycle we need to follow following steps:
Step 3: Prepare to run the normal billing for the account to bring it to the current billing cycle.
Run the following set of queries for the same:
select * from FC_BIP_CYCLE_ACCOUNTS where account_no = <Value retrieved from Step 1 in “Verify
the Customer and the MSISDN exists in Arbor DB and are valid“ section>

If the query returns values for the the account, use the following query delete the values:

delete from FC_BIP_CYCLE_ACCOUNTS where account_no = <Value retrieved from Step 1 in “Verify
the Customer and the MSISDN exists in Arbor DB and are valid“ section>

Run the following query to insert value into the table:

insert into FC_BIP_CYCLE_ACCOUNTS values ( Value retrieved from Step 1 in “Verify the Customer and the
MSISDN exists in Arbor DB and are valid“ section>,0,1)

Step 4: Run normal billing for the account.

4.1 Run one of the Pre-BIP processes as mentioned below based on the Customer
Database to which the account belongs:
CUSTOMER_01 FEARB041L
CUSTOMER_02 FEARB042L
CUSTOMER_03 FEARB043L
CUSTOMER_04 FEARB044L
CUSTOMER_05 FEARB055L
CUSTOMER_06 FEARB056L
CUSTOMER_07 FEARB057L
CUSTOMER_08 FEARB058L
CUSTOMER_09 FEARB609L
CUSTOMER_10 FEARB60AL
CUSTOMER_11 FEARB60BL
CUSTOMER_12 FEARB60CL
CUSTOMER_13 FEARB69DL
CUSTOMER_14 FEARB69EL
CUSTOMER_15 FEARB69FL
CUSTOMER_16 FEARB69GL
CUSTOMER_17 FEARB80HL
CUSTOMER_18 FEARB80IL

4.2 Run one of the BIP processes as mentioned below based on the Customer Database
to which the account belongs:
CUSTOMER_01 FEARB0411
CUSTOMER_02 FEARB0421
CUSTOMER_03 FEARB0431
CUSTOMER_04 FEARB0441
CUSTOMER_05 FEARB0551
CUSTOMER_06 FEARB0561
CUSTOMER_07 FEARB0571
CUSTOMER_08 FEARB0581
CUSTOMER_09 FEARB6091
CUSTOMER_10 FEARB60A1
CUSTOMER_11 FEARB60B1
CUSTOMER_12 FEARB60C1
CUSTOMER_13 FEARB69D1
CUSTOMER_14 FEARB69E1
CUSTOMER_15 FEARB69F1
 CUSTOMER_16 FEARB69G1
CUSTOMER_17 FEARB80H1
CUSTOMER_18 FEARB80I1
Repeat steps 4.1 and 4.2 repeatedly till the account’s billing cycle comes to the current cycle. Use
the following query to verify the same

select account_no, to_date, from_date, format_status, prep_date, bill_ref_no, prep_error_code,

process_num from BILL_INVOICE
where account_no= <Value retrieved from Step 1 in “Verify the Customer and the MSISDN exists in Arbor DB and
are valid“ section>
and prep_status = 1 and prep_error_code = NULL and process_num = '1'

Step 5: Prepare to run the sample billing for the account. Follow the following sub-steps for the
same:

5.1 Run the following query:

select * from CUSTOMER_ID_ACCT_MAP where account_no = <Value retrieved from Step 1

in “Verify the Customer and the MSISDN exists in Arbor DB and are valid“ section>

Take a note of external_id and external_id_type.

5.2 Run the following query to retrieve the value of account_category

select account_category from CMF where account_no = <Value retrieved from Step 1 in “Verify
the Customer and the MSISDN exists in Arbor DB and are valid“ section>

Take a note of the account_category.

5.3 Run the following query to get the to_date value for the account

select account_no, to_date, from_date, format_status, prep_date, bill_ref_no,

prep_error_code, process_num from BILL_INVOICE
where account_no= <Value retrieved from Step 1 in “Verify the Customer and the MSISDN exists in Arbor
DB and are valid“ section>
and prep_status = 1 and prep_error_code = NULL and process_num = '1'

Take a note of to_date.

5.4 Run the following set of queries to insert the value in the
FC_SAMPLE_LIST_MASTER table

Select * from FC_SAMPLE_LIST_MASTER where account_no = <Value retrieved from

Step 1 in “Verify the Customer and the MSISDN exists in Arbor DB and are valid“ section>

If the query returns values, run the following query to delete these values

delete from FC_SAMPLE_LIST_MASTER where account_no = <Value retrieved from

Step 1 in “Verify the Customer and the MSISDN exists in Arbor DB and are valid“ section>

Run the following query to insert value into the table

insert into FC_SAMPLE_LIST_MASTER values ('<Value of external_id retrieved from step

5.1>',<Value of external_id_type retrieved from step 5.1>,< Value retrieved from Step 1 in “Verify the
Customer and the MSISDN exists in Arbor DB and are valid“ section>,<Value of account_category
retrieved from step 5.2>,'<Value of to_date retrieved from step 5.3 + 1 month>',< Value of server_id
retrieved from Step 2 in “Verify the Customer and the MSISDN exists in Arbor DB and are valid“ section>,
-1,9,'Pruebas IBM India 6220',1)
Step 6: Run Sample billing for the account

6.1 Execute RSL job FEARB6001.

6.2 Run one of the Pre-BIP processes as mentioned below based on the Customer
Database to which the account belongs:
CUSTOMER_01 FEARB3610
CUSTOMER_02 FEARB3620
CUSTOMER_03 FEARB3630
CUSTOMER_04 FEARB3640
CUSTOMER_05 FEARB3750
CUSTOMER_06 FEARB3760
CUSTOMER_07 FEARB3770
CUSTOMER_08 FEARB3780
CUSTOMER_09 FEARBC190
CUSTOMER_10 FEARBC1A0
CUSTOMER_11 FEARBC1B0
CUSTOMER_12 FEARBC1C0
CUSTOMER_13 FEARBC2D0
CUSTOMER_14 FEARBC2E0
CUSTOMER_15 FEARBC2F0
CUSTOMER_16 FEARBC2G0
CUSTOMER_17 FEARB38H0
CUSTOMER_18 FEARB38I0
CUSTOMER_19 FEARB38J0
CUSTOMER_20 FEARB38K0

6.3 Run one of the BIP processes as mentioned below based on the Customer
Database to which the account belongs:
CUSTOMER_01 FEARB3615
CUSTOMER_02 FEARB3625
CUSTOMER_03 FEARB3635
CUSTOMER_04 FEARB3645
CUSTOMER_05 FEARB3755
CUSTOMER_06 FEARB3765
CUSTOMER_07 FEARB3775
CUSTOMER_08 FEARB3785
CUSTOMER_09 FEARBC195
CUSTOMER_10 FEARBC1A5
CUSTOMER_11 FEARBC1B5
CUSTOMER_12 FEARBC1C5
CUSTOMER_13 FEARBC2D5
CUSTOMER_14 FEARBC2E5
CUSTOMER_15 FEARBC2F5
CUSTOMER_16 FEARBC2G5
CUSTOMER_17 FEARB38H5
CUSTOMER_18 FEARB38I5
CUSTOMER_19 FEARB38J5
CUSTOMER_20 FEARB38K5
6.4 Run the following query to verify that the account has been billed or not

select account_no, to_date, from_date, format_status, prep_date, bill_ref_no,

prep_error_code, process_num from BILL_INVOICE
where account_no= <Value retrieved from Step 1 in “Verify the Customer and the MSISDN exists in Arbor
DB and are valid“ section>
and prep_status = 1 and prep_error_code = NULL and process_num = '9'

Verify that the to_date and from_date have been correctly updated and format_status
field has the value 0.

6.5 Execute one of the FED jobs as mentioned below based on the Customer Database
to which the account belongs:
CUSTOMER_01 FEARBED10
CUSTOMER_02 FEARBED20
CUSTOMER_03 FEARBED30
CUSTOMER_04 FEARBED40
CUSTOMER_05 FEARBED50
CUSTOMER_06 FEARBED60
CUSTOMER_07 FEARBED70
CUSTOMER_08 FEARBED80
CUSTOMER_09 FEARBED90
CUSTOMER_10 FEARBEDA0
CUSTOMER_11 FEARBEDB0
CUSTOMER_12 FEARBEDC0
CUSTOMER_13 FEARBEDD0
CUSTOMER_14 FEARBEDE0
CUSTOMER_15 FEARBEDF0
CUSTOMER_16 FEARBEDG0
CUSTOMER_17 FEARBEDH0
CUSTOMER_18 FEARBEDI0
CUSTOMER_19 FEARBEDJ0
CUSTOMER_20 FEARBEDK0

6.7 Execute one of the FNC jobs as mentioned below based on the Customer Database
to which the account belongs:
CUSTOMER_01 FEARB3616
CUSTOMER_02 FEARB3626
CUSTOMER_03 FEARB3636
CUSTOMER_04 FEARB3646
CUSTOMER_0A FEARB3756
CUSTOMER_06 FEARB3766
CUSTOMER_07 FEARB3776
CUSTOMER_08 FEARB3786
CUSTOMER_09 FEARBC196
CUSTOMER_10 FEARBC1A6
CUSTOMER_11 FEARBC1B6
CUSTOMER_12 FEARBC1C6
CUSTOMER_13 FEARBC2D6
CUSTOMER_14 FEARBC2E6
CUSTOMER_1A FEARBC2F6
CUSTOMER_16 FEARBC2G6
CUSTOMER_17 FEARB38H6
 CUSTOMER_18 FEARB38I6
CUSTOMER_19 FEARB38J6
CUSTOMER_20 FEARB38K6

6.6 Execute the following FNM jobs sequentially

FEARB3801
FEARB3802

6.7 Run the following query to verify that the processes have run fine

select account_no, to_date, from_date, format_status, prep_date, bill_ref_no,

prep_error_code, process_num from BILL_INVOICE
where account_no= <Value retrieved from Step 1 in “Verify the Customer and the MSISDN exists in Arbor
DB and are valid“ section>
and prep_status = 1 and prep_error_code = NULL and process_num = '9'

Verify that the format_status value has been updated to 2. Take a note of the

6.8 Run the following query to validate that the ext_bill_ref_no is updated.

select * from FC_BILL_INVOICE_SEQUENTIAL where bill_ref = <Value retrieved from

step 6.7>

Step 7: Run the following sub-steps to complete the extraction of bill to be sent to DOC1 for the
preparation of the pdf format Invoice.

7.1 Execute one of the FEC jobs as mentioned below based on the Customer Database
to which the account belongs:
CUSTOMER_01 FEARB3910
CUSTOMER_02 FEARB3920
CUSTOMER_03 FEARB3930
CUSTOMER_04 FEARB3940
CUSTOMER_05 FEARB4050
CUSTOMER_06 FEARB4060
CUSTOMER_07 FEARB4070
CUSTOMER_08 FEARB4080
CUSTOMER_09 FEARBC390
CUSTOMER_10 FEARBC3A0
CUSTOMER_11 FEARBC3B0
CUSTOMER_12 FEARBC3C0
CUSTOMER_13 FEARBC4D0
CUSTOMER_14 FEARBC4E0
CUSTOMER_15 FEARBC4F0
CUSTOMER_16 FEARBC4G0
CUSTOMER_17 FEARBC8H0
CUSTOMER_18 FEARBC8I0
CUSTOMER_19 FEARBC8J0
CUSTOMER_20 FEARBC8K0

7.2 Execute one of the CDOC jobs as mentioned below based on the Customer
Database to which the account belongs:
CUSTOMER_01 FEARB3052
CUSTOMER_02 FEARB3052
CUSTOMER_03 FEARB3052
CUSTOMER_04 FEARB3052
CUSTOMER_05 FEARB3053
CUSTOMER_06 FEARB3053
CUSTOMER_07 FEARB3053
CUSTOMER_08 FEARB3053
CUSTOMER_09 FEARB3054
CUSTOMER_10 FEARB3054
CUSTOMER_11 FEARB3054
CUSTOMER_12 FEARB3054
CUSTOMER_13 FEARB3055
CUSTOMER_14 FEARB3055
CUSTOMER_15 FEARB3055
CUSTOMER_16 FEARB3055
CUSTOMER_17 FEARB3055
CUSTOMER_18 FEARB3055
CUSTOMER_19 FEARB3055
CUSTOMER_20 FEARB3055

7.3 Execute job FEARB3051

7.4 Execute job FEARB4111

7.5 Execute job FEARB4112

7.6 Go to the /$home/data/doc1/facturacion/ready directory and verify that the file

SAM2_YYYYMMDD_DEF_01.dat is generated where the value of YYYYMMDD is
the to_date used in insert query in Step 5.4. For example to_date was selected as
1st Nov 2008, then the file generated will be SAM2_20081101_DEF_01.dat.
Rating in Arbor
Rating process in Arbor receive usage records from a network mediation layer, associate them
with accounts calculate usage charges and commit the results to the database.

The Rating process is divided into following modules:-

• The Communications (COM) process retrieves files of usage records from a network mediation
layer.
• The Usage Router (MCAP) process routes usage records to the proper Customer server.
• The Usage Guider/Rater (CAP) process rates usage records.
• The Long Term Persistence (LTP) module commits rated usage data to the Arbor database.

Steps for Execution:

1. Login to Arbor Unix Box.

2. The CDR received from Mediation or prepared manually is put into
/opt/kenan/data/kenanFX/data/cdr_input/gsm/ready3 directory in Arbor Unix Box.
3. Run COM process by launching FEARB2605 process from anywhere inside Arbor Unix
Box.
4. Run MCAP process by launching FEARB2611 process.
5. Run CAP process. Launch the following process depending on the Customer Server to
which the MSISDN belongs:
CUSTOMER_01 FEARB2711
CUSTOMER_02 FEARB2721
CUSTOMER_03 FEARB2731
CUSTOMER_04 FEARB2741
CUSTOMER_05 FEARB2851
CUSTOMER_06 FEARB2861
CUSTOMER_07 FEARB2871
CUSTOMER_08 FEARB2881
CUSTOMER_09 FEARB5091
CUSTOMER_10 FEARB50A1
CUSTOMER_11 FEARB50B1
CUSTOMER_12 FEARB50C1
CUSTOMER_13 FEARB57D1
CUSTOMER_14 FEARB57E1
CUSTOMER_15 FEARB57F1
CUSTOMER_16 FEARB57G1
CUSTOMER_17 FEARB17Q1
CUSTOMER_18 FEARB17R1
CUSTOMER_19 FEARB17S1
CUSTOMER_20 FEARB17T1

The logs for each process can be seen at $HOME/logs directory.

The CAP process internally call LTP process and it is not required to launch the same
separately. Once the CAP has processed our CDR file it puts the file in
/opt/kenan/data/kenanFX/data/usage/ltp/ready directory with the naming convention as
OriginalFileName.file_id.
We look out for ltp logs in $HOME/logs directory to verify that the ltp process is
completed or not. Generation of ltp logs implies that the ltp process has completed
 processing. Once the ltp process completes, our CDR file moves from
/opt/kenan/data/kenanFX/data/usage/ltp/ready to
/opt/kenan/data/kenanFX/data/usage/ltp/done directory

Once the ltp process finishes, go to CDR_DATA table in FACTT0x_MS and verify that
the CDR records have been committed to database or not. Here x is either 0 or 3
depending upon the Customer Server. Use the following query for the same

Select * from CDR_DATA where file_id = <file id no. retrieved from

/opt/kenan/data/kenanFX/data/usage/ltp/ready directory>

Additional cases
Free Calls:
In cases of calls defined as “to be rated “ but “not to be billing“, one entry is generated in
CDR_FREE table in FACTT0x_MS. These calls will not follow with billing process.
Use the following query:

Select * from CDR_FREE where file_id = <file id no. retrieved from

/opt/kenan/data/kenanFX/data/usage/ltp/ready directory>

Invalid calls
In case of invalid calls, that it is not possible to be rated, one entry is generated in
CDR_DATA_WORK table in FACTT_MS in Admin Database.

Select * from CDR_DATA_WORK where file_id = <file id no. retrieved from

/opt/kenan/data/kenanFX/data/usage/ltp/ready directory>

In case of invalid calls, get the value of miu_error_code from CDR_DATA_WORK

table using the following query

Select miu_error_code from CDR_DATA_WORK where file_id = <file id no. retrieved from
/opt/kenan/data/kenanFX/data/usage/ltp/ready directory>

Then query in table SYSTEM_MESSAGES to see error message. Use the following
query:

Select * from SYSTEM_MESSAGES where message_number = <Value of miu_error_code

retrieved from previous query>
CDR Creation

The Rating process in Arbor begins when a text file containing call records arrives to ARBOR.
These files are commonly called CDRs (Call Data Records). Each line in the file is associated
with one call, one SMS, one download etc. These files come to ARBOR from different systems
depending on the consumption type

APACHE/MASSAI  GSM, GPRS

INFRANET  SVA, SMS
SIGRA  Roaming

But usually in our testing scenario, we manually create CDRs to replicate usage scenarios. The
document explains how a CDR is manually created.

Each CDR has a particular format based on usage type. These CDR formats information is
available in Arbor table RAW_USAGE_FIELD_MAPPING. CDR format is based on type of a
usage for which we need to perform testing. For example the snapshot below shows the CDR
format for GPRS.

Each CDR starts with a header line. It is then followed by one or more lines of details of usage.
Finally a CDR file ends with a trailer. Attached is a sample CDR file for GPRS

C:\Documents and
Settings\Administrator\Desktop\March Release\Execution\6363\ES6363\Arbor-Doc1\SC_01\CDR_63630102_New.txt

For our testing purpose we usually manipulate some of the fields from the sample CDR to
prepare test data.

Important Fields which are usually modified:

1.) type_id_usg- It is basically a numeric value which specify the usage type for a particular
consumption. It is dependent on the Price Plan, usage type, products, services etc for
which the usage is being generated.
2.) trans_dt: The date in which the usage occurs. It is YYYYMMDDHHMMSS format.
3.) external_id: It specifies the MSISDN or IMSI number from which the usage is made.
4.) external_id_type: Depending on the value of external_id, this value is set. For example
for GPRS, we need to specify IMSI number. The external_id_type here will be 8. We can
refer to EXTERNAL_ID_TYPES_VALUES tables to see different external_id_types
The values to be entered into the CDR for the external_id can be retrieved from
EXTERNAL_ID_EQUIP_MAP table. For example to get the value for an IMSI no. we need to run
the following query:

select * from EXTERNAL_ID_EQUIP_MAP where external_id = ‘Clarify MSISDN no’ and

external_id_type = 8

5.) comp_status: - It specifies the status of the usage.

Referring to above table we can give comp_status depending on comp_status_value mentioned
above.

For details please refer following tables.

CDR_COMP_STATUS_VALUES – First Output

CDR_COMP_STATUS_REF – Second output.

Examples of the field explained above:-

24614 - Type_id_usage
20080817001134 - Trans_dt
8 - External_id(5 Char including Spaces)
214016500288224 - External_id_type(IMSI in this case)
003 - Comp_status.
DOC1
Step 1: Deleted all the documents from directory “E:\arbor\in\ciclo”.

Step 2: Extracted the invoice (“SAM2_20081026_DEF_01.DAT”) in E:\arbor\in\ciclo.

Step 3: Executed "FENIX_F.bat" script

Step 4: Checked invoice generated in E:\arbor\out\fijapdf0.

Step 5: Verify that the invoice generated reflects the changes in Price Plan and Discounts
correctly.

TO generate XML for BRM:-

1) Once you have created the invoice (pdf file), then create the xml file. Also clear
everything from path "E:/factxml/out_ciclo_01/fxml0"

2) Execute “aDOC1-XML.cmd” script which is in “F:/doc1/factxml/scripts”, but you

must do it in the following way.

3) You must open a DOS console and go to “F:/doc1/factxml/scripts” folder.

4) Two parameters must be passed to the script, the parttition and the cycle, in our case
the parttition is “0” and the cycle will be “01”. The script must be executed as “aDOC1-
XML.cmd 0 01”

5) The XML files will be at “E:/factxml/out_ciclo_01/fxml0” there will be one XML file
for each invoice.

BRM:- The application is used for Recalculation of Invoices.

Loading & Viewing the Invoice

1) Generate the XML file.

2) Connect to “62.87.0.54” machine with “wladmin2” as username and password as
“******”.
3) Go to “/opt/weblogic/share/brm-vod/facturas” folder and put the XML file of the
invoices that must be recalculated in BRM.
4) Open the URL, http://62.87.0.54:5001/brm-vod.
5) Go to option menu “Iniciar proceso de recalculo”.
6) A new screen will open, enter the invoice no. in field Factura No. and click on
Buscar.
7) Select your invoice. Till here the loading of the invoice is done.
8) A new screen will open having your details of invoice. Till here the viewing of the
invoice is done.

Recalculation

1) Go to Servicios tab and check MSISDN in the column “Servicios” that is in left of
window in tab “Servicios”.
2) If you are applying the PricePlan click on Cambiar Plan de Precios.
3) Else if you are applying the Supplementary Serivce click on Service
Supplemento.
4) Else if you are applying the Bonus click on Applicadas Bonos.
5) Else click on Descuntos if you are applying the discount.
6) A new corresponding (either to PP, SS, Bonus, Discount) screen will open and
select the corresponding (either PP, SS, Bonus, Discount) from the drop down
menu.
7) Click on Anadir.
8) Click on Recalcular.
9) A new small screen will open.
10) Click on ver field against your factura number.
11) Another new screen will open “Resumen del Proceso de Recalculo”, which shows
the calculation being done after the PP or SS or Bonus or Discount is applied.
12) Click on volver button.
13) In Datos Administrativos screen, click on 7 tabs that are at the end of the page, to
see the changes.

MEDIATION:-
Apache

1) Connect to “Apache” preproduction Machine

(esxha122.es.sedc.internal.vodafone.com ).
2) Move to /home/users/E2E/test/scripts/input directory. This directory will contain
the input files that are to be processed.
3) The input file name format should be as follow :
- GRPS: chsLog.[0-9]{4}
- MMS:
i. MM4: udr-MMR-YYYYMMDDHHMM
ii. MSCL: MSCL_xxx_YYYYMMDDHHMM_[0-9]{3}
iii. MMSC Nokia:
BF_preprost_YYYYMMDDHHMMSS_MMSCxx_[0-9]{4].DAT
(x=nodo)
iv. GPRS MMS: FYYYYMMDDHHMM
- CHAT : Em_billing_yyyymmdd_HHMM_[0-9]{10}.log
- PUSH TO TALK: pttudr01_YYYYMMDD_HHMMSS_[0-9]{3}
- WLAN: YYYYMMDD.act.x (x=nodo)
- MENSAWEB: WEBMMS_HDDMMYYYYHHMMSS
- DMR: drm_YYYYMMDDHHMM.txt
- Liberty: liberty_YYYYMMDDHHMM.txt
- STARENT : ggsn[0-9]{3}-gss*

Rename input file as the following format SOURCE.SOURCEFILE where SOURCE is

the name of the network node and SOURCEFILE is the name of the file collected from
the network node.

4) Copy the input file in the corresponding directory depending on the type of usage
to be tested
/CHAT
/DRM
/GPRS
/LIBERTY
/MMS
/PushToTalk
/STARENT

5) Process the input file. Go to /home/users/E2E/test/scripts

6) Execute start.sh
7) Select the corresponding value depending on the flow to be tested
1 – chat
2 – drm
3 – gprs
4 – liberty
5 – mms
 6 – pushtotalk
7 – starent

8) Execute status.sh to check the process status.

9) Check Output files. Go to /home/users/E2E/test/scripts/output/
10) Recover output files from the different folders where the process has generated
output files. In the output files filter the calls to recover we are interested in.

Navajo

1) Connect to “Navajo” preproduction Machine

(esxha126.es.sedc.internal.vodafone.com).
2) Move to /home/users/E2E/test/scripts/input directory. This directory will contain
the input files that are to be processed.
3) The input file name format should be as follow :
ERICSSON:
- MSC: Mxxx([0-9]{4})
- MSS: Cxxx([0-9]{4}), (where “xxx” identifies the node)
TAP3
- MACH.CDxxxxxyyyyy[0-9]{5}, where xxxxx: Origin Operator / yyyyy:
Target Operator ("ESPVV") in case virtual operator)
LES
- LES_YYYYMMDDHHMMSS
- GFLOC[0-9]{4}_YYYYMMDDHHMMSS
UM
- b[0-9]{1}.[0-9]{12}
IVPN
- IVPNxx-([0-9]{6})-YYYYMMDDHHMMSS, Where xx identifies the
node.
TMAP
- TMAP_([0-9]{6})_YYYYMMDDHHMMSS
CORPA
- FP_YYYYMMDDHHMMSS
GAIAS
- TexInfo-([0-9]{6})-YYYYMMDDHHMMSS.dat
MENSAWEB
- WEB_HYYYYMMDDHHMMSS
SCP
- SCP: Sxxx([0-9]{4})
- TSP: Sxxx.([0-9]{14}).([0-9]{4})
GDF
- GFSMSxxxx_YYYYMMDDHHMMSS
CCN
- CCNxxx-([0-9]{4}), where xxx identifies the node.
CCP
 - CCNxxx-([0-9]{4}), where xxx identifies the node
EFAX
- Tele2.eFax.YYYYMMDDHHMMSS

Rename input file as the following format SOURCE.SOURCEFILE where SOURCE is

the name of the network node and SOURCEFILE is the name as the file collected from
the network node.

4) Copy the input file in the corresponding directory depending on the type of usage
to be tested
/CCN
/CCP
/CORPA
/EFAX
/ER
/ER4
/GAIAS
/GDF
/IVPN
/LES
/MWEB
/NRTROUT
/SCP
/TAP3
/TMAP
/UM

5) Process the file, Go to /home/users/E2E/test/scripts

6) Execute start.sh
7) Select the corresponding value depending on the flow to be tested
1 – ccn
2 – ccp
3 – corpa
4 – efax
5 – ericsson
6 – gaias
7 – gdf
8 – ivpn
9 – les
 10 – mensaweb
11 – nrtrout
12 – scp
13 - tap3
14 – tmap
15 – um

8) Execute status.sh to check the process check status

9) Check Output files. Go to /home/users/E2E/test/scripts/output/
10) Recover output files from the different folders where the process has generated
output files. In the output files filter the calls to recover we are interested in.

Itanium

1) Connect to preproduction Machine (esxha126.es.sedc.internal.vodafone.com).

2) Put the input files in the path /var/opt/SIUt/E2E/test/scripts/input/ER4
3) Go to the path /home/users/E2E/test/scripts
4) Execute start.sh and select option Ericssion.
5) Move the output files generated from
/var/opt/SIUt/iumwork/ready/r3/input/medievo/mpdis01/ directory in Navajo-
Itanium (62.87.4.208) to /var/opt/SIUt/iumwork/ready/r3/input/medievo/mpdis01
directory in Navajo-PA-RISC (62.87.4.144).
6) Move the output files generated from
/var/opt/SIUt/iumwork/ready/r3/input/elmer/sai01/ directory in Navajo-Itanium
(62.87.4.208) to /var/opt/SIUt/iumwork/ready/r3/input/elmer/sai01 directory in
Navajo-PA-RISC (62.87.4.144)
7) Execute start.sh in Navajo-PA-RISC (62.87.4.144)
8) The output files for ARBOR are generated in Navajo-PA-RISC (62.87.4.144) as
usual.
9) This will generate the file for ARBOR, Fraude, Dbcall.
OPTIMAL PRICING

Optimal Pricing is a tool, principal target of which is to rate all clients call events following several
configurations. The tool is basically used to suggest an optimal price plan to the Vodafone client
whenever he requests for the same. When a Vodafone Customer enquires with a CSR about the
Optimal Price Plans available, the CSR simulates the Price Plan and then suggest the list of Price
Plans which are more Optimal (If any) than the existing Price Plan the Customer has. By
simulation we mean that for the same CDRs, the simulated rating is done with different price
plans and then Optimal Price Plan is suggested to the Customer. The application is also used by
Marketing Executives to identify the Optimal Plans available for a group of users. All the existing
Price Plans are configured in this tool and new Price Plans are added whenever a request comes
for the same. This tool shows to the users their saving with the different configured prices plans
and other interested information.
1. OPTIMAL PRICING OPERATIONS
One of the major component of Optimal Pricing is the Rater. OPR’s major functionality is to
calculate the call events price with the diferent Vodafone price plans.

1.1 Input/Output for Optimal Pricing Rater

The image below shows the Optimal Pricing Rater (OPR) and the inputs/outputs of this tool.

OPR receives 2 types of Input files :-

 Configuration Files : These are several xml files which have all information on Vodafone
price plans, tariffs, profits, products.

 Client Call Event Files : These are the call event files which the OPR receives from the
Arbor (PostPaid) and PUC (PrePaid) systems. For each billing cycle all the call events
are sent by Arbor and PUC to the OPR. The OPR uses these files to carry out its
operations. The Arbor Postpayment files will be with the naming convention
“FAC_{cycle’s date YYYYMMDD}_OP.dat” while the PUC file have the naming convention
“PUC_{cycle’s date YYYYMMDD}_OP.dat”.

Attached are the two sample Arbor and PUC files.

FAC_20100801_OP. PUC_20080901.dat
dat

The Rater loads all information from configuration files in the RAM memory to use it during the
rater process. OPR then calculate the call events price with the diferents Vodafone price plans
with the help of the input files from Arbor and PUC. The OPR generate several files with the
results of the price plan simulations. Following is the list of output generated :

 TarificadosDetalle: It shows the price plans simulation information for each Vodafone
client. This information will be loaded in the data bases’s table
OP_RC_RESULTADOS_PS.
 DetalleUsosPPOriginal: It shows simulated information in differents levels which are
defined in the table OP_CA_DETALLE_USOS. This information will be loaded in the
table: OP_OR_DETALLE_USOS.
  MejoresB: It shows the information of calls and sms to the best B numbers for each
client. This information will be loaded in the table: OP_OR_USOS_MEJORES_B.
 UsoProductosContratados: It shows clients products information. This information will
be loaded in the table: OP_OR_USO_PRODUCTOS_CTR.
 Promociones: It shows promotions information. This information will be loaded in the
table: : OP_OR_PROMOCIONADOS.
 Data: It shows data price plans simulations, this information will be loaded in the table:
OP_RC_DATA.

1.2 Operations to be performed through Back End

The Optimal Pricing application has two subproducts, namely Optimal Pricing Particular (OPP)
and Optimal Pricing Enterprise (OPE). In each one of the sub products the following
functionalities will be defined:

1. Start the Retarificador (rebilling calculator).

2. Initiate the load of data.
3. Monitor the processes.
Each one of these processes is a shell script that conducts the relevant operations for the correct
functioning of the application.

1.2.1 Optimal Pricing Particular

This part of the Optimal Pricing makes a reference to all the operations to be performed on the
individuals. There are 2 directories which will be navigated during the entire backend processes
that need to be executed.

 /
opt/weblogic/wlprep1/PREPRO/applications/VodafoneApps/OptimalPricing_R3/OP_
Retarificador is the app directory and will have all the scripts that need to be executed.
 /opt/weblogic/share/OptimalPricing_R3/OP_Retarificador will have the input files and
the log files generated.

Launch Pricing Process

This process is responsible for rebilling the input files received from Arbor and PUC. For this
process it required to put the input file in the
/opt/weblogic/share/OptimalPricing_R3/OP_Retarificador/input/current directory. If the
directory has more than 1 file then the file which has the oldest date will be processed first. Once
this initial set up is done, the script launch_rater.sh is executed from
/opt/weblogic/wlprep1/PREPRO/applications/VodafoneApps/OptimalPricing_R3/OP_Retarif
icador.

Once the script is launched the input file passes from the
/opt/weblogic/share/OptimalPricing_R3/OP_Retarificador/input/current to the directory
/opt/weblogic/share/OptimalPricing_R3/OP_Retarificador/input/current/in_process. This
indicates that the file is getting processed. The files resulting from rebilling will be saved in the
same directory.
When the script completes “0” will be printed on the console if everything has gone well and a
"1" is printed in case of some problem.

If the process completes correctly the input file will move from the directory
/opt/weblogic/share/OptimalPricing_R3/OP_Retarificador/input/current/in_process to
the directory /opt/weblogic/share/OptimalPricing_R3/OP_Retarificador/input/current/old
and will be compressed to occupy the smaller possible space in File System. The resulting
files will be stored in the
/opt/weblogic/share/OptimalPricing_R3/OP_Retarificador/output/current folder of the
work directory.

If the process fails, it would be necessary to review the logs to try to detect the error and to be
able to relaunch the process.

Load Data in Database

This process loads files generated by the rebilling process explained in previous section into
the Database.
In order to initiate this process it is necessary that in the
/opt/weblogic/share/OptimalPricing_R3/OP_Retarificador/output/current directory there
is a folder with the name of a file which will contain the files generated by the rebilling process.
For example, if the file processed by the rebilling process was FAC_20080921.dat, then all the
files processed by rebilling process should be stored in the path
/opt/weblogic/share/OptimalPricing_R3/OP_Retarificador/output/current/FAC_20080921.
If there are several folders, the process will pick up the one that has the oldest date.

Once we validate all the files are in place we will execute the E_launch_load.sh shell script.

Once the shell script start processing the files will be moved to the directory
/weblogic/share/OptimalPricing_R3/OP_Retarificador/output/current/in_process and the
script will begin to load file by file in the data base. Each loaded file will be moved to the
directory path
/weblogic/share/OptimalPricing_R3/OP_Retarificador/output/old/nombre_fichero folder
and will be compressed to occupy the smaller possible space in the data base.

When the script completes “0” will be printed on the console if everything has gone well and a
"1" is printed in case of some problem.

When the files finish loading themselves, a process in parallel is launched (Clarify Process)
that updates the fields of tables. When the process completes successfully the data entered
into the Database can be viewed from the Web Application. If this process has not completed,
there is a possibility that the Web Application will not work properly.

If the process fails, it would be necessary to review logs to try to detect the error and to be
able to relaunch the retarificador.
Monitoring Process

In order to monitor the processes we need to verify the logs generated by these processes. There
are 3 types of logs are generated:

 Log of scripts: It shows the information about the state of all the process being
launched. We can navigate to these logs to verify whether the process has completed
successfully or have errored out. The file can be viewed at the following path in the
Unix box
/opt/weblogic/share/OptimalPricing_R3/OP_Retarificador/log/script_OPR.log.
 Log of the tarificador: The tarificador generates log indicating the number of clients
that will be rebilled.
/opt/weblogic/share/OptimalPricing_R3/OP_Retarificador/log/OPR.log is the path
where these logs can be found.
 Log of loaders: These files show how the load has gone in the data base for each
file resulting from the rebilling. They are generated in Work directory in the
/opt/weblogic/share/OptimalPricing_R3/OP_Retarificador/log/loader/nombre_fic
hero_arbor route and they can be of three types, according the load that has finished
(log, bad, dis).

1.2.2 Optimal Pricing Enterprise

This part of the Optimal Pricing makes a reference to all the operations to be performed on the
companies. There are 2 directories which will be navigated during the entire backend processes
that need to be executed.

 /
opt/weblogic/wlprep1/PREPRO/applications/VodafoneApps/OptimalPricing_R2/OP_
Retarificador is the app directory and will have all the scripts that need to be executed.
 /opt/weblogic/share/OptimalPricing_R2/OP_Retarificador will have the input files and
the log files generated.

Launch Pricing Process

This process is responsible for rebilling the input files received from Arbor and PUC. For this
process it required to put the input file in the
/opt/weblogic/share/OptimalPricing_R2/OP_Retarificador/input/current directory. If the
directory has more than 1 file then the file which has the oldest date will be processed first. Once
this initial set up is done, the script launch_rater.sh is executed from
/opt/weblogic/wlprep1/PREPRO/applications/VodafoneApps/OptimalPricing_R2/OP_Retarif
icador.

Once the script is launched the input file passes from the
/opt/weblogic/share/OptimalPricing_R2/OP_Retarificador/input/current to the directory
/opt/weblogic/share/OptimalPricing_R2/OP_Retarificador/input/current/in_process. This
indicates that the file is getting processed. The files resulting from rebilling will be saved in the
same directory.

When the script completes “0” will be printed on the console if everything has gone well and a
"1" is printed in case of some problem.
If the process completes correctly the input file will move from the directory
/opt/weblogic/share/OptimalPricing_R2/OP_Retarificador/input/current/in_process to
the directory /opt/weblogic/share/OptimalPricing_R2/OP_Retarificador/input/current/old
and will be compressed to occupy the smaller possible space in File System. The resulting
files will be stored in the
/opt/weblogic/share/OptimalPricing_R2/OP_Retarificador/output/current folder of the
work directory.

If the process fails, it would be necessary to review the logs to try to detect the error and to be
able to relaunch the process.

Load Data in Database

This process loads files generated by the rebilling process explained in previous section into
the Database.
In order to initiate this process it is necessary that in the
/opt/weblogic/share/OptimalPricing_R2/OP_Retarificador/output/current directory there
is a folder with the name of a file which will contain the files generated by the rebilling process.
For example, if the file processed by the rebilling process was FAC_20080921.dat, then all the
files processed by rebilling process should be stored in the path
/opt/weblogic/share/OptimalPricing_R2/OP_Retarificador/output/current/FAC_20080921.
If there are several folders, the process will pick up the one that has the oldest date.

Once we validate all the files are in place we will execute the E_launch_load.sh shell script.

Once the shell script start processing the files will be moved to the directory
/weblogic/share/OptimalPricing_R2/OP_Retarificador/output/current/in_process and the
script will begin to load file by file in the data base. Each loaded file will be moved to the
directory path
/weblogic/share/OptimalPricing_R2/OP_Retarificador/output/old/nombre_fichero folder
and will be compressed to occupy the smaller possible space in the data base.

When the script completes “0” will be printed on the console if everything has gone well and a
"1" is printed in case of some problem.

When the files finish loading themselves, a process in parallel is launched (Clarify Process)
that updates the fields of tables. When the process completes successfully the data entered
into the Database can be viewed from the Web Application. If this process has not completed,
there is a possibility that the Web Application will not work properly.

If the process fails, it would be necessary to review logs to try to detect the error and to be
able to relaunch the retarificador.

Monitoring Process

In order to monitor the processes we need to verify the logs generated by these processes. There
are 3 types of logs are generated:

 Log of scripts: It shows the information about the state of all the process being
 launched. We can navigate to these logs to verify whether the process has completed
successfully or have errored out. The file can be viewed at the following path in the
Unix box
/opt/weblogic/share/OptimalPricing_R3/OP_Retarificador/log/script_OPR.log.
 Log of the tarificador: The tarificador generates log indicating the number of clients
that will be rebilled.
/opt/weblogic/share/OptimalPricing_R3/OP_Retarificador/log/OPR.log is the path
where these logs can be found.
Log of loaders: These files show how the load has gone in the data base for each file resulting
from the rebilling. They are generated in Work directory in the
/opt/weblogic/share/OptimalPricing_R3/OP_Retarificador/log/loader/nombre_fichero_arbor
route and they can be of three types, according the load that has finished (log, bad, dis).

1.3 Application Modules

The Optimal Pricing Application has two modules. Ne module is for Individuals and the other one
is for the Enterprise. For both the modules there are 3 different types of profile of the users.
These are RAC, Marketin and Advanced Marketing.

1.3.1 Optimal Pricing Particular

As the name suggest this Module of the Optimal Pricing is used for Individuals. The application is
basically used to simulate the price plans for the individuals so that an Optimal Price plan can be
suggested to the Customer.

The three different users, i.e. RAC, Marketing and Marketing Advance login to the application
using the following URL: http://62.87.1.82:8801/op-vod_R3.

On successful login, the first page for all the three users is different.

The figure below shows the first page for a Advance Marketing profile on successful login.
The Advance Marketing profile can carry out following operations using the Advance Options
given in the figure above:

• To configure Parameters: It allows the user to access to the screen in which he can
manage the Default values and can form groups of plans of prices.
 To initiate Online Optimal Pricing: Clicking this Tab the user will be able to initiate
process online.
 To initiate Optimal Pricing batch: Clicking on this option, the user will be able to
initiate a batch process.
 To consult Advance of Optimal Processes: In this tab the user can view all the
Batch processes initiated by the user. These process can be in In-Process or
Finalized state.
 To consult the conducted Processes Batch: This tab is used to search and
summarize all the batch processes which have been finalized.

For the profile Marketing, the following first page appears on the successful login:
The Marketing profile can carry out following tasks with the Advanced Menu Options:
 To initiate Optimal Pricing: On clicking this option, the user will be able to
initiate a batch process.
 Advance consult of Processes of Optimal: In this tab the user can view all the
Batch processes initiated by the user. These process can be in In-Process or
Finalized state.
 To consult the conducted Processes Batch: This tab is used to search and
summarize all the batch processes which have been finalized.

And for the profile, RAC the following page appears:

The user pertaining to roll RAC does not have menu options since all the phases carried out by
RAC are unique and are made available automatically.

Important Note: - Once you login to Optimal Pricing Application using any of these profiles, the
following screen appears:
In this case in the URL, please remove all the contents after the word Portal (As shown in the
figure above) and press Enter key.

To Log Out from the Application, Click on the Exit Button and the window gets closed.

Advanced Menu Tasks

This section describes all the Advanced Menu options and the tasks that can be carried out from
the same.
Configure Parameters
This Menu is only available for Advanced Marketing Profile. The following tasks can be carried
out from this Menu:
 From this Tab the user can define the default Groups which will be visible for that Profile
in Start Optimal Pricing Online menu. This can be achieved by selecting a value from the
drop down as shown in figure below:

 The user can also define the % value of the Threshold. It means when the Price Plans
are simulated, all the price plans which are more than x% cheaper than the given price
plan will be recommended as Optimal Price Plans in the Optimal Pricing Online. In the
figure below, 4% is selected as the threshold value. So when price plan simulation is
done, then all the Price plans which are more than 4% cheap will be recommended.
 The user can create a new group and add price plans to it using Neuvo Group button as
shown in the figure below:
  User can give permissions to a particular profile for accessing a particular Price Plan
group by use of checkbox shown in the figure below. Once a Profile has the permission to
a particular Price Plan, that profile then can simulate a Price Plan against that Price Plan
group. This will be explained later when Optimal PricePlan Online is explained.

 User can also delete a particular Price Plan group by clicking on the Bucket shaped
figure under the Borrar column as shown in the figure above.
 User can also modify a Particular Price Plan group by clicking on the Pen icon figure
under Modificar column. The user can add a particular Price Plan or delete a particular
Price Plan from a Price plan Group as a part of Modification process. The figure below
shows the Grid that appears once we click the Pen icon. The New Price Plan can be
added to the Price Plan Group by selecting a Plan from the list and clicking on the button
highlighted in the figure. A Price Plan can be deleted by clicking on the Bucket Icon.

Start Optimal Pricing Online

This menu is used to simulate the Price Plans for one Individual and suggest an Optimal Price
Plan and also to recommend an Optimal Product. The User can find out an Optimal Price Plan
and a recommended product for a Customer by providing
 MSISDN number.
 The Price Plan group against which the simulation will be made
 The other values of filters (If required).

The fields are shown in the figure below:

Once the values are entered, the User can initiate the simulation process by clicking the Start
Process button as shown in the figure below:

Once the process of simulation completes the result is displayed as shown in the figure below. It
diplays the Actual Plan the Customer has, the recommended Price Plans according to the group
selected, Graphical representation of the Recommendations and the Recommended and Non-
Recommended products. The important thing to note is that simulation is done against only
those Price Plans which belong to the Price Plan Group selected.
Explanation of the resulting fields after Simulation Process Completes:

 Original Plan:
The portion of the window selected in the figure above specifies the Actual plan and Product that
the Customer presently has. Each column in this portion is explained below:
 Plan: It is the plan which the Customer has. In case of Prepaid Customer it is the actual
plan and in case of Postpaid it is the plan for which the last invoice was generated for the
Customer.
 Contracted products: List of products contracted by the client.
 Consumption: Total consumption in a particular billing cycle of the client in Euros.
 Commercializable: If the contracted plan is marketable or not.
 Detailed Call: It has a magnifying Glass Icon. Once we click this Icon we get a new
window which will have details of all the calls that were made by the Customer in the last
Billing Cycle. The window will have, for each call information like type of call, Total No. of
Calls made and the Duration for the calls in MM:SS format.

 Optimal Plans Recommendations :

This portion of the page shows all the Price Plans under the Price Plan group which was selected
for Simulation process. Rating simulations is done for these Price Plans and on the basis of
simulation, % saving in comparison for original plan is calculated for each Price Plan. On the
basis of these % savings the price plans are either recommended or not recommended. This
section of the page is highlighted in the figure below:
The different fields and their relevance is explained below:

 Plan: Each Price Plan present in the Price Plan Group for which the simulation was
carried out.
 %Saving: The percentage of saving that would be obtained with respect to the Original
Price Plan held by the client. A negative saving vaue means that the original price plan is
more optimal than the Price plan for which simulation was performed.
 Recommendation (YES/NO): On the basis of the savings calculated, recommendation
are made whether a Price Plan is Optimal or not. In section 6.1.1.1.1 (Page 21) we
discussed about the Threshold value. So if we have set a value of Threshold as 4%, then
all those Price Plans which have more than 4% of Saving will be recommended as
Optimal Price Plans for the
 Detail of Calls: It gives the detail of the calls and the % saving which can be achieved
with different Price Plans. When we click the Binoculare Image following window opens:

As can be seen, the Window gives information about the type of calls, total no. of calls
made, total duration of calls for each type and simulated savings which can be achieved
if the Price Plan is selected with the recommendation in the bracket.
 Detail of Consumptions: This column shows the detailed comparison of the
consumption between Original Price Plan and the one which is simulated. Once we click
the binocular Icon, the following window opens:
 As can be seen in the figure the Window gives in detail, different periods within a Billing
Cycle, Actual Consumption with the Original Price Plan, Consumption that will happen
with the simulated Price Plan, percentage savings and recommendations in the bracket.

Please note that only 3 simulated plans will be displayed in order of decreasing % saving. To see
next 3 plan, please click on the “3 Siquintes” link. Do go back to 3 previous plans, “3 Anteriors”
link needs to be clicked.

 Graphical Comparison
The Optimal Pricing online also presents a graphical representation of the comparison of actual
plan with the three better Price Plans present in the group.
The actual plan will always be in dark gray color, whereas the rest of colors go in accordance with
the following criteria:
 Red: Optimal plan.
 Purple: Secondly better Plan.
 Green: Third better Plan.
Below is the figure with the Graphical Portion marked:

Note: - In case of not having three recommendable plans, the graph will only show those
price plans that there are available.

 Recommendation of Products
The figure above shows the Product Recommendation section of the window marked. This
section has the following sub-sections:
§ Contracted products: The products that customer already holds with him.
§ NonRecommendable products: The products that the Customer does not have and are
also not recommended to the Customer.
§ Recommendable products: The products that the Customer does not have contracted
and that are recommended to the Customer as it would result in more saving for him.

There is an icon to the right side of the Recommended Products. Once we click on this icon, a
new window opens which will provide more detail on why this product is recommended. It will
have information like Product Identifier, B Number (if applicable) to which if the call is made using
this product will lead to more savings and % savings using this product.

Optimal Pricing Batch

This Advanced Menu of the application is used to initiate a batch process for simulating Price
plans for more than 1 service at a time. The figure below shows the window for Optimal Pricing
Batch
There are two forms to initiate a process batch:

1) To initiate a process batch through a file batch:

We can directly upload the file to initiate the batch process. The file has to be in the format given
below:

Campaign: test loads

Description: test loads
Group of Plan of Prices: Postpaid - Particular
Product list: A2; QTAL; NUMEROSHABITUALES; NUE GOES CUENTAFAMILIAR;

667485232
(...)

 Campaign: Name of the process we need to initiate

 Description: Description of the campaign
 Group of Plan of Prices: Group of plans against which the simulation needs to be done.
  Product list: Product identifiers separated by semi colon. It can be empty also.
 List of Services: Services, one by line, on which one has to do the simulations.
It is important to consider that the maximum number of services that can be included in a file is
15,000

We then upload this file by browsing this file using “Find” button and then loading the file using
“Load File” Button. Then click “Initiate Process” to initiate Batch process.

2) Initiate Process by Manually putting data:

To initiate a process manually we use the following section of the window as shown in the figure
above. Firstly, we give enter the name of the campaign and its Description. We then select the
Price Plan group against which simulation needs to be done. Then products required for the
simulations can be added by using icon. This can also be left blank. Then click Add/Modify.
The following section appears as shown in the figure below on clicking Add/Modify
Services can be added either by entering each MSISDN individually and clicking Add each time
or it can be added in Bulk by browsing a file using Find Button against Service Massive Charge
text box and then clicking Load file. The number of Services added to the campaign gets
populated under the Number of Services of the Campaign field as shown in the next diagram
where 4 services have been added.

Once these steps are complete then either we can Save File, Clear Data or Initiate the process.

View Optimal Pricing Process Progress

Once we click on the Initiate Process in the Optimal Pricing Batch Menu, the application
automatically takes the user to the View Optimal Pricing Process Progress Menu. In this menu
the user can see all the processes that have been launched from the GUI and from backend for
Optimal Pricing and their percentage completion. The processes are displayed in ascending
dates of launch of process. So the latest process launched will be present at the end. Below is
the figure showing this Window:
This window gives information about the user who launched a process, Name of the Campaign,
Date and Time in HH:MM:SS when the process was launched, Pricing Plan group which was
selected during launch of the process, No. of services for which the batch process was launched,
% of the process completed. If the process completes completely, the % progress will appear as
“Finalizado”. There is a section called Show which will have a Binocular Icon for all processes
which are complete. On clicking this icon another window with more details on the process gets
opened. The following figure shows the window which opens on clicking the Binocular Icon:

The results have the following sections:

1. The top most section describes the Name of the Campaign, Start Date when the Batch
process was initiated, End Date when the batch process finished, number of services selected
in the batch process, Name of the Price Plan Group, all the Price Plans present within the
Price Plan group selected and the Products selected when the batch process was launched.
2. A table that reflects the percentage of clients which were processed and the percentage of
clients which could not get processed. In case the percentage of clients not processed is
greater than zero, a Binocular icon will appear. On clicking this icon, a Window showing the
Percentage of the Customers which could not processed with the reason on why they were
not processed. The figure below shows the window which appears on clicking Binocular icon:

3. There is another table in this window which gives a percentage of Customers with Optimal
Price plan and the percentage of Customers which do not have an Optimal Price Plan. If the
percentage of Customers which have Optimal Price Plan is more than 0%, then a Binocular
Icon will be present. On clicking this icon, a window will appear which will show Optimal price
plan names and the % of Customers having the Optimal Plan.
If the Customers not having Optimal Price plan is greater than 0% a Binocular Icon will be
present against it and on clicking it a new Window will open as shown in the figure below. This
new window will have Actual Plan and % of Customers having it. It wall also have all the
recommended products with the % of Customers for which the product is recommended.
INFRANET:-

The application is used for Rating of VAS Services (Both Postpaid and Prepaid).
Different operations performed during Testing

A) Verifying that Customer Exists in INFRANET:-

Connect Infranet DDBB .INFRA5.TEST.AIRTEL.ES

Select in unique_account_vf_master_t and recover the poid_db, this value indicate the
database where is the client.

select poid_db, ACCOUNT_OBJ_ID0

from UNIQUE_ACCOUNT_VF_MASTER_T a
where a.MSISDN = 'MSISDN'

if the result of poid_db is1 then

Connect to
INFRA5.TEST.AIRTEL.ES
if the result is 2 then
Connect to
INFRA6.TEST.AIRTEL.ES

B) Creating an Event from FList

The events are created in Portal Infranet by using a flist. Flist is a structure that Portal
Infranet uses to carry out various operations like rating, billing etc. Below are the steps
that we need to carry out for creating a sms usage.

1. Login to Portal Infranet Unix Box.

2. Move to $HOME/testnap directory
3. In the $HOME/testnap directory open a vi editor and paste the following flist:

0 PIN_FLD_POID POID [0] 0.0.0.1 /service/sva/sms 0 0

0 PIN_FLD_MSISDN STR [0] "600000184"
0 PIN_FLD_TRANS_ID STR [0] "7318_01"
0 PIN_FLD_SERVICE_TYPE STR [0] "SMS"
0 PIN_FLD_PARAMS ARRAY [0] allocated 20, used 2
1 PIN_FLD_PARAM_VALUE STR [0] "0"
1 PIN_FLD_PARAM_NAME STR [0] "DEFAULT_FLAG"
0 PIN_FLD_PARAMS ARRAY [1] allocated 20, used 2
1 PIN_FLD_PARAM_VALUE STR [0] "2100000000"
1 PIN_FLD_PARAM_NAME STR [0] "PROVIDER_ID"
0 PIN_FLD_PARAMS ARRAY [2] allocated 20, used 2
1 PIN_FLD_PARAM_VALUE STR [0] "16371"
1 PIN_FLD_PARAM_NAME STR [0] "SERVICE_ID"
0 PIN_FLD_PARAMS ARRAY [3] allocated 20, used 2
 1 PIN_FLD_PARAM_VALUE STR [0] "1"
1 PIN_FLD_PARAM_NAME STR [0] "PREPAID_IND"
0 PIN_FLD_PARAMS ARRAY [4] allocated 20, used 2
1 PIN_FLD_PARAM_VALUE STR [0] "1"
1 PIN_FLD_PARAM_NAME STR [0] "NETWORK_TYPE"
0 PIN_FLD_PARAMS ARRAY [5] allocated 20, used 2
1 PIN_FLD_PARAM_VALUE STR [0] "ALGA"
1 PIN_FLD_PARAM_NAME STR [0] "SWITCH_ID"
0 PIN_FLD_PARAMS ARRAY [6] allocated 20, used 2
1 PIN_FLD_PARAM_VALUE STR [0] "IMEI"
1 PIN_FLD_PARAM_NAME STR [0] "214019802429154"
0 PIN_FLD_PARAMS ARRAY [7] allocated 20, used 2
1 PIN_FLD_PARAM_VALUE STR [0] "500"
1 PIN_FLD_PARAM_NAME STR [0] "PROVIDER_DEST"
0 PIN_FLD_PARAMS ARRAY [8] allocated 20, used 2
1 PIN_FLD_PARAM_VALUE STR [0] "666814845"
1 PIN_FLD_PARAM_NAME STR [0] "B_NUMBER"
0 PIN_FLD_PARAMS ARRAY [9] allocated 20, used 2
1 PIN_FLD_PARAM_VALUE STR [0] "600002177"
1 PIN_FLD_PARAM_NAME STR [0] "ORIGIN_OPERATOR"
0 PIN_FLD_PARAMS ARRAY [10] allocated 20, used 2
1 PIN_FLD_PARAM_VALUE STR [0] "123"
1 PIN_FLD_PARAM_NAME STR [0] "LOCATION"
0 PIN_FLD_PARAMS ARRAY [11] allocated 20, used 2
1 PIN_FLD_PARAM_VALUE STR [0] "680578838"
1 PIN_FLD_PARAM_NAME STR [0] "VLR_ORIGIN"

Make

4. Save the file. Now type testnap and press Enter.

5. The following prompt will be visible
> testnap
===> database 0.0.0.1 from pin.conf "userid"
nap(xxx)>
6. In the prompt type r FILE_NAME 1 and press Enter
7. If Error then some mistake is there in Flist and it need to be corrected.
8. If no error, type xop VSVA_OP_SDP_FILTER 0 1 and press Enter.
9. If it returns error, then we need to verify where the error is.
10. If no error, the output flist will be published on the screen.
11. Run the following query to see if the event is generated or not

select MSISDN, bundle_id, charge, ts_to_date(creation_date),

ts_to_date(event_date), purchase_method, trans_id
from EVENT_SVA_T where MSISDN = '600000184'
and trans_id = '7318_04'
C) Creating an Event from UEL:-

1) Put the input Mediacion file into the path /home/infranet/users/inf_bat/input/siu/trabajo

2) Go to the path "/home/infranet/users/inf_bat/sys/uel" to run the uel process.
3) Then type ./uel -t GPRS -v <name of the file> > Output.log

4) Check whether the event is created from the below query,

select * from event_sva_t where trans_id like "%...%"
Trans_id is transaction id from input file.
5) Output file will get generated in some time in the path
/home/infranet/users/inf_bat/batch/extractor_2/distributor/done.

D) Verifying Bonus, Deals in Infranet:-

To verify the Bundles use the following query:-

select c.BUNDLE_ID, ts_to_date (c.END_T), ts_to_date (c.start_t),

ts_to_date(c.cancel_date), c.CURRENT_FREE, c.INITIAL_FREE
from account_t a, ACCOUNT_PRODUCTS_T b , SERVICE_SVA_BUNDLES_T c
where a.ACCESS_CODE1 = '600000184' and a.POID_ID0 = b.OBJ_ID0 and
b.SERVICE_OBJ_ID0 = c.OBJ_ID0
and c.BUNDLE_ID in (‘<List of Bundles>’);

To Verify the Deals use the following query:-

select
access_code1,ts_to_date(d.created_t),ts_to_date(purchase_end_t),dt.name,p.name,service
_obj_type,d.status, dt.*
from account_t a, account_products_t d,product_t p,deal_t dt
where a.poid_id0 = d.obj_id0
and p.poid_id0=d.product_obj_id0
and dt.poid_id0=d.deal_obj_id0
and a.access_code1='600000184'
and service_obj_type ='/service/sva/mms'
and dt.name in ('<List of Deals>')
STRATUS

Application is used to calculate the share for the 3 rd Party in Case of Revenue Sharing
Scenario:-

Steps

1) Login to Stratus.

2) Check whether the event files from Clarify/Or some other system have been ftped at
the destination path:

3) Run the EVENT_HANDLER as mentioned below:

Stratus_start <name of the instance>

Check from respective tables, that how records are processed correctly.

Duplicate as well as error records will go to the respective directory paths and will
be embedded in the corresponding files on that location:

ERRORS
DUPLICATES

Run process “Invalidas” to insert these records into table “INVALIDAS”

As the result of run of process “Invalidas” below files are generated, indicating
that records are inserted into INVALIDAS table:

Files with correct records are generated at the respective directory path:
/home/stratus/input/internal/*****/processed

Before Running RATER, we need to check the table

BILL_GROUP.AUTO_COMMIT
In this table, AUTO_COMMIT can have two values as below
1) t  true
It means, it is a committed-bill. It will be approved automatically.

2) f  false
It means, it is non-committed bill . Again it has two categories. Which are
discussed next in this document under Billing processes.

4) Run RATER to rate the event files by running the command as below:
Startus_start <instance name>

For events files with the names, run

Startus_start <instance name>

Check respective tables for data, whether the correct records have come

Note Here DD will be the date at which event has occurred.

**
After running Rater, there are two types of Queues generated corresponding to the
Rated number.
For Example, if we run Rater STRA_R012, then following two tyes of Queues
will be generated::

QUEUE_RATER_RECYCLE_VF_012
QUEUE_RATER_REJECT_VF_012

If data goes to Queue “QUEUE_RATER_RECYCLE_VF_012”, then its not a

problem. Because it will be processed in future by CALCULATOR as per the
billing cycle.
But if Data goes to Queue “QUEUE_RATER_REJECT_VF_012”, then it’s a
problem and this data will not be processed. One of the reasons is mismatch of
BILL_GROUP_ID and BILL_CYCLE_NUMBER in tables “BILL_GROUP” and
“DEAL”

BILL Processes.

Running of Billing Processes, depends upon the condition, that if the Bill is
Committed or non-committed.

Check field value::

BILL_GROUP.AUTO_COMMIT
In this table, AUTO_COMMIT can have two values as below
1. t  true
It means, it is a committed-bill. It will be approved automatically.
In case of committed bill, we need to runn following tree billing processes:

a. BILL CONTROLLER
b. BILL CALCULATER
c. BILL GENERATOR

2. f  false
It means, it is non-committed bill . Again it has two categories. Which are
discussed next in this document under Billing processes.
In case of non-committed bills, we need to run cycle, either 5 times or 6 times.
It depends upon the field BILL_GROUP.REVIEW_DELAY
If field REVIEW_DELAY has Null value, then we need to run following 5
Billing processes:

a. BILL CONTROLLER
b. BILL CALCULATOR
c. BILL GENERATOR
After this, we need to update BILL_GROUP.GROUP_STATUS as “AP”
means approved.
d. BILL CALCULATOR
e. BILL GENERATOR
But if field REVIEW_DELAY has other then Null value, then we need to run
following 6 Billing processes:

a. BILL CONTROLLER
b. BILL CALCULATOR
c. BILL GENERATOR
d. BILL CONTROLLER
e. BILL CALCULATOR
f. BILL GENERATOR

Note Here we need not any manual approval. Instead of manual approval,
we are running BILL CONTROLLER extra.

In case of Blackberry, we have following cases/deals:

1. APM  Here need to run 5 Billing Processes. (non-committed)

2. BA  Here need to run 6 Billing Processes. (non-committed)
3. BA07 Here need to run only 3 Billing Processes (Committed)

At Starting point, we should have following status in BILL_GROUP table:

Field GROUP_STATUS = “BL”

Field REQUEST_STATUS = ”CONTROLLER”

5) Run the BILL CONTROLLER by giving following command on command prompt:-

Startus_start BCONTRL
 BILL CONTROLLER will close the bill cycles for the customers whose bill cycles falls
under that period

6) Run the BILL CALCULATOR by giving following command on command prompt:-

Startus_start BCALC

BILL CALCULATOR will calculate the bill for all those customers whose Bill cycles are
being closed by BILL CONTROLLER.

Perform following verification steps:

Check data into BILL Table:

Select BILL_NUMBER from BILL where DEAL_NAME=”APM” and

ACCOUNT_ID=XXXXXX

Let BILL_NUMBER=xyz

Check data into BILL_DETAIL

Select * from BILL_DETAIL where BILL_NUMBER=”xyz” DEAL_NAME=”APM” and
ACCOUNT_ID=XXXXXX

7) Run BILL GENERATOR by giving below command on command prompt:-

Startus_start BGEN

BILL GENERATOR will generate the BILLS for all those customers, whose BILL is being
calculated by BILL CALCULATOR.

Go to directory path: /home/stratus/stratus_2_1/output/temporal

Report of name “stratus_XXXXX.tmp” should be generated, where XXXXX is the serial

number.

Run below query to confirm if the entry of the generated report is made in table
SUBMITTING_REQUEST:

Select * from SUBMITTING_REQUEST where DOCUMENT =

”/home/stratus/stratus_2_1/output/temporal/stratus_XXXXX.tmp”

STATUS of this generated report should be as “PENDING”

Navigate to directory path: /home/stratus/output/bill/blackberry

Check a file of name APM_XXXXXXXXX_YYYYMMDD.txt is generated.
Where XXXXXXXX is the BILL_NUMBER

Now these generated reports take data from the following various tables:

RATED_BA07_LIQ_YYYYMMDD
RATED_EVENT_BA_YYYYMMDD
RATED_EVENT_BLB_YYYYMMDD

Note: Here DD will be the last date of that billing cycle month.
In order to verify the reports, we need to check data in these tables.
In order to generate INVALID data reports, run below query::
RGEN --script -o /home/stratus/output/Invalidas.xls -i excel Excel Invalidas Start_Date End_Date
NoteStart_Date= End_Date=Date of report generation.

For generating 3 general reports, run respective queries. For Eg:

1) RGEN --script -o /home/stratus/output/APM_0500.xls -i excel Excel APM_0500 30 10

2)RGEN --script -o /home/stratus/output/BA06_0500.xls -i excel Excel BA06_0500 35 5

3)RGEN --script -o /home/stratus/output/DBA07_BL0500.xls -i excel Excel
DBA07_BL0500 31 5

8) Run SUBMITTER by giving the below command on command prompt as: -

Startus_start SUBMITTER

SUBMITTER will submit all the Bills generated by BILL GENERATOR to SAP
Run below query to check is the report is being submitted to SAP

Select * from SUBMITTING_REQUEST where REMOTE_NAME =

”APM_XXXXXXXXX_YYYYMMDD.txt”

STATUS of this generated report should be as “PROCESSED”

Report”APM_XXXXXXXXX_YYYYMMDD.txt” is submitted to SAP.

The data for sending of the files are:

PPR:
IP: m2sappre
User / Pass: ftpnimbus / 01ftnimb
Path: The one which will apply according affected product.
FTP: Started by Stratus

PUC:-
This application is used to store all Information for the Prepaid Customers. General Steps
used during the execution:

Load the records in Obelix Database

1) The output files from Infranet or Mediation are input for PUC
2) Connect to PUC Prepod machine.
3) Put the input file at the path /opt/vista/OBELIX/FICHEROS
4) Go to path /opt/vista/OBELIX/PROGRAMA and run the program OBLIXxxx
(where xxx is the number specific to the project). This in turn generates another file
with the name PUC_* and this will be in the directory /opt/vista/OBELIX/FICHERO
5) Check the log at the path /opt/vista/OBELIX/LOG for OBLIX101 to check that the
process has finished correctly
6) Check the path /opt/vista/OBELIX/PREPROCESO to check that the preproceso
file has been successfully generated
7) Go to path /opt/vista/OBELIX/PROGRAMA and run the program OBLIXxxx
(where xxx is the number specific to the project).
8) Check the /opt/vista/OBELIX/LOG to verify that the process has finished correctly
9) Connect to OBELIX database and check the records of the file has been
successfully loaded.
10) Select * from OBELIX where FICHERO LIKE File name%
11) If it returns records, the file has been loaded. Check the contents of the table to
verify that they are correct.

Load the data into VISTA Database:-

1) The output files from Mediation are the input file for PUC.
2) Connect to PUC Prepod machine.
3) Put the input file at the path /opt/vista/BASE_DATOS/FICHEROS_NUE
4) Go to path /opt/vista/BASE_DATOS/PROGRAMA and run the program
VISTAxxx
5) Check the log at the path /opt/vista/BASE_DATOS/LOG for VISTA500 to check
that the process has finished correctly
6) This in turn generates PUC_* files in the path
/opt/vista/BASE_DATOS/FICHEROS_NUEVOS
7) Check the path /opt/vista/BASE_DATOS/PREPROCESO to check that the
preproceso file has been successfully generated
8) Go to path /opt/vista/BASE_DATOS/PROGRAMA and run the program
VISTAxxx.
9) Check the /opt/vista/BASE_DATOS/LOG to verify that the process has finished
correctly
10) Connect to VISTA database and check the records of the file has been
successfully loaded.
11) Select * from GPRS_XX where numero_A = MSISDN
XX is the month when the calls were made
12) If it returns records, the file has been loaded. Check the contents of the table to
verify that they are correct.
SIRA:-

SIRA is the application to manage recharges of Prepaid Customers.

To validate the recharge has been applied use the following steps:
1) Connect to database of SIRA Alias RECAR.TEST.AIRTEL.ES
User RECARGAT Password gat200
2) Search the recharge of promotion using the next query:
select a.RCRG_CC_MSISDN, b.CDEN_CC_NOMBRE,
b.CDEN_DS_DESCRIPCION, b.CDEN_CO_TELCO,
a.RCRG_CA_CANTIDAD_REAL, a.RCRG_CA_CANTIDAD,
a.RCRG_FX_FECHAHORA, a.RCRG_CO_REFOPER
from RCRG_RECARGAS a, CDEN_CODIGOS_ENTIDAD b
where b.CDEN_CO_TELCO = a.RCRG_CO_ENTIDAD
and a.RCRG_CC_MSISDN = '666666666'
Change the msisdn, and put the prepaid msisdn to search the recharge

To perform the recharge follow the following steps:

1) Login to PPRD Machine - 10.10.39.106
user - des_reca
pwd - reca321
2) home directory - des_reca@ppr-to6-c:/home/recargas/des_recargas>
3) cd test
4) vi BL_RECHARGE_627370587.in
5) Change the MSISDN number
6) Change the AMOUNT (if required)
7) Run command - driverupws BL_RECHARGE_627370587.in
8) Output -
CF_SHOP C0003238
CF_REFERENCE E3P1OD
CF_CODPROV 28
CF_ERRORDESC Recarga OK! - Recoger referencia.
PPAS_USUARIO GFI