DEV1.T24 Template Programming-R10

T24 Template Programming
TEMENOS EDUCATION CENTRE

NOTICE
These training materials are the copyrighted work of Temenos Headquarters SA and other companies in the TEMENOS group of companies
(The Copyright Owner). The training materials contain protected logos, graphics and images. Use of the training materials is restricted solely for
use by licensed end users, partners and employees. Any un-licensed reproduction by any means, redistribution, editing, transformation,
publishing, distribution, or public demonstration of the training materials whether for commercial or personal gain is expressly prohibited by law,
and may result in severe civil and criminal penalties. Violators will be prosecuted to the maximum extent possible. Such training materials shall
not be represented
represented, extracted into or included in part
part, or in whole
whole, as part of any other training documentation without the express permission of
the Copyright Owner, which must given in writing by an authorised agent of the Copyright Owner to be valid. Where such permission is given a
clear and prominent notice must be displayed on any and all documentation accrediting the Copyright Owner with having copyright over the
materials. End-user licenses will in no event contain permissions extending the use of these training materials to third parties for commercial
training purposes.
Without limiting the foregoing, copying or reproduction of the training materials in part or in whole to any other sever or location for further
reproduction or redistribution is expressly prohibited, unless such reproduction is expressly licensed by the Copyright Owner.
Copyright © 2010 Temenos Headquarters SA
Version History
Version Date Author Reviewer
1.0 1st March 2009 Alamelu SenthilNathan
2.0 1st February 2010 Alamelu SenthilNathan
Slide 2
Objectives
At the end of the session you will have
 Adequate knowledge to understand

 How applications work in T24
 Adequate knowledge to create

 Applications in T24 version R7 and above
 Applications in T24 version R5 and below
 Adequate knowledge to
 Write code to raise accounting entries, overrides, errors, validations
 Create Multi threaded subroutines
Slide 3
Day wise Agenda
 Day 1
 An introduction to TEMPLATE programming
 Understanding the TEMPLATE subroutine
 Day 2
 Understanding THE.TEMPLATE flow
 Day 3
 Discuss the DEBIT CARD example
 Creating Fields in an Application
 Day 4
 Creating required applications
Slide 4
Day wise Agenda
 Day 5
 Validations and Workshops
 Day 6
 Overrides & DAS
 Workshops
 Day 7
 Multithreading
M ltith di
 Running as COB and Service
 Workshop
Slide 5
Day wise Agenda
 Day 8 & 9
 Accounting
 Workshop
 Writing better code workshop
 D 10
Day 10, 11 & 12
 Extra Information
 Templates in R5
 Workshop
 Comparison between R5, R7 and R9 templates
Slide 6
Day 1
Day 1
 An introduction to TEMPLATE programming
 Understanding g the TEMPLATE subroutine
Slide 7
g1
What Is An Application In T24?
n1
 T24 Applications
 Allows input of data
 Stores data in database
 Performs a business functionality
 Example: Funds Transfer, Money Market
 T24 Tables
 Allows input of data
 Stores data in database
 Holds static data used by other applications
 Performs no business functionality on its own
 Example:
p Category,
g y Currency y
Slide 8
Slide 8
n1 Read the document for Template Programming in R10 for a detailed understanding of the course
nausheen, 2/17/2010
g1 Since this is elearning course instead of giving numbers 1 & 2 in the notes page please mention that explanantion for no. 1 is for What
is an application. and explanation for no. 2 is for What is a Table.
e.g. start the notes page like What is an application?

then explanin what it is, explain each point in brief as writeen on the slide. give examples of an applications in T24
Follow the same for What is a Table? Since no. 2 has started directly with it is similar to applications will lead to confusion for
elearning team. Explain each point in brief for T24 Tables and give examples of Tables in T24
gshital, 4/5/2010
g2
Applications in T24
 There are different kinds of applications in T24

 H type
 U type
 L type
 T type
 W type
 At database level depending on the kind above, there can be

 A $HIS file (Data)
 A $NAU file (Data)
 A Live file (Data)
 A ]D file (Dict)
Slide 9
Slide 9
g2 Since L T & W type application contains only live file explain the difference among these 3 types with example.
gshital, 4/5/2010
Functions in T24
 There are different functions that can be used with these applications
 I Input
 A Authorise
 S See
 L List
 V Verify
 C Copy
 D Delete
 R Reverse
 H History Restore
 2 Second Authoriser
 P Print
 Q Audit
Slide 10
Application Classification
 Applications can be broadly classified in any of the three categories

 CUS
 FIN
 INT
 Other classifications
Oth l ifi ti available
il bl ttoo, b
butt h
have properties
ti off one off th
the
above
 Naming conventions for database files
 CUS – F<MNE>.<APPLICATION>{$<SUFFIX}
 FIN – F<MNE>. <APPLICATION>{$<SUFFIX}
 INT – F. <APPLICATION>{$<SUFFIX}
Slide 11
Definitions from T24
 What is an Application in T24?

 An application in T24 allows input of data and performs some business
processing too.
 What is a Table in T24

 A table
t bl ttoo stores
t data,
d t static
t ti data
d t that
th t can be
b used
d by
b one or more
applications
 What is a Product?
 One or more applications and tables that work together to perform a
business functionality
Slide 12
Before Creating An Application
 W mustt decide
We d id a name ffor our application
li ti
 What type of application (H, U, L, T, W)
 What classification (CUS, FIN, INT)
 W mustt decide
We d id what
h t ffunctions
ti are going
i tto be
b permitted
itt d
 We must decide fields

 Data
D t types
t
 Max, Min Characters
 Field Names
 Extra validations of data
 Other related file updates
 What is the business functionality to be built in
Slide 13
s2
g3
Application flow in T24 – Always the same
1. Enter Application
pp Name
T24 checks if a VALID Application is entered.
2. Enter Function and ID
When data is entered and we hit enter, T24 validates it as a function.
When we enter data and hit the edit button, the function is taken as I and the
data is validated as an ID of the application
3. Open record
Checks if record exists with same ID, if yes read from file and load into cache
If record does not exist, open new record for user.

user
Slide 14
Slide 14
s2 When explaining this slide you must demo to them so that they will actually accept this flow. First you can launch an invalid
application, and then you can use a correct application name but with an invalid function etc. If your batch of trainees is not freshers,
then you can ask them to try this out instead of a demo by you. This too is a really important slide and a demo by you will make the
‘flow of an application’ in T24 crystal clear.
sara, 4/28/2009
g3 Instead of using 'we' in the notes page make usage of 'you' or 'user' explain each step in the flow in brief not all steps are explained
here in the notes page
gshital, 4/5/2010
s5
g12
Application flow in T24 – Always the same
4. Enter Data and Commit
Validates data, raises errors or overrides and saves record in database
5. Authorise Record
If everything is OK, save changes in the database, update other applications if

required
S d advices
Send d i t
to customer
t (if any)
)
Slide 15
Slide 15
s5 When explaining this slide you must demo to them so that they will actually accept this flow. First you can launch an invalid
application, and then you can use a correct application name but with an invalid function etc. If your batch of trainees is not freshers,
then you can ask them to try this out instead of a demo by you. This too is a really important slide and a demo by you will make the
‘flow of an application’ in T24 crystal clear.
sara, 4/28/2009
g12 Instead of using 'we' in the notes page make usage of 'you' or 'user' explain each step in the flow in brief not all steps are explained
here in the notes page
gshital, 4/5/2010
g4
We have decided
Business Functionality
When and What we must do
Other Features
-Functions
F ti My new
-Product Information Application
-Type of Application H, U. L etc.,
-Classification FIN, CUS, INT etc.,
T24 Application Flow
Slide 16
Slide 16
g4 Remove 'we' as explained before
Explain each box in brief that to create an application these many steps required to take.
gshital, 4/5/2010
Code…
 If we want to develop an application in T24, do we have to start writing

code from scratch?
 NO NO NO
 There are two core subroutines called TEMPLATE and

THE.TEMPLATE that we must use to create an application
 That’s why this course is called TEMPLATE PROGRAMMING 
Slide 17
What now…
Business Functionality
When and What we must do
METHODS
Other Features
-Functions
F ti My new
-Product Information Application
-Type of Application H, U. L etc.,
-Classification FIN, CUS, INT etc.,
Properties defined in TEMPLATE
T24 Application Flow

THE TEMPLATE
THE.TEMPLATE
Slide 18
s3
Common Variables
 Variables in T24
 Global
 Local
 Most variables used in TEMPLATE programming can be found in

I_COMMON
 Application / Product specific common variables also available

 I_ENQUIRY.COMMON
 I_GTS.COMMON etc
 Must include I_ file in all code
 $
$INSERT I_File - will look for I_ file in current directory,
y, T24.BP and
bnk.run
 $INCLUDE <Dir> I_File– must specify the directory in which file is

present . Better to not use $INCLUDE.
$INCLUDE
Slide 19
Slide 19
s3 Many trainees are confused with the contents of COMMON insert files and Application insert files. Clear the air at this point in time.
This is because the INSERT statment is used for both
sara, 4/28/2009
A Must Know
 Following common variables need to be understood before we attempt to

create version routines
 ID.NEW
 ID.OLD
 ID.NEW.LAST
 R.NEW()
 R.OLD()
 R.NEW.LAST()
 All the above mentioned variables are common variables defined in

I COMMON
I_COMMON.
Slide 20
What Happens When A New Record Is Created In T24?
 User creates new CUSTOMER record using CUSTOMER I F3

 When record is committed…
ID.NEW : 123456 ID.NEW.LAST - NOT USED ID.OLD - NOT USED
R.NEW R.NEW.LAST R.OLD

Mnemonic : TRG
Name.1 : TRG
Street : RANGA ROAD
Sector : 1100 NOT USED NOT USED
Target : 999
Customer Status : 1
Nationality : IN
Residence : IN
Language : 1
Record Status :
Slide 21
ID.NEW
 Common variable defined in I_COMMON
 Contains the ID of the currently opened record in any application
 When the record is closed or committed or authorised the value in this

variable gets flushed.
Slide 22
R.NEW
 Dimensioned array which comprises of 500 dynamic arrays
 Holds the currently opened record in any application
 ID.NEW holds the ID of the currently opened record, while R.NEW holds the
actual record. ‘R’ in the variable name stands for ‘Record’
Definition as seen in II_COMMON

COMMON : DIM R
R.NEW(C$SYSDIM)
NEW(C$SYSDIM)
Where C$SYSDIM = 500
 Inference : Since the size of R.NEW is now restricted to 500 it implies that
no application in T24 has more than 500 fields. The day it exceeds 500,
C$SYSDIM’s value will be increased
Slide 23
When Happens When A Record Is Authorized?
 User opens INAU record to authorise it
ID.NEW : 123456 ID.NEW.LAST – 123456 ID.OLD – Not Used

Mnemonic : TRG Mnemonic : TRG
Name.1 : TRG Name.1 : TRG
Street : RANGA ROAD Street : RANGA ROAD
Sector : 1100 Sector : 1100 Not Used
Target : 999 Target : 999
Customer Status : 1 Customer Status : 1
Nationality : IN Nationality : IN
Residence : IN Residence : IN
Language : 1 Language : 1
Record Status : INAU Record Status :INAU
Values from R.NEW only are written into the database when record is COMMITTED/AUTHORISED
Slide 24
ID.NEW.LAST
 If an unauthorized record exists for the currently opened record in any

application, this variable will hold the ID of the unauthorized record
 You may ask, ‘Will the ID of a live record and a unauthorized record
ever be different?”
 No. This variable enables us to know, programmatically whether an
unuathorised record exists for the currently opened record
Slide 25
R.NEW.LAST
 Holds the currentlyy opened

p record in any
y application
pp
 ID.NEW.LAST holds the ID of the currently opened record’s unuathorised

record (if it exists), while R.NEW.LAST holds the actual unauthorized record
(If it exists). ‘R’ in the variable name stands for ‘Record’
Definition as seen in I_COMMON : DIM R.NEW.LAST(C$SYSDIM)

Slide 26
What Happens When An Authorized Record Is Amended?
ID.NEW : 123456 ID.NEW.LAST – NOT USED ID.OLD - 123456

Mnemonic : TRG Mnemonic : TRG
Name.1 : TRG Name.1 : TRG
Street : RANGA ROAD Street : RANGA ROAD
Sector : 1100 1200 NOT USED Sector : 1100
Target : 999 Target : 999
Customer Status : 1 Customer Status : 1
Nationality : IN Nationality : IN
Residence : IN Residence : IN
Language : 1 Language : 1
Record Status : Record Status :
Values from R.NEW only are written into the database when record is COMMITTED/AUTHORISED
Slide 27
ID.OLD
 If an authorized record exists for the currently opened record in any

application, this variable will hold the ID of the authorized record
 This variable enables us to check programmatically whether the

currently opened record has a previously authorized record
Slide 28
R.OLD
 Holds the currently opened record’s previously authorized record (if

any) in any application
 ID.OLD holds the ID of the currently opened record’s authorised record

(if it exists), while R.OLD holds the actual live record (If it exists). ‘R’ in
the variable name stands for ‘Record’
Definition as seen in I_COMMON : DIM R.OLD(C$SYSDIM)

Slide 29
g5
What Happens When A Change On An Authorized Record Is Authorized?
The
The old authorized record (With Sector 1100) goes to history (FBNK.SECTOR$HIS)
ID of the record in the history file will be 123456;1
Contents
C t t off R.NEW
R NEW is
i written
itt tot the
th LIVE file
fil
ID.NEW : 123456 ID.NEW.LAST - 123456 ID.OLD - 123456

Mnemonic : TRG Mnemonic : TRG Mnemonic : TRG
Name.1 : TRG Name.1 : TRG Name.1 : TRG
Street : RANGA ROAD Street : RANGA ROAD Street : RANGA ROAD
Sector : 1200 Sector : 1200 Sector : 1100
Target : 999 Target : 999 Target : 999
Customer Status : 1 Customer Status : 1 Customer Status : 1
Nationality : IN Nationality : IN Nationality : IN
Residence : IN Residence : IN Residence : IN
Language : 1 Language : 1 Language : 1
Record Status : INAU Record Status : INAU Record Status :
Slide 30
Slide 30
g5 Please mention that this record is opened for authorisation that's why R.NEW and R.NEW.LAST hold the same copy in this case record
is committed and opened for authorization
Need to verify following point

If the record we have requested is in INAU status, the record from file is loaded into R.NEW.LAST and the record is displayed to the
user for further modification, the copy that the user is looking at is R.NEW. In this case record is not committed it's in INAU status
Mention both cases in the notes page the explanation given in the notes page is not enough R.NEW.LAST is not at all explained in the
notes page
gshital, 4/6/2010
Common Variables – I_COMMON
We must learn the use of these common variables before we continue
 V$FUNCTION – Holds the T24 function entered by the user
 MESSAGE – Allows inter routine or inter para communication by

setting process ‘state’ in this variable
 AF, AV, AS – Holds the field position, multi value position and sub
value position respectively
 E and ETEXT – Variables used to store error message to be displayed.

E is used by THE.TEMPLATE itself to display errors if any
 ID.COMPANY and R.COMPANY – Variable that holds the ID of the

company we are currently logged into and the COMPANY record is
loaded into R
R.COMPANY
COMPANY
Slide 31
Some more Common Variables
 R.USER - Loaded as soon as the user logs in, holds the USER profile
 OPERATOR – ID of the User currently logged in
 APPLICATION - Holds the name of the application currently in use. In

T24 only one application can be active at a given point in time
 LCCY, LNGG
 Holds Local Currency as defined in company
 Holds the language from the USER profile
 TODAY - Holds T24’s today (date)
 C$SYSDIM – Common variable equated to 500 in II_COMMON,

COMMON, used to
define the size of all dimensioned array common variables
Slide 32
The TEMPLATE Subroutine
Static Information or Properties of our application
 Use core subroutine TEMPLATE (T24.BP)
 We must decide a name for our application
 What type of application (H, U, L, T, W)
 What classification (CUS, FIN, INT)
 We must decide what functions are g

going
g to be p
permitted
 Why do we need to mention all this?

 To create additional components of an application
Slide 33
Other Component of an Application
s19
 What does T24 do with all the properties of the application we define in
the TEMPLATE subroutine?
 There are other components of an application other than code
 PGM.FILE Entry
 Type of application
 Special properties (additional info)
 FILE.CONTROL Entry
 File suffixes available
 Classification
Slide 34
Slide 34
s19 Do not discuss how to create these right now, but discuss the use of each
salamelu, 2/20/2009
s21
 STANDARD.SELECTION Entry
 Actual field names
 Field properties
Slide 35
Slide 35
salamelu, 2/20/2009
s48
 Insert File - I_ File

 For programming
Slide 36
Slide 36
salamelu, 2/20/2009
s49
 Files at database level to store data

 To store data 
Slide 37
Slide 37
salamelu, 2/20/2009
Getting Started
 DO NOT MODIFY the TEMPLATE subroutine in T24.BP
 Each application that we create, must have its own copy of the
TEMPLATE
jsh-->COPY FROM T24.BP TEMPLATE TO DBCARD.BP
jsh-->COPY FROM DBCARD.BP TEMPLATE, <NEW APPNAME>
 The above line must be modified to reflect <NEW APPNAME> as the

name of the subroutine
 Properties of an application are defined here
Slide 38
g6
Table Objects
Table.name = 'XX.TABLE.NAME' ;* Full application name

Table.title = 'XX TABLE.NAME' ;* Screen title
Table.stereotype = 'H' ;* H, U, L, W or T
Table.product = 'XX' ;* Must be on EB.PRODUCT
Table.subProduct = ‘ ' ;* Must be on EB.SUB.PRODUCT
Table.classification = 'INT' ;* As per FILE.CONTROL
Table systemClearFile = 'Y'
Table.systemClearFile ;* As per FILE
FILE.CONTROL
CONTROL
Table.relatedFiles = '' ;* As per FILE.CONTROL
Table.isPostClosingFile = '' ;* As per FILE.CONTROL
Table.equatePrefix = 'XX.YY' ;* Use to create I_F.EB.LOG.PARAMETER
Table.idPrefix = '' ;* Used by EB.FORMAT.ID if set
Table.blockedFunctions = '' ;* Space delimited list of blocked
functions
Table.trigger = '' ;* Trigger field used for OPERATION style
Slide 39
Slide 39
g6 Need to specify from where this screen shot has been taken. In this case it is taken from TEMPLATE
please mention that
gshital, 4/5/2010
g7
How are the properties used?
 The ID of the FILE.CONTROL ,PGM.FILE and SS entry - Table.name
 The TYPE for the PGM.FILE record – Table.stereotype
 The SCREEN.TITLE in PGM.FILE record(Description) – Table.title
 The PRODUCT field in FILE.CONTROL and PGM.FILE –

Table.product
 The CLASSIFICATION field in FILE.CONTROL – Table.classification
 The prefix for all fields in the I_ files – Table.equatePrefix
 Functions that are not allowed for the application –

Table.blockedFunctions
Slide 40
Slide 40
g7 Mention that from the given list we can see that T24 gets information for the additional components of an application from the
information provided in TEMPLATE subroutine..
gshital, 4/5/2010
I_Table
s43
 Contains all common variables used in table object
COMMON/OBJECT.TEMPLATE/Table.fieldNeighbourArray(C$SYSDIM),Table.name,
Table.title,
Table.stereotype,
Table.product,
Table.subProduct,
Table.idPrefix,
Table.blockedFunctions,
Table.systemClearFile,
Table.relatedFiles,
Table.isPostClosingFile,
Table.equatePrefix,
bl fi
Table.triggerField,
Table.classification,
Table.noInputFields,
Table.inputtableFields,
Table lastApplication
Table.lastApplication,
Table.idPrefix,
Table.blockedFunctions,
Table.systemClearFile,
Table.relatedFiles,
Table.isPostClosingFile,
Table.equatePrefix,
Table.triggerField,
Table.lastCompany,
Slide 41
Slide 41
s43 Open I_Table and show the various common variables in that insert file, to get the trainees familiar about them
salamelu, 2/22/2010
How is TEMPLATE and THE.TEMPLATE related?
s22
 To launch an application, we type its name in the command prompt

 It is validated – VALIDATE.APPLICATION subroutine (after the browser
level checks)
• Checks PGM.FILE
 Calls RUN.APPLICATION which in turn calls

EB.EXECUTE.APPLICATION
 Calls subroutine with <APPLICATIONNAME>
 Subroutine APPLICATION name is nothing but a copy of TEMPLATE

with static properties, and the list of methods to be called
 EB.EXECUTE.APPLICATION also invokes THE.TEMPLATE
Slide 42
Slide 42
s22 Tell trainees to read the word document also, many points are left out on the slide
salamelu, 2/20/2009
SUBROUTINE EB.EXECUTE.APPLICATION(APPLICATION.NAME)
.
.
.
Table.name = ''
CALL @APPLICATION.NAME
IF Table
Table.name
name THEN
CALL THE.TEMPLATE ;* We need to call the central template routine
END ELSE
Table.lastApplication = "" ;* We've called a non central template
END
.
.
.
.
.
Note: In releases before R9, EB.EXECUTE.APPLICATION called the <Application>

Subroutine which in turn called THE.TEMPLATE
Slide 43
THE.TEMPLATE Subroutine
s6
 The core subroutine used by every application in T24 since it contains

the execution flow
 An application’s business logic is broken up into individual subroutines,

called method.
 THE.TEMPLATE contains code to call or invoke these methods at the

right time
Slide 44
Slide 44
s6 Explain about the flow in THE.TEMPLATE in general terms, before going into the actual methods. Refer the document.
salamelu, 2/20/2009
Methods in Template Programming
s7
 The business logic of an application is not part of TEMPLATE or

THE.TEMPLATE
 It is split up into methods
 There are 11 methods available for use
 THE.TEMPLATE determines the order of execution
 Methods are nothing but individual subroutines called from

THE.TEMPLATE
 M t follow
Must f ll naming
i convention
ti APPNAME.METHODNAME
APPNAME METHODNAME
Slide 45
Slide 45
s7 Though THE.TEMPLATE does not enforce any method as mandatory, Every application must have atleast one field, hence defining
.FIELDS method is essential.
salamelu, 2/20/2009
Methods
 Where are method names defined?
 Are they hard coded?
Slide 46
I_METHODS.AND.PROPERTIES
 Common variable to define method names
 Methods with different names ignored
Slide 47
 T24’s convention is to represent each position C_ROUTINES array by

a name not a number
Slide 48
Methods in Template Programming
s23
 INITIALISE
 FIELDS
 FUNCTION
 ID
 RECORD
 VALIDATE
 PREVIEW
 OVERRIDES
 PROCESS
 AUTHORISE
 RUN
 This is also the order in which they are executed by THE.TEMPLATE
Slide 49
Slide 49
s23 Dont discuss each method in detail now.. Ask the class what they think will be part of the methods
salamelu, 2/20/2009
Day 2
 Understanding THE.TEMPLATE flow
Slide 50
THE.TEMPLATE
 Pattern of Execution of an application
 MUST NOT BE MODIFIED
 Advantage of having THE.TEMPLATE

 We can maintain code consistency and code standard
 Enables rapid code development, no need to start from scratch
Slide 51
Behind the Scenes – THE.TEMPLATE
s9
Launch Application from Command Prompt
 Initialise
 The first method to be executed when an application is launched
 Fields
 The next method to be executed
Input Record ID and press Enter (Function defaulted to I)
 Function
 This is executed after a function is entered by the user. If no function is
entered the default is Input
entered, Input.
 ID
 Executed after the function entered is validated. Validated ID, can modify ID
if required
Slide 52
Slide 52
s9 Explain what methods will get called at what stage of exection. When you click on validate, all methods from .DEFAULT to .PROCESS
gets executed. Again when you click on commit button, all these methods get executed. Clicking on validate button, gives an overall
picture of what happens when the record gets committed, except that it does not call UNAUTH.RECORD.WRITE.
salamelu, 2/20/2009
 Record
 Executed before the record requested (existing or new) is displayed to the
user
Record requested is displayed (existing or new)

Data is input / modified, then Commit
 Validate
 After values are defaulted (if any) all data is validated
 Preview
 After data is validated, a delivery preview is available
 Overrides
 Overrides if any are generated now
Slide 53
 Process
 If all overrides are accepted, then this method is called before the record is
written to the $NAU file
Record is written to $NAU NOW
Authorise button is clicked
 Validate
 All data is validated twice,
twice once during commit and once during authorise
 Authorise
 This is executed after the Authorise button is clicked
Record is written to LIVE NOW

Run
 This is executed if the function used is Verify
Slide 54
Using the Template Methods – Common Variables Available
s24
 INITIALISE
 Anything that needs to be done as soon as an application is launched can
be done here. It is not a mandatory method
 FIELDS
 This is the method in which an applications fields are defined. This is a
mandatory method as an application must have at least one field
 FUNCTION
 Code that need to be executed depending on the function entered,
manipulation of the function itself can be done here (V$FUNCTION)
Slide 55
Slide 55
s24 Disucss the use of the methods in detail and also make sure you mention from which method onwards, what common variables are
available for manipulation....
salamelu, 2/20/2009
s50
 ID
 Special editing to the ID entered, special validations to the ID (ID.NEW)
Slide 56
Slide 56
salamelu, 2/20/2009
s51
 RECORD
 Editing of the requested record before display to the user (R.NEW,
R.NEW.LAST,R.OLD)
Slide 57
Slide 57
salamelu, 2/20/2009
Using the Template Methods
The methods listed here are executed after Commit is clicked
 VALIDATE
 Special validation of data
 R.NEW, R.NEW.LAST, R.OLD, E, Subroutine ERR
 OVERRIDES
 Overrides if any, must be raised here
 R.NEW, R.NEW.LAST, R.OLD, ETEXT, Subroutine STORE.OVERRIDE
Slide 58
The method listed here are executed after Commit is clicked
 PROCESS
 Processing that has to be done before the record is written to the $NAU file
Limits
Accounting
Charges
Slide 59
The methods listed here are executed after Authorise is clicked
 AUTHORISE
 Processing to be done before record is written into LIVE file
Accounting
Delivery
Updating associated applications
 RUN
 This method is called only for W type applications that use the Verify
function
Slide 60
What Can Applications In T24 Do?
 The ability to have custom validations for data entered
 The ability to be customised (add extra functionality) by clients if

required
 The ability to raise overrides and errors
 The ability to generate delivery advices (1 or more)
 The ability to raise accounting entries
 The ability to raise charges
 The ability
abilit to add / remo
remove
e fields
 Associated COB processing if required
Slide 61
Digging Deep - THE.TEMPLATE
 Launch an application from the prompt
 Core subroutine VALIDATE.APPLICATION called

 Checks PGM.FILE Entry
 Checks if application can be used in GUI
 Checks User SMS
 Checks valid token for browser
Slide 62
 RUN.APPLICATION is now called which in turn calls

 This calls
Thi ll a subroutine
b ti with ith th
the application
li ti name – nothing
thi b butt th
the
subroutine which a copy of TEMPLATE
 EB EXECUTE APPLICATION also calls THE

EB.EXECUTE.APPLICATION THE.TEMPLATE
TEMPLATE
 INITIALISE Method invoked first
 Application ready to receive input of function or ID
Slide 63
 On hitting enter, the application thinks we have entered a function and

validates that – FUNCTION method
 With any input, if we click the Edit button, it validates the data against
the ID of the application – ID method
Slide 64
 Core routine RECORD.READ called to fetch the requested record

 Searches in
 Search in the $NAU File for the application
 Search in the Live File for the application
 Search in the $HIS File for the application
 El di
Else displays
l new record d
 Before displaying record, RECORD method executed
 FIELD.INPUT and FIELD.DISPLAY are two core routines that take care
of displaying the application screen
 FIELD.MULTI.INPUT, FIELD.MULTI.DISPLAY routines available to

deal with multiple fields per line if using version
Slide 65
 Click
Cli kCCommit
it or V
Validate
lid t andd th
then…
 Can move on only after correcting errors
 VALIDATE method
Slide 66
s42
 Can view
C i preview
i off d
delivery
li message after
ft validation
lid ti
 .PREVIEW has to be set in ‘Additional Info’ field in PGM.FILE
 PREVIEW method
 P i
Preview generated
t d using
i core routine,
ti EB
EB.HANDOFF
HANDOFF
Slide 67
Slide 67
s42 Make the trainees input an FT. After validation, view the' delievery outref' and 'delivery inref' id's updated in the FT record. Click the
preview icon. Note the delivery preview pop up window.
Note: Ensure 'Dr Advice Reqd' and 'Cr Advice Reqd' fields in FT.TXN.TYPE.CONDITION is set to 'Y'.
For any application to generate preview of delivery advices, supporting code has to be provided in .PREVIEW method.
salamelu, 2/12/2010
 Overrides
O id come nextt
 No option to reject overrides, just change data and Commit again
 OVERRIDES method
Slide 68
 PROCESS method executed

 UNAUTH.RECORD.WRITE called to update $NAU file in database
 Constraint processing invoked if any – Used to set user defined conditions
and overrides
 STP processing done here if set – Used for automatic authorization
versions based on conditions
 Version routines invoked if using version
 Audit fields updated
 Existing INAU record over written if any
 Deals slips triggered if any
 Everything is going to be ok…
Slide 69
 Record opened for authorisation
 VALIDATE method
 AUTHORISE method
 AUTH.RECORD.WRITE called to update Live file

 Call version routines if any
 Update CONCAT files if any
 Update AUDIT fields
 Update JOURNAL
Slide 70
JOURNAL ???
 F.JOURNAL
 Used for recovery purposes before
 F.JOURNAL at any given time will only hold the last 20 transactions per user
 Replaced with jBASE Transaction Journaling
 F WRITE writes
F.WRITE it tot cache
h
 FWC, FWT, FWF
 JOURNAL.UPDATE flushes data to disk from cache
Note: F.JOURNAL will hold the transaction details only if the field INFO.JOURNAL in SPF is
set to YES.
Slide 71
Day 3 & 4
 Discuss the DEBIT CARD example
 Creating
g Fields in an Application
pp
 Creating required applications
Slide 72
DEBIT CARD EXAMPLE
DEBIT CARD EXAMPLE
Slide 73
Debit Card Example
 Let us now create an application on our own - Read the Business

Specification now
 To provide the Debit Card feature in T24 we need to

 Create an application that will store all debit cards issued
 Create an application that will store parameter values
 Create an application that will store different types of debit cards available
 Create an application that will store all debit card transactions
 We must make sure to create a directory to keep the code that we are
going to write
jsh-->CREATE.FILE DBCARD.BP TYPE=UD
jsh-->COPY FROM T24.BP TO DBCARD.BP TEMPLATE
Slide 74
Debit Card Example
s25
 To create any type of application, we must make a copy of the

TEMPLATE subroutine from T24.BP
jsh-->COPY FROM DBCARD.BP TEMPLATE,APPLICATIONNAME
 To create the fields for an application, we must make a copy of the

TEMPLATE.FIELDS subroutine from T24.BP
jsh-->COPY FROM T24.BP TO DBCARD.BP TEMPLATE.FIELDS
jsh-->COPY FROM DBCARD.BP TEMPLATE.FIELDS,APPLICATIONNAME.FIELDS
Slide 75
Slide 75
s25 Discuss the copy command
Discuss the use of I_COMMON and I_EQUATE
Discuss that the 2 variables shown are dynamic variables and they are discussed on the next slide
salamelu, 2/20/2009
What we want to achieve…
s10
Slide 76
Slide 76
s10 Ask trainees to go through the functional and technical spec for Debit Card and make sure they are clear about the requirements.
salamelu, 2/20/2009
What we want to achieve…
Slide 77
Defining Fields
 Fields of an application are defined in the .FIELDS methods
 Though not made mandatory, this method must exist, since an

application must contain at least one field
 This method is called after the .INITIALISE method
 Uses the common variables from I_COMMON

 F
 N
 T
 ID.F
 ID.N
 ID.T
 CONCATFILE
 CHECKFILE
 ID.CHECKFILE
 V
Slide 78
F Array
 Dimensioned array used to specify field name, multi-value status
 Used only for fields in an application, not the ID
 Normal Field
F(Field position) = ‘FIELDNAME1’
 Simple Multi value

F(Field position) = ‘XX.FIELDNAME2’
Slide 79
F Array
 Associated Multi value (with sub value)

F(Field position) = ‘XX<FIELDNAME1’
XX<FIELDNAME1
F(Field position) = ‘XX.XX<FIELDNAME2’
F(Field position) = ‘XX.XX>FIELDNAME3’
F(Field position) = ‘XX>FIELDNAME4’
Slide 80
F Array
 Language Multi value
F(Field position) = ‘XX.LL.FIELDNAME1’
 F Array equivalent used ONLY for ID of an application
ID.F = ‘DEBIT.CARD.ID’
Slide 81
N Array
 Dimensioned array used to specify

 Maximum Characters
 Minimum Characters
 Field validations attached
Syntax Used Description
’10’ Up to 10 characters allowed, no special editing will be done.
’35.2’ A maximum of 35 characters, but at least 2 must be entered (Mandatory Field)
'006.6' Input must be 6 characters. Leading zeros will not be removed and the field
data will be validated at commit time.
Slide 82
ID.N
 N Array equivalent used to define ID properties only
ID.N = ‘16’
ID.N = ’16.1’ ; * .1 makes the field mandatory
Slide 83
T Array
s26
 Dimensioned array that holds information about

 Data type
 List of possible values
 NOINPUT / NOCHANGE characteristics
 Justification
 HOT FIELD HOT
HOT.FIELD, HOT.VALIDATE
VALIDATE properties
 Has 10 sub fields to specify all field properties
 T(Field position)<1> - Data type to call IN2 routine

 T(FieldPosition)<1> = ‘A’ will call IN2A routine to validate the data entered
 T(Field position)<2> - List of input options if predefined

 T(FieldPosition)<2> = “Yes_No_Maybe”
 T(FieldPosition)<2>
T(FieldPosition) 2 = ‘1001…5000’
1001…5000 will display all numbers from 1001 to
5000
Slide 84
Slide 84
s26 For each sub field in the T array, we must give examples of use from existing applications. Please refer Template Programming
document
salamelu, 2/20/2009
T Array
 T(FieldPosition)<3> - NOINPUT/NOCHANGE/EXTERN
 NOINPUT – Field never available for input
 NOCHANGE – Field not inputtable after record is authorised
 EXTERN – Field is cleared if record is copied
Slide 85
T Array
 T(FieldPosition)<4> - Format Mask

 Data can be displayed differently, irrespective of how it is stored in the
database. The Mask character used is #
 T(FieldPosition)<5> - Justification
 Default
D f lt Left
L ft justified,
j tifi d no need
d to
t specify
if T(FieldPosition)<5>
T(Fi ldP iti )<5>
 Right justified (R) and center justified (C ) are the other 2 options
Slide 86
T Array
s27
 T(FieldPosition)<6> - MACHINE to default to machine date instead of

T24 date
 U d iin th
Used the USER application
li ti
 T(FieldPosition)<7> - TEXT to display a text box in the browser
 T(FieldPosition)<8> - NOMODIFY/NODELETE/NOEXPAND
 No Modification or changes allowed to multi value set after first
authorisation
 Multi value set cannot be deleted after record is authorised
 Multi value set cannot be expanded further after authorisation
 T(FieldPosition)<9> - HOT.FIELD/HOT.VALIDATE/WEB.VALIDATE
 HOT.FIELD causes field to be validated immediately
 HOT.VALIDATE causes all fields to be validated
 WEB.VALIDATE triggers validation at web server level
Slide 87
Slide 87
s27 Mention that the T(Z)<8> is used for multi value sets and that T(Z)<3> is for a single value field
salamelu, 2/20/2009
Built-in Data Types
 T24 supports a lot of built-in standard data types
 Built-in data types are equated to standard names in an Insert file

called I_Datatypes
Slide 88
I_Datatypes
EQU T24_String TO 'T24.STRING'

EQU T24_BigString TO 'T24.BIG.STRING'
EQU T24_Text TO 'T24.TEXT'
EQU T24_TextWide TO 'T24.TEXT.WIDE'
EQU T24_Numeric TO 'T24.NUMERIC'
EQU T24
T24_Date
Date TO 'T24
T24.DATE
DATE'
EQU T24_Portfolio TO 'T24.PORTFOLIO'
EQU T24_Account TO 'T24.ACCOUNT'
EQU T24_InternalAccount TO 'T24.INTERNAL.ACCOUNT'
EQU T24_Customer TO 'T24.CUSTOMER'
EQU T24_Frequency TO 'T24.FREQUENCY‘
EQU Field_Mandatory TO ',mandatory'

EQU Field_NoInput TO ',NOINPUT'
EQU Field
Field_NoChange
NoChange TO '
',NOCHANGE'
NOCHANGE'
EQU Field_Unique TO ',UNIQUE'
EQU Field_NoNulls TO ',NONULLS'
EQU Field_AllowNegative TO ',ALLOW.NEGATIVE'
COMMON/DataTypeCommon/DataType.list,
DataType.nArrays,
DataType.tArrays,
DataType.checkFiles
Slide 89
TableUtil.loadFieldTypes
s11
 THE.TEMPLATE invokes TableUtil.loadFieldTypes which loads the id,

length and type depending on the basic data types
IF NOT(DataType.list) THEN
CALL TableUtil.loadFieldTypes
END
 DataType.list is a common variable in I_Datatypes, which holds the list

of data types
 The values populated by this subroutine are session specific
Slide 90
Slide 90
s11 Explain why the values populated for the datatypes by this subroutine, are session specific
salamelu, 2/20/2009
TableUtil.loadFieldTypes
 Loads each of the basic data types as given below
SUBROUTINE TableUtil.loadFieldTypes
id = "T24.STRING"
length = 35
type = "A"
file = ''
GOSUB addBasicType
addBasicType:
typePos +=1
DataType.list<typePos> = id
DataType.nArrays<typePos> = length
DataType.tArrays<typePos> = LOWER(type)
DataType.checkFiles<typePos> = file
RETURN
Slide 91
Field Definitions
Field Definitions
Slide 92
Defining Fields – API’s
s4
 T24 supports a number of API’s are used to define fields.
 These API’s internally update the F, N and T arrays.
Slide 93
Slide 93
s4 Go through the word document for a detailed explanation of the API's. Use the examples provided in the word document to explain the
use of the API's to the trainees.
salamelu, 2/12/2009
g8
Table.defineId
 Defines the ID field
 ID.F, ID.N and ID.T are assigned
 Table.defineId(idName, dataType)
 It takes 2 parameters,
parameters the id name (ID
(ID.F
F item) and the data type of the
key
 The data type

yp of the key
y can either be
 A standard data type defined in I_Datatypes in DataType.list
 Populate data type with values corresponding to N and T arrays
Slide 94
Slide 94
g8 Notes page doesn't look in e-lerning format it should be more descriptive not the just the copy of slide points
gshital, 4/6/2010
s46
g9
Table.defineIdProperties
 Defines the ID field
 ID.F, ID.N and ID.T are assigned
 Table.defineIdProperties(idName, dataType)
 Table defineId invokes this API to define the fields

Table.defineId fields.
SUBROUTINE EB.DEBIT.CARD.PARAMETER.FIELDS
dataType = ''
dataType<2> = 16.1
dataType<3> = ''
dataType<3 2> = 'SYSTEM'

dataType<3,2> SYSTEM
CALL Table.defineId("DB.PARAMETER.ID",dataType)
Slide 95
Slide 95
s46 Table.defineId and table.defineIdProperties works the same way

salamelu, 2/22/2010
g9 gshital 06/04/2010
Notes page doesn't look in e-lerning format it should be more descriptive not the just the copy of slide points
gshital, 4/6/2010
s44
Table.addField
 Adds a field with standard data types
 Table addField(fieldName fieldType

Table.addField(fieldName, fieldType, args,
args neighbour)
 It takes 4 parameters, where,

• fieldName - The name of the field to add. The "F" arrayy item
• fieldType - The standard T24 data type of the field
• args - Any arguments (mandatory, no input, etc.)
• neighbour - Reserved for future use.
 The various arguments possible are : Field_NoChange, Field_NoInput,

Field_Mandatory, Field_AllowNegative, Field_unique, Field_NoNulls
CALL Table.addField("XX.LL.DESCRIPTION",T24_String,‘‘,‘‘)
Slide 96
Slide 96
s44 This API is used for creating fields with teh standard data type specifications
salamelu, 2/22/2010
s45
Table.addFieldDefinition
s47
 Adds a field using the F, N and T definitions
 Table.addFieldDefinition(fieldName, fieldLength, fieldType, neighbour)

• fieldName - The name of the field to add. The "F" array item
• fieldLength - The length of the field. “N” array item
• fieldType - The type of the field. “T” array item
• neighbour - Reserved for future use
CALL Table.addFieldDefinition("XX.LL.DESCRIPTION",35,‘A‘,‘‘)
Slide 97
Slide 97
s45 This API is used when we want to specify our own values for N and T arrays, instead of using the standard data types.
salamelu, 2/22/2010
s47 The trainer could ask the trainees to start creating the debit card application at this point after explaining the basic API's to create the
id and fields. This will help becoming familiar with teh use of these API's rather than explainign all the API's and then starting the
template creation.
salamelu, 2/22/2010
Table.processArgs
s41
 Processes the arguments passed to Table.addField API
 Not invoked directly from .FIELDS method
 Assigns the N array and T array positions according to the arguments.
 Table.processArgs(args, nArrayItem, tArrayItem)
 It takes 3 parameters,
parameters where
where,
• args – the list of arguments passed to Table.addField.
• nArrayItem - The N array item to process
• tArrayItem - The T array item to process
Slide 98
Slide 98
s41 To pass multiple arguments to the args parameter, do it as follows:
ARGS = Field_Mandatory:",":Field_AllowNegative
CALL Table.addField("TEST.AMOUNT",T24_Numeric,ARGS,'')
salamelu, 3/6/2009
Field.setAttributes
 Sets the N and T array
 Not invoked directly from .FIELDS

FIELDS method
 Field.setAttributes(fieldLength, fieldType, neighbour)

• fieldLength : The N array item
• fieldType : The T array item
• neighbour : Reserved for future use
 Table.addField and Table.addFieldDefinition use this API to set the N

and
d T arrays b
based
d on th
the parameters
t passed d on tto th
them
Slide 99
EB.LOOKUP
 T24 allows us to hard code drop down options for a field in the T array
 EB.LOOKUP now allows us to define dynamic drop down values
Slide 100
Table.addFieldWithEbLookup
 Add a field with a virtual table
 Used to create a field with a finite set of predefined options
 Table.addFieldWithEbLookup(fieldName, tableName, neighbour)

• tableName – The virtual table name used to access values in EB.LOOKUP
A li ti
Application.
Slide 101
Table.addVirtualTableField
 Adds a field with a virtual table.
 Performs the same functionality as Table.addFieldWithebLookup,

Table addFieldWithebLookup
except that the list of options are configurable.
 Table.addVirtualTableField(fieldName,
( tableName, args,
g neighbour)
g )

• tableName – The virtual table name used to access values in EB.LOOKUP
Application.
• args - (optional) Any additional arguments (mandatory, no input, etc.)
Slide 102
Field.setDefault
 Sets the default value for the current field
CALL Table.addField("START.DATE",T24_Date,Field_NoInput,'')
CALL Field.setDefault(TODAY) ;* Assign default value
Slide 103
CHECKFILES
 Variable used to store Application Vet details for a field
 Only ID of record from CHECKFILE Application is defaulted into field
 Enrichment can be any field from the CHECKFILE Application
CHECKFILE(currentFieldPosition) = tableName : FM : enrichmenentField
Slide 104
Field.setCheckFile
s39
 Adds a check file to a field
 Turns tableName(argument to Field

Field.setCheckFile)
setCheckFile) into a checkfile
argument using the default enrichment field (DEFAULT.ENRICH field)
set on standard selection or the 1st field.
CALL Table.addField("CUSTOMER",T24_Customer,Field_Mandatory,'')
CALL Field.setCheckFile("CUSTOMER")
 For the
F th field
fi ld C
Customer,
t whatever
h t iis entered
t d iin validated
lid t d against
i t th
the
CUSTOMER application.
Slide 105
Slide 105
s39 No specific API for defining checkfile for ID. WE have to use ID.CHECKFILE
salamelu, 3/3/2009
Field.setCheckFile
s52
 The setCheckFile routine internally assigns.

CHECKFILE(currentFieldPosition) = tableName : FM :
enrichmenentField
CALL Table.addField("CUSTOMER",T24_Customer,Field_Mandatory,'')
CALL Field.setCheckFile("CUSTOMER")
Slide 106
Slide 106
s52 No specific API for defining checkfile for ID. WE have to use ID.CHECKFILE
salamelu, 3/3/2009
Table.addAmountField
 Adds amount field to the application
 Table addAmountField(fieldName currencyFieldName,args,

Table.addAmountField(fieldName, currencyFieldName args neighbour)

fifieldName
ldN - The
Th name off ththe fifield
ld tto add.
dd The
Th "F" array ititem
currencyFieldName – Name of the field that holds the currency the field is held
in.
args g – Anyy additional arguments
g ((mandatory,
y no input,
p etc.))
neighbour – Reserved for future use
CALL Table.addAmountField("MAX.WITHDRAWAL.AMT",'CURRENCY','',' ')
Slide 107
Table.addOptionsField
 Adds a field with pre-defined set of options
 Table addOptionsField(fieldName options,

Table.addOptionsField(fieldName, options args,
args neighbour)

fieldName - The name of the field to add. The "F" arrayy item
options – The list of options separated by an ‘_’. The T(fieldposition)<2> item.
args – Any additional arguments (mandatory, no input, etc.)
neighbour – Reserved for future use.
CALL Table.addOptionsField("WITHDRAW.SWIPE","S_W",'','')
Slide 108
Table.addYesNoField
 Adds a simple field that holds the value YES or blank
 Table addYesNoField(fieldName args

Table.addYesNoField(fieldName, args, neighbour)

fieldName - The name of the field to add. The "F" array item
args – Any additional arguments (mandatory, no input, etc.)
neighbour – reserved for future use
Slide 109
Table.setAttributeOnFields
 API to set a number of fields to be NOINPUT, NOCHANGE or

inputtable
 Table.setAttributeOnFields(attribute, fieldList)

attribute - The attribute to set. One of NOINPUT, NOCHANGE or “ “
fieldList - The list of fields to set the attribute on. These are field numbers
 Loops th
L throughh eachh fifield
ld iin fifieldList
ldLi t and
d sets
t th
the atribute
t ib t iin th
the thi
third
d
field of the T array. Loops through each field in fieldList and sets the
atribute in the third field of the T array
 More than one field can be set to one specified attribute.
Slide 110
Table.addReservedField
s37
 All new applications must define a set of reserved fields that can be
used to add extra fields to the application without the need to change
the layout of the data
 The name of the reserved fields must be of the form RESERVED.1

etc.,
 Reserved fields can be added in 2 ways

CALL Table.addReservedField(“RESERVED.1”)
CALL Table.addField("RESERVED.1", T24_String, Field_NoInput,"")
Slide 111
Slide 111
s37 When new fields sre added to an existing application, we must release a convertion routine to realign the existing values. But if we add
that new field on to the reserved field, we can prevent this realigning. That is the main purpose of reserved fields.
salamelu, 2/27/2009
Table.addDeliveryReferenceField
 Applications that raise delivery events must define a field to hold the
delivery references
 The name of this field should be DELIVERY.REF
 Delivery Reference fields can be added in 2 ways
CALL Table.addDeliveryReferenceField(neighbour)
CALL Table.addField(“XX.DELIVERY.REF", T24_String, Field_NoInput,"")
 It can be multi valued to hold delivery references for multiple parties

involved
Slide 112
Table.addLocalReferenceField
 Local reference fields allows T24 clients to add user definable fields to
the application.
 The name of this field should be LOCAL.REF
 Local reference fields can be added in 2 ways
CALL Table.addLocalReferenceField(neighbour)
CALL Table.addField(“XX.LOCAL.REF", T24_String, Field_NoInput,"")
Slide 113
Table.addStatementNumbersField
 Applications that raise accounting entries must define a field to hold the
entry ids that have been raised
 The name of this field should be STMT.NOS
 Statement Numbers field can be added in 2 ways
CALL Table.addStatementNumbersField(neighbour)
CALL Table.addField(“XX.STMT.NOS", T24_String, Field_NoInput,"")
Slide 114
Table.addOverrideField
 All applications MUST have a field to store overrides
 Override fields can be added in 2 ways
CALL Table.addOverrideField
Table addOverrideField
CALL Table.addField(“XX.OVERRIDE", T24_String, Field_NoInput,"")
Slide 115
Table.setAuditPosition
 Sets the position of the audit fields when defining the field definition for
a table.
 This API uses ADD.COMMON.FIELDS to create audit fields and set

their position.
Slide 116
Audit Fields
 RECORD.STATUS – Holds status of record(INAU, IHLD, REVE etc.,).

A live record does not have any status
Slide 117
Audit Fields
 Two other audit fields AUDITOR.CODE and AUDIT.DATE.TIME not

populated here – only when you use the Q function
Note: The order of definition of fields must be such that the overrides field is just before the
audit fields and the STMT.NOS field must precede the overrides field.
Slide 118
CONCAT Files
 CONCAT files help eliminate unnecessary selects
 Example - CUSTOMER.ACCOUNT
 When CONCAT file is specified for a field in the application, data from
field is ID to record in CONCAT file and ID.NEW is the data of the
record in CONCAT file
 Code to update CONCAT files is part of THE.TEMPLATE
CONCATFILE(FieldName) = ‘ID.OPTION’:FM:’APPLICATION.NAME’
Slide 119
CONCAT Files
 ID Options are AL, AR, NEW
 The CONCAT application must be created separately since that too is

an application in T24, only updates are automatic
Slide 120
Non Stop Compliance
s40
 C$NS.OPERATION - Common variable defined in I_COMMON.
 It controls the behaviour of an application when the NS (Non Stop)

module is installed.
 This variable can be set to -
 ALL – Non stop allowed if module is installed. Meaning application will

behave normally even when COB is executing
 NEW – Only New deals allowed if NS is installed when COB is running
 NOD – NS complaint only if .NOD is mentioned in the application’s

PGM.FILE
G entry, where .NOD
O means No Dates record required for f its
processing.
Slide 121
Slide 121
s40 It is not mandatory that C$NS.OPERATION has to be set in .FIELDS method

salamelu, 3/3/2009
Workshop
 Copy the TEMPLATE subroutine for all DEBIT CARD related

applications
 Create the required fields for each of them using the API’s discussed
Slide 122
How to create additional components?
 We have created the fields for our application
 Do we have to manually create all the necessary additional

components to make our application work?
Slide 123
How to create additional components?
 No, EB.DEV.HELPER will do it for us…..
Slide 124
EB.DEV.HELPER
s28
 Workfile Application to create

 PGM.FILE entry
 FILE.CONTROL entry
 I_ File(insert file in BP)
 STANDARD.SELECTION
 Create files at Database level
 Create DAS routines – discussed later on…
 Record ID is Application Name
 Verify record
 Say Y to all questions asked
Slide 125
Slide 125
s28 Important thing to mention here is where EB.DEV.HELPER gets information to create each component
Do not discuss DAS option now

salamelu, 2/20/2009
When to create which additional component?
 If static properties have changed

 Rebuild PGM.FILE, FILE.CONTROL, DATABASE FILES if required
 If the field name has been changed

 Update I_File and SS
 If the field properties have been changed

 Update SS
 If a new field has been added

 Update I_File and SS
 If the application name has to be changed

 Update all components
Slide 126
Workshop
s12
 Run EB.DEV.HELPER and create additional components for all the

applications created relating to DEBIT CARD
Slide 127
Slide 127
s12 Discuss about how to create all the additional components manually
salamelu, 2/20/2009
Day 5
 Validation and Workshops
Slide 128
Data Validations
Data Validations
Slide 129
Validating Data
 ID validation can be done in .ID method
 Data validation must be written in .VALIDATE

VALIDATE method
Slide 130
Validating Data
 Overrides to be raised are also part of validating data, but must be

written in the .OVERRIDES method
 Extra validations (Client customization) can be done via Version

Routines
 Validation Routines
 I
Inputt Routines
R ti
 Authorisation Routines
 ID Routine
 Check Record Routine
 After UNAU Routine
 Before AUTH Routine
Slide 131
.RECORD Method – Debit Card Example – EB.DEBIT.CARD
s4
POPULATE.COMMONS:
*Code to populate the value for security number
CALL ALLOCATE.UNIQUE.TIME(RESULT.TIME)
Y.TIME1 = FIELDS(RESULT.TIME,'.',1,1)
Y.TIME2 = FIELDS(RESULT.TIME,'.',2,1)
Y.TIME = Y.TIME1:Y.TIME2
*Get the value of the year from today's date

Y.YEAR = LEFT(TODAY,4)
*Form the Card number by concatenating year and unique time

Y.CARD.NUMBER = Y.YEAR:Y.TIME
IF R.NEW(DBC.SECURITY.NUMBER) EQ '' THEN
R.NEW(DBC.SECURITY.NUMBER) = Y.CARD.NUMBER
END
* Code to populate the value for End date
Y.END.DAY1 = LEFT(TODAY,4) ;* Get the year portion
Y END DAY1 = Y
Y.END.DAY1 Y.END.DAY1
END DAY1 + 5 ;*
* Add fi
five years
Y.END.DAY2 = RIGHT(TODAY,4)
Y.END.DAY = Y.END.DAY1:Y.END.DAY2 ;*Concatenate year, day & month
* Is RESULTING YEAR a leap year? No. How are we going to tell this in our code
* CDT is a T24 subroutine used to CALCULATE DATE, if we specify the *number
number of
calendar dates, it will give the date after so many *calendar days. So let’s do a
plus 1 day and a minus of one day to *get the actual day
CALL CDT("",Y.END.DAY,"+1C");
CALL CDT("",Y.END.DAY,"-1C")
IF R.NEW(DBC.END.DATE) EQ '' THEN
R.NEW(DBC.END.DATE) = Y.END.DAY
END
Slide 132
Slide 132
s4 Concentrate on the common variables being used in the code
Refer tech spec before discussing this screen shot
Defaulting a date is not exactly a very good example - defaulting must be done only if the field is blank and hence the condition.
sara, 5/20/2009
.RECORD Method – Debit Card Example – EB.DEBIT.CARD
 Fields are defaulted when a new record is opened
Slide 133
Error Messages
 Errors are generated before overrides
 Errors are generated when data is validated
 Code to raise errors can be written in the .VALIDATE method
 We use the common variable E to store error messages that must be

displayed or an ID to an existing record in EB.ERROR
 ERR is the core subroutine to display

p y error messages
g
 When raising an error in for an ID in the .ID method, all we have to do

is set the error code or error message in the common variable E
 We do not have to call ERR as T24 calls it in THE.TEMPLATE
 If called,
called the error message is displayed after the record is opened
Slide 134
.VALIDATE Method – Debit Card Example – EB.DEBIT.CARD
s30
 To access the data that is being input we will have to use

 R.NEW in our .VALIDATE method
VALIDATE:
* TODO - Add the validation code here.
* Set AF, AV and AS to the field, multi value and sub value and
* invoke STORE.END.ERROR
* Set ETEXT to point to the EB.ERROR.TABLE
*Validation for customer's valid account

Y CUSTOMER = R.NEW(DBC.CUSTOMER)
Y.CUSTOMER R NEW(DBC CUSTOMER)
Y.ACCOUNT = R.NEW(DBC.ACCOUNT)
CALL F.READ(FN.ACC,Y.ACCOUNT,R.ACCOUNT,F.ACC,CUS.ERR)
CUS.ID = R.ACCOUNT<AC.CUSTOMER>
IF Y.CUSTOMER NE CUS.ID THEN
AF = DBC.CUSTOMER ;* Name of the field
ETEXT = 'CUSTOMER ACCOUNT MISMATCH' ;* The error code
CALL STORE.END.ERROR ;* Needs to be invoked per error
END
Slide 135
Slide 135
s30 Refer to tech spec to see what validations must be done for the debit card applications
salamelu, 2/20/2009
.VALIDATE Method – Debit Card Example – EB.DEBIT.CARD
 Error Message displayed
Slide 136
Workshop
 Perform validations relating to – refer Tech Spec (all applications)

 .RECORD method
 .VALIDATE method
Slide 137
.AUTHORISE Method – Debit Card Example – EB.DEBIT.CARD
PROCESS:
CALL EB.DEBIT.CARD.TRANS.ACCOUNTING
Y.DATE = R.NEW(DBT.VALUE.DATE)
Y.CARD.NUM = R.NEW(DBT.CARD.NUMBER)
CALL F.READ(FN.DBC,Y.CARD.NUM,R.DBC,F.DBC,DBC.ERR)
Y CUS = R
Y.CUS R.DBC<DBC.CUSTOMER>
DBC<DBC CUSTOMER>
Y.ACC = R.DBC<DBC.ACCOUNT>
Y.ATM.ID = Y.CUS:'-':Y.ACC:'-':Y.DATE
IF R.NEW(DBT.WITHDRAW.SWIPE) = 'W' THEN

CALL F.READ(FN.DCP,DCP.ID,R.DCP,F.DCP,DCP.ERR)
IF DCP.ERR EQ '' THEN
Y.MAX.AMT = R.DCP<DCP.MAX.WD.AMT>
END
CALL F.READ(FN.ATM,Y.ATM.ID,R.ATM,F.ATM,ATM.ERR)
IF R.ATM EQ '' THEN
Y DRAWN AMT = 0
Y.DRAWN.AMT
END ELSE
Y.DRAWN.AMT = R.ATM<ATM.AMOUNT.UTILISED>
END
Y.AMOUNT
Y AMOUNT = R.NEW(DBT.AMOUNT)
R NEW(DBT AMOUNT) + Y.DRAWN.AMT
Y DRAWN AMT
IF Y.AMOUNT GT Y.MAX.AMT THEN
AF = DBT.AMOUNT
ETEXT = 'AMOUNT EXCEEDS MAX WITHDRAWAL AMOUNT'
CALL STORE.END.ERROR
END ELSE
CALL F.WRITE(FN.ATM,Y.ATM.ID,Y.AMOUNT)
END
END
Slide 138
.AUTHORISE Method – Debit Card Example – EB.DEBIT.CARD
 Live file updated, accounting entries raised
Slide 139
Workshop
 Refer to the Tech Spec and create

 .AUTHORISE method
for the applications that require it
Slide 140
Day 6
 Overrides
 Workshopp
 DAS & Workshop
Slide 141
Overrides
Overrides
Slide 142
Overrides Messages
 Generating overrides or errors at appropriate places increases the user

friendliness of an application
 .OVERRIDES method available to raise override messages. It is

executed after the data is validated but before it is return to the $NAU
file
 OVERRIDE Application used to define override messages
 TEXT - common variable to store the ID of the OVERRIDE record or

the actual text to be displayed
 STORE.OVERRIDE is the core subroutine called to raise the override
 Overrides, if accepted are stored in the no input OVERRIDES field in

Overrides
an application
Slide 143
Overrides And Error Messages
 Overrides can be static in nature or dynamic (containing values from

the transaction)
 Values if any, must be passed in the TEXT variable itself before the call
to STORE.OVERRIDE
 TEXT = ‘OVERRIDE.ID’:FM:VALUE1:VM:VALUE2 etc…
Slide 144
.OVERRIDES Method – Debit Card Example – EB.DEBIT.CARD
s15
OVERRIDES:
* TODO Add your override here
* Set TEXT to be the key to the override you want to use form the OVERRIDE
table
* Set AF/AV/AS to be the field that is relevant to the override.
*
IF R.NEW(DBC.CARD.TYPE) NE Y.CARD.TYPE THEN

AF = DBC.CARD.TYPE
TEXT = "CARD.ELIGIBLE"
GOSUB DO.OVERRIDE
END
DO.OVERRIDE:
CALL STORE.OVERRIDE(CURR.NO)
IF TEXT = 'NO'
NO THEN
GOTO EXIT.SUB
END
RETURN
Note: CARD.ELIGIBLE is a record in OVERRIDE application. Before calling the core

subroutine STORE.OVERRIDE for the first time, this code must be executed. These
statements initialise the override field in the application and clear existing overrides if
present CURR.NO
present. CURR NO is then incremented by 1 in the STORE STORE.OVERRIDE
OVERRIDE subroutine so that
subsequent overrides are stored in the field and it is multi valued as required to store as
many overrides as required.
Slide 145
Slide 145
s15 Make the trainees raise the override as per the spec
salamelu, 2/20/2009
.OVERRIDES Method – Debit Card Example – EB.DEBIT.CARD
 When the Card Type is changed for an existing record…
Slide 146
DAS
DAS – Data Access Service
Slide 147
DAS
 SELECT statements are a part of almost every subroutine in T24
 SELECT statements not written efficiently is the killer when it comes to

the performance of any system
 If we needed data from the database, we would write an appropriate

SELECT statement and use the core subroutine EB.READLIST to
execute it
 DAS is now the standard that must be followed when writing queries for
an application
Slide 148
DAS
 Data Access Service
 Single frame work for queries
 No requirement to write jQL or any other query language
 The subroutine EB.QUERY.BUILDER which is the heart of DAS

generates the jQL or the SQL query depending on the database we are
using
 May be created by EB.DEV.HELPER if required
Slide 149
Components of DAS
 If the application we are creating uses SELECT(s), we first have to

decide the list of queries that we want to allow
 We obviously can’t think of every possible combination, so it’s best to

build the list as we along
 In DAS each query defined has 2 parts – the user defined name for the
query and its description
 DAS components for each application

 I_DAS.APPLICATION – Names for queries to be used in application
 I_DAS.APPLICATION.NOTES – Description
p for each q
query
y defined above
 DAS.APPLICATION – Routine to describe each query
Slide 150
I_DAS.APPLICATION
 Must list down all possible query option to be allowed for the application
 Each query must be given a meaningful name
 No need for any jQL yet
 Name must be equated to a number
 Naming convention must be DAS.<APPNAME>$<QUERYNAME>
EQU
QU DAS.EB.DEBIT.CARD$CUSTOMER.CARD
S. . .C $CUS O .C TO
O 1
EQU DAS.EB.DEBIT.CARD$CARD.VALIDITY TO 2
Slide 151
I_DAS.APPLICATION.NOTES
 This must contain an explanation for each of the queries used
 Notes must be stored in a variable called DAS$NOTES
 No actual query definition yet
COMMON/DAS.APPLICATION/DAS$CACHE(100),DAS$NOTES(100)
DAS$NOTES(DAS.EB.DEBIT.CARD$CUSTOMER.CARD)
$ ( $ ) = 'List of cards p
per customer'
DAS$NOTES(DAS.EB.DEBIT.CARD$CARD.VALIDITY) = 'Cards expiring before a date'
Slide 152
DAS.APPLICATION
 Definition of all queries take place here
 Queries are broken up into

 Fields
 Operands
 Sorts
 Joins
 For example, lets assume we need to define the two queries below
SELECT FBNK.EB.DEBIT.CARD WITH CUSTOMER EQ ‘10001
SELECT FBNK.EB.DEBIT.CARD WITH START.DATE EQ TODAY AND END.DATE LT

20200101
Slide 153
Defining the Queries
SUBROUTINE DAS.EB.DEBIT.CARD(THE.LIST,THE.ARGS,TABLE.SUFFIX)
$INSERT I_DAS.EB.DEBIT.CARD
$INSERT I_DAS.EB.DEBIT.CARD.NOTES
$INSERT I_DAS
I DAS
BUILD.DATA:
MY.TABLE = <EB.DEBIT.CARD>:TABLE.SUFFIX
BEGIN CASE
CASE MY.CMD = DAS.EB.DEBIT.CARD$CUSTOMER.CARD
MY.FIELDS = ‘CUSTOMER’
MY.OPERANDS = ‘EQ’
MY.DATA = THE.ARGS
CASE MY.CMD = DAS.EB.DEBIT.CARD$CARD.VALIDITY
MY.FIELDS = ‘START.DATE’
MY.OPERANDS = ‘EQ’
MY DATA = THE
MY.DATA THE.ARGS<1>
ARGS<1> ;*
* Can
C use TODAY h
here t
too
MY.JOINS = ‘AND’
MY.FIELDS<-1> = ‘END.DATE’
MY.OPERANDS<-1> = ‘LT’
MY.DATA<-1> = THE.ARGS<2>
END CASE
RETURN
Note: MY.TABLE, MY.FIELDS, MY.OPERANDS, MY.DATA, MY.JOINS are variable names that cannot be
changed The paragraph name has to be BUILD
changed. BUILD.DATA.
DATA The ordering of insert files in the above code is very
important.
Slide 154
DAS
 Core DAS Components

 I_DAS – Insert file with code to execute and cache query results
 I DAS COMMON – Insert
I_DAS.COMMON I t file
fil with
ith DAS common variables
i bl
 DAS – Subroutine that is an equivalent of EB.READLIST. Called when
execute of a query is needed
 Calling DAS is similar to EB.READLIST
CALL DAS(‘ApplicationName’, QUERYNAME, LIST, TABLE.SUFFIX)
 DAS$CACHE – Common variable used to cache query results
Slide 155
DAS
 Advantages
 Caching
 D t b
Database specific
ifi query fformation
ti
 Predefined selects for an application
Slide 156
DAS
<ANY ROUTINE WHERE SELECT MUST BE EXECUTED>

$INSERT I_DAS.EB.DEBIT.CARD
THE.LIST = DAS.EB.DEBIT.CARD$CUSTOMER.CARD
THE.ARGS = ‘10001’
TABLE.SUFF = ‘’ ;* Must mention $NAU or $HIS if required
CALL DAS(‘EB.DEBIT.CARD’,THE.LIST,THE.ARGS,TABLE.SUFF)
 DAS is the core subroutine which internally invokes the subroutine of

the form DAS.<APPLICATION>
 This routine would not usuallyy be called byy code outside of a CALL DAS
Slide 157
More information
 DAS subroutine also invokes EB.UPDATE.DAS.RESULTS which

updates a live file called DAS.RESULTS with the Table name, No of
records
d selected,
l t d Q Query name and
d th
the LIST returned.
t d
 dasMode is a COMMON variable defined in I_DAS.COMMON
 The results in DAS.RESULTS file will be used if

dasMode = dasReturnResults
 The query string that DAS builds, can be returned by setting

dasMode=dasReturnDescription and the select statement is returned,
along with the description
Slide 158
Workshop
 Write a multi threaded routine to select

 All debit cards from the debit card master application
 All debit cards of a particular card type
 All debit cards that belong to a particular customer
 All debit cards that expire on a particular date
using
i DAS
DAS.
Slide 159
Day 7
 Multithreading
 Running as COB and Service
 Workshop
Slide 160
Day 8 & 9
 Accounting
 XX.ACCOUNTING
 Workshop
Slide 161
Accounting
Accounting
Slide 162
Accounting files in T24
 STMT.ENTRY
 CATEG.ENTRY
 RE.CONSOL.SPEC.ENTRY
Slide 163
STMT.ENTRY
 Account related entries are raised ONLINE and OFFLINE for all
movements in the customer and internal accounts.
 All entries in the CATEGORY range 1-19999 are held in this file.
Slide 164
STMT.ENTRY
 In addition to STMT.ENTRY record, an entry is also generated in the

ACCOUNT.ENT.TODAY file
 ACCT.ENT.TODAY holds reference to transactions carried out since

the last COB and is cleared in the Start Of day processing. Similarly
ACCT.ENT.FWD holds reference to the forwarded dates transactions
 When the file is cleared during COB the contents is copied to a file by
name ACCT.ENT.LWORK.DAY file
 In the file ACCT.ACTIVITY, the actual account balance and other

related information for accounts are build using the ACCT.ENT.TODAY
file
Slide 165
CATEG.ENTRY
 Profit and Loss entries are raised ON-LINE and OFF-LINE and are kept
in the CATEG.ENTRY file.
 All entries hitting the Category codes over 50000 are held in this file.
Slide 166
CATEG.ENTRY
 In addition to CATEG.ENTRY record, an entry is also generated in the

CATEG.ENT.TODAY file.
 CATEG.ENT.TODAY holds reference to transactions carried out since the

last COB and is cleared in the Start Of day processing. Similarly
CATEG ENT FWD holds reference to the forwarded dates transactions
CATEG.ENT.FWD
 When the file is cleared during COB the contents is copied to a file by name
CATEG ENT LWORK DAY file
CATEG.ENT.LWORK.DAY
Slide 167
RE.CONSOL.SPEC.ENTRY
 The RE.CONSOL.SPEC.ENTRY file is updated only during COB.

Online spec entries are not raised
 Input of a fresh contract gives raise to a CONSOL.ENT.TODAY record,

which is converted to spec Entry during Close of Business
 The CONSOL.ENT.TODAY records are converted to SPEC entries in

EOD.CONSOL.UPDATE in SYSTEM.END.OF.DAY5 and are cleared in
FILE.TIDY.UP during Start Of day processing. Similarly
CONSOL ENT FWD holds reference to the forwarded dates
CONSOL.ENT.FWD
transactions
 When the file is cleared during COB the contents are copied to a file by
name CONSOL.ENT.LWORK.DAY file
Slide 168
Accounting in T24
 When a record in any application is committed, the accounting entries

are raised and are stored in the ENTRY.HOLD directory.
 Once the record is authorized, the entries are then transferred from
ENTRY.HOLD directory to the appropriate accounting files.
 Any processing that has to happen before a record goes to INAU status
has to be done in the .PROCESS method
 Any processing that has to be done before a record is authorized has to

be done in the .AUTHORISE method
Slide 169
g10
XX.ACCOUNTING Subroutine
s31
INITIALISATION
PRODUCE.ENTRIES
RAISE.AC.ENTRY RAISE.CATEG.ENTRY RAISE.CRF.ENTRY
BUILD.BASE.ENTRY BUILD.BASE.ENTRY BUILD.BASE.ENTRY
APPEND.ENTRIES APPEND.LIVE.ENTRIES APPEND.ENTRIES
APPEND.LIVE.ENTRIES APPEND.LIVE.ENTRIES
APPEND.FORWARD.ENTRIES
APPEND..FORWARD.ENTRIES
MULTI.ENTRIES
Slide 170
Slide 170
s31 Refer to word document for detailed explanation of this flow

salamelu, 2/20/2009
g10 Brief the flow in notes page

gshital, 4/6/2010
Sample Code from XX.ACCOUNTING
 Building Entries
 I_file of STMT.ENTRY or CATEG.ENTRY could be used since name

only represents a position in the array called ENTRY
ENTRY<AC.STE.COMPANY.CODE> = ID.COMPANY
ENTRY<AC.STE.TRANSACTION.CODE> = ''
ENTRY<AC.STE.THEIR.REFERENCE> = ID.NEW
ENTRY<AC.STE.VALUE.DATE> = VALUE.DATE
ENTRY<AC.STE.CURRENCY>
C.S .CU C = LCCY
CC ;
;* Set a value
a ue here
e e
ENTRY<AC.STE.POSITION.TYPE> = 'TR'
ENTRY<AC.STE.OUR.REFERENCE> = ID.NEW
ENTRY<AC.STE.CURRENCY.MARKET> = '1'
ENTRY<AC.STE.DEPARTMENT.CODE> = R.USER<EB.USE.DEPT.CODE>
ENTRY<AC.STE.SYSTEM.ID> = "AC"
ENTRY<AC.STE.BOOKING.DATE> = TODAY
Slide 171
EB.ACCOUNTING Subroutine
 EB.ACCOUNTING is the core routine that will actually raise the entries
 It is called from within XX.ACCOUNTING available in T24.BP
 Has 4 parameters
 Application Name
 Type of Accounting
 Entry Details
 F
Forwardd Entry
E t Flag
Fl
 EB.ACCOUNTING can raise more than one entry at a time with just
one call to it
Slide 172
EB.ACCOUNTING Parameters
 1st parameter – Application name / Product name
 2nd parameter – Type of Accounting

 VAL
 AUT
 CHG
 DEL
 REV
 SAO
 RSAO
 SNP
 3rd p
parameter – Arrayy containing
g entries,, separated
p by
y FM
 4th parameter – Variable that can contain 1 or 0 or “CONSOL” to raise

CRF entries
Slide 173
EB.ACCOUNTING Parameters
 3rd parameter – Array containing entries, separated by FM
 4th parameter – Variable that can contain 1 or 0 or “CONSOL” to raise

CRF entries
Slide 174
Important Note
 DO NOT GOSUB PRODUCE.ENTRIES when the function is A, R or D
 When we call EB.ACCOUNTING with AUT, all that we need to do is

select the correct entries from ENTRY.HOLD and move it to
STMT.ENTRY / CATEG.ENTRY
 Since the entries are already available, we do not have to populate the
MULTI.ENTRIES variable again
 This holds good when we use Reverse or Delete functions as well
Slide 175
Take a look at XX.ACCOUNTING
 Understand the different paragraphs and need for checking

V$FUNCTION before proceeding with processing
 Discuss under which circumstances must we pass values in ENTRY

array to EB.ACCOUNTING
Slide 176
Code for Accounting
 Accounting subroutine must be called in the .PROCESS as well as

.AUTHORISE method
 ID of ENTRY.HOLD is ID.NEW and hence when we call

EB.ACCOUNTING in the .AUTHORISE method, we don’t have to
populate ENTRY array again
Slide 177
XX.ACCOUNTING Subroutine
 The core routine that actually raises accounting entries is

EB.ACCOUNTING
 Refer to the EB.DEBIT.CARD.ACCOUNTING subroutine to understand

the entries raised by the Debit Card example we are discussing
 STMT.NOS is the no input field that gets updated with accounting entry
ids
Slide 178
Accounting in the Debit Card Example
 Accounting entries must be raised

 Accounting Entries
 Accounting entries must be raised when
 A customer withdraws from the ATM or swipes his card (POS)
If it is an ATM withdrawal
• STMT Entry – Debit the customer account
• S STMT Entry
ty–CCredit
ed t tthe
e ATM accou
accountt ((internal)
te a )
If it is a POS swipe
• STMT Entry – Debit the customer account
• STMT Entry – Credit the Vostro account
 Use enquiries NAU.ENTRY and STMT.ENT.TODAY to view entries

raised
Slide 179
EB.CONTRACT.BALANCES
 The reporting ('CRB') consolidation module maintains the 'CENTRAL

REPORTING BASE' from which financial reports (such as General
L d
Ledger, B
Balance
l Sh
Sheet,
t St
Statement
t t off conditions,
diti F
Foreign
i C Currency
Control Ledger, Central Bank reports etc.) are produced.
 The EB.CONTRACT.BALANCES
EB CONTRACT BALANCES file provides a single place for CRB
reporting to take its information.
 It is possible to extract the balance at the close of the last working day
as well as the current balance.
 Balances are updated real-time

real time at the authorization stage of a
transaction. For certain balance types unauthorized movements are
held too.
Slide 180
EB.CONTRACT.BALANCES
 The balances are updated from the core accounting processing based on
the Consol entries raised by the underlying application – there is no direct
update from the underlying application.
 The following applications currently update EB.CONTRACT.BALANCES

 ACCOUNT
 ASSET & LIABILITY (AL)
 MM.MONEY.MARKET
 LD.LOANS.AND.DEPOSIT
 PD PAST DUE
PD.PAST.DUE
 SC.TRADING.POSITION
 MG.MORTGAGE
 MD.DEAL
 SL.LOAN
 FOREX
 LIMIT
Slide 181
Workshop
 Raise accounting entries as per the requirement for the DEBIT CARD
example
Slide 182
D 10
Day 10, 11 & 12
 Extra Information
 Templates in R5
 W k h
Workshop
 Comparison between R5, R7 and R9 templates
Slide 183
Important Tidbits
Important Tidbits
Slide 184
HOOK Routines
 In some applications, we require a valid subroutine to be input as data

in certain fields
 Versions
 Enquiries
 How does T24 check is the data entered is in fact a valid routine name?
 T(FieldPosition) = ‘HOOK’
 Calls IN2HOOK to validate subroutine name entered
 Looks for an EB.API record for the data entered hence validating it
 Code to call the routine when required must be added by us at

application level
Slide 185
Transaction Boundaries in T24
 Transaction Boundaries ensure total updates or no updates at all
 Core subroutine EB.TRANS called to start / end / abort the boundary
 Transaction Blocks are handles in 2 ways

y depending
p g on the requests
q
 Bulk OFS requests
 Non Bulk OFS requests
 At application level, there are transaction boundaries in

UNAUTH.RECORD.WRITE and in AUTH.RECORD.WRITE
Slide 186
Non Bulk OFS Requests
Slide 187
Bulk OFS Requests
s18
Slide 188
Slide 188
s18 Mention the use of the common variable cTxn_TransactionLevel that is set and which in turn causes the transaction block at
application level to be skipped
salamelu, 2/20/2009
F.READ
 F.READ
 First checks if requested record is in the cache (FWC, FWT, FWF)
 Else reads from disk and loads into cache
 Subsequent reads within subroutine execution is only from cache
 Cache cleared after process termination
Slide 189
CACHE.READ
 CACHE.READ
 Checks if record is in cache (STATIC.INDEX, STATIC.DETAILS,
S
STATIC.DATA)
C )
 Else reads from disk and loads into cache
 This cache is session specific
 Records that rarely change can be accessed using this – SPF,
SPF COMPANY
 DON’T use this to read from ACCOUNT, CUSTOMER etc
 Difference between F.READ and CACHE.READ
Slide 190
Backward Compatibility
s16
 Before R9, Older TEMPLATE used C_PROPERTIES array to define

the properties
 C_PROPERTIES is a common variable defined in

 If properties are defined using the old TEMPLATE, THE.TEMPLATE

invokes a subroutine called TableUtil.fromMethods
 This subroutine populates the Table objects from C_PROPERTIES

array
 This is essentially used for backward compatibility
Slide 191
Slide 191
s16 Also explain about C_METHODS flag array in templates before R9 and how methods are being called now
salamelu, 2/20/2009
THE.TEMPLATE
Slide 192
Other Subroutines Used in THE.TEMPLATE
 MATRIX UPDATE
MATRIX.UPDATE
 MATRIX.ALTER
 FIELD.DISPLAY / FIELD.MULTI.DISPLAY
 FIELD INPUT / FIELD.MULTI.INPUT

FIELD.INPUT FIELD MULTI INPUT
Slide 193
Interesting Core Subroutines Used So Far
 CDD
 CDT
 DUP
Slide 194
Interesting Core Subroutines Used So Far
 EB.CALL.API
Slide 195
Older Templates
Templates in older versions of T24 (R5)
Slide 196
Template Programming in R5 and lower
 No THE.TEMPLATE
 Different TEMPLATE subroutine available depending on the type of

application
 U, H – Copy the TEMPLATE subroutine from T24.BP
 L – Copy the TEMPLATE.L subroutine from T24.BP
 T – Copy the TEMPLATE.T subroutine from T24.BP
 W – Copy the TEMPLATE.W subroutine from T24.BP
 No properties and methods concept. Only paragraphs or calls to other

routines
 No EB.DEV.HELPER to create other components, all done manually

using
 FILE.LAYOUT – To create the I_ file at the jBASE prompt
 PGM.FILE and FILE.CONTROL to create the respective records
 CREATE.FILES at the Awaiting Application prompt
 STANDARD SELECTION – to rebuild the SS record of an application
STANDARD.SELECTION
Slide 197
The TEMPLATE in R5
 The flow of an application built into the subroutine
 Changes for different types of applications incorporated into different

TEMPLATE subroutines
 Code to be written in corresponding paragraphs or individual

subroutines and called when required
 No naming convention for these subroutines
 Validations executed as and when required, unlike when using the

browser
Slide 198
CHECK.FUNCTION
 This is executed as soon as the function is entered
 Prohibit certain functions for a particular application
 Perform special checks if such functions are attempted.
 This is now the .FUNCTION method
Example :
IF INDEX(‘VH’,V$FUNCTION,1) THEN
E = ‘FUNCTION NOT ALLOWED FOR THIS APPLICATION’
CALL ERR
V$FUNCTION = ''
END
Slide 199
CHECK.ID
 E
Executed
t d as soon as th
the ID iis entered
t d
 Any special editing of the record id should be coded here.
 The value entered will be in ID.NEW.
 If an error is
i found
f d requiring
i i ththe id tto b
be re-input,
i t then
th ERROR mustt b
be
set so that T24 will ask for the record ID input again
 Error messages should be displayed using E and ERR

ERR.
 This is now the .ID method

Example :
IF (LEN(ID.NEW) > 12) OR NOT(NUM(ID.NEW[8,5])) THEN
E = "INVALID ID"
CALL ERR
V$ERROR = 1
END
Slide 200
CHECK.RECORD
 This is executed before the requested record is displayed to the user
 To perform additional processing / updating when an unauthorised

record is deleted
 This is now the .RECORD method
Slide 201
Major Difference in Validations
There are various stages where validation of data can be done.
 We could validate data as soon as a user types in data in a field and

presses return (Field Level Validation)
 When a user commits a record.
Validation of Data
Field Level Validation Input Level Validation

CHECK.FIELDS CROSSVAL
Slide 202
CHECK.FIELDS
There are 3 types of validations that can be done in check fields.
CHECK.FIELDS
XX.CHECK.FIELDS
C C S XX DEFAULT FIELDS
XX.DEFAULT.FIELDS
DEFAULT.OTHER.FIELDS
Slide 203
Paragraphs in the XX.CHECK.FIELDS Subroutine
 CHECK.FIELDS - Validate the value entered in a field and display error

messages (if any)
 DEFAULT.FIELDS - When data is not entered in a field, and if T24

must default a value into it, it is done in this paragraph which is
executed when the Enter key or Tab Key is used
 DEFAULT.OTHER.FIELDS – Based on the value entered in a field

(COMI) if other fields need to be defaulted,
(COMI), defaulted that code goes here
Slide 204
CHECK.FIELDS
 The third subfield of the ’N’ arrayy should be set to ’C’. This is to enable the
checkfile property.
N(Z) = ’35..C’
 The value input will be in COMI and AF, AV and AS will be set.
 The value entered will NOT have been assigned to R.NEW at this stage.
 This is now the .VALIDATE method
Slide 205
CHECK.DELETE
 To perform additional processing / updating when a record is deleted

(i.e., V$FUNCTION = ‘D’)
Slide 206
CHECK.REVERSAL
 To perform additional processing / updating when an authorised record

is reversed.
Slide 207
Cross Validation
 XX.CROSSVAL is the subroutine that will contain code to be executed

at cross validation
 This section will be performed only when the record has been
committed and FUNCTION is 'I' or 'C'.
 It should be split into three sections with calls to subroutines to process
Field cross validation

Overrides
Additional processing
Slide 208
Cross Validations
 R.NEW, R.OLD, R.NEW.LAST can be used
 Fields in error can be flagged with a corresponding error message by

calling STORE.END.ERROR with AF, AV and AS set
 Check field validations also called again
 In the new way of coding, the .VALIDATE method is called again in

THE.TEMPLATE when a record is committed
Slide 209
XX.OVERRIDE Subroutine or Paragraph
 Subroutine that will contain code to generate overrides
 R.NEW is used to access values in the fields and decide whether an

override must be generated or not
 XX.OVERRIDE must be a multi value field in the application
 Any override messages should be displayed by calling

STORE.OVERRIDE(CURR.NO) setting TEXT to the OVERRIDE
record ID or the text message to be displayed.
 If TEXT is returned as NO, then exit the subroutine immediately.
 The subroutine should initialise the override fields by calling

STORE.OVERRIDE with CURR.NO set to zero at the start of the
subroutine.
 This is now the .OVERRIDE method
Slide 210
Additional Processing
 Invoked after all cross validation checks and overrides.
 To invoke other sub-systems e.g. EB.ACCOUNTING, Delivery etc
 In the new coding standard, this type of processing can be put in

the .PROCESS method or the .AUTHORISE method
Slide 211
BEFORE.UNAUTH.WRITE
 To perform processing which is to be done before the record is written

to the unauthorised file.
 It will be executed when the FUNCTION used is D, R, C or I.
 After performing CHECK.DELETE, CHECK.REVERSAL and

CROSS.VALIDATION.
 To make related updates to other files.
Slide 212
AFTER.UNAUTH.WRITE
 The purpose of this section is similar to that of BEFORE.UNAU.WRITE

except that it will be performed after the write to the unauthorised file
 Not available in the new template programming
Slide 213
BEFORE.AUTH.WRITE
 To do special processing before the live record is written.
 To invoke accounting in authorisation mode and to handle the

authorisation of a reversal.
 To distinguish between the authorisation of Input and the authorisation

of a reversal, the record status must be checked
Example :
BEGIN CASE
CASE RECORD.STATUS[1,3] = "INA"
CALL XX.AUTHORISATION
CASE RECORD.STATUS[1,3]
RECORD STATUS[1 3] = "RNA"
CALL XX.REVERSAL
END CASE
Slide 214
AFTER.AUTH.WRITE
 Similar to BEFORE.AUTH.WRITE but performed after the write
 This is not available in the new template programming
Slide 215
What was defined where?
 Initialise method was INITIALISE paragraph in the TEMPLATE

subroutine in R5
 Fields method was the DEFINE

DEFINE.FIELDS
FIELDS paragraph in the TEMPLATE
subroutine in R5
 Function method was the CHECK.FUNCTION p

paragraph
g p in the
TEMPLATE subroutine in R5
 ID method was the CHECK.ID paragraph in the TEMPLATE subroutine

in R5
 Record method was the CHECK.RECORD paragraph in the

 Default method was part of the CHECK.FIELDS subroutine available in

R5
Slide 216
What was defined where?
 Validate method was CHECK.FIELDS paragraph / subroutine in R5
 Preview method was DO.PREVIEW paragraph in the TEMPLATE

subroutine in R5
 Overrides method was the OVERRIDES paragraph in the TEMPLATE

subroutine in R5
 Process method was the BEFORE.UNAUTH.WRITE paragraph in the

 Authorise
A th i method
th d was the
th BEFORE.AUTH.WRITE
BEFORE AUTH WRITE paragraph
h iin th
the
 Run method is the same as the $RUN routine in R5
Slide 217
Workshop
 Create the INSURANCE application according to the given

specification using the R5 template
 Perform the specified validations
Slide 218
Comparison of R5, R7 and R9 Templates
Comparison of R5, R7 and R9 Templates
Slide 219
TEMPLATE Subroutine
 In R5
 Both application flow and business logic built into TEMPLATE
 Different TEMPLATE subroutines for different application types
 No properties and methods
 All business functionality defines in paragraphs or call to routines
 No naming conventions for these routines
In R7
 Application flow in THE.TEMPLATE
 Same TEMPLATE subroutine for all types of application
 Business functionality in individual subroutines called methods
 C_PROPERTIES used to define properties
 C_METHODS flag array determines what methods to invoke
 In R9
 Table objects used to define properties
 Any method that exists will automatically be invoked
Slide 220
THE.TEMPLATE Subroutine
 In R5
 No concept of THE.TEMPLATE
 In R7
 THE.TEMPLATE holds execution flow
 .FIELDS method is made mandatory
 Other methods invoked based on C_METHODS
C METHODS flag array
 In R9
 Subroutine modified to be compatible with using Table definitions
 Any method that exists is automatically invoked
Slide 221
 In R5
 This invokes the <Application> Subroutine
 In R7
 This invokes the <Application> Subroutine
 The <Application> Subroutine (a copy of THE.TEMPLATE) in turn invokes
THE TEMPLATE
THE.TEMPLATE
 In R9
 This invokes both the <Application>
Application Subroutine and THE.TEMPLATE
Slide 222
Field Definitions
 In R5
 DEFINE.PARAMETERS paragraph in TEMPLATE contains the field
definitions
 ID F ID.N,
ID.F, ID N ID
ID.T,
T FF, N and T arrays are directly used to define the fields
fields.
 In R7
 In the .FIELDS method, ID.F, ID.N, ID.T, F, N and T arrays are directly used
to define the fields
 In R9
 In the .FIELDS method, there are a lot of API’s that can be used to define
fields which in turn populate values in the F, N and T arrays
 There are 2 new insert files
• I_Table
I Table to define common variables used in Table object
• I_Datatypes which equates basic data types to standard names
Slide 223
Validations
 In R5
 Validations can be done at 2 levels,
• Field level validations – CHECK.FIELDS paragraph
• Input
I t level
l l validations
lid ti ((when
h user commits
it th
the record)
d) – CROSSVAL
paragraph
 In R7
 Validations are written in the .VALIDATE method
• Executed on clicking validate, commit and authorise buttons
 For field level validations, field must be set as HOT.FIELD and code is
written in .VALIDATE method
• Executed on tab out of the field
 In R9
 Same as in R7
Slide 224
Creation of additional components
 In R5
 All components have to be created manually.
• FILE.LAYOUT at the jBASE prompt – to create the I_ file
• PGM.FILE
PGM FILE and d FILE.CONTROL
FILE CONTROL - to
t createt the
th respective
ti records
d
• CREATE.FILES at the Awaiting Application prompt – To create files at
database level
• STANDARD.SELECTION – to rebuild the SS record of an application
pp
 In R7
 EB.DEV.HELPER is a one stop shop to create all the additional
components
 In R9
 EB.DEV.HELPER
EB DEV HELPER is
i a one stop
t shop
h to
t create
t allll the
th additional
dditi l
components
Slide 225
g11
Summary
 Adequate knowledge to understand

 How applications work in T24
 Adequate knowledge to create

 Applications in T24 version R7 and above
 A li ti
Applications iin T24 version
i R5 anddbbelow
l
 Adequate knowledge to
 Write code to raise accounting entries
entries, overrides
overrides, errors
errors, validations
 Create Multi threaded subroutines
Slide 226
Slide 226
g11 Objective and Summary doesn't match slides followed by summary are about you will now be able to should be a part of notes page
gshital, 4/6/2010
You will now be able to …
 Appreciate the way all applications in T24 work
 Create new applications in T24
 Modify functionality of existing ones (if required, otherwise it’s a bug!!)
 Decide which methods to split up the required functionality into
 Explain to others the TEMPLATE and THE

THE.TEMPLATE
TEMPLATE subroutine in
T24
 Be able to decide what properties to set for an application you are

about
b t tto create
t
 Create applications using the older Template in T24
Slide 227
You will now be able to …
 Decide when to use F.READ / CACHE.READ
 Write validations, for an application as well as for a version
 Decide what type of accounting entries will be raised in a given

situation
 Write multi threaded routines for COB / Services
 Create additional components of an application and know their

relationship
 T debug
To d b iissues arising
i i ffrom iincorrectt code
d
 Explain to someone else about transaction management in T24
Slide 228
Thank You
TEMENOS EDUCATION CENTRE
NOTICE
These training materials are the copyrighted work of Temenos Headquarters SA and other companies in the TEMENOS group of companies
(The Copyright Owner). The training materials contain protected logos, graphics and images. Use of the training materials is restricted solely for
use by licensed end users, partners and employees. Any un-licensed reproduction by any means, redistribution, editing, transformation,
publishing, distribution, or public demonstration of the training materials whether for commercial or personal gain is expressly prohibited by law,
and may result in severe civil and criminal penalties. Violators will be prosecuted to the maximum extent possible. Such training materials shall
not be represented
represented, extracted into or included in part
part, or in whole
whole, as part of any other training documentation without the express permission of
the Copyright Owner, which must given in writing by an authorised agent of the Copyright Owner to be valid. Where such permission is given a
clear and prominent notice must be displayed on any and all documentation accrediting the Copyright Owner with having copyright over the
materials. End-user licenses will in no event contain permissions extending the use of these training materials to third parties for commercial
training purposes.
Without limiting the foregoing, copying or reproduction of the training materials in part or in whole to any other sever or location for further
reproduction or redistribution is expressly prohibited, unless such reproduction is expressly licensed by the Copyright Owner.
Copyright © 2010 Temenos Headquarters SA

DEV1.T24 Template Programming-R10

Uploaded by

Document Information

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

DEV1.T24 Template Programming-R10

Uploaded by

Copyright:

Available Formats

T24 Template Programming

TEMENOS EDUCATION CENTRE

Version Date Author Reviewer

1.0 1st March 2009 Alamelu SenthilNathan

2.0 1st February 2010 Alamelu SenthilNathan

At the end of the session you will have

 Adequate knowledge to understand

 Adequate knowledge to create

e.g. start the notes page like What is an application?

 There are different kinds of applications in T24

 At database level depending on the kind above, there can be

 Applications can be broadly classified in any of the three categories

 Naming conventions for database files

 FIN – F<MNE>. <APPLICATION>{$<SUFFIX}

 What is an Application in T24?

 What is a Table in T24

 What type of application (H, U, L, T, W)

 What classification (CUS, FIN, INT)

 We must decide fields

 Other related file updates

 What is the business functionality to be built in

T24 checks if a VALID Application is entered.

2. Enter Function and ID

When data is entered and we hit enter, T24 validates it as a function.

If record does not exist, open new record for user.

4. Enter Data and Commit

Validates data, raises errors or overrides and saves record in database

If everything is OK, save changes in the database, update other applications if

T24 Application Flow

g4 Remove 'we' as explained before

 If we want to develop an application in T24, do we have to start writing

 There are two core subroutines called TEMPLATE and

 That’s why this course is called TEMPLATE PROGRAMMING 

T24 Application Flow

 Most variables used in TEMPLATE programming can be found in

 Application / Product specific common variables also available

 Must include I_ file in all code

 $INCLUDE <Dir> I_File– must specify the directory in which file is

 Following common variables need to be understood before we attempt to

 All the above mentioned variables are common variables defined in

 User creates new CUSTOMER record using CUSTOMER I F3

ID.NEW : 123456 ID.NEW.LAST - NOT USED ID.OLD - NOT USED

R.NEW R.NEW.LAST R.OLD

 Common variable defined in I_COMMON

 Contains the ID of the currently opened record in any application

 When the record is closed or committed or authorised the value in this

 Common variable defined in I_COMMON

 Dimensioned array which comprises of 500 dynamic arrays

 Holds the currently opened record in any application

Definition as seen in II_COMMON

 User opens INAU record to authorise it

ID.NEW : 123456 ID.NEW.LAST – 123456 ID.OLD – Not Used

R.NEW R.NEW.LAST R.OLD

 Common variable defined in I_COMMON

 If an unauthorized record exists for the currently opened record in any

 Common variable defined in I_COMMON

 Dimensioned array which comprises of 500 dynamic arrays

 Holds the currentlyy opened

 ID.NEW.LAST holds the ID of the currently opened record’s unuathorised

Definition as seen in I_COMMON : DIM R.NEW.LAST(C$SYSDIM)

ID.NEW : 123456 ID.NEW.LAST – NOT USED ID.OLD - 123456

R.NEW R.NEW.LAST R.OLD

 Common variable defined in I_COMMON

 If an authorized record exists for the currently opened record in any