3- Local Reference and Alternate Keys

TEMENOS T24

Local Reference and Alternate Keys

User Guide

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.


Table of Contents Introduction.............................................................................................................................................. 3 Application Overview ........................................................................................................................... 3 LOCAL.TABLE ................................................................................................................................. 3 Simple Value .................................................................................................................................... 4 Zeroes/Embedded Spaces............................................................................................................... 5 Vetting Tables .................................................................................................................................. 6 Vetting with decisions....................................................................................................................... 7 Value from T24 file ......................................................................................................................... 10 Other fields ..................................................................................................................................... 11 LOCAL.REF.TABLE ....................................................................................................................... 11 Drilldown......................................................................................................................................... 12 Help text ......................................................................................................................................... 13 User Defined Alternate Keys ............................................................................................................. 14 Introduction..................................................................................................................................... 14 EB.ALTERNATE.KEY .................................................................................................................... 14 Creating an Alternate Key .............................................................................................................. 16

TEMENOS T24 User Guide Page 2 of 18


Introduction Application Overview The LOCAL.TABLE and LOCAL.REF.TABLE applications allow the entry of additional local customised input fields on existing T24 applications without any program modifications.

Note: The addition of a local field is only valid on applications, which have already reserved a field called LOCAL.REF. This field is hard-coded in the application program.

The fields, which can be added, may be of the following types:

•

simple free-format single value fields.

•

multi-values.

•

associated with other LOCAL.REF fields.

•

have list of permitted values.

•

validate input against other T24 files.

•

format in local or foreign currencies.

•

Support various data types such as dates.

LOCAL.TABLE This application defines the characteristics of the individual local input fields which are required, i.e. name of the input field, the minimum and maximum number of characters, type of characters etc.

The local fields are referenced by a numeric code (maximum 4 digits).

A record can vary between simple fields input to a more complex decision based type.

Refer to the HELPTEXT for LOCAL.TABLE for further details on field validations.



Simple Value To add a local reference field that accepts any alphanumeric input requires a record as in below:

Since there is no value in MINIMUM.CHAR the system will accept any alphanumeric characters up to 35, blank is accepted i.e. the field is optional. To make it mandatory a value would be needed in the field MINIMUM.CHAR.

Figure 1 - Local Reference Table Input Screen



Zeroes/Embedded Spaces The field capabilities provided by local reference can be configured further for “Zeroes or Embedded Spaces”.

•

Zeroes/Leading Zeroes - Users who wish to add fields that contain a zero or leading zeroes can use this option. Where serial numbers etc. are required values such as 001567100 can be input, and when a displayed value of zero is required it will not be changed to a blank or null.

A value of ‘009’ in MAXIMUM.CHAR in LOCAL.TABLE will allow zero or leading zeroes up to 9 characters, whilst ‘01’ will allow 0-9 only.

•

Embedded Spaces - The ability to specify that a local reference field should be allowed to contain multiple embedded spaces. Text fields typically would not use more than one space between words, but with this option it is possible.

A value of ‘ 25’ (i.e. a space followed by 25) in MAXIMUM.CHAR in LOCAL.TABLE will allow a 25 character field that can contain multiple embedded spaces (e.g. A sample with many spaces).



Vetting Tables Vetting tables values are where the user is only allowed to input a pre-defined value from those entered in the LOCAL.TABLE record.

A simple example would be where only the values true or false are allowed, as in the screenshot below:

Figure 2 - Vetting Tables This example needs an answer; it must be True or False. Note the REMARK field is used to provide the enrichment for the field value.



Vetting with decisions A further option is the use of decisions in local reference fields. In conjunction with the vetting table values the next screenshot checks whether the currency of an LD contract is local currency not.

Figure 3 - Vetting with Decisions TEMENOS T24 User Guide Page 7 of 18


The decisions can be quite complex and can involve replacement files, where the value entered becomes the record id of another file and a value on this file is checked before applying the vetting table value. For example, a local reference to set the "BUSINESS" could be set up for MM.MONEY.MARKET and would work as follows:

Take the value in the CUSTOMER.ID field on MM.MONEY.MARKET, use that as the record id of the CUSTOMER file. If there is a code of 1000 in the SECTOR field on the CUSTOMER record set the value of “BANK” in the local reference field.





Value from T24 file To check the local reference value entered is a valid record on a T24 file a LOCAL.TABLE could be defined as follows:

Figure 4 - Check local reference value is a valid record The above screenshot example will check that the input is a valid record on the T24 CUSTOMER file and will use the field SHORT.NAME for enrichment purposes.



Other fields There are three other main fields not mentioned in the previous examples:

OVERRIDE.POSSIBLE

The user can override a value.

DEFAULT.POSSIBLE

The system can default a value instead of it being entered manually.

NOINPUT.CHANGE.FLD

The field can be made NOINPUT or NOCHANGE.

LOCAL.REF.TABLE This application defines the names of Input applications to which the local fields defined are to be linked and the order in which they are to appear on the screen. It also controls the association between any local reference fields that the user has defined as a set of fields.

It is important to note that once the local fields are linked to the application, i.e. LOCAL.REF.TABLE entry is Input and Authorised, it is not possible to delete or re-arrange the local fields. Only the descriptions or conditions defined on LOCAL.TABLE may be changed.

Once the LOCAL.REF.TABLE entry has been authorised the T24 system will automatically update STANDARD.SELECTION with the new customised fields and hence build the corresponding dictionary items. It will also then be possible to use these fields in reports and enquiries as well as adding HELPTEXT for the field to let the users know what the field is for.



In an extreme example, the fields added using LOCAL.TABLE and LOCAL.REF.TABLE could consist of several single value fields, unrelated to each other and some multi-value fields (not related to any other fields), and to make it more complex, two sets of multi-valued fields, which are associated but not with each other, i.e.:

Figure 5 - Local Ref Table fields The method of associating fields is explained in detail in the HELPTEXT for field SUB.ASSOC.CODE of the LOCAL.REF.TABLE file.

Drilldown Using the "!" option in classic T24 (or the drilldown button in BROWSER) from LOCAL.TABLE fields will take you to the VETTING application or to the LOCAL.REF record itself. The "_" option will give you the valid options defined in the VETTING.TABLE.



Help text New fields added to an application can have localised help text added. This HELPTEXT is in the format of:

APPLICATION*NEWFIELD-GB

For example a new field called REPORTS added to the FOREX application file would be entered into HELPTEXT as FOREX*REPORTS-GB.



User Defined Alternate Keys Introduction This feature enables the user to define any field, core T24 fields as well as Local Reference fields, in application as an alternate key. The alternate key can be used through out T24.

For example, consider a local field namely; CUST.ALT.INDEX in CUSTOMER is defined as an alternate key field.

In the CUSTOMER application, if the value in CUST.ALT.INDEX (i.e. the alternate customer key) is used as key input, the corresponding customer record is displayed.

CUSTOMER fields in applications like MM, FX (e.g. field CUSTOMER.ID in MM) will respect the alternate keys. The user will be able to specify the alternate customer number and the system will substitute it with the T24 CUSTOMER number. The length of the field is adjusted by the system to allow the alternate key that is always longer than the T24 key.

EB.ALTERNATE.KEY The EB.ALTERNATE.KEY can be used to define the alternate keys. The key for the EB.ALTERNATE.KEY is the name of the application for which the alternate key has to be defined.

This application forms the basis of the alternate keys in T24.

The user should specify the field to be used as the alternate key in ALT.KEY.FIELD. The length of the alternate key field can be greater than actual key field length but not less than that. The size of the field set as alternate key will form the alternate key’s length.

The system allows the user to decide the access methods. There are three options available:

•

READ

•

SELECT

•

@ROUTINE



The access method should be specified in the ACCESS.METHOD field. If READ is specified, then a concat file will be used to retrieve the T24 key. If SELECT is used, a select operation will be performed on a concat file if present. If a concat file is not present, the select operation will be performed on the application file. If a routine is defined then it will be called to retrieve the T24 key.

The system allows an option of having the alternate keys as unique or non-unique. This is specified in the field UNIQUE with the value as SYSTEM, COMPANY, NONE. If it is set to ‘SYSTEM’, the system will not allow duplicate alternate key. This applies throughout T24.

If UNIQUE field is set to ‘COMPANY’, the duplicate alternate keys are allowed across the company. That said, an alternate key can exist in different companies but cannot exist more than once in the same company. If ‘NONE’ is specified, then duplicate alternate keys are allowed across the companies as well as in the same company.

Company Mnemonic/Alternate Key For eg.

BNK\1424576877825

Where

BNK – is a valid company mnemonic (Field 3 in the COMPANY record)

The company mnemonic can be a mnemonic other than the current company.

An enquiry can be attached in the ENQUIRY field to show the results if more than one possible key has been found and whether none of the keys is for the current company.

Figure 1 - EB.ALTERNATE.KEY Application



Creating an Alternate Key The following example is provided to help set-up an alternate key in T24. The example provided is for the CUSTOMER application. A Local field is being used as an alternate key.

For the example below, a local field CUST.ALT.INDEX is created and the same is linked to CUSTOMER. The attributes of this field are:

•

The minimum number of characters is 10. This is because the length of the alternate key should always be more than the length of the key.

•

Alphanumeric field. Allows Alphabets and numbers.

For this example it has been decided that the access method will be READ mode and the alternate keys will be UNIQUE.

Setup the local field CUST.ALT.INDEX as an alternate key, •

Create a record in EB.ALTERNATE.KEY with key as CUSTOMER. as shown in the above Figure.

•

Specify the local ref field name (i.e. CUST.ALT.INDEX) to be set as an alternate key in the field ALT.KEY.FIELD.

•

Set the field ACCESS.METHOD to READ.

•

Set the field UNIQUE to ‘SYSTEM’.

•

Commit the record and authorise the same.

Figure 2 - Creating EB.ALTERNATE.KEY



Once the EB.ALTERNATE.KEY record is authorised, the alternate key system in T24 is “enabled”. To test the set-up, create a CUSTOMER record with an alternate key and use the alternate key in transactions.

Figure 3 - Customer record with alternate key The Alternate Key can now be used in the command line instead of the original key and the associated record will be launched.



Here a Money Market contract uses the Alternate Key in the Customer ID field.

Figure 4 – Customer ID populated using alternate key

When the field is validated the original Customer ID is populated.

Figure 5 - Customer record invoked using alternate key TEMENOS T24 User Guide Page 18 of 18

3- Local Reference and Alternate Keys

Recommend Documents