TEMENOS T24

Browser Screen Versions

User Guide

Information in this document is subject to change without notice.

No part of this document may be reproduced or transmitted in any form or by any means,
electronic or mechanical, for any purpose, without the express written permission of TEMENOS Holdings NV.

Copyright 2005 TEMENOS Holdings NV. All rights reserved.

Browser Screen Versions

Table of Contents
Introduction.............................................................................................................................................. 3
Application Overview ........................................................................................................................... 3
Tabbed Screens................................................................................................................................... 4
Opening a tabbed screen ................................................................................................................. 4
Traversing tabbed screens - Enquiry to Enquiry.............................................................................. 7
Traversing tabbed screens - Enquiry to Transaction ....................................................................... 9
Traversing tabbed screens – Transaction to Transaction.............................................................. 10
Scenario 1 TXN – ENQ .................................................................................................................. 11
Tabbed screens – Enquiry command line invocation .................................................................... 11
Tabbed Screens - Transaction command line version invocation ................................................. 13
Composite Screens............................................................................................................................ 15
EB.COMPOSITE.SCREEN ............................................................................................................ 15
Hyperlinks .......................................................................................................................................... 19
Custom Field Buttons......................................................................................................................... 20

TEMENOS T24 User Guide Page 2 of 25

Browser Screen Versions

Introduction
Application Overview
VERSION is a standard T24 application, which allows users to create customised screens for input,
authorisation, display etc. It may also be used to automate the replacement of data on records.

It will be rare for any client to use the standard (main) screen input for all T24 applications. In fact T24
comes with many useful VERSION records for the majority of T24 applications. You are encouraged
to copy these and amend them to suit your requirements. Do not amend the originals because
changes may be issued in future releases.

It is also possible to add local sub-routines, which can be used for field, input and authorisation
validation. These small programs will allow even greater customisation of T24 by the user.

All T24 trading applications are capable of supporting more than one product, e.g.
LD.LOANS.AND.DEPOSITS supports loans, deposits, commitments etc. It also supports a wide
variation of options e.g. discounts, maturity, liquidation, rollovers and schedules to highlight a few. In
order to support this functionality the main LD contract has two hundred fields. Although all the fields
are necessary only a few are needed for the input or maintenance of a particular contract type.
Version allows you to create screens, which reflect each contract type, presenting only the necessary
fields and defaulting data into other fields.

Each version you define is referenced by the name of the application and the name of the version
separated by a “,”. For example, an LD version for inputting call deposits could have an id of
LD.LOANS.AND.DEPOSITS, CALLDEP. To ‘run’ the VERSION simply enter the application name with
the version reference.

SMS control can be defined specifically for the version by entering the name of the version, with the
comma, in USER in the field VERSION. Consequently you can restrict access to the contract types as
well as the application itself.

The creation of VERSION records can be divided into three main categories; input of the header or
title; the fields required for input or display; and the defaults to be pre-filled when using that specific
VERSION.

TEMENOS T24 User Guide Page 3 of 25

Browser Screen Versions

Tabbed Screens
Opening a tabbed screen
A tabbed screen enables the Browser to display a series of Enquiries and Versions together, on the
same screen.

Figure 1 - Tabbed Screen

• Each of the individual Enquiries and versions are displayed on individual tabs.
• Each tab is completely independent; only one tab may be active at any given time.
• Switching to another tab will lose all input to the previous tab.
• Tabbed screens are defined in the table EB.TABBED.SCREEN. In this example three tabs
have been defined: an enquiry and two versions.
• Whether the tab is to be an enquiry or a version is determined in the field
EB.TS.CONTENT.TYPE:
o ENQ – Enquiry
o TXN – Transaction
• The name that will appear on the tab is entered in the field EB.TS.TAB.TITLE.
• The actual enquiry, or version, to be run is entered in the field EB.TS.SOURCE.
• It is possible to link selection criteria, such that once the selection criteria has been set,
subsequent tabs can display the enquiry data without the need for the selection criteria to be
entered again. If there is no matching selection criteria defined in the EB.TABBED.SCREEN,
then the selection criteria will be displayed.

TEMENOS T24 User Guide Page 4 of 25

Browser Screen Versions

• The mapping between tabs is made possible via the fields EB.TS.SELECT.FROM and
EB.TS.SELECT.TO. The field you want to extract the data from goes in the former, and the field
you want to add the data to goes in the latter.
• The rules on which tabs the actual mapping comes from, is determined by the type of tabs
involved in the process. These rules are covered in the proceeding sections.

Figure 2 - EB.TABBED.SCREEN record

• A tabbed screen is invoked from the command line by typing in the command ‘TAB’, followed
by the key to the EB.TABBED.SCREEN.

TEMENOS T24 User Guide Page 5 of 25

Browser Screen Versions

Figure 3 - Calling a tabbed screen from the command line

• The above command will then display all of the tabs laid out in the EB.TABBED.SCREEN record
‘TEST6’.
• If the first tab on the tabbed screen is an enquiry, then it will present the Enquiry Selection screen.
This will only happen on initial display. On subsequent visits to this tab, the enquiry selection
criteria, if there is any, will be run.
• If the first tab is a version then it will be run as is.

TEMENOS T24 User Guide Page 6 of 25

Browser Screen Versions

Traversing tabbed screens - Enquiry to Enquiry

• All Enquiry mapping will refer to the first enquiry on the tabbed screen, regardless of the
designation of the last tab.
• In Figure 4, if the Enquiry ‘Account Balance’ tab is selected then it will use the fields referred to in
the EB.TS.SELECT.FROM field – in this case ACCOUNT – and attempt to map it to the field in the
EB.TS.SELECT.TO field. It will use the first enquiry on the tabbed screen to perform the mapping.
The first enquiry in this case is ‘Statement Entries’
• EB.TS.SELECT.FROM and EB.TS.SELECT.TO is multi valued, so more than one field can be
put forward for mapping.
• If the mapping is successful then it will bring back the results of the enquiry.

Figure 4 - Enquiry to Enquiry mapping

TEMENOS T24 User Guide Page 7 of 25

Browser Screen Versions

Figure 5 - Statement Entries result page

Figure 6 - Account Balance result page based on ACCOUNT mapping from 1st Enquiry

TEMENOS T24 User Guide Page 8 of 25

Browser Screen Versions

Traversing tabbed screens - Enquiry to Transaction

• When a user traverses from an enquiry to a transaction tab, the version will look for the field
specified in its EB.TS.SELECT.FROM field to use as the key to that version.

Figure 7 - Enquiry to transaction mapping

• This field will then be used to interrogate the F.ENQUIRY.SELECT record for the first enquiry on
the tabbed screen. On finding the field in the F.ENQUIRY.SELECT record, it will then use this
value as its key.
• In this example, the third multi value is a TXN that has specified that it will look for the field
CUSTOMER MNEMONIC.
• When the Customer Record tab is clicked, the server will attempt to find the field
CUSTOMER.MNEMONIC from the first enquiry – ACCOUNT-LIST. It will then attempt to use this as
the key to the CUSTOMER record.

TEMENOS T24 User Guide Page 9 of 25

Browser Screen Versions

Figure 8 - Customer record mapped from Enquiry Selection

Traversing tabbed screens – Transaction to Transaction

• When a version tab is selected, if the previous tab was a version with a valid key, then the new
version will attempt to use this key to invoke the new version.
• The second transaction is set up to look for the field CUSTOMER.MNEMONIC. The following rules
apply:
o On selecting this tab, if the previous tab was a version with a valid key, then it will use this
as the key to the new version tab.
o If a version tab had been navigated to with a valid key, then that key will be stored on the
client page for future use. When selecting the second version, if there is a stored key, then
it will attempt to open up the version with that key.
• This will override the Enquiry to Transaction rule. If an enquiry were to be run with a different
Customer ID, then the stored key on the client would take precedence.

TEMENOS T24 User Guide Page 10 of 25

Browser Screen Versions

Figure 9 - Transaction to Transaction mapping

Scenario 1 TXN – ENQ

• Enquiry mapping will always refer to the first enquiry

Tabbed screens – Enquiry command line invocation

• Running an enquiry with parameters via the command line.
o The user can specify the actual tab number of the enquiry to run, along with the selection
criteria.

TEMENOS T24 User Guide Page 11 of 25

Browser Screen Versions

Figure 10 - Running a tabbed enquiry from the command line, with specified selection criteria

• The above example will open the tabbed screen ‘TEST2’.

• It will run the enquiry on the first screen with the selection criteria:
o CUSTOMER.MNEMONIC EQ DBL
• See below, for the resultant enquiry screen.

TEMENOS T24 User Guide Page 12 of 25

Browser Screen Versions

Figure 11 - Command line enquiry result on tabbed screen

Tabbed Screens - Transaction command line version invocation

• The key to a specific tabbed version can be supplied via the command line.

Figure 12 - Running a specific tabbed version from the command line with specified key

TEMENOS T24 User Guide Page 13 of 25

Browser Screen Versions

Figure 13 - Version invoked from command line

• In the above example, the third tab is invoked using the key “DBL”.
• If the version on the tabbed screen already has a key specified in the EB.TABBED.SCREEN
record, then this will take precedence i.e. the hard coded key will be used instead of DBL.

Figure 14 - An example of overriding a command line version key request

TEMENOS T24 User Guide Page 14 of 25

Browser Screen Versions

In the above example, if the second tab is invoked from the command line with the key DBL, then the
key 100060 will take precedence.

Composite Screens
A Composite screen is a collection of screens in T24 placed in one browser window, but in different
frames. The individual frames can be set to accept requests for certain enquiries or transactions
enabling multiple contract screens and enquiry screens to be utilised without obscuring one another.
Individual screens within a composite screen can also be set to contain T24 menus, Tabbed Screens
URLs or other content created through utility routines as well as creating a whole new set of
composite screens.

Composite screens are defined in the T24 application EB.COMPOSITE.SCREEN and can be
invoked using the command COS <name of composite screen> which can be run through menus,
toolbars and on the T24 command line.

EB.COMPOSITE.SCREEN
The Composite screen application EB.COMPOSITE.SCREEN is used to define composite screens.
This application comprises of a title for the composite screen and a large linked multi value set for
defining the contents of each frame and makeup of the frames of the composite screen. The multi
value is made up of the following fields:

• CONTENT.TYPE: This field states what the item you are trying to define is. it can be one of the
following values:
o OPEN.FRAME: Create a frame set. Tells you are splitting this frame into further frames.
o CLOSE.FRAME : Closes the frameset.
o ENQ : This item is an Enquiry.
o TXN : This item is a contract screen.
o UTILITY: This allows you to call a browser routine. Not sure on the entire scope of this.
o TAB : This item is a tabbed screen.
o COS : This item is a composite screen.
o MENU : This item is a menu.
o URL : This item is a URL.
o BLANK : This item starts blank.
The value of this field then defines what the rest of the item will require:
• BORDER.SIZE: This field defines what the border of the frame set will be. Only used for Open
Frame
• COLS: This defines the number and width of the columns. It is done in the same format as the
frameset tag in html. For reference and instructions on this see
http://www.w3schools.com/html/html_frames.asp. For a given OPEN.FRAME item you must have
either the ROWS or the COLS field set. You cannot however have both.
• ROWS: As Cols, but used to specify rows.

TEMENOS T24 User Guide Page 15 of 25

Browser Screen Versions

• NAME: Gives a name for the Frame. All content defining items (i.e. telling you what is in a frame)
must have a name.
• SCROLLING: This defines whether the frame is going to allow scrolling. Can only be entered with
content defining items.
• CONTENT: This is a multi purpose field that defines the content of the frame. Either a URL, the
name of an Application and version, an enquiry etc. Also used to define the name of the utility to
be called.
• CONTENT.ARGS: If a UTILITY type is set then this will define the args for the called utility will be
defined here.
• ITEMS: This sub-valued field is used to define what requests should be sent to this frame. It can
be specific requests of application and version or enquiry, or it can be set to take all unassigned
enquiries by setting it to ENQ or all unassigned requests by setting it as ALL. Furthermore it can
be set to take everything except enquiries by setting it to NOENQ. The request is assigned to a
window by running through each item until a valid match is found for the request. If none are found
a new window is launched.

NOTE: By default when using Composite Screens, enquiry drilldowns will be opened in a new window.
To send an enquiry drilldown to a specific Composite Screen frame, set the ITEMS field to be the
drilldown option number (e.g. “1” for the first drilldown, “2” for the second drilldown, etc.).

TEMENOS T24 User Guide Page 16 of 25

Browser Screen Versions

The structure of a composite screen would be to create a frame set using the OPEN.FRAME type.
Then the next items would be the frame contents from left to right or top to bottom. The contents of a
frame can be another OPENFRAME item which will create a new frameset within that frame. The next
items would then relate to the frames in that frame set. Once all the items in that frame have been
defined then the CLOSE.FRAME item is added. This will cause the current frameset to close. If the
current frameset was embedded within a frame then the next item definition will return to the previous
frameset, unless it is at the top level at which point the composite screen definition is closed.

The content type and defined content of a content item is only defines the starting content of the item.
If the frame has any values defined in its ITEMS field then the content will be overwritten by any
requests that match those items.

Figure 15 - Composite Screen

TEMENOS T24 User Guide Page 17 of 25

Browser Screen Versions

Figure 16 - Customer Summary

TEMENOS T24 User Guide Page 18 of 25

Browser Screen Versions

Hyperlinks
Hyperlinks are added to a screen version by defining the path of the document or file in the
HYPERLINK field on VERSION. All information regarding hyperlinks must be input into the hyperlink
field with forward slashes “/” as below: -

- Internet files must be input as: http://, or https://, or www. followed by the address.
- Files must be input as file:/// followed by the path.

Figure 17 VERSION record CUSTOMER,CLIENT

Highlighted field shows hyperlink in field 10(Account Officer)

In the above example, clicking on the fieldname ACCOUNT.OFFICER in CUSTOMER,CLIENT

displays the document defined in the hyperlink, in a separate window

TEMENOS T24 User Guide Page 19 of 25

Browser Screen Versions

Custom Field Buttons

T24 Browser provides the facility to attach custom buttons to fields on a Version. Custom Buttons
perform the related custom javascript function applied to the custom.js file (under the scripts directory).
T24 Browser will provide the fieldname and the field value as two parameters and call the function as
defined in custom.js.
For example if “openOutlook” is placed into the ITEM field on BROWSER.TOOLS, the system looks
for the function “openOutlook” in custom.js and passes in the field name as the first parameter and the
field value as the second (where the button has been defined in a VERSION). Since the parameters
are pre-defined, brackets must not be used in the ITEM field.
It is therefore possible to pass in an email address under the field value and open up an email
application such as Outlook.

The following screenshots illustrate an example setup of a custom button: -

Figure 18 Showing new BROWSER.TOOLS creation with “FIELD.BUTTON” type.

TEMENOS T24 User Guide Page 20 of 25

Browser Screen Versions

For the created browser tool to function some java script code must be added to the custom.js script
file: -

Figure 19 Example display of custom.js path.

TEMENOS T24 User Guide Page 21 of 25

Browser Screen Versions

The highlighted text in the following example illustrates some JAVASCRIPT which can be changed to
dictate to the system what action to take for the custom button. Note that the function name
‘chequeIssue’ needs to match the value in the ITEM field on the BROWSER.TOOLS record: -

Figure 20 custom.js

The custom button is added to a version by applying the BROWSER.TOOLS record id to the
required HYPERLINK field on the VERSION record.

TEMENOS T24 User Guide Page 22 of 25

Browser Screen Versions

!CURRENT.XXXX
!CURRENT.XXXX variables
In addition to the system common variables that can be used in ENQUIRY and VERSION there is a
feature where users can populate a variable of their own and use it later. There are also a series of
new system variables and a much wider option for users to create and use their own.

User set variables

CURRENT.XXXX where XXXX can be any value that you feel is applicable, the important part for the
system to recognise them is the 'CURRENT.' prefix. The same use is made of these in ENQUIRY &
VERSION. Setting them is done by using them without the ! prefix and reading the content by using
the ! prefix. The variables can be set with values from an existing Enquiry field or with a literal value

Example:

CURRENT.NAME>SHORT.NAME populates the variable with the content of SHORT.NAME

field from the Enquiry
CURRENT.TEXT>"Hello Everyone" populates the variable with the simple text "Hello Everyone"
CURRENT.CCYS>[USD][GBP][JPY] populates the variable with a list of values

Then use them in ENQUIRY in the selection field or predefined selection.

TEST.DATE EQ !TODAY
TEST.NAME EQ !CURRENT.NAME
TEST.TEXT EQ !CURRENT.TEXT
TEST.CCYS EQ !CURRENT.CCYS

Creation of a !CURRENT.TEST1

Figure 21 Creation of Enquiry called CURRENT.TEST1

TEMENOS T24 User Guide Page 23 of 25

Browser Screen Versions

Linking this enquiry to

previous enquiry

Figure 22 Creating a second enquiry. When this enquiry is run, the system will search for
!CURRENT.TEST1 variable, (highlighted) set by the running of the first enquiry, and display the results.

These can be set to VERSION too.

AUTOM.FIELD.NO = DEBIT.THEIR.REF
AUT.NEW.CONTENT = !CURRENT.TEXT

This field should be populated

with your !CURRENT enquiry

Figure 23 Above shows how the VERSION record fields should be populated using the new variable data.

Note: You can set the Enquiry to drill down to both another Enquiry and a Version on the one screen.

TEMENOS T24 User Guide Page 24 of 25

Browser Screen Versions

To view the content of any CURRENT.xxxx variables there is an ENQUIRY called USER.VARIABLES
which displays the current content.
Note: The values of user set variables are empty at initial login and cleared on exit so this Enquiry will
only display values set during the current login session.

Figure 24 Showing variables set after running variety of enquiries

EB.External.User
These are set on login by an external user and cleared when they logout. This means that ENQUIRY
& VERSION can be tailored to accept the content of the variable instead of forcing a user to enter their
own customer number or arrangement etc.

For example instead of having a selection criteria for an Enquiry like "CUSTOMER.NO EQ
123456" the same Enquiry can use a pre-selection of "CUSTOMER.NO
EQ !CURRENT.CUSTOMER". The standard convention of using the variable is to prefix it with an
exclamation mark i.e !CURRENT.CUSTOMER.

Similarly in VERSION you can now default a field content by using the! CURRENT.CUSTOMER to
populate a customer field with the current content of the variable. So the variable could be set in one
Enquiry and used in either another Enquiry linked to it; or via VERSION to populate fields in an
application triggered from the Enquiry.

!CURRENT.CUSTOMER (Customer number)

! CURRENT.EXTERNAL.USER (Mnemonic)
!CURRENT.ARRANGEMENT (Arrangement number)

TEMENOS T24 User Guide Page 25 of 25