Вы находитесь на странице: 1из 23
Application Structure and files – R14 C-1
Application Structure and files – R14 C-1

Application Structure and files – R14

C-1

Application Structure and files – R14 C-2
Application Structure and files – R14 C-2

Application Structure and files – R14

C-2

Application Structure and files – R14 C-3
Application Structure and files – R14 C-3

Application Structure and files – R14

C-3

Application Structure and files – R14 C-4
Application Structure and files – R14 C-4

Application Structure and files – R14

C-4

Application Structure and files – R14 C-5
Application Structure and files – R14 C-5

Application Structure and files – R14

C-5

A transaction in T24 can involve multiple stake holders. A transaction is input by a

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.

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.

be displayed if the same user tries to input and also authorize the record. Application Structure

Application Structure and files – R14

C-6

FUNCTION : List of valid functions that the user can use in the company. Type

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.

is not yet authorized. A live record cannot be deleted. ‘E’ function allows the user to

‘E’ function allows the user to list the unauthorized records.

‘H’ function is used to move a record from history to live file.

‘I’

‘L’ function is used to list live records

function allows the user to input a record in an application.

‘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

Application Structure and files – R14

C-7

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

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

are input in a record and committed, it is saved in the unauthorized file Application Structure

Application Structure and files – R14

C-8

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

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

the record is moved from the unauthorised file to the authorised file Application Structure and files

Application Structure and files – R14

C-9

• Financial transactions , need version control • We need to store the changes made

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.

files. This enables preservation of deleted transactions for audit purposes. Application Structure and files – R14

Application Structure and files – R14

C-10

Application Structure and files – R14 C-11
Application Structure and files – R14 C-11

Application Structure and files – R14

C-11

Financial transactions , need version control We need to store the changes made in every

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.

files. This enables preservation of deleted transactions for audit purposes. Application Structure and files – R14

Application Structure and files – R14

C-12

When a record is commited or authorised, T24 updates the following audit fields. They are

When a record is commited or authorised, T24 updates the following audit fields. They are no input fields attached at 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, 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.

: Holds the ID of the user who has authorized the record. CO CODE : Defaults

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 – R14

C-13

Application Structure and files – R14 C-14
Application Structure and files – R14 C-14

Application Structure and files – R14

C-14

Data which is entered into T24 applications are stored in Files at database level. 1.

Data which is entered into T24 applications are stored in Files at database level.

1. At database level these files are broadly classified into Live files, Unauthorized files

History files and Deleted 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: INAU, INAO, INA2, RNAU, RNA2, RNAO, HNAU, IHLD

1.3

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 files ($HIS) store old copies of authorized records. When an authorized

100724;3
100724;3

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

The History file can store any number of amendments of a particular record.

1.4 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.

2. 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 – R14

C-15

Note: DELETE.HISTORY in FILE.CONTROL must be set to ‘YES’ if deleted history needs to be

Note: DELETE.HISTORY in FILE.CONTROL must be set to ‘YES’ if deleted history needs to be maintained by T24

must be set to ‘YES’ if deleted history needs to be maintained by T24 Application Structure

Application Structure and files – R14

C-16

T24 application records might have different status at different points in their life cycle. For

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, the record is stored in the unauthorized file CUSTOMER$NAU. Application Structure and files – R14

Application Structure and files – R14

C-17

When the record is authorized, it is moved from the $NAU file to the LIVE

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

is moved from the $NAU file to the LIVE file. Live files do not have a

Application Structure and files – R14

C-18

When a Live record is amended, it is available both in the Live and the

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

the modifications and the authorized record is available in the LIVE file Application Structure and files

Application Structure and files – R14

C-19

When the amendment on a Live record is authorized, the previous version of the authorized

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

ID of the record in the $HIS file is suffixed with the CURR.NO audit field Application

Application Structure and files – R14

C-20

How are the fields displayed in any application? The system reads the STANDARD.SELECTION file for

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.

a record in this file, there must be a corresponding FILE.CONTROL record. Application Structure and files

Application Structure and files – R14

C-21

1. False - “EB.RTN.SAME.NAME.AUTHORISER/INPUTTER” error message will be displayed if the same user tries to

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 - An application in T24 can have one or more files associated with it at database level

4. True

5. False – FILE.CONTROL provides that info

6. False – It is stored in $NAU

7. True

– FILE.CONTROL provides that info 6. False – It is stored in $NAU 7. True Application

Application Structure and files – R14

C-22

Application Structure and files – R14 C-23
Application Structure and files – R14 C-23

Application Structure and files – R14

C-23