This phase involves populating the database with financial information, transactions and all the live contracts from the existing system to the new system.
This phase of the implementation of Oracle FLEXCUBE poses many challenges. If these challenges are not planned for, it may result in serious difficulties during and after the conversion. This may then involve a re-conversion, resulting in project delay, loss of time, effort and additional expenditure.
This chapter focuses on the preparation and activities necessary to convert a branch to Oracle FLEXCUBE. Every implementation is likely to have specific requirements. Broad guidelines for the activity are mentioned here.
This chapter contains the following sections
The key players in this phase of the implementation are:
This chapter discusses the various aspects of the financial conversion for products of a branch that are covered by the following Oracle FLEXCUBE modules:
Financial conversion is often done under enormous time pressure. Input of financial data into the system calls for meticulous attention to the smallest detail and requires advance planning. The plan for conversion should cover the activities listed below.
This section contains the following topics
Conversion of financial data can be by automated means or manual. The decision regarding this should be taken well in advance since the activities will have to be planned accordingly. In case of automatic conversion the following will have to be decided in advance: -
The sequence of implementation of Oracle FLEXCUBE should be decided in consultation with the bank officials. In case of a multi branch scenario, the sequence of implementation at the various branches is to be decided, alternately, all branches may be converted at the same time, if this is estimated to be manageable. The set-up, whether centralized, distributed or decentralized, will also play a major role in deciding the sequence of conversion.
Secondly, the sequence of implementation of various Oracle FLEXCUBE modules in a branch, should be decided in consultation with the bank officials depending on their priority. In many situations, some of the modules will be taken up for implementation only after the bank goes live on critical products.
In case any of the products are to be converted in a later phase, the balances relating to those products should be kept in a separate General Account (with direct entry option) to be opened for the purpose, preferably product/ module wise. When the conversion of the products is taken up, these accounts will be the take-down account, and the balance in the accounts will become zero.
After the financial data have been entered, FX revaluation should be done on both the systems - existing and Oracle FLEXCUBE.
Before getting to the stage where financial entries are passed into the Oracle FLEXCUBE, the implementation team should check whether the following have been adequately taken care of:
Some of the precautions that have to be taken during the conversion activities are as follows:
The conversion of financial data to Oracle FLEXCUBE is performed by passing offsetting entries to the conversion accounts or customer settlement accounts defaulted as conversion account, setup specifically for this purpose.
The conversion in the simplest form implies that the various account balances (forming a part of the Trial Balance) be transferred to the Oracle FLEXCUBE accounts through Journal Entry as debit or credit entries as the case may be. At the end of this exercise, the balances would have been transferred and the total debits and credits would match, provided they matched in the existing system.
However, such a simplistic situation is not likely to occur in an installation. The primary reasons for this are:
In order to circumvent these problems, all offsetting entries to existing balances are posted to a Conversion Account. All contracts are entered with Customer settlement accounts (take-down accounts) as the conversion account so that they do not affect the customer account balances.
Similarly, the interest/provision accounts balances are entered by accruing in the Oracle FLEXCUBE system after entry of balances in all the accounts and passing adjustment entries to these accounts and the corresponding offset entries to the conversion account.
By following this principle, at the end of the conversion exercise, the conversion account(s) would have a zero balance. In case this is not so (i.e., the balance is not zero), it will serve as an indication that some of the account balances have not been transferred correctly. By examining the entries posted and checking the balances of all other accounts the error can then be traced and rectified. This rectification process should continue till the balance in the conversion accounts becomes zero or is brought down to an acceptable limit so that the branch can go parallel.
A generic description of the conversion process has been given here and the actual conversion process could have other items / aspects which would need to be considered on a case-by-case basis.
This section aims to explain the conversion procedure outlined in the previous section by giving an example of the accounting entries passed in a conversion exercise.
For the purpose of this exercise, we will consider the following accounts and contracts that are outstanding at the time of conversion. All accounts have been assumed to be in local currency. For simplicity sake, only a few accounts have been considered.
| Account | Amount | ||
|---|---|---|---|
| Cash | 100,000 DR | ||
| Current account of Mr. | 1,000 CR | ||
| Savings account of Mr. | 500 CR | ||
| Accrual account (deposits) | 3,000 CR | ||
| Accrual account (loans) | 2,000 DR | ||
| Interest Paid | 3,500 DR | ||
| Interest Received | 2,500 CR |
Outstanding Contracts Details:
| Contract | Amount | ||
|---|---|---|---|
| Deposit contract account | 150,000 CR | ||
| Loan contract account | 51,500.DR |
The entries generated during the conversion activity are shown below. Note that the figures in parentheses refer to the running balance of the conversion account and after all the entries are completed, the balance becomes zero.
Deposit contract entry will generate the following entries: -
| Accounting Entries | |||||
|---|---|---|---|---|---|
| DR Conversion account* | 150,000 | 150,000 DR | |||
| CR Deposit account | 150,000 | ||||
| DR Interest Paid | 3,000 | ||||
| CR Accrual account (dep.) | 3,000 | ||||
Loan contract entry will generate the following entries: -
| Accounting Entries | |||||
|---|---|---|---|---|---|
| DR Loan account | 51,500 | ||||
| CR Conversion account* | 51,500 | (98,500 DR) | |||
| DR Accrual account (loan) | 2,000 | ||||
| CR Interest received | 2,000 | ||||
Through Data Entry transfer the following balances will result in the entries shown below: -
| Accounting Entries | |||||
| DR Conversion account | 500 | (99,000 DR) | |||
| CR Savings account | 500 | ||||
| DR Conversion account | 1,000 | (100,000 DR) | |||
| CR Current account | 1,000 | ||||
| DR Cash account | 100,000 | (Nil Balance) | |||
| CR Conversion account | 100,000 | ||||
The entries also result in correct balances in all the accounts other than the accrual and interest paid/received accounts. These balances will be finally adjusted as follows: -
Since the balances in the two accrual accounts generated by the contracts match the accrual account balances in the existing system, no adjustments will be required.
However, the balances in the interest accounts do not match. This could be due to the reasons outlined in section 9.4.1, and the following entries will be made through Data Entry to adjust the balances.
Reverse the balance generated by the contracts entry:
| Accounting Entries | |||||
| DR Interest received account | 2,000 | ||||
| CR Conversion account | 2,000 | (2,000 CR) | |||
| DR Conversion account | 3,000 | (1,000 DR) | |||
| CR Interest Paid account | 3,000 | ||||
The above entries will make the balances in the respective accrual accounts zero. After this, input the existing system balances into Oracle FLEXCUBE accounts as follows:
| Accounting Entries | |||||
| DR. Conversion account | 2,500 | (3,500 DR) | |||
| CR. Interest Received | 2,500 | ||||
| DR. Interest Paid account | 3,500 | ||||
| CR. Conversion account | 3,500 | (Nil) | |||
After this set of entries, the conversion account is restored to zero balance and the interest accounts have the correct balances as per the existing system. At this stage, the transfer financial data to Oracle FLEXCUBE is complete and correct and the system is ready for parallel run.
Conversion Account will be maintained as the takedown account, during the product set-up.