In this activity, the database is populated with the Parameters, Code set-up and other static information (non-financial) as finalized in the database design activity.
This chapter contains the following sections
The data input activity involves the following major steps:
Population of data into the database can be carried either manually or can be automated. Large volume data are best automated. Parameter inputs of specialized and critical nature should be manually input for better control. If the existing operations of the banks are carried out in multiple systems (including manual registers, if any), it would be better if the data from these systems are first collated and translated into a common system, such as spread sheet package.
Automated data population can be carried out using standard conversion tools supplied as a part of tool-kit along with office automation package such as spreadsheets.
For banks moving from MicroBanker to Oracle FLEXCUBE, standard conversion tools for the purpose would be used.
The data and field structure to be maintained in the spread sheet for upload should be clearly worked out. As mentioned earlier, data relating to a common table, from different sources should be collated and made available in a single spreadsheet. The IT department of the bank should be made primarily responsible for making available the spread sheets in appropriate formats. Oracle Financial Services implementation team may offer any assistance, if required.
Code and identifier translation from old values to new values should be carefully checked out. Appropriate strategy should be evolved if the existing codes are not translated on one-to-one basis. Such cases should be dealt with separately, if required, manually. A master list of all such translations should be printed and kept aside for future cross-referencing.
Data which is planned to be input manually should be first filled in an appropriate input form and verified and signed off by the person responsible.
Data input and conversion process is likely to be different for each installation. For every implementation a conversion plan has to be prepared, covering all the activities of the bank, automation strategies etc.
Before embarking on data input the following should be ensured:
Input of static data and parameters in various tables requires a specific sequence to be followed. This is due the reason that certain tables are dependent on other tables, thus necessitating the maintenance of those tables first. Inputs to some of the tables can be grouped together. It is not necessary that all maintenance have to follow a sequence, certain inputs especially maintenance of various products can be done in parallel, if they are independent of each other.
Sequence of main tables for maintenance and key fields are outlined as follows:
| Maintenance Table | Depends On | ||
|---|---|---|---|
| Core Parameter maintenance | |||
| Bank maintenance | |||
| Branch maintenance | |||
| Countries | |||
| Transaction codes | |||
| System dates maintenance | Branch maintenance, Local holiday maintenance | ||
| Accounting periods maintenance | |||
| Status codes maintenance | |||
| Currency definition maintenance | |||
| Currency rate type maintenance | |||
| Currency pair maintenance | Currency definition maintenance | ||
| Local holiday maintenance | Branch maintenance | ||
| Currency holiday maintenance | Currency definition maintenance | ||
| Clearing holiday maintenance | |||
| Currency denom. Maintenance | Currency definition maintenance | ||
| Interbranch (IB) maintenance | Branch maintenance, IB GLs maintenance | ||
| Reporting lines | |||
| GL. | Reporting lines | ||
| Account class maintenance | |||
| Customer category maintenance | |||
| Customer (CIF) maintenance | Branch maintenance, Customer category | ||
| Customer accounts maintenance | Customer (CIF) maintenance, Currency, ACCLASS |
This section contains the following topics
Apart from maintaining bank and branch parameters, you will also have to maintain a set of core (miscellaneous) parameters that govern processing in Oracle FLEXCUBE. The following table describes the contents of the Oracle FLEXCUBE back-end table CSTB_PARAM that contains all such miscellaneous parameters. Even though the contents of this table have been described in some detail, it is actually not intended for the users of the bank to alter / add / remove. Based on the processing requirements of the Bank, the data in this table will have to be configured by the Oracle Financial Services implementation team during the implementation process.
| Parameter Name | Description | Typical Values & Examples | ||||
|---|---|---|---|---|---|---|
| Operating System related parameters | ||||||
| OPERATING_SYSTEM | The OS on which the Database is installed | UNIX / WINNT | ||||
| WORK_AREA | The path on the server where server debug output / any other handoff file of Oracle FLEXCUBE is written | Valid Directory | ||||
| DIRECTORY_SEPARATOR | The character that denotes directory separation | / | ||||
| ESC_SEQ | Specifies the escape sequence for printing | (s8S | ||||
| SPOOL_OS | Used to indicate the Operating System and based on the operating system path convention, the report spool path and path for moving and purging the spooled files | WINNT | ||||
| TRACE_AREA | Parameter for specifying the trace file path if invalid file handling occurs in debug file generation | /tmp | ||||
| S390 | Used for indicating whether it is ASCII or EBCDIC installation. 'FALSE' implies ASCII installation. | TRUE / FALSE | ||||
| X9$ | The code denoting the specific bank at which Oracle FLEXCUBE is being implemented; the typical convention is that the first three characters represent the currency and the next 4 characters represent the bank. | INRCITI | ||||
| ORG_NODE | Indicates the current host name | Alpsi.world | ||||
| Display Control parameters | ||||||
| SHOW_ALL_FT | If this parameter is set to Y, all the FTs are shown in the FT contract online form; else if it is set to N then only the FTs having Booking date as today are shown. | Y/ N | ||||
| SHOW_ALL_FX | Same as above, but for FX online screen | Y/ N | ||||
| SHOW_ALL_LD | Same as above, but for LD online screen | Y/ N | ||||
| SHOW_ALL_MM | Same as above, but for MM online screen | Y/ N | ||||
| SHOW_ALL_BC | Same as above, but for BC online screen | Y/ N | ||||
| SHOW_ALL_LC | Same as above, but for LC online screen | Y/ N | ||||
| SHOW_ALL_SI | Same as above, but for SI online screen | Y/ N | ||||
| LOV_CUSTNAME | If this parameter is set to Y, the customer names is also displayed along with the CIF id in the customer option-list | Y/N | ||||
| LC_SINGLE_FFT | If this flag is set to Y, the advice tag OTHER-FFTS will get populated. Else, each individual FFT defined will be available for message format definition and the consolidated tag will not get populated | Y/N | ||||
| Accounting related parameters | ||||||
| ACCOUNT_STATEMENT | Whether the account statement that is sent to customers periodically should be booking dated or value dated | BOOK_DATED; VALUE_DATED | ||||
| IC_NADJ_PADJ_TAGS_REQD | Whether Amount Tags indicating Positive and Negative Adjustment (in case of IC adjustment arising out of Back Valued transactions) is required. If this flag is set to Y and suitable accounting is set-up, Positive / Negatives IC adjustment will be passed with absolute amounts with appropriate sign (Dr / Cr) rather than passing negative values in accounting. | Y/N | ||||
| VDBAL_UPDATE | Whether Value-dated balances should get updated online | ONLINE; OFFLINE | ||||
| CCY_DATE_WISE_CHECK | If this parameter is Y, then the End of Day process (while marking EOTI) will check if the accounting entries are balanced currency-wise and value-date wise. If the check fails, a configurable override will be shown. | Y/N | ||||
| IC_ACCR_ON_HOLIDAYS | If this parameter is set, IC (daily accruals) will pass one entry each for each day even when EOD is run before a set of holidays (such as on Friday). Else IC passes one entry for the entire holiday period. | Y / N | ||||
| GL / MIS related parameters | ||||||
| GL_REBUILD | To enable automatic EOD rebuild of GL balances | Y/N | ||||
| GL_PERIOD_CHECK | To indicate whether GL (real and contingent) balance check should be done for all periods or current period | ALL; CURRENT | ||||
| MIS_REBUILD | To enable automatic EOD MIS rebuild | Y/N | ||||
| REFINANCE_DAILY | This flag must be set to Y if MIS daily refinance functionality is required. From Version Oracle FLEXCUBE 4.4 onwards, this flag is available in Bank Parameters. | Y/N | ||||
| Kondor Plus Interface related | ||||||
| KONDOR+ | Whether Kondor Plus interface is available at this installation | Y/N | ||||
| KPLUS_BRCODE | Branch code of the branch where Kondor Plus interface is installed | Valid Branch Code | ||||
| KPLUS_USERID | Oracle FLEXCUBE User ID of the User doing Kondor Plus Upload | Valid User ID | ||||
| KPLUS_FILE_PATH | Main Directory Path where all the Kondor Plus related files/ directories are located | Valid directory path | ||||
| KPLUS_IN_DIR | Directory on Oracle FLEXCUBE server to which files from Kondor will be copied | Sub-directory of the KPLUS_FILE_PATH | ||||
| KPLUS_WIP_DIR | File from Kondor will be moved to this directory from where interface will read the file and populate upload tables | Sub-directory of the KPLUS_FILE_PATH | ||||
| KPLUS_SUCCESS_DIR | File from Kondor will be moved to this directory if the upload writing was successful | Sub-directory of the KPLUS_FILE_PATH | ||||
| KPLUS_ERROR_DIR | File from Kondor will be moved to this directory if the upload writing was unsuccessful | Sub-directory of the KPLUS_FILE_PATH | ||||
| KPLUS_DIR_FILE | Name of the file which will be written by Oracle FLEXCUBE into each the above mentioned paths | *.TXT | ||||
| BROKER_BOOKING_METHOD | This specifies whether the default brokerage booking method is in Advance / Arrears where K + interface is installed | 1/2 | ||||
| BROKER_PAYABLE_CCY | This specifies the default brokerage payable Currency where K + interface is installed | Valid Currency | ||||
| BROKER_LIQ_TXN_CODE | This is the transaction code that the system should use to liquidate the brokerage booked through K + interface | Valid transaction code | ||||
| CUSTOMER_LIMIT_CCY | Specifies the Limit Currency in CIF upload through Kondor Plus | Valid Currency | ||||
| Other Interface related parameters | ||||||
| ELIXIR_IN_DIR | This is the directory in which the ELIXIR (clearing interface) file will have to put in for Oracle FLEXCUBE to read | Valid Directory path | ||||
| MUREX_UPLD_DIR | ||||||
| MUREX_TXN_CODE | Used to get default txn code for DE upload in MUREX interface | Valid Oracle FLEXCUBE txn code | ||||
| KIR_TXN_CODE | Used for indicating transaction code for DE Uploads in pc832.fnc (applicable only when KIR interface is installed). | |||||
| KIR_UPLOAD_DIR | This is the directory in which the KIR data file will have to put in for Oracle FLEXCUBE to read (when KIR interface is installed) | Valid Directory path | ||||
| EMSNT | Whether EMS NT (for messages) is installed | Y/ N | ||||
| ATM_INSTALLED | Indicates whether ATM interface is existing | Y/N | ||||
| ATM_DELAY | ATM EOD processes will start after the time delay specified in this parameter | |||||
| MAINT_NETT_REQD | This pertains to RBAN changes. The parameter is used for indicating if unnetted entries are to be inserted into actb_transaction_listing (used in acpks.sql) before accounting netting takes place. | Y / N | ||||
| RBAN_PATH | Used in achandof.fnc for specifying the path for generation of Transaction Handoff files. | Valid Directory Path | ||||
| SSN checking related parameters | ||||||
| SSN_FT_CHK_REQD | This parameter must be set to Yes for SSN based (anti money laundering) checking to be active. This will validate the total amount (SSN_AMOUNT) of FT transactions (outgoing FTs) that can be input for a given Customer (identified by his Social Security Number) within a running period of days (specified as SSN_DAYS) in a specified CCY (SSN_CCY) | Y/N | ||||
| SSN_AMOUNT | Refer above | Valid Amount | ||||
| SSN_DAYS | Refer above | Valid Number (of days) | ||||
| SSN_CCY | Refer above | Valid Currency | ||||
| Regulation CC related parameters | ||||||
| REGCC_AMT1 | This is the amount of Day 1 availability for Regulation CC | Valid Amount | ||||
| REGCC_AMT2 | Additional availability under Regulation CC | Valid Amount | ||||
| REGCC_CCY | Currency of the above amounts | Valid Currency | ||||
| Signon related parameters | ||||||
| COPYRIGHT_VERSION | The year of the Copyright clause to be displayed on the Signon Screen | Eg: 2001, 2002 | ||||
| RELEASE | The version of Oracle FLEXCUBE to be displayed on the SIGNON screen | Eg: 4.5; 5.0 | ||||
| Other parameters | ||||||
| CUST_ACC_UDF | This parameter is applicable if the customer account mask in the bank should contain a User defined field. | This field should have the name of the UDF that is part of the customer account mask | UD#CUST | |||
| AUTO_PRINT | This parameter should indicate whether the advices generated during the batch processing should be printed automatically or not | Y/N | ||||
| DERIVED_TAG | Used to indicate whether derived tags functionality is used or not | Y/N | ||||
| MAINT_HIST_REQD | Used for indicating if maintenance log history is required | Y/N | ||||
| LC_LIAB_AMT_ACTUAL | This Parameter is used to indicate if Liability tolerance(maintained at product level) is to be considered for LC amount validation or not. Used in BC Contract Online for defaulting LC Liability amount to LC amount in Bills. If set to 'Y', tolerance is not considered for defaulting . | Y/N | ||||
| SGEN_PARAM | This flag should be set to Y if SGEN feature is required for FTs | Y/N | ||||
| TRANSACTION_LIMIT | If this parameter is set, then the transaction level amount limits checking feature will be turned on | Y/N |
Specify the following details.
Initial skeletal information relating to Bank and branch, such as Bank Code, Name etc. will have to be uploaded. Next, the Customer account Mask and GL mask as decided during the database design discussions should be entered. Preferences such as inter-branch accounting scheme, rate copy option, and GL on-line update option can be entered.
Following fields are to be entered at a later stage after setting- up currencies, Chart of a/c, Transaction codes etc.
As in the case of Bank Parameters, skeletal Branch Information such as branch name address etc. will also have to be uploaded.
Following other inputs such as have to be captured after Chart of Accounts, Customer Maintenance is completed:
Login as MAIN with password as PASSWORD and create roles, users and assign functions.
Country Maintenance
Currency Definition
The following tables relating to currencies can be maintained later:
Some of the key inputs are:
Local Holidays
To start with, local holidays, particularly for the current year may be maintained. Holiday table for other years may be maintained later, prior to product maintenance.
Other holiday tables, Currency holidays and Clearing holidays can be maintained later.
The empty database will be on a specific date, which has to be updated to a current date, the next working date has to be suitably updated.
Specify the following details.
Customer Category
Customer categories as decided during the database design phase have to be input.
Customers
Customer information can be uploaded at this stage using the agreed upload strategy. Prior to uploading customers, appropriate translations of existing codes with new CIF numbers, categorizing customer s etc. should be in place. If MIS categorization of customers is also uploaded simultaneously, then MIS categories have to be maintained first. Otherwise, a methodology for updating the customer information with MIS categories later on will have to be worked out. It may be noted that CIF is at the bank level, common across the branches.
General Ledger
Creation of Chart of Accounts in the database is one of the most critical activities in database input, therefore has to be handled with extra care. It is advisable to automatically upload the chart of account from a spreadsheet to avoid input errors. It is better to keep separate spreadsheets for node GLs and leaf GLs, so that they can be uploaded separately.
Reporting Lines
GL Reporting Lines for both head office and central bank reporting have to be first input before creating the Chart of Account in the database. Here again the possibility of data upload from a spreadsheet can be explored.
Chart of Account
The node GLs have to be input before input of leaf GLs. Period/Year end P&L GLs, to which the account balance will be transferred, have to be input and authorized before creating the INCOME & EXPENSE GLs.
The bank/branch level parameter tables have to be revisited to update suspense GLs, year-end P&L GLs, Walk-in customer CIF etc.
Transaction Codes
Transaction codes for various accounting transactions to be passed in the system. Funds availability for the transactions to be input.
Override Parameters
All the errors will be a part of the database. However, most err Categorizing errors under overrides, errors, ignore, on-line authorization options.
Messaging
Allowed operations for message handling
Inter-Branch Maintenance
Identifying due to, due from GLs for inter branch postings. Inter branch accounting route to be decided. Accordingly, the maintenance has to be maintained.
Product Groups
Broad grouping of products offered by bank
Status Code
Product status codes to be maintained.
Bank Codes
Bank codes, Bank name - Clearing House members have to be created here.
Till/Vault
Till or Vault id codes for cash / teller transactions.
Journal Entry, MM/LD, BC Parameters
Product related parameters at Bank level
Reval Set-Up
Revaluation profit/ loss accounts, rate types applicable for revaluation etc. in respect of accounts to be revalued
Limits Template
Defining credit lines and sublines
Security & Issuer
Details of security, Issuer of security
Type
Defining collateral types
Other maintenance such as limits (customer level); Collateral, margins etc. can be set up later after product set-up is completed.
Specify the following details.
Account Class
Broad account categories with user-defined identifier are maintained here. Nature of accounts falling under the class (Current, Savings, Nostro etc.), GL account linkage, Reporting lines, Statement and other generic preferences, Branch, Currency and customer restrictions are specified.
Customer Accounts Maintenance
Opening of customer accounts (current, savings, nostro etc.). Here again, possibility of auto upload/creation of accounts using a spreadsheet could be explored. While creating the upload spread sheet, or creating the accounts manually, utmost care is to be taken in allocating account class, account number and other account level specific preferences. A master list containing the map or translations of old account number with new numbers should be kept aside duly approved, for future reference.
Interest & Charges
Interest and charges applicable to various customer accounts and account classes - Calculation method, formula and other parameters will be based on the database design worked out earlier as per the requirement of the bank.
End of Cycles
The processes to be run as per design are to be set up for each of the branches.
This is one of the major milestone activities in database input.
On a broad level, product set-up follows the following steps:
Note
For more specific product level set- up, you can refer to the respective User Manuals.
It would be more convenient to first identify and create generic rules for ICCF, Tax etc. which could be applied across the products or modules.