Oracle FLEXCUBE Branch module can be setup in three different ways.
Centralized Setup
In case of Centralized setup the Branch server, Branch object and Host object will be present in the same machine or located in the same Datacenter. Also in case of a Centralized setup, the Branch and Host DB objects need to be present necessarily in the same Oracle schema and instance. This removes a complete network hop, thereby reducing transaction time – and also eliminates the possibility of Branch going Offline with respect to the Host Server.
De-Centralized Setup
In case of a Decentralized setup, the Branch Server and Branch DB are present in a different datacenter from the datacenter hosting the Host DB. In a Decentralized setup, all calls to Host DB will happen through a HTTP call via the WAN. Since messages are sent over WAN, a Decentralized setup might be relatively slow. In case the network connection between the Branch and the Host Data center fails, the Branch will be forced to work in an Offline mode.
Hybrid Setup
This setup is a combination of Centralized & De-Centralized Branches. Out of 10 Branches say 7 are centralized and 3 are de-centralized.
This chapter contains the following sections:
This section contains the following topics:
In a centralized deployment:
Features
The features of this deployment are as follows:
In a de-centralized deployment:
In decentralized deployment, branch transactions can be entered in two modes, viz. online and offline.
If the branch is online, you can see the online status when you mouse over ‘Branch’ on the application toolbar.
The features of this deployment are as follows:
If the branch is online, you can see the online status when you mouse over ‘Branch’ on the application toolbar.
The features of this deployment are as follows:
Notification and Administration
The Change Branch functionality of FLEXCUBE will be disabled in offline mode. Which also acts as an indicator if the Branch is online or offline.
All transaction input in Offline mode will be tanked. Untanking happens once the link is restored.
In case, Branch switches from Offline to Online or vice versa after a transaction has been initiated then they have to be discarded and re-input again.
Offline Exposure Control
Exposure controlled by specifying the Offline Limit at Customer Account level.
Error will be displayed during save of a transaction in Offline mode, in case the sum of all Offline Debit transactions including the current transaction exceeds the Offline Limit.
When network is down in the decentralized branch, branch will be able to post transactions in offline mode with limited functionality.
The banks exposure in an Offline scenario will be controlled by the Offline limits set for a Customer Account in FCC.
Any transaction being executed Offline will validate against the Account’s Offline limit (as and where applicable) and on exceeding the same, will result in an Error. This validation will be for the sum of Transaction amounts for all Offline Debit transactions for that Account (including the current Transaction) against the Offline limit for the Account.
As Transactions are not going to Host, charges should be picked up locally. Following table is replicated for this purpose - fbtb_arc_maint. From this table various charges are picked up based on product code, currency code, Branch code, transaction type and account class group. Charge amount is shown only if the Charge Type is FLAT and Slab/Tire Type is none. In any other case teller is supposed to enter the charge amount.
Functionality like MIS/UDF/Rate pick up/Available Balance checks is not available in Offline mode.
Validations that are available for Customer Account accounts are dormant, frozen, no credits, no debits and cheque number for cheque transactions.
Oracle FLEXCUBE supports the following branch transactions in offline mode.
Sl No |
Function id |
Module |
Offline |
Description |
1 |
9001 |
Maintenance |
Y |
Open Teller Batch / Till |
2 |
9007 |
Maintenance |
Y |
Transfer Cash from Vault |
3 |
9008 |
Maintenance |
Y |
Transfer Cash to Vault |
4 |
9011 |
Maintenance |
Y |
Buy TCs from Agent |
5 |
9012 |
Maintenance |
Y |
Teller Platform Status Query Screen |
6 |
9015 |
Maintenance |
Y |
Buy TCs From HO |
7 |
9016 |
Maintenance |
Y |
Sell TC to HO |
8 |
9017 |
Maintenance |
Y |
Buy TCs from Vault |
9 |
9018 |
Maintenance |
Y |
Return TCs to Vault |
10 |
9020 |
Maintenance |
Y |
Display TCs available with Vault |
11 |
BCFT |
RT |
Y |
Transfer Cash from Teller |
12 |
DENM |
Maintenance |
Y |
Denomination Exchange |
13 |
EODM |
Maintenance |
Y |
EOD Maintenance |
14 |
OFDL |
Maintenance |
Y |
File download |
15 |
REAN |
Maintenance |
Y |
Reassign Transactions |
16 |
TVCL |
Maintenance |
Y |
Till Balancing and Closure |
17 |
TVQR |
Maintenance |
Y |
Till Vault Position Query |
18 |
1001 |
RT |
Y |
Cash Withdrawal |
19 |
1005 |
RT |
Y |
Miscellaneous GL Transfer |
20 |
1006 |
RT |
Y |
Funds Transfer Request |
21 |
1008 |
RT |
Y |
Miscellaneous Customer Debit |
22 |
1013 |
RT |
Y |
Cheque Withdrawal |
23 |
1060 |
RT |
Y |
Miscellaneous GL Debit |
24 |
1401 |
RT |
Y |
Cash Deposit |
25 |
1408 |
RT |
Y |
Miscellaneous Customer Credit |
26 |
1460 |
RT |
Y |
Miscellaneous GL Credit |
27 |
7551 |
RT |
Y |
Book Shortage |
28 |
7552 |
RT |
Y |
Book Overage |
29 |
9009 |
RT |
Y |
Buy Cash From Central Bank |
30 |
9010 |
RT |
Y |
Sell Cash To Central Bank |
31 |
LOCH |
RT |
Y |
In-House cheque Depo |
32 |
1009 |
DD |
Y |
TC Sale (Against Account) |
33 |
1409 |
DD |
Y |
TC Purchase (Against A/C) |
34 |
8003 |
DD |
Y |
TC Purchase (Walk-In) |
35 |
8204 |
DD |
Y |
TC Sale (Walk-In) |
36 |
8205 |
DD |
Y |
TC Sale (Against GL) |
37 |
5521 |
CG |
Y |
Inward Clearing Cheque Data Entry |
38 |
6501 |
CG |
Y |
Cheque Deposit |
39 |
6512 |
CG |
Y |
Consolidated Cheques Data Entry |
40 |
6520 |
CG |
Y |
Cheque Deposit to GL |
41 |
1025 |
UP |
Y |
Bill Payment by Cash |
42 |
1075 |
UP |
Y |
Bill Payment Against Account |
43 |
CLCS |
Maintenance |
Y |
Clear Cache |
Transactions are stored in Branch DB in Offline mode with the status as Tanked
Untanking job will pick up the Tanked transactions and store them in FLEXCUBE DB once the connectivity is restored.
Tanked transactions can also be uploaded to FLEXCUBE DB using the UI
You can download transactions from branch DB in to file is OFDL screen.
Downloaded file will be available under the folder where the path has been given in FBTB_PARAMS for column UNTANK_FILEUPLOAD_PATH.
You can upload file into Oracle FLEXCUBE DB using STDOFUPL screen.
Intra day batch STDOFUPL will force post the transactions in FLEXBRANCH DB.
Whenever branch goes to offline mode, the offline transactions have to be uploaded to host database either manually (file upload) or automatically (untanking job). Following which intra day batch STDOFUPL should be run, then only all transactions will pass accounting entries. Before Running EOD of offline branch, intra day batch (STDOFUPL –Tanked transactions host upload, from BABIDBAT screen) has to be run, to pass the accounting entries correctly.
Transactions that get timed out will be picked up by the untanking job and stored in FLEXCUBE DB.
Batch running in FLEXCUBE DB will pick up the transactions and reverse the same in FLEXCUBE.
The process flow for offline branches is as follows:
The process for uploading offline transactions is as follows:
On receipt of file from offline branch, the online branch should upload the transactions as suggested earlier.
Whenever branch goes to offline mode, the offline transactions have to be uploaded to host database either manually (file upload) or automatically (untanking job). Following which intra day batch STDOFUPL should be run, then only all transactions will pass accounting entries. Before Running EOD of offline branch, intra day batch (STDOFUPL –Tanked transactions host upload, from BABIDBAT screen) has to be run, to pass the accounting entries correctly.