Welcome to the learning unit on T24 Application Structure and Files

Application Structure and files – R17 C-1

 In this Learning unit we will look at
• Introduction to files in T24
• Introduction to simple workflow in T24
• List the roles of T24 Users
• Identify File structure in T24

Application Structure and files – R17 C-2

 We have seen in the previous session that a T24 product is made up of
Application, services, enquiries and versions. An application records the
data entered and stores it in an associated file, field by field

Application Structure and files – R17 C-3

 An application is associated with not just one table - Up to 4 tables
may be associated with an application in T24

Application Structure and files – R17 C-4

 A transaction in T24 can involve multiple stake holders. A transaction is
input by a user and is authorized by his manager. Depending on values
in the fields 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.
Inputter is the person who inputs data into the fields in a record.
Authorizer is the person who checks the record and authorizes it.
The error message “EB.RTN.SAME.NAME.AUTHORISER/INPUTTER” will
be displayed if the same user tries to input and also authorize the
record.

Application Structure and files – R17 C-5

 MAKER CHECKER Concept.
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 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

Application Structure and files – R17 C-6

 function is known as verify function

Application Structure and files – R17 C-6

 When values are input in a record and committed, it is saved in the
unauthorized file

Application Structure and files – R17 C-7

 When a record is authorised, the record is moved from the
unauthorised file to the authorised file

Application Structure and files – R17 C-8

 • 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.
• Deleted History file capture records deleted from unauthorized
files. This enables preservation of deleted transactions for audit
purposes.

Application Structure and files – R17 C-9

 Deleted history is not available by default and must be configured if
required for an application

This is done in FILE.CONTROL application by adding a SUFFIX value for

$DEL. A separate file deleted records will be created with extension
$DEL. For example for CUSTOMER, you would have
FBNK.CUSTOMER$DEL.

Application Structure and files – R17 C-10

  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.
 Deleted History file capture records deleted from unauthorized
files. This enables preservation of deleted transactions for audit
purposes.

Application Structure and files – R17 C-11

 When a record is committed or authorised, T24 updates the following audit
fields. They are no input fields attached at the end of every record.

RECORD STATUS: Holds the status of the record. Possible values are INAU,
IHLD, INAO, etc.,. If the record is in live file, RECORD.STATUS is Null
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 : Based on the COMPANY table, the corresponding audit fields of
the transaction record 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

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.

Application Structure and files – R17 C-12

 We know that a record passes through many stages – Unauthorized , Live ,
authorized , history and many more
The audit field RECORD.STATUS holds the status of a record
For a live record, RECORD.STATUS is blank/Null
Live records cannot be deleted. They can be reversed.
RECORD.STATUS may be one of the following
INAU – Input Not Authorized

INAO – Input Not Authorized due to Overrides

INA2 – Input requires Second Authorizer

RNAU –Reversal Not Authorized

RNA2 – Reversal requires second Authorizer

RNAO -Reversal Not Authorized awaiting Overrides

HNAU –History Not Authorized

IHLD - Input on HOLD.

Application Structure and files – R17 C-13

 REVE -Reversed

Application Structure and files – R17 C-13

 Data which is entered into T24 applications are stored in Files at database level.
At database level these files are broadly classified into Live files, Unauthorized files
History files and Deleted History files.
Live files store only authorized records. There will be no Record Status for records in
Live files.
Unauthorized files ($NAU) store unauthorized records. There are various Record
Statuses that can be associated with records in Unauthorized Files. The Record
Statuses are: INAU, INAO, INA2, RNAU, RNA2, RNAO, HNAU, IHLD
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 also 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.
Deleted History Files store unauthorized records which are deleted. The ID format of
these records take the form: <Transaction reference>;<Date and Time in milliseconds>.
Audit fields are updated with User details (who performed the deletion operation)
with the corresponding Date and Time. These records can be viewed only by using the
enquiry VIEW.DELETE.HISTORY.
Applications that have a financial impact have Live, Unauthorized and History types of
files. Most of the T24 applications have these 3 types of files at database level. If
required T24 can be configured to store deleted unauthorized records of an
application in the Deleted History Files.
Application Structure and files – R17 C-14
 Note: DELETE.HISTORY in FILE.CONTROL must be set to ‘YES’ if deleted
history needs to be maintained by T24

Application Structure and files – R17 C-15

Slide 15

t12 More on classification field to be discussed in the environment session.Now focus more on the suffixes
field
tspriya, 26/09/2011
 T24 application records might have different status 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 status.

When you input and commit a record in the CUSTOMER application,

the record is stored in the unauthorized file CUSTOMER$NAU.

Application Structure and files – R17 C-16

 When the record is authorized, it is moved from the $NAU file to the
LIVE file. Live files do not have a suffix

Application Structure and files – R17 C-17

 When a Live record is amended, it is available both in the Live and the
$NAU file. The $NAU contains the modifications and the authorized
record is available in the LIVE file

Application Structure and files – R17 C-18

 When the amendment on a Live record is authorized, the previous
version of the authorized record is moved to the $HIS file and the new
copy of the record is moved from $NAU to live file. As the record can
undergo modification multiple times, the ID of the record in the $HIS
file is suffixed with the CURR.NO audit field

Application Structure and files – R17 C-19

 How are the fields displayed in any application? The system reads the
STANDARD.SELECTION file for the corresponding application and
populates all the fields in the application. This file holds the field
names, field position, validations, etc. This is a no input file and is
generated automatically by the system. For an application to have a
record in this file, there must be a corresponding FILE.CONTROL record.

Application Structure and files – R17 C-20

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

Application Structure and files – R17 C-21

 In this learning unit, you learnt about Application structure and Files

You will now be able to:

State different file suffixes in T24
Recall the Input/ Authorizer mechanism
List the functions that can be performed on a record in T24
Recall the movement of a record in $NAU, Live, $HIS and $DEL files
State different RECORD.STATUS
Identify suffixes for application using FILE.CONTROL

Application Structure and files – R17 C-22