Sei sulla pagina 1di 93

1

Teller is one of the account based applications in T24 for moving funds around
the system internally and externally. It could involve transfer of funds from one
account to another account. It involve accepting cash deposit, withdrawal in
local currency, foreign currency etc. Teller application can handle currency
exchange as also sale and buy of Travelers cheques etc. In Teller application we
will be seeing linkages to various static tables like currency and commission on
TT. Objective of the course will cover application specific parameters connected
with this application, build sequence, product features. Cheque collection is one
of the applications encompassed in TT module. It covers various types of
collection cheque like local clearing cheque and outstation cheque etc.

T3TTT - Teller - R10.1

TELLER application is meant for handling cash, travellers cheques and account
to account transfer. Teller operations handle both local currency and foreign
currency transactions. Cash deposits and withdrawal, Foreign currency buying
and selling, account to account transfer, sales or purchase of travellers cheques
and printing of passbooks can be handled through TELLER application. It is also
possible to transfer cash from one teller to another for operational requirements
in addition to transfer of cash from Vault to Tellers. Teller operations affect
Customer Accounts, Internal Accounts and Profit and Loss items. Cash is an
internal account and any cash transaction done by a Teller will affect Cash
account. When a customer is paid cash or when cash is received from a customer
for credit to account, customers accounts are affected. Accounting is automatic.
When customer accounts are affected, limits are checked and updated
automatically, where applicable.
It is possible to take charges for some operations. When foreign currency is
bought or sold, banks take currency handling charges and commission. In
addition to this, Teller department may like to book marketing exchange profit or
loss when the rate offered to customer is different from Treasury rates.
Vault is where Banks cash is centrally held. There could be more than one vault
also. Head Teller operations include control of Vault. Head Teller also controls
other tellers. Controlling of other tellers include assigning tills to users,
authorising transactions of tellers and transfers between tills, physical checking
of cash during till closure.

T3TTT - Teller - R10.1

First step of daily operational cycle would be to actually open the till and assign a
user to it. Assigning tills to Tellers is done by Head Teller. Cash is transferred
from vault to tills. Various operations like cash deposit, withdrawal, currency
exchange and account transfer can be continued by the teller as long as the till is
open. During intraday, when cash balance in a till is insufficient to carry on
operations, cash is transferred from Vault to tills or among tills without operating
the Vault. At the end of the day, the tills are closed and surplus cash is transferred
to Vault. Some banks allow small change to be left with tellers. When closing a
till, teller is required to enter currency wise cash amounts which are checked
against the system balances. If any discrepancy is discovered an override is
raised and if accepted, T24 posts the difference automatically to cash overage or
shortage.
In line with accounting rules, Cash account is debited while receiving. Hence if
the balance with a Teller is negative balance, then Teller is having that amount.
At times, without adequate cash, a Teller may input a transaction to pay out cash.
T24 generates override that Till is having credit balance. Teller can then receive
cash from vault or another till and then physically effect payment. Record need
not be deleted on seeing the override.
It is possible to scan and store customers signatures through
IMAGE.MANAGEMENT application and use that whenever an account is
debited for payment. Printing of passbooks or deal slips can also be included by
linking the teller to a printer directly or through a network.

T3TTT - Teller - R10.1

TELLER in T24 makes use of CUSTOMER, ACCOUNTS, DELIVERY,


ACCOUNTING, LIMITS and other STATIC tables.
We need to have customer records before opening Customer type of account. As
CUSTOMER table is linked, all non financial information about the customer is
picked from the CUSTOMER record for any transaction.
We require accounts to handle various customer related transactions like cash
deposits, cash withdrawal etc. We also require internal accounts to handle cash,
travelers cheques etc.
Deal slips and Pass books could be printed by Tellers and delivered across the
counter to the customer.
When a customer account is debited for cash withdrawal, system checks for
balance in the account, limit if any sanctioned and attached to the account,
availability of limit before the withdrawal is put through. If the limit is exceeded
appropriate overrides are generated.
Other static tables used include CATEGORY for the various product category and
FT.COMMISSION.TYPE for recovering commission.

T3TTT - Teller - R10.1

Teller operations affect Customer Accounts, Internal Accounts and Profit and
Loss items.
Product code defines the type of the account like savings, current, Nostro, Vostro
etc. For customer type of accounts the category code should be between 1000
and 9999.
When a customer is paid cash or when cash is received for the credit to
customers account, customer accounts are affected.
Cash is an internal account and any cash transaction done by a Teller will affect
cash account. In the similar manner the Travellers cheques are also handled
through internal accounts in T24. For Internal type of accounts the category
code should be between 10000 and 19999 .
It is possible to take charges for some of the Teller operations. Category codes
for such profit and loss items used is 50000 and above.

T3TTT - Teller - R10.1

Charges and commission for TELLER application are collected by using


FT.COMMISSION.TYPE table. FT.COMMISSION.TYPE is used to indicate
pre defined commission to be collected for specific teller transactions.
FT.COMMISSION.TYPE records can be linked to TELLER.TRANSACTION
for collecting charges for specific transactions like foreign currency purchase,
cash withdrawal etc.
Banks can collect either a flat charge amount irrespective of transaction size or a
variable commission amount and can be defined for both these situations.
When transactions are input by teller, then appropriate rates for the specific
transaction linked to FT.COMMISSION.TYPE are applied.
It is possible to set minimum and maximum amount of commission to be
collected in FT.COMMISSION.TYPE. Likewise, it is possible to define zero
percent commission up to an amount of say USD 25,000 and 0.25%, thereafter.
Then, even when we opt to take commission for a transaction, if the transaction
amount were less than USD 25,000, T24 will not collect any commission for that.
Similarly it is also possible to collect tax, if any, by attaching a suitable TAX
record to TELLER.TRANSACTION.

T3TTT - Teller - R10.1

CURRENCY.PARAM table contains common details for each currency to ensure


that the same numeric code and no. of decimals are used on different currency
files in a multi company environment. Currency name and interest basis may be
changed at individual currency file level. Numeric currency code, an alternate to
currency code, can only be changed on this file. If two currencies are involved in
a conversion, then the currency with the lowest rank will take preference as base
currency. CURRENCY table is used to maintain buying, selling and middle rates
for different foreign currencies. When an account is debited, the currency of that
account is bought and T24 defaults buying rate of that currency from this table.
Similarly, when an account is credited, the currency of that account is sold and
T24 defaults selling rate. These rates are held market wise, like separate rates for
Currency market 1 and separate rates for Cash market 10. Currency market 1
could be used for all currency transactions and Currency market 2 could be used
for all travelers cheques related transactions. Up to 99 markets can be indicated
in CURRENCY.MARKET table. Consolidation keys are formed market wise.
Markets beyond 9 will be consolidated with the market type of the first digit
example 10 with 1. It is possible to set rules as to which market rates are to be
defaulted for what type of teller transactions.
When foreign currency transactions are input, we can indicate bought currency to
pick exchange rate from Market 1 and sold currency to pick exchange rate from
Market 10.

T3TTT - Teller - R10.1

T3TTT - Teller - R10.1

In TELLER.DENOMINATION table all denominations are entered for a


currency be it for cash handling or Travelers cheques handling. Denomination
will be defaulted in TELLER and TELLER.ID applications.
TELLER.PARAMETER is the top level parameter file to define general rules,
category and transaction codes to be used for Teller System.
ACCOUNT.CLASS table is used to define the product category, used to issue
passbooks instead of statements. In ACCOUNT.CLASS a record called
SAVINGS has to be duly defined. Category for market exchange is defined in
the table. TELLER.TRANSACTION table defines default values and
validations for each Teller transaction like accounts to be used, currency markets
for each leg and charges to be taken etc. TELLER.ID application is used to
open tills, assign users to tills and close and balance tills. Format for passbook
can be defined in TELLER.PASSBOOK.
Advices can be printed from any Teller transaction. Format and the content is
user definable by means of DEAL.SLIP.FORMAT utility.
DEAL.SLIP. FORMAT essentially describes what data should be extracted from
the deal and where on an advice should be printed. APPL.GEN.CONDITION
application can be used to allocate group codes based on a number of defined
conditions or it could be a local routine for any T24 application with a
STANDARD.SELECTION record.
TT.GROUP.CONDITION can be set up to create default conditions regarding
charges to be taken and rate spread.

T3TTT - Teller - R10.1

10

TELLER.DENOMINATION table is used to define description and currency


wise value of denominations to be used in Teller transactions. This will be
defaulted during transactions and closing of Tills. Before the denomination is
defined, denomination type is defined in DENOM.TYPE table.
DENOM.TYPE table is used to define various denomination types such as Cash,
Gift Cheques, Travelers Cheques, etc. This DENOM.TYPE is attached to
TELLER.DENOMINATION.
If it is proposed to use the denomination facility in TELLER and TELLER.ID
applications, then denominations are to be pre-defined here for each currency.
Denominations can be indicated for Cash as well as Travelers cheques and other
denomination types to be used. First 3 characters of Id to be a valid Currency. Id
can be like USD100, EURTC50. Value can be indicated while creating the
records.
Values are represented as multiples or fraction of ONE unit and up to 3 decimals.
For example 100.000 or 50.00 or 0.500 are valid values created.
All denominations entered here for a currency be it for cash handling or Travelers
cheques handling, will be defaulted in TELLER and TELLER.ID applications.
This could be filled up only for the denominations required either for Cash or for
TC or for both.

T3TTT - Teller - R10.1

11

TELLER.PARAMETER is the top level parameter file used for the teller
system.
It defines the category and transaction codes to be used for balancing tills, the
category to be used for cash, rounding details for local currency, vault id etc.
Rules can be set company wise and Id is Company code.
Vault related information is entered through VAULT.ID and VAULT.DESC
Fields. Vault is where Banks cash is centrally held. It is mandatory to have at
least one vault. There may be more than one vault for a bank one for Head
office and one each for a branch. Head Teller operations include control of
vault. Specifies the id of the vault as defined on the TELLER.ID file.
VAULT.ID Field defines which teller id is the vault. Vault differs from normal
teller operations in that it cannot be opened or closed and the only transactions
allowed are transfers to and from the teller cash accounts. Vault should be
entered here before entering the id on the TELLER.ID file. In T24, a Vault is
identified with a 4 digit number. If present on the TELLER.ID file then the status
and user fields must be null.
Description of the vault in VAULT.DESC Field is used as online enrichment on
transaction. This will be displayed whenever a vault is entered into TELLER, for
performing transfers etc.

T3TTT - Teller - R10.1

12

When an account is debited, currency of that account is bought and T24 defaults
buying rate of that currency from CURRENCY table. Similarly, when an
account is credited, currency of that account is sold and T24 defaults selling rate.
When both sides are foreign currencies, T24 defaults the cross currency rate for
the transaction automatically. RATE Field specifies whether there should be an
option to specify rate for same currency deals. RATE Field can take values from
1 to 3, where 1 - Not Allowed, 2 - Allowed with override always and 3 - Allowed
but have a variance override. MKT.EXCH.METHOD Field defines the method
for calculating local equivalents and deriving marketing exchange profit. For
example the following rates are available for GBP and EUR currency. Bank is
buying GBP 10000 and selling EUR 14656.06. Both sides of the transaction have
same local currency. The rates are as under:
Currency

Mid Rate

GBP

1.96

EUR

1.315

Buy Rate

Sell Rate

1.9346

------

-----

1.32

If the MKT.EXCH.METHOD is middle then GBP of 10000 is converted to 1.96


which is equivalent to USD 19600 and for EUR 14656.06 is converted at 1.315
which works out to USD 19272.72. The difference between USD19600 and
USD19272.72 which works out to USD 327.28 is accounted in MKTEXCHCR.
If the MKT.EXCH.METHOD is none, it is using the buy rate and the sell rate
GBP 10000 is converted at the buy rate viz 1.9346 which works out to
USD19346 and for EUR 14656.06 it is converted at the sell rate of 1.32 which
works out to USD 19346.

T3TTT - Teller - R10.1

13

T3TTT - Teller - R10.1

13

When there is shortage or excess in Till balance during closure of Till, it could
be transferred to internal account so as to tally the Till balances with system.
OVER.CATEGORY Field used to indicate for overages in Till. When a till is in
excess the system balance can be adjusted by transferring the amount from the
over account. SHORT.CATEGORY Field used to indicate shortages category.
When Till is in short, the amount could be transferred to the short account.
These internal accounts are maintained Currency wise and Teller wise. Similarly
TRAN.CODE.SHORT and TRAN.CODE.OVER Fields are used to define
transaction codes used for such transaction.
TRAN.CATEGORY Field specifies the category codes used to define the teller
cash accounts, vault and Travelers cheque Teller's cash accounts are defined
using the currency, category code and the teller id. Only these accounts will
require reconciliation with the till balances when the till is closed. Must be a
valid entry on the CATEGORY file and must be in the range 10,000 to 19,999.
Category codes cannot be the same for the over & short categories and duplicates
are not allowed.
AUTOCASH.CATEGORY Field is used to identify transactions which requires
an interface to the auto cash dispenser. Decision to invoke the auto cash interface
is based on a withdrawal against this category if the TELLER.ID record indicates
a device is installed. Device is indicated in AUTOCASH.DEVICE Field in
TELLER.ID application. Normally this should be the same as the cash category
defined in TRAN.CATEGORY Field.

T3TTT - Teller - R10.1

14

Rounding rule is specified through CURRENCY table. In


TELLER.TRANSACTION, if charges and taxes are defined, normally, the
charge and tax amount will be deducted from the related credit or debit
transaction of the customer and accounting entries will be raised for the net
amount only. Net amount is rounded based on the minimum amount by posting
the difference to PL category indicated in ROUNDING.CATEGORY Field.
Transaction codes used for crediting and debiting this PL category are indicated
to ROUND.TXN.CODE.CR and ROUND.TXN.CODE.DR Fields. It is also
possible to split the entries, as one for full transaction amount and the others for
the charge, tax related amounts. If a cash deposit in a customer account of
USD10000 has a charge of USD100 and tax of USD10, if
SPLIT.CHRG.ENTRIES is defined as YES, the following accounting entries are
raised.
Debit cash account for USD 10000, credit customer account for USD 10000.
Debit customer account for USD 100 for charges, Debit customer account for
USD 10 for Tax and credit tax account with USD 10. If SPLIT.CHRG.ENTRIES
were left blank, then for the above example, entries that will be passed are as
under: Debit Cash account for USD 10000, customer will be credited for USD
9890 and USD 100 will be credited to Charges and USD 10 to tax account.

T3TTT - Teller - R10.1

15

Till balance will always have a debit balance. When ever the till account goes
into credit balance on authorisation of a teller transaction the TILL.
BAL.AUTH.ERR Field will raise an error message as CREDIT TILL CLOSING
BALANCE, if the field is set as YES. If this field is set as null, then system
allows the user to authorise the transaction with out any error message.
When teller inputs a transaction which involves multiple internal accounts, one
with denomination control and others without denomination control, then system
should check for the denomination for the amount to be remitted into the account
with denomination control and not for the total amount of transaction.
In TELLER.PARAMETER by setting CHECK.STOCK.AMT. Field as YES or
NULL. If Yes is inputted in this field, system will check for denomination for the
amount mentioned for the account mentioned with denomination control in the
transaction, and not for the total amount of transaction. For example when a
teller inputs a debit transaction with two internal accounts in side1 where
account1 is for USD 10000 is having denomination control and account2 is not
having denomination control. Input amounts say USD 10000 for account1 and
USD 12000 for account2 and commit the transaction. Denomination will be
accepted for 10000 only. When this field is null the total denomination units in
the Teller transaction will be checked against the total transaction amount.

T3TTT - Teller - R10.1

16

Generally only one till is allotted to a user through TELLER.ID. As long as that
till is kept open, system will not allow another till to be allotted to the same user.
However, if it is proposed to allot more than one till to a user, then
MULTI.TILLS Field should be set as Yes.
Further, Multi Tills contains a limited amount of cash transferred from the Vault.
Whenever there is a shortage of cash instead of drawing from the Vault cash is
transferred from the MULTI TILLS. On the contrary if the till cash balance
exceeds the permissible limits then it is transferred to MULTI TILLS. In short,
we can call the Multi Tills as an intermediary between the Vault and the till.
Permitted values in the MULTI.TILLS are Yes and Null.
If set to yes the Max.Tills Field is a mandatory input. Multi Tills functionality
namely two or more tills for a user is made available any numeric, between 1-99
can be input in the field Max Tills. It represents the number of tills a user can
keep open at any given time when dealing with the Multi Tills facility. If multi
tills is Yes and this field is input as 4 it means any user can have a maximum of 4
tills open at any point of time. Input in this field can be changed at any time.
Once changed the new input will be effective and earlier validations will become
null and void. For example, if max tills is input as 3 and then changed to 2
any intention to input more than 2 tills subsequently will be met with the error
message Other tills must be closed for MULTI TILLS once this set-up is made
attaching of more than ONE teller id is done through application TELLER.ID.

T3TTT - Teller - R10.1

17

TELLER.TRANSACTION file defines the defaults and validation to be used for


teller transactions. It defines the accounts to be used for both sides of the
transaction, transaction codes, charges to be applied, currency, currency markets,
denomination types etc. Accounts could be customer accounts, internal accounts
or Profit and Loss categories. It is also possible to define the currency for side
one and side two of the transaction.
When inputting a teller transaction, when this predefined transaction code is
input, system automatically defaults all relevant values and validates against
rules set in the table.
It is not possible to input transactions without using a predefined
TELLER.TRANSACTION code.
TELLER.TRANSACTION consist of two sides, Debit and Credit sides. Rules
for each side are set separately. They could be defined in any sequence, but
system ensures that they are always contra.

T3TTT - Teller - R10.1

18

Transaction codes are defined for each side of the TELLER.TRANSACTION.


Debit or credit sign indicated in the TRANSACTION table decides whether this
side is debit or credit. Value date and exposure dates are also derived from here.
VALID.CURRENCIES.1 Field used to indicate which currencies are allowed.
Currency could be LOCAL or FOREIGN or ANY.
VALID.ACCOUNTS.1 Field is used to indicate which type of accounts are
allowed. It could be INTERNAL, PL, CUSTOMER or ANY.
CAT.DEPT.CODE.1 Field indicate category code of internal account or Profit
and loss. Category code can be mentioned alone or with DEPT.ACCT.OFFICER
or with NN99 -10001 or 100011234 or 10001NN99.
Internal account is determined using currency, category and department account
officer. If the DEPT.ACCT.OFFICER Field is blank, then the teller id is used.
Department account officer can also be in the format NN99. In this case the
internal account is constructed using currency, category, the first two digits of the
teller id and 99. Any number of digits can be defaulted in this way. This facility
can be used to support branch specific tills without the need to set up individual
TELLER.TRANSACTIONS for each branch. If the entry is posted to a P&L
category then the DEPT.ACCT.OFFICER code is inserted into the account
officer field of the entry.
If side 1 is defined as customer type of accounts, then this field must be blank.

T3TTT - Teller - R10.1

19

Charges and Tax to be collected for the transaction is defined in multi valued
Field CHARGE.CODE. Ids of FT.COMMISSION.TYPE and TAX can be
indicated here. Charges and commissions collected from ACCOUNT.2 of
TELLER application. If charges, commission and tax have to be split and
accounted separately in account, then SPLIT.CHRG.ENTRIES Field should be
set to YES. For example a cash deposit in a customer account of $10000 has a
charge of $100. If SPLIT.CHRG.ENTRIES is defined as YES, accounting
entries are:
Debit Cash account

USD 10000

Credit Customer account

USD 10000

Debit Customer account for Charges

USD 100

Credit P&L Account for charge

USD 100 otherwise

Debit Cash account

USD 10000

Credit Customer account

USD 9900

Credit P&L Account for charge

USD 100

For printing deal slips, PRINT.ADVICE Field to be set as yes.


ADVICE.VERSION Field defines entry on DEAL.SLIP.FORMAT file which
specifies the format of the advice. Multiple advices can be produced, although,
this is only available for DEAL.SLIP.FORMAT advices.

T3TTT - Teller - R10.1

20

It is possible to default the denominations at the user level. User can choose
whether the defaulting of the denomination should be enabled at the transaction
level or not. AUTO.DENOMINATE has allowable values, YES or NO. When
this field is set to YES, the system will support the current functionality of
default or pre-filling the denominations. When it is set to NO, the system will
not default any denominations. For example if a Teller is inputting a cash deposit
of USD 10000 to the customer account then if AUTO.DENOMINATE is set as
No, user has to input the denomination.
DENOM.FILTER feature allows the filtering of the denominations, based on the
type of transaction, and to restrict the number of denominations for a specific
type of transaction. If this is field is set to yes the denomination is specified for
credit side and debit side. For example, if a user does a transaction of accepting
cash deposit of USD 10000 for a customer account and if the DENOM.FILTER is
not set as yes, then you will find that all the denomination will appear on the
screen like cash denomination as well as travelers cheque denominations. Once
if you have set this DENOM.FILTER as YES and if a user is doing a transaction
of accepting cash deposit then the denomination pertaining to cash deposit will
alone be displayed. If a user is doing a transaction of selling travelers cheque then
only the denomination of travelers cheque alone will be displayed . This feature
of allowing to filter the denomination based on the type of the transaction.

T3TTT - Teller - R10.1

21

Transfers between two tills could be effected any time. TELLER.TRANSFER


Field specifies whether this transaction is a teller transfer. If the field is set to yes
then till to till transfer is permitted. If the transaction is a teller transfer then both
accounts must be internal, without a DEPT.ACCT.OFFICER specified.
TELLER transaction will allow the TELLER.ID Field to contain tellers other
than the current user and verify that the side 1 and side 2 currencies are same.
While inputting Till to Till transfer, TELLER.ID.1 and TELLER.ID.2 Fields are
used to indicated from which till to which till transfer is to take place. In all
other transactions, both these fields will indicate the TELLER.ID of the current
user only.
In respect of customer account transfer, it is possible to restrict the transaction for
customer account only. CUST.AC.TRANSFER Field must be set as yes, then
both sides of a transaction must be only customer accounts.
If the transaction is a customer transfer then both sides must be a customer
account. If the transfer is between different customers, then override has to be
approved.

T3TTT - Teller - R10.1

22

It is possible to scan and store Customers signature through


IMAGE.MANAGEMENT application. Scanned signature is displayed in various
applications like TELLER, FUNDS TRANSFER etc.
When a customer account is debited, then on input of account number, signature
of the customer is displayed. VERIFY.SIGNATURE Field specifies whether this
transaction will display the customers signature on input of the account number.
If set to YES then a signature will be displayed when debiting a customer
account, if the VERIFY.SIGNATURE is set to Yes and the signature is not
displayed due to absence of the same, due approval of override is required. If set
to NO, no such override is required.

T3TTT - Teller - R10.1

23

For performing Teller operations, tills are opened and allotted to Users.
TELLER.ID application is used to open tills, assign users to tills, close and
balance tills. Id for this application, is a 4 digit number. This is called Till
number or Tellers Id. Vault is also a till and a number, generally 9999, is
reserved for this and defined in TELLER.PARAMETER. It is possible to define
more than one vault in the system, and the remaining numbers can be used for
other tills. A Vault is differentiated in TELLER.ID by its status. It is neither
open nor closed and the status has a null value.
Even though the vault is not opened or closed or balanced like the other tills, but
transfers to and from the vault can still take place. For records created for vault,
STATUS Field and USER Field should be left blank.
Vault should be loaded initially using the DATA.CAPTURE system to transfer
the cash to the vault account.
For other tills a user can only perform transactions on a till if the till is open and
user is assigned to that till. When closing a till the user is requested to enter the
current cash amounts which are checked against the system balances. If any
discrepancy is discovered an override allows the system to balance automatically
by posting to the over or short accounts.

T3TTT - Teller - R10.1

24

It is possible to issue passbooks instead of statements to accounts duly defined in


ACCOUNT.CLASS as SAVINGS. For those accounts, PASSBOOK Field
should be set as YES in the respective accounts. TELLER.PASSBOOK
application to be set up for designing the passbook and ATTRIBUTE Field to link
printer attribute.
PASSBOOK.DEVICE Field of TELLER.ID application to indicate which printer
device is connected to this TELLER.
Id of PRINTER.ID application to be indicated in the PASSBOOK.DEVICE.
Passbook updating will take place only if these fields and files have been suitably
set up.
For example if we have a Passbook printer such as the Siemens High Print 4905
which needs a set of initialisation sequences to set the font, spacing etc we would
set the following values as under
APPLICATION PRINTER.ID Application ID Field SIEMENHP
TELLER.ID Application PASSBOOK.DEVICE Field SIEMENHP
TELLER.PASSBOOK Application ATTRIBUTE Field INIT
PRINTER.ATTRIBUTES Application ID Field SIEMENHP.INIT
Passbooks are updated by Teller using Function Verify in
TELLER.PASSBOOK.UPDATE

T3TTT - Teller - R10.1

25

Format for passbook can be defined in TELLER.PASSBOOK table used to define


the format of the data output on a savings account passbook. One record allowed
in this file, "SYSTEM".
Details of what is to be printed will be defined as under:
If it is for issue of new passbook, then it should indicate customers name and
address.
If it is for a new page to be printed then it should be set as balance brought
forward.
If it is an entry to be printed , it should mention transaction amount, debit or
credit column, balance etc.
Last line of the page could print balance carried forward.
When the last page of the passbook is printed it could indicate new pass book
issued message.

T3TTT - Teller - R10.1

26

The data printed can be any field from the following files:
ACCOUNT, CUSTOMER, COMPANY, TRANSACTION, CURRENCY,
ACCOUNT.STATEMENT, STMT.ENTRY, CATEGORY,
DEPT.ACCT.OFFICER. Any free format text or one of the following could be
used for printing.
CREDIT

positive amount from the entry

DEBIT

negative amount from the entry

BALANCE

new account balance

TODAY

todays date

TELLER.ID the current teller id

T3TTT - Teller - R10.1

27

T3TTT - Teller - R10.1

28

TELLER application is meant for retail cash operations.


Teller operations handle both local currency and foreign currency transactions.
Cash deposits and withdrawal, foreign currency buying and selling, account to
account transfer, sales or purchase of travellers cheques and cheques sent for
collection can be handled through TELLER application. It is also possible to
transfer cash from one teller to another for operational requirements in addition
to transfer cash from Vault to Tellers.
Teller operations affect Customer Accounts, Internal Accounts and Profit and
Loss items. Cash is an internal account and any cash transaction done by a Teller
will affect Cash account. When a customer is paid cash or when cash is received
from a customer for credit to account, customers accounts are affected. It is
possible to take charges for some operations. When foreign currency is bought or
sold, banks take currency handling charges and commission.
Head Teller operations and other Tellers are covered under TELLER application.
TELLER.ID application is used to open and close Tills. All other Teller
operations are handled through TELLER. Passbook updated through
TELLER.PASSBOOK.UPDATE.

T3TTT - Teller - R10.1

29

For performing Teller operations, tills are opened and allotted to users.
TELLER.ID is the application which is used to open till, assign user and balance
the till on closing. Id for this application, is a 4 digit number. This is called Till
number or Tellers Id. Vault is also a till and a it is a four digit number, defined in
TELLER.PARAMETER. It is possible to define more than one vault in the
system, and the remaining numbers can be used for other tills. A Vault is
differentiated in TELLER.ID by its status. It is neither open nor close and the
status has a null value. All other tills are opened before commencing teller
operations and closed once the operations are completed.
Each till has to be opened initially and a user assigned to the till by specifying the
user Id. A user can perform transactions on a till only if the till is open and he is
assigned to that till. A user cannot be assigned to more than one open till at any
time, unless special arrangements are made for multi tills. If necessary, a new
user can be assigned to the existing till by changing user Id suitably. Thereafter,
the new user can continue with operations of the till.
In line with accounting rules, cash account is debited while receiving. Hence if
the balance with a Teller is negative, then Teller is having that amount. At times,
without adequate cash, a Teller may input a transaction to pay out cash. T24
generates override that Till is having credit balance. Teller can then receive cash
from vault or another till and then physically effect payment. Previous record
need not be deleted on seeing the override.

T3TTT - Teller - R10.1

30

Transfers between two tills can be done any time intraday to meet cash needs.
Ids of till from where cash is transferred and the till which receives it are to be
indicated.
Amount and currency of cash transfer should also be specified to complete the
transaction.
T24 maintains internal account for cash or currency and till wise. USD currency
cash with Teller 1347, GBB currency cash with Teller 7354 etc. Hence, it will
suitably debit the account of receiving till and credit the account of giving till.
Before opening or closing a till in a Bank, it is a common practice to transfer
funds from vault to till or from a till to vault by the tellers. Transactions are
authorised through Head Teller operations.

T3TTT - Teller - R10.1

31

T3TTT - Teller - R10.1

32

T3TTT - Teller - R10.1

33

Different currency markets can be used for example, one for cash transactions
and another for account to account transfers. TELLER application automatically
defaults the buying or selling rate suitably depending upon the nature of
transactions. Debit currency is the buy and the credit currency is the sell. For
example when the local currency is used for a foreign currency brought, then buy
rate for the foreign currency is defaulted. When local currency is used foreign
currency sale, then the sell rate is defaulted for the foreign currency.
Difference between the above buy rate or sell rate and the middle rate can be
calculated by T24 as profit or loss for the Teller Department for foreign exchange
transactions, assuming middle rate is the Treasury rate. This profit or loss is
booked as the marketing exchange profit or loss.
It is possible to opt to waive charges or not to waive for a Foreign Currency sale
transaction. If it is opted not to waive, then T24 calculates and takes charges as
pre set for that transaction. For example, for foreign currency sale transactions,
we could set that charges to be taken at 0.10%. Normally charges are waived for
Foreign currency bought transactions. Currency exchange feature can be handled
for both customers and non customers. This includes walk-in customers too.

T3TTT - Teller - R10.1

34

T3TTT - Teller - R10.1

35

T3TTT - Teller - R10.1

36

T3TTT - Teller - R10.1

37

T3TTT - Teller - R10.1

38

TELLER application processes all cash transactions. Each and every type of
transaction is suitably pre-defined in TELLER.TRANSACTION and suitable
version created to guide the end user to key in only minimal input. There are two
sides to each transaction (1) the input side and (2) the balancing side. Input for
each transaction can be designed in TELLER.TRANSACTION such that the user
inputs one side of the transaction and the system generates the other side
automatically for balancing. This is possible where cash is the other side of
transaction. For example: to accept a deposit of local currency cash, it is enough
for user to give the cash amount and the customers credit account. T24 takes
care to automatically debit USD cash account where USD is the local currency.
Credit is done according to user input.
In case of withdrawals, cheque number has been made mandatory. Along with
cheque number, cheque type is also to be mentioned. Cheque type could vary as
per set-up, like CURR for current accounts, SB for savings accounts etc. When
a cheque type is not mentioned and only a cheque number is mentioned, T24
generates override to indicate absence of cheque type. If duly approved,
transaction goes through.
Denominations of each currency that the Bank would deal in, has already been
set up. Those denominations appear according to currency. Here, for local
currency transactions, denominations of USD appear, which have to be duly
filled according to actual cash receipt. Receipt should match the credit amount.

T3TTT - Teller - R10.1

39

The above functions are available from the teller section of the main menu,
although this may vary, depending on the individual users menu options.

40

41

The hot fields find the values and display these in the no input fields.
The cash deposit, cheque deposits (with and without clearance) and laser card
deposits function in a similar way, the exception is the debit accounts cheques:
nostro, laser card: control account.

42

The hot fields find the values and display these in the no input fields.
The cash deposit, cheque deposits (with and without clearance) and laser card
deposits function in a similar way, the exception is the debit accounts cheques:
nostro, laser card: control account.

43

The split deposit in cash and cheque with and without savings function in a
similar way, exceptions are the debit accounts cash, internal account, or cheque,
nostro account.
It is important for the phantom to be active when processing split deposits as the
phantom generates the FT transactions:
The amount entered in the Total Amount field will be split according to the
values in the Loan Repayment and Interest Repayment fields, these amounts may
be amended. The total amount is credited to account 10383 and debited to cash
account of the processing teller. The share account, 10383 is then debited with
the loan repayment and interest repayment amounts (two separate entries), both
amounts are credited to the loan account and finally the loan is debited and the
interest account credited with the interest repayment amount. This is to provide a
transparent trail of transactions.
The split processing will only be effective if the account mnemonics are assigned
as prescribed. See the Accounts Manual and AZ Loans Manual for more
information.

44

AZ Loan Accounts that have been written off using the procedures as developed
in T24forMCB, the account will have a mnemonic starting and ending in W. The
number between the Ws is the old/written off account. In this example, Account
W10413W of category 1150 is now account 11983 of category 8001.
It is important that the phantom be active when processing deposits (cash or
cheques) to written off accounts, as the phantom creates the FT transactions as
follows:
Cr 11983
Dr Cash account/Nostro
Cr Bad Debt Recovered PL
Dr Contingent Control Account

45

46

47

Should your institution make use of continuous cheque forms that are fed into a
dedicated cheque printer, these cheque numbers are captured daily in the
Administrator Menu>>Maintaining Tables>>Cheque Register. Each teller is then
assigned to a cheque register, when the cheque withdrawal is processed, the
system will find the cheque printer and then next available cheque number. This
cheque withdrawal version will be populated with the cheque number once the
record is committed. This procedure prevents the incorrect capture of cheque
details and therefore supports reconciliation of the nostro account.
Also note that the nostro account is in a no-input field. The version finds the
account number from the agency table, this is configured during implementation.

48

49

In this application, we have an agreement with SUPERMARKET to bring us


their bulk cash and in turn we provide them with a cheque to the same value, or
we may deduct charges for our effort.
The accounts involved are the cash account of the teller receiving the cash and
the nostro account against which the cheque is drawn.
The cheque number is populated from the Cheque Register. See notes to Cheque
Withdrawal earlier in this pack.

50

In this example, a cheque is presented for encashment, without processing


through a customer account. The entries are credit nostro and debit cash account
of the teller.
Enter the Cheque Number, Sort Code, Cheque Account Number and Drawer
Name as recorded on the cheque form. This information may be of value should
this cheque be lost in transit between the bank/s and clearing house.

51

T3TTT - Teller - R10.1

52

When selecting the Loan Ref Number which is created when the loan is approved
in the TELLER.DEFAULT table, the system populates all relevant fields. See the
available balance is USD 600,000, we are going to disburse only USD400,000 in
cash.
By entering the Loan Application Reference, we set the loan application status to
disbursed. This is an important step.

53

When entering the Drawn on Account number, the routine associated with this
hot field finds the available balance. The user is not able to withdraw more than
what is available from the account. Attempt to and see the error messages.
Once the record has been committed, you are able to view the Cheque Number
which has been populated from the Cheque Register as discussed in Cheque
Withdrawal earlier in this training session. Once more the Nostro account is
defaulted in the screen from the agency table.

54

It is possible to handle two different foreign currencies as two sides of a teller


transaction. Both the debit and credit currencies could be foreign currencies.
TELLER.TRANSACTION record for that type of transaction should have been
set up suitably to enable this. Likewise, both sides could be cash accounts or one
side customer account and the other cash, or the User may be given freedom to
choose each side in any desired way. When both sides are foreign currencies,
T24 defaults the cross currency rate for the transaction automatically.
When transferring money between accounts, it is also possible to manually input
a value date for debit or credit. T24 always defaults system date as value date.
Value date is significant from interest calculation point of view.
When a transaction takes place on 10th of a month, if a debit of USD 10,000 is
valued on 9th, then the balance in the account is treated as less by USD 10,000 on
9th itself for interest calculation purpose. When the interest is calculated on daily
balances, then balance of 9th is considered to be USD 10,000 less than what it
actually was.
In the same way, if the value date for a credit is after one day, then though the
account has got credit on the same day, for interest calculation purposes, its
balance has not changed that day and only on the next day it is considered to
have gone up by credit amount.

T3TTT - Teller - R10.1

55

Different currency markets can be used for example, one for cash transactions
and another for account to account transfers. CURRENCY table holds the
exchange rates for each currency in all the markets required. TELLER
application automatically defaults the buying or selling rate suitably depending
upon the nature of transactions. Debit currency is the buy and the credit currency
is the sell. For example when the local currency is deposited into a foreign
currency account, then the sell rate for the foreign currency is defaulted. When
local currency is withdrawn from a foreign currency account then the buy rate is
defaulted.
Difference between the above buy or sell rate and the middle rate can be
calculated by T24 as profit or loss for the Teller Department, assuming middle
rate is Treasury rate. This profit or loss is booked as the marketing exchange
profit or loss. If a bank does not want to follow this, it need not opt for this
choice. In that case, Teller departments exchange profit or loss will not be
separately worked out.
It is possible to opt to waive charges or not to waive them for any particular
transaction. If it is opted not to waive, then T24 calculates and takes charges as
pre set for that transaction. For example, local currency cash deposit into a
foreign currency account, we could set that for amounts up to USD 25,000, no
charges are to be taken and 0.5% is to be taken for amounts beyond.

T3TTT - Teller - R10.1

56

57

Foreign Currency Withdrawals and Deposits are processed in a similar way.


The Charge amount is defined in FT.CHARGE.TYPE and assigned to the
TELLER.TRANSACTION. This is a no-input field, bit could be opened at
implementation for authorised users to modify the charge amount.
The currency rate is defaulted from the CURRENCY table, and may be
overwritten in the Deal Rate field. The system populates both fields. The
transaction will processed using the rate in the Deal Rate field. This may be used
for special customers or staff accounts.

58

T3TTT - Teller - R10.1

59

T3TTT - Teller - R10.1

60

Travelers cheques processing could happen under two situations. One is Client
issuer of travelers cheques and the other is client who is not the issuer of
Travelers cheques, but uses travelers cheques issued by others.
Client required to record the amount or denomination or serial numbers of
Travelers Cheques issued to counterparts like Agents as well as own customers.
Handling Travelers cheques is similar to handling operations of other internal
accounts.
.

T3TTT - Teller - R10.1

61

It is necessary to create separate CATEGORY codes for Travelers cheques stock


control and Travelers cheques contra accounts.
If separate CATETORY codes for each issuer of Travelers cheques is assigned,
it will facilitate to keep track separately.
TELLER.TRANSACTION records for various types of Travelers cheques
related events are created like procurement, sale and till transfer of Travelers
cheques etc.
Suitable CURRENCY.MARKET, TRANSACTION records are to be created
and used. For each issuer as narration in statements may differ indicating issuer
name, separate transaction codes may be created.
TELLER.DENOMINATION records to be created currency and denomination
wise if required in TELLER application.

T3TTT - Teller - R10.1

62

Generally internal accounts are opened only in local currency. System


automatically opens them in foreign currencies as and when needed.
But, in this case, it is advised to open manually without relying on the System, in
all Foreign currencies, to enable having a control over Stock control type and
Serial number. STOCK.CONTROL.TYPE Field in such internal account has 3
options NULL, DENOM and SERIAL. If DENOM is indicated, then Teller has
to indicate denomination while inputting transaction. If SERIAL is indicated then
serial number as well as denomination is mandatory while inputting transactions.
SERIAL.NO.FORMAT is mandatory if SERIAL is chosen.
Serial Number format can have a mix of A,N, X, and . where A is any Alpha
character, N is Numeric character, X is Alpha numeric and . a separator.
For defining the format, it is necessary that at least one A to be defined next to
the Ns if the Ns are not defined either at the beginning or at the end. The
standard format of Serial Number is AA.NNN.NNN.NNN.
Mask character . can only be defined with the Ns. It is also mandatory to
define at least one N character in the format.
Care should be taken to set the Serial number format to exactly match with the
numbering pattern of the Travelers cheque stock received. This is required as the
Serial number format entered in a transaction input by Teller will be matched
with the format entered here.

T3TTT - Teller - R10.1

63

System maintains internal file called TT.STOCK.CONTROL with details of


available TC stock, Denomination and Serial numbers. Account number is
relating to the till. This will be an internal account which will be composed of
CCY : CATEGORY : DAO or Teller ID or Vault ID.
It is necessary to open internal accounts for Travelers Cheque contra in currency
of Travelers Cheques, issuer wise, for Travelers cheques stock control using
VAULT.ID .
According to accounting requirements, either single contra account for all issuers
or different account for each issuer can be opened. If issuer specific contra
accounts are maintained, this would help in proper reporting of liabilities. In the
case of contra accounts STOCK.CONTROL.TYPE and SERIAL.NO.FORMAT
Fields are left blank.

T3TTT - Teller - R10.1

64

Teller module handles Travellers cheque processing of both issue and purchase
of Travellers Cheques.
Stock of Travellers cheques is indicated as balances in an Internal Account. For
example category 10905 is used for issue of Travellers Cheque and category
10090 is used for Purchase.
STOCK.CONTROL.TYPE Field is set to SERIAL and SERIAL.NO.FORMAT
is defined as AA.NNN.NNN.NNN in internal account EUR10905999900001.
T24 handles various types of Travellers cheque related events. For example
receipt of TC stock from other banks, transfer from the vault to till, and the actual
issue of TC.
Travellers Cheques issued by any bank can be purchased and there is no control
for serial numbers during purchase.

T3TTT - Teller - R10.1

65

In the internal account for TC stock vault id 9999 to be used and contra to record
receipt of stock at vault. When stock is transferred to another branch, our stock
to be reduced. Separate version is available for such transfer. Vault Id is used in
both internal accounts.
When stock of Travelers Cheques is transferred from Vault to Till, Vault stock is
reduced and stock at Till increased. Contra is not affected. Vault id and Till id
to be used in internal account for TC stock alone.

T3TTT - Teller - R10.1

66

Travellers cheques can be issued in two ways. They can be sold against cash or
against debit to customers account in any currency. Separate versions are
designed to record sale of Travellers Cheques against cash and against account.
Internal account for the Till for TC stock to be used.
Generally, at the end of every day, or at agreed periodic intervals, funds are
remitted to the Travellers Cheque issuer for the sales effected. Option to record
such transaction is available under Head Teller operations.
Proceeds of the TC issue needs to be transferred to the TC issuer through
NOSTRO account or any other arrangement at the end of the day or at agreed
intervals .
Internal account for TC contra for the vault will be debited and funds remitted as
instructed.

T3TTT - Teller - R10.1

67

Travellers cheques of other issuers can be bought in two ways. Either it can be
bought against cash or through credit to Customers account in any currency.
Separate versions are designed to record buying of Travellers Cheques bought
against cash and through customers account. Predefined category 10090 is used
for TC bought. If internal accounts are opened for each issuer, it is possible to
keep track of TCs bought.
Internal account for the Till for TC bought to be used.
Internal account for TC contra for the vault will be debited and funds remitted as
instructed.
Version designed to buy TC against Local Currency cash.

T3TTT - Teller - R10.1

68

69

The TC Stock Control and TC Contra Accounts are defaulted in the version.
Multivalue the fields against the denomination and record the number of each
TC. These may not necessarily run in sequence.

70

On entering the number of units against the denomination, the system populates
the TC Serial numbers from the TCs taken into stock. Check the numbers of the
physical cheques against the screen. This functionality supports reconciliation of
stock held in teller drawers. Should number of units be entered where there is no
or insufficient stock, the user will receive a message to the effect.

71

When purchasing TCs back/or from customers, the number of units are recorded
but not the serial numbers as these TCs are now effectively presented and cannot
be re-negotiated, hence no provision is made for the user to capture serial
numbers. These TCs are returned to the Senior Teller with other cheques and the
institution receive cash reimbursement from agent bank or TC company, Thomas
Cooke or American Express.

72

T3TTT - Teller - R10.1

73

T3TTT - Teller - R10.1

74

A Bank Draft is a Cheque drawn in a currency that is not the local currency of the
institution. When entering the Currency of the transaction, the routine associated
with the hot field finds the Draft Control Account, this is the account that will be
credited with the transaction amount less the charges/commissions, the customer
account is debited and the P&L is credited with the charges/commissions. The
charge/commission is levied in the currency of the customer account, hence
despite the transaction currency being EUR, the commission currency is USD.

75

76

At the end of the day, all the tills are closed after transferring cash with Tellers to
Vault. Some Banks may permit petty cash to be held with the Teller. Closing of
Till involves physical cash counting, balancing it with T24. Till wise balances,
compensating for shortages or Bank allowing minor overages and shortages by
transferring that to separate accounts and physical closing of tills. Cash held by a
teller is either transferred to other tills or vault before closure.
Closing a till allows the teller to balance the actual contents of the till against the
balance held by T24. While closing, teller has to input the till balance in each
currency and this is compared with currency wise balance maintained by T24.
Difference, if any, between cash on hand and what it should be is indicated by
T24. If approved, this amount is transferred to internal account as Cash overage
or Cash shortage.
Next day, the till could be again allotted to the same Teller or to some other
Teller.

T3TTT - Teller - R10.1

77

T3TTT - Teller - R10.1

78

T3TTT - Teller - R10.1

79

T3TTT - Teller - R10.1

80

T3TTT - Teller - R10.1

81

T3TTT - Teller - R10.1

82

T3TTT - Teller - R10.1

83

In a Teller transaction, side 1 input through TELLER application has a facility to


multi value ACCOUNT.1, AMOUNT.LOCAL.1, AMOUNT.FCY.1 and
NARRATIVE.1 Fields. For example, if a single cheque is deposited for credit to
three accounts, this can be done by multi valuing credit account and amount.
Currency must be the same and all the three accounts should belong to the same
customer. No cross currency is allowed. Multi valued accounts can also include
internal accounts. However CUSTOMER.1 and CURRENCY.1 are single value
Fields. Hence it is possible to effect multiple credits or debits by using side 1 as
long as the Currency and Customer are same. Since multi valuing is permitted
only on side1, suitable TELLER.TRANSACTION records have to be defined
with transaction codes, currency and type of accounts that are to be Multi valued
and separate versions are created.
Charge levied on any of the TELLER transaction, wherein either the credit or the
debit side is multi valued, is collected from the first account and the account is
defaulted in CHARGE.ACCOUNT.
In the case of multi line TELLER transactions, in each leg of transaction, the
ACCOUNT.NUMBER can be multi valued as per the details defined on side1, of
the TELLER.TRANSACTION.

T3TTT - Teller - R10.1

84

TELLER.PARAMETER to be used to allow Multi till and to indicate maximum


number of tills for a user. If MULTI.TILLS Field is yes, then MAX.TILLS
Field is a mandatory input. Through Multi Tills functionality two or more tills
for a user is made available. Any numeric, between 1 to 99 can be input in
MAX.TILLS Field. It represents the number of tills a user can keep open at any
given time when dealing with the Multi Tills facility. If multi tills is Yes and this
field is input as 3, it means any user can have a maximum of 3 tills open at any
point of time. Input in this field can be changed at any time. Once changed the
new input will be effective and earlier validations will become null and void.
For example if Max tills is input as 3 and then changed to 2 any intention to input
more than 2 tills subsequently will be met with the error message Other tills
must be closed.
The concept of Linked Tills is introduced in Multi Tills to facilitate linking two
or more tills belonging to a particular user and automatically opening the linked
tills, when the Master Till is opened. TELLER.ID to be set up for the Main Till
and to indicate Ids of linked tills in Multi Field LINKED.TILLS. All the linked
tills should belong to the same User. System opens linked tills automatically
whenever the Main till is opened. Closing of Tills to be done individually.
TILL.TFR.ONLY Field can be set to Yes if it is intended to use this TELLER.ID
only for Till to Till transfer. At transaction level, the till used to log into
TELLER application is automatically defaulted unless changed at application
level.

T3TTT - Teller - R10.1

85

Under normal circumstances, one user is allotted one TELLER.ID. But Multi
Tills feature enables a single user to have more than one TELLER.ID. Number of
ids is depending on the set up enunciated in TELLER.PARAMETER application.
At the start of day, cash is transferred from vault to Master Till. Multi Tills
contain a limited amount of cash transferred from the Vault. Whenever there is a
shortage of cash instead of drawing from the Vault, cash is transferred from the
MULTI TILLS. On the contrary if the till cash balance exceeds the permissible
limits, then it is transferred to MULTI TILLS. This will eliminate operating of
the vault frequently. In short, we can call the Multi Tills as an intermediary
between the Vault and the till.
At the end of the day, all tills can be closed and cash transferred back to vault.

T3TTT - Teller - R10.1

86

For all debit/credit entries to accounts passed through TELLER, STMT.ENTRY


are generated. For PL category transactions CATEG.ENTRY are generated. PL
heads include Interest, Charges and Commission.
It is possible to split entries for Charges and Tax from Debit/Credit transactions
amount by suitable choice in TELLER.TRANSACTION.
TRANSACTION codes specified through TELLER.TRANSACTION.
It also used transaction codes defined for FT.COMMISSION.TYPE.
When transactions are marked for DATA.CAPTURE usage, it is possible to
indicate Exposure date rules for credit entries and value date rules for all entries.
When these transaction codes are used in TELLER, then these rules are
automatically made applicable here also. This can be manually changed at the
transaction level.

T3TTT - Teller - R10.1

87

Deal slips can be printed by the Teller for any transaction across the counter. Ids
of DEAL.SLIP.FORMAT to be printed for a transaction are attached through
ADVICE.VERSION in TELLER.TRANSACTION multi value Field.
These deal slips are generated when the Teller hits the PRT.HOT.KEY defined in
TERMINAL record.
If the Teller omits this then an override is generated.
TELLER.PASSBOOK.UPDATE application used with verify functions to print
passbooks. Passbooks are issued for SAVINGS class of accounts defined in
ACCOUNT.CLASS application. The account is marked for passbook in
ACCOUNT application.

T3TTT - Teller - R10.1

88

Teller application maintains the denomination of currencies and the quantity held
by each teller.
As soon as a Teller opens his till, an internal account would be created with Id as
Currency-Category Code-Teller Id (For example, USD100013333).
TT.STOCK.CONTROL file maintains the records for the cash held by tellers.
In real situation, the actual denomination of cash held by the teller needs to be
input by physically verifying so that system cross checks.
We can use TT.STOCK.CONTROL in command line, go to the record with the Id
belonging to the teller to view the denomination held.
Till R.10, T24 did not cater to record the exchange of currency notes from Teller
to customer during cash deposit and vice versa during cash withdrawal
transaction. Every teller transaction updated the TT.STOCK.CONTROL with the
number of denomination involved in the transaction for that particular TILL, the
default assumption being that in these transactions, the denomination recorded is
exactly equal to the value mentioned in the AMOUNT Field in Teller application.
T24 validated the value mentioned in AMOUNT Field with the sum total of
denomination input. From R.10, T24 would now record the actual Currency notes
involved in the transaction while maintaining the existing validation of checking
that the Net number of denominations/Currency notes entered in Teller
transaction does not differ from the amount specified in the transaction. In case
of a customer deposit, if he wishes to make cash deposit into his account, the
system would inform the Teller, the amount to be paid back and the teller would
be able to enter the denomination he is paying back as a negative amount. To that

T3TTT - Teller - R10.1

89

effect, the field TELLER.DENOMINATION now accepts a negative figure as well. The
transaction when authorised and the payback made, the file TT.STOCK.CONTROL will
get updated accordingly.

T3TTT - Teller - R10.1

89

TELLER application depends on CUSTOMER, ACCOUNT, CATEGORY, and


CURRENCY. Whenever an account is debited the availability of limit is
checked. When Bank takes collateral for a limit, the limit is secured to the
extent of value of collateral. When there is no collateral, the limit is unsecured.
For applying charges to TELLER transactions, the charges are attached from
FT.COMMISSION.TYPE. Preferential group for charges and commissions set
up through APPL.GEN.CONDITION and TT.GROUP.CONDITION application.
TELLER.DENOMINATION table is used to define the denominations used.
TELLER.PARAMETER is the top level table to define the rules of the TELLER
application. TELLER.TRANSACTION application is used to define all the
different types of transactions are set up. TELLER.ID is used to assigns tills and
closure of tills.
Printing of passbooks is done with TELLER.PASSBOOK.APPLICATION
application, DEAL.SLIP.FORMAT table used to define the deal slip format used
for printing deal slips across the counter.
TT.STOCK.CONTROL application used for control of Travelers cheques.

T3TTT - Teller - R10.1

90

91