T24 BASICS

Presented by
Shyamala Rajendran
Units of T24 Product
 Every T24 Product has 4 units associated – Application, Services, Enquiry, Versions
 Products are catalogued in EB.PRODUCT
 All Applications are catalogued in PGM.FILE
 All Services are catalogued in TSA.SERVICE
 All Enquiries are catalogued in ENQUIRY
 All Versions are catalogued in VERSION

 PGM.FILE – PROGRAM FILE – it is an index of all applications and Subroutines in T24

 @ID of PGM.FILE is the application names or routine name eg: CUSTOMER,
FUNDS.TRANSFER, TELLER
Evolution of T24 - T24 Product History

 T24 previously called as GLOBUS – simple client server architecture

 GLOBUS – DB used was IBM uniVerse, PRIMOS Operating System
 To access GLOBUS, client PC should use Terminal emulation s/w – using a CLI –
Command Line Interface –Telnet, ssh, putty etc..
 Limitations of GLOBUS – DB has 2GB limitations, GLOBUS & uniVerse were installed
in the same Application Server
 T24 – Temenos 24 - 24 denoting the system availability 24x7
 T24- Multi-tiered architecture
 1st Tier -Access to T24 through any T24 Browser compliant – Eg IE, Mozilla
 2nd Tier – Web/Application server- Std J2EE applications like Jboss, Websphere, Weblogic
 3rd Tier – T24 Application Server
 4th Tier – Database server like jBase, Oracle, SQL server or DB2
Units of T24 Product (cont..)
 T24 Services
 Services are programs that run as a background processes without user intervention
 Can be executed at a schedule and can also be triggered by a manual activity
 Spawn multiple processes and are centrally monitored by T24 –Multi threading
 Need for Services in T24 – Calculate interest on account, loans on the end of day/month,
Records older than 6 months must be archived, Currency exchange rates must be updated
periodically in FOREX transaction- all these background process done in COB without
manual intervention
Units of T24 Product (cont..)

 T24 Enquiries
 Enquiry is a query that is executed to fetch data from the database and display the results
in a user defined format
 Used to generate user defined reports
 Need for enquiries – Bank wants to view all the FT transaction where debit amount is
greater that 10000
 Enquires can be launched via Menus or command line
 Command line launching – ENQ<enquiry name>
Units of T24 Product (cont..)

 T24 Versions
 Versions can be compared to the concept of “Views” in Database
 T24 Versions helps us in creating screens with required/specific fields we want
 T24 Versions are customized screens that display the required fields from the application
 ID of version is APPLICATION,VERSION.NAME. Eg: CUSTOMER,INPUT
 Versions can be launched via menus or command line
Application Structure and Files

 Maker/Checker concept - Inputter/Authorizer

 Banks usually uses 4 eye view for a financial transaction
 To facilitate this T24 has 2 stages in a transaction
 Input
 Authorization
 Inputter is a person who inputs data into the fields in an application – data entered in the
application is stored in an associated file field by field
 Authorizer is a person who checks the record and authorizes it
 Error message “EB.RT.SAME.NAME.AUTHORISER/INPUTTER” will be displayed if
the same user tries to input and authorize the record
 Users needs to have special privileges to authorize a record. Those privileges are defined in
user profile in USER application
Application Structure and Files (cont..)
 Inputter inputs the data in a record and commits, the record is saved as Unauthorized file

Teller enters the application name

T24 checks the application in PGM.FILE

NO
Check if the TELLER has
the rights to access the
application

YES

Teller Record is displayed to fill the values

Save and commit the record

 
Application Structure and Files(cont..)
 When the record is authorized the record is moved from Unauthorized file to LIVE file

HEAD TELLER uses the “A”

function to authorise the record

NO
Check if the HEAD
TELLER has the
rights to authorise

YES

Record is authorized and moved to

LIVE file

 
Application Structure and Files(cont..)
 T24 Functions
 List of all functions the user can use are defined in user profile in USER application
 A2 B CDE F HILPR SV
 “A” is a function which allows to authorize a record
 When a record is in INA2 status – then function “2” needs to be set in the user profile to
authorize the record in this status
 “C” is a function which allows user to copy a record
 “D” is a function which allows user to delete a record which is in unauthorized status.
LIVE files can’t be deleted
 “E” is a function which allows user to list the unauthorized records
 “H” is a function which allows user to move a record from history to live file
 “I” is a function which allows user to input a record in an application
Application Structure and Files(cont..)
 “L” is a function which allows user to list live records
 “P” is a function which is used for Printing
 “R” is a function which allows user to reverse a record which is no longer used
 “S” is a function which allows user to view a record
 “V” is a special function which is supported only by some applications in T24. It is called
as verify function
 Eg for functions: User A has the functions A, D, E, I, L, R, S defined in his profile
 User A can input the command line as below
 CUSTOMER I F3 -> which opens a new customer application screens to input the data
 CUSTOMER S 1000110 -> Opens the existing customer with @ID 1000110 in view mode
 CUSTOMER E -> Will list all the customer records in Unauthorized status
Application Structure and Files(cont..)

 T24 stores the changes made in every record

 In T24 the current authorized version of a transaction is kept in the LIVE file and the older
versions are maintained in history file
 Reason for separate history file – information can be archived
Application Structure and Files(cont..)

 T24 Audit Fields

 T24 updates the following audit fields when a record is committed or authorised.
 They are no input fields attached at the end of every record across applications.
 RECORD STATUS: Holds the status of the record.
 CURR NO. : Holds the number of times the record was edited.
 INPUTTER : Holds the ID of the user who has inputted the record.
 DATE TIME : Displays the local zone date and time when USE.LOCAL.TIME is set to
YES in SPF
 AUTHORISER : Holds the ID of the user who has authorized the record.
 CO CODE : Defaults based on current company logged into
 DEPT CODE : Defaults to the user’s department code
Application Structure and Files(cont..)

 A record in T24 passes through many stages –Unauthorized, LIVE, History etc
 RECORD. STATUS – holds the status of the record.
 For a LIVE file the RECORD.STATUS is NULL/Blank
 FILE.CONTROL holds the information about the number of file an application has at the
DB level
Application Structure and Files(cont..)
Thank You – Any Queries?
Questionnaire – True or False
 Every Product/Module in T24 is a collection of related Application, Services, Enquiries and Versions?
 True
 PGM.FILE is a catalog of all the T24 applications?
 True
 Do ENQUIRY application stores the results of the enquiry?
 False- ENQUIRY stores the format of the query and the results are fetched from DB when the Enquiry is run
 Are ENQUIRY customized screens in T24?
 False – VERSIONS are customized screens
 Can a T24 user input as well as authorize the same record?
 False - “EB.RT.SAME.NAME.AUTHORISER/INPUTTER” will be displayed
 Can we set 2 levels of authorization for a T24 application?
 True
 An Application in T24 will always have 3 files associated with it at DB level?
 False – FILE.CONTROL provides that info
 A record in IHLD status is stored in $HIS file?
 False – It is stored in $NAU