CUS2.Creating Local Reference Fields

Welcome to the “Local Reference Fields in T24” learning unit.
This learning unit will

learn to create user defined fields and add them to static applications in T24.
CUS-Local Reference Fields 1

After completing this learning unit, you will be able to:
1. Explain the need for Local Reference Fields

2. Create Local Reference Fields
3. Attach them to applications in T24

T24 applications are self consistent and provide the end user with all the necessary
fields to store data pertaining to an application in general. Certain banks might want to
record some extra information with regard to an application which cannot be recorded
while using standard fields. So then, what would the bank do? Can it request Temenos
to add some new fields to the application code to store extra information? No.
Temenos might not do that, simply because not all the banks would need that field.
Then what is the solution? To cater to such situations, Temenos has introduced Local
Reference Fields which can be created in the particular client environment to meet
their need without affecting the actual application code.
Local reference fields are user defined fields and are totally customisable by the end
user.
Once these local fields are created, they can be reused in various applications across
T24.

1. To create a local reference field in T24, you would need to access two
applications. LOCAL.TABLE and LOCAL.REF.TABLE
1.1 The application LOCAL.TABLE is used to create the user defined field and set
properties of that field.
1.2 LOCAL.REF.TABLE is used to link the newly created field to any T24 application.
The process of creating the field is stand alone and therefore a field created can be
reused in any application in T24. You will learn to create a local field and attaching it to
an application in the next few slides.

You will now learn to create a local field. The ID of a record in this application was
numeric until R09 but from R10 it need not be numeric.
The field DESCRIPTION holds the description of the field.
SHORT.NAME field will hold the actual name of the field that you want to create. The
value given in this field will appear in the application you will attach this field to.
MAXIMUM.CHAR and MINIMUM.CHAR fields are used to denote the maximum and
minimum number of characters the local field can hold. If a value is defined in
MINIMUM.CHAR field, then the local field becomes a mandatory field.
The field CHAR.TYPE holds the information about what type of data can be input in
the local field created.
If you want to pre define values that can be stored in this field, then you can enter
possible values in the field VETTING.TABLE which can be multi valued to store
multiple values. However, it is not mandatory to pre define values into a field.
REMARK field is used to store the enrichment for the value in the VETTING.TABLE
field.

Now you are ready with the local field created which needs to be attached to an
application. LOCAL.REF.TABLE is used to link the local field to an application. The ID
of a record is the application name to which you want to attach the local field.
The field LOCAL.TABLE.NO is used to attach the ID of LOCAL.TABLE application.
SUB.ASSOC.CODE field is used to denote whether this local field is a multi value field
or a part of associated multi value set. Possible values in this field are as follows.
XX. denotes that this is a single Multi Value field.
XX< denotes the start of an associated multi value set.
XX- denotes that this is part of an associated multi value set.
XX> denotes the end of the associated multi value set.
If nothing is mentioned in this field, then it is a normal field in an application.
There are only two fields in this application which forms a multi value set.
Note that you cannot change the order of local fields. If you try to add a new local field
in between the existing local fields, you will not be able to commit the record. Also, a
local field once created cannot be deleted. Therefore care should be taken before
deciding to create one local field.

All the fields that appear on an application will have an entry on the
STANDARD.SELECTION record for that particular application. So then, do you have
to edit the SS record to add this local field that you have created just now? No. On
authorising a record in the LOCAL.REF.TABLE, the corresponding record in SS
application will get updated with the relevant data. Take a look at the CUSTOMER
record in SS application which is populated with the new field that is created.
Note that the field USR.TYPE is set to ‘I’ which denotes that this is an I-descriptor field
and is not stored with this name in the database. The physical field LOCAL.REF has
been multi-valued to hold the data of the newly created field. Note that this is the third
local field created for this application which is denoted as LOCAL.REF<1,3> in the
field USR.FIELD.NO.
The field USR.VAL.PROG contains the name of the IN2 routine that needs to be
invoked to perform data type validation. For this specific field the routine IN2A will be
invoked as you have set the field CHAR.TYPE to ‘A’ in LOCAL.TABLE application.
The other fields denote the display format and whether it is a single or multi value field
and if it is a language specific field.

You are done with creating the local field. So now, you should be able to see the local
field in the respective application. You have created a local field
VALUED.CUSTOMER and attached it to the CUSTOMER application. Open a new or
an existing CUSTOMER record, and you should be able to see the local field created
with all the features that you have set in the LOCAL.TABLE and LOCAL.REF.TABLE
applications. Note that the local field will be populated even in already existing records
in this application and not only in the new records. All the local fields will appear
towards the end of the record before the audit fields and in the order as they are
created.
Note the enrichment being displayed as defined in the LOCAL.TABLE application.

You have learnt to create a simple local reference field with out any complex
conditions. You will now learn the various fields involved in creating such fields from
LOCAL.TABLE application.
The field APPLICATION in this table denotes to which application this local field is
going to be attached to.
DECIS.FIELD holds the field name of the application defined in the previous field
whose value has to be checked to set a condition if any.
The field REPLACE.FILE is used to open an application with respect to the value in
the field DECIS.FIELD. This is used to drill down from one application to another to set
a condition while creating a local field.
REPLACE.FIELD holds the field name from the application in the previous field
against which condition is checked.
The DECISION field holds the operand against the field in REPLACE.FIELD
DECISION.FR and DECISION.TO fields are used to store the range of values to be
checked against the field. If the operand used is ‘EQ’, then you need not specify any
value in DECISION.TO.
As per the setting in the screen shot, using the CUSTOMER field in the ACCOUNT
application, the appropriate CUSTOMER record will be picked up and the value of

SECTOR will be checked. In the ACCOUNT record, the value for CATEGORY will be checked
against the value mentioned in the record.

The field OVERRIDE.POSSIBLE is used to specify whether input in the local field can
differ from the decision rules. If Y is input, the user may input a local reference that
does not meet the decision criteria in this table. The system will prefix the enrichment
with "OV!" and prompt the inputter for an override.
You can set the local field to default value if the conditions are met by setting the field
DEFAULT.POSSIBLE to YES. NOINPUT.CHANGE.FLD is used to denote whether or
not the local field is NOCHANGE after authorization or NOINPUT field.
If for a local field you want a drop down of the IDs of an application in T24, you must
specify the application name in the field APPLICATION.VET thus enabling the IDs to
form the drop down list. Note that the fields VETTING.TABLE and this are mutually
exclusive.
APPL.ENRICHM.FIELD is used to input a valid field name from the application
selected in the earlier field whose value should be given as enrichment for the local
field.

Create a local reference field ‘OFFICE.ADDRESS’ which should be a multi value field.
Maximum characters is 30 and it should be a mandatory field.

1. The local reference fields will be of type I-descriptor fields in
STANDARD.SELECTION application.
TRUE
FALSE
2. A local reference field created can be used in multiple applications in T24.
TRUE
FALSE
3. The ID of a record in LOCAL.TABLE application can be any alphanumeric text.
TRUE
FALSE
4. New local fields created can be inserted in between the existing fields in an
application in T24.
TRUE
FALSE
5. What does the value ‘XX-’ in the field SUB.ASSOC.CODE in LOCAL.REF.TABLE
application denote?
Multi value field
Starting of associated multi value set
Sub value field
Part of associated multi value set
6. A local reference field can never be set as ‘NOINPUT’ field.
TRUE
FALSE

1. Local reference fields are user defined fields and they are totally customisable by
the end user
2. The application LOCAL.TABLE is used to create the user defined field and set
properties of that field
3. LOCAL.REF.TABLE is used to link the local reference field to an application in

T24

In this learning unit you have learnt to create user defined fields and add them to static
applications in T24. You will now be able to ,
1. Explain the need for Local Reference Fields

2. Create Local Reference Fields
3. Attach them to applications in T24


CUS2.Creating Local Reference Fields

Uploaded by

Copyright:

Available Formats

CUS2.Creating Local Reference Fields

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

CUS2.Creating Local Reference Fields

Uploaded by

Copyright:

Available Formats

Welcome to the “Local Reference Fields in T24” learning unit.

This learning unit will

CUS-Local Reference Fields 1

1. Explain the need for Local Reference Fields

CUS-Local Reference Fields 2

CUS-Local Reference Fields 3

CUS-Local Reference Fields 4

The field DESCRIPTION holds the description of the field.

CUS-Local Reference Fields 5

CUS-Local Reference Fields 6

CUS-Local Reference Fields 7

Note the enrichment being displayed as defined in the LOCAL.TABLE application.

CUS-Local Reference Fields 8

CUS-Local Reference Fields 9

CUS-Local Reference Fields 9

CUS-Local Reference Fields 10

CUS-Local Reference Fields 11

CUS-Local Reference Fields 12

3. LOCAL.REF.TABLE is used to link the local reference field to an application in

CUS-Local Reference Fields 13

1. Explain the need for Local Reference Fields

CUS-Local Reference Fields 14

You might also like