14. Branch Deployment Options
14.1 Introduction
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:
- Section 14.2, "Deployment Options"
- Section 14.3, "Processing Transactions in Offline Mode"
- Section 14.4, "Tanking and Untanking"
- Section 14.5, "Auto-Reversal Process"
- Section 14.6, "Offline Batch Process Flow"
14.2 Deployment Options
This section contains the following topics:
14.2.1 Centralized Deployment
In a centralized deployment:
- Branch and Host DB objects are present in the same Oracle DB Schema.
- Requires network connectivity between the remote branches and datacenter at all times
- Faster transaction times.
- No offline support.
Features
The features of this deployment are as follows:
- Availability of network connectivity at all times.
- Teller transactions always directed to Data Center server.
- No Offline transaction capability for Teller transactions.
- Good connectivity between Data center and Branches to ensure continuity of business and performance.
14.2.2 De-centralized Deployment
In a de-centralized deployment:
- Branch Server and Branch DB are present in a different datacenter from the datacenter hosting the FLECUBE DB.
- Branch and Host schemas will be present in different Oracle DB Instances.
- Doesn’t require network connectivity at all times.
- DC Branch Till & Transaction specific data will be available on the Branch DB.
- Transactions will be tanked in Offline mode. Untanking process is triggered once the network connectivity is restored.
- The same Branch DB can host multiple branches.
In decentralized deployment, branch transactions can be entered in two modes, viz. online and offline.
14.2.2.1 Online Mode
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:
- Teller transactions are uploaded into FLEXCUBE DB present in Data Center.
- Teller transactions are routed to the FLEXCUBE DB in Data Center through Branch server
- Full functionality of teller transactions are supported
- Replication of latest data from FLEXCUBE DB to Branch DB at pre-set intervals.
14.2.2.2 Offline Mode
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:
- Network Connectivity between Remote Branch and Data Center is not available.
- Teller transactions are not uploaded into FLEXCUBE DB present in Data Center real time.
- Teller transactions are tanked in Branch Database present in the Remote Branch.
- Transactions are synchronized with FLEXCUBE Host once the connectivity is restored.
- Certain functionality like MIS/UDF/Rate pick up/Available Balance checks is not available in Offline mode.
- No replication of data from FLEXCUBE DB to Branch DB in Offline mode.
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.
14.3 Processing Transactions in Offline Mode
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 |
14.4 Tanking and Untanking
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.
14.5 Auto-Reversal Process
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.
14.6 Offline Batch Process Flow
The process flow for offline branches is as follows:
- When operations start in the morning, branch is connected and network is up.
- Transaction processing will continue as normal.
- Network is disrupted during middle of day and not restored back till end of day.
- Branch will automatically switch to offline mode.
- Branch will able to post only offline transactions.
- Before running EODM, branch should download the transactions as suggested earlier.
- Offline branch should ensure to send the file to online branch.
- After transactions have been downloaded by the branch, branch should run EODM and check for the dates.
14.6.1 Process Flow for Online Branch which uploads Offline Transactions
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.