Welcome to the learning unit on Versions in T24 .

In this learning unit you will learn about

Versions in T24. You will also create simple versions in T24

CUS6 Introduction to Version-R10.01 1

 The conventions used in this learning unit are,

1. Applications in T24 are represented in bold uppercase letters.

2. The fields in the applications are mentioned in uppercase letters.

3. This learning unit is example based. First an example output will be shown then you will
be taught the steps to create the Version. At the end of each section a workshop is
given to test your level of understanding.

CUS6 Introduction to Version-R10.01 2

 At the end of this learning unit you will be able to,

1.Explain what a Version is in T24.

2. Create simple Versions in T24.

3. Launch Versions in T24.

CUS6 Introduction to Version-R10.01 3

 1,2 Imagine that you have to input a funds transfer transaction in T24. You will use the
FUNDS.TRANSFER application, and the input function to do so. The screen that is
displayed to you contains all the fields in the FUNDS.TRANSFER application some of which
may not be important to the end user. Being the first time, you cannot figure out which fields
to use and which not to. What if you had a customised screen that showed you only the
fields that you require to input?

3,4 You can create customised application screens in T24. They are called versions. The
VERSION application must be used to create customised application screens. Your version
you can have just the mandatory fields in FUNDS.TRANSFER application.

5. Can you view data using versions?

Versions behave like the application itself, but only looks different. Thus all functions can
be used with a version. So, yes you can view data using a version. Versions work with all
functions of T24

CUS6 Introduction to Version-R10.01 4

 This task teaches you how to create a simple version of the ACCOUNT application in T24.

The requirements of the task are listed below:

1. The version must comprise of the following fields of the ACCOUNT application Customer
Number, Mnemonic, Currency and Category.

2. The header “Temenos Training” need to be displayed.

3. The customer accounts created should be authorised by another user.

CUS6 Introduction to Version-R10.01 5

 To create a version in T24, you must create a record in the VERSION application. The
format of the ID for the VERSION application is T24ApplicationName,VersionName. The
application name and the comma are mandatory, the optional part of the ID is the version
name. If the first portion of the ID is an invalid application name, an error message is
displayed. Here the version id created is ACCOUNT,TRG.VERSION1 where ACCOUNT is a
valid T24 application and TRG.VERSION1 is the version name.

Are Versions only used for creating customised screens to be used for input? Versions are
also used to define printed reports.
PRINT.ONLY - The first field indicates whether the version is created for printing reports. By
default it is blank stating that the version is just created for a customised screen

Before creating a version you must decide what fields are going to be part of it. Ensure that
you have all the mandatory fields of your application in your version. You will now learn the
use of some of the fields in the VERSION application. You can also view records using the
customised screens.

Do you want the version to display one record at a time or multiple records? Where do you
specify this?
RECORDS.PER.PAGE –The RECORDS.PER.PAGE field has options that lets you to have
one or multiple records per page. When RECORDS.PER.PAGE is set to one, one record will
be displayed per page.

Note: If RECORDS.PER.PAGE is set to multi, multiple records will be displayed. This field
works only with the DESKTOP.

CUS6 Introduction to Version-R10.01 6

 FIELDS.PER.LINE- Next how do you want the fields to be displayed – one below the other
or on the same line? Specify this in the field FIELDS.PER.LINE. Choose one as the option
for the field FIELDS.PER.LINE . This will make the fields to appear one after the other.

LANGUAGE.CODE - The language used to display field labels for each field in the version is
decided by LANGUAGE.CODE. It is not a mandatory field and if left blank, it will default the
LANGUAGE value from the user profile of the person committing the version record.

Where do you specify the headers for your version?

HDR - You may specify headers for your version in different languages. The field HDR holds
the text that will be displayed as header. It is a multi-value field. The header is displayed in a
column range of (1) one to (132) one thirty two. The header shown in the example is
displayed from column one to thirty nine.

FIELD.NO - Now you have to specify the fields of your version. This is specified in the field
called FIELD.NO, where you specify the actual field name as given in the application. It is a
multi-value field. You can multi-value and specify the other fields also. In this example we
have chosen four fields namely, CUSTOMER, MNEMONIC, CURRENCY and CATEGORY.

CUS6 Introduction to Version-R10.01 7

 When using an application in T24 to create a new record, the record status is INAU when
the record is first committed and then has to authorised. Now what if you want to skip the
INAU stage? Will a T24 application allow you to authorise a record straight away? The
answer is No. But a version offers you a work around.

T24 allows a maximum of 2 levels of authorisation. The default is 1 for an application. In

other words, one user must use the ‘A’ function for the record to move to Live.

NO.OF.AUTH - The number of authorisers is set in NO.OF.AUTH field. It enables the user to
specify the number of authorisers required when using this version. Value for this field is
defaulted based on the value of the field DEFAULT.NO.OF.AUTH in the COMPANY
application. The minimum value is (0) zero and the maximum value is (2) two for this field.
When it is set to 0 your version becomes an Auto Auth Version. Auto auth version is nothing
but self-authorisation.

When NO.OF.AUTH is set to two, you require two different users to authorise the record.
Once when the record is authorised it moves to INA2 status. In order to make it as a LIVE
file the record has to be authorised by a different user again.

You have now created the customised screen. You must authorise your Version record next.
It is now ready for use.

CUS6 Introduction to Version-R10.01 8

 1. After you authorise the version record , to launch the version specify the version ID -
ACCOUNT,TRG.VERSION1 in the command line.

2. The version behaves like the under lying application so you can either open a new
record or view an existing record using the created Version.

3. You can also launch the version from a menu

CUS6 Introduction to Version-R10.01 9

 1.In the VERSION record the NO.OF.AUTH field is set to 1(one) .

2.A record created using this version is shown. You can see that the record has moved to
INAU status.

3.After you authorise the record it moves to LIVE status. You can see the name of the
inputter and authoriser of the record.

Note : For those records in LIVE status the RECORD.STATUS field is not displayed.

CUS6 Introduction to Version-R10.01 10

Slide 10

a2 In the following 2 slides the functionality of NO.OF.AUTH field is explained with the values 1,0 & 2 set.
The slides are animated ones.
assispriya, 2008/07/30
 1.Here the NO.OF.AUTH field is set to zero.

2.When you use this version to create records, the record immediately moves to LIVE status
as soon as you commit the record. This is a auto-auth version.

Note: VERSION, (version comma) is an auto-auth version for creating versions in T24.

CUS6 Introduction to Version-R10.01 11

 1. Here the NO.OF.AUTH field is set to 2(two)

2. Now when you create a record using this version it moves to INAU status.

3. Once you authorize the record, the record does not move to LIVE status. It moves to
INA2 status.

4. When the record is authorized by a second authorizer, only then it moves to LIVE
status.

Note that the name of the second authorizer is appended in the field AUTHORISER.

CUS6 Introduction to Version-R10.01 12

 1. Unless all mandatory fields of an application are specified in a version, a record cannot be
committed using the version.

The example shows you the creation of an Account using a version. It displays an error
message when you commit the record. CURRENCY is a mandatory field in the ACCOUNT
application and that field is not part of the version used. If you miss out any of the mandatory
fields in the Version, when you create records using the Version T24 does not allow you to
commit the record. The version may be a customised screen but the underlying ACCOUNT
application works the same way in T24.

2. Certain applications in T24 has inter-dependent fields. Depending on values entered in

some fields, other fields are populated by the system. If the values defaulted can be
edited, they must be part of the screen to enable a user to do so.

CUS6 Introduction to Version-R10.01 13

 This is the workshop section of the learning unit.
1. Create a version for the CUSTOMER application.

2. The name of the version will be CUSTOMER,XXX (XXX is your initial)

3. The Fields that must be part of the version are

MNEMONIC,SHORT.NAME,NAME.1,STREET,SECTOR,ACCOUNT.OFFICER,INDUS
TRY,TARGET,NATIONALITY,CUSTOMER.STATUS,RESIDENCE,LANGUAGE.

Refer Captivate -Version-WS1_demo.cp

CUS6 Introduction to Version-R10.01 14

 The task here teaches you to create version that displays multiple fields in a line.

The requirement of the task is to:

1. Create a version for the ACCOUNT application with the following fields - Mnemonic,
Customer Number, Currency and Category.

2. The fields Mnemonic and Customer Number need to be displayed one beside the other

3. The fields Currency and Category need to be displayed one beside the other.

4. Labels must be user-defined.

CUS6 Introduction to Version-R10.01 15

 FIELDS.PER.LINE – When set to MULTI enables the display of multiple fields on the same
line. The fields MNEMONIC and CURRENCY are to be displayed on the same line.

Important Note: For muti-value fields the field name is appended with -1(hyphen one) in the
field FIELD.NO. For sub-value fields append the field name with .1(dot one).

COLUMN - Value required only if FIELDS.PER.LINE is set to MULTI. The first field
MNEMONIC will be displayed in column one. Also the field CURRENCY will be displayed in
column one.

CUS6 Introduction to Version-R10.01 16

 TEXT.CHAR.MAX – Defines the length of your label . The length defined here determines
the total number of characters included in the TEXT Field which includes spaces also. In the
example shown here, fields MNEMONIC and CURRENCY hold the value as eight(8) in the
COLUMN field . This makes the fields to be aligned properly in the version.

TEXT - You have to specify user defined labels for the fields. Specify the label in the field
TEXT. This is a sub-value field which can be expanded by itself to allow the label to be
entered in the various languages defined in LANGUAGE.CODE field. If no Text is entered by
the User, the Version screen will be presented without any Text for this specific field.

COLUMN - For the next field CUSTOMER COLUMN value is forty(40). Specify the other
fields also.

Do not forget to authorise your version record.

CUS6 Introduction to Version-R10.01 17

 1.Launch the version by specifying the version name in the command line. The version
name can also be suffixed with a valid T24 function to open the version in that particular
function mode. When you want to create a new account, you can specify
ACCOUNT,TRG.VERSION2 I F3 where, I denotes the input mode and F3 for auto id
generation.

2. You can see the new account created using the version.

CUS6 Introduction to Version-R10.01 18

 You can format the display of fields in version. You can have blank lines displayed between
fields. The previous example is modified to just include a blank space between the fields.

1. How do you make the CURRENCY field to appear after a blank line?

Specify an asterisk (*) in the field FIELD.NO to get a blank line. Since this blank space is
to be displayed before CURRENCY field , specify asterisk (*) before providing the
values for CURRENCY field in the associated multi-value set.

2. The output shows the blank space displayed between the two fields.

CUS6 Introduction to Version-R10.01 19

 1. Amend the version already created to display 2 fields in a row rather than one.

Refer Captivate -Version-WS2_demo.cp

CUS6 Introduction to Version-R10.01 20

 In this task you will learn how to default values into fields using a version. You will also learn
how to set special field properties.

The bank wants to create a user friendly version that has the following features:

1.The CURRENCY field should be defaulted to USD.

2.Also the user should not be allowed to change the CATEGORY field ,once the record is
authorised.

3. If there is an already existing value in the field ACCOUNT.TITLE.1 which begins with
TEM, then a value “Training” should get defaulted overwriting the previous value.

4. The SHORT.TITLE field should be a mandatory field in the version even though it is not in
the ACCOUNT application itself.

Can you design a customised screen for this requirement?

CUS6 Introduction to Version-R10.01 21

 T24 allows you to default values into fields using the VERSION application. When you open
a record with the version, the field will already have a value in it instead of being blank. To
accomplish this you need to use the fields AUTOM.FIELD.NO and AUT.NEW.CONTENT.

AUTOM.FIELD.NO – Specify the name of the field for which you need to default the value.
AUT.NEW.CONTENT – Specify the value that is to be defaulted here. (i,e ) USD.

There is one more property that you may choose to set for such a field – NOINPUT. The
NOINPUT property will prevent the users from inputting or amending the contents of this
field. NOINPUT fields appear greyed out when displayed. It is a multi value field hence
multiple fields can be made NOINPUT fields.

If you choose to make a mandatory field as a NOINPUT field, ensure that you default a
value for that field else you will not be able to commit a record using that version.

CUS6 Introduction to Version-R10.01 22

 You are required to ensure that the value in the CATEGORY field is not modified once the
record is authorised. To do this you use the property of NOCHANGE fields. Specify
CATEGORY as a NOCHANGE Field. Once the record is authorised fields defined here will
appear greyed out when displayed. In short, NOCHANGE fields are fields that become
NOINOUT fields after authorisation. Multiple fields can be displayed as NOCHANGE fields.

CUS6 Introduction to Version-R10.01 23

 If the value in the field ACCOUNT.TITLE.1 begins with TEM, then it should default the value
to TRAINING . How do you replace an existing value in a field? . To accomplish this you
need to use the fields AUTOM.FIELD.NO , AUT.OLD.CONTENT and AUT.NEW.CONTENT.
The value specified in AUT.OLD.CONTENT is replaced with the value in
AUT.NEW.CONTENT. This works like the find and replace option in windows.

AUTOM.FIELD NO – Here you will specify the field name as ACCOUNT.TITLE.1.

AUT.OLD.CONTENT- Specify the old value in AUT.OLD.CONTENT as TEM0X where,
TEM is the starting string
0X is like a wildcard character.
0X stands for any character and any number of characters.
AUT.NEW.CONTENT - Specify the new value as Training in the field AUT.NEW.CONTENT.

To default USD in the field CURRENCY no matter whether it is a new record or an existing
record with a value in the field CURRENCY, specify 0X in the field AUT.OLD.CONTENT .

CUS6 Introduction to Version-R10.01 24

 According to the task you have to make SHORT.TITLE as a mandatory field. To make a
field as mandatory you specify the field name in the MANDATORY.FIELD of your version.
This forces the user to enter value in that field else he will not be able to commit the record.
A non mandatory field in the application can be made a mandatory field in a version. Vice
versa is not possible.

CUS6 Introduction to Version-R10.01 25

 Here is the output,

1. When you use the version to create an account record, you could see that the value for
the field CURRENCY is defaulted as USD . SHORT.TITLE is a mandatory field in the
version.

2. The field CATEGORY has become a NOCHANGE field . The value for the field
ACCOUNT.TITLE has been modified from TEMENOS to TRAINING .

CUS6 Introduction to Version-R10.01 26

 1. Amend the previously created version so that

1.1 A value thousand(1000) is defaulted in the field SECTOR

1.2 Make SECTOR a NOINPUT field

1.3 A value IN is defaulted in the field NATIONALITY if the previous available

value is US

1.4 Make TEXT a mandatory field

1.5 Ensure that the value of ACCOUNT OFFICER is not changed once the
customer record is authorized.

Refer Captivate -Version-WS3_demo.cp

CUS6 Introduction to Version-R10.01 27

 1. Comma Versions are Auto-Auth Versions in T24.

2. Some of the comma Versions in T24, are

2.1 ACCOUNT,
2.2 FUNDS.TRANSFER,
2.3 CUSTOMER,

3. Records created using comma Versions are self-authorised records. Once you commit
the records they move to LIVE status .

4. In all comma Versions the NO.OF.AUTH field is set to 0(zero). These Versions does not
contain any fields.

5. VERSION, is the comma Version which is used to create auto-auth Versions in T24. Use
VERSION, from now on to create your versions .

CUS6 Introduction to Version-R10.01 28

 1. True
2. False
3. False
4. True
5. False

CUS6 Introduction to Version-R10.01 29

 1. The Rekey field is used in Version at the authorisation level.

2. This enables authorisers to re-enter the data in specific fields so as to re-confirm the
entry done by the Inputter. For example in an FUNDS.TRANSFER application, there are
sensitive data like amount, debit account no etc which are entered by an Inputter.

3. The rekey feature can prompt the Authoriser to re-enter the data for confirmation. If the
data entered by the Authoriser does not match with the Inputter, then the record does
not get authorised.

4. The data for the rekey fields are hidden during authorisation and the Authoriser needs to
compulsorily re-enter the information.

CUS6 Introduction to Version-R10.01 30

 This task helps in understanding the Rekey feature in version. Lets take an example of
FUNDS.TRANSFER application.

1. To create a version for funds transfer, you need to input a command as: VERSION,
FUNDS.TRANSFER,<VERSION NAME> for ex: VERSION,
FUNDS.TRANSFER,TRGFT in our case

2. Input the mandatory and required fields.

CUS6 Introduction to Version-R10.01 31

 Enter all the fields required in your version.

Field No.1: The name of the field in the FUNDS.TRANSFER application.

Text.1 : The name as it should appear in the version.

Tool Tip: On pointing the mouse the field description is displayed.

Rekey Field: These are the fields where the system will prompt the authoriser to re-enter
data for confirmation.

CUS6 Introduction to Version-R10.01 32

 1. Create a funds transfer record by typing the command FUNDS.TRANSFER,TRGFT

2. A new funds transfer application using the version is opened.

3. Click on new deal icon and the fields as required in the version application alone is
displayed.

CUS6 Introduction to Version-R10.01 33

 1. Input the data for Transaction type, Debit currency, Debit Account No, Debit Amount,
Credit Account No and commit the record.

2. Note the record key (ID) of the Funds Transfer that was created.

CUS6 Introduction to Version-R10.01 34

 1. When the record is opened in authorize mode the rekey fields are hidden, although
these fields are visible when the record is opened in the SEE mode.
2. Hit the authorize button and the system will prompt the user to re-enter value in the
rekey fields.
3. If the data entered by the Authoriser does not match with the Inputter data, the record
does not get authorised. The rekey fields are marked in red to denote incorrect data. No
error message are displayed at this point.

CUS6 Introduction to Version-R10.01 35

 1. Login as a different user to authorise the funds transfer record.

2. On Authorisation the system prompts the user to rekey the data for the fields that were
set to be rekeyed. The fields that need to be rekey are actually hidden from the Version
screen. Only if the data reentered matches with the one that was already input by the
inputter the record get authorised.

CUS6 Introduction to Version-R10.01 36

 1. What happens when a USER who is trying to authorize the record enters incorrect rekey
values multiple times ? The system records the number of incorrect rekey attempts by a
same authorizer, in a file called EB.REKEY.RETRIES. A record is created in this file
whenever a version that contains a rekey field is being authorized. The record id of
EB.REKEY.RETRIES would be of the format COMPANY*APPLICATION*RECORD.ID.

2. The maximum number of incorrect retries allowed for a USER who tries to authorize a
record can be restricted using the field NO.OF.RETRIES in SPF application. When this
field is left blank, there is no limit set for incorrect rekey attempts.

CUS6 Introduction to Version-R10.01 37

 1. If the number of incorrect rekeys by the same authoriser exceeds the NO.OF.RETRIES
specified on SPF, an error message “Exceeded Maximum Number of Retries” is
displayed. Also, the inputter field of the transaction is updated with the authoriser’s user
name. This is done so that the authoriser who exceeded the retries would not be able to
authorise anymore, even with the correct rekey value.
2. Hence, a different authorizer is required to authorize the same record.

CUS6 Introduction to Version-R10.01 38

 1. View is a user defined screen and can be created for any application in T24.

2. A version should always compliment the functionality provided by an application and not
overrule it.

3. Using a version you can input records , only when all the mandatory fields of the
application are part of your version.

4. The number of authorisers can be set to 0,1 or 2 in a version.

5. Special field properties like NOINPUT, NOCHANGE and MANDATORY can be set using
versions.

6. You can also default values into fields using versions.

7. Any additional functionality that an application must perform can be achieved by writing
local routines. But how are these routines executed? For example, for any date field in T24,
all that T24 does is validate the date according to the application business logic. What if the
client wants an additional validation? The VERSION application allows you to attach these
routines to perform these validations. These routines are known as User exits in T24.

8. Rekey field in VERSION enables enhanced verification by the authoriser in the Banking
System

CUS6 Introduction to Version-R10.01 39

 You have learnt Versions in T24. You can also create simple versions in T24. You will now
be able to,

1. Explain what a Version is in T24

2. Create simple Versions in T24

3. Launch Versions in T24

CUS6 Introduction to Version-R10.01 40

CUS6 Introduction to Version-R10.01 41
CUS6 Introduction to Version-R10.01 42