Professional Documents
Culture Documents
The T24 Security Management System course is designed to teach you the SMS
related topics like Overrides, Dispo and Constraint Processing. Click the tabs on
your left to view the course introduction, objectives and structure.
Course Introduction:
Course Objectives:
In this course, you will learn the SMS related settings in T24.
The course is divided into four learning units, each comprising of simple, self-
contained topics. Concepts are explained using simple animations, demos and
practices. At the end of each learning unit, you will be presented with a small quiz.
You will receive immediate feedback on your responses to assess your level of
understanding.
Irrespective of where you work today, you have a role to play in your organisation.
You can do certain things, and you are restricted from doing others. In a bank, there
are different job profiles that an employee can have. For example, one can be a
Teller, another can be a Loan Disbursal Manager, or just the housekeeper. Now
should a Teller be able to disburse a loan? Will the housekeeper even be allowed
access to T24?.
The software that the bank uses must be able to control what an employee can and
cannot do once logged on. You are going to learn how this is done in T24.
T24 validates the data entered and if correct, the employee can access T24. If not,
an error message ‘SECURITY VIOLATION’ is displayed. This is the first encounter that
an employee has with T24 SMS.
Now if T24 has to validate this data entered, it must be stored somewhere in the
first place. These login details are stored in an application called USER. So if you
want to login to T24, you need a user profile, in other words a record created for
you in the USER application.
Both sign on name and password are masked when typed.
Once a user is successfully logged in to T24, SMS checks do not end there. Anything
that a user tries to do is tracked and can proceed only if the user has necessary
permissions. Before the bank allows all users to log on to T24 and start using it, it
must decide what a user has access to within this system. This must be done
because when a user tries to input a record in any application, T24 checks to see if
the user has the permission to do so before allowing to create the record.
Permissions that are checked here include whether the user has access to the Input
function and the application in use. This is where the user will encounter T24 SMS
for the second time. To save the record created an employee will click on the
validate button, before storing the record in the database the T24 application may
reference various static tables of data to complete the record just input. The user
does not need to have implicit permission to do so. This is not part of T24 SMS. If all
goes well and no overrides are encountered, the record is now stored in the
unauthorised file.
Every record in T24 must be authorised. When a user tries to authorise a record,
T24 must check to see if the user has the authorisation permission for the
application. User will not be allowed to authorise the record with insufficient
permissions.
Static information could be updated at this stage as well, for example accounting
entries etc. Explicit SMS setting is not required for all this. Close Of Business is the
process which does not need any user intervention and hence no SMS check is
required. The user administering COB must have the relevant SMS setting for COB
related applications. SMS comes into the picture even if you just want to execute an
enquiry in T24. In other words, even though you only want to view data, you must
have necessary permissions to do so.
To create a record in T24, you need to input all the mandatory fields and then get
the record authorised.
Inputter is the person who inputs data into the fields in a record. The user must
have access to the Input function.
Authoriser is the person who checks the record and authorises it. The user must
have access to the Authorise function.
1. Every user who needs login and to perform any action in T24 needs to have a
profile or in other words a record in USER application
2. Rights and privileges for a user are defined in his user profile . For example,
access given only to FUNDS TRANSFER and CUSTOMER application and also restrict
the access only to Input and List functions
To create a user in T24, you will feed values into some mandatory fields in the USER
application. You will now learn to create a simple USER profile. To create a user
record, type USER and the ID of the record you want to create in the command line.
USER ID and the USER NAME can be the same but the SIGN ON NAME has to be
different from the USER ID.
ID : This is the ID of the record in the USER application which can be any
alphanumeric text.
SIGN ON NAME : Name which the user will use to sign on to T24. Has to be different
from the name given in the field User Name.
PASSWORD : The password is also stored as part of the user profile. It is encrypted
at database level and is not displayed as part of the record in the USER application.
LANGUAGE : You have to set up the language field in the USER application for all the
messages, instructions, help text etc. to be displayed when possible in the language
indicated. The language codes are pre defined in the LANGUAGE table. The model
bank setup of T24 supports four languages namely : ENGLISH, FRENCH, GERMAN,
SPANISH. If the translation is not available for other languages, then ENGLISH will be
defaulted.
T24 allows the user to access multiple companies as it supports MULTI COMPANY
set up.
COMPANY CODE : Specify the companies to which the user has access to. The first
company code specified here will be the default company to which the user will log
on to. The companies defined in a T24 installation can be found in the COMPANY
application. The keyword ALL can be used to access all companies.
If the value in the COMPANY CODE field is specified to ALL and in the next multi-
value set if the company code is specified as EU0010001, then when the user logs
into T24 EU0010001 is the default company into which he will log into.
All users must belong to some department or the other in the Bank. Department
Code will allow an easy identification of any user of the T24 System. Department
Codes must be predefined in the static table DEPT.ACCT.OFFICER in T24. The
purpose of this table is to identify each Department and Account Officer in the bank
by means of a code.
DEPARTMENT CODE : Specifies the department to which the user belongs to.
PASSWORD VALIDITY : Specifies how often and on what date the User must change
his Password. Next Change Date entered, must be greater than today's date
(machine date) and not more than 6 months from today. Date until which the
password is valid followed by the frequency of change.
01 – 1st day of the 7th month after 1st Dec 2008 which is 1st June 2009
The next change date would be 1st Dec 2009 and so on.
There are fields in the USER application that controls the validity of the user profile.
This period is controlled by the following fields.
START DATE PROFILE : Date from which the profile of the user will be active. User
will be able to login into T24 from this date onwards. This field takes machine date
and not T24 date. Date entered in this field should not be less than today’s machine
date.
END DATE PROFILE : Date until which the user profile is active. The user will not be
able to login into T24 after this date.
If a user has access to T24, would the bank want to give him a 24hr access to the
system? No, in most cases the working hours of the bank will determine when a
user must be allowed to use the system. The fields Start Time and End Time control
the time span in a day when the user can log in to T24. Input can be like 0-2359,
0000-2359, 00:00-23:59, etc..
These two fields form a multi-value set, enabling multiple periods of time to be
defined per day.
If you want to open a savings account with a Bank, the user of the bank has to first
open a new record for you in the CUSTOMER application. In this process, if the user
who is opening the record for you is called for some other important work, he might
have to leave your record without completing and may walk away. No other user is
allowed to open your record and edit it as it will be locked by the first user. In such a
scenario, how long would you wait for the same user to return back and complete
your record? This is practically not possible. Therefore T24 supports the concept of
Time Out Minutes. The Administrator can specify the number of minutes the user
can be active without actually working on the system. If the time limit lapses for the
first user, he is signed off automatically and another user can complete your record.
TIME OUT MINUTES : Specifies the maximum time in minutes during which the User
may be inactive without being Signed Off automatically. Once this time is reached
the user is not allowed to perform any action. The user has to login again to perform
any action in T24. Maximum of three numeric characters which is 999 minutes.
Most websites that require a user name and password, have a check on the number
of times that a user can incorrectly type in a password. The account is then locked
and the user is forced to reset his password. T24 also supports this functionality
that allows the administrator to define how many unsuccessful sign on attempts a
user can have before locking his account. This helps safe guard the profile against
hackers.
ATTEMPTS : Allows only one numeric character to input and hence the maximum
can only be nine.
A user in T24 may not be allowed to perform same set of actions in different
companies. It is possible to specify application, function and field level restrictions
for a company. These set of permissions can be set up in the Associated multi value
set from COMPANY RESTR to DATA TO. The company to which you want to restrict
the access should have been mentioned in the COMPANY CODE field.
COMPANY RESTR : Contains a valid company code. This company should be defined
as part of the COMPANY CODE field. Permits to input "ALL" to allow the access for all
companies listed in the COMPANY.CODE field.
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.
‘2’ is not a function. This is used along with the function ‘A’ to allow the user to
authorise a record which needs a second authoriser. (Record status of a record
which needs a second authorisation would be INA2).
‘D’ is a function which allows the user to delete a record which is not yet authorised.
A live record cannot be deleted.
All the actions performed by the user may or may not be logged. PROTOCOL is the
file in T24 which stores the logging information of a user. If you want to record all
the actions performed by the user, the following fields have to be set to YES. This
file is updated by T24 and therefore records cannot be edited but only viewed.
SIGN ON OFF LOG : If set to YES, will log sign on and sign off details of the user in
the PROTOCOL file.
SECURITY MGMT L : If set to YES will log details in the PROTOCOL file when the user
accesses the following SMS related files in T24
PASSWORD.RESET
USER
APPLICATION LOG : If set to Yes will log details of applications that the user uses on
to the PROTOCOL file.
FUNCTION ID LOG : If set to Yes will log the functions and the IDs used by the user
on to the PROTOCOL file.
INPUT DAY MONTH : Format for the user to input dates. No matter how the date is
input by the user, T24 will store the data in YYYYMMDD format.
CLEAR.SCREEN : This is a mandatory field. This field is more oriented towards CUI
Interface where once a deal is committed the screen is cleared if set to ‘Y’.
If you set the field CLEAR SCREEN to ‘NO’, even after the transaction is complete
the record is still displayed on the screen.
If you set the field CLEAR SCREEN to ‘YES’, after the transaction is complete the
record gets closed and the screen is cleared.
Create a user profile with sign on name as your name with values into all the
mandatory fields that you have just learnt. Authorize the record and try logging in
to T24 with the new user you have created.
If in a particular company you want the user to have access only to few specified
applications and functions? Can you also restrict the user access based on actual
data contained in the records that the user is going to access. Is this possible in
T24?.
Yes. These specific restrictions can be achieved by using the fields from
COMPANY.RESTR to DATA.TO which form a multi value set. The field
COMPANY.RESTR can have the company code in which the user will be allowed
access only to few applications. The APPLICATION field will hold the name of the
application which can be accessed by the user. The field VERSION can contain a
valid version name of the application specified in the field APPLICATION. The field
FUNCTION will hold the function which the user can access in the particular
application.
FIELD NO : Must enter the actual field number of the required field from the record
in an application.
DATA COMPARISON : Must select the valid operand you would want to use for
comparison. This field can be left without any input also. Different operands
available are
EQ which resembles Equal To. This operand can also be used to specify a range of
values.
LK resembles Like
UL resembles Unlike
DATA FROM : Must enter a valid value for the field specified in Field No. This may
also contain the starting range.
User can access records in the CUSTOMER application for the company GB0010001
in Input mode only and provided the field SECTOR is EQ to 1000.
User can access records in the ACCOUNT application for the company GB0010004 in
Authorize mode only and provided the field CATEGORY ranges from 1000 to 2000.
The operand to use to select the range is EQ.
The following set of fields gives the information for Audit purposes. All these fields
are updated by the system and hence are no input fields.
This date is the actual date (system date and not T24 date) on which the User
Signed On.
TIME.LAST.SIGN.ON : Indicates the time of day at which this User last Signed On
successfully. It is displayed on the SIGN.ON Screen.
PASSW CHANGE DATE: Indicates the date on which the password was changed last
time.
DEACTIVATION.DATE : The date that defines the start of the deactivation period.
This can only be entered or changed by the User via the PASSWORD Application.
REACTIVATION.DATE : The date that defines the end of the deactivation period. This
can only be entered or changed by the User via the PASSWORD Application
CLEAR.SCREEN : This is a mandatory field. This field is more oriented towards CUI
Interface where once a deal is committed the screen is cleared if set to ‘Y’.
The code specified here will be defaulted when a transaction is input in some
applications like FUNDS.TRANSFER, FOREX, etc., by this user. The code to be
specified here should have an entry in DEALER DESK table. The currency position
specified for this dealer will be used for the transaction input by this user.
DEALER.DESK : Identifies the dealer desk position which needs to be updated by the
deal being created. Identifies the dealer desk code applicable to the user. If left
blank T24 will default code ‘00’.
PRINTER For Rpts : Name of a T24 printer to which reports will be spooled and
printed. Printer names specified in other report generation specific applications take
priority over this. Printer is set up using the application PRINTER.ID in T24.
Printer For P Func : Name of a T24 printer to which reports will be spooled and
printed when the user uses function P to print.
GB USER.ADDR : Address that will be printed on the report banner page. Each multi-
value represents one line on the banner. A maximum of three lines can be used. If
left blank then the delivery point from the DEPT.ACCT.OFFICER file is used.
RPT.TO.RECEIVE until Last Spool Time: This is a associated multi value set.
RPT TO RECEIVE : The name of the reports this user is to receive from the over-
night batch run. Must be a valid entry on the REPORT.CONTROL file.
LAST.SPOOL.TIME : The time the report was last spooled. Both the LAST SPOOL
DATE and LAST SPOOL TIME are no input fields.
The field ATTRIBUTES on the USER profile can be used to control specific T24
functionality. What you set in this field will decide what the user can or cannot do.
Some of the attributes can only be used if the front end is DESKTOP. The various
options available are explained in detail below.
COMMAND.LINE : The user is allowed the use of the command line in T24 Browser.
ENQUIRY.INDEX and EXPLORER : These options does not have enough information.
LOCK.DESIGNERS : Prevents user access to the listed Designer Tools dropdown list.
LOCK.PREFERENCES : If the user is given this option then the ‘User Preferences’
option under the ‘Tools’ menu on the Desktop toolbar will be disabled. This will
prevent the user from gaining access to various Desktop settings including file
locations and some system administrative functions.
NO.ENQUIRY.REPORT : Prevents user exporting Enquiry data from an Enquiry
screen, the icon will be dimmed and non reactive.
REALTIMEENQUIRY : Allows the use of real time enquiries for this user. When signing
onto T24, Browser will create another session for use by the real time enquiries.
This does use an additional database license, but not an additional T24 license. Not
enough information is available for this option as well.
SUPER.USER : The user has access to all of the features detailed above, and for all
future functionality with the exception of REALTIMEENQUIRY.
If you want T24 to perform some extra action during sign off process, you have to
define the following field.
SIGN.OFF.ITEM : The name of any BASIC subroutine can be entered into this field.
During the SIGN OFF process, any subroutines defined in this field will be called with
one parameter. If this parameter returns with the values N, or NO the SIGN OFF
processes will be halted
OTH.BOOK.ACCESS and OTH.BOOK.BLOCK fields are used only if T24 Multi Book
product is installed.
A Bank may not want its users to login to the system out of its working hours or
may even limit the user’s access to a specific time period. These settings can be
done using the following Associated multi value set.
ALLOWED DAYS : This field is used to specify the access to T24 in particular days.
You can choose a number from the drop down list which can contain a value from
one to seven where one is Monday and seven is Sunday.
DAY ST TIME : Time is based on 24 hour clock. This field indicates the start time of
the user’s access to T24 in a particular day.
DAY END TIME : This field indicates the end time of the user’s access to T24 in a
particular day.
Example with reference to the screen shot : User CHAITANYA1 can access T24 on
Monday from 10:00 to 15:00 and on Wednesday from 16:00 to 23:00
If the above set of multi value fields is not specified for a particular day, then the
values set in the field Start Time and End Time will be used.
If you want to sign on to T24 as soon as you signed on to your system, how can you
do it? This is possible in T24 in the following fields.
Ldap Id and Ldap Dn : These fields are used to configure the Temenos Connector to
use LDAP as part of the authentication mechanism. It is most widely used as part of
a corporate single sign on mechanism. The advantage of this system is that the T24
username and password are never known outside the T24 server. Ldap Dn becomes
mandatory field once Ldap Id is entered.
Irrespective of the date format given in the USER application, T24 stores the date in
a single format across. However you can set the display format of
Date Format : Describes the format for displaying the date. Options available are
1 - DDMONTHYEAR
2 - DD/MM/YYYY
3 - YYYY/MM/DD
4 - YYYYMMDD
OFFLINE.SMS.PROFILE field is used only if the BRANCH RESILIENCE product is
installed.
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.
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.
Another SMS check that you may encounter when you try to login outside the time
slab specified in your user profile (in the fields Day St Time and Day End Time).
3. At first sign on, Temenos T24 will ask for Password to be input twice
The bank can decide the format of all it’s user’s passwords. Many corporate
organizations follow this standard and thus T24 has options of implementing it.
This field defines the number of different passwords a user must input before being
able to repeat the first one.
2. This field defines the minimum number of characters in the password. The
minimum number of characters for a password is six which will be defaulted.
3. This field defines the number of upper case characters mandatory in the
password.
4. This field defines the number of lower case characters mandatory in the
password
5. This field defines the number of numeric values mandatory in the password
6. This field defines any other special characters or numbers or alphabets that
needs to be part of the password
7. Total of PASS.UPPER.ALPHA, PASS.LOWER.ALPHA, PASS.NUMERIC and
PASS.OTHER should not exceed a maximum of 16 characters and cannot be less
than six characters
SYSTEM PARAMETER FILE is an application where all the configuration details are
stored. This application has only one record SYSTEM. Password characteristics are
controlled in this record in six fields.
Earlier, T24 used a proprietary one way hash algorithm to store passwords. This
hash mechanism is replaced to enable use of standard encryption or hashing
algorithms that are generally accepted in the industry. The system can be setup for
using a locally developed algorithm for password encryption. Now, the client has the
option of by-passing the in-built security for user-login provided by T24. This can be
achieved by attaching the algorithm to the SPF application.
What if you forget your password? What if your account is locked since you
unsuccessfully tried different passwords and exceed the maximum number of
attempts? The application PASSWORD.RESET will allow an administrator to reset
your account. You may not have access to this application.
In this demo, you will learn how to reset your user account which has been locked
due to maximum unsuccessful attempts. Note that the field ATTEMPTS in USER
application is set to three.
If a user crosses the number of password attempts or if the user forgets the
password, these can be set in the following fields:
User Attempt : Every user is given a specific number of password attempts after
which the user account gets locked. Maximum number of password attempts is
specified in the application USER. Such locked user accounts can be unlocked by
giving the user name in the field User Attempt.
What if an administrator wants to activate a profile of an user even before the end
of the deactivation period? You can achieve this by setting the following field.
User Deact Perd : Specifies the ID of the user for whom the security administrator
wants to reactivate the profile before the end of the deactivation period.
User Reset : This field has the ID of a user whose password is to be reset.
User Password : A new password must be set in this associated field. This password
will be set up as expired once you login and thus the user will be forced to change it
on the sign-on.
In this demo, you will learn how T24 throws an error if you do not enter a new
password after its is reset.
The new password holds good for this user ID.
3. User should be allowed to access only the ACCOUNT and CUSTOMER applications
4. User should be allowed to use only functions. See, List and Print for the
CUSTOMER application. See and Exception listing for the ACCOUNT
application
6. User should be able to use the system only between 10:00 and 06:00 on all days
Stores login and logoff details if the field Sign On Off Log is set to YES in USER
application. Unsuccessful attempts to SIGN.ON are always logged, regardless of the
value in this field
Stores the log details if the user accessed SMS related files if the field Security
Mgmt L is set to YES
Stores the details if the fields Application Log and Function Id Log are set to YES
PROTOCOL file can be accessed in two ways
By typing PROTOCOL L in the command line to list all the records in the file
By running an enquiry ENQ %PROTOCOL, which takes you to the selection box
@ID : This is the code by which a record is identified. The format being:
YYYYMMDD is the date on which the recorded event (security violation or other
activity) occurred.
XX is the sequence number to identify the number of activities per one second.
Process Date : Date on which the activity took place. Displayed in the format which
was selected in the DATE FORMAT field in USER application.
TIME : Identifies the time at which the recorded event took place.
TIME.MSECS : Time when the activity took place denoted in the format
hh:mm:ss:msc
TERMINAL ID : The input is in the format NN XX. The first part of the terminal id
denotes the database user number and the second part denotes operating system
port number.
USER : Holds the USER.ID of the user who has performed the action.
APPLICATION : Identifies the Application which was being used by the user.
REMARK : This field denotes the activity performed and why the system did not
allow the attempted activity.
1. PROTOCOL file gets accumulated with all the activities performed by the user
and hence this file can grow very huge in size
1. What do you do if you have to set the same set of privileges to a group of users?
2. Will you set the privileges in every single user’s user profile?
3. Would you like to create something like a role in Oracle (set of privileges) and
apply it to the relevant users?
There are about 10 account managers in the bank for whom the following privileges
need to be granted
1. Restrict usage to the following functions only : Input, See, Delete and Authorize
2. Application that they can have access to is CUSTOMER provided the field Sector
is 1000. This can be done using an application USER.SMS.GROUP in T24
APPLICATION: Multi Value Field which is used to input all the applications which this
user group can have access to.
FUNCTION: This field is used to input all the allowed functions for the group of users.
FIELD NO: Specified when used together with fields Data Comparison, Data From
and Data To. For example, a CUSTOMER record can be accessed only if the field
no.23 in the CUSTOMER record, which happens to be field SECTOR is equal to 1000.
3. The millions & thousands separator can be a comma, full stop or apostrophe. The
decimal separator can only be either a comma or full stop
Input is restricted to two character pair. For example ., or ‘, or ‘. The first value is
the separator used for millions and thousands. The second value is the one used as
a decimal separator.
If you only enter the amount without any separators in the field Debit Amount and
validate the record, the separators are defaulted as set in the Amount Format field
in user profile.
After completing this learning unit, you will be able to:
An override in T24 is required in a situation where the user needs to be warned that
he has to confirm the action which he would be performing.
For example, A customer wants to withdraw $100 from his savings account which
has a balance of $150. Assume that by T24 norms, the minimum balance in the
savings account should be $100. Now if you input the transaction to debit $100,
when committing it T24 must warn you about the insufficient funds available. T24
cannot stop you, but it can warn you. T24 generates an override to do this. You will
have only two options, to accept it and complete the transaction or reject it and
stop.
When you input a record in any Application in T24 and commit it, it is possible that
you come across two types of messages.
In case of Error Messages, you need to correct the data input in the particular fields
and commit the transaction again. A record is not saved till all errors are corrected.
You cannot even put the record on hold.
Override Messages: These are warning messages, at least most of the time. A user
may accept or reject override. If accepted, T24 saves the record and the override
message is stored as part of it in the field OVERRIDE. If you do not want to accept
the Override, you may either put the record on hold to correct it later or amend the
record and commit it again.
In this demo, you will learn how overrides are handled in Classic mode of T24.
1. ‘Override’ is the name of the field which stores the override messages generated
on committing the record
1. There can be two different types of override messages. They are Non Blocked
and Blocked overrides
2. A record which generates non blocked overrides can be authorised by any user
in T24
3. A record which generates blocked overrides can be authorised only by users with
appropriate privileges. If you do not have sufficient privileges the record will go to
INAO (Input Not Approved due to Override) status
GB Message : This field contains the actual override message that is displayed on
committing the record.
So are override messages only static text messages? What if they need to hold
values from the transaction? In that case, the override message will also contain a
special character ‘&’ and each ‘&’ is then replaced with a value when T24 actually
generates the override.
In the override ACCT.UNAUTH.OD, the first & is used to denote Currency, the second
& to denote Amount and the third & to denote Account number.
Type, Channel and Approve Method : These fields are used only in ARC IB and are
not in the scope of this learning unit. However, to give you little information about
Channel field, based on the type of Channel you select to access T24 (like call
center, branch, internet, etc.,), you can set this Override message to act differently
such as a warning message, an error message, a confirmation message, etc.,.
Numeric Id : This is a no input field. T24 generates a unique number for every
record in the OVERRIDE application on committing the record. This number is
prefixed with ‘O’ which resembles Override.
App Version, Subroutine and Validation fields is used only in Desktop and does not
have any relevance in Browser.
You will now see an illustration to prove that all overrides in T24 by default are non-
blocked. In other words, no special permission is required to accept it.
You will see how the override ACCT.UNAUTH.OD is generated when you try to
transfer funds from a zero balance account to another account. The screen shot
above is of an account record created exclusively for this illustration. This account
now has a zero balance.
The account created earlier is debited in this FUNDS TRANSFER transaction. The
override message is displayed and you can accept it. The record is now committed.
After the record gets committed, open it in ‘SEE’ mode and check the field
OVERRIDE. You will notice that all the Overrides generated are stored in the record
and are never deleted.
1. Now that you realise what a non-blocked override is, the next thing to learn is
how to block an override
2. Any user can accept blocked overrides when generated and commit the record
thus moving it into INAU status
To grant the privilege to authorise records that have generated blocked overrides,
you must use the OVERRIDE.CLASS field in the USER application. This field accepts
any string data. The relationship of this data entered here and the override is
clearly visible from the screen shots.
The override record has been modified to include the user class details thus making
it a blocked override.
The user TRAINEE1 can now authorise the record which generated the
ACCT.UNAUTH.OD override.
You will now learn more uses of the fields APPLICATION and CLASS in the OVERRIDE
application.
You can also specify Class Application wise. For example, if the Override is
generated in the FUNDS.TRANSFER application, then only users with Class TEM in
their User profiles can accept it.
Class : This field specifies a group name. Users belonging to this group alone will be
able to approve this override. Class name can be any descriptive text. Maximum of
four characters only. The group name specified in this field should be attached in
the User profiles in the field ‘Override Class’.
Note that the user Chaitanya is not attached to the class TRG.
Now login as the user Chaitanya and input an FT transaction, accept the overrides
and commit the record. Open it in SEE mode and see the filed Override.3 being
suffixed with *. TRG which implies that only a user belonging to the class TRG can
authorize the record.
Note that the user CHAITANYA1 is not attached to the class TRG.
Now login as CHAITANYA1 and authorize the record. You will see the message ‘YOU
CANNOT APPROVE ALL OVERRIDES’. This is because, the user who tried to authorize
the record is not one among the class specified in OVERRIDE application.
You can see the record status has gone to INAO. Only users with the field Override
class set to ‘TRG’ in the user profile can authorize the record.
Note that the user TRAINEE1 is attached to the class TRG.
Now login as TRAINEE1 and authorize the same FT record. Open the record in SEE
mode and check for the field Override.3 being suffixed with
‘*TRG*TRAINEE1_OFS_BROWSERTC’
TRAINEE1 resembles the name of the user who has approved the override.
OFS_BROWSERTC denotes that the record has been authorized from Browser
frontend.
Note that the field Authorizer still holds the user CHAITANYA1 and does not change
to TRAINEE1.
Now what if you login as TRAINEE1 who belongs to the class TRG, and input a
FUNDS.TRANSFER transaction and commits it?
Open the record input by TRAINEE1 in SEE mode and look at the value in the
Override field suffixed with *TRG*I which implies that the user belonging to the
class ‘TRG’ has only input the record. In such a case, since TRAINEE1 has only input
the record, any other user who does not belong to the class also can authorize the
record.
Now what if you login as TRAINEE1 who belongs to the class TRG, and input a
FUNDS.TRANSFER transaction and commits it?
Open the record input by TRAINEE1 in SEE mode and look at the value in the
Override field suffixed with *TRG*I which implies that the user belonging to the
class ‘TRG’ has only input the record. In such a case, since TRAINEE1 has only input
the record, any other user who does not belong to the class also can authorize the
record.
1. There might be many such cases in a Bank that a simple Class restrictions may
not be sufficient
2. What if there is a need to restrict access to authorize the record which has a
specific value?
Using an illustration you will learn how to block overrides based on conditions.
Table Row 1 : Only the user ACCTOFF1 can approve the override if the currency is
USD and the overdraft amount is in the range one to 10000
Table Row 2 : Only the user ACCTOFF2 can approve the override if the currency is
USD and the overdraft amount is in the range one to 10000
3. Manager classification
Table Row 1 : Only the user MANAGER1 can approve the override if the currency is
USD and the overdraft amount is in the range 10001 to 50000
Table Row 2 : Only the user MANAGER2 can approve the override if the currency is
USD and the overdraft amount is in the range 10001 to 50000
4. GM classification
Table Row 1 : Only the user GENMGR1 can approve the override if the overdraft
amount is in the range 50001 to 1000000
To set the multiple level restrictions to approve an override you have to use the
application OVERRIDE.CLASS.DETAILS. You can set different groups who can
approve overrides only if the conditions specified in their groups are satisfied.
Data Def : This field refers to the & values in the override message.
ACCT.UNAUTH.OD is the Override in which &1 refers to Currency, &2 refers to
Amount and &3 refers to Account. In this example, conditions are specific to only
Currency and Amount and hence only &1 and &2 are defined.
Classification : This field holds any user defined text that best defines the group
classification.
Data Def No. : This field indicates which data item, as defined in the field DATA DEF
is to be used for the classification.
The number in this field identifies which multi-value from the field DATA DEF is to be
referred. For example, the number '1' indicates that it is the data item defined by
field DATA DEF.1 and the number '2' indicates that it is the content of field DATA
DEF.2 . You can also define one DATA DEF and use it for all the classifications.
Comparison : It refers the operand to be used. Must select the valid operand you
would want to use for comparison. This field can be left without any input also.
Different operands available are
Data From : This field holds the value indicated in the field DATA DEF (according to
the field DATA DEF NO), is compared against the value in this field according to the
operator in the field COMPARISON. If the outcome of the comparison is true, the
corresponding CLASSIFICATION group will be allocated the override.
When the override message is raised from the application FUNDS.TRANSFER, the
conditions specified in the record TRAINING in the OVERRIDE.CLASS.DETAILS
application will be checked and appropriately validated.
If the override message is raised for an amount which is beyond the amount
specified in OVERRIDE.CLASS.DETAILS then only the users who belong to the class
TRG can approve the override.
When the override message is generated for applications other than
FUNDS.TRANSFER (Denoted using a *), users with the field Override Class set to
TRG in their user profiles will be able to approve the override.
Specify the value given in the field CLASSIFICATION (first multi value set) in
OVERRIDE.CLASS.DETAILS and in the field OVERRIDE CLASS in the User profiles of
ACCTOFF1 and ACCTOFF2.
Specify the value given in the field CLASSIFICATION (second multi value set) in
OVERRIDE.CLASS.DETAILS and in the field OVERRIDE CLASS in the User profiles of
MANAGER1 and MANAGER2.
Specify the value given in the field CLASSIFICATION (third multi value set) in
OVERRIDE.CLASS.DETAILS and in the field OVERRIDE CLASS in the User profiles of
GENMGR1.
Login to T24 as any user and input a FT debiting an account with nil balance with
USD 9000.
In this demo, you will learn how to set simple multi level restrictions to approve
overrides in T24.
1. Login as any user and input an FT debiting an account with nil balance with USD
10400
3. Note that the record status is INAO as ACCTOFF1 does not have the privileges to
authorize transactions with overdraft amount beyond USD 9000
4. Login as MANAGER1 and authorize the record
5. The authorizer field will still show value of ACCTOFF1 only as initially the record
was authorized by the user ACCTOFF1
In this demo, you will learn how the record moves from INAU to INAO to LIVE status
when authorized by users who do not have enough permissions to approve
overrides.
1. Login as any user and input a FT debiting an account with nil balance with USD
51000
3. Only user GENMGR1 will be able to approve the override and authorize the
record
In this demo, you will learn how to set multi level restrictions to approve overrides
and try to authorize the record with different users in T24.
1. Login as any user and input an FT debiting an account with nil balance with USD
2000000
3. Since the overdraft amount does not fall into any of the ranges defined in the
OVERRIDE.CLASS.DETAILS application, the default class TRG defined for FT has
been used
4. Therefore, this override can be approved only by users who have class set to
TRG in their User profile
In this demo, you will learn how to any T24 user can approve overrides which do not
fall under the amount which are set in OVERRIDE.CLASS.DETAILS.
For example, If an FT is input and the overdraft amount is 9000, the override
message will always appear as <Override Message>* ACOF.
A user with MGR override class set will not be able to approve the above mentioned
override.
Logically a user with MGR override class set should be able to approve an override
of 9000 USD. To get this done, you need to add ‘ACOF’ apart from the ‘MGR’ class in
the user profile of MANAGER1 and MANAGER2.
You are now familiar with the concept of override processing in T24. Can an
override message be triggered as an error in T24?
The answer is yes. The field TYPE in OVERRIDE application has the following options
– Error, Auto, Message and Warning. When TYPE is set to Error, the override
message becomes an error. When TYPE is set to Auto, the override message will be
automatically accepted by T24 , the user acceptance is not required.
You will not be allowed to commit the record when an error is raised in T24.
In the previous example, the override was displayed as an error message. Now can
you display customised error messages for overrides?
The above created record should be attached to the OVERRIDE application in the
field MESSAGE.
When the override is triggered in a transaction, you could see the customised error
message displayed.
1. Can you simply create a new Override without any hassels?
2. No. OVERRIDE is one of the core applications in T24. It is not possible to simply
create a new record in OVERRIDE application and let it to populate for any records
in any applications. Only TEMENOS DEVELOPMENT can do it. However Client
customization is possible but is not as simple as creating any record in OVERRIDE
application. All the override messages to be generated should be defined in the
OVERRIDE application in T24
For example, When T24 wishes to raise an override stating that a particular account
has been over drawn, it will only say that an override ACCT.UNAUTH.OD needs to be
raised. T24 core then picks up the actual message from the field GB Message in
OVERRIDE application and displays it.
DISPO PROCESSING:
2.There can be two different types of override messages. They are Non Blocking
and Blocking overrides.
2.1 A record which generates non blocking overrides can be authorized by any user
in T24.
2.2 A record which generates blocking overrides can be authorized only by users
with appropriate privileges. If you do not have sufficient privileges the record will go
to INAO (Input Not Approved due to Override) status.
By default, all overrides in T24 are Non Blocking in nature.
Teaching you how to block and un-block overrides are not in the scope of this
learning unit.
You are absolutely right if you think that this can be achieved through
OVERRIDE.CLASS.DETAILS
Tom wants to transfer funds from his account to Tim’s account. The T24 way to do
this is by using the application FUNDS.TRANSFER. What if Tom’s account does not
have enough funds? Will the transaction abort? No.
T24 will allow him to perform the transaction by overdrawing his account. The
system will raise an override on committing the transaction, telling the T24 user
that Tom’s account does not have enough funds and is being overdrawn.
What if the bank wants to set a limit on the amount of overdraft that a particular
user can authorize?
In the override record, you have to specify a valid DISPO Officer ID in the field
DISPO.OFFICER
Now that you have done the base work, will it be feasible if any T24 user can view
the records in DISPO.ITEMS and approve or reject or comment it?
To control such a situation, you need to assign a DISPO Officer to a particular user
in the USER application. The field DISPO.OFFICER is used to assign the Officer. The
input in this field should be a valid officer defined in DISPO.OFFICER application.
DISPO Officer is the one of the important fields in the DISPO.ITEMS application.
DISPO Officer has the right to approve or reject or comment on DISPO Items
SHORT.TITLE : This is a multi lingual field which holds the description for the DISPO
officer in different languages
OVERRIDE.ID : This field holds the ID of an override record, for which DISPO
processing has been enabled. This is a multi value field and will hold all the override
IDs that this officer will deal with
DISPO.AMOUNT : This field holds the amount up to which the Officer can comment
on an override
OVERDRAFT.AMT : This field holds the amount up to which the Officer can approve
or reject an override
NEXT.DISPO.OFF : This field holds the ID of the next level Officer for financial
Overrides, to whom the DISPO Item would be assigned, in case the current Officer
does not have privileges to approve an override
When a particular DISPO Officer is not available for a specific time, you can set an
alternate DISPO Officer who will be acting like the actual Officer for the specified
time.
ROUTE.TO : This field holds the ID of the DISPO Officer to whom the DISPO items
should be routed for the dates and times specified in the DATE.FROM, DATE.TO,
TIME.FROM, TIME.TO fields. Only if this field contains a valid DISPO Officer ID, the
other fields like DATE.FROM, DATE.TO, TIME.FROM, TIME.TO will be input able.
Otherwise all these fields are no input fields.
DATE.FROM : This field holds the date from which the DISPO Item should be routed
to the alternate DISPO Officer
DATE TO : This field holds the date till which the DISPO Item should be routed to the
alternate DISPO Officer
TIME FROM : This field holds the starting time on a day from which a particular
DISPO item should be routed to the alternate DISPO Officer.
TIME TO : This field holds the ending time on a day till which a particular DISPO item
should be routed to the alternate DISPO Officer.
Example : FT08009436R9*BNK
APPLICATION : This field holds the application name by which the override has been
generated.
OVERRIDE.TEXT : This field holds the actual override message as generated in the
transaction.
CURRENCY : This field holds the currency of the account which has been debited in
the transaction.
AMOUNT : This field holds the total amount overdrawn on the debited account.
ACCOUNT.OFFICER : This field holds the ID of the account officer responsible for the
account.
DATE and TIME : These fields hold the date and the time in which the override was
raised in the transaction .
CUSTOMER.NO : This field holds the ID of the customer who holds the account.
OVERRIDE.ID : This field holds the ID of the override record that is generated.
In the DISPO.OFFICER record with ID 101 set the ROUTE.TO field 102. This means
that the DISPO item should actually be approved or rejected or commented upon by
DISPO officer 101, however since he is not available the item will be assigned to
DISPO Officer 102.
Input an FT transaction, accept the overrides and commit the record. A record in
DISPO.ITEMS should have been created with ID as TransactionID * Company
mnemonic. Now open the record in the DISPO.ITEMS application and check for the
fields DISPO.OFFICER and COMMENT.OFFICER.
You will note that both these fields are defaulted to officer 102 and not 101 though
the amount falls under the officer 101 range. This is because, the ROUTE.TO field in
the officer 101 record is set to officer 102 for 9th Jan from 10AM to 06PM, and the
FT transaction was input and committed within this time frame.
DISPO.ITEMS is the application used to view the DISPO items. However, you can use
an enquiry DISPO.DETAILS to
2. Enquiry DISPO.SUMMARY can be used to view all the pending DISPO items for
approval.
3. You have been hearing the words approve, reject, comment a DISPO item all
through the course. Can you simply open a record in DISPO.ITEMS and authorize it?
The system will not allow you to do so. You can perform this action only by using
the enquiry DISPO.SUMMARY or DISPO.DETAILS.
Try authorizing a DISPO item. The system will not allow you to do so. This is
because, the record status is INAU. To authorize a DISPO item, the record should be
in INAO status. Try to authorize the record with a user who is not assigned an
appropriate DISPO officer and then check the record status. The record will now be
in INAO status and is ready for authorizing or rejecting or commenting.
4. Only a user who is assigned a DISPO officer can open the record in see mode.
However, a user who is not assigned any DISPO officer can still list the DISPO items.
Also remember, user with an appropriate DISPO officer can only approve or reject or
comment an item with in his limits defined in the DISPO.OFFICER application.
User inputs an FT transaction. When the user accepts the override message
generated, the transaction is complete and the record goes to INAU status. At this
stage a record in DISPO.ITEMS is created.
Open the item and note that the fields DISPO.OFFICER and COMMENT.OFFICER are
defaulted to officer 100 as the transaction amount falls in his approval limits.
Login as another user who do not have the DISPO officer set and try authorizing the
FT record.
Login as the user who has appropriate DISPO authorities and approve the DISPO
item. Open the enquiry DISPO.DETAILS for the officer – 100. All the DISPO items
available for the officer 100 are displayed. Click on the button ‘ADD COMMENT’ to
either approve or reject or comment the item. After the record is open, approve it
and commit the record. Now you should be able to authorize the corresponding FT
record. The transaction is complete and the FT is authorized by the appropriate
DISPO officer. If the DISPO officer reject the DISPO item, then you will not be able to
authorize the FT transaction.
Enquiry DISPO.SUMMARY will display all the records enabled for DISPO processing
for all the DISPO officers. If the user has sufficient privileges, he can add the
required comments, approve or reject the DISPO item. All the comments made are
recorded in the DISPO.ITEMS record.
Enquiry DISPO.SUMMARY will display all the records enabled for DISPO processing
for all the DISPO officers. If the user has sufficient privileges, he can add the
required comments, approve or reject the DISPO item. All the comments made are
recorded in the DISPO.ITEMS record.
Officers can either comment or approve or reject based on the amount involved in
the override generated by a transaction.
2. The officer who can comment an override is the COMMENT.OFFICER and the
officer who can approve or reject the override is the DISPO.OFFICER
Table Column 3 holds the amount up to which an Officer can approve or reject an
override.
Table Column 4 holds the ID of a DISPO Officer who is the next level financial
approver.
The officer with ID 100 can comment on amounts lesser than or equal to 20,000 and
can approve or reject overrides with overdraft amount lesser than or equal to
10,000. If this DISPO Officer cannot approve or reject overrides, then 101 is the next
Officer who has privileges to approve or reject or comment on the override.
When an FT transaction was input for 20,123, which falls under the officer 101, both
the DISPO.OFFICER and COMMENT.OFFICER fields are populated with the respective
officers in DISPO.ITEMS record. This implies that only officer 101 can comment and
either approve or reject this override.
Now try answering the following questions. The transaction amount is 20,100.
5. Officer 101
6. Officer 102
1. All that you have seen till now is partial DISPO processing. There is much more
added functionality for DISPO processing
2. If DISPO field is set to ‘YES’, then DISPO processing can be enabled with limited
features.
2. DISPO.ALLOWED field is set at the core and cannot be modified by any user. The
field DISPO should also be set to ‘YES’
3. If an override is enabled for full DISPO processing, then the fields PRECEDENCE,
TRANSACTION.IND, CONDITION.CON in the OVERRIDE application can be used
1. Most of the overrides in T24 are stored in an application called OVERRIDE. The
example which was discussed in the previous slide is a record in the OVERRIDE
application with ID as ACCT.UNAUTH.OD. Based on the special certifications
required for a transaction, DISPO Processing may or may not be allowed for an
Override
2. To enable full DISPO Processing for an Override, the first step is to check if the
field DISPO.ALLOWED is set to ‘YES’ in the OVERRIDE application. This field is set at
the core which means whether or not an Override is allowed for DISPO is decided by
Temenos and T24 user cannot modify this field
Now you should be able to differentiate that if the field DISPO.ALLOWED is set to ‘’
(NULL) and the field DISPO is set to ‘YES’, then the override is enabled for partial
DISPO processing. If the field DISPO.ALLOWED is set to ‘YES’ and the field DISPO is
set to ‘YES’, then the override is enabled for full DISPO processing
2. If the field PRECEDENCE is set for an override, then the officer assigned in that
particular application will take precedence over the officer set in the OVERRIDE
application. When no officer is identified in the application, then the item will be
assigned to the default officer specified in the override record
3. The value in this field must be input in the format ‘APPLICATION NAME>FIELD
NAME FOR OFFICER IN THE APPLICATION’. Example : ACCOUNT>DISPO.OFFICER
To check the functionality of the field PRECEDENCE, set the DISPO.OFFICER field in
ACCOUNT record - 35475 to a valid DISPO officer - 101. Open the record
ACCT.UNAUTH.OD in the OVERRIDE application, and set the field PRECEDENCE as
ACCOUNT>DISPO.OFFICER and in the field DISPO.OFFICER, set an officer other than
the one set in the ACCOUNT record - 100. Attach the officer 101 in the field
DISPO.OFFICER in a user record. Input an FT transaction by debiting the account
35475. Accept the overrides and view the transaction in DISPO.ITEMS. Note that the
fields DISPO.OFFICER and COMMENT.OFFICER are defaulted to 101 as set in the
ACCOUNT record and not to 100 as set in the OVERRIDE record.
1. To disable DISPO processing for a transaction, the field TRANSACTION.IND should
be set to ‘YES’
To enable the functionality of the field TRANSACTION.IND, the first step is to open
an FT record, and note the statement number generated for the transaction. Open
the corresponding STMT.ENTRY record and note the value in the field
TRANSACTION.CODE - 213. Now view the record - 213 in the TRANSACTION
application and note the field GB.NARRATIVE. Set the field DISPO.EXEMPT to ‘YES’.
Set the field TRANSACTION.IND in the OVERRIDE application to ‘YES’. Input a new FT
record with TRANSACTION.TYPE ‘AC’ as the transaction code is 213 and commit the
record. Now try to view the same record in DISPO.ITEMS application. There will be
no DISPO item for this transaction as you have exempted transaction type 213 from
DISPO processing.
You already know that a particular transaction can be exempted from DISPO
processing in spite of the override being enabled for DISPO.
1. You can set conditional DISPO processing using the field CON.OVERRIDE which
will hold the ID of another override
2. For the transaction to be enabled for DISPO processing, the actual override and
the override specified in this field should be generated. If either of the overrides is
generated, the transaction will not be subject to DISPO processing and will not have
an entry in DISPO.ITEMS.
To understand the functionality of the field CON.OVERRIDE, check out for override
records which have the field DISPO.ALLOWED set to ‘YES’. Open the record
LIMIT.UNAVAIL in the OVERRIDE application and set the field CON.OVERRIDE to
‘EXCESS.ID’ which is ID of an override record and is enabled for full DISPO
processing. Check if both the records LIMIT.UNAVAIL and EXCESS.ID has the field
DISPO.ALLOWED set to ‘YES’ and DISPO.OFFICER set to the same officer – 105. In
the record 105 in DISPO.OFFICER application, add both the override IDs. Input a new
LD record and note that both the overrides are generated. Accept the overrides and
commit the transaction. Now view the record in DISPO.ITEMS. Note that both the
overrides generated are recorded in the DISPO item. Input another LD record and
validate the transaction. Note that only one override has been generated for this
record. Accept the overrides and commit the record. Copy the record ID and check if
there is any DISPO item for this transaction. There will not be any DISPO item as the
LD has generated only one override and therefore the transaction is not enabled for
DISPO processing.
No dispo item will be found which matches the ID, as this record has generated only
one override and is therefore not enabled for dispo processing
1. The field DISPO should be set to ‘YES’ and the field DISPO.ALLOWED to ‘’ (NULL)
to enable partial DISPO processing. The field DISPO.ALLOWED should be set to ‘YES’
along with the field DISPO set to ‘YES’ for full DISPO processing. If an override is
enabled for partial DISPO processing, then the fields PRECEDENCE,
TRANSACTION.IND, CONDITION.CON in the OVERRIDE application cannot be used.
You cannot set the fields DISPO.AMOUNT and OVERDRAFT.AMT in DISPO.OFFICER
application
2. Create Officers using DISPO.OFFICER application
4. If the PRECEDENCE field is set, then set the DISPO.OFFICER field in the
appropriate application
7. Open the record using the enquiry LLS to reject or approve or to add a comment
1. Create an account
When you input a record in any Application in T24 and commit it, it is possible that
you come across two types of messages.
Due to incorrect relationship between field name and the data that is input.
In case of Error Messages, you need to correct the data input in the particular fields
and commit the transaction again.
A record is not saved till all errors are corrected. You cannot even put the record on
hold.
Override Messages: These are warning messages, at least most of the time. User
has only one option to Accept Overrides. If accepted, T24 saves the record and the
override message is stored as part of it in the field OVERRIDE. If you do not want to
accept the Override, you may either put the record on hold to correct it later or
amend the record and commit it again.
1. Have you ever been able to generate an override message for a condition of
your choice?
2. Have you ever been able to generate an error message for a condition of your
choice?
At this point you may be thinking if you really can generate errors and overrides for
a condition of your choice in T24.
T24 allows you to create errors and overrides for custom defined conditions using
the Constraint Processing.
EB.GC.PARAMETER can have two types of records. The ID of the record may be
‘SYSTEM’ or <COMPANY CODE> Eg.: GB0010001
Values set at the global level (in the SYSTEM record) will be overridden by the
values set in the records created for specific company.
EB.GC.ACTIVE is a FIN type file and the values that are set here are company
specific. This application is used to disable or enable constraint processing for a
particular application. The ID of the record should be <APPLICATION NAME> Eg.
LD.LOANS.AND.DEPOSITS. The field APP.PROCESSING should be set to ‘YES’ to
enable or ‘NO’ to disable constraint processing.
What could be the next step after constraint processing is enabled for an
application?
The next step to do after an application is enabled for constraint processing is to
define the conditions and the message to be generated. This can be achieved
through EB.GC.CONSTRAINTS. The ID should be the application name. Eg.:
LD.LOANS.AND.DEPOSITS.
TEST.FIELD : This field holds a valid field from the respective application (record ID
is the application name). Eg.:The value in this field is given as INTEREST.RATE which
is a valid field in the application LD.LOANS.AND.DEPOSITS.
T24 performs a validation check on this field. If a wrong field name from the
application is entered, an error is thrown at the user.
OPERAND : This field holds the operand against which a condition is generated.
EVAL.VALUE : This field holds the value or set of values for comparison against
which an override or an error is generated.
SEPERATOR : This field holds the separator to be used for the values mentioned in
the field EVAL.VALUE
FIRST.VALID.DATE : This field holds the value date from which the constraint
becomes active. The date in this field should be current date or a date greater than
today.
You are now ready to generate the override set in constraint processing. Input an
LD record with the value in the field INTEREST.RATE greater than five.
Note that the overrides set by the core and the overrides set in constraint
processing are generated. The value given in the field NARRATIVE in the
LD.LOANS.AND.DEPOSITS record in the EB.GC.CONSTRAINTS application is
generated as the override.
Now that you know how to generate an override, you can generate an error
message also. Give the conditions for an application (Eg.:FUNDS.TRANSFER) in the
EB.GC.CONSTRAINTS application. To generate a message as an error, set the field
ERROR.OVERRIDE to ‘ERROR’.
Eg.: If a record is committed in the FT application, an error should be generated if
the field TRANSACTION.TYPE is not equal to ‘AC’.
Note that the error message is generated as it is given in the field NARRATIVE in
EB.GC.CONSTRAINTS application when the field TRANSACTION.TYPE is not set to AC
in FUNDS.TRANSFER application.
What if you wish to generate same errors or overrides for different applications?
Eg.: When contracts are input in applications such as LD, MM and FT, if the loan
amount or deposit amount or debit amount transacted is greater than 200000, an
error message “Amount should be less than 200000’ needs to be generated.
1. T24 has the functionality to generate the same error or override message for
multiple applications, based on specific fields
2. Grouping users is done to set same set of privileges for a group of users in
USER.SMS.GROUP. Grouping applications for constraint processing is similar to that
EB.GC.GLOBAL is the application in which all the application names and their
respective fields for which you wish to check the condition and raise the same
override or error are stored. The ID of the record in EB.GC.GLOBAL can be any user
defined value. Eg.: ABCD, FT, 1235, TOM, etc..
APPLICATION : This is a multi value field which specifies the application name for
which the override or error has to be generated
TARGET.FIELD : The field holds the field name from the application mentioned in the
previous field for which the condition has to be checked.
Even before you set up the record, the applications that are to be used in
EB.GC.GLOBAL should be enabled for constraint processing. As you know by now,
this can be achieved by using the application EB.GC.ACTIVE.
The field TEST.FIELD should contain a field name of the application which is the ID
of the record in EB.GC.CONSTRAINTS application. What will you specify in this field if
the ID is set to ‘GLOBAL’?
In the record ‘GLOBAL’ the field TEST.FIELD should hold the ID of the record (in
which the applications are grouped) from EB.GC.GLOBAL application.
If you recollect the example you have seen in the earlier slides, the applications
LD.LOANS.AND.DEPOSITS and FUNDS.TRANSFER have application specific records in
EB.GC.CONSTRAINTS. The conditions were - If interest rate is greater than 5%, an
override to be raised and if TRANSACTION.TYPE is not AC, an error to be raised
respectively.
You have also set the group which is a part of the record ‘GLOBAL’ in
EB.GC.CONSTRAINTS application in which LD, FT and MM are included. The
constraint set for this record is - If amount is greater than 200000, then an override
is to be raised.
2. Will the conditions set in the application specific records as well as the conditions
set in the GLOBAL record be executed for LD and FT? Yes. If both the conditions are
executed, then this is known as Cumulative constraint processing.
3. Can you specify that the conditions specified in application specific records alone
should be executed for LD and FT? Yes. This is known as Single constraint
processing.
The value set in the field APP.METHOD in EB.GC.ACTIVE takes precedence over the
value set in the field COM.METHOD in EB.GC.PARAMETER application.
Since CUMULATIVE processing is enabled for FT, constraint set for the application as
well as the constraint set in the GLOBAL record are executed.
Since SINGLE processing is enabled for LD, only the constraint set for the
application in the application specific record is executed.
Note that though the value in the amount field is greater than 200000, an error is
not generated but the application specific override is generated as the field
APP.METHOD in LD record in EB.GC.ACTIVE is set to SINGLE and the application
level setting takes the precedence.
Since CUMULATIVE processing is enabled for MM, constraint set in the GLOBAL
record is only executed as it does not have a constraint set in the application
record.
1. What if you wish to restrict a user to use only a particular value in a field?
Eg.: When contracts are input in LD application by the user CHAITANYA, she should
only be allowed to use a value 21051 in CATEGORY field. If she inputs any other
value other than 21051 , an error ‘CATEGORY SHOULD BE 21051’ is to be
generated.
To set constraint for a specific user, create a record in EB.GC.GLOBAL with ID as any
text and specify the application and the field name against which condition is to be
set.
As you already know, the field TEST.FIELD should hold the ID of the record (created
for user specific constraint) from EB.GC.GLOBAL application. The other fields should
hold the conditions and the error message to be generated.
If the field APP.METHOD is set to SINGLE, then the user specific constraints are only
executed. One important thing to note here is the order of precedence for
constraints to be executed. User specific constraint is to be executed first,
application specific constraint is the second and group specific constraint is the last.
Eg.: When a contract is input in LD with AMOUNT set to 300000 CATEGORY set to
21052 and INTEREST.RATE set to 9%, only one error for the field CATEGORY is
raised and no other constraints are executed as LD enables only SINGLE constraint
processing.
To overcome this, there are a set of fields in EB.GC.PARAMETER which controls the
precedence of constraints when single constraint processing is enabled. The fields
PRECEDENCE.USER, PRECEDENCE.CURR, PRECEDENCE.ACCT, PRECEDENCE.PORT
and PRECEDENCE.CUST will define the order of precedence. These fields can hold a
value from one to five. A value of one in any of the fields means that, this specific
constraints takes the precedence over the other.
You can achieve this by creating another record in EB.GC.GLOBAL with the required
applications and relevant fields, attach the ID of this record in the field TEST.FIELD
and specify other conditions in EB.GC.CONSTRAINTS. This is similar to what you
have already done.
However, you can also achieve this by using another application EB.GC.GROUP
Normal way of achieving this grouping is to create a record with the required
applications (which were already a part of the group) in EB.GC.GLOBAL, and attach
it in EB.GC.CONSTRAINTS application with the condition.
Eg.: Create another group for LD and FT with their relevant fields, with ID set to
CURRENCY. Attach this ID in the record GLOBAL in EB.GC.CONSTRAINTS.
APPLICATION : This is a multi value field which specifies the list of applications
which are members of this subgroup. Only the applications which have a record in
EB.GC.ACTIVE can be input in this application.
Eg.: Generate an error ’CURRENCY MUST BE USD’ for the applications LD and FT if
the currency used is not equal to USD
As soon as a record is created and authorized in EB.GC.GROUP, the field GROUP is
updated with the ID of the subgroup record in the corresponding record in
EB.GC.ACTIVE application.
GROUP : This is multi value field and is not inputtable by the user. This field holds
the ID of the records in EB.GC.GROUP
Create a record in EB.GC.GLOBAL with the required applications and their relevant
fields. Create a record in EB.GC.CONSTRAINTS whose ID is the same as the ID in
EB.GC.GROUP. Attach the ID of the record created in EB.GC.GLOBAL in the field
TEST.FIELD in EB.GC.CONSTRAINTS application and specify the relevant conditions.
Take a look at the records. In both FT and LD the error ‘CURRENCY MUST BE USD’ is
raised.
As the field APP.METHOD is set to SINGLE in EB.GC.ACTIVE, in FT, error is raised for
DEBIT.AMOUNT field as the value in this field should be less than 200000.
Eg.: When a credit account with currency other than USD is input in a FT
transaction, an override message ‘CREDIT CURRENCY IS NOT USD’ needs to be
raised. This override should only be approved by user belonging to a particular
class.
The fields COM.DIAG and APP.DIAG can hold the value ‘YES’ or ‘NO’. A value ‘YES‘
denotes that diagnostics recording is enabled. This field decides whether or not the
constraints are to be logged.
The field COM.DIAG.LIFE holds the number of days after which the logs should be
deleted.
The settings in the field APP.DIAG in EB.GC.ACTIVE takes the precedence over the
settings in the field COM.DIAG in EB.GC.PARAMETER application.
When the condition set for a particular field is breached or violated, the constraint is
triggered. At this point, a log will be created in the file EB.GC.DIAGNOSTIC. This is a
live file and updated by the system.
All the details of the constraint are stored in this record. The field DATE holds the
date on which the log was entered and the field DEATH.DATE will hold a date which
is equivalent to the date of the log + the number of days given in the field
COM.DIAG.LIFE.
Eg.: If the log date is 7th August 2008 and the COM.DIAG.LIFE will hold a value of 8,
then the death date will be 19th August 2008.
1. Who will actually delete the logs from the file EB.GC.DIAGNOSTIC and when?
A COB job named EB.GC.DIAGNOSTIC.COB deletes the log if the value in the field
DEATH.DATE is less than today
2. EB.GC.DIAGNOSTIC.COB checks the field DEATH.DATE for all the records and if
this is less than today, then the log record is deleted from the file.
1. T24 allows you to create override and error messages using the ‘Constraint
Processing’