1

When you install T24, it creates a directory structure similar to the one you are looking at. For
ease of understanding, not all directories have been listed here. Only the important directories
that you must know about will be discussed. bnk is the name of the parent directory of T24.
There are 5 important sub-directories under it which you must know of.

T24 uses J4 files to store its data in. As you know, a J4 file is made up of a Data file and a DICT
(Dictionary) file.
Note: The client can decide which files to convert to JR if required.
bnk.data : This directory stores the data files for all applications in T24. There are multiple sub-
directories that represent the different products in T24. Data files for applications are stored
under the appropriate subdirectories.
Examples of subdirectories are AC for the Account product, FX for the FOREX product, EB for
the T24 core and so on

bnk.dict : This directory stores the dictionary files for all applications in T24. There are no
further subdirectories here.

bnk.run : This is the home directory for all T24 users. It contains the sub directories t24bin,
t24lib, bin and lib.
For any software a bin directory executables and a lib directory library files.
The sub-directories t24bin and t24lib holds T24‟s core executables and libraries whereas the
sub-directories bin and lib hold locally developed executables and libraries.

bnk.help : This is the directory where help files are installed in the earlier releases of T24.
However with the new Multi Tier Architecture (Browser front end), the xml help files can be
stored on the Web Server and T24‟s Browser component configured accordingly.

GEN4-T24 Directory Structure and Application Classification-R09.01 4

T24.BP: For a source code release of T24 which is used by the Development department of Temenos,
all the code of subroutines that make up T24 reside here. It also contains various „include‟ files that will
be used while writing local code and while creating local applications.
1.
A transaction in T24 can involve multiple stake holders. A transaction is input by a user
and is authorized by his manager. Depending on the type and size of the transaction -
banks might want more than 1 level of authorization.

To create a record in T24, you need to input all the mandatory fields and then get the
record authorized.
1.1 Inputter is the person who inputs data into the fields in a record.
1.2 Authorizer is the person who checks the record and authorizes it.
2. The error message “EB.RTN.SAME.NAME.AUTHORISER/ INP UTTE R” will be
displayed if the same user tries to input and also authorize the record.

7
FUNCTION : List of valid functions that the user can use in the company. Type ALL to
give access to all the functions. When the record is committed it will display the values
A 2 B C D E F H I L P R S V Q automatically. The Q function does not appear by
default. Q stands for Audit Review.
„A‟ is a function which allows the user to authorize a record.

For a User to authorize a record in INA2 Status, a value of 2 needs to be set in the
FUNCTION field of their USER profile.

„C‟ is a function which allows the user to copy a record.

„D‟ is a function which allows the user to delete a record which is not yet authorized. A
live record cannot be deleted.
„E‟ function allows the user to list the unauthorized records.
„H‟ function is used to move a record from history to live file.
„I‟ function allows the user to input a record in an application.
„L‟ function is used to list live records
„P‟ is used for printing
„R‟ is used to reverse a record which is no longer used.
„S‟ allows user to only view the records.
„V‟ is a special function which is supported only by some applications in T24. It is used
to produce some extra information and also performs some extra actions. V function is
known as verify function
Why do we have 3 files?

Take the following example :

1. Teller enters the application name
2. T24 checks if this name is valid by checking in the product catalog – PGM.FILE
3. If existent, It checks if the teller has the rights to access the application
3.1 If yes, application opens
3.2 If no, it throws an error message
4. Fill in requires values in the application
5. Now the head teller tries to log in and authorize the values input by the teller
6. T24 checks if the head teller has the rights to authorize
6.1 If yes, the record is authorized
6.2 If no, T24 throws an error
 Financial transactions , need version control
 We need to store the changes made in every record
 In T24, the current authorized version of a transaction is kept in the live file and
older versions are maintained in a history file
 The reason for having separate history files is that over a period - this
information can be archived
When a record is commited or authorised, T24 updates the following audit fields. They
are no input fields attached to the end of every record across applications.

RECORD STATUS: Holds the status of the record. Possible values are INAU, IHLD,
INAO, etc.,. If the record is in live file, then there is no entry in this field.
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 : Holds the date and time when the record was last edited
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

The two fields below are populated only when a record is audited (Q function)
AUDITOR CODE : Holds the code of the auditor who has reviewed the record.
AUDIT DATE TIME : Holds the audit date and time.
 Data which is entered into T24 applications are stored in Files at database level.
1. At database level these files are broadly classified into three different categories. They are
Live files, Unauthorized files and History files.
1.1 Live files store only authorized records. There will be no Record Status for records in Live
files.
1.2 Unauthorized files ($NAU) store unauthorized records. There are various Record Statuses
that can be associated with records in Unauthorized Files. The Record Statuses are:

1.3 History files ($HIS) store old copies of authorized records. When an authorized record is
edited and the changes authorized, the latest version of the record is stored in the Live file and
the old version is moved to the History file. If an authorized record is reversed and the reversal
authorized, that record too moves from the Live file to the History file. The Record Status of a
reversed record is REVE.
Format of the record ID is : <Record ID>;<Sequence Number>
For Example : 100297;4
100724;3
The History file can store any number of amendments of a particular record.

2. Applications that have a financial impact have all the three types of files.
Most of the T24 applications have all the 3 types of files at database level.

GEN4-T24 Directory Structure and Application Classification-R08.02

How do you find out whether an application is a CUS, FIN or INT type?
How do you find out how many files an application has at database level?
FILE.CONTROL table holds all this information. More on this in the later sessions

This is an INT type of file which is not company specific and therefore file name is
F.FILE.CONTROL.
ID of a record in FILE.CONTROL is Application name.
All applications in T24 will have an entry in this file.
Routines will not have an entry in FILE.CONTROL table as they do not store any data.
 T24 application records might have different statuses at different points in their life
cycle. For this purpose, T24 applications have multiple files at database level to store
these records based on their statuses.

When you input and commit a record in the CUSTOMER application, the record is
stored in the unauthorized file CUSTOMER$NAU.

GEN4-T24 Directory Structure and Application Classification-R08.02

 When a CUSTOMER record in INAU status is authorized, the record is deleted from
CUSTOMER$NAU the unauthorized file and written to the CUSTOMER Live file.

GEN4-T24 Directory Structure and Application Classification-R08.02

 When you edit an existing authorized CUSTOMER record, this amended copy of the
record is written to the unauthorized file CUSTOMER$NAU when committed. The
authorized copy of this record still remains in the Live CUSTOMER file.

At this point in time it is important to understand that if you request for the record using
the Input or Authorize function, T24 returns the record from the $NAU file. If you
request for this record using the See function, T24 return the record from the Live
CUSTOMER File.

GEN4-T24 Directory Structure and Application Classification-R08.02

 When you authorize the record currently in $NAU it is deleted from CUSTOMER$NAU
and written to the Live CUSTOMER file. The previously authorized record will be
moved to History that is the CUSTOMER$HIS file in order to keep a trail of all changes
to the record.

GEN4-T24 Directory Structure and Application Classification-R08.02

1. False - “EB.RTN.SAME.NAME.AUTHORISER/INP UTTER” error message will be
displayed if the same user tries to input and also authorize the record.
2. True
3. True
4. False - An application in T24 can have one or more files associated with it at
database level depending based on the record status
5. False – FILE.CONTROL provides that info
6. True
7. False – It is stored in $NAU