4. Module Upgrade

4.1 Introduction

This chapter discusses the data migration methods specific to Oracle FLEXCUBE Universal Banking Solutions modules. This step is part of the mock upgrade activity. The following points are discussed in detail in this chapter:

4.2 Scope

The scope of the Oracle FCUBS module upgrade is discussed below.

Upgrade of Revamped Modules

The Oracle FCUBS modules such as LD and LM in the older versions are revamped and upgraded to CL and ELCM modules. This migration requires the bank’s consent and such cases must be handled separately.

As the target version application may refer to a new set of tables, you need to move the data from the old set of tables to the new set.

Upgrade of Existing Modules

In the target version, new tables and columns may have been added as part of functional enhancements. You need to use the module wise conversion scripts to migrate the data from such modules.

You need to separately handle the customization changes done at site. Involve the bank authorities in the discussions and decide whether data migration is required for the tables added as part of customization. Identify such requirements and document that as an addendum to this guide.

For the existing tables, if data conversion scripts are not provided for newly added columns or existing columns, you need to analyze and handle them manually.

4.3 Upgrade of Revamped Modules

Data migration scripts are provided for the following operations:

4.4 Migrating Data from Loans and Deposits to Consumer Lending Module

The loans portion of LD module has been replaced with CL module in the versions later than FCUBS 7.1.0.0.0.0.2. You can use the migration scripts to upload all active loans from LD module to CL module.

This involves the following steps:

You must migrate commitments before loans. For ease of reference, this document first discusses the loans migration strategy and then the commitment migration strategy.

4.4.1 Migrating Products from LD to CL

You cannot migrate the product data from LD module to CL module. You must create the products in CL manually.

4.4.2 Migrating Contracts from LD to CL

The method of migrating LD contracts to CL module is explained below.

Prerequisites for Source

The below set of instructions are applicable for the source environment

You need to first identify the LD contracts which are not eligible for migration. You can identify such contracts using the script ‘Prelim_src_data_chk.sql’. This script is available in the location ‘SOFT\TOOLS\Upgradeto2olkit\Soft\Migration\LD-CL\SCRIPTS\SOURCE’.

Execute the script ‘Prelim_src_data_chk.sql’ to populate the LD contracts which are not eligible for migration.

The following objects needs to be compiled in the source environment for successful execution of this script.

Once you execute the script ‘Prelim_src_data_chk.sql’ in the source environment, it will print the following output:

querying from CSTB_LD_CONTRACT_CHECK...

COUNT(1)

---------------

0

query should return ZERO rows....

If the count is greater than zero, then the details of the contracts that are not eligible for migration will be populated in ‘CSTB_LD_CONTRACT_CHECK’. You need to scrutinize them.

Note

If you are not able to correct the non-eligible contracts, you need o manually reverse such LD contracts.

Prerequisites for Target

For target version, you need to do the following maintenances:

Once the above maintenances are done, you can execute the scripts for migration. These scripts will migrate the eligible LD contracts to CL module.

You must execute the following scripts in the order given below:

  1. 1_pre-migration-upd.sql
  2. 2_ld-comt-extraction.sql
  3. 3_commitment-upload.sql
  4. 4_ld-loan-extraction.sql
  5. postextraction_check_html.sql
  6. 5_cl-upload.sql
  7. 5.1.post-migration-checks.sql
  8. 6_limits-update.sql
  9. 7_bills-update.sql
  10. 8_post_migration_updates.sql

When contracts should be migrated again, you need to execute the following scripts in the order given below.

  1. cl_account_creation_rollback.sql
  2. ld_extraction_rollback.sql

Note

    • You need to create the CL products manually through front end.
    • Characteristics of LD module like GL mapping, tenor, transaction code, holiday period, exchange rate code etc. must be the maintained AS IS in CL. There should not be any deviation.
    • Once the migration is completed, irrespective of the Interest period basis for contracts in LD, the corresponding CL accounts will be based on ‘Include from’ and ‘Exclude to’.
    • Schedules pertaining to capitalized LD contract in CL would not be reflected after migration. Nevertheless, capitalization will be handled on the schedule due date.

4.4.2.1 General Migration Strategy

The strategy for migration of LD contracts to CL module is given below.

  1. LD loans portfolio is migrated to CL module.
  2. Only active LD contracts are considered for migration. Inactive, liquidated or reversed contracts will not be migrated.
  3. Contract Reference Number in LD module is stored as Alternate Account Number in CL module. This Alternate Account Number can be used for future references.
  4. The status of the LD contracts migrated to CL module will be updated as ‘M’ to indicate that they were migrated contracts. Changes will be done in the batches to ignore all contracts with status ‘M’.
  5. All the loans migrated to CL module will start with version 1 and event DSBR.
  6. The value date of the LD contracts will be the original start date of the CL accounts. Incase the original start date is available in the LD contract, then it will be taken as the original start date of the CL account.
  7. Value date of the migrated CL accounts will be determined from the Last Fully Paid Schedule's Due Date (LFPSD) irrespective of the schedule type, payment method, status and interest rates (fixed / floating). This LFPSD will be the Last fully Paid Schedule for Principal/Interest component.

Example - Case 1

In the below example, Principal and Interest components are fully paid on April 15, 2012 and Interest is fully paid on May 16, 2012. whereas Principal component for May 16, 2012 is Outstanding. So, the LFPS would be on April 15, 2012.

Contract Reference Number Component Due Date Amount Due Amount Settled
406LILP10040000Z INTEREST 1/17/2012 120 120
406LILP10040000Z PRINCIPAL 1/17/2012 1000 1000
406LILP10040000Z INTEREST 2/15/2012 120 120
406LILP10040000Z PRINCIPAL 2/15/2012 1000 1000
406LILP10040000Z INTEREST 3/15/2012 110 110
406LILP10040000Z PRINCIPAL 3/15/2012 1000 1000
406LILP10040000Z INTEREST 4/15/2012 110 110
406LILP10040000Z PRINCIPAL 4/15/2012 1000 1000
406LILP10040000Z INTEREST 5/16/2012 100 100
406LILP10040000Z PRINCIPAL 5/16/2012 1000 0
406LILP10040000Z INTEREST 6/15/2012 100
406LILP10040000Z PRINCIPAL 6/15/2012 1000 0
406LILP10040000Z INTEREST 7/15/2012 100
406LILP10040000Z PRINCIPAL 7/15/2012 1000 0

Example - Case 2

In this example, the Principal component is fully paid on March 30, 2012 and the Interest component is fully paid on April 15, 2012. LFPS in this case would be March 30, 2012.

Contract Reference Number Component Due Date Amount Due Amount Settled
406LILP10040000Z INTEREST 1/17/2012 120 120
406LILP10040000Z INTEREST 2/15/2012 120 120
406LILP10040000Z INTEREST 3/15/2012 110 110
406LILP10040000Z PRINCIPAL 3/30/2012 1000 1000
406LILP10040000Z INTEREST 4/15/2012 110 110
406LILP10040000Z INTEREST 5/16/2012 100 50
406LILP10040000Z INTEREST 6/15/2012 100 0
406LILP10040000Z PRINCIPAL 6/30/2012 1000 0
  1. Migration date plays a vital role in this strategy. No operations (payments, amendment, rollover, reversals) are allowed on migrated loans prior to the migration date.
  2. The LD outstanding principal amount as on the migration date is taken as ‘Amount Disbursed’ and ‘Amount Financed’ in CL account. Original loan amount has to be stored as a UDF at CL contract level. Contracts with fully paid principal amounts will be migrated with 0.01 as ‘Amount Disbursed’ / ‘Amount Financed’.

Example - Case 1

The principal outstanding from the last fully paid schedule (No partial payment after LFPS).

Loan Date: December 15, 2011

LFPS: April 15, 2012

Migration Date: June 30, 2012

Contract Reference Number Component Due Date Amount Due Amount Settled
406LILP10040000X PRINCIPAL 1/17/2012 6734.310 6734.310
406LILP10040000X PRINCIPAL 2/15/2012 7394.010 7394.010
406LILP10040000X PRINCIPAL 3/15/2012 7571.560 7571.560
406LILP10040000X PRINCIPAL 4/15/2012 7112.080 7112.080 (LFPS)
406LILP10040000X PRINCIPAL 5/16/2012 7130.450 0.000
406LILP10040000X PRINCIPAL 6/15/2012 7306.740 0.000
406LILP10040000X PRINCIPAL 7/15/2012 7325.000 0.000
406LILP10040000X PRINCIPAL 8/15/2012 7186.670 0.000
406LILP10040000X PRINCIPAL 9/15/2012 7205.240 0.000
406LILP10040000X PRINCIPAL 10/17/2012 7068.410 0.000
406LILP10040000X PRINCIPAL 11/15/2012 7551.820 0.000
406LILP10040000X PRINCIPAL 12/15/2012 7413.71 0.000 - Maturity
TOTAL     87000 28811.96

Principal Outstanding = 87000 - 28811.96 = 58188.04

In the above case, since the principal outstanding is 58188.04 on the migration date -

CL Account Disbursement Amount = 58188.04

Amount Financed = 58188.04

Original disbursement amount 87000 has to be stored as UDF at the CL account Level.

To summarize, the least of the last fully paid schedule among the components pertaining to a loan will be considered as the value date of the account.

  1. During migration from LD to CL module, the fully paid schedules are not considered. Only the partially paid and unpaid schedules are migrated to CL module. History of the fully paid schedules have to be viewed from LD screens.
  2. All overdue schedules (partial/full overdue) for all components are moved to CL with the current outstanding amount as it is without any further calculations. This table is stored in a table and contains the data as is from LD module. This table contains data for all schedules between LFPSD and migration date. Current running schedule will also be present in this table. This will be applicable to outstanding interest, penalty, unpaid principal amount and up-front fees collected.
  3. All the future schedules from migration date onwards are calculated automatically in CL module based on the schedule definition at the contract level.
  4. When the minimum tenor of a CL product is higher than the tenor of the active pending loans of the corresponding LD contracts, the product definition of CL product has to be modified manually for the migration purpose. You can later update it to the actual tenor. During migration, the minimum tenor will be updated as one day and once the contract migration is over, the CL products should be updated to its original minimum tenor as in the LD product.
  5. Contracts having only bullet schedule for principal and interest components are migrated with the original value date.
  6. For a given contract, the following values are migrated from LD to CL module for a given contract
    LD (Loans) CL (Loans)
    Contract Reference Number Alternate Account Number
    Last Fully Paid Schedule's Due Date (LFPSD) Value Date
    Book Date Book date will be the Migration Date
    Maturity Date Maturity Date
    Outstanding principal amount as on migration date Loan Amount
    Original Start Date Original Start Date
    Value Date Original Start Date (if original start date is null in LD)
    Number of Schedules Derived (LD original schedules as on LFPSD)
    Frequency Same as in LD from LFPSD
    No of Units Derived from LFPSD
  7. For a given contract, the following details are migrated from LD to CL module:
    LD (Loans) CL (Loans)
    Contract CL Account Upload
    Parties CL Account Parties Upload
    Components CL Component Upload
    Schedules CL Component Schedule Upload
    Interest Rates CL Account UDE Upload
    Linkages CL Linkages Upload
    Settlement Details CL Account Settlement Upload
    MIS Details Migrated as is from LD contract

4.4.2.2 Accounting Strategy

During the migration process, accounting entries will not be passed in CL module during. All the relevant tables, especially GL balances, will be populated from LD to CL module.

GL mapping between CL tables and LD tables should be the same. Otherwise you may notice inconsistencies in the GL balances.

4.4.2.3 Interest and Accrual

The accrued interest is populated in one table which will have CL replica of LD from last fully paid schedule due of LD till the migration date including the current running schedule. This is applicable to outstanding interest, penalty, unpaid principal amount and up-front fees collected.

During the migration process, accounting entries will not be passed in CL module during. All the relevant tables will be populated as they are from LD module starting from the last fully paid schedule till the migration date including the current running schedule. Accruals from the migration date onwards will continue in CL module.

Example

Consider the following details:

Loan Contract: 550AMN208086xxxx

Loan Book Date: January, 25 2012

LFPSD: May 26, 2012

Migration Date: July 20, 2012

Contract Reference Number Component Due Date Amount Due Accrued Amount Amount Settled
550AMN208086xxxx AMN2-INTER 1/26/2012 56.020 56.020 56.020
550AMN208086xxxx AMN2-INTER 2/28/2012 52.960 52.960 52.960
550AMN208086xxxx AMN2-INTER 3/28/2012 37.570 37.570 37.570
550AMN208086xxxx AMN2-INTER 4/26/2012 31.170 31.170 31.170
550AMN208086xxxx AMN2-INTER 5/26/2012 24.170 24.170 (LFPS) 24.170
550AMN208086xxxx AMN2-INTER 6/27/2012 17.120 17.120 0.000
550AMN208086xxxx AMN2-INTER 7/26/2012 55.860 44.56 0.000
Total 274.870 263.57 201.890

In the above example since till 26 May, 2012 the interest has been fully paid by the customer. Accrued interest in above example will be 61.68.

At the time of migration, the system will migrate schedules which are partially paid/unpaid. LD partially paid/unpaid schedule will be migrated and populated in the CL table ‘cltb_mig_account_schedule’ as given below.

Contract Reference Number Component Due Date Amount Due Accrued Amount Amount Settled
550AMN208086xxxx AMN2-INTER 6/27/2011 17.120 17.120 0.000
550AMN208086xxxx AMN2-INTER 7/26/2012 55.860 44.56 0.000
Total 72.980 61.68 0.000

Note

From the migration date onwards, accrual will continue as per the existing CL calculation.

4.4.2.4 Status Change Rules

Status change rules are applicable to automatic as well as manual status changes.

Automatic Status Change Rules

After migration, irrespective of the status in LD module, all the CL accounts have ‘NORM’ status.

During migration when the CL account upload happens, the system processes status change, by suppressing the CL status. This action will move the status depending on the status change rule maintained for the CL products after the CL account upload. The status change rule should to be maintained with the same conditions as in the LD module to ensure that the account status will change from ‘NORM’ to the new status. The status of the LD contract is matched against the changed status of the CL account, to ensure that the status has not changed after migration.

Note

During migration, the status change of CL accounts is strictly based on the rules defined at product level. Statuses that are supposed to be manual must be maintained as ‘Manual’ at CL Product level in order to avoid incorrect status derivation.

Manual Status Change Rules

There may be loan contracts in the LD modules whose status has been manually changed.Such contracts will be migrated to CL module with the status ‘NORM’. Once the migration is completed, you need to manually change the status of these accounts to their respective statuses in LD module. You also need to manually reverse the accounting entries passed during manual status change.

4.4.2.5 Limits Utilization

During CL account migration process, the limit utilization will be disabled. After migration, the ELCM tables will be updated with the new CL account number in place of loans reference number.

After the migration process, the component wise balances, interest rates, schedule definition, UDF fields, calculation method, date fields etc. have to be compared and verified with LD module contracts.

4.4.2.6 Commitments Linkage

You need to update the commitment linkages separately after the migration of both commitment and loans contracts.

4.4.2.7 MIS

During the CL account migration process, the MIS update is disabled. After the migration, the MIS tables will be updated with the new CL account number in place of loans reference number.

4.4.2.8 UDF

You need to associate the user defined fields defined at the LD product level with the CL products. Account level UDFs attached to the LD contracts will be automatically migrated to CL accounts based on the product mapping done in CL. New UDFs has to be created for storing the original loan amount.

4.4.2.9 SMS

The customer needs to define the SMS roles for new function IDs. Since the LD - CL function ID mapping is not always one-one, the bank needs to manually do the new role configuration.

4.4.2.10 Exceptions in Migration Strategy

The exceptions in the migration strategy are as follows:

4.4.3 Migrating Commitments

Commitment migration strategy is similar to the loans migration strategy except for the derivation of commitment amount and value date.

See “Migrating Data from Loans and Deposits to Consumer Lending Module” on page 2. for the migration flow of loans. You can follow the same method for commitment migration except for derivation of commitment amount and value date.

Derivation logic for commitment amount and value date is given below.

Type Value Date Amount Maturity Date Linking Strategy
Non-revolving Min value date (active loans outstanding) Sum (active loans outstand­ing) + Unutilized as on migration date Same as origi­nal commit­ment During CL migrations, uti­lize the com­mitment
Revolving Min value date (active loans outstanding) Original commit­ment amount Same as origi­nal commit­ment During CL migrations, uti­lize the com­mitment

Example

This example explains the derivation of parameters for non-revolving and revolving commitments. Assume that the commitment does not have VAMI events and the loans have simple BOOK and LIQD events.

Non-revolving:

Commitment Event Date Utilized Un-utilized LD Contract Event Amount
C1 (1000) 01-Jan-12 0 1000      
  01-Feb-12 100 900 L1 BOOK 100
  01-Mar-12 300 700 L2 BOOK 200
  01-May-12 300 700 L1 LIQD** 100
  01-Jun-12 150 550 L3 BOOK 150

Contract L1 is liquidated on 01 May, 2012. Hence L1 is not migrated.

C1 is migrated as CX1, L2 is migrated as LX2 and L3 is migrated as LX3.

Migration Date: 15 June, 2012

Commitment Value Date: 01 May, 2012 (Minimum of value date of active loan (L2,L3))

Commitment amount: 350 + 550 = 900 (sum of outstanding loans (L2,L3) + Un-utilized)

Utilization is as follows:

Commitment Event Date Utilized Un-utilized LD Contract Event Amount
CX1 (900)            
  01-Mar-09 0 900      
  01-Mar-09 200 700 LX2 BOOK 200
  01-Jun-09 350 550 LX3 BOOK 150

Revolving:

Commitment Event Date Utilized Un-utilized LD Contract Event Amount
C2 (1000) 01-Jan-12 0 1000      
  01-Feb-12 100 900 L11 BOOK 100
  01-Mar-12 70 930 L11 PAYM 30
  01-Mar-12 270 730 L12 BOOK 200
  01-Apr-12 240 760 L11 PAYM 30
  01-Apr-12 190 810 L12 PAYM 50
  01-May-12 150 850 L11 LIQD** 40
  01-Jun-12 300 700 L13 BOOK 150

Contract L1 is liquidated on 01 May, 2012. Hence L11 is not migrated.

C2 is migrated as CX2, L12 is migrated as LX12 and L13 migrated as LX13.

Migration Date: 15 June, 2012

Commitment Value Date: 01 March, 2012 (Minimum of value date of active loan (L12, L13))

Commitment amount: 1000 (Original amount)

Utilization is as follows:

Commitment Event Date Utilized Un-utilized LD Contract Event Amount
CX2 (1000)            
  01-Mar-12 0 1000      
  01-Mar-12 150 850 LX12 BOOK 150
  01-Jun-12 300 700 LX13 BOOK 150

4.5 Migrating Data from LM Module to ELCM Module

The LM module in the source version may have been revamped as ELCM module in the target version. You need to migrate the LM data to the ELCM module. This involves the following steps:

4.5.1 Migration Approach

The migration approach is as follows:

4.5.2 Prerequisites

The prerequisites for this migration are as follows:

Note

The prerequisites given above are a few basic checks to be completed. For complete de­tails, refer to the Installation Manuals of the target version.

4.5.3 Enabling Triggers

Before you import the data from LM to ELCM in the target schema, you need to enable certain ELCM related triggers. You can enable the triggers using the script ‘ELCM-TriggersEnable.sql’.

See “Annexure” on page 1. for details on the location and usage of the SQL file.

As per the migration strategy, by default all the triggers are disabled before the data import. However, the triggers mentioned in this section must be enabled as exceptional cases.

The list of triggers is given below:

Sl. No. Trigger Name Type Event On Table
1 ELTR_ACC_­CLASS AFTER EACH ROW INSERT OR UPDATE OR DELETE STTM_AC­COUNT_CLASS
2 ELTR_CLT­M_PRODUCT AFTER EACH ROW INSERT OR UPDATE OR DELETE CLTM_PROD­UCT
3 ELTR_CLT­M_PRO­DUCT_UDE AFTER EACH ROW INSERT OR UPDATE OR DELETE CLTM_PRO­DUCT_UDE
4 ELTR_GETM_LIA­B_CUST_01 BEFORE EACH ROW INSERT OR UPDATE GETM_LIA­B_CUST
5 ELTR_LDTB_­CON­TRACT_MASTER AFTER EACH ROW INSERT OR UPDATE CSTB_CON­TRACT
6 ELTR_PRODUCT AFTER EACH ROW INSERT OR UPDATE OR DELETE CSTM_PROD­UCT
7 ELTR_STT­M_CUSTOMER BEFORE EACH ROW INSERT OR UPDATE STTM_CUS­TOMER
8 ELTR_STT­M_CUST_AC AFTER EACH ROW INSERT OR UPDATE STT­M_CUST_AC­COUNT

4.5.4 Migrating Data

You need to migrate the data from LM to ELCM module in the target version. Follow the steps given below:

  1. Ensure that the triggers related to ELCM are enabled.
  2. Use the package ‘ELPKS_LM_REPLICATION’ to migrate LM data to GE (ELCM module) tables. You can use the stub ‘LM_EL_MIG_Stub.sql’ to call the package.
  3. See “Annexure” on page 1. for details on the location and usage of the LM_EL_MIG_STUB.sql.
  4. Use the function ‘fn_process’ for migrating maintenance entities and utilizations. You may migrate the entities either one-by-one or all in one stretch. The parameters to the function are as follows:
    • p_user_id IN VARCHAR2,
    • p_ref_no IN OUT VARCHAR2,
    • p_function_id IN VARCHAR2,
    • p_process_no IN NUMBER,
    • p_remarks IN VARCHAR2,
    • p_errs IN OUT VARCHAR2,
    • p_prms IN OUT VARCHAR2
  1. In the above list, the parameter ‘p_function_id’ is a mandatory parameter. You may leave the other parameters blank. Remarks, if passed, will be used for updating the log tables.
  2. The tables ‘eltb_migration_log’ and ‘eltb_mig_exception_log’ are the log tables populated during the migration process.
  3. You can control the behaviour of the migration using function ID input parameter. If you pass the value ‘ALL’ as the input, then all liabilities, maintenance entities and utilizations will be migrated in one step. Or we can pass individual function IDs to migrate each entity one-by-one. The functions IDs are listed below:
    • GEDMLIAB - Liabilities Maintenance
    • GEDCULIK - Liability-Customer Link
    • GEDCOLTY - Collateral Types Maintenance
    • GEDSTYPE - Static Types Maintenance
    • GEDCOLCA - Collateral Categories Maintenance
    • GEDISSUR - Issuer codes Maintenance
    • GEDSECTY - Securities Maintenance
    • GEDCOLLT - Collaterals Maintenance
    • GEDCOLTD - TD Collaterals
    • GEDMPOOL - Pool Collateral Linkages
    • GEDFACLT - Facilities Maintenance
    • GEDTRANS - Facilities Transger
    • GEDBLOCK - Facilities Block
    • GEDTRKEXP - Country wise limits
    • GEDUTILUPD - Utilization Upload
    • GEDUTILMIG - Utilization Migration

4.5.5 Truncating Database

During upgrade, you may need to iterate the migration of LM to ELCM module. Before an iterative migration, the EL tables in target database can be truncated to re-run the whole process.

You can use the script ‘ELCM_TRUNCATE.sql’ to truncate.

See “Annexure” on page 1. for details on the location and usage of ELCM_TRUNCATE.sql.

Note

Partial truncation or partial re-migration is not supported.

4.6 Migrating Data from Branch to Retail Teller

In Oracle FCUBS 10.0 version, the branch related data has been moved to new set of tables. Conversion or upgrade scripts are not provided for migration of branch data into retail teller.

At the time of upgrade, the implementation team needs to ensure that outstanding transactions are not pending to be posted to the account at the time of cut-over in any of the web-branches.

The clearing checks which are yet to be paid will come as part of the host-data-migration. That will be available in the upgraded system.

Amendment or reversal an old transaction, which was entered before upgrade, is not supported in the new system after upgrade.

You can setup the new Retail-Branch.

For details, refer to the chapter ‘Data Replication’ in ‘Savings’ user manual.

Note

4.7 ATM/POS Modules Impact

For handling ATM/POS transactions in Oracle FCUBS, ‘Switch’ module was introduced in version 10.3. From this version a totally new set of tables are used. Migration scripts are not provided for the upgrade.

At the time of cut-over, all the transactions should have been posted to the accounts from the Switches. You need to ensure that there is no pending transaction in the Switches.

Reversal of a transaction entered in the source version is not supported in the new system after upgrade.

Maintenance table of ATM/POS terminals may have huge data. The bank may want to migrate such data to the new system.

4.8 Upgrading Existing Modules

You need to upgrade the modules that are not revamped. The conversion scripts for new tables, columns and functional enhancements are available in the ‘Conversion Script Repository’ (See “Conversion Script Generation Tool” on page 1.).

Scripts are available for the following modules for upgrade from a lower versions to a higher version.

4.8.1 Generic Conversion Methods

The generic conversion methods are discussed under the following headings.

Note

If the source data has account numbers which are in mixed case alphabet or contain char­acters that are considered to be invalid in target version, then you need to change the re­spective RAD XML property. You must manually uncheck the uppercase property in RAD.

4.8.1.1 Node Update

Node field is updated with the new database name in different tables across modules. The script for node update is available in the conversion script repository.

4.8.1.2 Basic Parameters Setup

As per the upgrade strategy, E-Data tables will not get imported into target schema. The basic application level parameters (CSTB_PARAM table) is of type E-Data. It cannot be imported to the target version.

You can setup the basic parameters through the following methods:

The implementation team should verify the parameter values wherever parameters are set up.

4.8.2 Upgrading Core Module

Conversion scripts are provided for various tables related to GL, ST, CIF, CASA, IC, IS and MS modules.

See “Conversion Script Generation Tool” on page 1..

Import the source data into target schema and apply the conversion scripts referred above. Once this step is completed, you need to do some maintenances for the imported data to work in the target environment.

In case of CIF screen, note that the data in the maintenance tables of the LOV fields (option lists) like ‘Prefix’, ‘Customer Category’ etc. may have mixed case text. But in the new setup of Oracle FCUBS (12.0 and higher), such data is expected to be created in upper case. FCUBS 12.0.2.0.0 accepts mixed case characters during modification of the records.

4.8.2.1 Limitations

Following are the limitations with regard to account creation:

Conversion scripts are not provided for the above two cases.

4.8.3 Upgrading SMS Module

4.8.3.1 Password History

During migration, if the source version is older than Oracle FCUBS 11.3, you should not move the password history from source to target.

You can control this by updating the column ‘DATA_IMPORT_REQD’ in ‘CVTM_TABLE_TYPES’ to 'N' where TABLE_NAME ='SMTB_PASSWORD_HISTORY'.

4.8.3.2 Password Reset

Once the data upgrade activities are completed and the front end application is setup, you may login to the new system. However, you need to reset the password.

Using the Oracle FLEXCUBE Universal Banking Installer, you can create two users with password.

Refer to the Installation Manual ‘User Creation Utility’ for details.

You can login to new system with the user IDs created. Once logged in, you can reset the password for any or all the users. You can use the ‘User Credentials Change’ (SMDCHPWD) screen to reset the password.

You can directly specify the password in the field only if it is enabled. Otherwise, you will notice the option ‘Reset Password’ as enabled.

Refer to the user manual ‘Security Management System’ for details on this screen.

4.8.4 Upgrading Deposits Module

The existing deposits in the source version will be created based on the ‘Deposit’ type of products as part of LD (Loans and Deposits) module. These deposits will be migrated as ‘Corporate Deposits’ and can be handled through the CD (Corporate Deposits) module.

If required, you need to configure new TD products in the target version (12.0.0 or higher) to make use of the TD functionality.

4.8.5 Dynamic Package Generation for IC Rule

A stub is provided to generate the rule based package dynamically. For each rule in IC module, a package, which is necessary for the functioning of IC module, is generated.

The package ‘icpks_gen_new.PR_GEN_RULE’ is called for each IC rule defined.

4.8.6 Dynamic Package Generation for Products in CD/MM

A stub is provided to generate a dynamic package for each of the migrated products in CD and MM modules.

The package ‘Ldpkss_Status_Rule_Gen.Fn_Gen_Rule’ is called for all CD and MM products.

4.8.7 Upgrading PC Module

4.8.7.1 Dynamic Package Generation for Products in PC Module

A stub is provided to generate a dynamic package for each of the migrated products in PC module. This package will help in resolving the rule set at product level for charges calculation.

The package ‘PCPKS_CHG_CALC.Fn_Create_Body’ is called for all PC products.

4.8.7.2 Bank Clearing Network Maintenance

In lower versions of Oracle FLEXCUBE the bank network clearing maintenance was not mandatory. However, it is mandatory in the higher versions.

Once the migration process is complete, before you start with the operations, maintenances need to be done for the required ‘Bank Code-Network ID’ combinations.

4.8.8 LC Module - Tracers Generation

If the batch ‘LCTRACER’ is maintained as part of EOD/BOD batch, make sure that the advices are properly maintained for TRGN event of the product. Otherwise, LC tracer will fail due to non-maintenance of advices for TRGN event.

4.8.9 Upgrading CASA Module - Lower Case Alphabets in Account Number

In the higher versions of Oracle FCUBS, only upper case alphabets are allowed in account numbers. However, in lower versions which needs to be upgraded, in the existing database the account number fields may have alphabets in both upper and lower cases. You need to handle such cases separately.

To handle such situations, after upgrade, you can correct the front end UI file to accept lower case input in the below fields:

You should not set the ‘Upper Case’ property and ‘Restricted Text’ property in the RAD XML for the above fields. The RAD XML for these fields is ‘STDCUSAC_RAD.XML’.

Once the changes are effected, you need to deploy the UI files and related back end packages. Refer to the Installation Manuals of the target version for details.

4.9 Module Wise Verification Check Points

You need verify the modules to ensure the following: