T3IMBR - Teller - R9.01

T3IMBR - Teller - R9.
01
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.
T3IMBR - Teller - R9.01
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, Travellers 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 Travellers 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 Travellers
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.
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.
When an account is debited, the currency of that account is bought and T24 defaults
buying rate of that currency from CURRENCY table. Similarly, when an account
is credited, the 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. Difference between the buy rate or sell
rate and the middle rate can be calculated in T24 as profit or loss for the Teller
Department, assuming middle rate is the Treasury rate. This profit or loss is booked
as the marketing exchange profit or loss. Input of "NONE" or leaving this field
blank means that no market exchange profit will be calculated during TELLER
transactions. Local equivalent of one of the transactions is calculated and is
assumed to be the local equivalent of the other side. Option "MIDDLE" will
indicate that local equivalents will be calculated using middle rates for
corresponding currency markets. Market exchange profit is then calculated as
difference between LOCAL.AMT.1 and LOCAL.AMT.2 Fields. Profit or loss
arising out of the transaction will be accounted in the PL category indicated
ACCOUNT.CLASS with Ids MKTEXCHCR and MKTEXCHDR.
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 Travellers 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.
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. For
example, a cash deposit of $10000 in a customer account has a charge of $100 . If
SPLIT.CHRG.ENTRIES is defined as YES, accounting entries are:
Debit Cash account
USD10000
Credit Customer account
USD 10000
Debit Customer account for Charges
USD 100
Credit P&L Account for charge
USD 100
If SPLIT.CHRG.ENTRIES were left blank, entries are:
Debit Cash account
USD 10000
USD 9900
USD 100
Multi-line deals allow the user to process multiple transactions before applying
defaults such as minimum commissions. A multi-line deal is comprised of a Master
transaction containing links to each 'child' or 'leg' and controls the overall charges
and accounting of the 'set'. The total of sales is taken into consideration before
applying the minimum commission. For example, the sale of one foreign currency
against local currency. With default charges this could mean that a customer with 3
transactions is charged three times the commission or the Teller has to adjust the
charges manually.
To invoke a multi-line deal instead of using F3 to get the next id you must enter the
character - in place of the id. This will tell the system to use multi-line transaction
ids.
There are a few considerations to take into account when using Multi-line
transactions:
1. There should be only one client in the set of legs comprising the multi-line deal.
2. Charges are calculated taking the Multi-line as a complete unit.
3. Charges can be standard or modified at input time.
4. Deal Slips for Multi-line deals are produced via Enquiries.
5. Only Multi-line deals can use the Copy function.
6. Authorisation, Reversal and Copy is done via the Master Deal only.
In Multi-line transaction deal, when Teller desires to modify charges by inputting a

charge amount instead of System calculated amount, this could be accounted under
a different Category code and by using different Transaction codes than the standard
charge codes indicated in TELLER.TRANSACTION.
MODIFY.CHARGE.CODE Field can be used to indicate another
FT.COMMISSION.TYPE with the required Category and transaction codes. While
the System will use these, it will NOT apply the charge rules or amounts stipulated
in these Codes. Amount input manually will override the defined amounts, if any.
FINISH.ROUTINE Field together with VERSION Field allows local customisation
and validation.
When a Version of TELLER entered in VERSION Field is used in a multi-line deal,
when the 'finish' option is completed, sub-routine specified here is run
automatically.
For multi-line Teller deals, it is possible to set a default at AUTO.NEXT Field so
that when the Teller finishes one leg of a multi-line deal the system automatically
starts a new leg or prompts each time asking whether to create a new one or finish.
Yes indicates that a new leg should be started automatically. NO or blank means the
Teller should be prompted each time.
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.
10
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.
11
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.
12
Currency market from which exchange rates are to be defaulted to side 1 of the
transaction is defined in CURR.MKT.1 Field. By default the system will use
Market 1. Although currency markets have been defined for each side of the
transaction, a default market is needed to be indicated for the entire Teller
transaction, being the rate offered to the Customer.
Side 1 of the transaction is a multi value field when inputting transaction in T24.
For example if amount is withdrawn from one USD savings account and one GBP
current account of a customer then instead of inputting it as two transaction , it can
be inputted as a single transaction. It is not possible to multi value the side 2 of the
transaction.
Similarly the rules are defined for Side 2 in respective fields with suffix 2.
Markets have been defined for each leg for calculating marketing exchange profit .
Rate to be offered to Customer, deal rate is derived from market defined in
DEAL.MARKET Field. If this field is left blank , market defined in CURR.MKT.1
is defaulted. Market to be used for calculating exchange rate for charges is defaulted
into CHARGE.MARKET Field from CURR.MKT.2.
13
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
USD 10000
Debit Customer account for Charges
USD 100
USD 100 otherwise
Debit Cash account
USD 10000
USD 9900
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.
14
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. User will be able 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, transaction for issue of Travellers Cheques, the
denomination is restricted to TC through the DENOM.FILTER.
15
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.
16
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.
17
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.
18
A 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. Credit amount is automatically filled by system
depending on whether any charges are involved in the transaction.
19
20
21
22
23
24
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.
25
Retail home page has custom set of menus/enquiries required by a Retail user to carry on the
day to day operations. Home Page will help the User to process Teller transaction, view the
customer details, input transactions and view/create opportunities for the customer. Home
Page is designed to assist the Head Teller in authorising transactions, to view enquiries and
delivery messages.
Menus available for Teller for inputting Cash deposit, withdrawal, currency exchange,
Travellers cheque, etc
Components of Remittances Home Page is available in the form of tabs, for easy navigation.
Functionality is provided with essential CRM features for the front end.
26
27
28
29
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.
31
32
33
34
35
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.
36
Travellers cheques processing could happen under two situations. One is Client
issuer of travellers cheques and the other is client who is not the issuer of Travellers
cheques, but uses travellers cheques issued by others.
Client required to record the amount or denomination or serial numbers of
Travellers Cheques issued to counterparts like Agents as well as own customers.
Handling Travellers cheques is similar to handling operations of other internal
accounts.
.
37
It is necessary to create separate CATEGORY codes for Travellers cheques stock

control and Travellers cheques contra accounts.
If separate CATETORY codes for each issuer of Travellers cheques is assigned, it
will facilitate to keep track separately.
TELLER.TRANSACTION records for various types of Travellers cheques related
events are created like procurement, sale and till transfer of Travellers 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.
38
If separate rates are needed for sale of Travellers cheques, a new record to be
created in CURRENCY.MARKET.
If an exclusive market is created quotes for this market to be created in
CURRENCY records for respective currencies of Travellers cheques.
Suitable Versions to be created for procuring Travellers cheques stock, Travellers
cheque sales and Issuer wise. For each till handling Travellers cheques separate
accounts are opened. If it is proposed to default internal accounts, then separate
versions will be needed to be built Issuer wise.
39
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 Travellers 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.
40
System maintains internal file called TT.STOCK.CONTROL with details of

available TC stock, Denomination and Serial numbers. It could be maintained at
Vault level if so opted in TELLER.PARAMETER.
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 Travellers Cheque contra in currency of
Travellers Cheques, issuer wise, for Travellers 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.
41
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.
42
Stock of Travellers Cheques are recorded through Head Teller operations. Version
created for Receipt of Travellers Cheque stock to be used. 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 Travellers 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.
43
44
45
46
47
48
49
50
51
52
53
54
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.
55
56
57
58
59
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.
60
61
62
63
64
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.
65
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.
66
Enquiries are available under Head Teller as well as Teller operations.

Teller wise cash position provides details of currency held by a Teller. Currency
wise cash position for all Tellers displays currency wise cash position of all Tellers
for a single currency. If no selection criteria is given, then list is displayed for all
currencies.
Account Balance displays customer wise list of accounts with balances. Selection
can be given with a customer id or account no. We can drill down to view the
accounting entries for the day or entries since last statement and forward
movements in the account.
Similarly we can run enquires to view TC issue entries and TC buy entries today.
67
68
69

T3IMBR - Teller - R9.01

Încărcat de

Informații document

Descriere originală:

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

T3IMBR - Teller - R9.01

Încărcat de

Drepturi de autor:

Formate disponibile

T3IMBR - Teller - R9.