Welcome to the T24 Application Structure and Products

1
Here is the agenda of this Course

2
The learning objectives of this Course are:
- To understand T24 TAFJ directory structure
- To learn about T24 Applications
- To discover how T24 applications are classified
- To learn the different type of Companies in T24
- To know how the T24 tables are Accessed
And finally to understand the components of a T24 application

3
We will start with the T24 Application Structure.
We will cover 4 topics in this chapter, the first one being an Introduction to
T24 Application Structure

4
5
This folder contains the UD directory

UD Directory

This contains various log files used by T24

Also contains various directories used by OFS

Enquires and Report are spooled here

6
We will now discover the application types in T24

7
Data which is entered into T24 applications is stored in Tables at the database level.
At the database level these tables are broadly classified into three different categories. They are
Live tables, Unauthorized tables and History tables.
Live tables store only authorized records. All T24 applications must have a Live Table. There will
be no Record Status for records in Live Tables.
Unauthorized tables ($NAU) store unauthorized records. There are various Record Statuses that
can be associated with records in Unauthorized Tables. Not all T24 applications have an
Unauthorised table. The Record Statuses are as follows.
INAU is a record which has been input but not Authorised.
INAO means the record has been input and awaiting approval of override.
INA2 implies that the record requires a second Authoriser.
RNAU means the reversal of a record has not been authorised
RNA2 indicates the reversal is waiting for a second authorisation
RNAO means the reversal is awaiting approval of a blocking override
HNAU are records which have been restored from history and needs authorisation.
IHLD indicates that the record is on Hold
History tables ($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 table and the
old version is moved to the History table. If an authorized record is reversed and the reversal is
authorized, that record too moves from the Live table to the History table. The Record Status of
a reversed record is REVE.
The format of that record will be the record ID followed by a sequence number.
The History table can store any number of amendments of a particular record.

Delete table is introduced to capture the records deleted from unauthorized tables. The Delete
table is given a $DEL suffix.
$DEL table creation is allowed only for H and U type applications, when DELETE.HISTORY field in
FILE.CONTROL is set to ‘Y’.
Not all T24 applications have a delete table. Most T24 applications have the Live, Unauth and
History tables at the database level.

8
Let’s now learn about Application Types

9
T24 application records might have different statuses at different points in
their life cycle. For this purpose, T24 applications have multiple tables at
the 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 table CUSTOMER$NAU.

10
A new table referred as ‘Delete’ table is introduced to capture the records
deleted from unauthorized tables. The Delete table is given a $DEL suffix.
When ‘hold’ and ‘unauthorised’ records are deleted from the application,
they can be stored in the corresponding $DEL table.

11
When a CUSTOMER record in INAU status is authorized, the record is first
moved to the CUSTOMER Live table and then deleted from the
CUSTOMER$NAU table. It is similar to a cut and paste operation.

12
When you edit an existing authorized CUSTOMER record, the amended
copy of the record is written to the unauthorised table CUSTOMER$NAU
when committed. The authorised copy of this record still remains in the Live
CUSTOMER table without any amendments done to it.
At that point in time it is important to understand that if you request for the
record using the Input or Authorise function, T24 will return the record
from the $NAU table. If you request this record using the See function, T24
will return the record from the Live CUSTOMER Table.

13
When you authorise an amended CUSTOMER record, the original copy of
the record is written to the History table CUSTOMER$HIS when authorised.
The amended copy of this record is written to the Live CUSTOMER table
with the amendments done to it. The record in the live table will have the
Current Number incremented by 1.

14
There are different T24 functions used to view records in application, the
function used to retrieve a record is dependant on whether the record is in
unauthorized, live or history state,
Viewing data from Browser is pretty simple. You must use an appropriate
function depending on the record status.
The alternate way to list the CUSTOMER, or any other record is to request a
listing from the TAFJ SHELL prompt.
The screen displayed here shows the Commands to use in the GUI as well
as the equivalent jBase prompt to retrieve authorized, unauthorized and
history Customer records.

15
If the $DEL table is enabled for an application, deleted records can be
viewed using the enquiry VIEW.DELETE.HISTORY. The enquiry, which can be
either called directly from command line or found under Admin
Menu>System Administration>Search Deleted Records, displays all the
transaction references with the corresponding date and time of deletion.
Model Bank menu has been modified to cope with this new functionality.

16
Here’s an example of a $DEL record, which you can view by clicking on the
‘See Record Details’ hyperlink on the VIEW.DELETE.HISTORY enquiry output.

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.
Date time fields are also updated accordingly.

Records in the $DEL table are deleted permanently using the predefined
multi-threaded service EB.PURGE.DEL.FILE.
Deletion criteria in the parameter table EB.PURGE.DEL.FILE.PARAM must be
configured. This table has two fields, APPLICATION.NAME which can be
multivalued and PURGE.DATE to specify the date before which the records
are purged.

Note:Note:For AA transactions, FILE.CONTROL is set individually for

AA.ARRANGEMENT.ACTIVITY and required property class files. Upon
deletion of parent record, the parent record along with related child

17
property class records are moved to the corresponding $DEL tables for
which FILE.CONTROL is set.
For LD defined with schedules, FILE.CONTROL is set for LD application. On
deletion, LD record is moved to the corresponding $DEL table. Support for
moving related defined schedule to $DEL table is withheld

‹#› 17
We will now learn about how Table names are derived at the database level

18
1. Do you think the LIST command without FBNK will give you the required
output? The answer is No, it will not work without FBNK.
2. What does FBNK stand for and Why is it important?

19
Most banks will have branches. In T24 a branch is referred to as a company.
T24 supports the definition of multiple companies. When the bank receives
the T24 software from Temenos, there will be only one company defined, it
is called the Master Company. If the bank wishes to create additional
companies then, as a part of the implementation process, the required
number of companies can be created.
Before creating the companies, the bank has to decide on a few things. The
local currency, the Company Names and the Mnemonic of each of the
companies. The use of this Mnemonic field is what you will learn about
next.

20
1. When you install T24, the database already contains a set of tables to
store application data belonging to the Master Company that already exists.
2. When you create a new company, are the same tables used to store its
data? The answer is No, a new set is created to store data belonging to the
new company. All this is part of the New Company Creation process.

21
These are the tables at the database when only the Master Company is
present. There is only one Customer table, one Account table and one
Funds.Transfer table.
Note: The other tables for the Master Company have been omitted for ease
of understanding.

22
Now when we add a second company, a new set of tables get created. But,
how can you have two tables with the same name at database level? The
tables would overwrite each other. How can we get round this problem?

23
So in order to differentiate one Company table set from another, the
Company Mnemonic is added to the table names. This gives each Company
table a unique name.

24
All tables at the database level follow the naming convention F.Tablename.
So this is how you arrive at the naming convention that T24 uses –
F, immediately followed by the Mnemonic, then, .TableName

25
1. By now you will understand why the commands LIST CUSTOMER, LIST
CUSTOMER$NAU and LIST CUSTOMER$HIS do not work.

2. Therefore $NAU and $HIS table names also follow the same naming
convention
For example FBNK.CUSTOMER, FBNK.CUSTOMER$NAU, etc.,.

26
Every time you create a new company in T24, will a separate set of tables
always be created? At this moment you may think the answer is yes. You
will now learn more about the types of companies in T24 and then try and
answer this question again.

27
The next chapter is about T24 Application Classification And Table Access.
This chapter is organised into 3 parts. First, we will discuss how T24
Applications are classified

28
Applications in T24 are broadly classified into three CLASS types. These are INT,
CUS and FIN. There are other sub-types, but those are not in the scope of this
learning unit.

INT Application Tables are usually parameter tables or static tables. They are
common to all companies in a T24 installation. Examples are SPF, PROTOCOL and
COMPANY applications. For these, only one Table exists at the database level
regardless of the number of companies.

FIN Application Tables store financial data. Examples are ACCOUNT, TELLER and
LD.LOANS.AND.DEPOSITS applications. Financial information is always stored
specific to a particular company. Thus these types of applications will require
multiple files at the database level depending on the number of companies.

CUS Application Tables store customer related information. T24 gives the bank
two options of storing this type of data. The first option being similar to the INT
type where there will only be one table at the database level, irrespective of the
number of companies. In this option, the data is to be shared among the
companies. The second option is to have multiple tables at the database level to
store company specific data. The data is not shared between companies and
each company would have its own set of data.

The FILE.CONTROL application contains information about which classification an

application falls under.

29
INT type applications are specific to one T24 installation.
Such tables are shared and are not company specific. They only have one
table in the first Lead Company, irrespective of the number of branches in
an installation.
All the other Lead and Branch companies can access this type of table.
As these tables are installation specific, the company mnemonic is not part
of the table name. The syntax is F.<APPLICATION>.
For example, F.SPF and F.COMPANY are INT type of tables.

30
FIN type tables or applications store financial information related to a
company.
Financial information as a practice is not shared. It is segregated and stored
by company. Financial information is crucial in deciding the “health” of the
Bank and its branches and thus is stored by company.
As these files are company specific, the mnemonic of the company is a part
of the table name. This helps to identify which company the files belong to.
The Syntax of the table name would be F<MNEMONIC>.<APPLICATION>.
For example, FBNK.ACCOUNT

31
CUS type tables store customer related information.
These tables can be shared by companies or each company can have its
own set of tables.
The Syntax of the table name would be F<MNEMONIC>.<APPLICATION>.
For example, FBNK.CUSTOMER

32
Now, we will go over the type of Companies in T24

33
Will a separate set of tables always be created, every time you create a new
company in T24? At this moment you may think so but it is not necessarily the
case. You will now learn more about the types of companies in T24 and then try
and answer this question again.
When creating companies in T24, they can either be Lead companies or Branch
companies.
A Lead Company is a company which has its own Financial tables. The first Lead
company that the system is shipped with is called the Master company. Financial
tables cannot be shared between a Lead company and the Master company or
with ANY other Lead companies. However Lead companies share the Installation
tables with the Master company. A Lead company may have its own Customer
tables or may share them with the Master company. Each Lead company
operates in one LOCAL currency and can have its own LOCAL currency which can
be different from the Master company.
A Branch Company does not have its own tables at the database level. They only
share the tables of the Lead company. A Branch company cannot exist on its own.
Each Branch company must be linked to one and only one Lead company. No two
branch companies can be linked to each other. A Branch company has to share
the LOCAL currency of its Lead company.
Some T24 clients have branches around the world that use different local
currencies. Each country must have at least one Lead company defined. This
Lead company will have the LOCAL currency defined for that country. Branch
companies will share the LOCAL currency of the Lead company.
Both Lead and Branch companies will each have a record in the COMPANY
application.
T24 comes with a default Lead company record – referred to as the Master
company, or first Lead Company.

34
A T24 installation where only Lead Companies are defined is called a Multi
Company setup.
Each Company will have its own FIN type tables. CUS type tables may be
shared if required and of course there is only one set of INT type tables.

35
A T24 installation where there is only one Lead Company with multiple
Branch Companies, is called a Multi Book Setup.
All Branches will share the tables of the Lead Company. This includes FIN
type tables.

36
A T24 installation with multiple Lead Companies and Branch Companies
within them is referred to as an Extended Multi Company Setup.
INT tables like F.COMPANY and F.SPF will be shared by all the Lead and
Branch Companies.
Each Lead company and its Branch companies will share FIN type tables.
These are Lead Company specific. Examples include FCOM1.ACCOUNT and
FCOM2.ACCOUNT.
CUS tables can be Company specific or can be shared.
For example, if company specific, FCOM1.CUSTOMER, FCOM2.CUSTOMER
and FCOM3.CUSTOMER would exist. If shared, then only
FCOM1.CUSTOMER would exist.

37
Coming back to the question. Will all companies created in T24 have their
own set of tables at database level?
The answer is NO

38
How do you know whether a company is a Lead or a Branch company? Is
there a way to tell?

39
All branches to be defined in a Bank must have a record in the COMPANY
application in T24. The ID of the record is the Company code. Some of the
important fields are discussed here.
The field GB COMPANY NAME holds the name of the Bank.
The NAME ADDRESS field is multi valuable and can store the address where
the bank is located. This is used for reporting purposes.
The MNEMONIC field holds a 3 character short name of the company. The
Mnemonic can be used as an alternate ID of the company. The name given
in this field is used as a prefix to the tables belonging to this company.
The LANGUAGE field holds the language of the company. This will affect all
the messages, instructions and help text to be displayed. The language
codes are pre defined in the LANGUAGE table. T24 can support up to 12
languages. This can be expanded to 99 using EB.DICTIONARY. In T24 some
of the output has already been translated into ENGLISH, FRENCH, GERMAN
and SPANISH. If the translation required is not available for a specific
Language, then ENGLISH will be defaulted.

40
FINANCIAL COM is a field that holds the ID of a company where the FIN
type of tables are stored. If the value in this field is the same as the ID of
this company record then this is a Lead company. It will own its own set of
Financial tables. All Lead companies will have their own FIN type tables. If
the value in this field is the ID of another company, then this is a Branch
company. It will share all the tables of its Lead company specified here.
If the value in the FINANCIAL MNE (mnemonic) field is the same as the
MNEMONIC field of this company record then this is a Lead company. If it is
not equal to the MNEMONIC of this record then this company is a branch

41
And now we will look how to access tables in T24

42
INT type of tables are always shared by all Lead and Branch companies.

43
CUS type of Tables are shared in most installations, but can also be separate
for Lead companies. All these Tables are stored in the database at the
Central Server.

44
CUS type tables can also be separate for each Lead companies. All the
Branch companies linked to a particular Lead company will share the CUS
type tables of the Lead company. Specific CUS tables are stored for each
Lead company at the Central Server in the bnk.data directory.

45
FIN type tables cannot be shared between Lead companies. Each Lead
company must have its own set of FIN type tables.

46
This last chapter is about T24 Application Components. First, we will define
an Application

47
In T24 the data input fields that a user sees on the screen are related to the
data fields at the database level. There is a one to one relationship between
them. The only way to enter data into T24 is via an APPLICATION. This
records the data entered and stores it in an associated table at the
database.
Most T24 applications allow the full functionality of T24 to be performed on
them. Examples are Data entry, authorization, deletion and viewing.
Different components must be present in order for an application to be
complete and usable. Those components are:
• PGM.FILE
• FILE.CONTROL
• STANDARD.SELECTION
We will learn more about these.

48
We will now look at the Parameter Table called PGM.FILE

49
PGM.FILE stands for PROGRAM FILE.

All applications and routines that need to be executed in T24 should have
an entry in this table. It is an index of all applications and routines.

PGM.FILE is an INT type table and therefore the table name at the database
level is F.PGM.FILE . Note, this table is not company specific.

The ID of a record in PGM.FILE is the Application name or the Routine

name.
Examples include CUSTOMER, FUNDS.TRANSFER and VERSION.

50 50
As you already know, anything that T24 needs to understand should have an entry in the PGM.FILE. Therefore all the
applications or routines executed in T24 must have a record in this table. The record ID will be the name of the
Application or of the Routine.
Applications in T24 have multiple tables associated with them at the database level. For example an application like
CUSTOMER has a LIVE table, a $NAU table and a $HIS table. The information about what types of tables are stored at
the database level is specified in the TYPE field.
This field specifies the type of data an application can store. Different types available in T24 are displayed in the drop
down on the screen shot. However, irrespective of the type mentioned in this table, all applications store Live
records. Live tables are updated upon authorizing a record.
Type A denotes Access to the T24 environment. A routine of this type can actually determine whether we are
working on the CUI, GUI or Browser interface of T24 and allow it to behave accordingly. There is only one entry in the
PGM.FILE with type A. This is called "EX“, which is spelled EX.
Type H denotes that the application can store the Unauthorized and History tables. The Unauthorized table is updated
upon inputting a record and the History table is updated upon authorizing an amended record. It will also be updated
when a reversed record is authorised. CUSTOMER is an example of a type H application.
Type L denotes that an application stores data of live tables but does not allow updates. Updates to these tables
would be controlled by the System automatically. STMT.ENTRY is an example of a type L application.
Type U denotes that a program can store only Unauthorized tables. ABBREVIATION is an example of this type
Type T denotes Concat tables which stores only Live records. An application that displays data but does not allow any
input. Data in such tables is updated by T24. An example of a type T application is CUSTOMER.ACCOUNT.
Type W denotes that an application supports Verify function. These types of applications store only Live tables but
unlike T type of applications, the user is allowed to update a table. DL.DEFINE is an example of this.
Type B denotes a Batch job that can only be accessed during the 'off-line' processing in BATCH.CONTROL. This type
signifies a routine that gets executed as a part of COB.
Type S denotes a Subroutine. A program used in the T24 system that is executed automatically whenever required. It
cannot be entered by the User; regardless if from the command line or from within the Batch Control system. It is
recommended that these are loaded only when they are needed by the report generator. The IN2 routines are
examples of this.
Type M denotes Main-line programming. This type is set for Routines that can be run from the command line but has
no table directly associated with it. These routines do not store any data. BATCH.CONTROL is an example of a Main-
Line program.
Type R denotes a Report Generator routine. There is an application in T24 named REPGEN, which is spelled r e p g e n,
which will be used to generate reports after executing routines that will gather data. These routines are set to TYPE R
in PGM.FILE.
Type D denotes Dynamic applications. Every application in T24 should have an associated code executing in the back
ground. T24 allows the user to create his own applications without writing a single line of code. All that you will have
to do is describe the fields and the properties of the application and T24 will generate the associated code.
Type V denotes a routine to pass mandatory parameters for the program. This parameter is set in the
ADDITIONAL.INFO field of the PGM.FILE application. This is almost similar to that of Type S.
Type O is obsolete and is not used.

51
The SCREEN.TITLE field is used to specify the name to be displayed when
the application is launched. A Bank may want a different name to be
displayed on the title bar when the corresponding application is launched.
T24 offers this flexibility.
The ADDITIONAL INFO field defines any special attributes or characteristics
that an application or batch routine can have. The values that this field can
hold are as follows.
.IDA stands for auto id generation. This applies to applications where the
ID’s increment by one.
.NOD denotes no dates checking required - For example applications like
BATCH and PGM.FILE can be modified both during COB as well as Online.
.NO! stands for no level down processing
.NOH stands for no hold facility after 1st input.
.NUH states that the INAU records will not be put on HOLD by unauthorized
processing.
.BDA implies that the application may run in a Branch database. This applies
to Branch Resilience.
There other values which the field ADDITIONAL INFO can hold but these fall
are out of Scope for this course.

52
The BATCH.JOB field is used only if the TYPE field holds the value of B or R.
The value in this field identifies the Batch job or the Routine to be called
when the program is being executed respectively. If the value in this field is
@BATCH.JOB.CONTROL or is NULL then the routine is a multi threaded
routine. If the value is @<name of the routine> then it is a single threaded
routine.
Data tables of the application are stored in the database.
The PRODUCT field holds the name of the sub directory under the bnk.data
directory under which the data tables of the application are stored. All the
tables related to a particular application, whether it be live, $NAU or $HIS,
will be stored in the respective sub directory mentioned in this field.

53
We will now learn about the FILE.CONTROL concept

54
1. How can we know whether an application is a CUS, FIN or INT TYPE?
2. How do we find out how many tables an application has at the database
level?

The answer to both questions is FILE.CONTROL

The information stored in FILE.CONTROL is useful to decide how a table

should be named at the database level. Should it be an F. or and F<Branch
Mnemonic>.
FILE.CONTROL is an INT type application so the name at the database level
is F.FILE.CONTROL.
The ID to FILE.CONTROL is the application name. There are no routines
defined on this table, only applications.
All T24 applications must have an entry on this table.

55
PGM.FILE and FILE.CONTROL complement each other. FILE.CONTROL is a
no-input table. The Input function cannot be used in the application
FILE.CONTROL.
The DESCRIPTION field holds the description of the record ID.
The PRODUCT field holds the name of the sub directory under the bnk.data
directory under which the data tables of the application are stored. All the
tables related to a particular application (Live, $NAU, $HIS tables) will be
stored in the respective sub directory mentioned in this field. The value in
this field should be same as that of the value in the PRODUCT field in the
PGM.FILE application.
The value entered in the field TYPE in the PGM.FILE application is replicated
in the multi valuable field SUFFIXES in the FILE.CONTROL application.
The SUFFIXES field holds the suffixes of data tables that the application
supports. Apart from live table, an application can have unauthorized
($NAU) and history ($HIS) tables.
Since the SUFFIXES are $HIS and $NAU and the TYPE in PGM.FILE is H, the
CUSTOMER application has three data tables. As the product is ST in both
PGM.FILE and FILE.CONTROL, the data tables of the CUSTOMER application
are stored under bnk.data directory under st sub directory.

56
All tables are classified to be either CUS, INT or FIN types of tables.
The CLASSIFICATION field holds the table classification of that particular
application. This is the field that decides the prefix for the tables.
INT tables have F. as the prefix.
CUS and FIN tables have F<Branch mnemonic>. as the prefix.
Since the CLASSIFICATION field in the screen shot displayed holds the value
CUS, the CUSTOMER table has FBNK as its prefix.
The three data tables for CUSTOMER are
• FBNK.CUSTOMER
• FBNK.CUSTOMER$NAU
• FBNK.CUSTOMER$HIS
The field which indicates whether the contents of the table are to be
deleted or not is SYS CLEAR FILES. This field may hold the value Y or N. If
this contains a value Y, then the contents of all data tables of the
application will be cleared when SYSTEM.CLEAR.FILES is executed from the
command line.

57
$DEL table creation is allowed only for H and U type applications, when
DELETE.HISTORY field in FILE.CONTROL is set to ‘Y’.
When ‘hold’ and ‘unauthorized’ records are deleted from the application,
they are stored in the corresponding $DEL table of the application.

58
Finally we finish this Course by learning about the STANDARD.SELECTION
Concept

59
1. SS stands for STANDARD.SELECTION
2. The STANDARD SELECTION table holds all the field names and definitions
of all the tables in T24.
3. This table contains the DICTIONARY information of an application.
3. The ID of a record in STANDARD SELECTION is the name of the application
itself.
4. STANDARD SELECTION is an INT type of table, which is not company
specific. It is named F.STANDARD.SELECTION at the database level.

60
The table STANDARD.SELECTION contains one record per application. It will
contain the field definitions of all the fields in the application. It not only
contains the field definitions of the core T24 fields, also known as the
system fields, but also contains the definitions of all local reference fields,
also known as user defined fields. All the system fields are ‘no input’ fields
and can be modified only by T24. All the user-defined fields can be
modified.
The label of the field that will appear in a particular application is to be set
in the appropriate record in the SS table.
The field SYS.FIELD.NAME defines the name of the field in an application.
The SYS.TYPE field defines the type of field that is to appear in SYS FIELD
NO. It is used by the enquiry system to determine what type of selection is
to be made.
• D stands for Data field.
• I stands for I type descriptor. This is used to store the values of
concatenated fields. Data is not stored in such fields but only generated
during run time.
• J stands for J type descriptor. It specifies field join specification. Allows
for the selection to be performed on data in other applications.

61
The field SYS FIELD NO holds the position of the field in an application. @ID
which represents the ID of any application will always be field 0.

‹#› 61
To validate different data types, T24 has many subroutines. What if you
input text in amount field? How will T24 know that you have input a wrong
data type? For this reason, certain routines are used to validate the data
input into the fields.
The SYS VAL PROG field holds the name of the routine that will perform the
data type validation on the respective field. All such routines are prefixed
with IN2.
For example IN2CUS validates a customer number. Input of a customer
mnemonic will also be accepted and converted to the customer number.
IN2A - Allows alphanumeric input. The character set is defined in
ASCII.VALUES and ASCII.VAL.TABLE.
The SYS DISPLAY FMT field gives the display format. It contains the
maximum number of characters the field name can hold followed by the
justification. R for Right justified and L for Left Justified.
The SYS SINGLE MULTI field is used to specify if the field is a single or a
multi value field.
The SYS LANG FIELD specifies if the field is a language specific field. It
determines whether or not the field can hold data in multiple languages.
The SYS GENERATED field denotes whether or not the field and its
properties are system defined or not. If set to Y, then these are core fields
and therefore cannot be amended by the user. For all the core fields it is set

62 62
to Y, for others, this is set to N.

‹#› 62
The next field is a user defined field.
NAME.ADDRESS is a logical field and hence has the field SYS TYPE set to “I”,
I being the I-Descriptor. It holds the values of Short Name, Name 1, Name 2,
Street and Town Country concatenated. The field does not store data.
Assume, to generate reports for customers, you need a set of details to be
displayed from the CUSTOMER application. Instead of getting the values for
each report, you can define a logical field with SYS TYPE set to I. When
required, T24 will populate the values of all the fields mentioned in SYS
FIELD NO. This does not become a physical field in the application, but
the value is built at run time.

63 63
1. The database has to be installed on the same server where TAFJ is installed. FALSE
2. How do we know whether a DEL table created for an application? when DELETE.HISTORY field in
FILE.CONTROL is set to ‘Y’.
3. By looking at which field in the COMPANY application, will you know whether a company is a Lead or
Branch Company? FINANCIAL COM and FINANCIAL MNE
4. A setup of one Lead company with several Branch companies is called Multi-Book in T24.TRUE

64
This is what we learnt during this Course

65
66