Professional Documents
Culture Documents
User Guide
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.
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
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.
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.
• 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.
• 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.
• A tabbed screen is invoked from the command line by typing in the command ‘TAB’, followed
by the key to the EB.TABBED.SCREEN.
Figure 6 - Account Balance result page based on ACCOUNT mapping from 1st Enquiry
• 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.
Figure 10 - Running a tabbed enquiry from the command line, with specified selection criteria
Figure 12 - Running a specific tabbed version from the command line with specified key
• 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.
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.
• 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.).
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.
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.
For the created browser tool to function some java script code must be added to the custom.js script
file: -
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.
!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.
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:
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 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.
AUTOM.FIELD.NO = DEBIT.THEIR.REF
AUT.NEW.CONTENT = !CURRENT.TEXT
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.
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.
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.