Senior Teller &Teller R10.pdf

8/19/2019 Senior Teller &Teller R10.pdf

http://slidepdf.com/reader/full/senior-teller-teller-r10pdf 1/93

1



T3TTT - Teller - R10.1 2

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 inlocal 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.




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 buyingand 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, customer’s 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 Bank’s 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.



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, currencyexchange 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 ifthe 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.





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. AsCUSTOMER 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.




Teller operations affect Customer Accounts, Internal Accounts and Profit and

Loss items.

Product code defines the type of the account like savings, current, Nostro, Vostroetc. 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

customer’s 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 codesfor such profit and loss items used is 50000 and above.




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.




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 bechanged 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.




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.




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 isdefined, 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.




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, thecategory 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 Bank’s 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 transactionsallowed 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, 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 Buy Rate Sell RateGBP 1.96 1.9346 ------

EUR 1.315 ----- 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.




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 inexcess 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 avalid 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 debittransaction 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.



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 CLOSINGBALANCE, 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 ateller 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.





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, thenMULTI.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 cankeep 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.




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, butsystem ensures that they are always contra.




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 theinternal 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.




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 ofTELLER 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 otherwiseDebit 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.




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. Whenthis 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 isnot 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.




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 bothaccounts 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.




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.




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 Tillnumber or Teller’s 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.




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.PASSBOOKapplication 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




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 customer’s 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 bookissued message.




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 today’s date

TELLER.ID the current teller id




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 toaccount 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, customer’s 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.




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 Tillnumber or Teller’s 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 newuser 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.




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.




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 oftransactions. 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.




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 twosides 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 customer’s 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.



40

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



41



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 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.



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 W’s is the old/written off account. In this example, AccountW10413W 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 thenassigned 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



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 incash.

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 beenset 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.




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. TELLERapplication 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 thischoice. In that case, Teller department’s 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.



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 atimplementation 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




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.

.




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.




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, inall 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 ‘N’s if the ‘N’s are not defined either at the beginning or at the end. Thestandard format of Serial Number is “AA.NNN.NNN.NNN”.

Mask character ‘.’ can only be defined with the ‘N’s. 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.




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 ofCCY : 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.




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. Forexample 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.




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.




Travellers cheques can be issued in two ways. They can be sold against cash or

against debit to customer’s 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.




Travellers cheques of other issuers can be bought in two ways. Either it can be

bought against cash or through credit to Customer’s account in any currency.

Separate versions are designed to record buying of Travellers Cheques boughtagainst 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.



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 TC’s taken into stock. Check the numbers of the

physical cheques against the screen. This functionality supports reconciliation ofstock 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 TC’s back/or from customers, the number of units are recorded

but not the serial numbers as these TC’s are now effectively presented and cannot

be re-negotiated, hence no provision is made for the user to capture serialnumbers. These TC’s 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



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 becredited 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.




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 tothree 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 thedebit 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.




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 tillsfor 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 twoor 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.




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.




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.




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.



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 asCurrency-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 thenumber 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




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.





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 theextent 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.APPLICATIONapplication, 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.

Senior Teller &Teller R10.pdf

Documents

Transcript of Senior Teller &Teller R10.pdf