Savings is the web-enabled front end of Oracle FLEXCUBE, and is used for handling the Retail Teller transactions. It is fully browser based and facilitates the processing of several types of transactions, like cash transactions, cheque transactions, remittance transactions, funds management transactions and so on.
A typical Savings transaction may be classified into the following five Workflow stages:
The Workflow engine which forms the core of Savings, determines the flow of the transaction from one stage to the other.
For more details on the Workflow engine, refer the ‘Transaction Workflow’ chapter of this User Manual.
This section contains the following topics:
You can define the User Roles, applicable in Savings, in the host. Each role may be associated with a set of functions that are allowed for the role. For example, roles of the following type may be created and associated to appropriate transactions:
Typically, a department within a branch will have only one system administrator and a single vault but can have any number of supervisors and tellers. However, you can add additional roles depending on the bank’s requirement.
Some of the salient features of the module are discussed below:
Host based ‘Push’ Replication is used to reproduce the critical data (maintenances/customer data) from host to branch at regular intervals. These maintenances are pushed to the branch automatically. The time interval between each replication cycle can be configured as per the bank’s requirement. Host will ensure that only necessary and critical information is made available locally in the branch.
For more details on replicating data from the host, refer ‘Data Replication’ chapter of this User Manual.
When branch places a request on the host, as part of the response mechanism, the system can dynamically determine whether the branch is online with the host.
You can manually reverse only authorized and completed transactions. A transaction may be a normal completed transaction or a tanked transaction, which is believed to be complete in all respect.
When you reverse a transaction, the data is not removed from the system. The contract will remain in the system with the contract status as ‘Reversed’ and the accounting entries will be reversed (negative amounts will be posted into the accounts). Also, this will update the Till balance for the currencies (for cash transactions), wherever applicable.
You can pick up the transaction to be reversed from the transaction screen. If reversal is applicable (i.e. you have defined a reversal workflow stage for the transaction), save icon will be enabled. When you click on this button, the reversal request will be sent as a fresh request.
You have the provision to delete incomplete transactions at any stage prior to its completion. This is typically done as part of the End of Day activities.
The ‘Workflow’ section in the Application Browser will display the count of Incomplete Transactions. You can fetch any of these transactions for clearing. Once you mark a transaction for deletion, the system will not display the transaction in the Complete/Incomplete/Pending transactions list.
Auto-Reversals are applicable for transactions which have been configured as ‘One Stage’ transactions. If, during submission to host, the request (or the response) times out, then the transaction is updated as ‘Marked for Reversal’. The untanking job will pick up such transactions and do the needful.
However, for ‘Two Stage’ transactions, timeouts will be based on the stage of the transaction. If the first stage request encounters a time out, the transaction will be updated as ‘Marked for Delete’. But, if the first stage request goes through successfully, as a result of which the transaction is saved in the host (but is unauthorized), the subsequent second stage request time out will update the status as ‘Marked for Roll Forward’. This implies that the transaction is complete is all respect and will be forced posted in host. But, in case of a timeout, if the subsequent branch follow through updates (e.g. Till updates, Transaction Status updates etc), if any, fails, the transaction status will be updated as ‘Marked for Reversal’ and not as ‘Marked for Roll Forward’.
In both the above cases, the untanking process will pick up the transactions and do the needful.
The following section explains the process in branch and host:
In Branch
When the connection between branch and host is lost, the transactions will be tanked in the branch. Subsequently, when the connection is re-established, the system will untank the tanked transactions from the branch to host. The transactions will be saved in the transaction log master in the same stage at which the connection between the branch and host is lost i.e. the stage at which the transaction failed to take place in the host.
The following transaction will be tanked:
In the branch, all the transactions which failed to reach the host are tanked. The tanked transactions are marked with status ‘T’. The untanking process will fetch the count of pending transactions in the branch and then upload the tanked transactions to the host when online. During the upload, the transactions in the branch remain locked. This is to prevent other parallel processes from picking up the same records. After successful upload, the status of the transactions is updated to ‘P’ in the branch which indicates that the transactions have been processed. The system, then unlocks the transactions which were locked in the branch.
In Host
The host will process the tanked transactions sent from the branch. The host will receive the untanking requests from the branch in the form of XML via an interface. These requests will be stored in a table. A background job will process the untanked transactions by first parsing the XML requests received by the host. Each transaction is identified by a unique external transaction reference number. On successful parsing, the job will forward it to the relevant interface for further processing. If there are any errors, the host is updated with the status and error details. If the transaction is successfully completed, the transaction status in the host will be marked as ‘S’.
Transaction reconciliation with host
During the EOD activities in the branch, the transactions processed in the branch have to be reconciled against their corresponding entries in the host. Each teller of the branch will perform this activity as part of the respective Till balancing and closure. The following checks will be done as part of the transaction reconciliation in branch:
These mechanisms will minimize the reconciliation efforts required as a result of any branch-host inconsistencies either at the Cash Till/GL level or at the Transaction Amount or Count levels.
Further, based on the results and observations of these reports/queries, you can initiate adjustment processes, as required, for Audit and Control measures.