Data Entry User Manual

Data Entry User Manual
Data Entry
Oracle FLEXCUBE Universal Banking
Release 11.5.0.0.0
[July] [2014]
Data Entry
Table of Contents
1.
ABOUT THIS MANUAL................................................................................................................................ 1-1
1.1
INTRODUCTION ........................................................................................................................................... 1-1
1.1.1
Audience ............................................................................................................................................ 1-1
1.1.2
Organization ...................................................................................................................................... 1-1
1.1.3
Related Documents ............................................................................................................................ 1-2
1.1.4
Glossary of Icons ............................................................................................................................... 1-2
2.
AN OVERVIEW OF DATA ENTRY MODULE ......................................................................................... 2-1
2.1
INTRODUCTION ........................................................................................................................................... 2-1
2.1.1
Organizing Transactions into Batches ............................................................................................... 2-1
2.2
CROSS-CHECKING MECHANISMS ................................................................................................................ 2-2
2.2.1
Specifying an Exchange Rate Variance ............................................................................................. 2-2
2.2.2
Enforcing Signature Verification ....................................................................................................... 2-2
2.2.3
Indicating Values to be Rekeyed during Authorization ...................................................................... 2-3
2.2.4
Defining Transaction and Authorization Amount Limits ................................................................... 2-3
2.2.5
Online Authorization for Overdrafts .................................................................................................. 2-3
2.3
OTHER FEATURES ....................................................................................................................................... 2-3
2.3.1
Account Statements ............................................................................................................................ 2-4
2.3.2
Opting to Track Denominations involved in Transactions ................................................................ 2-4
2.4
RETRIEVING INFORMATION ........................................................................................................................ 2-4
3.
MAINTAINING DATA SPECIFIC TO DATA ENTRY MODULE .......................................................... 3-1
3.1
INTRODUCTION ........................................................................................................................................... 3-1
3.1.1
Maintaining Static Data..................................................................................................................... 3-1
3.2
MAINTAINING DATA ENTRY BRANCH CONDITIONS ................................................................................... 3-1
3.2.1
Branch Conditions that can be Defined ............................................................................................. 3-2
3.2.2
Defining Branch Conditions .............................................................................................................. 3-2
3.2.3
Opting for Denomination Tracking ................................................................................................... 3-5
3.2.4
Maintaining Templates for Multi-Offset Transactions ...................................................................... 3-6
3.2.5
Specifying Details for the Offset Leg of Transactions ....................................................................... 3-9
4.
BEGINNING AND END-OF-DAY OPERATIONS ..................................................................................... 4-1
4.1
INTRODUCTION ........................................................................................................................................... 4-1
4.2
BATCH OPERATIONS ................................................................................................................................... 4-1
4.2.1
Purpose of Batch................................................................................................................................ 4-1
4.2.2
Opening Batch ................................................................................................................................... 4-2
4.2.3
Maintaining Error Codes................................................................................................................... 4-3
4.2.4
Reopening batch ................................................................................................................................ 4-4
4.2.5
Deleting batch .................................................................................................................................... 4-5
4.3
END-OF-DAY CASH DISPENSER VALIDATIONS ........................................................................................... 4-5
5.
DATA ENTRY OPERATIONS ...................................................................................................................... 5-1
5.1
INTRODUCTION ........................................................................................................................................... 5-1
5.1.1
Beginning-of-day Teller operations ................................................................................................... 5-1
5.2
SAVING TRANSACTION ............................................................................................................................... 5-1
5.2.1
Transaction Reversal ......................................................................................................................... 5-2
5.2.2
Transaction Delete ............................................................................................................................. 5-3
5.2.3
In case a Wrong Check Total has been Entered ................................................................................ 5-3
5.3
CLOSING BATCH ......................................................................................................................................... 5-3
5.4
OTHER OPERATIONS ON BATCH ................................................................................................................. 5-4
5.4.1
Reopening Batch ................................................................................................................................ 5-4
5.4.2
Deleting Batch ................................................................................................................................... 5-4
5.4.3
Teller Till Balancing .......................................................................................................................... 5-5
5.5
ENTERING JOURNAL TRANSACTIONS .......................................................................................................... 5-6
5.5.1
Saving Transaction ............................................................................................................................ 5-9
5.5.2
Batch Close ...................................................................................................................................... 5-11
5.5.3
Deleting Journal Transaction .......................................................................................................... 5-11
5.6
ENTERING MULTI-OFFSET TRANSACTIONS ............................................................................................... 5-12
5.6.1
Entering a Multi-offset Transaction................................................................................................. 5-12
5.6.2
Entering Details of Main Leg .......................................................................................................... 5-14
5.6.3
Deleting Transaction ....................................................................................................................... 5-17
6.
DATA ENTRY CONTROL OPERATIONS................................................................................................. 6-1
6.1
INTRODUCTION ........................................................................................................................................... 6-1
6.2
BATCH AUTHORIZATION ............................................................................................................................ 6-1
6.2.1
Authorizing Batches ........................................................................................................................... 6-1
6.3
REASSIGNING BATCH ................................................................................................................................. 6-3
6.3.1
Reassigning Batch ............................................................................................................................. 6-3
6.4
PROCESSING JOURNAL BATCH.................................................................................................................... 6-4
6.4.1
Viewing Journal Batches ................................................................................................................... 6-4
6.4.2
Unlocking Journal Batches ................................................................................................................ 6-5
6.4.3
Reserving Journal Batches ................................................................................................................ 6-5
6.4.4
Maintaining Journal Upload Preferences ......................................................................................... 6-7
7.
REPORTS ........................................................................................................................................................ 7-1
7.1
7.2
INTRODUCTION ........................................................................................................................................... 7-1
REPORT ON CURRENCY POSITIONS OF YOUR BRANCH ................................................................................ 7-1
1.
1.1
About this Manual
Introduction
This manual is designed to help you quickly get acquainted with the Data Entry module of Oracle
FLEXCUBE.
It provides an overview to the module, and provides information on using the Data Entry module
of Oracle FLEXCUBE.
Besides this User Manual, you can find answers to specific features and procedures in the Online
Help, which can be invoked, by choosing ‘Help Contents’ from the Help Menu of the software.
You can further obtain information specific to a particular field by placing the cursor on the
relevant field and striking <F1> on the keyboard.
1.1.1 Audience
This manual is intended for the following User/User Roles:
Role
Function
Back office clerk
Input functions for contracts
Back office managers/officers
Authorization functions
Product Managers
Product definition and authorization
End of day operators
Processing during end of day/ beginning of day
Financial Controller / Product Managers
Generation of reports
1.1.2 Organization
This manual is organized into the following chapters:
Chapter 1
About this Manual gives information on the intended audience. It also lists
the various chapters covered in this User Manual.
Chapter 2
An Overview of the Data Entry Module is a snapshot of the features that
the module provides.
Chapter 3
Maintaining Data specific to the Data Entry Module gives information on
basic information that needs to be maintained in the system before
beginning operations in the DE module.
Chapter 4
Beginning and End-of-Day Operations explains the beginning and end of
day operations for the data entry module.
Chapter 5
Data Entry Operations described in this chapter is the procedure to process
all types of Data Entry, Teller type and Multiple Off-set entry transactions.
Also explained is the method of associating a DE product with a DE
contract. The advantage of defining products is highlighted in this chapter.
1-1
Chapter 6
Data Entry Control Operations details the data entry control operations for
the Data Entry module.
Chapter 7
Report provides a list of reports that can be generated in this module and
also explains their contents.
1.1.3 Related Documents

Settlements User Manual

Products User Manual

Charges and Fees User Manual

Tax User Manual

User Defined Fields User Manual
1.1.4 Glossary of Icons
This User Manual may refer to all or some of the following icons:
Icons
Function
Exit
Add row
Delete
row
Option
List
1-2
2.
2.1
An Overview of Data Entry Module
Introduction
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:

Disbursement and receipt of cash

Processing of checks for clearing

Sale and purchase of travelers checks

Transfer of cash between accounts

Passing adjustment entries
For the sake of convenience, these operations are classified in the Data Entry module of Oracle
FLEXCUBE as:

Teller type transactions

Journal entries

Multiple offset entry transactions
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.
2.1.1 Organizing Transactions into Batches
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.
2-1
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.
2.2
Cross-checking Mechanisms
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 example, you can

Define exchange rate variance limits

Specify the limit over which signature verification is required

Specify the values that the authorizer of a transaction has to rekey before the complete
details of a transaction are displayed

Specify transaction (amount) limits

Display online override for overdrafts
2.2.1 Specifying an Exchange Rate Variance
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.
2.2.2 Enforcing Signature Verification
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.
2-2
2.2.3 Indicating Values to be Rekeyed during Authorization
All operations on a transaction (input, modification, etc.,) have to be authorized:

By a user other than the one who carried out the operation

It should be done before you can begin the end-of-day operations
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.
2.2.4 Defining Transaction and Authorization Amount Limits
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.
2.2.5 Online Authorization for Overdrafts
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.
2.3
Other Features
The following are some of the other salient features of the Data Entry module:

You can define the format of the account statements to suit your requirements.

You can opt to track the denominations involved in transactions.

You can retrieve information relating to transactions in the form of reports.
2-3
2.3.1 Account Statements
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.
2.3.2 Opting to Track Denominations involved in Transactions
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.
2.4
Retrieving Information
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 printer

The screen (as a display)

A spool file (stored as a spool file to be printed later)
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.

Batch totals

Currency positions

Till/Vault positions

Teller transactions for the day

Exchange of denominations

Cash transactions for the day

Till liquidation

Till closing report

Till balancing exceptions
2-4
3. Maintaining Data Specific to Data Entry Module
3.1
Introduction
Before you begin operations in the Data Entry module of Oracle FLEXCUBE you must maintain
certain basic information in the system. For example, you must maintain the following:

Branch specific parameters (you can opt to enforce denomination tracking)

Till/Vault/Cash Dispenser details of your branch

Bank codes (for other banks)
This data is maintained first since it is required to create your teller products, enter teller
transactions, and so on. In other words, this is the foundation on which you build the
superstructure ‘Products’ to which, you can link transactions.
3.1.1 Maintaining Static Data
Static data, which is maintained in Oracle FLEXCUBE, can be either common to several modules
or specific to a module. For example, data relating to exchange rates is common to modules like
Foreign Exchange and Money Market. Static Data that is commonly accessed by several
modules is maintained centrally.
Data that is specific to a module is maintained in the module itself. For example, data relating to
Tills, Vaults and Cash Dispensers is specific to the Data Entry module. It is therefore maintained
in the Data Entry module.
You can maintain static data specific to the Data Entry module in three different screens:

Data Entry Branch Conditions screen

Till/Vault/Dispenser Maintenance screen

Clearing Bank Code Maintenance screen
The procedure to invoke and maintain the tables is explained below.
3.2
Maintaining Data Entry Branch Conditions
The mandatory operations and the default parameters that you can define for your branch are
referred to as Branch Conditions.
For example, you can establish operational controls in your branch such as:

Enforce rekey of important values of a transaction at the time of authorization

Set default parameters for your branch such as enforcing the input of currency
denominations for teller transactions

Defining an exchange rate variance (explained below) for your branch which will apply to
journal and multi offset transactions
3-1
The advantages
The ‘Rekey at authorization’ facility is a cross-checking mechanism, which has been provided in
Oracle FLEXCUBE. By rekeying the values of a transaction the authorizer can ensure that a
transaction is error free.
Example
You have debited a sum of $100 USD from a customer account. The account number of the customer is
USDUS100003D. The Value Date of the transaction is 20/12/99.
The authorizer of the above transaction will have to rekey, for example, the Account Number of the
customer; the Amount of the transaction; and the Value Date of the transaction if you have indicated that
these values have to be rekeyed at the time of authorization.
By doing so the authorizer can ensure that the transaction is error free.
3.2.1 Branch Conditions that can be Defined
You can define the following branch conditions in the Data Entry Branch Conditions table:

Rekey at the time of authorization of journal and multi offset transactions

Transaction codes for cash transfers amongst Tills Vaults and Cash Dispensers

Exchange Rate Variance

Local currency equivalent of the Exchange Rate Variance

Denomination input for teller transactions

Use Exchange rate history

Allow Cash Dispenser functionality and define the minimum dispensable amount

Defining the maximum amount to be dispensed during an alarm situation.
3.2.2 Defining Branch Conditions
You can invoke the ‘Journal Entry Branch Parameters Maintenance’ screen by typing
‘DEDBRCON’ in the field at the top right corner of the Application tool bar and clicking the
adjoining arrow button.
3-2
Select ‘New’ from the Actions menu in the Application tool bar or click new icon. You can now
maintain the branch conditions for your branch.
Branch Code
Select the branch for which you are maintaining the parameters.
3.2.2.1 Specifying Journal Entry and Multi Offset Entry
You can specify the values that the authorizer of a transaction has to rekey when authorizing it.
All operations on a transaction (input, modification, etc.,) have to be authorized:

By a user other than the one who carried out the operation

Before you can begin the end-of-day operations
When you invoke a transaction for authorization—as a cross-checking mechanism to ensure that
you are calling the right transaction—you can specify that the values of certain fields should be
entered before the other details are displayed. The complete details of the transaction will be
displayed only after the values to these fields are entered. This is called the ‘re-key’ option. The
fields for which the values have to be given are called the ‘re-key’ fields.
If no re-key fields have been defined, the details of the transaction will be displayed immediately
when the authorizer calls the transaction for authorization. The re-key option also serves as a
means of ensuring the accuracy of inputs.
3-3
You can specify the values of Journal and Multi-offset transactions that the authorizer should
rekey in this screen.
Under Journal Entry (on the top left corner) and Multi-Offset Entry (top right corner), you will find
the following option: Rekey Required Under this option you will see two buttons against ‘Yes’ and
‘No’ respectively.
Click on the button against Yes if you want the authorizer of journal transactions to rekey values.
Similarly, click on the button against Yes if you want the authorizer of multi offset transactions to
rekey important fields.
Click on the button against No, in these fields, if you do not want the authorizer to rekey values at
the time of authorization.
3.2.2.2 Indicating Re-Key and Multi Rekey Fields
Under Journal Entry and Multi Offset Entry respectively, you will see a list of re- key fields. Check
against the fields that you want to be re-keyed at the time of authorizing for Journal and Multi
Offset entries.
The fields that can be re-keyed for journal entries are:

Value Date

Amount

Transaction Code

Account
The fields that can be re-keyed for multi offset entries are:

Value Date

Main Transaction Code

Offset Transaction Code

Amount
3.2.2.3 Specifying Exchange Rate Variance
You can maintain exchange rate variation limits for Journal and Multi offset transactions. When
you input a Journal transaction, the exchange rate (which you maintain at the beginning of day in
the currency table) will be applied. This is referred to as the default exchange rate.
However, for a special customer or in special cases, you may want to use an exchange rate that
is greater than the default exchange rate. In this field, you can specify the maximum and
minimum percentage difference of the special rate from the default rate. In other words, you can
specify the Maximum and Minimum Exchange Rate Variance.
3-4
When you enter a transaction, the system will not seek an override if the Exchange Rate that
you choose to apply is lower than the Minimum Exchange Rate Variance specified in the
Minimum Exchange Rate Variance field. If the Exchange Rate is between the Minimum and the
Maximum Exchange Rate Variance defined, the system will display an override message. The
system will not store a transaction if you apply an Exchange Rate that is more than the Maximum
Exchange Rate Variance defined.
3.2.2.4 Specifying Local Currency Equivalent Variable Limit
Another parameter that you can define for Teller and Journal type transactions, in this screen, is
the LCY Equivalent Variance Limit.
When a teller enters a transaction (Teller/ Journal/ Multi offset) she can change the local currency
equivalent for the transaction (if it is a foreign currency transaction). The input in this field
determines the variance in number of units (note NOT percentage) between the default value and
the value changed.
3.2.2.5 Specifying Use Exchange Rate History
Often you may enter back dated transactions. That is, you may enter a transaction date that is
earlier than your current system date. On such a transaction a teller may want to apply the
exchange rate that prevailed on the transaction date. This rate must be retrieved from history.
By clicking on the box adjacent to ‘Use Exchange Rate History’ you can indicate that you would
like to apply the exchange rate from history on back dated transactions. If you do not choose this
option, the Spot Rate (maintained for the day on which the transaction is entered in the system)
will be used for the transaction.
Example
If the default equivalent of a FCY transaction is 120 units in the LCY and the allowed variance amount that
you have specified is 10 units in the LCY, then the LCY equivalent if changed should be between 110 and
130 units.
3.2.3 Opting for Denomination Tracking
You can opt for tracking denominations for data entry transactions by checking the ‘Denomination
Tracking Required’ checkbox.
3.2.3.1 Specifying Back Value Details
You can post back value dated transactions in Oracle FLEXCUBE. However, for the purpose of
risk tracking, you can specify a limit beyond which users will be prevented from posting a back
value dated transaction in the system.
Check against the option ‘Back Valuation Check Required’ if you want enable back value dated
transactions. You then need to specify the number of days to which a transaction posted by a
user can be back-valued dated in Oracle FLEXCUBE. If a user specifies a date that does not fall
within the back value days limit (measured in calendar days i.e. this period is inclusive of
holidays) maintained here, the system will display the following message:
The value date is earlier than the Permitted value days
3-5

If the message is configured as an ‘error’, you will not be able to proceed with the
transaction, until you specify a date, which is within the limits maintained.

If the message is configured as an ‘override’, you will be able to proceed with entering
the transaction, but an override is logged into the database, that the date specified does
not fall within the limits maintained.

If it is configured as a ‘ignore’ message, then no back-valuation check will be performed.
The same validations are carried out for transactions that are uploaded from external systems.
Note the following:

You will be allowed to specify the ‘Back Value Days’ only if the ‘Back Valuation Check
Required’ option is checked. If the option is not enabled, the system will allow you to post
back-valued transactions upto any date in the past (no check will be done). Further, if the
option is checked but you have not maintained the ‘Back Value Days’ (maintained as
NULL), the system will interpret it to be ‘Zero’ days allowed (for back valued
transactions).

This Functionality will be available for your branch only if the ‘Denomination Tracking
Required’ functionality is not enabled for your branch.
3.2.4 Maintaining Templates for Multi-Offset Transactions
If a transaction involves one debit entry and multiple credit entries (or one credit entry and
multiple debit entries), it may be referred to as a multi-offset entry transaction. In other words, a
multi-offset transaction is one in which multiple accounting entries are passed (to the offset
accounts) to balance a single entry
You can maintain templates that can be used for processing multi-offset transactions. The
attributes of the templates will be defaulted to the transaction thereby minimizing the time and
effort required to process such transactions.
You can invoke the ‘Journal Multi Offset Template Maintenance’ screen by typing ‘DEDTEMPL’ in
the field at the top right corner of the Application tool bar and clicking the adjoining arrow button.
3-6
Specify the following details.
3.2.4.1 Specifying Details for the Main Leg of Transactions
Specify the following details in this ‘MAIN’ tab of the screen:
Template Identification and Description
Specify a unique id to identify the template throughout the system. You can also capture a brief
description of the template being maintained.
Account Number and Description
Select the account number and the description for the template. All the account numbers that are
maintained in the branch are available in the option-list provided. The entry passed to this
account will represent the main leg of the multi-offset transaction.
On selection of the account number, the associated description is displayed in the next field.
Currency
The currency of the account number that you have entered (in case of a customer account) is
displayed here. However, you are allowed to maintain a different currency. All the valid currencies
in the branch are available in the option-list provided. You can select the appropriate currency
from the list.
3-7
Amount
In this field, enter the amount of the transaction. The amount that you enter here will be
considered to be in the currency that you select in the previous field.
You must also indicate whether the amount is to be credited to the account or debited from the
account. To do this, you must select either ‘Dr’ or ‘Cr’, depending on the nature of the entry.
Additional Text
You can capture any additional remarks regarding the template in this field. This is a free format
text and is used only for information purposes.
Debit/Credit Indicator
Debit Credit Indicator defines if the template is being maintained for Debit or Credit. In the Main
Tab you can give an Account, from that account if you mark as Debit, the amount will be debited.
Under the Offset tab those are the accounts which you credit for this debit in main account.
3.2.4.2 Specifying Transaction Code
A transaction code is used to identify the nature of the entries that are passed. You can specify a
transaction code for the main leg of the transaction as well as for the offset entry.
An option-list consisting of all the valid transactions maintained in your branch is provided for
each field (Main and Offset). You can select the appropriate transaction codes from this list.
3-8
3.2.5 Specifying Details for the Offset Leg of Transactions
The details of the offset leg of the transaction are captured in the ‘OFFSET’ tab of the screen:
3.2.5.1 Indicating Offset Entries
For the offset leg of the transaction, you can select multiple accounts that belong to different
branches of your bank. The option list provided for the ‘Account’ field gets populated with the
relevant accounts, depending on the branch code selected.
For each account that is selected, you can specify either the amount or the percentage of the
amount.
If you specify the amount, the percentage is automatically calculated with respect to the amount
that you specify for the main leg of the transaction (in the ‘MAIN’ tab). Similarly, the amount is
automatically calculated if you decide to specify the percentage for each offset account.
The Serial Number is automatically displayed on selection of an offset account from the option-list
provided.
The sum total of all the amounts specified for each offset account must be equal to the
amount of the main leg. So also, the total of the percentages should not exceed 100%.
At the time of processing multi-offset transactions, you can associate a template with the
transaction. The details from the template will get defaulted to the transaction.
3-9
4. Beginning and End-of-Day Operations
4.1
Introduction
Tellers, or the Customer Service Representatives of your branch, can perform three types of input
operations in Oracle FLEXCUBE. They can enter:

Teller type transactions

Journal type transactions

Multiple Offset Entry transactions
Cash transactions and trade in travelers’ checks are typical teller type transactions.
Simple voucher entries, such as interest adjustments, payments made by the bank towards
taxes, internal book entries of the bank etc., are examples of Journal transactions.
If a transaction involves one debit entry and multiple credit entries, or one credit entry and
multiple debit entries, it is referred to as a multi-offset transaction. The following is an example of
a multi-offset transaction.
Example
Cavillieri and Barrett Finance Corporation has an account with your bank. They have instructed you to debit
their account with you, and credit their employees’ salary accounts on the last day of every month. When
you carry out these instructions at the end of the month, you would be entering a multi-offset transaction.
However, before you can commence teller operations you must perform two functions. You must
open a ‘batch’ and a Till. These operations may be referred to as Beginning of Day operations.
4.2
Batch 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 in batches. Each ‘batch’
corresponds to a ‘page’. The accounting entries that are generated by transactions of a particular
type are posted in a batch.
4.2.1 Purpose of Batch
All transactions that have been entered into the system have to be authorized at the end of the
day by a user with the required authorization rights. You can authorize transactions of a particular
type by authorizing the batch into which they have been posted (since all transactions of a
particular type are posted into a batch).
4-1
4.2.2 Opening Batch
You can invoke the ‘Journal Batch Authorization’ screen by typing ‘DEDBTAUT’ in the field at the
top right corner of the Application tool bar and clicking the adjoining arrow button.
If automatic generation of batch numbers has been allowed at your bank in the ‘Bank Wide
Parameters’ screen, the system automatically generates the batch numbers sequentially. The
number of the first batch will be 0000. The series in which the subsequent batch numbers are
generated is as follows:

0000 to 0009

000a to 000z

0010 to 0019

001a to 001z

0020 to 0029

002a to 002z and so on.
When all the batch numbers are used up, system will display a message stating that all the
available batch numbers have been exhausted.
Batch Number
If your bank has not opted for automatic generation of batch numbers, enter a number for the
batch in the Batch Number field. You can enter a number between 1 and 9999. If the Batch
Number that you have specified is not already in use, you can use the batch to post the
transactions that you will enter during the day.
At the description field, you may enter a description for the batch. Every time you reopen, view,
delete or authorize the batch the description will be displayed.
4-2
An entry in the Check Total field is not mandatory. If the total debit and the total credit, generated
by the transactions to be posted in a batch, is known upfront you can enter the values (in LCY) in
the Check Total field. In case the actual debit and credit totals posted to the batch do not match
the entries in this field, you cannot leave the Teller Entry Form. In such a case, check the
transactions that have been entered and correct those that have been erroneously entered or
missed out on.
In case you entered a wrong check total in this field, you can change it in the ‘Batch Summary
screen’. Click on ‘Batch’ in the Teller Entry Form. The ‘Batch Summary’ screen will be displayed.
Entry Total
Enter any value as the debit and credit total.
4.2.3 Maintaining Error Codes
According to the requirements of your bank, you can configure the system to display an error
message if you have not opted for batch balancing at the time of opening a batch.
This is indicated in the ‘Overrides Maintenance’ screen before opening a batch.
You can invoke the ‘Overrides Maintenance’ screen by typing ‘CSDOVDMT’ in the field at the top
right corner of the Application tool bar and clicking the adjoining arrow button.
4-3
According to your instructions in the ‘Overrides Maintenance’ screen, Oracle FLEXCUBE will
either:

Display an error message if balancing is not allowed at the time of opening a batch
(system will allow you to enter the details of the journal entry only if the option 'Balancing’
is checked)

Display an override message reminding that the batch that has been opened will not be
balanced (even if the option ‘Balancing’ is unchecked, system will display an override and
allows you to proceed further and enter the journal entry details)

Ignore your selection for the option 'Balancing'. System will not display an error message
or override irrespective of your selection for the option ‘Balancing’ and you can proceed
to enter the details of the journal entry in the 'Journal Entry' screen.
According to the requirements of your bank, indicate your option (Error, Override, or Ignore) for
the error code DEBATBAL-1.
Depending on your selection in the ‘Overrides Maintenance’ screen for the error code
DEBATBAL-1, system will either display an error message or an override message or will just
ignore your selection for the option ‘Balancing’.
In the ‘Overrides Maintenance’ screen, if you have indicated the ‘Type’ as ‘Error’ and if you don’t
opt for ‘Balancing, system will display an error message –
“The batch is not balanced”
and ‘Balancing’ is automatically checked. In other words, it is mandatory to opt for balancing. This
is to ensure that all batches that are opened to post entries are balanced.
If you have indicated the Type as ‘Override’, system will display an override message if you
haven’t checked the option ‘Balancing’:
“The batch is not balanced. Do you want to proceed? Yes/No”.
You can proceed to enter the details of the journal transaction if you select ‘Yes’.
If you have opted for ‘Ignore’ in the ‘Error Codes Maintenance’ screen, irrespective of whether
you opt for balancing of batches or not, system will allow you enter the details of the journal
transaction in the ‘Journal Entry’ screen (system will not display an error message or an override).
4.2.4 Reopening batch
You can reopen a batch that you opened earlier.
To reopen a batch, select ‘Reopen’ from the Actions menu in the Application tool bar or click
reopen icon. When you reopen a batch, the system ensures that you are the user who originally
opened the batch. You cannot reopen a batch that has been opened by another user — even if it
is not in use. The System Administrator has to reassign the batch to you before you can use it.
4-4
4.2.5 Deleting batch
If you opt to delete a batch, the system checks if the entries that have been passed into the batch
were passed by you. That is, if you were the original user of the batch. If not, you cannot delete
the batch. The system also checks if the batch is in use. If it is, you cannot delete the batch. You
can delete a batch from the Batch Browser. To delete a batch, select ‘Delete’ from the Actions
menu in the Application tool bar or click delete icon.
When you delete a batch all unauthorized transactions in it will be deleted.
4.3
End-of-Day Cash Dispenser Validations
As part of the End of Transaction Input, the dispenser log’s credibility will be checked against the
cash dispenser position and an error will be raised if the two do not match. The cash dispenser
daily log will be archived in the archive table and cleaned as a part of EOD processing.
An EOD batch will post accounting entries for the cash GL’s during online transactions. This
batch will read the journal entries which gets logged online for every transaction and process the
accounting entries for the cash GL’s for the cash dispenser functions like Partial Load, Partial
Unload, Empty Dispenser, Give Change, Notes Counting, Give Alarm, Deposit and Withdrawal
Transactions.
Apart from processing accounting entries, this batch job will update the cash till and dispenser
balances.
4-5
5. Data Entry Operations
5.1
Introduction
Broadly speaking, teller functions would include entering:

Journal type transactions

Multiple Offset Entry transactions
The sale and purchase of travelers checks; foreign currency transactions; and cash deposits and
withdrawals are examples of Teller transactions.
Journal transactions are typically used to post adjustment entries passed to internal accounts.
If a transaction involves one debit entry and multiple credit entries (or one credit entry and
multiple debit entries), it may be referred to as a multi-offset entry transaction. The following is an
example of a multi-offset transaction.
Example
Cavillieri and Barrett Finance Corporation has an account with your bank. They have instructed you to debit
their account with you, and credit their employees’ salary accounts on the last day of every month. When
you carry out these instructions, at the end of the month, you would be entering a multi-offset transaction.
5.1.1 Beginning-of-day Teller operations
Before you start your regular teller operations for the day such as cash deposit, cash withdrawal
etc., you have to perform two preliminary operations. You have to:

Open tills and vaults

Move cash into vaults (through teller transaction input)

Move cash between the vault(s) and tills (through the cash movement function)
These operations are referred to as Beginning-of-day Teller operations. (Please refer the chapter
‘Beginning and End-of-Day operations’ for details).
5.2
Saving Transaction
When you have entered all the details of a transaction you have to save the transaction in the
system
To save a transaction click save icon on the Toolbar or choose ‘Save’ from the Actions menu.
The system will update the transaction as an unauthorized transaction. The user ID of the teller
who entered the transaction and the date and time at which the transaction was saved will be
displayed at the bottom of the screen
5-1
Cross Validations
The system performs the following cross validations when you input a transaction. It ensures that:

you have entered all the mandatory details in the appropriate fields

the product related restrictions are not violated

you have the Cash GL linked to the transaction currency and/or offset currency in case of
cash based products

the exchange rate variance conforms to that defined at the product level
Validations for a transaction
When you save a transaction the following validations will be carried out

Transaction amount is within the Minimum and the Maximum specified in the Branch
conditions Table

Exchange rate conforms to the Variance limit defined

Availability of funds in the specified accounts

Teller limit verification

Override incase the value date is back date or future dated
5.2.1 Transaction Reversal
In special circumstances, you may want to remove a transaction from the system. In Oracle
FLEXCUBE you have the option of either ‘deleting’ the transaction or ‘reversing’ it
When is reversal possible?
Every transaction that is entered in the system must be ratified or, in other words, ‘authorized’ by
another user with the requisite rights. An authorized transaction can only be reversed It cannot be
deleted
In case you want to reverse a cash transaction, which was entered the previous day, the following
validation is performed:

the system ensures that the till used for the reversal is the same as that used in the
original transaction
Reversing a transaction
In the Teller Entry form navigate to the transaction that you want to reverse. Click reverse icon in
the Toolbar or choose Reverse from the Actions menu. The system will seek a confirmation of the
reversal. On confirmation, the system will reverse the accounting entries that were passed for the
transaction.
If cash transactions are reversed the system performs the following validations:

the system ensures that the till used for the reversal is the same as that used in the
original transaction
5-2

the denominations are input (If the transaction is reversed the same day that it is input,
the denominations of the transaction can be altered.)

a batch is open
5.2.2 Transaction Delete
In special circumstances, you may want to remove a transaction from the system. In Oracle
FLEXCUBE you have the option of either ‘deleting’ the transaction or ‘reversing’ it.
When is deletion possible?
If a transaction that you have input has not been authorized, you can delete it. Remember that
only the user who input a transaction can delete it. You have to reverse a transaction that has
been authorized.
Deleting a transaction
When you are in the ‘Teller Transaction Input’ choose ‘Delete’ from the Actions menu or click
delete icon on the Toolbar. The transaction that is displayed in the screen will be deleted. All
accounting entries passed for the transaction will be removed. The Advises specified at the
product level will be suppressed, if they have not already been printed.
Note that the Charges and Tax components for the transaction will also be deleted.
5.2.3 In case a Wrong Check Total has been Entered
In case the actual debit and credit totals that you post to the batch do not match your entry in the
Check Total field (in the Batch Opening screen), you cannot close the teller entry form or close
the batch.
If you are unable to close a batch check the transactions that have been posted to the batch and
correct those that have been erroneously entered or missed out
Changing the Check Total
On occasion, you may not be able to close a batch because you entered an erroneous Check
Total while opening the batch. In such a case, you can correct the check total in the Batch
Summary screen.
To correct the check total, invoke the ‘Batch Summary’ screen from the ‘Teller Transaction Input’
screen. In the Check Total field in this screen you can enter the correct debit and credit check
totals for the batch. The total of the debit and credit entries that you have posted in the batch will
be displayed in the Entry Total field.
You can correct the check total values in the Check Total field and update them in the system.
You may or may not opt to use the changed values. If you opt not to use the original Check Total
values the system will use the original values to tally the actual entries that you post to the batch.
5.3
Closing Batch
5-3
Once you complete operations for the day you can ‘close’ the batch that you opened before
commencing teller operations. You cannot post further transactions to a batch that is closed. You
have to reopen a closed batch to post transactions.
You can close a batch when you:

complete operations for the day

complete operations of a particular type (eg., entering journal transactions) and proceed
to other operations (eg., selling travelers cheques)
Normally, you can close a batch by choosing the close icon in the Toolbar. However, in case of a
General Protection Fault, you can close a batch using the Batch Closure screen.
Please refer to the chapter ‘Beginning and end-of-day operations in this User Manual for further
details.
5.4 Other Operations on Batch
You can perform the following operations on a batch

Reopening a batch

Deleting a batch
5.4.1 Reopening Batch
The following example illustrates the concept of reopening a batch.
Example
Assume Mr. Darcy, who has to meet a customer, closed batch 0001 after posting 100 cash transactions to it.
After meeting the customer, Mr. Darcy wants to continue entering transactions. He can either open a new
batch to post transactions or he can choose to post into batch 0001 which he opened initially. To continue to
post transactions to batch 0001, he has to reopen the closed batch.
How to reopen a batch
When in the Batch Opening screen click on reopen icon on the Toolbar or choose Reopen in the
Actions Menu to reopen a closed batch.
When you attempt to reopen a batch, the system ensures that you are the user who originally
opened the batch. You cannot reopen a batch that was opened by another user. The System
Administrator has to reassign the batch to you, before you can use it. Please note that you cannot
reopen a batch that is in use.
5.4.2 Deleting Batch
If you want to delete all the transactions that you posted to a batch you can opt to delete the
batch.
5-4
When a batch can be deleted?
You can delete a batch under the following conditions

if you are original user of the batch

if all transactions posted to the batch are yet to be authorized

if the batch is not in use currently
Example
You posted ten transactions to a batch. You want to delete all the transactions in the batch at one
stroke.
Open the Batch Browser screen. Navigate to the batch that you want to delete. Choose delete
icon on the Toolbar or choose Delete from the Actions menu. All the transactions posted to the
batch will be deleted
How to delete a batch
Open the ‘Batch Browser’ screen. Navigate to the batch that you want to delete. Choose delete
icon on the Toolbar or choose Delete from the Actions menu. All the transactions posted to the
batch will be deleted
Remember that you can only delete a batch if all the transactions posted to the batch are
unauthorized.
5.4.3 Teller Till Balancing
At the end of the day, when you complete all operations that involve the till, you must balance it. If
you do not balance a till, you cannot proceed with the end-of-day operations. To balance a till is
to ensure that the cash that is left in the till is the right amount. In other words, ‘Till’ balancing
involves checking the physical balance in the Till (actual balance) against the balance in the Till
according to the system.
Refer the chapter ‘Beginning and end-of-day operations’ in this User Manual for further details.
5-5
5.5
Entering Journal Transactions
What is a Journal transaction?
Simple voucher entries, such as interest adjustments, payments made by the bank towards
taxes, internal book entries of the bank etc., can be entered into the system as journal
transactions. In a journal transaction only one accounting entry is passed - either a debit or a
credit.
The difference between a journal and a teller transaction
A journal (type) transaction is different from a teller (type) transaction in that, it generates only
one account entry. The offset entry is not generated as in the case of Teller transactions.
Before you can enter journal transactions for the day you must open a ‘batch’ to post these
transactions.
Now that you have opened a batch, you are ready to input a journal transaction. In the ‘Journal
Entry’ screen, you can enter the following details of the journal transaction that you want to enter.
You can invoke the ‘Journal Single Entry Input’ screen by typing ‘DEDJRONL’ in the field at the
top right corner of the Application tool bar and clicking the adjoining arrow button.
5-6
Specify the following details.
Batch Number
The batch that you have opened to post the journal transaction is displayed at the top of the
‘Journal Entry’ screen.
Fund Identification
Specify the fund id to which the journal entry account will be linked by selecting from the adjoining
option list.
Current Number
Every journal transaction that you enter into the batch is assigned a ‘current number’ by the
system. This helps you identify the journal transactions that you enter for the day.
Account Number
Specify the exact account /GL number for journal entry posting. The journal entry will be posted to
this account or GL.
Account Branch
In the Account Branch field, system defaults to the branch that you have logged in to. You can,
choose the branch to which you want to post the journal entry.
Currency
The system displays the currency of the account number, if it is a customer account. Else, you
have to enter the transaction currency, in this field. Select the currency from the adjoining option
list.
Amount
In this field enter the amount of the transaction. The amount that you enter here must be in the
currency of the account number that you specified.
Now you must indicate if the amount is to be credited to the account or debited from the account.
To do this, you must click on either of the buttons adjacent to this field.
If the amount is to be credited to the account, click on the button against ‘Cr’. If the amount is to
be debited, click on the button against ‘Dr’.
Example
You want to post an adjustment entry to your customer, Ms Eustacia Fry’s, account. Assume the bank has
to pay her a nominal interest. The currency of the account is USD and the transaction amount is 100 USD.
When you enter this transaction in the system, you will enter 100 USD in the amount field. You will then click
on the button against Cr, adjacent to this field, since you want to credit your customer with the amount.
5-7
Transaction Code
Select the transaction code that you want to enter from the adjoining option list.
Period Code
The financial year of your bank is divided into four quarters. These details are maintained in the
Global Parameters module.
Example
You are entering a transaction on 31 March 1998. You are crediting a customer’s account with 125 USD.
The value date of the transaction, or the date when the transaction becomes effective, is 01 April 1998.
When you enter the Period Code, you will choose Q2 or the second quarter. You would do so since your
bank’s financial cycle would have entered the second period when the transaction becomes effective.
When you input a journal transaction you must indicate the financial period to which the
transaction belongs. Select the financial period for the journal entry you are entering from the
adjoining option list.
Financial Cycle
The period code is further divided into financial cycles. For example, your bank’s Board of
Directors meet once a month therefore, you would divide the financial cycle into monthly periods.
When you input a journal transaction, indicate the financial cycle to which the transaction
belongs.
Instrument Number
In case you are entering a check transaction, you have to enter the instrument number here if the
transaction code specifies an instrument number.
Additional Text
Enter any other additional information related to the transaction.
Local currency Amount
The system displays the transaction amount in case the transaction is in the local currency.
If the transaction that you are entering involves a foreign currency, the system calculates a local
currency equivalent of the transaction amount using the Exchange rate that is displayed in the
previous field.
Value Date
The system will display the current system date here. You can, however, enter a back dated or a
future dated transaction. In Oracle FLEXCUBE, the interest is calculated on the basis of the
Value Date.
5-8
Exchange Rate
In case the currency of the transaction is a foreign currency, the system displays the standard
mid rate for the currency. You can change the Exchange rate that is displayed in this field. Only,
the changed value should be within a certain range referred to as the Exchange Rate Variance.
The exchange rate variance is specified at the Branch Level for journal transactions.
In case you are entering a Foreign Currency back value dated transaction, the system will
pickup the exchange rate applicable on the Value Date. This is possible only if you have
maintained the Exchange Rate History for your branch (refer the ‘Branch Conditions’ screen).
Example
The default exchange rate that is displayed in the exchange rate field is 50.0 in the local currency. The
Minimum and Maximum Exchange Rate Variance that you have defined at the bank level is 1.5% and 2.0%
respectively. If you change the Exchange Rate, it can only be between 50.75 and 51 units in the local
currency.
Related Customer
The ID of the Customer involved in the transaction is entered in this field. This is used for MIS
purposes. The adjoining option list displays a list of the Customer IDs that have been maintained
in your branch. Double click on the ID that you want to enter in this field.
MIS Group
The MIS group to which the transaction belongs gets displayed here.
Total Debit
The total amount debited for the whole batch is converted into the local currency equivalent and
displayed here.
Total Credit
The total amount credited for the whole batch is converted into the local currency equivalent and
displayed here.
A single journal entry is validated during batch closure. The balance of currency and value
date accounting entries are checked during validation, only if Currency Wise Balancing check box
is checked at batch level.
5.5.1 Saving Transaction
When you have entered all the details of a transaction you have to save the transaction in the
system.
To save a transaction, select ‘Save’ from the Actions menu in the Application tool bar or click
save icon.
5-9
The system will update the transaction as an unauthorized transaction. The user ID of the teller
who entered the transaction and the date and time at which the transaction was saved will be
displayed at the bottom of the screen.
5-10
5.5.2 Batch Close
You can validate a batch to check whether it is balanced or not, using ‘Batch Close’ button. The
system unlocks the batch further to the validation. While creating a new batch, if you have
checked the option ‘Balancing’ in ‘Batch Open’ screen, you need to balance the transaction in
order to exit the batch.
Save the transaction and click ‘Batch Close’ button. If the transaction is balanced, the system will
process and unlock the batch. If the transaction is not balanced, system will display the following
error:
‘Batch not balanced’
If you see such an error message, you need to manually post equivalent entries in order to
balance the batch.
If you cancel this operation at the end of transaction input, the system does not verify the batch
balance. Further, the batch gets locked in ‘Batch Unlock Screen’.
While creating a new batch, if you have not checked the option ‘Balancing’ in ‘Batch Open’
screen, the input transaction need not be balanced in order to exit the batch. Thus, when you
click ‘Batch Close’ button, if the transaction is balanced, the system processes the batch and
unlocks it. If the transaction is not balanced, the system unlocks the batch and save the
transaction.
The Validations
The system performs the following cross validations during transaction input. It ensures that:

All the mandatory fields have been input by the user

The transaction amount is within the allowed limit for the teller

The exchange rate variance conforms to that defined at the branch level

The local currency variance limit
5.5.3 Deleting Journal Transaction
In special circumstances, you may want to remove a transaction from the system. In Oracle
FLEXCUBE you have the option of ‘deleting’ a journal transaction.
When a transaction can be deleted
If a transaction that you have input has not been authorized, you can delete it. Remember that
only the user who input a transaction can delete it.
5-11
How to delete a transaction
When you are in the Journal Input Form, select ‘Delete’ from the Actions menu in the Application
tool bar or click delete icon. The transaction that is displayed in the screen will be deleted. All
accounting entries passed for the transaction will be removed.
5.6
Entering Multi-offset Transactions
Specifying a Multi-offset transaction.
What is a Multi-offset transaction?
A multi-offset transaction is one in which multiple accounting entries are passed to balance one
main entry. For example, if cash that is debited from an account and credited to several other
accounts, multiple offset entries are passed to balance the one debit entry.
Example
Bounderby Inc., a multinational, has an account with your bank. Bounderby has instructed you to debit its
account with you, and credit its employee’s salary accounts on the last day of every month. When you carry
out these instructions at the end of the month, you would be entering a multi-offset transaction.
When you enter a multi-offset transaction, the system ensures that the total amount of the offset
entries is equal to the amount of the main entry.
Before you can enter multi-offset transactions for the day, you must open a ‘batch’ to post
these transactions.
5.6.1 Entering a Multi-offset Transaction
You can invoke the ‘Journal Multi Offset Input’ screen by typing ‘DEDJRMLT’ in the field at the
top right corner of the Application tool bar and clicking the adjoining arrow button.
5-12
The following are the details of a Multi-offset transaction that you need to enter in this screen:

Account

Amount

Exchange Rate

Instrument Number and Description

Additional text

Fund Identification

Transaction Code for the main leg

Transaction Code for the offset leg

Currency

Indicate Debit/Credit

Value Date
Batch Number
The batch that you have opened to post the multi-offset transaction is displayed at the top of the
‘Multi-offset Input’ screen. Every such transaction that you enter into the batch is assigned a
‘current number’ by the system. This helps you to identify the multi-offset transactions that you
enter for the day.
Template Identification
You can process a multi-offset transaction by associating a relevant template to the transaction.
The details maintained for the template will be defaulted to the transaction. You will be required to
capture only the remaining mandatory details (if any) to save the transaction.
The option list for ‘Template ID’ field displays the templates maintained for a particular branch.
You need to choose a Template ID from this list. Further click ‘Default Template’ button to get the
selected template defaulted. However, you cannot type in a Template ID in the Template
Identification field.
Current Number
Every such transaction that you enter into the batch is assigned a ‘current number’ by the system.
This helps you to identify the multi-offset transactions that you enter for the day.
On selection of the template, the following details get defaulted to the transaction:
In the MAIN tab
1. The Account Number for the main leg of the transaction and the associated description.
2. The currency and amount of the transaction. The debit/credit indicator for the same.
3. The transaction code associated with the main entry and the offset entry of the transaction.
5-13
4. Additional remarks, if any.
In the OFFSET tab
1. The branch codes and the accounts for the offset leg of the transaction.
2. The amount for each account.
You can process a multi-offset transaction without a template also. This is explained in detail in
the following sections of this manual.
5.6.2 Entering Details of Main Leg
Click on Main to enter the details of the main leg of the transaction.
Account
Specify the exact account /GL number of the main leg of the transaction.
Amount
In this field enter the amount of the transaction. The amount that you enter here must be in the
currency of the account number that you specified.
Exchange Rate
In case the currency of the transaction is a foreign currency, the system displays the standard
mid rate for the currency. You can change the Exchange rate that is displayed in this field. Only,
the changed value should be within a certain range referred to as the Exchange Rate Variance.
The exchange rate variance is specified at the Branch Level for Journal transactions.
In case you are entering a Foreign Currency back value dated transaction, the system picks
up the exchange rate applicable on the Value Date. This is possible only if you have maintained
the Exchange Rate History for your branch (refer the ‘Branch Conditions’ screen).
Example
The default exchange rate that is displayed in the exchange rate field is 50.0 in the local currency. The
Minimum and Maximum Exchange Rate Variance that you have defined at the bank level is 1.5% and 2.0%
respectively. If you change the Exchange Rate it can only be between 50.75 and 51 units in the local
currency.
Overrides
If you change the exchange rate to a value between the maximum and minimum exchange rate
variance
You cannot change the exchange rate to a value that is greater than the specified maximum
exchange rate variance.
5-14
Instrument Number
In case one leg of the transaction involves a check, you have to enter the instrument number here
if the transaction code specifies an instrument number.
Description
Enter a brief description for the Instrument Number that you have specified.
Additional Text
If required, enter any additional information related to multi-offset transactions.
Fund Identification
Specify the fund id to which the journal entry account will be linked by selecting from the adjoining
option list.
Transaction code
Under Transaction Code on the right top of the screen, you will observe two fields, ‘Main’ and
‘Offset.’
In the Main field, the adjoining option list displays a list of all the transaction codes that are
maintained in your branch. Double click on the transaction code that you want to specify as the
transaction code of the main leg of the transaction.
In the Offset field, the adjoining option list displays a list of all the transaction codes that are
maintained in your branch. Double click on the transaction code that you want to specify as the
transaction code for the offset leg of the transaction.
Currency
The system defaults to the currency of the account number that you have entered (in case of a
customer account). If the account is a GL, the system defaults to the local currency.
If you have to enter the currency of the transaction, you can do so. The adjoining option list
displays a list of valid currencies. Double click the currency that is the transaction currency.
Debit/Credit
You must indicate if the amount is to be credited to the account or debited from the account. To
do this, you must click either of the buttons adjacent to this field.
If the amount is to be credited to the account, click the button against Cr. If the amount is to be
debited, click the button against Dr.
Example
You want to debit the account of Bounderby Inc., and credit the accounts of its 250 employees. You would
enter the amount of the transaction, and click on the button against Dr to indicate that the account of
Bounderby Inc. is to be debited.
5-15
Value Date
The system will display the current system date here. You can, however, enter a back dated or a
future dated transaction. In Oracle FLEXCUBE, the interest is calculated on the basis of the
Value Date.
Overrides

If the value date is back dated or future dated

If the value date is a holiday
Batch Close
While creating a new batch, you need to check the option ‘Balancing’ in ‘Batch Open’ screen, in
order to balance the input transaction. To exit the batch, the transaction need to be mandatorily
balanced. When you click ‘Batch Close’ button, if the transaction is balanced, the system
processes the batch and unlocks it. If you cancel the batch, the batch gets locked in ‘Batch
Unlock’ screen. However, you can unlock it manually.
Entering Details of the Offset Leg of the Transaction
To enter details of the Offset leg of the transaction, click Offset.
Specify the following details.
5-16
Branch
In this field, enter the branch IDs of each of the offset accounts.
Account
Enter the account number of each of the offset accounts in this column.
Amount
For each of the offset accounts enter the offset amounts.
Instrument Number
If the Offset leg of the transaction involves an instrument number, enter the same in this column.
The total offset amount will be displayed at the bottom of the screen. After you have made your
specifications in the above columns map each offset entry to the branch, an account and the
amount.
5.6.2.1 Saving Transaction
When you have entered all the details of a transaction you have to save the transaction in the
system.
To save a transaction, select ‘Save’ from the Actions menu in the Application tool bar or click
save icon.
The system will update the transaction as an unauthorized transaction. The user ID of the teller
who entered the transaction and the date and time at which the transaction was saved will be
displayed at the bottom of the screen.
The Validations
The system performs the following Cross Validations during Transaction Input. It ensures that:

All the mandatory fields have been input by the user

The transaction amount is within the allowed limit for the user

The exchange rate variance conforms to that defined at the branch level

The sum of the offset amounts is the same as the main amount
5.6.3 Deleting Transaction
In special circumstances, you may want to remove a transaction from the system. In Oracle
FLEXCUBE you have the option of ‘deleting’ a multi-offset transaction.
When can a transaction be deleted?
If a transaction that you have input has not been authorized, you can delete it. Remember that
only the user who input a transaction can delete it.
5-17
How to delete a transaction
When you are in the Multi-offset Input Form, select ‘Delete’ from the Actions menu in the
Application tool bar or click delete icon. The transaction that is displayed in the screen will be
deleted. All accounting entries passed for the transaction will be removed.
5-18
6.
6.1
Data Entry Control Operations
Introduction
The Data Entry Supervisor of your branch performs certain operations during the day. The
following are the functions that the Data Entry Supervisor would perform
6.2

Batch authorization

Unlocking a batch

Reassigning a batch to another user etc.

Batch upload
Batch Authorization
Authorization is a cross-checking mechanism that Oracle FLEXCUBE offers. The transactions
that tellers enter during the day must be ‘authorized’ by the Data Entry Supervisor at the end of
day.
This ensures that all the transactions that have been entered by tellers conform to the parameters
that have been defined for your branch.
6.2.1 Authorizing Batches
At the Beginning of Day, each teller opens a batch to post a particular type of transaction. A teller
who enters three different types of transactions will open as many batches. Instead of authorizing
individual transactions that have been entered during the day, you can authorize the batches into
which they have been posted. This is called ‘summary authorization.’
Summary Authorization of a batch
At the End of Day, authorizing every transaction could be a tedious process. You can instead do,
what is called, a Summary Authorization of the batch into which the transactions have been
posted.
Only users other than the one who posted transactions (the Data Entry supervisor, for example)
into a batch can authorize the transactions in the batch.
Summary Authorization is possible in two ways.
You can invoke the ‘Journal Batch Authorization’ screen by typing ‘DEDBTAUT’ in the field at the
top right corner of the Application tool bar and clicking the adjoining arrow button.
6-1

Summary Authorization of a batch with limits

Summary Authorization of a batch without limits
The ‘Batch authorization’ screen can be invoked from the Application Browser.
Summary Authorization of a batch with limits
It is possible to define authorization limits for a user with authorization rights (Refer the SMS
Manual). If such a limit has been defined for you, you cannot authorize transactions which cross
the limit. That is, if the transaction amount exceeds the limit specified, you will not be allowed to
authorize the transaction.
A user whose authorization limits have been defined, can perform a summary authorization of a
batch. If the transaction size of any transaction posted to the batch exceeds the authorization limit
defined for the authorizer, it will not be authorized.
When the summary authorization of the batch is complete, the number of transactions that were
authorized and the number of transactions that were not authorized (those that crossed the
authorization limit) will be displayed.
Summary Authorization of a batch without limits
If no authorization limits have been specified for you, you can authorize transactions of any size.
If a user with an unspecified authorization limits does a summary authorization of a batch, all the
transactions in the batch will be authorized.
When the summary authorization of the batch is complete, the number of entries that were
authorized will be displayed.
To Authorized the transactions in a batch choose Jrnl/Teller Batch Op in the Application Browser.
Click on Auth Without Limits. The ‘Batch Authorization’ screen will be displayed.
The date and the time at which the batch was authorized will be displayed in the bottom of the
screen.
6-2
6.3
Reassigning Batch
To ‘reassign’ a batch is to allow a teller who did not originally open a batch to use it. The Data
Entry Supervisor has the rights to reassign a batch to a teller who did not originally open a batch.
However, only unauthorized batches can be reassigned.
You can invoke the ‘Journal Batch Reassign’ screen by typing ‘DEDBTASN’ in the field at the top
right corner of the Application tool bar and clicking the adjoining arrow button.
6.3.1 Reassigning Batch
To reassign a batch to a different user click on Jrnl/Teller Batch Op in the Application Browser.
Choose Reassign Batch displayed under it. The ‘Batch Reassign’ screen will be displayed.
Batch Number
The adjoining option list displays a list of unauthorized batches that are opened for the day.
Choose the batch that you want reassign in the batch number field.
Reassign Identification
Choose the User Id of the teller to whom you want reassign the batch in the Reassign ID field.
The system ensures that the batch is not currently in use. If you choose to reassign the batch to
yourself, the system will seek an override.
Entry Total
Total Entries indicates the total amount debited and credited for a particular batch.
Click ‘Ok’ button to confirm the reassign operation. If you do not want to continue with the
reassign operation, choose ‘Exit’ or ‘Cancel’ button to exit the function.
6-3
6.4
Processing Journal Batch
Using Oracle FLEXCUBE, you can view, unlock, reserve journal batches and set your
preferences with regard to journal upload.
6.4.1 Viewing Journal Batches
You can search and view all journal batches using ‘Journal Batch Browser’ screen. To invoke the
screen, type DEDBATOT in the field at the top right corner of the Application Browser and click
the adjoining arrow button.
This screen displays all the batches that have been created in the current branch.
You can delete or authorize the batches based on your requirement. Select the record / records
that you wish to delete or authorize by checking the adjoining box. Further click the delete button
or authorize button for respective actions.
During authorization the balance of currency and value date accounting entries are checked,
only if Currency Wise Balancing check box is checked at batch level.
6-4
6.4.2 Unlocking Journal Batches
While entering a transaction through Journal Single and Multi Offset entries, if you have not
checked the option ‘Batch Close’, the system locks the batches in. You can unlock such locked
journal batches using Journal Batch Unlock screen. To invoke the screen, type DESBTULK in the
field at the top right corner of the Application Browser and click the adjoining arrow button.
You can search for the records based on batch number and / or operator. The system fetches the
records based on the search criteria. Select the batches that you wish to unlock and click ‘Batch
Unlock’ button. The system unlocks the selected batches.
6.4.3 Reserving Journal Batches
You can reserve journal batches for DE Macro upload purpose (excel upload) for a specific
branch and source combination. To invoke Journal Batch Reservation screen, type DEDBTRES
in the field at the top right corner of the Application Browser and click the adjoining arrow button.
6-5
Here, you can capture the follwoing details:
Branch Code
Specify the branch code for which you wish to apply the restriction.
Source Code
Specify the source code. The system will apply this restriction to the branch-source combination
maintained here.
Batch Number
This is the batch identification number.
Remarks
This field captures the remarks about the branch.
You can add more rows to the restriction list by clicking add button. Once you save the
maintenance, the system considers these batches as reserved. You cannot input transactions
through Single or Multi Offset Entry. These batches can be used for DE Excel Upload
transactions only.
6-6
6.4.4 Maintaining Journal Upload Preferences
You can set your preferences specific to journal upload using ‘Journal Upload Preferences
Maintenance’ screen. To invoke the screen, type DEDUPLPR in the field at the top right corner of
the Application Browser and click the adjoining arrow button.
You can maintain Suspense GLs where entries have to be posted for each external system in the
event of failure of account validation during DE Upload.
You can capture the following details on this screen:
Source Code
Specify the source code for upload.
Real Local Currency
Specify the suspense GL for real local currency on credit as well as debit transactions.
Real Foriegn Currency
Specify the suspense GL for real foreign currency on credit as well as debit transactions.
Contingent Loacl Currency
Specify the suspense GL for contingent local currency on credit as well as debit transactions.
Contingent Foreign Currency
Specify the suspense GL for contingent foreign currency on credit as well as debit transactions.
6-7
Once you have captured all the details, save the maintenance. If an invalid account is specified in
the upload process, the respective Suspense GLs maintained for that external system will be
debited or credited based on the nature of the transaction.
6-8
7. Reports
7.1 Introduction
The following are the reports that you can generate in Data Entry module:

Batch Totals report

Currency Position report
To generate any of these reports choose Reports in the Application Browser. Choose Browser
under it. A list of all the reports in each module will be displayed. You can choose to view or print
the report.
The time and the operator who generated the report will be displayed.
7.2 Report on Currency Positions of your Branch
You can ascertain the position of a currency, across the Tills/Vaults that are maintained in your
branch, any time during the day. The position of a currency in your branch (i.e. the total amount of
the specified currency in all the Tills and Vaults) can be generated in the form of a report using
the ‘Currency Position Report’ screen. You can also invoke this screen by typing ‘GLRPCCY’ in
the field at the top right corner of the Application tool bar and clicking the adjoining arrow button.
This summary and the detailed view of this report can be generated. The report will be in a
tabular format. The user ID of the Teller who is using any particular Till, at the time the report is
generated, will be displayed in the Detailed View of the report.
In the summary view if you double click on a row (i.e. on a Till) the position of the Till in the
specified Currency will be displayed.
The Report contains the following details in the summary view:

Currency

Total position of the Currency specified
The Report contains the following details in the detailed view:

Till ID
7-1

Teller ID

Currency

Total Position of the Currency

Currency position of a specified Till
7-2
Data Entry
[July] [2014]
Version 11.5.0.0.0
Oracle Financial Services Software Limited
Oracle Park
Off Western Express Highway
Goregaon (East)
Mumbai, Maharashtra 400 063
India
Worldwide Inquiries:
Phone: +91 22 6718 3000
Fax:+91 22 6718 3001
www.oracle.com/financialservices/
Copyright © [2007], [2014], Oracle and/or its affiliates. All rights reserved.
Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their
respective owners.
U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs
installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer
software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As
such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system,
integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and
license restrictions applicable to the programs. No other rights are granted to the U.S. Government.
This software or hardware is developed for general use in a variety of information management applications. It is not
developed or intended for use in any inherently dangerous applications, including applications that may create a risk of
personal injury. If you use this software or hardware in dangerous applications, then you shall be responsible to take all
appropriate failsafe, backup, redundancy, and other measures to ensure its safe use. Oracle Corporation and its affiliates
disclaim any liability for any damages caused by use of this software or hardware in dangerous applications.
This software and related documentation are provided under a license agreement containing restrictions on use and
disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or
allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit,
perform, publish or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of
this software, unless required by law for interoperability, is prohibited.
The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any
errors, please report them to us in writing.
This software or hardware and documentation may provide access to or information on content, products and services
from third parties. Oracle Corporation and its affiliates are not responsible for and expressly disclaim all warranties of any
kind with respect to third-party content, products, and services. Oracle Corporation and its affiliates will not be
responsible for any loss, costs, or damages incurred due to your access to or use of third-party content, products, or
services.
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertisement