Teller - User Guide: Release - R18AMR

Teller - User Guide
Release - R18AMR
May 2018
©2018 Temenos Headquarters SA - All rights reserved.

Warning: This document is protected by copyright law and international treaties. Unauthorised reproduction of this document, or any portion of it, may result in severe
and criminal penalties, and will be prosecuted to the maximum extent possible under law.
Table of Contents
Introduction 3
Purpose of this Guide 3
Intended Audience 3
Overview 4
Configuration 5
Teller Denominations 10
Multi till set up 16
Deal Processing 18
Opening Tills 18
Closing Tills 18
TELLER.TRANSACTION Concept 20
Stock Control 22
Teller Limits 22
Teller Charge 22
Printing Advices 22
DRAFT MANAGEMENT 24
PASSBOOKS 24
Default Processing 37
Process 42
Multi – Line Teller and TT.GROUP.CONDITION 43
CARD.ISSUE 50
Multi-line Transactions Overview 50
Multi-line Charging 56
Special Function handling 57
Teller - Enquiries 59
Close of Business Processing 61
Teller - R18AMR - Page 2 of 61

Introduction
Purpose of this Guide
This user guide describes all functionality relating to work performed by Retail Teller. It incorporates
the administration of Tills, processing of local and foreign currency transactions,Travellers Cheques,
currency transfers, denomination control, passbook updates, advice production, automatic charges
defaulting, rate defaulting and so on.
Intended Audience
This user guide is intended to the following users / user roles:
Role Description
Teller Assists the Bank customers with an array of monetary transactions
Head Teller Supervises and co-ordinates the activities of the Tellers in the Branch and
approves transactions
Payments Officer Process transactions which involve Inward and Outward Remittances, Clears
Operations and Cheque collection
Payments Super- Authorises remittances, clears and cheque collection transactions and ensure
visor adequate controls and risk processes are followed
Branch Oper- Oversees all data processing activities supporting account and deposit servicing
ations Manager functions of a bank

Overview
The TELLER module in T24 processes a wide variety of retail transactions.Teller is a account based
application for moving funds. It incorporates the administration of Tills, processing of local and foreign
currency transactions, Travellers Cheques, currency transfers, denomination control, passbook
updates, advice production, automatic charges defaulting, rate defaulting and so on.
The wide variety of transactions can be configured easily in T24 by the menu system or by using role
based home pages and can be customised for each user or bank. Also, various risk mitigation functions
are also incorporated such as Teller limits, maker checker concept, stock control and so on for better
transaction and operation control.

Configuration
Teller Accounting
It is possible to raise entries through the TELLER application that have exposure splits on them. This
has been illustrated with an example shown below:
Customer A makes a deposit for $12,000 of which $4,000 in cash and a $1,000 Cashier’s Check is made
immediately available. The transactions made are described as under:
Example Teller Accounting

The value date on all above transactions must be set to the same value. Let us assume that the value
date for all of the transactions made is the 29/06/98, the same as the booking date for the trans-
actions. Assuming that these are the only deposits made to the account, this would cause the following
balances on the account for the following days:

Example Account Balancing Days
If on Monday (the 5th business day from the first deposit) a deposit is made for a 15,000 value dated
the 06/07/98 of which all checks are drawn locally and all items are ‘floated’ for 3 days as shown
under:
Example Teller Account

The above table would be amended to as show under:

Example Account Balancing Days
Travellers Check Accounting

The basic accounting for dealing with Travellers Checks is:
Your own receipts/sales:
On receipt of stock for yourself
Debit TC Stock Account
Credit TC Contra Account
On Sale of TC to customer
Debit Client TC Amount and Charges
Credit PL with charges
Credit Stock Account
Pay Issuer for Day’s Sales
Credit Nostro (in cover of payment)
Debit Contra Account
For Trusted Clients
On receipt of stock for trusted client
Debit TC Stock Account – Trusted Clients
Credit TC Contra Account

On Sale of TC to customer by Trusted Client
Debit Trusted Client TC Amount and Charges
Credit PL with charges
Credit Stock Account – Trust Clients
Pay Issuer for Day’s Sales
Credit Nostro (in cover of payment)
Debit Contra Account
Of course you may wish to receive all traveller’s cheques into your stock account and then allocate to
your trusted clients from there.
The ENQUIRYTC.STOCK.IN.BANK shows the stock held by currency, denomination and serial number
ranges.
Enquiry TC.STOCK.IN.BANK
There are 3 further enquires:
l TC.STOCK.IN.TRUST shows the stock allocated to trusted clients.
l TC.RETAILER.STOCK shows the stock held at a specific site:
l TC.STOCK, which displays the stock by CATEGORY, CURRENCY and/or TELLER.ID, which can be
used to verify the sales made that day.

Enquiry TELLER.POSITION shows the balances of a specific Tellers tills
The ENQUIRY TELLER.OVERALL shows the teller positions of all the tills in each currency.

Enquiry showing balances of all tills, listed by currency
Teller Denominations
TELLER.DENOMINATION records identify the units, coins and notes that are available. When a trans-
action requiring the use of denomination is entered these can be used to identify the stock levels of
each currency at note/coin level.
Example:
USD1000 One thousand US Dollar Bill/TC 1000.000

USD500 Five Hundred US Dollar Bill/TC 500.000
USD5CENT Five Cent coil 0.050
Note the id is for clarity; it is the actual value of the unit that is important (it caters for 0 to 3 decimal
unit currencies), note the above example does not mean there are 3 decimals in USD.
Denomination Control
The denomination control for side 1 of the TELLER transaction can be changed by the use of field
CHECK.STOCK.AMT. If this field is set to Yes and more than one internal account is used on side 1 then
only the accounts with stock control set to DENOM can be used to check for denominations to the deal
amount. If left to No then all the accounts are used in the denomination control totals.

Denomination filtering
The file DENOM.TYPES is used to define various denomination types such as Cash, Gift Cheque, Trav-
eller’s Cheques and so on.
DENOM.TYPE
DENOM.TYPE with example

This DENOM.TYPE is attached to TELLER.DENOMINATION.
TELLER.DENOMINATION Application

TELLER.DENOMINATION with DENOM.TYPE “CASH” available
Based on the DENOM.FILTER (YES), CR.DENOM.TYPE and DR.DENOM.TYPE set at the
TELLER.TRANSACTION level, the filtering functionality is enabled, else the usual functionality is avail-
able.
TELLER.TRANSACTION with DENOM.FILETER Y CR.DENOM.TYPE set to CASH

TELLER record being input with a TELLER.TRANSACTION = 10

Teller record continued
As only CR.DENOM.TYPE is set in this particular TELLER.TRANSACTION, TELLER.DENOMINATION having
“CASH” DENOM.TYPE are available in the UNIT side of the TELLER transaction. The DR.UNIT side has
all the available DENOMINATIONS since DR.DENOM.TYPE is NULL. It is also possible to have filtering
enabled in both sides of the TELLER.TRANSACTION.
Auto Denomination
The field AUTO.DENOMINATE in TELLER.TRANSACTION is used to cater for the user to determine
whether they want to define what denominations are selected for each TELLER transaction or if they
require the system to automatically pre-fill the denominations. Allowable values are YES/NO. When

this field is set to YES, then the system should support the current functionality of default or pre-fill the
denominations, when this field is set to NO, the system does not default any denominations. The user is
able to input the denomination.
TELLER TRANSACTION with AUTO.DENOMINATE YES

If NO is input and the user does not input the correct denomination which equals the transaction
amount, the system throws an appropriate error message and does not pre-fill or default the denom-
ination and hence the transaction can not be committed.

In other words, if the user is not inputting the correct denomination, then the system never commits
the transaction by pre-filling a denomination.
Serial Numbers
It is advisable to create TELLER.TRANSACTION records and customised VERSION for the Receipt/Sale of
Travellers checks, together with others for dealing with clients to whom you provide Travellers checks
on a trust basis.
Multi till set up

The basic set-up required for the functioning of MULTI TILLS should be made in the application
TELLER.PARAMETER.
TELLER.PARAMETER
The trigger to Multi Tills functionality is based on inputs in two fields in the application
TELLER.PARAMETER.
1) Multi-Tills
l Permitted values are (1) Yes and (2) Null.
l If yes-the “Max. Tills” field is a Mandatory input.
l Multi Tills functionality i.e. two or more tills for a user is made available
(2) Max –Tills

l Any numeric, between 1-99 can be input.
l When input –It represents the number of tills a user can keep open at any given time when deal-
ing with the Multi Tills facility.
l The input in this field can be changed at any time.
l Once changed – the new input is effective and earlier validations becomes “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 is going to meet with the error message “Other tills must be closed”
For MULTI TILLS once this set-up is made the attaching of more than ONE teller id is done through
application TELLER.ID.Adequate logic has been built to permit more than one teller id (for a user)
ONLY if the field MULTI TILLS is set to YES or raise an error in case this field is set to “null”.
In TELLER.PARAMETER the max tills is set to 2. That means a user can have maximum of 2 tills and
any attempt to input more than 2 results in system raising an error as shown in the below screenshot.
TELLER.ID

Deal Processing
Opening Tills
In order for a till (TELLER.ID) to be used it must be opened and assigned to a specific USER. The system
ensures that only that user can input transactions to that till. It is possible to change the current tell-
er/user without closing the till by assigning a different user. Normally, each morning it is common
practise for the Teller to visually check the cash in their till prior to beginning the day’s work. In T24
the Teller would open the till.
Example of opening a till and assigning a User
Closing Tills
Closing of the Till can comprise of several operations.
l Balancing the Till by the amount of currencies.
l Balancing the Till by entering the denominations (thereby calculating the amount).
l Compensating where the Till is short in a currency.
l Compensating where the Till is over in a currency.
l Authorising the Till closure.
The closing of a till allows the teller to balance the actual contents of the till against the balance held
by the system. On closure the teller is prompted for the till balance (in each currency) and this is com-
pared to the current system balance.

Alternatively, if the Teller has been set to use denominations, the entering of the number of units in
each denomination (that is, 150 USD100 bills would be USD15000.00) would force the physical count to
agree the till balance to the cash account.
If a difference is found then an override is required. Answering yes to the override automatically
adjusts the system balance to the till balance and posts the balancing entries to the over and short
ACCOUNT records defined in the TELLER.PARAMETER file.
Closing a till
When forcing the Till closing by denominations, it would be preferable to set-up a special VERSION
that requires the input of each number of units of the held currencies. The next screenshot gives an
indication of this but shows the balance as well for information.

Closing a Till
Note:
When re-opening the till, the system checks that the system balance has not moved since the last clos-
ure. If this is the case, then the till cannot be opened until the system balance is adjusted (via
DATA.CAPTURE) to match the till closing balance.
TELLER.TRANSACTION Concept
Although the system processes many different types of transactions, the basic mechanism for bal-
ancing entries, defaulting rates and charges is the same. Hence all transactions are processed by the
one application (TELLER), but the screen prompts can be varied by tailored VERSION with specific
defaults being controlled by a TELLER.TRANSACTION.

Each transaction prepares two balancing accounting entries (more when charges are present). Invari-
ably one side is the 'client' (side 1) and the balancing entry is the teller cash account (side 2), that is, a
simple cash deposit entails a credit to the CUSTOMER account and a debit to the teller cash account.
In the Teller system, the cash that is held at a teller's position is recorded in an internal account
defined as:
CURRENCY-CASH CATEGORY- TELLER ID
example USD-10000-0012
The cash CATEGORY is specified in the TELLER.PARAMETER file. It is the balance of these account
records, which can be reconciled with the actual cash when the till is closed.
Cheques should be posted directly to collection accounts and not held by teller (defined in
TELLER.TRANSACTION). This allows for easy reconciliation of funds as each cheque is recorded as a sep-
arate entry to this account.
It is possible to specify an exposure date on the teller contract, which is used to decide when the funds
credited gets updated to the cleared balance on the account record. It is also possible to clear funds on
a single teller transaction on multiple dates. This information is entered in the exposure date ladder
fields (EXP.SPLIT.DATE and EXP.SPLIT.AMT). Although the splitting information can be entered manu-
ally, they may also be made to default using either the TRANSACTION record or the BC.SORT.CODE
record. Refer to the Local Clearing and System Table for further information on setting up exposure
date splitting defaults.
It is also possible to default the value date on the credit side by specifying a sort code that points to a
BC.SORT.CODE record set up with a default value date period.

Stock Control
It is possible in T24 to keep a track of the currency notes/bills and/or Travellers cheques by currency
and denominations. In the case of currency, it is useful or sometimes a mandatory banking require-
ment to track the amount of currency held by denomination, if only to be able to provide a service to
your clients.
Field STOCK.UPD is introduced in TELLER.PARAMETER and TELLER.ID. If this field is set to YES, the
denomination units input in TELLER.ID during till closure is treated as final stock with teller and over-
write the TT.STOCK.CONTROL with denomination units entered in TELLER.ID for each currency denom-
ination except Travellers Cheques denominations
This functionality is catered only for “Cash” Transactions.
Travellers cheques are more closely controlled by serial number as well as the denominations held.
Teller Limits
Till limits functionality helps currency wise till level limits to be maintained in each till based on setup
in TELLER.ID. The limits whenever breached by a teller transaction raises necessary overrides. Also,
overrides are raised to mean that limit has not been set for currencies found in the stock, whenever a
till is opened or closed if the limit flag is set in TELLER.ID.
Teller Charge
Charges for customers account to account transfer transaction can now collected from any account.
This allows flexibility to collect charges either from the remitter account, beneficiary account or from
a third party account.field CHG.TYPE is introduced in TELLER.TRANSACTION and TELLER applications.
CHARGE.ACCOUNT field at TELLER level is enabled that allows the user to specify the charge account
.The charge account can be in any currency.
Printing Advices
Advices can be printed from any teller transaction. The format and content is user definable by means
of the DEAL.SLIP.FORMAT utility.
To define an advice the details should be entered into the DEAL.SLIP.FORMAT file. This file essentially
describes what data should be extracted from the deal and where, on an advice, it should be printed. It
also allows free format text, totalling and data to be extracted from associated files.

DEAL.SLIP.FORMAT screen for Foreign Currency Sell advice
This advice can now be linked to an individual transaction by entering the DEAL.SLIP.FORMAT key(s)
into the ADVICE.VERSION field of the TELLER.TRANSACTION record. If the advice should be printed by
default then the PRINT.ADVICE field in the TELLER.TRANSACTION record should be set to 'Y'. An over-
ride can be requested if the teller does not subsequently produce the advice.

Assigning specific DEAL.SLIP.FORMAT record to Teller Transaction
The advice is printed whenever the PRT.HOTKEY is depressed, which is defined on the TERMINAL
record, or if the deal slip button is clicked when using the Browser. The advice can be printed at any
stage during the transaction, which means that the customer prior to committing the transaction can
sign the advice.
DRAFT MANAGEMENT
CHEQUE.REGISTER.SUPPLEMENT table holds various statuses like issued presented, cleared, exception,
unknown, cancelled, stopped, and returned. Hence the current status of a draft can be known by refer-
ring this application.
CHEQUE.TYPE field and TELLER application aids in classifying an instrument as cheque or drafts. Addi-
tional validations like validating the payee name, validating the draft number can also be handled in
this table.
PASSBOOKS
Updating Passbooks (Definition)

Passbooks can be issued to savings accounts (see ACCOUNT.CLASS and ACCOUNT). When an entry is
passed across a passbook account from any application, the details are recorded and the TELLER sys-
tem updates the passbook when it is presented.
The layout of the passbook must be defined in the TELLER.PASSBOOK file. This describes the physical
dimensions of the book in addition to 'header' type information, for example, CUSTOMER name and
address, and positions of the debit/credit columns. In fact, the entire content of the passbook is user
definable - see TELLER.PASSBOOK for further details.
To set up the system for passbook printing, do the following:

1. Define the TELLER.PASSBOOK format.
2. Define the 'device' on the appropriate TELLER.ID.
3. Ensure that the TERMINAL can support a local print function.
4. Sets up any printer attributes - see TELLER.ID and PRINTER.ATTRIBUTES.
Inputting SYSTEM record for TELLER.PASSBOOK

This definition has the client details printed when a new book is issued (NEW), the balance carried for-
ward as the first line of each page (FIRST) and the entries themselves on each detail line (LINE). It also
defines the dimensions of the passbook and any printer attributes that should be downloaded when the
device is initiated.

Assigning a Passbook device to a specific Teller using TELLER.ID
To inform the system that the teller has access to a passbook device, the device name is entered on
the TELLER.ID record. The device name is used to form the key to the PRINTER.ATTRIBUTES file, which
is made up from PASSBOOK.DEVICE and the attributes, defined on the TELLER.PASSBOOK record in the
ATTRIBUTE field. In this example the key to the PRINTER.ATTRIBUTES file in our example is therefore
HP8000L.INIT.
Note that there is an option to set the language used by if the field PRT.LANG is used. This ensures the
language descriptions from any records are consistent and not affected by the language on the Teller’s
USER record.
Updating Passbooks (Processing)

Once the teller transaction is committed the application TT.PASSBOOK.PRINT should be launched.
TT.PASSBOOK.PRINT record

The id of the record is the account number that needs to be printed for. This application displays the
page and line of the passbook to be printed and the outstanding entries to print. Here it shows there
are 2 entries to print as there is 1 outstanding entry to print from before this teller transaction.
The user can modify the page and line no and instruct that a new passbook be printed by using the
fields on this application.
If the teller does not wish to print the passbook at this time then they can simply set the
PRINT.PASSBOOK field to NO and commit. Print logic is not invoked this time.
Once the teller agrees with the PAGE.NO, LINE.NO and NEW.PASSBOOK fields they should hit commit.
Also, note if deal slip printing is configured, then this can also be launched in a separate window:
DEAL.SLIP
Once this is committed, two things happen:
1. A new window containing the Passbook Print data appears.
2. The TT.PASSBOOK.PRINT application displays a confirmation message.

Passbook print window
In order print this, it is required to right click this window and select print; then the passbook printer is
needed to select.
The system requests confirmation that the passbook printed correctly. The user must now reply YES or
NO. If NO, then the user is taken back to the initial TT.PASSBOOK.PRINT screen.
Confirmation printing was correct
TT.PASSBOOK.PRINT SCREEN
If YES, then:

Confirmation of printed passbook.
If there are no entries to print for an account/passbook, the system displays the following message.
No entries to print for passbook message
Requesting a Teller Passbook REPRINT between 2 specified dates

The application TELLER.PASSBOOK.REPRINT is used to request a reprint.
Input and commit the record 1st specifying the required date range.

TELLER.PASSBOOK.REPRINT
Go back into the TELLER.PASSBOOK.REPRINT record for the account and Verify the record.
Verify the TELLER.PASSBOOK.REPRINT

The TT.PASSBOOK.PRINT application is launched:

TT.PASSBOOK.PRINT
Note this now shows all entries between dates previously specified on TELLER.PASSBOOK.REPRINT this
can be checked by viewing the START.DATE and END.DATE no-input fields.
Note this application also shows the total number of pages to print and it is possible to identify what
page is going to be printed by looking at the PROCESS.PAGE no-input field.
Again the teller can update the LINE and PAGE.NO and NEW.PASSBOOK fields and press commit.
The 1st page of entries appears:

PASSBOOK ENTRIES PAGE 1
Since this is a multi-page print job then TT.PASSBOOK.PRINT now displays confirmation for the 2nd
page:

TT.PASSBOOK.PRINT for page 2
Also note the ‘Entries to Print’ has decreased accordingly and the page is now 2 of 2.
Commit the record again
Page 2 of Passbook Entries:
Passbook entries page 2

TT.PASSBOOK.PRINT now shows the confirmation stage:
Note that the user is unable to modify PAGE, LINE and NEW.PASSBOOK as these fields are now NO-
INPUT.

TT.PASSBOOK.PRINT confirmation
If user replies NO and commits, the initial screen appears:

TT.PASSBOOK.PRINT – confirmation ‘NO’
If user replies YES, then transaction has finished.
Transaction completed message

If during a multi-page transaction the print job spans across passbooks, that is, the 1st passbook is full
and a NEW passbook must be inserted then TT.PASSBOOK.PRINT appears:
“Insert NEW Passbook A/C XXXXXX”

Different Pass Book Layout
TELLER.PASSBOOK ID as “BOND”
For general accounts the system by default takes the passbook layout as “system”. However it is also
possible to define and attach a different passbook layout using the new field PASSBOOK.ID in the applic-
ation ACCOUNT.STATEMENT.
Input of Passbook. Id field in ACCOUNT.STATEMENT application

Note: - Unless this field is input – for an a/c, which has, the passbook field flagged
as “Yes”- the default passbook lay out would be “System” only.
TELLER.PASSBOOK.REPRINT
The application TELLER.PASSBOOK.REPRINT can be used to print entries at any time for an account.
Besides, the a/c number the period for which the passbook to be printed should be specified in the
fields START DATE and END DATE as shown below.
TELLER.PASSBOOK.REPRINT for a/c 27208
Default Processing
The TELLER system provides an interface to other modules within T24 by use of the TELLER.DEFAULT
application.
Essentially it provides the ability for a TELLER transaction to be created automatically by another mod-
ule, thus containing all necessary information - accounts, amounts, rates, charges and so on which can
then be accessed by the teller by simply entering a reference number.
For example;
The closing of an ACCOUNT. If a client wishes to close his account the teller must perform two trans-
actions within T24. Firstly the account record must be closed. This informs the teller of all outstanding
credit/debit interest, charges, tax and so on, and secondly the teller must pay the client the amount
due. However, in order to perform the latter he would have to enter the details from the
ACCOUNT.CLOSURE screen into TELLER. What the account closure procedure actually does is, to record
the details in TELLER.DEFAULT (id of account number) and the teller pulls the details automatically
into a TELLER transaction by entering the account number into the OUR.REFERENCE field.

ACCOUNT.CLOSURE screen
Once the TELLER.DEFAULT record has been processed it cannot be reprocessed. The layout of
TELLER.DEFAULT is exactly the same as TELLER itself but includes ten additional fields that can include
free format data and two fields to record that the record has been processed, the process date and the
transaction reference number.

TELLER.DEFAULT record created as part of Account Closure
The link to TELLER.DEFAULT is through the OUR.REFERENCE field in TELLER. If this is entered prior to
any other data, then the associated TELLER.DEFAULT record gets loaded.
Foreign Currency P&L

Foreign Currency P&L entry’s can be entered in Teller, the functionality is similar to the Funds Transfer
application. The other leg of the teller transaction must also be of the same FCY, otherwise the system
produces the following error message.

Teller record where both sides of a P&L entry are not of the same currency
Example APPL.GEN.CONDITION record for STAFF

The Contract Groups created through the APPL.GEN.CONDITION are linked to TT.GROUP.CONDITION.
l TT.GROUP.CONDITION enables to define preferential exchange rate spread, commission and
charges for a contract group created through APPL.GEN.CONDITION. The data defined here for
rates spread, charges and commission overrides the default conditions otherwise used by
the TELLER application.

l The ID of TT.GROUP.CONDITION is the same as the Contract Group defined under
APPL.GEN.CONDITION (say for example, Staff)
The following fields of TT.GROUP.CONDITION define the settings relating to the preferential treatment
for a contract group:
RATE.SPREAD defines the preferential rate that could be applied on the exchange spread
(CUST.MED.SPREAD, CUST.SMALL.SPRD of the corresponding CURRENCY record based on the trans-
action value)
CHG.PERCENT defines the concession percentage of charge or commission for the charge or com-
mission type specified.
Instead of a concession percentage of charge or commission, a fixed amount also could be defined
according to the currency.
It is also possible to define the attributes for a particular customer alone by giving the ID as C-Cus-
tomer number (example: C-100001) in TT.GROUP.CONDITION.

Example TT.GROUP.CONDITION record for STAFF
Example TT.GROUP.CONDITION for a customer
Process
Whenever a Teller transaction is made for a customer, the contract group is identified from
APPL.GEN.CONDITION and the preferential percentage of rates, commission and charges pertaining to
this group are applied based on the data specified in the TT.GROUP.CONDITION of that group. A no
input field called CONTRACT.GROUP in TELLER storesand displays the name of the contract group to
which the customer belongs to for future reference.
Examples
Concession on rate for staff
Suppose the Bank wants to pass on a concession of 30% on the exchange rate spread to its staff and
wants to charge only 70% of the spread. The following steps are followed:
a. Create a record for TELLER in APPL.GEN.CONDITION.
b. Under CONTRACT.GROUP define STAFF.
c. Link the decision field to SECTOR of customer record, as STAFF as described above using j descriptor.
d. In TT.GROUP.CONDITION, give the @id as STAFF.
e. In RATE.SPREAD of TT.GROUP.CONDITION, enter 70
After these settings are over, whenever a Teller transaction involving foreign exchange happens for
Staff, then the system finds out the customer spread from the CURRENCY based on the amount of trans-
action, say 0.05, and calculate 70% of it, which works out to 0.035. This spread of 0.035 is added to the
rate for Staff, whereas for others the normal spread of 0.05 is added.
Concession Charges for Staff: (Only 60% to be charged for Staff)

As in “Concession on rate for staff”, the CONTRACT.GROUP for STAFF has to be set.
Supposing the charges for Draft as defined in FT.CHARGE.TYPE is USD30. In TT.GROUP.CONDITION of
STAFF; 60 is defined under the field CHARGE.PERCENT. Then in all the Teller transactions of the Cus-
tomers who are identified as STAFF (CONTRACT.GROUP), if the charge type is Draft, instead of char-
ging USD30, only USD18 is going to be charged.
Multi – Line Teller and TT.GROUP.CONDITION

In the case of MLT, all the legs belong to the same customer and charges are consolidated and applied
based on the type. So if the Contract Group is constructed based on a field of the CUSTOMER, all legs
has the same Contract Group, and the relevant charge concessions defined in TT.GROUP.CONDITION is
applied. If Contract Groups are based on some other criteria, and if the contract groups are not the
same across the legs of the Multi Line Teller, then TT.GROUP.CONDITION is not supported.
It is also possible to define maximum and minimum amounts of charges, together with a discount or
premium, at an individual customer level or for a group of customers. This action overrules the
MAXIMUM.AMT and MINIMUM.AMT fields specified in the generic charge record.
The following fields of TT.GROUP.CONDITION define the special conditions applicable to specific
groups of customers or individual customers:
CHG.MAXIMUM.AMT defines the maximum amount to be charged for which the Charge Type applies.
CHG.MINIMUM.AMT defines the minimum amount to be charged for which the Charge Type applies.
CHG.DISCOUNT.AMT specifies the amount to be deducted from the Charge amount calculated.
CHG.PREMIUM.AMT specifies the amount to be added to the Charge amount calculated.
Multi Tills
The feature of Multi Tills (or Cash Bag) enables a single user to have more than one TELLER.ID depend-
ing on the set-up enunciated in the application TELLER.PARAMETER. Further, Multi Tills contains a lim-
ited amount of cash transferred from the safe. Whenever there is a shortage of cash instead of
drawing from the safe –cash is transferred from the MULTI TILLS. On the contrary if the till cash bal-
ance exceeds the permissible limits then it is transferred to MULTI TILLS. In short, it is possible to call
the Multi Tills as an intermediary between the safe and the till. The set-up, features of Multi Tills are
detailed in the following lines.
Concept of linked tills

This is set up using two fields in TELLER.ID application. They are:
LINKED.TILLS
l This field can be input with any valid TELLER.ID
l The “ID” that is input should belong to the same user or else system raises an error
TILL.TRF.ONLY

l This field can take either “YES” or “null”.
l If input as YES – the TELLER.ID can do only “till to till transfer”.
l If a transaction representing other than “till to till transfer” – is input the system raises an error.
The input in the field can be changed by the user any time.
TELLER.ID – Linked Tills

The above screen shot indicates how for TELLER.ID 0002 the TELLER.ID 0003 (for the same user) is
linked using the LINKED.TILLS field.
In the above screenshot,
l The field LINKED.TILLS is a multi-value field. So far a user if there are more than 2 tills it can be
linked by multi-valuing the field.
l TELLER.ID 0002 is the called “main till” and 0003 is called the linked till, because in TELLER.ID
0002 – the id 0003 is input in LINKED.TILLS field.
The concept of Linked Tills is introduced in Multi Tills to facilitate:

l To Link two or more tills belonging to a particular user.
l To automatically open the linked tills, when the Master Till is opened.
To illustrate - In the above case:
l User LISA2 has two tills Till 0002 Till 0003.
l Till 0002 is the master till and Till 0003 is called the linked or child till.
l Therefore, when Till 0002 is opened –then Till 0003 should also be opened automatically.
Note: This is applicable to only opening of Tills –Closure of tills should be done
individually following traditional teller concepts.
Note: In the above case – suppose the user also had one more till say for example
0005 and assume it has not been linked to till 0002. Then in that case -opening of
till 0002 does not result in opening of till 0005- since it has not been linked.
Warning:
Instead of teller.id 0002 if teller.id 0006 is linked (user is LISA2)- the system raises
an error at check fields “Till does not exist for Current User” as shown in the
screen shot below

TELLER.ID – Link of till pertaining to different user
Default teller id
Earlier, one user had only one teller id. Therefore, at the transaction level the teller id is defaulted
without any difficulty. However, with the evolution of multi tills concept in teller the question arises
which teller id is defaulted at the transaction level. The till used to log into the teller application is the
one that would be automatically defaulted unless it is changed at the application level.
Multi-Valued Teller
The TELLER module in T24 processes a wide variety of transactions. It facilitates the management of
tills, processing of local and foreign currency transactions, travellers cheques, denomination control,
pass book printing, and so on.
In addition to this, now multi value of certain fields is allowed in order to facilitate credit or debit to
more than one account. This facility can also be used for passing on credit directly to various accounts
of a customer out of a single cheque proceeds without routing the same through suspense accounts.
This would help in updating the passbook online, but the actual availability of the amount would be
only after the clearance of the cheque.
For example, if a single cheque is deposited for credit to three accounts, this can be done by multi-valu-
ing the fields credit account number and amount.
The procedure of creating a multi-value transaction is as follows:
l A TELLER.TRANSACTION hasto be defined for each type of transaction. Since multi-valuing is per-
mitted only on side-1 new TELLER.TRANSACTIONS have to be defined with the transaction codes
and the currency and type of accounts that has to be Multi-valued. The values input on side-1
would automatically be defaulted on side–2.

Setting up of teller transaction
For example, if a cheque of USD 10,000 is deposited and has to be credited to three accounts AC1, AC2
& AC3, while processing the teller transaction, credit fields can be multi-valued if the same are
defined in side –1, of the TELLER.TRANSACTION.
The currency must be the same and all the three accounts should belong to the same customer.
No cross currency is allowed. The multi-valued accounts can also include internal accounts.
In the above transaction, if two accounts of the same customer are used, a single
CHEQUE.COLLECTIONis created showing credit to both the accounts.

Teller transaction records having more than ONE credit account

Cheque collection records containing more than one credit account
The account and the amount fields can be multi-valued on side 1 only.
The following are the field level changes that have been made to the existing CHEQUE.COLLECTION
application.
l ACCOUNT
l AMOUNT
The ACCOUNT and AMOUNT fields are defaulted from the credit side of the TELLER record.
l 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. Any further change in the charges either during the TELLER transaction or
during CHEQUE.COLLECTION affects the first account only.
l The validations for using the above facility is as follows:
a) The currency of the accounts should be the same.
b) Accounts must belong to the same customer.
c) The multi-valued side can include internal accounts also.
l 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 side-1, of the TELLER.TRANSACTION.
Customer Groups
It is the practice of banks to pass on certain preferential treatment to a selected group of customers or
staff in the case of charges/ commission and exchange rate spread.

In the Funds Transfer application, FT.GROUP.CONDITION takes care of providing preferential treat-
ment to a group of customers based on certain criteria like category and sector. A similar feature is
provided in TELLER by way of TT.GROUP.CONDITION.
TT.GROUP.CONDITION
The group of customers who need preferential treatment for Charges, Commission and Exchange rate
spread should have been classified under a particular Contract Group for identification. The procedure
for defining a Contract Group for Teller related preferential treatment is as given below:
In APPL.GEN.CONDITION, create a record with TELLER as Id.
CONTRACT.GROUP field of APPL.GEN.CONDITION can be used to create groups like Staff and so on
(this is a multi-value field that enables creation of many number of groups based on different
decisions).
DECIS.FIELD is used to link any field of any application like SECTOR of CUSTOMER to one of the fields
in TELLER, so that any transaction made for this contract group refers to the related
TT.GROUP.CONDITION and applies the preferential rates. The linking is done through J descriptors. For
example in the Standard Selection record of TELLER, the field CUSTOMER.2 can be linked through J
descriptor to the SECTOR field in CUSTOMER. This has to be done under a unique field name. After-
wards in APPL.GEN.CONDITION, under the CONTRACT.GROUP (say Staff), set the DECIS.FIELD to the
unique field name and equate it to a sector number relevant for staff (say 9900)
CARD.ISSUE
It is possible to capture the Card number attached to the debit account in the transaction. The card
number is to be input in the field CARD.NUMBER at the time of transaction. Validations are in place to
check that the card number input has been issued to the debit account number. If a different card num-
ber is input, system gives an override message. If the card number does not exist, system gives an
error message. It is also possible to capture the details of the card transaction in a text field.
Multi-line Transactions Overview

Multi-line Teller deals are unique to users operating with the Desktop interface.
A multi-line deal is comprised of a Master transaction containing links to each 'child' or 'leg' and con-
trols the overall charges and accounting of the 'set'.
The words 'leg' and 'child' have the same meaning within the context of multi-leg transactions.
The purpose of multi-line deals is to progress from the original design of Teller which was essentially a
2 entry transaction (a credit and a debit). For example, the sale of one foreign currency against local;
with default charging this could mean that a customer with 3 transactions is charged too much com-
mission overall; or the Teller has to adjust the charges manually.
Multi-line deals allow the user to process multiple sale transactions whilst building a running total for
charge/commissions. The total of sales is taken into consideration before applying defaults such as min-
imum commissions.

To invoke a multi-line deal instead of using F3 to get the next id, enter the character ‘-‘ in place of the
id. This tells the system to use multi-line transaction ids.
There are a few considerations to take into account when using Multi-line transactions:
1. There should only be one client in the set of legs comprising the multi-line deal.
2. Charges are calculated taking the Multi-line as a complete unit.
3. Charges can be standard or modified at input time.
4. Deal Slips for Multi-line deals are produced via Enquiries.
5. Only Multi-line deals can use the Copy function.
6. Authorisation, Reversal and Copy is done via the Master Deal only.
Multi-line Usage
Consider an example where selling two currencies to a client, and receiving payment and commissions
in local currency. The menu item can be chosen for this TELLER, SELLFM and system selects input
mode for user.
TELLER,SELLFM
It is convenient to allow the system to generate the next id, this is done by putting the character ‘-‘ in
the id and committing the record.

Selecting next ID in the Teller record
It then transposed into the correct id format as:
System converts ‘-‘ into next ID number

Entering the data is done the same way as usual, it is done only when user completes the deal and
presses F5 or the Commit Data toolbar icon that the special processing starts to become apparent.
Inputting a deal:

ID showing ‘-01’ after main ID number
Note:
The transaction id is TT/00084/00044-01, which indicates user is in Multi-line mode and this is the first
leg of the deal.
Depending on whether the VERSION is set for Zero authoriser input or requires a separate authoriser,
the next dialog box may appear different.
Dialog box showing options after transaction has been committed

With a zero authoriser the deal can be completed (Finish), this button does not appear at this stage if
the deal needs an independent authoriser.
Alternative dialog box

What do the various choices mean and what do they do?

NEXT
Accepting this choice means that user is wishing to add further deals to the multi-line set. A fresh input
screen opens and the id is incremented. In the example earlier, it is started with TT/00084/00044-01
and the next number would be TT/00084/00044-02.
MODIFY
This option allows the user to modify the charges across a multi-line deal. It is covered in the Modi-
fying multi-line charging section of this guide.
EXIT
This simply exits the user from the current deal. Similar to finishing a normal deal
For Zero Authoriser VERSION only user also has:
FINISH
It triggers the authorisation of all the legs of the deal. If any of the legs are on hold, the authorisation
process stops. If an override message is generated on any leg that requires an independent authoriser,
the deal remains as unauthorised (usually status INAO) until such authorisation is provided.
So, choose NEXT and do the second leg of the deal:
Second leg of multiple Teller input

Again on committing the data, system allows to choose FINISH, NEXT, MODIFY or EXIT.
If FINISH is chosen:
l The deal and all the legs are authorised. Accounting, especially the charges are finalised.
If NEXT is chosen:
l A new input screen opens with the incremented id.

If EXIT is chosen:
l There is an opportunity to come back and do further deals (defer the FINISH).
If MODIFY is chosen:
l There are more options as discussed later.
* The accounting updates are processed real-time for each leg, the charges are calculated but may
change with further input.
The Master and Child Deals

The Master deal raised from the above example is shown in the following screenshot:
Teller Master Deal for multiple inputs

User can see the individual ids of the multi-line legs, the accounting information, and in this case the
ids of the accounting items (including the charges).
Not much point making a VERSION for this information.

The child deals are where the majority of the transaction data is held:
Viewing the individual (child) transactions
Multi-line Charging
Charging on Multi line deals differs from single line deals. Each charge type is taken from each sep-
arate TELLER.TRANSACTION used on the legs of the deal. Each Charge type is then applied across the
total balance across all the legs of the deal. The amount of each charge is stored on the header record
for the multi line deal. The charges are all calculated at the Local currency and converted to the cur-
rency of the first leg and posted to the corresponding account.
Modifying multi-line charging

At the end of each leg the user has the opportunity to modify the charge over the entire multi line
deal. This is done by pressing the MODIFY button. This then gives the user three options. Waive,
Modify and Standard.

Charging option
WAIVE
This option waives completely the charge from the entire multi line deal.
MODIFY
This option takes the user to a new dialog box that asks them which account to post the charges to.
The accounts appear as buttons with the accounts MNEMONIC or account number if there is no
MNEMONIC. Once the user has chosen the account to post to they are prompted to choose the amount
in the currency of that account to post as a charge. This process is shown below where the user
chooses to post 200 Australian dollars to the account with the MNEMONIC, “FREDAUD”.
STANDARD
This option reverts the charges of the multi line deal to the default charges that would have normally
been levied across it.
Choosing an account to post charges to using Modify option
Selecting charge amount using Modify option
Special Function handling

The standard T24 functions operate slightly differently on multi line TELLER. The following features
are specific to multi-line.

Copy
Copy on a multi line TELLER only works if performed on a HEADER portion of a multi line deal. It
serves to copy the entire multi line deal to a new set of ID’s. The copy is done leg by leg and the
header is rebuilt after each individual copy (this means that if between original input and copy the
charges on the TELLER.TRANSACTION’s used change, the copied deal have different amounts to the ori-
ginal). All unique data (Cheque serial numbers and so on) is deleted and the Teller ID is replaced with
the ID of the currently signed on TELLER. Once the copy function has been run and T24 has the ID of
the new deal, pressing F3 or entering ‘-‘ brings up the next available ID. There is no way of zero author-
ising a Multi line TELLER copy. If any of the legs of a multi line deal are in hold status then the deal
does not copy.
Delete
Delete works the same as in other applications. The only difference being if a leg is deleted from a
multi line deal it rebuilds the header. If the line header is deleted, then it deletes in turn each leg. To
maintain the integrity of the deal, it rebuilds the header after each leg it deletes.
Reverse
It is now possible to reverse any one of the child records. The master deal gets rebuilt with the remain-
ing child records.
Authorise
Authorise can only be performed on header records. It then goes through each leg and authorises
them individually. If any legs are in hold status then the authorisation is not allowed.

Teller - Enquiries
The ENQUIRY records provided with the system allow the teller to view his current cash position by till,
cash position by currency and cash position by denomination (TELLER.POSITION), the cash held by all
other tellers and vault (TELLER.OVERALL) and the entries, in chronological order, passed across the
teller cash account(s) (STMT.ENT.TODAY) and reversed teller transactions.
There are other Enquiries associated with Travellers checks, detailed previously in this chapter.
TELLER.POSITION enquiry listing balances by Teller

TELLER.OVERALL enquiry showing balances of all till accounts, grouped by currency
This is in addition to the standard List facility that enables the user to list all TELLER transactions, with
any selection criteria in any sort order.
For the STMT.ENT.TODAY ENQUIRY the ACCOUNT to be entered for the selection criteria should be the
teller's cash account (CURRENCY: CATEGORY CODE: TELLER.ID).
For client account enquiries, STMT.ENT.TODAY gives the current account balance including all entries
today. The account balance can also be obtained from the main account record.

Close of Business Processing
Two functions are performed at the Close of Business for Teller transactions TT.END.OF.DAY.
1. Remove any unauthorised transactions and place on hold.
2. Transfer all authorised transactions to history.
This means that under normal circumstances, the transaction file is empty at the start of each day.
If passbook processing is active then the Close of Business process, TELLER.PASSBOOK.STMT, updates
the ACCOUNT.STATEMENT and associated files with the details of passbooks updated today (see
TELLER.PBOOK.PRINTED). This process emulates the updates that would take place if a statement had
been produced. A passbook update is viewed as a statement by the system.

Teller - User Guide: Release - R18AMR

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Teller - User Guide: Release - R18AMR

Uploaded by

Copyright:

Available Formats

Teller - User Guide

©2018 Temenos Headquarters SA - All rights reserved.

Teller - R18AMR - Page 2 of 61

Teller - R18AMR - Page 3 of 61

Teller - R18AMR - Page 4 of 61

Example Teller Accounting

Teller - R18AMR - Page 5 of 61

Example Teller Account

Teller - R18AMR - Page 6 of 61

Travellers Check Accounting

Teller - R18AMR - Page 7 of 61

Teller - R18AMR - Page 8 of 61

Teller - R18AMR - Page 9 of 61

USD1000 One thousand US Dollar Bill/TC 1000.000

Teller - R18AMR - Page 10 of 61

DENOM.TYPE with example

Teller - R18AMR - Page 11 of 61

TELLER.TRANSACTION with DENOM.FILETER Y CR.DENOM.TYPE set to CASH

Teller - R18AMR - Page 12 of 61

Teller - R18AMR - Page 13 of 61

Teller - R18AMR - Page 14 of 61

TELLER TRANSACTION with AUTO.DENOMINATE YES

Teller - R18AMR - Page 15 of 61

Multi till set up

Teller - R18AMR - Page 16 of 61

Teller - R18AMR - Page 17 of 61

Example of opening a till and assigning a User

Teller - R18AMR - Page 18 of 61

Teller - R18AMR - Page 19 of 61

Teller - R18AMR - Page 20 of 61

Teller - R18AMR - Page 21 of 61

Teller - R18AMR - Page 22 of 61

Teller - R18AMR - Page 23 of 61

Updating Passbooks (Definition)

Teller - R18AMR - Page 24 of 61

Inputting SYSTEM record for TELLER.PASSBOOK

Teller - R18AMR - Page 25 of 61

Updating Passbooks (Processing)

Teller - R18AMR - Page 26 of 61

Teller - R18AMR - Page 27 of 61

Confirmation printing was correct

Teller - R18AMR - Page 28 of 61

No entries to print for passbook message

Requesting a Teller Passbook REPRINT between 2 specified dates

Teller - R18AMR - Page 29 of 61

Verify the TELLER.PASSBOOK.REPRINT

Teller - R18AMR - Page 30 of 61

Teller - R18AMR - Page 31 of 61

Teller - R18AMR - Page 32 of 61

Passbook entries page 2

Teller - R18AMR - Page 33 of 61

Teller - R18AMR - Page 34 of 61

Transaction completed message

Teller - R18AMR - Page 35 of 61

Input of Passbook. Id field in ACCOUNT.STATEMENT application

Teller - R18AMR - Page 36 of 61

TELLER.PASSBOOK.REPRINT for a/c 27208

Teller - R18AMR - Page 37 of 61

Teller - R18AMR - Page 38 of 61

Foreign Currency P&L

Teller - R18AMR - Page 39 of 61

Example APPL.GEN.CONDITION record for STAFF

Teller - R18AMR - Page 40 of 61