The Data Entry module is a sub system of Oracle FLEXCUBE. This module is designed, primarily, for the use of the tellers in your bank.
Typically, the different operations that a teller performs in the course of the day are the:
For the sake of convenience, these operations are classified in the Data Entry module of Oracle FLEXCUBE as:
The sale and purchase of traveler’s checks, foreign currency transactions, check transactions, and cash deposits and withdrawals, are examples of teller transactions. These are transactions that are typically processed across the teller counter.
When a transaction involves one debit entry and multiple credit entries, or vice versa, it is referred to as a multi offset entry transaction. Examples of such transactions could be the posting of entries for clearing transactions: where you credit your customers’ accounts for incoming checks and debit the clearing account.
Classifying teller operations in such a manner helps your teller easily access the appropriate input screen required to perform an operation. Each screen, in turn, is streamlined to capture only the data peculiar to the operation. For example, if a teller has to debit an account and credit several other accounts (for salary purposes) she can access the multi-offset transaction input screen and enter only the required data. Similarly, for a cash withdrawal transaction, the appropriate screen is easily accessed and only data specific to the transaction captured.
This chapter contains the following sections:
Batches help you organize information (and therefore, simplify teller operations).
In a manual accounting system, you may maintain the details of transactions in a register. For easy retrieval, you may write down all transactions belonging to one type on a page. For example, you may write details of all Teller transactions on one page, loan transactions on another page, and so on.
In Oracle FLEXCUBE, this is achieved by grouping transactions as ‘batches’. Each ‘batch’ corresponds to a ‘page’ in the register. The accounting entries that are generated by transactions of a particular type are grouped under a batch. For example, a teller could choose to post the multi-offset transactions entered during the day into a batch, all cash withdrawals into another, and so on. This facilitates quick retrieval of information and easy balancing of books.
Grouping transactions into batches also helps you to authorize transactions in batches. In Oracle FLEXCUBE all operations performed by a user should be authorized by another user with the requisite rights. At the end of day, you do not have to authorize transactions individually. If you print the transaction journal for the batch, you can authorize transactions in batches.
The Data Entry module of Oracle FLEXCUBE is designed not only to simplify, but also to ensure the accuracy of the operations that a teller performs. There are a host of cross checking mechanisms that you can opt to ensure the accuracy of the financial details that the teller enters into. For instance, you can:
This section contains the following topics:
When a transaction involves a currency conversion the rates defined for the Rate Type, specified for the product, will be picked up by default (examples for Rate Type could be TC buy rate, cash rate, etc.). This default can be changed. You can impose some restrictions on this changed rate, as follows:
Normal Variance
If the exchange rate variance exceeds the exchange rate for the Rate Type by this value (normal variance), the system will ask the teller for an override before proceeding to apply the exchange rate. This override will be recorded and retrieved along with the transaction. Further, the transaction has to be authorised by another user with the requisite rights before it is stored.
Maximum Variance
A teller cannot apply an exchange rate (on a transaction involving the product) that is greater than the value that you specify as the Maximum Variance. If the teller specifies an exchange rate that exceeds the standard rate by the maximum variance you have defined for the product, the system will not store the transaction.
You can opt to enforce the verification of a customer’s signature for transactions that exceed a limit that you specify. The system will enforce verification of the customer’s signature if the transaction amount exceeds the limit that you specify.
All operations on a transaction (input, modification, etc.) have to be authorized:
To ensure that an authorizer is calling the correct transaction, you can specify that certain transaction details should be entered before the other details are displayed. For example, you can specify that you would like the authorizer of a transaction to rekey values such as the transaction amount, the transaction currency, the transaction account, and so on. The complete details of the transaction will be displayed only after the authorizer enters these values. This is called the re-key option. The fields for which the values have to be given are called the re-key fields.
The details of a transaction will not be displayed for authorization (even if the authorizer of the transaction enters them correctly) if the teller had captured erroneous values while entering the transaction. A transaction will be displayed for authorization only if the values entered by the teller and the authorizer are identical.
If no re-key fields have been defined, the details of the transaction will be displayed when the authorizer calls the transaction for authorization.
You can define the transaction amount limits for the teller products that you create. A teller cannot enter into a transaction that exceeds the limit defined for the product, which it involves. By defining transaction and authorization limits for tellers and supervisors, you can control the teller transactions that are entered and authorized in your branch.
You can define whether an online authorization is required when an account gets into overdraft. When a teller inputs a transaction and the account goes into an overdraft, the teller should have the transaction authorized by a supervisor. The transaction cannot be saved without an authorization from the supervisor. A transaction that results in an overdraft should be authorized by a third person subsequently. In effect, such a transaction will have to be authorized twice as against the mandatory authorization required for normal transactions.
The following are some of the other salient features of the Data Entry module:
This section contains the following topics:
You can maintain the format of account statements to suit your requirements. You can generate the account statement at regular intervals or when required. The account statements that you provide your customer will contain details of all the transactions involving the account. You can choose to view an account statement (without actually printing it) to provide your customer with transaction details for an account.
You can opt to track the denominations involved in cash transactions. If you choose to enforce denomination tracking, tellers also have to specify the denominations involved at the time of entering cash transactions and transferring cash between tills and vaults.
During the day, or at the end of the day, you may want to retrieve information on any of the several operations that were performed during the day in your bank. This information may be generated in the form of reports.
A report is information retrieved mostly in a printed format. However, you can direct a report to one of the following destinations:
The reports that you have spooled can be printed, or viewed, through the ‘Reports Browser’ screen.
The following are the reports specific to teller operations that you can generate.