1

Allen and Cathy want to deposit cheques in bank ABC. Allen wants to deposit a local
cheque ,whereas Cathy has a foreign cheque . The teller has to fill these details in a
TELLER application. There are some fields that are required for a foreign cheque but
not for a local cheque. Example : Currency . How can we make things easier ?
T24 gives us the luxury of designing our own screens from a base application. Here,
TELLER is the base application. We cull out fields required for a local cheque and
design a screen .Similarly design one for foreign cheques. Now the tellers have to
invoke what they want ! Simple, isn‟t it?
Versions can be compared to the concept of “Views “ in Database Management
system . A database consists of huge volume of information which might not be
required for all users. So the users can create views, consisting of the columns that
they need . So a view is basically a customized look from a base table . When we use
a spreadsheet with multiple columns, we hide the columns that might not be necessary
and project those we need. Versions help us in creating our own screens with the
fields we want.
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 customized screen that showed
you only the fields that you require to input?

You can create customized application screens in T24. They are called versions. The
VERSION application must be used to create customized application screens. Your
version you can have just the mandatory fields in FUNDS.TRANSFER application.
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.
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.

To c reate a version in T24, you must create a record in the V ERSION application. The
format of the ID for the V ERSION application is T24A pplicationName,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.
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.
RECORDS.PER.PAGE –Do you want the version to display one record at a time or
multiple records? Where do you specify this?
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
FIELDS.P ER.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 LA NGUAGE value from the user profile of the person committing the
version record
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.
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

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,STREE T,SECTOR,ACCOUNT.OFFICE R,IN
DUSTRY,TARGET, NA TIONA LITY, CUS TOMER.S TA TUS,RESIDENCE,LANGUA
GE.

Refer Captivate -Version-WS1_demo.cp

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.

When using an application in T24 to create a new record, the record status is INA U
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 DEFA ULT. 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 A uth 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.
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 CA TEGORY 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 S HORT. 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?

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.
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

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 .
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
5. 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*RE CORD. ID.

6. 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.
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
3. 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.
4. Hence, a different authorizer is required to authorize the same record.
1. True
2. False
3. False
4. True
5. False
1. View is a user defined screen and can be created for any application in T24.

2. A version should always complement 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
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