Creating VERSIONS in T24

DateOf Issue Version Changes By

Dec 2004 1.0 Initial Sara Cleur

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.
Versions in T24

Table of Content
Table of Content ................................................................................................................................... 1
Table of Content ................................................................................................................................... 2
Introduction........................................................................................................................................... 3
Importance of Versions in T24........................................................................................................... 3
The VERSION Application .................................................................................................................... 3
Working with the VERSION Application.............................................................................................. 10
Adding a heading to the version .................................................................................................. 13
Multiple fields per line .................................................................................................................. 14
Grouping information in a version ................................................................................................ 16
Setting properties to fields in a version............................................................................................ 17
MANDATORY FIELDS ................................................................................................................ 17
NO INPUT FIELDS ...................................................................................................................... 19
NO CHANGE FIELDS ................................................................................................................. 20
REKEY FIELDS ........................................................................................................................... 26
Defaulting values in field using VERSIONS..................................................................................... 27
Creating Zero Authoriser Versions...................................................................................................... 30
Summary ............................................................................................................................................ 33

TEMENOS Training Publications Page 2 of 34 December 2004

T2ITT – R05 – 1.0
Versions in T24

Introduction
T24’s core has a large number of applications that are used for various banking purposes. Depending
on a person’s role in the bank, he will have to use one or many T24 applications. Each application has
various fields in which the user can input the required information for the core to process. Most of the
times, he will not use all fields in an application. Let us assume there are 50 fields in an application,
but the user has information for only 15, because that is all the bank requires. In this case, he will have
to look for the 15 fields in the application every time he uses it or he may have to remember the field
number / names. This is tedious. Foreseeing this, T24 has an application called VERSION that allows
the user to customise how the application screen looks. Using this application he can make T24
display just the required 15 fields, making input easy. But this is not the only use of the VERSION
application. Lets take another example. The bank requires certain pre processing on the information
input into the application before the core can process it. This processing is done with the help of
routines. But there is no way of attaching routines to the applications. The VERSION application
solves this problem as well. We will discuss all these features in detail in this chapter.

Importance of Versions in T24

No software that is developed can be used off the shelf. That too when it caters to a vast number of
clients that have different needs. As mentioned above, the more the bank can customise T24 to suit its
requirement, the more user-friendly the software is considered to be. Thus the VERSION application is
an important utility available in T24. Its main uses are
• To customise the input screen for applications
• To handle pre processing by allowing routines to be attached
• Create a connection between applications (by allowing us to launch associated versions and
next versions – to be discussed in detail later)
• Allows printing of information from the screen (to be used as an advice slip for bank customers
– to be discussed later in detail)
• To set the number of authorisers required (the number of different users that must authorise
the information in the application before it can be actually updated in the data base by the T24
core)
• To set special properties to fields in the application – for example: we can set some field to
have the “mandatory input” property, or the “No input” property to some fields.
• To default values in some fields based on certain conditions or using a routine.

The VERSION Application

In this section, we will look at all the fields in this application.
ID The ID of the version application has the following syntax <T24application
name>,<version name> E.g. ACCOUNT,OPENNEW or CUSTOMER,NEW

PRINT ONLY Indicates whether the version is to be used for screen input or to print
information from the application. Can be set to Y or left blank

TEMENOS Training Publications Page 3 of 34 December 2004

T2ITT – R05 – 1.0
Versions in T24

RECORDS PER PAGE Indicates whether more than one record may be shown on the same screen in
the version the user is creating. It can be set to ‘Multi’ if more than one record
must be seen / input. Default value is 1

FIELDS PER LINE Fields displayed can be place one below the other or more than one field per
line can be displayed. Must be set to ‘Multi’ if more than one field must be
displayed. Default is 1.

LAUGUAGE CODE Defines the languages in which the text on the screen (name of the fields,
headers etc) will appear. In default, the language mentioned in the Users
profile will be used.

HDR.1.001..039 Text that is input here is displayed on the first line of the header in columns 1
to 39

HDR.1.040..078 Text that is input here is displayed on the first line of the header in columns 40
to 78

HDR.1.079..117 Text that is input here is displayed on the first line of the header in columns 79
to 117

HDR.1.118..132 Text that is input here is displayed on the first line of the header in columns
118 to 132

HDR.2.001..039 Text that is input here is displayed on the second line of the header in
columns 1 to 39

HDR.2.040..078 Text that is input here is displayed on the second line of the header in
columns 40 to 78

HDR.2.079..117 Text that is input here is displayed on the second line of the header in
columns 79 to 117

HDR.2.118..132 Text that is input here is displayed on the second line of the header in
columns 118 to 132

FIELD.NO A valid field from the application, that the user needs to input.

COLUMN Specify the column in which the field must be displayed. This is used when
the FIELDS PER LINE is set to multi.

TEMENOS Training Publications Page 4 of 34 December 2004

T2ITT – R05 – 1.0
Versions in T24

*EXPANSION This is used for multi value or sub value fields. It can be set to Y or blank.
Using this we can control if the field can be expanded or not when the version
is being used. This field is used only when the FIELDS PER LINE field is set
to Multi in the version.

TEXT CHAR MAX This indicates the total number of characters that can be displayed for the
name of the field in the version. When FIELDS PER LINE is 1, then the field
numbers and names are displayed as they are in the standard T24 application.

*TEXT Allows us to specify the text that must be displayed before the field. We can
include the field number as part of the text as well. The format used is
N (fields 1 to 9) NN (fields 10 to 99) and NNN (fields 100 onwards)
• For a single value field - > N <text> / NN <text> / NNN <text>
• For a multi value field - > N XX <text> / NN XX <text> / NNN XX <text>
• For a sub value field - > N XX XX <text> / NN XX XX <text> / NNN XX
XX<text>

TXT.040..078 This field is used when we want to display a heading or a comment across the
screen in a version. In this case, the FIELD NO is set to “*”. The text entered
here will appear in columns 40 to 78.

TXT.079..117 The text entered here will appear in columns 79 to 117.

TXT.118..132 The text entered here will appear in columns 118 to 132

TXT.040..078 This field is used when we want to display a heading or a comment across the
screen in a version. In this case, the FIELD NO is set to “*”. The text entered
here will appear in columns 40 to 78.

ENRICHM CHAR Indicates how many characters is reserved for displaying the enrichment for
the field.

ENRI COL Specifies the Position of the Enrichment for the field, when the "Allow Prompt
Movement" option in the Desktop has been set
This is done using the following option: Tools -> User Preferences ->
Advanced -> Screen Designer
This is mainly used for Designing versions through Screen Designer, in the
Arabic format where the Enrichments are displayed the left

PROMPT COL Specifies the Position of the Prompt for the field, when the "Allow Prompt
Movements" option in the Desktop has been set
TEMENOS Training Publications Page 5 of 34 December 2004
T2ITT – R05 – 1.0
Versions in T24

When value for this field is set, then the existing value of the field COLUMN
denotes the position of the Editable / Display value
The value in this field is considered only when "Allow Prompt Movements"
option in Desktop is set in User preferences
Tools -> User Preferences -> Advanced -> Screen Designer
If the above option is not set, then the existing functionality of Version is used.
i.e the field COLUMN denotes the position of the Prompt. This option is used
mainly for designing Screens in the Arabic format where the Enrichment and
Fields are from the left
The value in this field is automatically updated when version is designed
through Screen Designer

*PROMPT TEXT Text entered here as a prompt to the user instead of the T24 field name.
Feature not available as yet in the browser

*TOOL TIP Text entered here appears near the mouse pointer when it is pointing to the
field. Feature not available as yet in the browser

DROP DOWN The ENQUIRY to be used to generate the drop down list for the field.
ENQ SELECTION the selection criterion that is to be applied to the ENQIORY mentioned in the
DROP DOWN field.

POPUP CONTROL This allows us to specify a built in T24 pop up tool (e.g. Calendar, Calculator,
Rate Control) for the field defined.

CASE CONV We can define the case conversion of the data in the field. Options are ‘Blank’,
‘Lowercase’, ‘Uppercase’, ’Proper case’. Feature not available as yet in the
browser

HYPERLINK The name of an application, version or script may be entered here. It is

invoked when we click on the field’s text.

I LINK IDESCRIPTORS are dependant on the content of data fields, if the data field
changes the IDESCTRIPTOR must be re-evaluated. This field will indicate
which IDESCRIPTOR fields should be triggered if the data field changes

ASSOCIATION In order for the IDECRIPTOR to appear in a multi-valued grid, the

IDESCRIPTOR must form part of the association. This field will specify which
multi-valued association the IDESCRIPTOR is to be associated with

DISPLAY TYPE This can be used to display the field in a different format. There are 3 options
• Toggle
• Checkbox

TEMENOS Training Publications Page 6 of 34 December 2004

T2ITT – R05 – 1.0
Versions in T24

• No display

I DESC States whether the field is an I Descriptor or not.

ATTRIBS Can be set to HOT FIELD. If set, it causes the current contract to be validated
and errors are displayed when the field is exited.

RIGHT ADJ FIELD This indicates that the input area of the field is right justified.

REF NO IN 1ST LINE Indicates whether the ID of the record must be displayed on the first line. By
default the ID is displayed on the 3rd line. Can be used when RECORDS PER
PAGE is set to 1.

ID AUTOM SEQU Contains a list of IDS of the current application that must be accessed
whenever the version is invoked.

NO OF AUTH This field is used to specify the number of authorisers required when using
this version. Values that can be used are 0, 1 and 2.

NOINPUT FIELD The field names mentioned here, will not allow the user to input data in them.

NOCHANGE FIELD The fields mentioned here cannot be modified once the record has be
authorised.

REKEY FIELD NO Fields mentioned here must be re-keyed during authorisation of the record.

AUTOM FIELD NO Allows us to define a field that is going to be defaulted in this version with a
pre-defined value.

AUT OLD CONTENT Enables the User to define the previous field content which is to be changed
automatically with the new default value as held in the next field.

AUT NEW CONTENT Enables the User to define the new automatic default value.

MANDATORY FIELD Fields specified here have to be input.

VALIDATION FIELD Any field from the version that needs a special validation
VALIDATION RTN Discussed in detail in the ‘Version Routines’ document

D SLIP FORMAT Refer to the ‘Deal Slip’ document for details

TEMENOS Training Publications Page 7 of 34 December 2004

T2ITT – R05 – 1.0
Versions in T24

D SLIP FUNCTION Refer to the ‘Deal Slip’ document for details

D SLIP TRIGGER Refer to the ‘Deal Slip’ document for details

INPUT ROUTINE Discussed in detail in the ‘Version Routines’ document

AUTH ROUTINE Discussed in detail in the ‘Version Routines’ document

REPORT LOCKS Defines whether locking situations are reported to the user.

GTS CONTROL Defines how GTS (Globus Transaction Server) will handle error situations
with the version. It can be set to

• 0 – Reject errors, Allow overrides

• 1 – Place record in HLD status with errors, allow overrides
• 2 – Reject records with errors, place record in HLD if overrides are
present
• 3 – Place record in HLD if errors, overrides are present
• 4 – Place record in HLD no matter what

DESCRIPTION A description of the version is entered here.

ASSOC VERSION A list of VERSIONs that is associated with the current VERSION is held in this
field. These associated VERSIONs are used as alternative views of the
contract input. The associated VERSIONs appear "behind" the main version
and can be accessed by "tabs".

NEXT VERSION In ‘Next Version’ you can specify the name of a version to be launched as
soon as this version has been validated.

INITIAL CURSOR POS Indicates the Field Name that the User wants to be first active in the Version.
When the Version is launched the Initial Cursor Position would be at this field.

BUS CRIT FIELD NA

CAPTION The text that appears to the left of the field when displayed or ready for input,
indicating the purpose of the field

EXC INC RTN Flag to indicate whether the routines defined in VERSION.CONTROL should
be executed for this version or not. For more details refer to the document
that covers VERSION CONTROL in detail.

TEMENOS Training Publications Page 8 of 34 December 2004

T2ITT – R05 – 1.0
Versions in T24

ID RTN Discussed in detail in the ‘Version Routines’ document

CHECK REC RTN Discussed in detail in the ‘Version Routines’ document
AFTER UNAU RTN Discussed in detail in the ‘Version Routines’ document
BEFORE AUTH RTN Discussed in detail in the ‘Version Routines’ document

VERSION TYPE Used to group related versions and execute a set of common routines. The ID
of the VERSION.CONTROL record is like Application name.XXX , where XXX
is the version type.

ENABLE GRID Converts the I Descriptor information layout to a Grid format on display.
Values that can be specified are YES / NO / Null

MAX DISPLAY LINES Determines the number of lines to display when using I descriptors

AUTO OVERRIDES If the VERSION is being used as part of an OFS transaction & this field is set
to "YES", then each Override that is encountered will be checked to see if it
can be considered for automatic validation.

NAU PROCESSING This field helps to handle situations when information is passed through OFS
into T24 with an ID that already exists in the $NAU file of the application. It
can take the following values
• 0 – Reject a message when an ID exists in the $NAU file
• 1- Overwrite the existing record with the OFS data
• 2 – Accept Reversal of the record as deletion
• 3 – Apply both rules 1 and 2.

BUSINESS DAY This field indicates on what type of business day the VERSION can be run.
This is based on the value of the CURRENT.DAY field on the DATES record.
• “NORMAL” – the branch is open on an official working day
• “RESTRICTED” – the branch is open on an official holiday, e.g. a
weekend or public holiday
• “CLOSED” – the branch is closed i.e. the holiday table for the branch
indicates a non working day, or the day corresponds to a value on the
BRNACH.CLOSED field for the company

SYS MSG SUPPRESS This field in VERSION along with a similar field in SYSTEM.OVERRIDE table
set to YES will suppress the system override message
Any messages that have not been flagged in the System Override Message
Table will not be suppressed, even when a VERSION or
VERSION.CONTROL (including 'SYSTEM') record is set for suppression

TEMENOS Training Publications Page 9 of 34 December 2004

T2ITT – R05 – 1.0
Versions in T24

The default for SYS.MSG.SUPPRESS field in both the System Override

Message Table and the VERSION/VERSION.CONTROL will be no
suppression.

ATTRIBUTES If the value NO.HEADER.TAG is specified here, associated versions, if

attached, no longer appear as tabs next to the main version. They appear
below the main version.

D SLIP STYLE SHEET An XSL file can be specified to customise the way a deal slip looks.

WEB VAL RTN Some Java routines can be attached here and executed at the Web Server
level. Writing these routines and how they are executed are beyond the scope
of this document.

Now lets take a look at a few screenshots and examples (wherever possible) to get a clearer picture of
how VERSIONS work.

Working with the VERSION Application

To launch the VERSION application, type VERSION into the command line. Since a version is a
customised form of a T24 core application, the ID contains the application’s name as part of it. If
anything else is entered as the ID, the user will see this error message.

A valid VERSION ID is of the form <APPLICATION NAME>,<VERSION NAME> where <VERSION

NAME> is user defined.

TEMENOS Training Publications Page 10 of 34 December 2004

T2ITT – R05 – 1.0
Versions in T24

A valid version name

contains a T24 application as
the first part of the ID.

There is one important point that we must remember while creating versions
• Every T24 application has certain fields that must be filled up for the record to be authorised.
These fields are mandatory fields. A version must contain all these fields, apart from other
fields that we may require.
Now let is create a simple version for the Account application. The following fields of the Account
application need to be part of the Version as they are mandatory fields.

• Mnemonic
• Customer
• Currency
• Category

The authorised version record would look like this.

TEMENOS Training Publications Page 11 of 34 December 2004

T2ITT – R05 – 1.0
Versions in T24

ID of the version, APPLICATION,versionname

One record per page will be displayed

One field per line will be displayed

Fields from the ACCOUNT

application that will be displayed
when the version is user online

To use this version, we have to launch it from the COMMAND line.

This contains the version name

and the T24 function (in this case
Input and F3 (this will generate
the ID automatically)

This is the next screen that we will see. This is the version of the account application that contain the 4
fields we defined.

TEMENOS Training Publications Page 12 of 34 December 2004

T2ITT – R05 – 1.0
Versions in T24

So far we have seen how to create a simple version and launch it. Let us now enhance the way this
version looks and works by using many more of the features of the VERSION application.

Adding a heading to the version

As we can see in the screen shot above, the ID of the version appears on line 1. We can change that
and add a meaningful heading to the version using the HEADER field.

Make the following changes in the version record.

When the version record is now launched, it has this text displayed on the first line.

TEMENOS Training Publications Page 13 of 34 December 2004

T2ITT – R05 – 1.0
Versions in T24

Multiple fields per line

Since we have total control on how a version looks, we can arrange 2 fields on a single line.
Lets see the changes we need to make for this.

Changed from 1 to MULTI

Column in which it must be displayed

Text to be displayed before

the field in the version

Similar changes need to be made for all fields, depending on where they must be displayed.

TEMENOS Training Publications Page 14 of 34 December 2004

T2ITT – R05 – 1.0
Versions in T24

Let us now take a look at how the version looks

TEMENOS Training Publications Page 15 of 34 December 2004

T2ITT – R05 – 1.0
Versions in T24

More than one field per line is being displayed

Grouping information in a version

In T24 applications, some fields are related to others in some way or the other. When versions are
created, it would look presentable, if we could group these fields together and separate them from the
rest, maybe by drawing a line or adding a header. Lets see what changes have to be done to the
version record.

The screen shot below, shows a field that must be added to the version record.

This field in the version must

usually contain a valid
application field name. When a
“*” is used, it signifies a
comment line and we can type
in text to displayed as headers

The heading is displayed on the version as shown below.

TEMENOS Training Publications Page 16 of 34 December 2004

T2ITT – R05 – 1.0
Versions in T24

Setting properties to fields in a version

MANDATORY FIELDS
Using the version application, we can control the way a field behaves in a T24 application. As
mentioned earlier, certain fields have to be input. They are made mandatory by the T24 core; similarly,
while customising an application for a bank, we can set other fields to “mandatory” using a version.
With the help of an illustration lets see how this can be achieved.
Let us add a few more field to the version we have been using so far ACCOUNT,TRG.NEW and make
some of them mandatory.
Fields to be added are
• LIMIT.REF
• ACCOUNT.TITLE.1
Lets make the existing field ACCOUNT.OFFICER and the new field ACCOUNT.TITLE.1 mandatory.

The screen shots below show us what changes we have to make to the existing version record.

To add the new fields and to make the 2 fields mandatory

TEMENOS Training Publications Page 17 of 34 December 2004

T2ITT – R05 – 1.0
Versions in T24

New fields added

2 fields set as MANDATORY

These fields appear with a “*” symbol near them in the version.

When we try to authorise a record with values missing from the above fields, an error message is
generated by T24.

TEMENOS Training Publications Page 18 of 34 December 2004

T2ITT – R05 – 1.0
Versions in T24

NO INPUT FIELDS
There are number of fields in T24 that do not allow input. One of the reasons for this being that T24
core automatically populates values into them.
Using the Version application, we can restrict access to certain normally accessible fields, by setting
the NO INPUT property for the field in the version.
For example, in a bank, more than one clerk may be using the same applications, and due to security
reasons, some of them should not be able to access or change certain information in the records.
Thus setting those fields to NO INPUT in the versions that they will be using is an easy solution.
Let us now see the changes that we have to make in the version application.
For example, once the ACCOUNT.TITLE is entered, it must not be changed, thus we can set that field
to a NO INPUT field in the version.

TEMENOS Training Publications Page 19 of 34 December 2004

T2ITT – R05 – 1.0
Versions in T24

We have removed this

field as a mandatory
input field and added it
to the no input field list
Changes in the version screen are shown below.

Cannot modify
contents of the
field

NO CHANGE FIELDS
Sometimes, there may be certain information held in T24 applications that must not be changed after
the record has been authorised. An example that exists in the T24 core is – once an account has been
created for a customer, we cannot change the customer to which that account belongs to. These field
properties are already set in the core. Using versions, we can set this property to whichever field we
want as the situation requires.

For an example to illustrate this, we are going to use a new version CUSTOMER, BANK. In that the
SECTOR field is set as a no change field. Let us take a look at the version record. (Since it is a new
version, the entire record is pasted for your reference)

TEMENOS Training Publications Page 20 of 34 December 2004

T2ITT – R05 – 1.0
Versions in T24

TEMENOS Training Publications Page 21 of 34 December 2004

T2ITT – R05 – 1.0
Versions in T24

TEMENOS Training Publications Page 22 of 34 December 2004

T2ITT – R05 – 1.0
Versions in T24

TEMENOS Training Publications Page 23 of 34 December 2004

T2ITT – R05 – 1.0
Versions in T24

TEMENOS Training Publications Page 24 of 34 December 2004

T2ITT – R05 – 1.0
Versions in T24

The screen shot below is the version when it is used online.

TEMENOS Training Publications Page 25 of 34 December 2004

T2ITT – R05 – 1.0
Versions in T24

Once the record is

authorised, the SECTOR
field becomes a no change
field.

REKEY FIELDS
This property makes us re key in the value to a particular field in the version, before a record is
authorised. This is useful, when information once keyed in cannot be changed. By adding this property
to the field in the version, it ensures that only the correct value is written into the database. This
feature is not yet available in the browser.
TEMENOS Training Publications Page 26 of 34 December 2004
T2ITT – R05 – 1.0
Versions in T24

Defaulting values in field using VERSIONS

The version application can also be used to default values in certain fields. This helps to reduce
repeated input of same values into fields for different records.
The 3 fields used for this purpose are

Refer to the section in this document where all the fields in the VERSION application have be
explained for more details. This section just tells you how it works.

For e.g. The bank wants to default the SECTOR field as “1000” and LANGUAGE to “English” in all
records that are opened using the version CUSTOMER,CLIENT.

The screen shot below is of the VERSION record. It shows the 3 fields must be set up.

When this version is used to create a new CUSTOMER record, this is what the bank clerk will see.

TEMENOS Training Publications Page 27 of 34 December 2004

T2ITT – R05 – 1.0
Versions in T24

The two fields are

defaulted while the
others remain blank.

This set of fields can also be used to default existing values with new ones. For example, in the
SECTOR field, if a customer has 4200, this must be replaced by 1000. Let us now see how to set the
version record.

When we use this version to manipulate customer records, records with sector 4200 will be defaulted
as 1000.

TEMENOS Training Publications Page 28 of 34 December 2004

T2ITT – R05 – 1.0
Versions in T24

Take a look at an existing customer record.

This is an existing customer

record with SECTOR = 4200

When we open this record with the version CUSTOMER,CLIENT that has been modified to default the
SECTOR field look what happens.

TEMENOS Training Publications Page 29 of 34 December 2004

T2ITT – R05 – 1.0
Versions in T24

SECTOR has been

defaulted to 1000 from
4200

Creating Zero Authoriser Versions

By now you are familiar with the field NO.OF.AUTH in the version application. In this field, you can set
the number of authorisers required for authorising records using that particular version. This field
defaults to 1 if not entered. The other values it can take is 2 (meaning 2 different users have to use the
authorise function to finally commit a record to the database) or 0. When this field is set to zero, the
user that inputs the record using the version, authorises it the first time that he presses the “Commit”
button. This is usually not recommended to the bank since it may cause a lot of chaos. But these type
of versions can be used for ENQUIRY and other applications that do not affect the working of the bank,
in case a record is wrongly committed.
An important point needs to be noted here. While creating a zero authoriser version,
• Every T24 application has a field called OVERRIDE. This field stores all the warnings that T24
raises when we try to authorise a record. A version that is used for authorising must contain
this field.

Let us now see how a version works with the NO.OF.AUTH field set to 1 and then 0.

TEMENOS Training Publications Page 30 of 34 December 2004

T2ITT – R05 – 1.0
Versions in T24

The screen shot below of the version CUSTOMER,CLIENT

Let us see what happens when a record is modified using this version. After the “Commit” button is
pressed, the status of the record is in INAU – meaning it must be authorised by another user.

Let us now set the NO.OF.AUTH to 0 in the version and see what happens

TEMENOS Training Publications Page 31 of 34 December 2004

T2ITT – R05 – 1.0
Versions in T24

When a record is now modified using this version, it will be authorised.

The screen shot below is before the alteration of the record.

Field to be modified

Authorised record

The record is now modified and committed.

TEMENOS Training Publications Page 32 of 34 December 2004

T2ITT – R05 – 1.0
Versions in T24

Field changed

Record authorised

There is a naming convention followed in T24. All zero authoriser versions are called “Comma”
versions. The names of the versions follow this syntax <APPLICATION NAME>, For example:
CUSTOMER, or ACCOUNT,
This naming convention isn’t compulsory, but is commonly used.
However, any versions created can have zero authoriser set even if their ids are in the format
<APPLICATION NAME>,<VERSION NAME>

Summary
• VERSIONS are primarily used to customise the way the T24 applications look when used
online.
• VERSIONS can be used for printing purposes alone.
• VERSIONS allow us to manipulate the way some fields in the application work.
o Fields can be set as MANDATORY
o Or they can be set as NOINPUT, NOCHANGE, REKEY fields
o Fields can be defaulted with predefined values
• The number of authorisers can be set in the VERSION
TEMENOS Training Publications Page 33 of 34 December 2004
T2ITT – R05 – 1.0
Versions in T24

• Routines that are required to be executed at various stages can be attached to VERSIONS
• All T24 core mandatory fields must be present in the version
• If the version is used for authorising records, the OVERRIDE field must be one of the fields in
the version.

TEMENOS Training Publications Page 34 of 34 December 2004

T2ITT – R05 – 1.0