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:
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.
Data migration scripts are provided for the following operations:
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.
You cannot migrate the product data from LD module to CL module. You must create the products in CL manually.
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:
When contracts should be migrated again, you need to execute the following scripts in the order given below.
Note
The strategy for migration of LD contracts to CL module is given below.
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 |
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.
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 |
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 |
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.
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.
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.
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.
You need to update the commitment linkages separately after the migration of both commitment and loans contracts.
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.
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.
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.
The exceptions in the migration strategy are as follows:
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 outstanding) + Unutilized as on migration date | Same as original commitment | During CL migrations, utilize the commitment | |||||
Revolving | Min value date (active loans outstanding) | Original commitment amount | Same as original commitment | During CL migrations, utilize the commitment |
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 |
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:
The migration approach is as follows:
The prerequisites for this migration are as follows:
Note
The prerequisites given above are a few basic checks to be completed. For complete details, refer to the Installation Manuals of the target version.
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_ACCOUNT_CLASS | |||||
2 | ELTR_CLTM_PRODUCT | AFTER EACH ROW | INSERT OR UPDATE OR DELETE | CLTM_PRODUCT | |||||
3 | ELTR_CLTM_PRODUCT_UDE | AFTER EACH ROW | INSERT OR UPDATE OR DELETE | CLTM_PRODUCT_UDE | |||||
4 | ELTR_GETM_LIAB_CUST_01 | BEFORE EACH ROW | INSERT OR UPDATE | GETM_LIAB_CUST | |||||
5 | ELTR_LDTB_CONTRACT_MASTER | AFTER EACH ROW | INSERT OR UPDATE | CSTB_CONTRACT | |||||
6 | ELTR_PRODUCT | AFTER EACH ROW | INSERT OR UPDATE OR DELETE | CSTM_PRODUCT | |||||
7 | ELTR_STTM_CUSTOMER | BEFORE EACH ROW | INSERT OR UPDATE | STTM_CUSTOMER | |||||
8 | ELTR_STTM_CUST_AC | AFTER EACH ROW | INSERT OR UPDATE | STTM_CUST_ACCOUNT |
You need to migrate the data from LM to ELCM module in the target version. Follow the steps given below:
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.
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
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.
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.
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 characters that are considered to be invalid in target version, then you need to change the respective RAD XML property. You must manually uncheck the uppercase property in RAD.
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.
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.
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.
Following are the limitations with regard to account creation:
Conversion scripts are not provided for the above two cases.
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'.
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.
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.
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.
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.
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.
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.
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.
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.
You need verify the modules to ensure the following: