Senior Teller &Teller R10.pdf

1

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

T3TTT - Teller - R10.1

2

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

T3TTT - Teller - R10.1

3

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

T3TTT - Teller - R10.1

4

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

T3TTT - Teller - R10.1

5

Teller operations affect Customer Accounts, Internal Accounts and Profit and Loss items. Product code defines the type of the account like savings, current, Nostro, Vostro etc. For customer type of accounts the category code should be between 1000 and 9999. When a customer is paid cash or when cash is received for the credit to 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 codes for such profit and loss items used is 50000 and above.

T3TTT - Teller - R10.1

6

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

T3TTT - Teller - R10.1

7

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

T3TTT - Teller - R10.1

8

T3TTT - Teller - R10.1

9

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

T3TTT - Teller - R10.1

10

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

T3TTT - Teller - R10.1

11

TELLER.PARAMETER is the top level parameter file used for the teller system. It defines the category and transaction codes to be used for balancing tills, the category to be used for cash, rounding details for local currency, vault id etc. Rules can be set company wise and Id is Company code. Vault related information is entered through VAULT.ID and VAULT.DESC Fields. Vault is where 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 transactions allowed are transfers to and from the teller cash accounts. Vault should be entered here before entering the id on the TELLER.ID file. In T24, a Vault is identified with a 4 digit number. If present on the TELLER.ID file then the status and user fields must be null. Description of the vault in VAULT.DESC Field is used as online enrichment on transaction. This will be displayed whenever a vault is entered into TELLER, for performing transfers etc.

T3TTT - Teller - R10.1

12

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

Mid Rate

GBP

1.96

EUR

1.315

Buy Rate

Sell Rate

1.9346

------

-----

1.32

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

T3TTT - Teller - R10.1

13

T3TTT - Teller - R10.1

13

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

T3TTT - Teller - R10.1

14

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

T3TTT - Teller - R10.1

15

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

T3TTT - Teller - R10.1

16

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

T3TTT - Teller - R10.1

17

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

T3TTT - Teller - R10.1

18

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

T3TTT - Teller - R10.1

19

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

USD 10000

Credit Customer account

USD 10000

Debit Customer account for Charges

USD 100

Credit P&L Account for charge

USD 100 otherwise

Debit Cash account

USD 10000

Credit Customer account

USD 9900

Credit P&L Account for charge

USD 100

For printing deal slips, PRINT.ADVICE Field to be set as yes. ADVICE.VERSION Field defines entry on DEAL.SLIP.FORMAT file which specifies the format of the advice. Multiple advices can be produced, although, this is only available for DEAL.SLIP.FORMAT advices.

T3TTT - Teller - R10.1

20

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

T3TTT - Teller - R10.1

21

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

T3TTT - Teller - R10.1

22

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

T3TTT - Teller - R10.1

23

For performing Teller operations, tills are opened and allotted to Users. TELLER.ID application is used to open tills, assign users to tills, close and balance tills. Id for this application, is a 4 digit number. This is called Till number or 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.

T3TTT - Teller - R10.1

24

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

T3TTT - Teller - R10.1

25

Format for passbook can be defined in TELLER.PASSBOOK table used to define the format of the data output on a savings account passbook. One record allowed in this file, "SYSTEM". Details of what is to be printed will be defined as under: If it is for issue of new passbook, then it should indicate 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 book issued message.

T3TTT - Teller - R10.1

26

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

positive amount from the entry

DEBIT

negative amount from the entry

BALANCE

new account balance

TODAY

today’s date

TELLER.ID the current teller id

T3TTT - Teller - R10.1

27

T3TTT - Teller - R10.1

28

TELLER application is meant for retail cash operations. Teller operations handle both local currency and foreign currency transactions. Cash deposits and withdrawal, foreign currency buying and selling, account to account transfer, sales or purchase of travellers cheques and cheques sent for collection can be handled through TELLER application. It is also possible to transfer cash from one teller to another for operational requirements in addition to transfer cash from Vault to Tellers. Teller operations affect Customer Accounts, Internal Accounts and Profit and Loss items. Cash is an internal account and any cash transaction done by a Teller will affect Cash account. When a customer is paid cash or when cash is received from a customer for credit to account, 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.

T3TTT - Teller - R10.1

29

For performing Teller operations, tills are opened and allotted to users. TELLER.ID is the application which is used to open till, assign user and balance the till on closing. Id for this application, is a 4 digit number. This is called Till number or 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 new user can be assigned to the existing till by changing user Id suitably. Thereafter, the new user can continue with operations of the till. In line with accounting rules, cash account is debited while receiving. Hence if the balance with a Teller is negative, then Teller is having that amount. At times, without adequate cash, a Teller may input a transaction to pay out cash. T24 generates override that Till is having credit balance. Teller can then receive cash from vault or another till and then physically effect payment. Previous record need not be deleted on seeing the override.

T3TTT - Teller - R10.1

30

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

T3TTT - Teller - R10.1

31

T3TTT - Teller - R10.1

32

T3TTT - Teller - R10.1

33

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

T3TTT - Teller - R10.1

34

T3TTT - Teller - R10.1

35

T3TTT - Teller - R10.1

36

T3TTT - Teller - R10.1

37

T3TTT - Teller - R10.1

38

TELLER application processes all cash transactions. Each and every type of transaction is suitably pre-defined in TELLER.TRANSACTION and suitable version created to guide the end user to key in only minimal input. There are two sides to each transaction – (1) the input side and (2) the balancing side. Input for each transaction can be designed in TELLER.TRANSACTION such that the user inputs one side of the transaction and the system generates the other side automatically for balancing. This is possible where cash is the other side of transaction. For example: to accept a deposit of local currency cash, it is enough for user to give the cash amount and the 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.

T3TTT - Teller - R10.1

39

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

40

41

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

42

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

43

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

44

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

45

46

47

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

48

49

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

50

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

51

T3TTT - Teller - R10.1

52

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

53

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

54

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

T3TTT - Teller - R10.1

55

Different currency markets can be used for example, one for cash transactions and another for account to account transfers. CURRENCY table holds the exchange rates for each currency in all the markets required. TELLER application automatically defaults the buying or selling rate suitably depending upon the nature of transactions. Debit currency is the buy and the credit currency is the sell. For example when the local currency is deposited into a foreign currency account, then the sell rate for the foreign currency is defaulted. When local currency is withdrawn from a foreign currency account then the buy rate is defaulted. Difference between the above buy or sell rate and the middle rate can be calculated by T24 as profit or loss for the Teller Department, assuming middle rate is Treasury rate. This profit or loss is booked as the marketing exchange profit or loss. If a bank does not want to follow this, it need not opt for this choice. In that case, Teller 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.

T3TTT - Teller - R10.1

56

57

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

58

T3TTT - Teller - R10.1

59

T3TTT - Teller - R10.1

60

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

T3TTT - Teller - R10.1

61

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

T3TTT - Teller - R10.1

62

Generally internal accounts are opened only in local currency. System automatically opens them in foreign currencies as and when needed. But, in this case, it is advised to open manually without relying on the System, in all Foreign currencies, to enable having a control over Stock control type and Serial number. STOCK.CONTROL.TYPE Field in such internal account has 3 options NULL, DENOM and SERIAL. If DENOM is indicated, then Teller has to indicate denomination while inputting transaction. If SERIAL is indicated then serial number as well as denomination is mandatory while inputting transactions. SERIAL.NO.FORMAT is mandatory if SERIAL is chosen. Serial Number format can have a mix of A,N, X, and ‘.’ where A is any Alpha character, N is Numeric character, X is Alpha numeric and ‘.’ a separator. For defining the format, it is necessary that at least one ‘A’ to be defined next to the ‘N’s if the ‘N’s 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 ‘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.

T3TTT - Teller - R10.1

63

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

T3TTT - Teller - R10.1

64

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

T3TTT - Teller - R10.1

65

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

T3TTT - Teller - R10.1

66

Travellers cheques can be issued in two ways. They can be sold against cash or against debit to 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.

T3TTT - Teller - R10.1

67

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

T3TTT - Teller - R10.1

68

69

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

70

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

71

When purchasing 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 serial numbers. 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

T3TTT - Teller - R10.1

73

T3TTT - Teller - R10.1

74

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

75

76

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

T3TTT - Teller - R10.1

77

T3TTT - Teller - R10.1

78

T3TTT - Teller - R10.1

79

T3TTT - Teller - R10.1

80

T3TTT - Teller - R10.1

81

T3TTT - Teller - R10.1

82

T3TTT - Teller - R10.1

83

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

T3TTT - Teller - R10.1

84

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

T3TTT - Teller - R10.1

85

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

T3TTT - Teller - R10.1

86

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

T3TTT - Teller - R10.1

87

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

T3TTT - Teller - R10.1

88

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

T3TTT - Teller - R10.1

89

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

T3TTT - Teller - R10.1

89

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

T3TTT - Teller - R10.1

90

91