You are on page 1of 70

T24 - Security Management System

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:

“T24 Security Management System” is a self-paced learning course. This course is
recommended for anyone who wishes to learn about the SMS settings in T24. This
does not need any pre-requisites courses to be attended.

“T24 Security Management System” is an audio-enabled course. Please keep your
speakers switched on to optimize your learning experience. You may click the Notes
button on the left pane to view the course notes.

Course Objectives:

In this course, you will learn the SMS related settings in T24.

After completing this course, you will be able to:

 Explain in detail about various applications involved in SMS

 Explain override and error processing in T24

 Explain the password related settings in T24

 Explain the concept of Dispo and Constraint Processing

Course Structure:

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.

Why does SMS need to be a part of T24?.

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.

To login to T24, an employee needs to input a sign on name and password.

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.

Once the record is authorised, it moves to the authorised file.

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.

SIGN ON NAME : Name which the user will use to sign on to T24. The user profile is nothing but a record in the USER application To create a user in T24.AUTHORISER/INPUTTER” will be displayed if the same user tries to input and also authorise the record. The user must have access to the Authorise function. USER NAME : This field holds the name of the user.RTN.NAME. you will feed values into some mandatory fields in the USER application.Inputter is the person who inputs data into the fields in a record. . You will now learn to create a simple USER profile. Authoriser is the person who checks the record and authorises it. ID : This is the ID of the record in the USER application which can be any alphanumeric text. USER ID and the USER NAME can be the same but the SIGN ON NAME has to be different from the USER ID. access given only to FUNDS TRANSFER and CUSTOMER application and also restrict the access only to Input and List functions 3. type USER and the ID of the record you want to create in the command line. To create a user record. 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. The error message “EB.SAME. Rights and privileges for a user are defined in his user profile . For example. The user must have access to the Input function. Has to be different from the name given in the field User Name.

The purpose of this table is to identify each Department and Account Officer in the bank by means of a code. It is encrypted at database level and is not displayed as part of the record in the USER application. COMPANY CODE : Specify the companies to which the user has access to. SPANISH. The first company code specified here will be the default company to which the user will log on to. Department Codes must be predefined in the static table DEPT. LANGUAGE : You have to set up the language field in the USER application for all the messages. i.e. instructions. T24 allows the user to access multiple companies as it supports MULTI COMPANY set up. It is always advisable in any software to change the password at specified frequency to ensure that there is no fraud happening on using the same password for a long . GERMAN. The language codes are pre defined in the LANGUAGE table.OFFICER in T24. CLASSIFICATION : Int (Internal) Indicates whether the User is 'Internal'. The model bank setup of T24 supports four languages namely : ENGLISH.ACCT. DEPARTMENT CODE : Specifies the department to which the user belongs to. All users must belong to some department or the other in the Bank. The companies defined in a T24 installation can be found in the COMPANY application. If the translation is not available for other languages. 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. Ext (External) is currently not working. The keyword ALL can be used to access all companies. then ENGLISH will be defaulted. an employee of the bank using T24. to be displayed when possible in the language indicated. Department Code will allow an easy identification of any user of the T24 System. then when the user logs into T24 EU0010001 is the default company into which he will log into. help text etc. FRENCH.PASSWORD : The password is also stored as part of the user profile.

etc. This field takes machine date and not T24 date. 00:00-23:59. Date entered in this field should not be less than today’s machine date. T24 allows the user to specify the password valid date and the frequency of change. START TIME : Based on the 24 hour clock. Input can be like 0-2359. in most cases the working hours of the bank will determine when a user must be allowed to use the system. M0601 : M06 – Every six months after 1st Dec 2008 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. END DATE PROFILE : Date until which the user profile is active. Next Change Date entered. This period is controlled by the following fields. There are fields in the USER application that controls the validity of the user profile. 0000-2359. (one denotes 0001). PASSWORD VALIDITY : Specifies how often and on what date the User must change his Password. The fields Start Time and End Time control the time span in a day when the user can log in to T24. Date until which the password is valid followed by the frequency of change. User will be able to login into T24 from this date onwards.. would the bank want to give him a 24hr access to the system? No. The user will not be able to login into T24 after this date. must be greater than today's date (machine date) and not more than 6 months from today. If a user has access to T24.time. . START DATE PROFILE : Date from which the profile of the user will be active.

In this process. he is signed off automatically and another user can complete your record. how long would you wait for the same user to return back and complete your record? This is practically not possible. These set of permissions can be set up in the Associated multi value set from COMPANY RESTR to DATA TO. These two fields form a multi-value set. have a check on the number of times that a user can incorrectly type in a password. Once this time is reached the user is not allowed to perform any action. Maximum of three numeric characters which is 999 minutes. The account is then locked and the user is forced to reset his password. In such a scenario.END TIME : Based on the 24 hour clock. Irrespective of the time specified here. If the time limit lapses for the first user. The user has to login again to perform any action in T24. However. Therefore T24 supports the concept of Time Out Minutes. function and field level restrictions for a company. No other user is allowed to open your record and edit it as it will be locked by the first user. . It is possible to specify application. 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. ATTEMPTS : Allows only one numeric character to input and hence the maximum can only be nine. Most websites that require a user name and password. This helps safe guard the profile against hackers. If you want to open a savings account with a Bank. if the user who is opening the record for you is called for some other important work. the user of the bank has to first open a new record for you in the CUSTOMER application. The Administrator can specify the number of minutes the user can be active without actually working on the system. he will be allowed to continue accessing T24. he might have to leave your record without completing and may walk away. once logged off user will not be allowed to login after the time specified in this field. enabling multiple periods of time to be defined per day. if the user is logged in to the system. A user in T24 may not be allowed to perform same set of actions in different companies. The company to which you want to restrict the access should have been mentioned in the COMPANY CODE field. TIME OUT MINUTES : Specifies the maximum time in minutes during which the User may be inactive without being Signed Off automatically.

‘A’ is a function which allows the user to authorise an unauthorised record. ‘H’ function is used to move a record from history to live file. A live record cannot be deleted. FUNCTION : List of valid functions that the user can use in the company.CODE field. ‘2’ is not a function.PG. ‘E’ function allows the user to list the unauthoirsed records. 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. APPLICATION : Can contain a valid application name or if it contains ALL. The Q function does not appear by default. This is used along with the function ‘A’ to allow the user to authorise a record which needs a second authoriser. ‘C’ is a function which allows the user to copy a record. ‘I’ function allows the user to input a record in an application. (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. Q stands for Audit Review. Permits to input "ALL" to allow the access for all companies listed in the COMPANY.COMPANY RESTR : Contains a valid company code. the user will have access to all applications in T24 in to the company entered in the field COMPANY RESTR. . Type ALL to give access to all the functions. This company should be defined as part of the COMPANY CODE field.

SIGN ON OFF LOG : If set to YES. . will log sign on and sign off details of the user in the PROTOCOL file. If you want to record all the actions performed by the user. ‘P’ is used for printing. All the actions performed by the user may or may not be logged. 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 (Used to change companies) PASSWORD. PROTOCOL is the file in T24 which stores the logging information of a user. ‘S’ allows user to only view the records.RESET USER APPLICATION LOG : If set to Yes will log details of applications that the user uses on to the PROTOCOL file.‘L’ function is used to list live records. the following fields have to be set to YES. This file is updated by T24 and therefore records cannot be edited but only viewed. It is used to produce some extra information and also performs some extra actions. ‘R’ is used to reverse a record which is no longer used. ‘V’ is a special function which is supported only by some applications in T24.

T24 will store the data in YYYYMMDD format. 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?. These specific restrictions can be achieved by using the fields from COMPANY. CLEAR.TO which form a multi value set. This field is more oriented towards CUI Interface where once a deal is committed the screen is cleared if set to ‘Y’.FUNCTION ID LOG : If set to Yes will log the functions and the IDs used by the user on to the PROTOCOL file. DATA COMPARISON : Must select the valid operand you would want to use for comparison. FIELD NO : Must enter the actual field number of the required field from the record in an application. The field FUNCTION will hold the function which the user can access in the particular application. The field VERSION can contain a valid version name of the application specified in the field APPLICATION. even after the transaction is complete the record is still displayed on the screen. Authorize the record and try logging in to T24 with the new user you have created. INPUT DAY MONTH : Format for the user to input dates. Yes. If you set the field CLEAR SCREEN to ‘NO’.RESTR to DATA. This field can be left without any input also. 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. Different operands available are . If you set the field CLEAR SCREEN to ‘YES’. No matter how the date is input by the user.SCREEN : This is a mandatory field. The APPLICATION field will hold the name of the application which can be accessed by the user.RESTR can have the company code in which the user will be allowed access only to few applications. The field COMPANY.

This may also contain the starting range. with reference to the screen shots: 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. . This operand can also be used to specify a range of values.EQ which resembles Equal To. DATA TO : This field holds the end range of the selection. For example. GE resembles Greater than or Equal To GT resembles Greater than LE resembles Lesser than or Equal To LT resembles Lesser than NE resembles Not Equal To LK resembles Like UL resembles Unlike DATA FROM : Must enter a valid value for the field specified in Field No.

It is displayed on the SIGN.ON screen. ATTEMPTS SINCE: Indicates the number of unsuccessful attempts to SIGN.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 CLEAR.SIGN. This field is more oriented towards CUI Interface where once a deal is committed the screen is cleared if set to ‘Y’.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. DEACTIVATION. 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.ON. The operand to use to select the range is EQ. . This date is the actual date (system date and not T24 date) on which the User Signed On.ON Screen. It is displayed on the SIGN. REACTIVATION.DATE : The date that defines the end of the deactivation period. TIME. DATE.ON Screen. It is displayed on the SIGN.ON : Indicates the date this User last Signed On successfully.SCREEN : This is a mandatory field. PASSW CHANGE DATE: Indicates the date on which the password was changed last time.SIGN. PASSW END DATE: Indicates the end date of the password. This can only be entered or changed by the User via the PASSWORD Application.ON since the last successful SIGN.LAST.LAST.ON : Indicates the time of day at which this User last Signed On successfully.

etc.TRANSFER.DESK : Identifies the dealer desk position which needs to be updated by the deal being created.CONTROL file.RECEIVE until Last Spool Time: This is a associated multi value set. DEALER. RPT.. Identifies the dealer desk code applicable to the user. RPT. Both the LAST SPOOL DATE and LAST SPOOL TIME are no input fields.The code specified here will be defaulted when a transaction is input in some applications like FUNDS. . Printer is set up using the application PRINTER.ADDR : Address that will be printed on the report banner page. by this user. PRINTER For Rpts : Name of a T24 printer to which reports will be spooled and printed.OFFICER file is used. LAST.COPIES : The number of copies this user should receive. If left blank then the delivery point from the DEPT. Must be a valid entry on the REPORT.ID in T24. The currency position specified for this dealer will be used for the transaction input by this user.SPOOL.ACCT. A maximum of three lines can be used. GB USER.TIME : The time the report was last spooled. LAST.SPOOL. Printer names specified in other report generation specific applications take priority over this.TO. RPT TO RECEIVE : The name of the reports this user is to receive from the over- night batch run. If left blank T24 will default code ‘00’. The code to be specified here should have an entry in DEALER DESK table. Each multi- value represents one line on the banner.DATE : The date when the report was last spooled. 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. FOREX.

DESIGNERS : Prevents user access to the listed Designer Tools dropdown list. This will prevent the user from gaining access to various Desktop settings including file locations and some system administrative functions. DEVSTUDIO : This is reserved for future use.MANAGER : Only if the client has BRANCH RESILIENCE product. The branch administrator will use the T24 Toolbox to monitor and maintain the branch backup database. LOCK.MANAGER selected in the Attributes field in the USER application. COMMAND.The field ATTRIBUTES on the USER profile can be used to control specific T24 functionality. back to the head office system and ensures that updates to and from the branch and head office are processed. this attribute can be set for the user. BRANCH. LOCK.INDEX and EXPLORER : These options does not have enough information. ENQUIRY.LINE : The user is allowed the use of the command line in T24 Browser. .DEACTIVATION : Prevents user access to the User Deactivation listed in Tools dropdown list.ITEMS : Will bring up a Security Violation when the User Abbreviations Toolbar. Once repairs to the communication infrastructure at head office are complete and reliable. Enquiry and Report lists are used. To use the T24 Toolbox the user must have the value BRANCH. Branch Resilience is a backup system for branches to be used when communications to the head office system are interrupted. 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. the local administrator will begin the process of switching users. What you set in this field will decide what the user can or cannot do. LOCK. Some of the attributes can only be used if the front end is DESKTOP. The various options available are explained in detail below.MISC.

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. SIGN. Browser will create another session for use by the real time enquiries.BOOK. These settings can be done using the following Associated multi value set. During the SIGN OFF process.BLOCK fields are used only if T24 Multi Book product is installed.BOOK. If you want T24 to perform some extra action during sign off process.ACCESS and OTH. SUPER.ENQUIRY. but not an additional T24 license. you have to define the following field.OFF. This does use an additional database license. OTH. ALLOWED DAYS : This field is used to specify the access to T24 in particular days. This field indicates the start time of the user’s access to T24 in a particular day. and for all future functionality with the exception of REALTIMEENQUIRY.NO. any subroutines defined in this field will be called with one parameter. DAY ST TIME : Time is based on 24 hour clock. 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. When signing onto T24. . If this parameter returns with the values N.ITEM : The name of any BASIC subroutine can be entered into this field.USER : The user has access to all of the features detailed above. or NO the SIGN OFF processes will be halted SIGN ON ITEM and PROCESS DEPT fields are obsolete. the icon will be dimmed and non reactive.REPORT : Prevents user exporting Enquiry data from an Enquiry screen. Not enough information is available for this option as well. REALTIMEENQUIRY : Allows the use of real time enquiries for this user.

DAY END TIME : This field indicates the end time of the user’s access to T24 in a particular day. T24 stores the date in a single format across. However you can set the display format of the date at the user level. If you want to sign on to T24 as soon as you signed on to your system. then the values set in the field Start Time and End Time will be used. Ldap Id and Ldap Dn : These fields are used to configure the Temenos Connector to use LDAP as part of the authentication mechanism. 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. Lead Pref : Is an obsolete field in T24. 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. Irrespective of the date format given in the USER application. Options available are 1 . Ldap Dn becomes mandatory field once Ldap Id is entered.DDMONTHYEAR 2 . Date Format : Describes the format for displaying the date.YYYY/MM/DD 4 . how can you do it? This is possible in T24 in the following fields.DD/MM/YYYY 3 .YYYYMMDD .

CURR NO. If the record is in live file. The two fields below are populated only when a record is audited (Q function). T24 passwords must follow the rules discussed below.OFFLINE. They are no input fields attached to the end of every record across applications.. etc. T24 updates the following audit fields. CO CODE : Defaults based on current company logged into.SMS. AUTHORISER : Holds the ID of the user who has authorized the record. When a record is commited or authorised. INAO. DEPT CODE : Defaults to the user’s department code. Possible values are INAU. : Holds the number of times the record was edited. INPUTTER : Holds the ID of the user who has inputted the record. then there is no entry in this field. AUDIT DATE TIME : Holds the audit date and time. RECORD STATUS: Holds the status of the record. AUDITOR CODE : Holds the code of the auditor who has reviewed the record. . DATE TIME : Holds the date and time when the record was last edited.. IHLD.PROFILE field is used only if the BRANCH RESILIENCE product is installed. 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).

1. Password should not have more than two repeated characters

2. Last three passwords cannot be used

3. At first sign on, Temenos T24 will ask for Password to be input twice

4. Password should have a minimum of six and a maximum of sixteen characters

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.

1. The default number of passwords is three

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.

The fields PASSWD.ROLLOVER.FR and ENCRYPTION.ALGORIT are used to enable this
functionality.

ENCRYPTION.ALGORIT : This field is used to attach the JAVA routine written to
encrypt the password. This routine should be pre-defined in EB.API. If this is done,
then the system will skip the normal T24 password encryption mechanism and
follow the user-defined encryption method written in the routine. If this field is left
blank, the normal T24 password encryption will happen.

PASSWD.ROLLOVER.FR : This field is a frequency field containing the password
rollover frequency. This is used when ENCRYPTION.ALGORITHM specified to re-
encrypt the password with new security settings for the specified frequency.

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.

The ID of a record in PASSWORD.RESET can be any alphanumeric text.

USER PW ATTEMPT: This field specifies the ID of the user whose record has been
locked. When this record is authorised T24 resets the password and enables the
profile at the same time. You must set a new password the next time you log in.

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.

The password has been reset for locked user account.

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.

User should have access to any one company only – GB0010001 3. you will learn to create a user record in T24. See and Exception listing for the ACCOUNT application 5. Create a user named XXXXX (Where XXXXX is your name) 2. . User should be able to use the system only between 10:00 and 06:00 on all days In this demo.The new password holds good for this user ID. 1. See. The user record has been created. User should be able to use the command line 6. User should be allowed to use only functions. List and Print for the CUSTOMER application. User should be allowed to access only the ACCOUNT and CUSTOMER applications 4.

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 in T24 stores all the details of actions performed by user. This file is updated by T24 and therefore records cannot be edited but only viewed  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.

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. The format being: . which takes you to the selection box The contents of a PROTOCOL record include- @ID : This is the code by which a record is identified.

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.YYYYMMDD is the date on which the recorded event (security violation or other activity) occurred. Process Date : Date on which the activity took place. TIME : Identifies the time at which the recorded event took place. The first part of the terminal id denotes the database user number and the second part denotes operating system port number. Displayed in the format which was selected in the DATE FORMAT field in USER application. USER : Holds the USER. Level 2 indicates . PHANTOM ID : Denotes the terminal at which the activity took place.FUNCTION : Identifies whether the Application had been accessed directly or via '!'.ID of the user who has performed the action. LEVEL. APPLICATION : Identifies the Application which was being used by the user. XX is the sequence number to identify the number of activities per one second. COMPANY ID : Denotes the company in which the activity took place. TIME. The first event recorded each day is 0000000001 and so on. Level 1 indicates that the Application was accessed directly. NNNNNNNNNN is the sequence number allocated to the event when it was recorded.

Delete and Authorize 2. . 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.GROUP in T24 Open a record in the application USER. Based on the requirements. 1. Restrict usage to the following functions only : Input. ID : Holds the record ID of the application used. this file has to be cleared periodically by attaching a routine to COB.that the Application was accessed from another Application via '!' mark.SMS. Application that they can have access to is CUSTOMER provided the field Sector is 1000. REMARK : This field denotes the activity performed and why the system did not allow the attempted activity. weekly. Based on the requirements. PROTOCOL file gets accumulated with all the activities performed by the user and hence this file can grow very huge in size 2.GROUP. monthly or on an adhoc basis 1.SMS. This can be done using an application USER. What do you do if you have to set the same set of privileges to a group of users? 2. See. this job could be executed daily. ID can be any alphanumeric text. ! Works only on the classic user interface of T24 and is used to drilldown from one application’s field to another. Will you set the privileges in every single user’s user profile? 3.

GROUP has to be attached in the profile of the user in the field Application as “@ID”. FIELD NO: Specified when used together with fields Data Comparison. If you only enter the amount without any separators in the field Debit Amount and validate the record. a CUSTOMER record can be accessed only if the field no. you cannot input in the fields Version. which happens to be field SECTOR is equal to 1000.. For example. the separators are defaulted as set in the Amount Format field in user profile. APPLICATION: Multi Value Field which is used to input all the applications which this user group can have access to. . Field No. you cannot specify individual privileges to the user. Data From and Data To. The first value is the separator used for millions and thousands. Data From and Data To in the USER application. The second value is the one used as a decimal separator. full stop or apostrophe. Specifies the separators to be used when formatting amounts for Enquiries.. For example . For example.SMS.23 in the CUSTOMER record.GB DESCRIPTION: Mandatory field used to input the narrative of the record ID. REPGEN’s and screen input/display 3. 1. The millions & thousands separator can be a comma. FUNCTION: This field is used to input all the allowed functions for the group of users. The decimal separator can only be either a comma or full stop Input is restricted to two character pair. Function. or ‘. Amount Format field specifies the separators to be used when formatting amounts 2. When you attach the SMS group for a particular user. or ‘. The record ID created in USER. Data Comparison.

Assume that by T24 norms. the minimum balance in the savings account should be $100. When you input a record in any Application in T24 and commit it. you will be able to:  Describe and differentiate types of overrides in T24  Explain the applications used for Override Processing  Setup up multi level restrictions on Override access 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. but it can warn you. it is possible that you come across two types of messages. You will have only two options. For example. to accept it and complete the transaction or reject it and stop. T24 generates an override to do this. Now if you input the transaction to debit $100.After completing this learning unit. T24 cannot stop you. Error Messages: Such type of messages are displayed -  Due to data not being input in mandatory fields  Due to incorrect data input . when committing it T24 must warn you about the insufficient funds available. A customer wants to withdraw $100 from his savings account which has a balance of $150.

Override Messages: These are warning messages. you may either put the record on hold to correct it later or amend the record and commit it again. In this demo. It is a no input field and updated by T24 4. Due to incorrect relationship between field name and the data that is input In case of Error Messages. 1. If you do not want to accept the Override. This field is part of almost all the applications in T24 3. T24 saves the record and the override message is stored as part of it in the field OVERRIDE. There can be two different types of override messages. If accepted. you will learn how overrides are handled in Classic mode of T24. They are Non Blocked and Blocked overrides 2. You cannot even put the record on hold. ‘Override’ is the name of the field which stores the override messages generated on committing the record 2. A record which generates non blocked overrides can be authorised by any user in T24 . A user may accept or reject override. You have learnt how to handle overrides in CUI. at least most of the time. Old overrides are overwritten with new ones 1. 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.

Now what if we decide to change an override message in T24? . the override message will also contain a special character ‘&’ and each ‘&’ is then replaced with a value when T24 actually generates the override. all overrides in T24 are Non Blocked in nature Where are Override messages stored? In the OVERRIDE Application.. etc.).. the first & is used to denote Currency. you can set this Override message to act differently such as a warning message. etc.3. In the override ACCT. However. an error message. So are override messages only static text messages? What if they need to hold values from the transaction? In that case. to give you little information about Channel field. A record which generates blocked overrides can be authorised only by users with appropriate privileges. ID : ID of the record can be any meaningful alphanumeric string GB Message : This field contains the actual override message that is displayed on committing the record. By default. based on the type of Channel you select to access T24 (like call center. If you do not have sufficient privileges the record will go to INAO (Input Not Approved due to Override) status 4.UNAUTH. internet.OD. the second & to denote Amount and the third & to denote Account number. T24 applications generate override messages stored here.. Type. a confirmation message. branch. Channel and Approve Method : These fields are used only in ARC IB and are not in the scope of this learning unit.

The account created earlier is debited in this FUNDS TRANSFER transaction. the next thing to learn is how to block an override 2. This number is prefixed with ‘O’ which resembles Override. You will notice that all the Overrides generated are stored in the record and are never deleted. This account now has a zero balance.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. The record is now committed. The override message is displayed and you can accept it. After the record gets committed. Subroutine and Validation fields is used only in Desktop and does not have any relevance in Browser. no special permission is required to accept it. You will now see an illustration to prove that all overrides in T24 by default are non- blocked. T24 generates a unique number for every record in the OVERRIDE application on committing the record. App Version. You will see how the override ACCT. 1. Numeric Id : This is a no input field. To block an override in other words is to restrict access to particular users when it comes to authorising a record with this override . Any user can accept blocked overrides when generated and commit the record thus moving it into INAU status 3. Only overrides that have changed over the years will have a value in this field. In other words. Now that you realise what a non-blocked override is.UNAUTH.Prev Message : This field in the OVERRIDE application holds the message which was previously displayed for that particular Override. open it in ‘SEE’ mode and check the field OVERRIDE.

The relationship of this data entered here and the override is clearly visible from the screen shots. This field accepts any string data.OD override.4. The user TRAINEE1 can now authorise the record which generated the ACCT.UNAUTH. If the record which has generated blocked overrides is accepted by the user with appropriate permissions. then the record becomes live or else it will move to INAO status To grant the privilege to authorise records that have generated blocked overrides. The override record has been modified to include the user class details thus making it a blocked override.CLASS field in the USER application. . you must use the OVERRIDE.

only users with Class TRG in their User profile can accept the override. Class name can be any descriptive text. Users belonging to this group alone will be able to approve this override. then only users with Class TEM in their User profiles can accept it.TRANSFER application. You can also specify Class Application wise. Maximum of four characters only. accept the overrides and commit the record. irrespective of the application from which this override is generated. Application : Specify a * to denote. Open it in SEE mode and see the filed Override. TRG which implies that only a user belonging to the class TRG can authorize the record. For example. Now login as the user Chaitanya and input an FT transaction. The group name specified in this field should be attached in the User profiles in the field ‘Override Class’. Class : This field specifies a group name. .You will now learn more uses of the fields APPLICATION and CLASS in the OVERRIDE application.3 being suffixed with *. if the Override is generated in the FUNDS. Note that the user Chaitanya is not attached to the class TRG.

You will see the message ‘YOU CANNOT APPROVE ALL OVERRIDES’. This is because. 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. the user who tried to authorize the record is not one among the class specified in OVERRIDE application. Now login as CHAITANYA1 and authorize the record. .Note that the user CHAITANYA1 is not attached to the class TRG.

.3 being suffixed with ‘*TRG*TRAINEE1_OFS_BROWSERTC’ TRG is the Class name. OFS_BROWSERTC denotes that the record has been authorized from Browser frontend. Open the record in SEE mode and check for the field Override.Note that the user TRAINEE1 is attached to the class TRG. TRAINEE1 resembles the name of the user who has approved the override. Now login as TRAINEE1 and authorize the same FT record.

. and input a FUNDS. since TRAINEE1 has only input the record. any other user who does not belong to the class also can authorize the record.Note that the field Authorizer still holds the user CHAITANYA1 and does not change to TRAINEE1. In such a case. since TRAINEE1 has only input the record. In such a case. 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. Now what if you login as TRAINEE1 who belongs to the class TRG.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.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.

Account Officer classification 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 . 1. When an unauthorized overdraft override message is generated in T24. 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. only the following users should be able to approve the override based on the following conditions 2.1. There might be many such cases in a Bank that a simple Class restrictions may not be sufficient 2.

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. You can set different groups who can approve overrides only if the conditions specified in their groups are satisfied. : This field indicates which data item. 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. Data Def No. In this example.CLASS. Classification to Data To field is a multi value set. &2 refers to Amount and &3 refers to Account. ACCT. as defined in the field DATA DEF is to be used for the classification.DETAILS. Data Def No to Data To field is a sub value set. .OD is the Override in which &1 refers to Currency. Classification : This field holds any user defined text that best defines the group classification.UNAUTH. Data Def : This field refers to the & values in the override message. conditions are specific to only Currency and Amount and hence only &1 and &2 are defined.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.

If the outcome of the comparison is true.The number in this field identifies which multi-value from the field DATA DEF is to be referred.DETAILS then only the users who belong to the class TRG can approve the override. Comparison : It refers the operand to be used. NE resembles Not Equal To.TRANSFER. You can also define one DATA DEF and use it for all the classifications. LK resembles Like. NR resembles Out of range. For example. UL resembles Unlike.CLASS. GE resembles Greater than or Equal To.2 .1 and the number '2' indicates that it is the content of field DATA DEF.DETAILS application will be checked and appropriately validated. Must select the valid operand you would want to use for comparison. the number '1' indicates that it is the data item defined by field DATA DEF. Data From : This field holds the value indicated in the field DATA DEF (according to the field DATA DEF NO). GT resembles Greater than. RG resembles the range. . LT resembles Lesser than. When the override message is raised from the application FUNDS. is compared against the value in this field according to the operator in the field COMPARISON.CLASS. If the override message is raised for an amount which is beyond the amount specified in OVERRIDE. the conditions specified in the record TRAINING in the OVERRIDE. LE resembles Lesser thank or Equal To. Different operands available are EQ which resembles Equal To . This field can be left without any input also. DATA. the corresponding CLASSIFICATION group will be allocated the override.TO : This field holds the end value of a range.

Login as any user and input an FT debiting an account with nil balance with USD 10400 2.CLASS. Login as ACCTOFF1/ACCTOFF2 and authorize the FT. Specify the value given in the field CLASSIFICATION (second multi value set) in OVERRIDE. you will learn how to set simple multi level restrictions to approve overrides in T24. Specify the value given in the field CLASSIFICATION (first multi value set) in OVERRIDE. In this demo. Login to T24 as any user and input a FT debiting an account with nil balance with USD 9000.DETAILS and in the field OVERRIDE CLASS in the User profiles of GENMGR1. Login as ACCTOFF1/ACCTOFF2 and authorize the FT 3.TRANSFER (Denoted using a *).CLASS.DETAILS and in the field OVERRIDE CLASS in the User profiles of ACCTOFF1 and ACCTOFF2. End of demonstration Multi Level Restriction I. users with the field Override Class set to TRG in their user profiles will be able to approve the override. 1. Note that the record status is INAO as ACCTOFF1 does not have the privileges to authorize transactions with overdraft amount beyond USD 9000 .CLASS.When the override message is generated for applications other than FUNDS.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.

1. Note that the Override message is suffixed with *TRG 3. the record will go to INAO status 3. If ACCTOFF1/ACCTOFF2/MANAGER1/MANAGER2 login and try to authorize the record. 1.4. Since the overdraft amount does not fall into any of the ranges defined in the OVERRIDE.CLASS. End of demonstration Multi Level Restriction III. The authorizer field will still show value of ACCTOFF1 only as initially the record was authorized by the user ACCTOFF1 In this demo. Only user GENMGR1 will be able to approve the override and authorize the record In this demo. Login as any user and input an FT debiting an account with nil balance with USD 2000000 2. Login as any user and input a FT debiting an account with nil balance with USD 51000 2. the default class TRG defined for FT has been used . 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. Login as MANAGER1 and authorize the record 5. you will learn how to set multi level restrictions to approve overrides and try to authorize the record with different users in T24.DETAILS application. End of demonstration Multi Level Restriction II.

CLASS.4. approval is possible. Default class to be used is TRG 4.DETAILS. To get this done.CLASS. 1. If yes. A user with MGR override class set will not be able to approve the above mentioned override. When an override is to be approved T24 checks to see if the override class mentioned in the user profile matches the override class suffixed with the override message. else. T24 always checks for conditions in the order specified in the OVERRIDE. you need to add ‘ACOF’ apart from the ‘MGR’ class in the user profile of MANAGER1 and MANAGER2. Therefore.OD override to allow only the following users to approve the override. the override message will always appear as <Override Message>* ACOF.DETAILS record. 2.UNAUTH. Create the necessary users 3. Logically a user with MGR override class set should be able to approve an override of 9000 USD. Amend the ACCT. If an FT is input and the overdraft amount is 9000. For example. End of demonstration Multi Level Restriction IV. record will got to INAO status. this override can be approved only by users who have class set to TRG in their User profile In this demo. Two trainees to form a group . you will learn how to any T24 user can approve overrides which do not fall under the amount which are set in OVERRIDE.

TRG’ and input appropriate details. GRP2 needs to edit the record ‘TEMENOS. The message is specified in the field ERROR. Once done. The first group to create the record and add in details appropriate to GRP1. . All groups will then have to create new accounts and input FTs debiting the account and check override processing. Message and Warning. You will not be allowed to commit the record when an error is raised in T24. The above created record should be attached to the OVERRIDE application in the field MESSAGE. you could see the customised error message displayed.DETAILS application.MSG.CLASS. the override was displayed as an error message.TRG. The field TYPE in OVERRIDE application has the following options – Error. Can an override message be triggered as an error in T24? The answer is yes. The ID should be TEMENOS. When the override is triggered in a transaction. GRP10 to link the OVERRIDE. create a record in EB. the override message will be automatically accepted by T24 . When TYPE is set to Auto.The first group needs to create a record in OVERRIDE. Then. In the previous example.ERROR application. When TYPE is set to Error. Now can you display customised error messages for overrides? To display customised error messages for overrides.CLASS. the user acceptance is not required. Auto. record passes on to GRP3 and so on.DETAILS record to OVERRIDE application. You are now familiar with the concept of override processing in T24. the override message becomes an error.

No. OVERRIDE is one of the core applications in T24.UNAUTH. . All the override messages to be generated should be defined in the OVERRIDE application in T24 For example. However Client customization is possible but is not as simple as creating any record in OVERRIDE application. Only TEMENOS DEVELOPMENT can do it.1.OD needs to be raised. Can you simply create a new Override without any hassels? 2. T24 core then picks up the actual message from the field GB Message in OVERRIDE application and displays it. It is not possible to simply create a new record in OVERRIDE application and let it to populate for any records in any applications. When T24 wishes to raise an override stating that a particular account has been over drawn. it will only say that an override ACCT.

DISPO.ITEMS. If you do not have sufficient privileges the record will go to INAO (Input Not Approved due to Override) status. They are Non Blocking and Blocking overrides.SUMMARY  Differentiate partial and full DISPO processing Sometimes when committing a transaction in T24. DISPO.2 A record which generates blocking overrides can be authorized only by users with appropriate privileges.DETAILS and DISPO.DISPO PROCESSING: After completing this learning unit. 2.OVERRIDE.OFFICER  Create DISPO Officers in T24  Explain the process DISPO Processing has on overrides  Explain the use of enquiries DISPO. . 2. These messages are called Overrides.1 A record which generates non blocking overrides can be authorized by any user in T24. 2. you will be able to:  Differentiate between blocking and non blocking overrides  Explain the use of the following applications .There can be two different types of override messages. one or more warning messages are generated.

. The T24 way to do this is by using the application FUNDS. is raised by many applications like FUNDS. T24 will allow him to perform the transaction by overdrawing his account. all overrides in T24 are Non Blocking in nature.DETAILS However. The system will raise an override on committing the transaction. Tom wants to transfer funds from his account to Tim’s account. What if the bank wants to set a limit on the amount of overdraft that a particular user can authorize? Even though this can be achieved using OVERRIDE.CLASS. The Override ACCT.UNAUTH. LD. How can you make a non-blocking override a blocking override? You are absolutely right if you think that this can be achieved through OVERRIDE.OD.AND. you can also achieve this using DISPO Processing.DETAILS.TRANSFER.DEPOSITS etc. Teaching you how to block and un-block overrides are not in the scope of this learning unit. What is DISPO Processing? An example will make this clear.CLASS.By default.TRANSFER. Dispo Processing allows you to do this with extra options. the applications that involve an account in the transactions.LOANS. The same override can be generated by any application depending upon business requirement. telling the T24 user that Tom’s account does not have enough funds and is being overdrawn. 1. What if Tom’s account does not have enough funds? Will the transaction abort? No..

The input in this field should be a valid officer defined in DISPO.OFFICER application ID : The ID of a record can be any alphanumeric input SHORT.OFFICER is used to assign the Officer.ITEMS application. This is a multi value field and will hold all the override IDs that this officer will deal with DISPO. for which DISPO processing has been enabled. The field DISPO. you need to assign a DISPO Officer to a particular user in the USER application. will it be feasible if any T24 user can view the records in DISPO. you have to specify a valid DISPO Officer ID in the field DISPO. DISPO Officer is the one of the important fields in the DISPO.TITLE : This is a multi lingual field which holds the description for the DISPO officer in different languages OVERRIDE.OFFICER application. in the Override record.2. In the override record. To control such a situation.ID : This field holds the ID of an override record.ITEMS and approve or reject or comment it? If this is done than the whole idea of DISPO Processing is in vain. To enable DISPO Processing for a particular application set the field APPLICATION to either the name of the application or ‘*’ (star enables DISPO for all applications generating the override) and the field DISPO to ‘YES’. DISPO Officer has the right to approve or reject or comment on DISPO Items A DISPO officer can be created using the DISPO.AMOUNT : This field holds the amount up to which the Officer can comment on an override .OFFICER Now that you have done the base work.

TO.FROM.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. Only if this field contains a valid DISPO Officer ID. TIME.FROM. TIME.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. Whenever an override. ROUTE. DATE. to whom the DISPO Item would be assigned. a record is created in an application called DISPO.DISPO.FROM. TIME.OVERDRAFT. is accepted in a transaction.TO will be input able. DATE. that has been subject to DISPO Processing.TO. DATE. Otherwise all these fields are no input fields.TO fields. the other fields like DATE.OFF : This field holds the ID of the next level Officer for financial Overrides. TIME.AMOUNT NEXT. 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. 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.FROM.AMT should be less than or equal to DISPO. you can set an alternate DISPO Officer who will be acting like the actual Officer for the specified time.ITEMS .AMT : This field holds the amount up to which the Officer can approve or reject an override OVERDRAFT.

ITEMS is created internally by the system only when the transaction generating the override enabled for dispo is committed.ITEMS application and check for the fields DISPO. set the field DISPO. CUSTOMER.NO : This field holds the debit account number. This means that the DISPO item should actually be approved or rejected or commented upon by DISPO officer 101. ACCOUNT.OFFICER : This field holds the ID of the account officer responsible for the account. ACCT.TO field in . The record ID is TransactionID*CompanyMnemonic. You will note that both these fields are defaulted to officer 102 and not 101 though the amount falls under the officer 101 range. A record in DISPO. AMOUNT : This field holds the total amount overdrawn on the debited account. In the DISPO.ITEMS should have been created with ID as TransactionID * Company mnemonic. CURRENCY : This field holds the currency of the account which has been debited in the transaction.OFFICER to 101. Example : FT08009436R9*BNK APPLICATION : This field holds the application name by which the override has been generated.UNAUTH. This is because. At this stage a record in DISPO. however since he is not available the item will be assigned to DISPO Officer 102. OVERRIDE. accept the overrides and commit the record. the ROUTE.OFFICER record with ID 101 set the ROUTE. A record in DISPO. ACCOUNT.NO : This field holds the ID of the customer who holds the account.OFFICER and COMMENT.OFFICER.ID : This field holds the ID of the override record that is generated.TEXT : This field holds the actual override message as generated in the transaction. In the OVERRIDE record. Now open the record in the DISPO.User inputs an FT transaction. Input an FT transaction. DATE and TIME : These fields hold the date and the time in which the override was raised in the transaction .ITEMS is created.OD. When the user accepts the override message generated.TO field 102. the transaction is complete and the record goes to INAU status. OVERRIDE.

DISPO. Only a user who is assigned a DISPO officer can open the record in see mode. Open the item and note that the fields DISPO. However. reject. 2.OFFICER and COMMENT. a user who is not assigned any DISPO officer can still list the DISPO items. The system will not allow you to do so.OFFICER application. the transaction is complete and the record goes to INAU status. At this stage a record in DISPO. 4. When the user accepts the override message generated. The record will now be in INAO status and is ready for authorizing or rejecting or commenting. Can you simply open a record in DISPO. you can use an enquiry DISPO. You have been hearing the words approve.OFFICER are defaulted to officer 100 as the transaction amount falls in his approval limits. 3. Try authorizing a DISPO item.ITEMS is created. the record should be in INAO status.the officer 101 record is set to officer 102 for 9th Jan from 10AM to 06PM. Enquiry DISPO.ITEMS and authorize it? The system will not allow you to do so.ITEMS is the application used to view the DISPO items. However. To authorize a DISPO item. that has been subject to DISPO Processing.SUMMARY or DISPO. comment a DISPO item all through the course.DETAILS. is accepted in a transaction. a record is created in an application called DISPO. Try to authorize the record with a user who is not assigned an appropriate DISPO officer and then check the record status. This is because. . Whenever an override.SUMMARY can be used to view all the pending DISPO items for approval. and the FT transaction was input and committed within this time frame. Also remember. the record status is INAU.ITEMS User inputs an FT transaction.DETAILS to view the items specific to an officer. user with an appropriate DISPO officer can only approve or reject or comment an item with in his limits defined in the DISPO. You can perform this action only by using the enquiry DISPO.

he can add the required comments.AMOUNT and the amount up to which an Officer can approve or reject an override is in the field OVERDRAFT. The amount up to which an Officer can comment on an override is given in the field DISPO.AMOUNT in DISPO.SUMMARY will display all the records enabled for DISPO processing for all the DISPO officers.Login as another user who do not have the DISPO officer set and try authorizing the FT record. approve or reject the DISPO item.ITEMS record. If the user has sufficient privileges. All the comments made are recorded in the DISPO. Login as the user who has appropriate DISPO authorities and approve the DISPO item. Now you should be able to authorize the corresponding FT record. If the DISPO officer reject the DISPO item.SUMMARY will display all the records enabled for DISPO processing for all the DISPO officers. Open the enquiry DISPO. All the DISPO items available for the officer 100 are displayed. approve it and commit the record. Enquiry DISPO.OFFICER With reference to the table in the slide: Table Column 1 holds the record IDs of DISPO Officers.OFFICER and the officer who can approve or reject the override is the DISPO. 1.OFFICER application.DETAILS for the officer – 100. The record is in live status Enquiry DISPO. then you will not be able to authorize the FT transaction. The transaction is complete and the FT is authorized by the appropriate DISPO officer. If the user has sufficient privileges.ITEMS record. After the record is open. approve or reject the DISPO item. The officer who can comment an override is the COMMENT. Click on the button ‘ADD COMMENT’ to either approve or reject or comment the item. 2. . Officers can either comment or approve or reject based on the amount involved in the override generated by a transaction. he can add the required comments. All the comments made are recorded in the DISPO.

000.000 3. This implies that only officer 101 can comment and either approve or reject this override. No.ITEMS record. When an FT transaction was input for 20.OFFICER and COMMENT. because the limit to comment on is only 20.100. Officer 101 can do it. 1.123. Illustration of the table.Table Column 2 holds the amount up to which an Officer can comment on. then 101 is the next Officer who has privileges to approve or reject or comment on the override. Table Column 3 holds the amount up to which an Officer can approve or reject an override. An example will make things clear. Table Column 4 holds the ID of a DISPO Officer who is the next level financial approver. both the DISPO. The transaction amount is 20. because the limit to approve is only 10. because his limit to approve/reject is up to 30. No. If this DISPO Officer cannot approve or reject overrides.000 . which falls under the officer 101.OFFICER fields are populated with the respective officers in DISPO.000 and can approve or reject overrides with overdraft amount lesser than or equal to 10. The officer with ID 100 can comment on amounts lesser than or equal to 20. Now try answering the following questions.000 2.

4. DISPO Processing may or may not be allowed for an Override 2. All that you have seen till now is partial DISPO processing. then the fields PRECEDENCE. then DISPO processing can be enabled with limited features.UNAUTH. To enable full DISPO Processing for an Override.OFFICER application 1.ALLOWED is set to ‘YES’ in the OVERRIDE application. Officer 102 1. If DISPO field is set to ‘YES’.CON in the OVERRIDE application can be used 4. You can also set the fields DISPO. DISPO.IND.OD.AMOUNT and OVERDRAFT. Based on the special certifications required for a transaction. Officer 101 can do it. This field is set at . Officer 101 6.ALLOWED in OVERRIDE application should be set to ‘YES’ 2.ALLOWED field is set at the core and cannot be modified by any user. TRANSACTION. To enable an override for full DISPO processing.000 5. If an override is enabled for full DISPO processing. The example which was discussed in the previous slide is a record in the OVERRIDE application with ID as ACCT. Most of the overrides in T24 are stored in an application called OVERRIDE. the first step is to check if the field DISPO. The field DISPO should also be set to ‘YES’ 3. There is much more added functionality for DISPO processing 2. 1.AMT in DISPO. CONDITION. because his limit to comment on is 40. the field DISPO.

A DISPO officer can be set in the CUSTOMER. set the DISPO. set an officer other than the one set in the ACCOUNT record .OFFICER in a user record.OFFICER are defaulted to 101 as set in the ACCOUNT record and not to 100 as set in the OVERRIDE record. The value in this field must be input in the format ‘APPLICATION NAME>FIELD NAME FOR OFFICER IN THE APPLICATION’. TRANSACTION.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.IND. POSTING.UNAUTH. However.101. Attach the officer 101 in the field DISPO. Example : ACCOUNT>DISPO. Accept the overrides and view the transaction in DISPO. then the override is enabled for full DISPO processing In the OVERRIDE application. If the field PRECEDENCE is set for an override.OFFICER. When no officer is identified in the application. then the item will be assigned to the default officer specified in the override record 3. If the field DISPO.OFFICER To check the functionality of the field PRECEDENCE. Open the record ACCT. the fields CON. PRECEDENCE can be used only if the field DISPO.OFFICER field in ACCOUNT record . the fields from APPLICATION to DISPO. then the override is enabled for partial DISPO processing.OFFICER form a multi-value set.OVERRIDE.ALLOWED is set to ‘’ (NULL) and the field DISPO is set to ‘YES’. Note that the fields DISPO.OD in the OVERRIDE application.ALLOWED is set to YES which implies that an override is enabled for full dispo processing. then the officer assigned in that particular application will take precedence over the officer set in the OVERRIDE application.OFFICER and in the field DISPO.OFFICER and COMMENT. .RESTRICT and LIMIT applications apart from the OVERRIDE application 2. All the other fields are used for dispo processing.ITEMS. 1.ALLOWED is set to ‘YES’ and the field DISPO is set to ‘YES’. and set the field PRECEDENCE as ACCOUNT>DISPO. ACCOUNT. Input an FT transaction by debiting the account 35475.100.35475 to a valid DISPO officer . The fields CLASS and DETAIL are not to be used when an override is enabled for dispo processing.

213 in the TRANSACTION application and note the field GB.IND in the OVERRIDE application to ‘YES’.EXEMPT to ‘YES’ in a record in ACCOUNT or CUSTOMER application. the field TRANSACTION.NARRATIVE.TYPE ‘AC’ as the transaction code is 213 and commit the record. You can set conditional DISPO processing using the field CON. Input a new FT record with TRANSACTION. This can be done by specifying the field DISPO. There will be no dispo item as you have enabled TRANSACTION.ENTRY record and note the value in the field TRANSACTION. Set the field DISPO. The ID of a record should be numeric and a maximum of three numbers. Now try to view the same record in DISPO.1. which means any transaction which involves transfer of funds between accounts will have the TRANSACTION ID set to 213 To enable the functionality of the field TRANSACTION. Open the corresponding STMT. and note the statement number generated for the transaction. There will be no DISPO item for this transaction as you have exempted transaction type 213 from DISPO processing.CODE .IND should be set to ‘YES’ 2.EXEMPT to ‘YES’ You already know that a particular transaction can be exempted from DISPO processing in spite of the override being enabled for DISPO.IND. a small description is given about the transaction which is called as ‘NARRATION’. record 213 is used for ‘TRANSFER’.OVERRIDE which will hold the ID of another override . Now view the record . the first step is to open an FT record. For example. Set the field TRANSACTION. It is also possible to exempt overrides generated for a particular ACCOUNT or CUSTOMER record from DISPO processing. When an accounting entry is raised. To disable DISPO processing for a transaction.ITEMS application. T24 describes different types of transactions in an application called TRANSACTION. 1.213.EXEMPT to ‘YES’.IND In TRANSACTION application set the field DISPO.

ALLOWED set to ‘YES’. TRANSACTION.OFFICER application. then the fields PRECEDENCE. Accept the overrides and commit the record. Open the record LIMIT.2.OFFICER set to the same officer – 105. Copy the record ID and check if there is any DISPO item for this transaction.ITEMS.CON in the OVERRIDE application cannot be used. add both the override IDs. Now view the record in DISPO.OVERRIDE. No dispo item will be found which matches the ID. Note that only one override has been generated for this record. You cannot set the fields DISPO.UNAVAIL in the OVERRIDE application and set the field CON.AMOUNT and OVERDRAFT. Input a new LD record and note that both the overrides are generated. Check if both the records LIMIT. In the record 105 in DISPO. 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. The field DISPO should be set to ‘YES’ and the field DISPO.IND. Accept the overrides and commit the transaction. the actual override and the override specified in this field should be generated. Note that both the overrides generated are recorded in the DISPO item.ALLOWED set to ‘YES’ and DISPO.OVERRIDE to ‘EXCESS. Input another LD record and validate the transaction. CONDITION.AMT in DISPO.UNAVAIL and EXCESS.ALLOWED should be set to ‘YES’ along with the field DISPO set to ‘YES’ for full DISPO processing. If either of the overrides is generated.ID has the field DISPO. If an override is enabled for partial DISPO processing. The field DISPO.OFFICER application . Both the overrides generated in the transaction will be subject to DISPO processing To understand the functionality of the field CON. 3.ITEMS. check out for override records which have the field DISPO. as this record has generated only one override and is therefore not enabled for dispo processing 1. the transaction will not be subject to DISPO processing and will not have an entry in DISPO. For the transaction to be enabled for DISPO processing.ALLOWED to ‘’ (NULL) to enable partial DISPO processing.ID’ which is ID of an override record and is enabled for full DISPO processing.

OFFICER record with your name 4. Ask the trainer to modify ACCT. Set up the override record with all the required options 4. Create an account 2.2.UNAUTH. transaction will go to INAO 7. Create a DISPO. If the PRECEDENCE field is set. enter an FT 6. Authorize the FT.OD in your training area with precedence set as ACCOUNT>DISPO.OFFICER 3. Assign the DISPO officers to USER profiles 6.OFFICER is attached . Log in as the USER to whose account the DISPO.OFFICER field in the appropriate application 5. Log in as another user. Attach the Officer to a new USER profile 5.OFFICER application 3. Create Officers using DISPO. then set the DISPO. Input a new transaction and get the record status to INAO 7. Open the record using the enquiry LLS to reject or approve or to add a comment 1.

Error Messages: Such type of messages are displayed - Due to data not being input in mandatory fields Due to incorrect data input Due to incorrect relationship between field name and the data that is input.8. In case of Error Messages. it is possible that you come across two types of messages. . you will be able to:  Explain the need for constraint processing in T24  Define the steps in constraint processing  Create single and cumulative constraints  Explain the constraint related applications in T24 When you input a record in any Application in T24 and commit it. you need to correct the data input in the particular fields and commit the transaction again. Authorize the Override After completing this learning unit. Open the Dispo Item assigned to you 9.

constraints are a set of conditions on transactions to prevent certain activities. One can either enable or disable constraint processing in T24 1. 1. 2. The application EB.PARAMETER is used to enable constraint processing for all the companies in a T24 set up. 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. You cannot even put the record on hold. If you do not want to accept the Override. Constraint means limitation or restriction. If accepted. T24 allows you to create errors and overrides for custom defined conditions using the Constraint Processing.A record is not saved till all errors are corrected. From a T24 perspective. 3. Constraint Processing may or may not be enabled at different levels in T24. you may either put the record on hold to correct it later or amend the record and commit it again. Different applications are used to set this at different levels. Have you ever been able to generate an override message for a condition of your choice? 2. T24 saves the record and the override message is stored as part of it in the field OVERRIDE. at least most of the time. User has only one option to Accept Overrides. The ID should be ‘SYSTEM’ . Override Messages: These are warning messages.GC.

GC.PARAMETER record with ID as <COMPANY CODE>) Global level (EB. The ID of the record may be ‘SYSTEM’ or <COMPANY CODE> Eg.PARAMETER record with ID as ‘SYSTEM’) For example.GC. The ID should be <COMPANY CODE>.GC. If this field is set to ‘NO’.TRANSFER The field COM.GC. Eg.AND.PROCESSING in EB.PARAMETER table and if the field APP.GC.ACTIVE is used to enable constraint processing for a specific application in T24.PARAMETER decides whether or not constraint processing is enabled for a specific company or for all companies.PROCESSING should be set to ‘YES’ to enable or ‘NO’ to disable constraint processing. The ID of the record should be <APPLICATION NAME> Eg. Eg.: FUNDS. then constraint processing is disabled and if set to ‘YES’ constraint processing is enabled EB.GC.ACTIVE) Company level (EB.LOANS.: 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.AND.GC.GC.: GB0010001 The application EB. EB.PROCESSING in the record LD. The following is the order of precedence in setting up constraint processing Application level (EB.PARAMETER can have two types of records.PROCESSING in the records ‘SYSTEM’ and ‘GB0010001’ is set to ‘NO’ in the EB. then constraint processing is still enabled for the application LD.AND.ACTIVE (in GB0010001 company).ACTIVE is a FIN type file and the values that are set here are company specific.LOANS. if the field COM. LD.PARAMETER is used to enable constraint processing for a specific company. What could be the next step after constraint processing is enabled for an application? . The ID should be <APPLICATION NAME>. This application is used to disable or enable constraint processing for a particular application.DEPOSITS.GC.DEPOSITS.GC.LOANS.DEPOSITS is set to ‘YES’ in the application EB.The application EB. The field APP.

CONSTRAINTS application. either an override or an error.:The value in this field is given as INTEREST. FIRST.LOANS. An override ‘Debit Amount is less than 100000’ needs to be generated when a record in the FUNDS.DATE : This field holds the value date from which the constraint becomes active. set the field ERROR.DEPOSITS. Give the conditions for an application (Eg. Input an LD record with the value in the field INTEREST.OVERRIDE to ‘ERROR’.LOANS. you can generate an error message also. . Note that the overrides set by the core and the overrides set in constraint processing are generated. You are now ready to generate the override set in constraint processing.AND.AND. an error is thrown at the user.AND.VALUE ERROR.GC. If a wrong field name from the application is entered.TRANSFER application is committed with the field DEBIT. SEPERATOR : This field holds the separator to be used for the values mentioned in the field EVAL.LOANS.RATE greater than five. TEST. To generate a message as an error.AMOUNT set to a value less than 100000 Now that you know how to generate an override. This can be achieved through EB.RATE which is a valid field in the application LD. OPERAND : This field holds the operand against which a condition is generated.VALID. T24 performs a validation check on this field.:FUNDS.DEPOSITS.GC.DEPOSITS record in the EB. EVAL. Eg. The date in this field should be current date or a date greater than today.CONSTRAINTS.TRANSFER) in the EB. NARRATIVE : This field holds the actual message to be generated as an error or override. Eg. The value given in the field NARRATIVE in the LD.FIELD : This field holds a valid field from the respective application (record ID is the application name).VALUE : This field holds the value or set of values for comparison against which an override or an error is generated.The next step to do after an application is enabled for constraint processing is to define the conditions and the message to be generated.CONSTRAINTS application is generated as the override.OVERRIDE : This field holds the type of message to be generated. The ID should be the application name.: LD.GC.

TYPE is not set to AC in FUNDS.ACTIVE and EB.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.GROUP.: When contracts are input in applications such as LD.GC.: If a record is committed in the FT application. based on specific fields 2.GLOBAL is used EB. You could simply create three records in EB.GC. if the loan amount or deposit amount or debit amount transacted is greater than 200000. 1235. An error ‘DEBIT CURRENCY SHOULD BE USD’ needs to be generated when a record in the FUNDS.SMS. an error should be generated if the field TRANSACTION. So then what else can you do to accomplish this setting? 1. EB. To group applications that generate same error or override. Grouping users is done to set same set of privileges for a group of users in USER.CURRENCY has a value other than USD What if you wish to generate same errors or overrides for different applications? Eg.Eg.GLOBAL can be any user defined value. TOM. an error message “Amount should be less than 200000’ needs to be generated. etc.TRANSFER application.: ABCD.TYPE is not equal to ‘AC’.CONSTRAINTS (one for each application) and set appropriate conditions for the specific fields. MM and FT. The ID of the record in EB.. Note that the error message is generated as it is given in the field NARRATIVE in EB.GC. .TRANSFER application is committed if the field DEBIT.GC. FT. But what if the bank wants several applications to generate same override or error message? Creating different records in these applications becomes a tedious job. Eg.GC.CONSTRAINTS application when the field TRANSACTION. Grouping applications for constraint processing is similar to that 3. T24 has the functionality to generate the same error or override message for multiple applications.GC.

MONEY.CONSTRAINTS. an error to be raised respectively.APPLICATION : This is a multi value field which specifies the application name for which the override or error has to be generated TARGET.CONSTRAINTS If you recollect the example you have seen in the earlier slides.AND.GLOBAL.CONSTRAINTS should be ‘GLOBAL’. a record in EB.GC.GC.GLOBAL should be enabled for constraint processing.If interest rate is greater than 5%. the ID is the application name itself.GC.LOANS.AMOUNT in FUNDS. When there are multiple applications involved in constraint processing. an override to be raised and if TRANSACTION. the applications that are to be used in EB. Eg. the applications LD. this can be achieved by using the application EB.TYPE is not AC. the field AMOUNT in LD. An application can have two constraints defined in EB. The conditions were .DEPOSITS and FUNDS. Both these fields form a associated multi value set.ACTIVE.MARKET should generate an error message if the respective fields holds a value greater than 200000 After the applications are grouped in EB. If only one application is involved.FIELD : The field holds the field name from the application mentioned in the previous field for which the condition has to be checked.GC. the ID of the record in EB.TRANSFER. As you know by now.GC.FIELD should contain a field name of the application which is the ID of the record in EB.GLOBAL application.TRANSFER have application specific records in EB.GC.CONSTRAINTS application.AND. The field TEST. What will you specify in this field if the ID is set to ‘GLOBAL’? In the record ‘GLOBAL’ the field TEST.: The field DEBIT.FIELD should hold the ID of the record (in which the applications are grouped) from EB. 1.GC.DEPOSITS and the field PRINCIPAL in MM.CONSTRAINTS is to be created with ID set to GLOBAL. Even before you set up the record. .GC.GC.LOANS.

PARAMETER and the field APP. both constraints will be generated.CONSTRAINTS. 2. A value CUMULATIVE denotes that multiple constraints can be applied.METHOD in EB.GC. which constraint takes the precedence if the field APP. Can you specify that the conditions specified in application specific records alone should be executed for LD and FT? Yes.METHOD in EB.PARAMETER application.GC.GC.GC. The field COM.METHOD in EB. 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.CONSTRAINTS. 3.If amount is greater than 200000. then this is known as Cumulative constraint processing.CONSTRAINTS takes the precedence and only the error or override stored in this record can be generated.METHOD is set to SINGLE? The constraint which is defined in the application specific record in EB.GC.You have also set the group which is a part of the record ‘GLOBAL’ in EB.CONSTRAINTS application in which LD. . The constraint set for this record is .METHOD in EB.GC. If an application has constraints set up in the application specific record as well as GLOBAL record in EB. If an application has constraints set up in the application specific record as well as GLOBAL record in EB. This is known as Single constraint processing.ACTIVE are the ones which decide whether or not a company or an application is enabled for ‘SINGLE’ or ‘CUMULATIVE’ constraint processing. then. FT and MM are included. then an override is to be raised. The value set in the field APP. A value SINGLE denotes that only one constraint can be applied.GC. If both the conditions are executed.ACTIVE takes precedence over the value set in the field COM.GC.

MARKET and FUNDS.: When contracts are input in LD application by the user CHAITANYA.: USER is the record ID in EB. Since CUMULATIVE processing is enabled for MM.METHOD in LD record in EB. Note that though the value in the amount field is greater than 200000.TRANSFER. What if you wish to restrict a user to use only a particular value in a field? 2. An error should be generated if any other value is used by the user. she should only be allowed to use a value 21051 in CATEGORY field.MONEY. Eg. an error ‘CATEGORY SHOULD BE 21051’ is to be generated.GLOBAL with ID as any text and specify the application and the field name against which condition is to be set.AND.LOANS.Since CUMULATIVE processing is enabled for FT. an error is not generated but the application specific override is generated as the field APP. Since SINGLE processing is enabled for LD.GLOBAL To set constraint for a specific user. MM.GC. Eg.GC. constraint set in the GLOBAL record is only executed as it does not have a constraint set in the application record.ACTIVE is set to SINGLE and the application level setting takes the precedence. if the fields CURRENCY and DEBIT.GLOBAL . only the constraint set for the application in the application specific record is executed.CURRENCY is not equal to USD.DEPOSITS. an error message ‘CURRENCY SHOULD BE USD’ is to be generated 1.GC. This is almost similar to setting up a group in EB. constraint set for the application as well as the constraint set in the GLOBAL record are executed. create a record in EB.GC. When contracts are input in applications such as LD. If she inputs any other value other than 21051 .

CURRENCY in FT application.METHOD in EB. etc. an account.FIELD should hold the ID of the record (created for user specific constraint) from EB.GC. currency . An error ‘CURRENCY MUST BE EUR’ should be generated if any other currency is used By now you should know that a record in EB. One important thing to note here is the order of precedence for constraints to be executed.METHOD is set to SINGLE.GC.After creating the record in EB. it has application specific record. If amount is greater than 200000. The constraints were . account.. If you recollect the constraints set for LD. all the constraints will be enabled for a contract if it is input by this specific user. Eg. Use five forward slashes in between.GC. application specific constraint is the second and group specific constraint is the last. the field TEST. User specific constraint is to be executed first. an error message to be raised.LOANS.CONSTRAINTS. Eg. As you know if you set the field APP.GC.AND. a record in EB. then the user specific constraints are only executed.GC.. If any other user inputs the contract. If the field APP.GC.: When a contract is input in LD with AMOUNT set to 300000 CATEGORY set to 21052 and INTEREST. a customer.RATE set to 9%.CONSTRAINTS is to be created with ID set to GLOBAL/////<USER NAME>..CONSTRAINTS can be created specific to a user. etc. record with ID as GLOBAL and a user specific record in EB. The actual expansion of the ID in EB.GC. then the constraint pertaining to the field CATEGORY will not be executed as it is user specific. an override to be raised and If category is not equal to 21051. User should only be allowed to input ‘EUR’ in the field DEBIT. only one error for the field CATEGORY is raised and no other constraints are executed as LD enables only SINGLE constraint processing.CONSTRAINTS is GLOBAL/CUSTOMER/PORTFOLIO/ACCOUNT/CURRENCY/USER which means that you can also set conditions specific to a customer.ACTIVE for LD to CUMULATIVE.: GLOBAL/////CHAITANYA As you already know.GLOBAL.DEPOSITS.If interest rate is greater than 5%.. Now if there are different specific conditions defined in this application for a customer. an override to be raised .GLOBAL application. portfolio. an account. The other fields should hold the conditions and the error message to be generated.

GLOBAL with the required applications and relevant fields. To create a subgroup use the application EB.GC. you can also achieve this by using another application EB.GC.CURR.GROUP.PARAMETER which controls the precedence of constraints when single constraint processing is enabled. with ID set to CURRENCY. Eg.and user which means different specific records created and if the constraint processing is set to single for the company. and attach it in EB. PRECEDENCE.ACCT. then which constraint will take the precedence? How will you control the precedence in such a scenario? To overcome this. attach the ID of this record in the field TEST.CUST will define the order of precedence.FIELD and specify other conditions in EB.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.GLOBAL. This is similar to what you have already done. These fields can hold a value from one to five. this specific constraints takes the precedence over the other.PORT and PRECEDENCE. PRECEDENCE.GC.CONSTRAINTS application with the condition. APPLICATION : This is a multi value field which specifies the list of applications which are members of this subgroup.GC. Attach this ID in the record GLOBAL in EB. Eg.GC. there are a set of fields in EB. ID of the record can be text. PRECEDENCE. Only the applications which have a record in EB. A value of one in any of the fields means that.CONSTRAINTS.ACTIVE can be input in this application.CONSTRAINTS.USER. However.GC. You can achieve this by creating another record in EB. The fields PRECEDENCE.GC.: Generate an error ’CURRENCY MUST BE USD’ for the applications LD and FT if the currency used is not equal to USD .GC.: Create another group for LD and FT with their relevant fields.GC.

the fields CURRENCY and CREDIT. an override message ‘CREDIT CURRENCY IS NOT USD’ needs to be raised.GROUP Create a record in EB.MARKET and FUNDS.CONSTRAINTS whose ID is the same as the ID in EB.CONSTRAINTS application and specify the relevant conditions. Otherwise an error ‘CURRENCY NOT EQUAL TO EUR’ should be raised.GLOBAL with the required applications and their relevant fields.GROUP. Otherwise an error ‘CURRENCY NOT EQUAL TO EUR’ should be raised.MONEY.GC. In both FT and LD the error ‘CURRENCY MUST BE USD’ is raised. How can an override generated by constraint processing be made a blocking override? Eg.: The field DEBIT. Use EB.GC.: When a credit account with currency other than USD is input in a FT transaction.As soon as a record is created and authorized in EB.TRANSFER. As the field APP.GLOBAL in the field TEST.MONEY. an error should be thrown. in FT. For applications MM.MARKET and FUNDS.GC. . the fields CURRENCY and CREDIT.TRANSFER.METHOD is set to SINGLE in EB. Eg.GC. Attach the ID of the record created in EB. Use EB.GC.FIELD in EB. GROUP : This is multi value field and is not inputtable by the user.GC.CURRENCY respectively should accept only EUR.GC. Create a record in EB.ACTIVE.GC. the field GROUP is updated with the ID of the subgroup record in the corresponding record in EB.ACTIVE application.GROUP.GROUP application to achieve this.GROUP application to achieve this. This override should only be approved by user belonging to a particular class.GC.GC. error is raised for DEBIT. For applications MM.GC.CURRENCY respectively should accept only EUR.CURRENCY and CURRENCY in FT and LD should be USD. Otherwise. Take a look at the records. This field holds the ID of the records in EB.AMOUNT field as the value in this field should be less than 200000.

DIAG can hold the value ‘YES’ or ‘NO’.LIFE will hold a value of 8. The field DATE holds the date on which the log was entered and the field DEATH.DATE for all the records and if this is less than today.COB deletes the log if the value in the field DEATH.DIAG. This is a live file and updated by the system.GC. The field COM. 3.GC.DIAG in EB. Who will actually delete the logs from the file EB.DATE is less than today 2.DIAGNOSTIC. The job EB.DIAG and APP. At this point.The fields COM.DIAGNOSTIC.COB is a ‘D’ frequency job and is run daily.DIAGNOSTIC.GC.DIAG.GC. a log will be created in the file EB. then the log record is deleted from the file. 1. The settings in the field APP.: If the log date is 7th August 2008 and the COM. This field decides whether or not the constraints are to be logged.LIFE holds the number of days after which the logs should be deleted. EB.ACTIVE takes the precedence over the settings in the field COM. Eg.GC.DIAGNOSTIC. All the details of the constraint are stored in this record.DATE will hold a date which is equivalent to the date of the log + the number of days given in the field COM.LIFE.GC.PARAMETER application.DIAG. . When the condition set for a particular field is breached or violated. A value ‘YES‘ denotes that diagnostics recording is enabled.DIAGNOSTIC and when? A COB job named EB. then the death date will be 19th August 2008.GC.DIAG in EB. the constraint is triggered.COB checks the field DEATH.

Note that only working days are calculated to arrive at death date. 1.GC. EB.Eg. EB.CONSTRAINTS application decides whether an error or override message has to be generated 5.LIFE will hold a value of 8. then the death date will be 19th August 2008.: If the log date is 7th August 2008 and the COM. EB.GC. EB. EB.DIAG.PARAMETER is used to enable constraint processing at company level or SYSTEM level 3.ACTIVE is used to enable constraint processing at application level 4.GLOBAL allows constraints to be established at Global level across multiple applications 6.GROUP enables creation of sub groups .GC.GC. This record will be deleted from the file during COB on 20th August 2008. T24 allows you to create override and error messages using the ‘Constraint Processing’ 2.GC.