THIS IS ALL ABOUT 'OVERRIDE.

CLASS'
This table will allow the user to group into different classifications any override message generated by a
T24 application. Each override message defined in an application or in a subroutine of an application can
be classified but please note the system does not force it.

Classification will be done by creating an OVERRIDE.CLASS record by means of OVERRIDE.CLASS table

where the ID is the application name, Field 1 is the (hardcoded) override message and Field 3 is the
classification code. Field 2 can be used to qualify an override message based on its variable elements and
set up different classifications based upon these (see T24 Help Text, OVERRIDE CLASS DETAILS). Fields 1
to 3 are multivalue to allow the inclusion, if necessary, of all override messages of an application

A classified override can only be approved by a user who has the allowance for this code. The allowance
is defined by the content of the field within the USER record ('OVERRIDE.CLASS'), which is a multivalue
field.

The approval can be done by inputter, authoriser (first or second when more than one) or a 3rd or more
person.
When the record is authorised but not every override approved the status of the record will be 'fNAO'
(f=Function).

The status of the override will be displayed at the end of the text (separated by field mark). First suffix =
classification code of OVERRIDE.CLASS record (if any), 'second suffix' = way of approval: 'I' = Inputter did
it, 'A' resp. 'A1' or 'A2' = Authoriser, any name = name of the person approving an override after
authorisation.

Approval (after authorisation) will be done by means of the standard authorisation function (A-
Function). This override approval function can be used although the operator has no allowance for
function 'A' in his user profile but has one or more classification codes in his user record.