Adding New Field

Release: R19 AMR

May 2019

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, for any purpose, without the express written permission
of TEMENOS HEADQUARTERS SA.

© 2019 Temenos Headquarters SA - all rights reserved.

 Adding New Field

Table of Contents
Introduction 3
Purpose of this Guide 3
Intended Audience 3
Overview 4
Framework and Application 6
Framework 6
Application Exit points 6
Configuration 7
AA.CLASS.DEFINITION 8
EB.TABLE.DEFINITION 16
Deal Processing 22
AA Soft Class applications 23
Dynamic Applications 25

2
Adding New Field

Introduction
Purpose of this Guide
This document describes the T24 framework as a packaged methodology which
defines and maintains the tables.

Intended Audience
This User Guide is intended for the use of Internal Temenos users and Clients.

3 Introduction
 Adding New Field

Overview
Temenos Core Banking framework offers a packaged methodology to define and
maintain the tables. Temenos Core Banking acts as a master for such table defin-
ition and abstracts underlying artefacts being created at the database layer. This
methodology also ensures that the definitions are in sync with the Core Banking
application standards. These are popularly called as templates and are exposed
through versions and queried through Core Banking enquiries. Core Banking has the
ability to define templates through code and also through a codeless mechanism.
This new feature aims to improve such definition mechanism, so that the main-
tenance of underlying tables is more effective.
l This neighbour field feature facilitates in adding new fields to an existing tem-
plate without requiring a layout change.
l Definition of any new fields to be stored after Audit fields.
l Introduction of any fields as part of the existing multi-value or sub-value set
have to be defined within the multi value set only and stored after Audit
fields.
l This physical position is accessed for referring the record but not for screen
display or manipulation.
l By this way, future conversions can be avoided to rearrange the data to
ensure that the field values are stored in its relative positions.
Temenos Core Banking framework offers a packaged methodology to define and
maintain the tables. Temenos Core Banking acts as a master for such table defin-
ition and abstracts underlying artefacts being created at the database layer. This
methodology also ensures that the definitions are in sync with the Core Banking
application standards. These are popularly called as templates and are exposed
through versions and queried through Core Banking enquiries. Core Banking has the
ability to define templates through code and also through a codeless mechanism.
This new feature aims to improve such definition mechanism, so that the main-
tenance of underlying tables is more effective.
l This neighbour field feature facilitates in adding new fields to an existing tem-
plate without requiring a layout change.
l This feature can be used when there is no reserved fields available in the pos-
ition where new fields are need to be added in field definitions.
Generally to overcome conversion, when applications are defined in T24 it is
defined with maximum reserved fields possible in required positions or places
of field definitions. These reserved fields are nothing but the field’s position
reserved for future use. That is new fields can be introduced in future by
renaming this reserved fields (re-using this reserved position) for that cor-
responding T24 application requirement. This avoids the conversion as there
is no need to rearrange the existing data of that application to fit into the

Overview 4
Adding New Field

relative positions in Data base. The reserved fields again for multi value
groups should be defined exactly within the position to overcome conversions.
So when new fields has to be added within that multi value group, the
reserved field should exist in that group so that it can be renamed. But the
reserved fields drain out quickly with the constant requirement of T24 this
number of reserved fields are not helping permanently.
Considering these in order to ensure that we don’t constantly release con-
versions, using Neighbour field feature the new fields can be added to an
existing application without requiring a layout change.
l By this way, future conversions can be avoided to rearrange the data to
ensure that the field values are stored in its relative positions.
Because, the definition of any new field’s value will be stored after Audit
fields upon record commit. Introduction of any fields as part of the existing
multi-value or sub-value set have to be defined within the multi value set
itself as like before and value will be stored after Audit fields upon record
commit. This is called physical order data record in database. This happens
according to the physical position defined for each newly added fields. By this
way conversions are avoided as Existing data in database not require con-
version. This neighbour field feature has intelligence to covert this physical
order record into a logical order for display. There is no change in display of
an application data records in screen.

5 Overview
 Adding New Field

Framework and Application

The framework and application have a clear distinction on how to refer to a field
position.

Framework
l It does not look up for a value with physical position.
l Ensures that only logical position is maintained.
l They are generally not distinguished between applications and cannot use
hardcoded position.
l Uses the definition of template to understand logical field position.

Application Exit points

l Applications always refer to physical positions.
l Framework provides the record or the copy of record in physical order.
l Applications refer to records and any definition parameters in the physical
order.
l Applications do not loop through a record and assume logical positions.

Framework and Application 6

Adding New Field

Configuration
T24 allows a Bank to create their own applications through codeless mechanism.
These are primarily applications that are created locally, as they do not have the
full capabilities of applications created using the template. But with the help of
neighbour feature, the basic capability of enhancing an existing application by
adding new fields are ease to maintain in template framework, AA soft class applic-
ations created using AA.CLASS.DEFINITION and Dynamic applications are created
using the EB.TABLE.DEFINITION. This new feature aims to improve such definition
mechanism, so that the maintenance of underlying tables is more effective.

7 Configuration
 Adding New Field

AA.CLASS.DEFINITION
The following setup is required based on which an existing AA soft class application
can be added with new fields using the neighbour field feature.
l Codeless mechanism of defining a template called as Dynamic applications or
Soft class applications.
l To add new fields to an existing AA soft class application through
AA.CLASS.DEFINITION, system auto populates PHYSICAL.POSITION field.
l For example, here CITY field has been added in-between an existing field lay-
out and its PHYSICAL.POSITION value is decided by system based on
AUDIT.DATE.TIME of that soft class application for which new fields are
added.
l For subsequent neighbour field insertion, the PHYSICAL.POSITION value is
decided by system based on maximum physical position already in use.

Configuration 8
Adding New Field

PHYSICAL.POSITION
It is auto populated by system based on AUDIT.DATE.TIME position of that applic-
ation for which new field being added or maximum physical position already in use
if any.
Technical information

9 Configuration
 Adding New Field

l Holds actual field number of a new field (called as neighbour field) added to
an existing dynamic application without requiring a layout change. Value
should always be greater than AUDIT.DATE.TIME position of corresponding
application to which this new field is added and should not exceed
“AUDIT.DATE.TIME position + Total number of neighbour fields”
l This physical position supplies to 15th position of this field’s T array and the
same is updated in its STANDARD.SELECTION
l An array conversion order is updated in PHYSICAL.ORDER and
LOGICAL.ORDER fields of STANDARD.SELECTION during authorization of
EB.TABLE.DEFINITION through AA.CLASS.DEFINITION
For example, AUDIT.DATE.TIME = 43 in STANDARD.SELECTION of this soft applic-
ation, then
l PHYSICAL.POSITION for first neighbour (new) field should be
AUDIT.DATE.TIME+1 = 43+1=44.
l PHYSICAL.POSITION for second neighbour (new) field should be
AUDIT.DATE.TIME + numberOfNeighbourFieldsExist +1 = 43+1+1=45
l PHYSICAL.POSITION for Nth neighbour (new) field should be
AUDIT.DATE.TIME + numberOfNeighbourFieldsExist + 1 = 43+N+1=NN
Where numberOfNeighbourFieldsExist can be identified manually from cor-
responding application’s STANDARD.SELECTION record.
Upon authorizing AA.CLASS.DEFINITION record, the EB.TABLE.DEFINITION record is
updated with CITY field.

Configuration 10
Adding New Field

It updates STANDARD.SELECTION of corresponding AA soft class applications with

new fields.
The list of soft applications for EV*PASSPORT record in AA.CLASS.DEFINITION is
based on its CLASS.TYPE = EVIDENCE.CLASS (id of AA.CLASS.TYPE table):

11 Configuration
 Adding New Field

STANDARD.SLEECTION is updated with

1. PHYSICAL.POSITION value in SYS.FIELD.NO for neighbour fields.
2. SYS.VAL.PROG gets updated as Physical position in T<15>.
3. PHYSICAL.ORDER and LOGICAL.ORDER fields which tells the order to which
an array to be converted from logical to phyiscal wise versa. We can tell in
other terms, these fields shows the mapping order to arrive at expected
order of an array.
These field gets updated only if T array 15th position of an application field(s) posi-
tioned as neighbour field.

Configuration 12
Adding New Field

STANDARD.SELECTION is updated with:

l CITY field with the physical position value in SYS.FIELD.NO and T<15> th value
in SYS.VAL.PROG (T array) fields.
l Fields of STANDARD.SELECTION – LOGICAL.ORDER and PHYSICAL.ORDER are
updated.

13 Configuration
 Adding New Field

PHYSICAL.ORDER- Holds the sequence of order in which the application data is

stored.
LOGICAL.ORDER- Holds the sequence of order in which the application data is dis-
played.
These field gets updated only if T array 15TH position of an application field(s) are
positioned as neighbour field. Generated insert also contains new neighbour field
with physical position pointed.

Configuration 14
Adding New Field

15 Configuration
 Adding New Field

EB.TABLE.DEFINITION
The following setup is required based on which an existing Dynamic application can
be added with new fields using the neighbour field feature.
Inserting new fields to an existing dynamic applications created through
EB.TABLE.DEFINITION will auto populates PHYSICAL.POSITION field, and upon
authorising this record will update physical position in SYS.FIELD.NO of its
STANDARD.SELECTION as part of those new field’s properties. In addition, it updates
PHYSICAL.ORDER, LOGICAL.ORDER fields.
PHYSICAL.ORDER – Holds the sequence of order in which the application data being
stored.
LOGICAL.ORDER – Holds the sequence of order in which the application data being
displayed
This is base for neighbour feature to function.

Configuration 16
Adding New Field

17 Configuration
 Adding New Field

JOINT.HOLDER.ADDRESS and MOBILE.NUMBER new fields are added and it got

updated with PHYSICAL.POSITION field. The ADD.SPECIAL.FIELDS in
EB.TABLE.DEFINITION used to add special fields such as XX.LOCAL.REF,
XX.DELIVERY.REF, XX.STMT.NO, and these fields also can adopt for this neighbour
feature when adding it up. Its physical position stored in STANDARD.SELECTION is
used by system for any further processing of this application field.

Configuration 18
Adding New Field

PHYSICAL.POSITION
It is auto populated by system based on AUDIT.DATE.TIME position or maximum
physical position already in use with that application for which new fields has been
added.
It holds actual field number of that new field (called as neighbour field) added to
that existing dynamic application without requiring a layout change. Value always
greater than AUDIT.DATE.TIME position but not exceed ‘AUDIT.DATE.TIME position
+ Total number of neighbour fields’.
This physical position supplies to 15th position of this field’s T array and the same is
updated in its STANDARD.SELECTION.
The array conversion order is updated in PHYSICAL.ORDER and LOGICAL.ORDER
fields of STANDARD.SELECTION during authorisation of record in
EB.TABLE.DEFINITION.
For example, AUDIT.DATE.TIME value is 25 in STANDARD.SELECTION of this
dynamic application, then
l PHYSICAL.POSITION for first neighbour (new) field should be
AUDIT.DATE.TIME + 1 = 25+1 = 26
l PHYSICAL.POSITION for second neighbour field should be
Highest physical position used + 1 = 26+1 = 27
STANDARD.SELECTION record updated with
1. PHYSICAL.POSITION value in SYS.FIELD.NO for neighbour fields.
2. SYS.VAL.PROG updated with Physical position (that is equivalent of T<15>)
3. PHYSICAL.ORDER and LOGICAL.ORDER fields that tells the sequence of order
to which an record array to be converted from logical to physical wise versa.
Any neighbour field added to an application will have corresponding details in its
STANDARD.SELECTION as shown in this picture.

19 Configuration
 Adding New Field

Configuration 20
Adding New Field

Generated insert also contains new neighbour field with physical position pointed.

21 Configuration
 Adding New Field

Deal Processing

Deal Processing 22
Adding New Field

AA Soft Class applications

Design time soft application EV.DES.PASSPORT defines the conditions. The (neigh-
bour) CITY field appears in expected position as display below.

The run time soft application EV.EVIDENCE.PASSPORT’s child application spawned

during EV.EVIDENCE parent application validation or commit also displays the
(neighbour) field.

23 Deal Processing
 Adding New Field

Deal Processing 24
Adding New Field

Dynamic Applications
The newly added neighbour fields named JOINT.HOLDER.ADDRESS and
MOBILE.NUMBER are appearing in expected logical position as defined.

View of record after commit and authorisation:

25 Deal Processing