Loading documents preview...
Creating VERSIONS in T24
DateOf Issue Dec 2004
Version
Changes
By
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 T2ITT – R05 – 1.0
Page 2 of 34
December 2004
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 , 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 T2ITT – R05 – 1.0
Page 3 of 34
December 2004
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 T2ITT – R05 – 1.0
Page 4 of 34
December 2004
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 / NN / NNN
•
For a multi value field - > N XX / NN XX / NNN XX
•
For a sub value field - > N XX XX / NN XX XX / NNN XX XX
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 T2ITT – R05 – 1.0
Page 5 of 34
December 2004
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
TEMENOS Training Publications T2ITT – R05 – 1.0
•
Toggle
•
Checkbox Page 6 of 34
December 2004
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 T2ITT – R05 – 1.0
Page 7 of 34
December 2004
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 T2ITT – R05 – 1.0
Page 8 of 34
December 2004
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
BUSINESS DAY
•
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.
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 T2ITT – R05 – 1.0
Page 9 of 34
December 2004
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>, where is user defined.
TEMENOS Training Publications T2ITT – R05 – 1.0
Page 10 of 34
December 2004
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 T2ITT – R05 – 1.0
Page 11 of 34
December 2004
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 T2ITT – R05 – 1.0
Page 12 of 34
December 2004
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 T2ITT – R05 – 1.0
Page 13 of 34
December 2004
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 T2ITT – R05 – 1.0
Page 14 of 34
December 2004
Versions in T24
Let us now take a look at how the version looks
TEMENOS Training Publications T2ITT – R05 – 1.0
Page 15 of 34
December 2004
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 T2ITT – R05 – 1.0
Page 16 of 34
December 2004
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 T2ITT – R05 – 1.0
Page 17 of 34
December 2004
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 T2ITT – R05 – 1.0
Page 18 of 34
December 2004
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 T2ITT – R05 – 1.0
Page 19 of 34
December 2004
Versions in T24
Changes in the version screen are shown below.
We have removed this field as a mandatory input field and added it to the no input field list
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 T2ITT – R05 – 1.0
Page 20 of 34
December 2004
Versions in T24
TEMENOS Training Publications T2ITT – R05 – 1.0
Page 21 of 34
December 2004
Versions in T24
TEMENOS Training Publications T2ITT – R05 – 1.0
Page 22 of 34
December 2004
Versions in T24
TEMENOS Training Publications T2ITT – R05 – 1.0
Page 23 of 34
December 2004
Versions in T24
TEMENOS Training Publications T2ITT – R05 – 1.0
Page 24 of 34
December 2004
Versions in T24
The screen shot below is the version when it is used online.
TEMENOS Training Publications T2ITT – R05 – 1.0
Page 25 of 34
December 2004
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 T2ITT – R05 – 1.0
Page 26 of 34
December 2004
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 T2ITT – R05 – 1.0
Page 27 of 34
December 2004
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 T2ITT – R05 – 1.0
Page 28 of 34
December 2004
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 T2ITT – R05 – 1.0
Page 29 of 34
December 2004
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 T2ITT – R05 – 1.0
Page 30 of 34
December 2004
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 T2ITT – R05 – 1.0
Page 31 of 34
December 2004
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 T2ITT – R05 – 1.0
Page 32 of 34
December 2004
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>,
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 T2ITT – R05 – 1.0
Page 33 of 34
December 2004
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 T2ITT – R05 – 1.0
Page 34 of 34
December 2004