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.

Inputter is the person who inputs data into the fields in a record. The user must have access to the Input function.

Authoriser is the person who checks the record and authorises it. The user must have access to the Authorise function.

The error message “EB.RTN.SAME.NAME.AUTHORISER/INPUTTER” will be displayed if the same user tries to input and also authorise the 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. Rights and privileges for a user are defined in his user profile . For example, access given only to FUNDS TRANSFER and CUSTOMER application and also restrict the access only to Input and List functions

3. The user profile is nothing but a record in the USER application

To create a user in T24, you will feed values into some mandatory fields in the USER application. You will now learn to create a simple USER profile. To create a user record, type USER and the ID of the record you want to create in the command line. USER ID and the USER NAME can be the same but the SIGN ON NAME has to be different from the USER ID.

ID : This is the ID of the record in the USER application which can be any alphanumeric text.

USER NAME : This field holds the name of the user.

SIGN ON NAME : Name which the user will use to sign on to T24. Has to be different from the name given in the field User Name.

PASSWORD : The password is also stored as part of the user profile. It is encrypted at database level and is not displayed as part of the record in the USER application.

CLASSIFICATION : Int (Internal) Indicates whether the User is 'Internal', i.e. an employee of the bank using T24. Ext (External) is currently not working.

LANGUAGE : You have to set up the language field in the USER application for all the messages, instructions, help text etc. to be displayed when possible in the language indicated. The language codes are pre defined in the LANGUAGE table. The model bank setup of T24 supports four languages namely : ENGLISH, FRENCH, GERMAN, SPANISH. If the translation is not available for other languages, then ENGLISH will be defaulted.

T24 allows the user to access multiple companies as it supports MULTI COMPANY set up.

COMPANY CODE : Specify the companies to which the user has access to. The first company code specified here will be the default company to which the user will log on to. The companies defined in a T24 installation can be found in the COMPANY application. The keyword ALL can be used to access all companies.

If the value in the COMPANY CODE field is specified to ALL and in the next multi-value set if the company code is specified as EU0010001, then when the user logs into T24 EU0010001 is the default company into which he will log into.

All users must belong to some department or the other in the Bank. Department Code will allow an easy identification of any user of the T24 System. Department Codes must be predefined in the static table DEPT.ACCT.OFFICER in T24. The purpose of this table is to identify each Department and Account Officer in the bank by means of a code.

DEPARTMENT CODE : Specifies the department to which the user belongs to.

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 time. T24 allows the user to specify the password valid date and the frequency of change.

PASSWORD VALIDITY : Specifies how often and on what date the User must change his Password. Next Change Date entered, must be greater than today's date (machine date) and not more than 6 months from today. Date until which the password is valid followed by the frequency of change.

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.

There are fields in the USER application that controls the validity of the user profile. This period is controlled by the following fields.

START DATE PROFILE : Date from which the profile of the user will be active. User will be able to login into T24 from this date onwards. This field takes machine date and not T24 date. Date entered in this field should not be less than today’s machine date.

END DATE PROFILE : Date until which the user profile is active. The user will not be able to login into T24 after this date.

If a user has access to T24, would the bank want to give him a 24hr access to the system? No, in most cases the working hours of the bank will determine when a user must be allowed to use the system. The fields Start Time and End Time control the time span in a day when the user can log in to T24. Input can be like 0-2359, 0000-2359, 00:00-23:59, etc..

START TIME : Based on the 24 hour clock. (one denotes 0001).

END TIME : Based on the 24 hour clock. Irrespective of the time specified here, if the user is logged in to the system, he will be allowed to continue accessing T24. However, once logged off user will not be allowed to login after the time specified in this field.

These two fields form a multi-value set, enabling multiple periods of time to be defined per day.

If you want to open a savings account with a Bank, the user of the bank has to first open a new record for you in the CUSTOMER application. In this process, if the user who is opening the record for you is called for some other important work, he might have to leave your record without completing and may walk away. No other user is allowed to open your record and edit it as it will be locked by the first user. In such a scenario, how long would you wait for the same user to return back and complete your record? This is practically not possible. Therefore T24 supports the concept of Time Out Minutes. The

Administrator can specify the number of minutes the user can be active without actually working on the system. If the time limit lapses for the first user, he is signed off automatically and another user can complete your record.

TIME OUT MINUTES : Specifies the maximum time in minutes during which the User may be inactive without being Signed Off automatically. Once this time is reached the user is not allowed to perform any action. The user has to login again to perform any action in T24. Maximum of three numeric characters which is 999 minutes.

Most websites that require a user name and password, have a check on the number of times that a user can incorrectly type in a password. The account is then locked and the user is forced to reset his password. T24 also supports this functionality that allows the administrator to define how many unsuccessful sign on attempts a user can have before locking his account. This helps safe guard the profile against hackers.

ATTEMPTS : Allows only one numeric character to input and hence the maximum can only be nine.

A user in T24 may not be allowed to perform same set of actions in different companies. It is possible to specify application, function and field level restrictions for a company. These set of permissions can be set up in the Associated multi value set from COMPANY RESTR to DATA TO. The company to which you want to restrict the access should have been mentioned in the COMPANY CODE field.

COMPANY RESTR : Contains a valid company code. This company should be defined as part of the COMPANY CODE field. Permits to input "ALL" to allow the access for all companies listed in the COMPANY.CODE field.

APPLICATION : Can contain a valid application name or if it contains ALL.PG, the user will have access to all applications in T24 in to the company entered in the field COMPANY RESTR.

FUNCTION : List of valid functions that the user can use in the company. Type ALL to give access to all the functions. When the record is committed it will display the values A 2 B C D E F H I L P R S V automatically. The Q function does not appear by default. Q stands for Audit Review.

‘A’ is a function which allows the user to authorise an unauthorised record.

‘2’ is not a function. This is used along with the function ‘A’ to allow the user to authorise a record which needs a second authoriser. (Record status of a record which needs a second authorisation would be INA2).

‘C’ is a function which allows the user to copy a record.

‘D’ is a function which allows the user to delete a record which is not yet authorised. A live record cannot be deleted.

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

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

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

‘L’ function is used to list live records.

‘P’ is used for printing.

‘R’ is used to reverse a record which is no longer used.

‘S’ allows user to only view the records.

‘V’ is a special function which is supported only by some applications in T24. It is used to produce some extra information and also performs some extra actions.

All the actions performed by the user may or may not be logged. PROTOCOL is the file in T24 which stores the logging information of a user. If you want to record all the actions performed by the user, the following fields have to be set to YES. This file is updated by T24 and therefore records cannot be edited but only viewed.

SIGN ON OFF LOG : If set to YES, will log sign on and sign off details of the user in the PROTOCOL file.

SECURITY MGMT L : If set to YES will log details in the PROTOCOL file when the user accesses the following SMS related files in T24

PASSWORD (Used to change companies)

PASSWORD.RESET

USER

APPLICATION LOG : If set to Yes will log details of applications that the user uses on to the PROTOCOL file.

FUNCTION ID LOG : If set to Yes will log the functions and the IDs used by the user on to the PROTOCOL file.

INPUT DAY MONTH : Format for the user to input dates. No matter how the date is input by the user, T24 will store the data in YYYYMMDD format.

CLEAR.SCREEN : This is a mandatory field. This field is more oriented towards CUI Interface where once a deal is committed the screen is cleared if set to ‘Y’.

If you set the field CLEAR SCREEN to ‘NO’, even after the transaction is complete the record is still displayed on the screen.

If you set the field CLEAR SCREEN to ‘YES’, after the transaction is complete the record gets closed and the screen is cleared.

Create a user profile with sign on name as your name with values into all the mandatory fields that you have just learnt. Authorize the record and try logging in to T24 with the new user you have created.

If in a particular company you want the user to have access only to few specified applications and functions? Can you also restrict the user access based on actual data contained in the records that the user is going to access. Is this possible in T24?.

Yes. These specific restrictions can be achieved by using the fields from COMPANY.RESTR to DATA.TO which form a multi value set. The field COMPANY.RESTR can have the company code in which the user will be allowed access only to few applications. The APPLICATION field will hold the name of the application which can be accessed by the user. The field VERSION can contain a valid version name of the application specified in the field APPLICATION. The field FUNCTION will hold the function which the user can access in the particular application.

FIELD NO : Must enter the actual field number of the required field from the record in an application.

DATA COMPARISON : Must select the valid operand you would want to use for comparison. This field can be left without any input also. Different operands available are

EQ which resembles Equal To. This operand can also be used to specify a range of values.

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. This may also contain the starting range.

DATA TO : This field holds the end range of the selection.

For example, 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.

User can access records in the ACCOUNT application for the company GB0010004 in Authorize mode only and provided the field CATEGORY ranges from 1000 to 2000. The operand to use to select the range is EQ.

The following set of fields gives the information for Audit purposes. All these fields are updated by the system and hence are no input fields.

ATTEMPTS SINCE: Indicates the number of unsuccessful attempts to SIGN.ON since the last successful SIGN.ON. It is displayed on the SIGN.ON screen.

DATE.LAST.SIGN.ON : Indicates the date this User last Signed On successfully. It is displayed on the SIGN.ON Screen.

This date is the actual date (system date and not T24 date) on which the User Signed On.

TIME.LAST.SIGN.ON : Indicates the time of day at which this User last Signed On successfully. It is displayed on the SIGN.ON Screen.

PASSW CHANGE DATE: Indicates the date on which the password was changed last time.

PASSW END DATE: Indicates the end date of the password.

DEACTIVATION.DATE : The date that defines the start of the deactivation period. This can only be entered or changed by the User via the PASSWORD Application.

REACTIVATION.DATE : The date that defines the end of the deactivation period. This can only be entered or changed by the User via the PASSWORD Application

CLEAR.SCREEN : This is a mandatory field. This field is more oriented towards CUI Interface where once a deal is committed the screen is cleared if set to ‘Y’.

The code specified here will be defaulted when a transaction is input in some applications like FUNDS.TRANSFER, FOREX, etc., by this user. The code to be specified here should have an entry in DEALER DESK table. The currency position specified for this dealer will be used for the transaction input by this user.

DEALER.DESK : Identifies the dealer desk position which needs to be updated by the deal being created. Identifies the dealer desk code applicable to the user. If left blank T24 will default code ‘00’.

PRINTER For Rpts : Name of a T24 printer to which reports will be spooled and printed. Printer names specified in other report generation specific applications take priority over this. Printer is set up using the application PRINTER.ID in T24.

Printer For P Func : Name of a T24 printer to which reports will be spooled and printed when the user uses function P to print.

GB USER.ADDR : Address that will be printed on the report banner page. Each multi-value represents one line on the banner. A maximum of three lines can be used. If left blank then the delivery point from the DEPT.ACCT.OFFICER file is used.

RPT.TO.RECEIVE until Last Spool Time: This is a associated multi value set.

RPT TO RECEIVE : The name of the reports this user is to receive from the over-night batch run. Must be a valid entry on the REPORT.CONTROL file.

RPT.COPIES : The number of copies this user should receive.

LAST.SPOOL.DATE : The date when the report was last spooled.

LAST.SPOOL.TIME : The time the report was last spooled. Both the LAST SPOOL DATE and LAST SPOOL TIME are no input fields.

The field ATTRIBUTES on the USER profile can be used to control specific T24 functionality. What you set in this field will decide what the user can or cannot do. Some of the attributes can only be used if the front end is DESKTOP. The various options available are explained in detail below.

BRANCH.MANAGER : Only if the client has BRANCH RESILIENCE product, this attribute can be set for the user. Branch Resilience is a backup system for branches to be used when communications to the head office system are interrupted. Once repairs to the communication infrastructure at head office are complete and reliable, the local administrator will begin the process of switching users, back to the head office system and ensures that updates to and from the branch and head office are processed. The branch administrator will use the T24 Toolbox to monitor and maintain the branch backup database. To use the T24 Toolbox the user must have the value BRANCH.MANAGER selected in the Attributes field in the USER application.

COMMAND.LINE : The user is allowed the use of the command line in T24 Browser.

DEVSTUDIO : This is reserved for future use.

ENQUIRY.INDEX and EXPLORER : These options does not have enough information.

LOCK.DEACTIVATION : Prevents user access to the User Deactivation listed in Tools dropdown list.

LOCK.DESIGNERS : Prevents user access to the listed Designer Tools dropdown list.

LOCK.MISC.ITEMS : Will bring up a Security Violation when the User Abbreviations Toolbar, Enquiry and Report lists are used.

LOCK.PREFERENCES : If the user is given this option then the ‘User Preferences’ option under the ‘Tools’ menu on the Desktop toolbar will be disabled. This will prevent the user from gaining access to various Desktop settings including file locations and some system administrative functions.

NO.ENQUIRY.REPORT : Prevents user exporting Enquiry data from an Enquiry screen, the icon will be dimmed and non reactive.

REALTIMEENQUIRY : Allows the use of real time enquiries for this user. When signing onto T24, Browser will create another session for use by the real time enquiries. This does use an additional database license, but not an additional T24 license. Not enough information is available for this option as well.

SUPER.USER : The user has access to all of the features detailed above, and for all future functionality with the exception of REALTIMEENQUIRY.

If you want T24 to perform some extra action during sign off process, you have to define the following field.

SIGN.OFF.ITEM : The name of any BASIC subroutine can be entered into this field. During the SIGN OFF process, any subroutines defined in this field will be called with one parameter. If this parameter returns with the values N, or NO the SIGN OFF processes will be halted

SIGN ON ITEM and PROCESS DEPT fields are obsolete.

OTH.BOOK.ACCESS and OTH.BOOK.BLOCK fields are used only if T24 Multi Book product is installed.

A Bank may not want its users to login to the system out of its working hours or may even limit the user’s access to a specific time period. These settings can be done using the following Associated multi value set.

ALLOWED DAYS : This field is used to specify the access to T24 in particular days. You can choose a number from the drop down list which can contain a value from one to seven where one is Monday and seven is Sunday.

DAY ST TIME : Time is based on 24 hour clock. This field indicates the start time of the user’s access to T24 in a particular day.

DAY END TIME : This field indicates the end time of the user’s access to T24 in a particular day.

Example with reference to the screen shot : User CHAITANYA1 can access T24 on Monday from 10:00 to 15:00 and on Wednesday from 16:00 to 23:00

If the above set of multi value fields is not specified for a particular day, then the values set in the field Start Time and End Time will be used.

If you want to sign on to T24 as soon as you signed on to your system, how can you do it? This is possible in T24 in the following fields.

Ldap Id and Ldap Dn : These fields are used to configure the Temenos Connector to use LDAP as part of the authentication mechanism. It is most widely used as part of a corporate single sign on mechanism. The advantage of this system is that the T24 username and password are never known outside the T24 server. Ldap Dn becomes mandatory field once Ldap Id is entered.

Lead Pref : Is an obsolete field in T24.

Irrespective of the date format given in the USER application, T24 stores the date in a single format across. However you can set the display format of

the date at the user level.

Date Format : Describes the format for displaying the date. Options available are

1 - DDMONTHYEAR

2 - DD/MM/YYYY

3 - YYYY/MM/DD

4 - YYYYMMDD

OFFLINE.SMS.PROFILE field is used only if the BRANCH RESILIENCE product is installed.

When a record is commited or authorised, T24 updates the following audit fields. They are no input fields attached to the end of every record across applications.

RECORD STATUS: Holds the status of the record. Possible values are INAU, IHLD, INAO, etc.,. If the record is in live file, then there is no entry in this field.

CURR NO. : Holds the number of times the record was edited.

INPUTTER : Holds the ID of the user who has inputted the record.

DATE TIME : Holds the date and time when the record was last edited.

AUTHORISER : Holds the ID of the user who has authorized the record.

CO CODE : Defaults based on current company logged into.

DEPT CODE : Defaults to the user’s department code.

The two fields below are populated only when a record is audited (Q function),

AUDITOR CODE : Holds the code of the auditor who has reviewed the record.

AUDIT DATE TIME : Holds the audit date and time.

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

T24 passwords must follow the rules discussed below.

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.

The new password holds good for this user ID.

1. Create a user named XXXXX (Where XXXXX is your name)

2. User should have access to any one company only – GB0010001

3. User should be allowed to access only the ACCOUNT and CUSTOMER applications

4. User should be allowed to use only functions. See, List and Print for the CUSTOMER application. See and Exception listing for the ACCOUNT

application

5. User should be able to use the command line

6. User should be able to use the system only between 10:00 and 06:00 on all days

In this demo, you will learn to create a user record in T24.

The user record has been created.

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, regardless of the value in this field

Stores the log details if the user accessed SMS related files if the field Security Mgmt L is set to YES

Stores the details if the fields Application Log and Function Id Log are set to YES

PROTOCOL file can be accessed in two ways

By typing PROTOCOL L in the command line to list all the records in the file

By running an enquiry ENQ %PROTOCOL, which takes you to the selection box

The contents of a PROTOCOL record include-

@ID : This is the code by which a record is identified. The format being:

YYYYMMDD is the date on which the recorded event (security violation or other activity) occurred.

NNNNNNNNNN is the sequence number allocated to the event when it was recorded. The first event recorded each day is 0000000001 and so on.

XX is the sequence number to identify the number of activities per one second.

Process Date : Date on which the activity took place. Displayed in the format which was selected in the DATE FORMAT field in USER application.

TIME : Identifies the time at which the recorded event took place.

TIME.MSECS : Time when the activity took place denoted in the format hh:mm:ss:msc

TERMINAL ID : The input is in the format NN XX. The first part of the terminal id denotes the database user number and the second part denotes operating system port number.

PHANTOM ID : Denotes the terminal at which the activity took place.

COMPANY ID : Denotes the company in which the activity took place.

USER : Holds the USER.ID of the user who has performed the action.

APPLICATION : Identifies the Application which was being used by the user.

LEVEL.FUNCTION : Identifies whether the Application had been accessed directly or via '!'. Level 1 indicates that the Application was accessed directly. Level 2 indicates that the Application was accessed from another Application via '!' mark. ! Works only on the classic user interface of T24 and is used to drilldown from one application’s field to another.

ID : Holds the record ID of the application used.

REMARK : This field denotes the activity performed and why the system did not allow the attempted activity.

1. PROTOCOL file gets accumulated with all the activities performed by the user and hence this file can grow very huge in size

2. Based on the requirements, this file has to be cleared periodically by attaching a routine to COB. Based on the requirements, this job could be executed daily, weekly, monthly or on an adhoc basis

1. What do you do if you have to set the same set of privileges to a group of users?

2. Will you set the privileges in every single user’s user profile?

3. Would you like to create something like a role in Oracle (set of privileges) and apply it to the relevant users?

There are about 10 account managers in the bank for whom the following privileges need to be granted

1. Restrict usage to the following functions only : Input, See, Delete and Authorize

2. Application that they can have access to is CUSTOMER provided the field Sector is 1000. This can be done using an application USER.SMS.GROUP in T24

Open a record in the application USER.SMS.GROUP. ID can be any alphanumeric text.

GB DESCRIPTION: Mandatory field used to input the narrative of the record ID.

APPLICATION: Multi Value Field which is used to input all the applications which this user group can have access to.

FUNCTION: This field is used to input all the allowed functions for the group of users.

FIELD NO: Specified when used together with fields Data Comparison, Data From and Data To. For example, a CUSTOMER record can be accessed only if the field no.23 in the CUSTOMER record, which happens to be field SECTOR is equal to 1000.

The record ID created in USER.SMS.GROUP has to be attached in the profile of the user in the field Application as “@ID”. When you attach the SMS group for a particular user, you cannot specify individual privileges to the user. For example, you cannot input in the fields Version, Function, Field No., Data Comparison, Data From and Data To in the USER application.

1. Amount Format field specifies the separators to be used when formatting amounts

2. Specifies the separators to be used when formatting amounts for Enquiries, REPGEN’s and screen input/display

3. The millions & thousands separator can be a comma, full stop or apostrophe. The decimal separator can only be either a comma or full stop

Input is restricted to two character pair. For example ., or ‘, or ‘. The first value is the separator used for millions and thousands. The second value is the one used as a decimal separator.

If you only enter the amount without any separators in the field Debit Amount and validate the record, the separators are defaulted as set in the Amount Format field in user profile.

After completing this learning unit, you will be able to:

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.

For example, A customer wants to withdraw $100 from his savings account which has a balance of $150. Assume that by T24 norms, the minimum balance in the savings account should be $100. Now if you input the transaction to debit $100, when committing it T24 must warn you about the insufficient funds available. T24 cannot stop you, but it can warn you. T24 generates an override to do this. You will have only two options, to accept it and complete the transaction or reject it and stop.

When you input a record in any Application in T24 and commit it, it is possible that you come across two types of messages.

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

In case of Error Messages, you need to correct the data input in the particular fields and commit the transaction again. A record is not saved till all errors are corrected. You cannot even put the record on hold.

Override Messages: These are warning messages, at least most of the time. A user may accept or reject override. If accepted, T24 saves the record and the override message is stored as part of it in the field

OVERRIDE. If you do not want to accept the Override, you may either put the record on hold to correct it later or amend the record and commit it again.

In this demo, you will learn how overrides are handled in Classic mode of T24.

You have learnt how to handle overrides in CUI.

1. ‘Override’ is the name of the field which stores the override messages generated on committing the record

2. This field is part of almost all the applications in T24

3. It is a no input field and updated by T24

4. Old overrides are overwritten with new ones

1. There can be two different types of override messages. They are Non Blocked and Blocked overrides

2. A record which generates non blocked overrides can be authorised by any user in T24

3. A record which generates blocked overrides can be authorised only by users with appropriate privileges. If you do not have sufficient privileges the record will go to INAO (Input Not Approved due to Override) status

4. By default, all overrides in T24 are Non Blocked in nature

Where are Override messages stored?

In the OVERRIDE Application. T24 applications generate override messages stored here.

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.

So are override messages only static text messages? What if they need to hold values from the transaction? In that case, the override message will also contain a special character ‘&’ and each ‘&’ is then replaced with a value when T24 actually generates the override.

In the override ACCT.UNAUTH.OD, the first & is used to denote Currency, the second & to denote Amount and the third & to denote Account number.

Type, Channel and Approve Method : These fields are used only in ARC IB and are not in the scope of this learning unit. However, to give you little information about Channel field, based on the type of Channel you select to access T24 (like call center, branch, internet, etc.,), you can set this Override message to act differently such as a warning message, an error message, a confirmation message, etc.,.

Now what if we decide to change an override message in T24?

Prev Message : This field in the OVERRIDE application holds the message which was previously displayed for that particular Override. Only overrides that have changed over the years will have a value in this field.

Numeric Id : This is a no input field. T24 generates a unique number for every record in the OVERRIDE application on committing the record. This number is prefixed with ‘O’ which resembles Override.

App Version, Subroutine and Validation fields is used only in Desktop and does not have any relevance in Browser.

You will now see an illustration to prove that all overrides in T24 by default are non-blocked. In other words, no special permission is required to accept it.

You will see how the override ACCT.UNAUTH.OD is generated when you try to transfer funds from a zero balance account to another account. The screen shot above is of an account record created exclusively for this illustration. This account now has a zero balance.

The account created earlier is debited in this FUNDS TRANSFER transaction. The override message is displayed and you can accept it. The record is now committed.

After the record gets committed, open it in ‘SEE’ mode and check the field OVERRIDE. You will notice that all the Overrides generated are stored in the record and are never deleted.

1. Now that you realise what a non-blocked override is, the next thing to learn is how to block an override

2. Any user can accept blocked overrides when generated and commit the record thus moving it into INAU status

3. To block an override in other words is to restrict access to particular users when it comes to authorising a record with this override

4. 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, you must use the OVERRIDE.CLASS field in the USER application. This field accepts any string data. The relationship of this data entered here and the override is clearly visible from the screen shots.

The override record has been modified to include the user class details thus making it a blocked override.

The user TRAINEE1 can now authorise the record which generated the ACCT.UNAUTH.OD override.

You will now learn more uses of the fields APPLICATION and CLASS in the OVERRIDE application.

Application : Specify a * to denote, irrespective of the application from which this override is generated, only users with Class TRG in their User profile can accept the override.

You can also specify Class Application wise. For example, if the Override is generated in the FUNDS.TRANSFER application, then only users with Class TEM in their User profiles can accept it.

Class : This field specifies a group name. Users belonging to this group alone will be able to approve this override. Class name can be any descriptive text. Maximum of four characters only. The group name specified in this field should be attached in the User profiles in the field ‘Override Class’.

Note that the user Chaitanya is not attached to the class TRG.

Now login as the user Chaitanya and input an FT transaction, accept the overrides and commit the record. Open it in SEE mode and see the filed Override.3 being suffixed with *. TRG which implies that only a user belonging to the class TRG can authorize the record.

Note that the user CHAITANYA1 is not attached to the class TRG.

Now login as CHAITANYA1 and authorize the record. You will see the message ‘YOU CANNOT APPROVE ALL OVERRIDES’. This is because, the user who tried to authorize the record is not one among the class specified in OVERRIDE application.

You can see the record status has gone to INAO. Only users with the field Override class set to ‘TRG’ in the user profile can authorize the record.

Note that the user TRAINEE1 is attached to the class TRG.

Now login as TRAINEE1 and authorize the same FT record. Open the record in SEE mode and check for the field Override.3 being suffixed with ‘*TRG*TRAINEE1_OFS_BROWSERTC’

TRG is the Class name.

TRAINEE1 resembles the name of the user who has approved the override.

OFS_BROWSERTC denotes that the record has been authorized from Browser frontend.

Note that the field Authorizer still holds the user CHAITANYA1 and does not change to TRAINEE1.

Now what if you login as TRAINEE1 who belongs to the class TRG, and input a FUNDS.TRANSFER transaction and commits it?

Open the record input by TRAINEE1 in SEE mode and look at the value in the Override field suffixed with *TRG*I which implies that the user belonging to the class ‘TRG’ has only input the record. In such a case, since TRAINEE1 has only input the record, any other user who does not belong to the class also can authorize the record.

Now what if you login as TRAINEE1 who belongs to the class TRG, and input a FUNDS.TRANSFER transaction and commits it?

Open the record input by TRAINEE1 in SEE mode and look at the value in the Override field suffixed with *TRG*I which implies that the user belonging to the class ‘TRG’ has only input the record. In such a case, since TRAINEE1 has only input the record, any other user who does not belong to the class also can authorize the record.

1. There might be many such cases in a Bank that a simple Class restrictions may not be sufficient

2. What if there is a need to restrict access to authorize the record which has a specific value?

Using an illustration you will learn how to block overrides based on conditions.

1. When an unauthorized overdraft override message is generated in T24, only the following users should be able to approve the override based on the following conditions

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

Table Row 2 : Only the user ACCTOFF2 can approve the override if the currency is USD and the overdraft amount is in the range one to 10000

3. Manager classification

Table Row 1 : Only the user MANAGER1 can approve the override if the currency is USD and the overdraft amount is in the range 10001 to 50000

Table Row 2 : Only the user MANAGER2 can approve the override if the currency is USD and the overdraft amount is in the range 10001 to 50000

4. GM classification

Table Row 1 : Only the user GENMGR1 can approve the override if the overdraft amount is in the range 50001 to 1000000

To set the multiple level restrictions to approve an override you have to use the application OVERRIDE.CLASS.DETAILS. You can set different groups who can approve overrides only if the conditions specified in their groups are satisfied.

Data Def : This field refers to the & values in the override message. ACCT.UNAUTH.OD is the Override in which &1 refers to Currency, &2 refers to Amount and &3 refers to Account. In this example, conditions are specific to only Currency and Amount and hence only &1 and &2 are defined.

Classification to Data To field is a multi value set.

Data Def No to Data To field is a sub value set.

Classification : This field holds any user defined text that best defines the group classification.

Data Def No. : This field indicates which data item, as defined in the field DATA DEF is to be used for the classification.

The number in this field identifies which multi-value from the field DATA DEF is to be referred. For example, the number '1' indicates that it is the data item defined by field DATA DEF.1 and the number '2' indicates that it is the content of field DATA DEF.2 . You can also define one DATA DEF and use it for all the classifications.

Comparison : It refers the operand to be used. Must select the valid operand you would want to use for comparison. This field can be left without any input also. Different operands available are

EQ which resembles Equal To , GE resembles Greater than or Equal To,

GT resembles Greater than, LE resembles Lesser thank or Equal To,

LT resembles Lesser than, NE resembles Not Equal To,

LK resembles Like, NR resembles Out of range,

RG resembles the range, UL resembles Unlike.

Data From : This field holds the value indicated in the field DATA DEF (according to the field DATA DEF NO), is compared against the value in this field according to the operator in the field COMPARISON. If the outcome of the comparison is true, the corresponding CLASSIFICATION group will be allocated the override.

DATA.TO : This field holds the end value of a range.

When the override message is raised from the application FUNDS.TRANSFER, the conditions specified in the record TRAINING in the OVERRIDE.CLASS.DETAILS application will be checked and appropriately validated.

If the override message is raised for an amount which is beyond the amount specified in OVERRIDE.CLASS.DETAILS then only the users who belong to the class TRG can approve the override.

When the override message is generated for applications other than FUNDS.TRANSFER (Denoted using a *), users with the field Override Class set to TRG in their user profiles will be able to approve the override.

Specify the value given in the field CLASSIFICATION (first multi value set) in OVERRIDE.CLASS.DETAILS and in the field OVERRIDE CLASS in the User profiles of ACCTOFF1 and ACCTOFF2.

Specify the value given in the field CLASSIFICATION (second multi value set) in OVERRIDE.CLASS.DETAILS and in the field OVERRIDE CLASS in the User profiles of MANAGER1 and MANAGER2.

Specify the value given in the field CLASSIFICATION (third multi value set) in OVERRIDE.CLASS.DETAILS and in the field OVERRIDE CLASS in the User profiles of GENMGR1.

Login to T24 as any user and input a FT debiting an account with nil balance with USD 9000.

Login as ACCTOFF1/ACCTOFF2 and authorize the FT.

In this demo, you will learn how to set simple multi level restrictions to approve overrides in T24.

End of demonstration Multi Level Restriction I.

1. Login as any user and input an FT debiting an account with nil balance with USD 10400

2. Login as ACCTOFF1/ACCTOFF2 and authorize the FT

3. Note that the record status is INAO as ACCTOFF1 does not have the privileges to authorize transactions with overdraft amount beyond USD 9000

4. Login as MANAGER1 and authorize the record

5. The authorizer field will still show value of ACCTOFF1 only as initially the record was authorized by the user ACCTOFF1

In this demo, you will learn how the record moves from INAU to INAO to LIVE status when authorized by users who do not have enough permissions to approve overrides.

End of demonstration Multi Level Restriction II.

1. Login as any user and input a FT debiting an account with nil balance with USD 51000

2. If ACCTOFF1/ACCTOFF2/MANAGER1/MANAGER2 login and try to authorize the record, the record will go to INAO status

3. Only user GENMGR1 will be able to approve the override and authorize the record

In this demo, you will learn how to set multi level restrictions to approve overrides and try to authorize the record with different users in T24.

End of demonstration Multi Level Restriction III.

1. Login as any user and input an FT debiting an account with nil balance with USD 2000000

2. Note that the Override message is suffixed with *TRG

3. Since the overdraft amount does not fall into any of the ranges defined in the OVERRIDE.CLASS.DETAILS application, the default class TRG defined for FT has been used

4. Therefore, this override can be approved only by users who have class set to TRG in their User profile

In this demo, you will learn how to any T24 user can approve overrides which do not fall under the amount which are set in OVERRIDE.CLASS.DETAILS.

End of demonstration Multi Level Restriction IV.

T24 always checks for conditions in the order specified in the OVERRIDE.CLASS.DETAILS record.

For example, If an FT is input and the overdraft amount is 9000, the override message will always appear as <Override Message>* ACOF.

A user with MGR override class set will not be able to approve the above mentioned override.

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. If yes, approval is possible, else, record will got to INAO status.

Logically a user with MGR override class set should be able to approve an override of 9000 USD. To get this done, you need to add ‘ACOF’ apart from the ‘MGR’ class in the user profile of MANAGER1 and MANAGER2.

1. Amend the ACCT.UNAUTH.OD override to allow only the following users to approve the override.

2. Create the necessary users

3. Default class to be used is TRG

4. Two trainees to form a group

The first group needs to create a record in OVERRIDE.CLASS.DETAILS application. The ID should be TEMENOS.TRG. The first group to create the record and add in details appropriate to GRP1. Once done, GRP2 needs to edit the record ‘TEMENOS.TRG’ and input appropriate details. Then, record passes on to GRP3 and so on. GRP10 to link the OVERRIDE.CLASS.DETAILS record to OVERRIDE application. All groups will then have to create new accounts and input FTs debiting the account and check override processing.

You are now familiar with the concept of override processing in T24. Can an override message be triggered as an error in T24?

The answer is yes. The field TYPE in OVERRIDE application has the following options – Error, Auto, Message and Warning. When TYPE is set to Error, the override message becomes an error. When TYPE is

set to Auto, the override message will be automatically accepted by T24 , the user acceptance is not required.

You will not be allowed to commit the record when an error is raised in T24.

In the previous example, the override was displayed as an error message. Now can you display customised error messages for overrides?

To display customised error messages for overrides, create a record in EB.ERROR application. The message is specified in the field ERROR.MSG.

The above created record should be attached to the OVERRIDE application in the field MESSAGE.

When the override is triggered in a transaction, you could see the customised error message displayed.

1. Can you simply create a new Override without any hassels?

2. No. OVERRIDE is one of the core applications in T24. It is not possible to simply create a new record in OVERRIDE application and let it to populate for any records in any applications. Only TEMENOS DEVELOPMENT can do it. However Client customization is possible but is not as simple as creating any record in OVERRIDE application. All the override messages to be generated should be defined in the OVERRIDE application in T24

For example, When T24 wishes to raise an override stating that a particular account has been over drawn, it will only say that an override ACCT.UNAUTH.OD needs to be raised. T24 core then picks up the actual message from the field GB Message in OVERRIDE application and displays it.

DISPO PROCESSING:

After completing this learning unit, you will be able to:

Differentiate between blocking and non blocking overrides

Explain the use of the following applications - OVERRIDE, DISPO.ITEMS, DISPO.OFFICER

Create DISPO Officers in T24

Explain the process DISPO Processing has on overrides

Explain the use of enquiries DISPO.DETAILS and DISPO.SUMMARY

Differentiate partial and full DISPO processing

Sometimes when committing a transaction in T24, one or more warning messages are generated. These messages are called Overrides.

2.There can be two different types of override messages. They are Non Blocking and Blocking overrides.

2.1 A record which generates non blocking overrides can be authorized by any user in T24.

2.2 A record which generates blocking overrides can be authorized only by users with appropriate privileges. If you do not have sufficient privileges the record will go to INAO (Input Not Approved due to Override) status.

By default, all overrides in T24 are Non Blocking in nature.

Teaching you how to block and un-block overrides are not in the scope of this learning unit.

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.CLASS.DETAILS

However, you can also achieve this using DISPO Processing.

What is DISPO Processing? An example will make this clear.

Tom wants to transfer funds from his account to Tim’s account. The T24 way to do this is by using the application FUNDS.TRANSFER. What if Tom’s account does not have enough funds? Will the transaction abort? No.

T24 will allow him to perform the transaction by overdrawing his account. The system will raise an override on committing the transaction, telling the T24 user that Tom’s account does not have enough funds and is being overdrawn.

What if the bank wants to set a limit on the amount of overdraft that a particular user can authorize?

Even though this can be achieved using OVERRIDE.CLASS.DETAILS, Dispo Processing allows you to do this with extra options.

1. The same override can be generated by any application depending upon business requirement. The Override ACCT.UNAUTH.OD, is raised by many applications like FUNDS.TRANSFER, LD.LOANS.AND.DEPOSITS etc., the applications that involve an account in the transactions.

2. 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’, in the Override record.

In the override record, you have to specify a valid DISPO Officer ID in the field DISPO.OFFICER

Now that you have done the base work, will it be feasible if any T24 user can view the records in DISPO.ITEMS and approve or reject or comment it?

If this is done than the whole idea of DISPO Processing is in vain.

To control such a situation, you need to assign a DISPO Officer to a particular user in the USER application. The field DISPO.OFFICER is used to assign the Officer. The input in this field should be a valid officer defined in DISPO.OFFICER application.

DISPO Officer is the one of the important fields in the DISPO.ITEMS application. DISPO Officer has the right to approve or reject or comment on DISPO Items

A DISPO officer can be created using the DISPO.OFFICER application

ID : The ID of a record can be any alphanumeric input

SHORT.TITLE : This is a multi lingual field which holds the description for the DISPO officer in different languages

OVERRIDE.ID : This field holds the ID of an override record, for which DISPO processing has been enabled. This is a multi value field and will hold all the override IDs that this officer will deal with

DISPO.AMOUNT : This field holds the amount up to which the Officer can comment on an override

OVERDRAFT.AMT : This field holds the amount up to which the Officer can approve or reject an override

OVERDRAFT.AMT should be less than or equal to DISPO.AMOUNT

NEXT.DISPO.OFF : This field holds the ID of the next level Officer for financial Overrides, to whom the DISPO Item would be assigned, in case the current Officer does not have privileges to approve an override

When a particular DISPO Officer is not available for a specific time, you can set an alternate DISPO Officer who will be acting like the actual Officer for the specified time.

ROUTE.TO : This field holds the ID of the DISPO Officer to whom the DISPO items should be routed for the dates and times specified in the DATE.FROM, DATE.TO, TIME.FROM, TIME.TO fields. Only if this field contains a valid DISPO Officer ID, the other fields like DATE.FROM, DATE.TO, TIME.FROM, TIME.TO will be input able. Otherwise all these fields are no input fields.

DATE.FROM : This field holds the date from which the DISPO Item should be routed to the alternate DISPO Officer

DATE TO : This field holds the date till which the DISPO Item should be routed to the alternate DISPO Officer

TIME FROM : This field holds the starting time on a day from which a particular DISPO item should be routed to the alternate DISPO Officer.

TIME TO : This field holds the ending time on a day till which a particular DISPO item should be routed to the alternate DISPO Officer.

Whenever an override, that has been subject to DISPO Processing, is accepted in a transaction, a record is created in an application called DISPO.ITEMS

User inputs an FT transaction. When the user accepts the override message generated, the transaction is complete and the record goes to INAU status. At this stage a record in DISPO.ITEMS is created.

A record in DISPO.ITEMS is created internally by the system only when the transaction generating the override enabled for dispo is committed. The record ID is TransactionID*CompanyMnemonic.

Example : FT08009436R9*BNK

APPLICATION : This field holds the application name by which the override has been generated.

OVERRIDE.TEXT : This field holds the actual override message as generated in the transaction.

CURRENCY : This field holds the currency of the account which has been debited in the transaction.

AMOUNT : This field holds the total amount overdrawn on the debited account.

ACCOUNT.OFFICER : This field holds the ID of the account officer responsible for the account.

DATE and TIME : These fields hold the date and the time in which the override was raised in the transaction .

CUSTOMER.NO : This field holds the ID of the customer who holds the account.

OVERRIDE.ID : This field holds the ID of the override record that is generated.

ACCOUNT.NO : This field holds the debit account number.

In the OVERRIDE record, ACCT.UNAUTH.OD, set the field DISPO.OFFICER to 101.

In the DISPO.OFFICER record with ID 101 set the ROUTE.TO field 102. This means that the DISPO item should actually be approved or rejected or commented upon by DISPO officer 101, however since he is not available the item will be assigned to DISPO Officer 102.

Input an FT transaction, accept the overrides and commit the record. A record in DISPO.ITEMS should have been created with ID as TransactionID * Company mnemonic. Now open the record in the DISPO.ITEMS application and check for the fields DISPO.OFFICER and COMMENT.OFFICER.

You will note that both these fields are defaulted to officer 102 and not 101 though the amount falls under the officer 101 range. This is because, the ROUTE.TO field in the officer 101 record is set to officer 102 for 9th Jan from 10AM to 06PM, and the FT transaction was input and committed within this time frame.

DISPO.ITEMS is the application used to view the DISPO items. However, you can use an enquiry DISPO.DETAILS to

view the items specific to an officer.

2. Enquiry DISPO.SUMMARY can be used to view all the pending DISPO items for approval.

3. You have been hearing the words approve, reject, comment a DISPO item all through the course. Can you simply open a record in DISPO.ITEMS and authorize it? The system will not allow you to do so. You can perform this action only by using the enquiry DISPO.SUMMARY or DISPO.DETAILS.

Try authorizing a DISPO item. The system will not allow you to do so. This is because, the record status is INAU. To authorize a DISPO item, the record should be in INAO status. Try to authorize the record with a user who is not assigned an appropriate DISPO officer and then check the record status. The record will now be in INAO status and is ready for authorizing or rejecting or commenting.

4. Only a user who is assigned a DISPO officer can open the record in see mode. However, a user who is not assigned any DISPO officer can still list the DISPO items. Also remember, user with an appropriate DISPO officer can only approve or reject or comment an item with in his limits defined in the DISPO.OFFICER application.

Whenever an override, that has been subject to DISPO Processing, is accepted in a transaction, a record is created in an application called DISPO.ITEMS

User inputs an FT transaction. When the user accepts the override message generated, the transaction is complete and the record goes to INAU status. At this stage a record in DISPO.ITEMS is created.

Open the item and note that the fields DISPO.OFFICER and COMMENT.OFFICER are defaulted to officer 100 as the transaction amount falls in his approval limits.

Login as another user who do not have the DISPO officer set and try authorizing the FT record.

Login as the user who has appropriate DISPO authorities and approve the DISPO item. Open the enquiry DISPO.DETAILS for the officer – 100. All the DISPO items available for the officer 100 are displayed. Click on the button ‘ADD COMMENT’ to either approve or reject or comment the item. After the record is open, approve it and commit the record. Now you should be able to authorize the corresponding FT record. The transaction is complete and the FT is authorized by the appropriate DISPO officer. If the DISPO officer reject the DISPO item, then you will not be able to authorize the FT transaction.

The record is in live status

Enquiry DISPO.SUMMARY will display all the records enabled for DISPO processing for all the DISPO officers. If the user has sufficient privileges, he can add the required comments, approve or reject the DISPO item. All the comments made are recorded in the DISPO.ITEMS record.

Enquiry DISPO.SUMMARY will display all the records enabled for DISPO processing for all the DISPO officers. If the user has sufficient privileges, he can add the required comments, approve or reject the DISPO item. All the comments made are recorded in the DISPO.ITEMS record.

Officers can either comment or approve or reject based on the amount involved in the override generated by a transaction.

1. The amount up to which an Officer can comment on an override is given in the field DISPO.AMOUNT and the amount up to which an Officer can approve or reject an override is in the field OVERDRAFT.AMOUNT in DISPO.OFFICER application.

2. The officer who can comment an override is the COMMENT.OFFICER and the officer who can approve or reject the override is the DISPO.OFFICER

With reference to the table in the slide:

Table Column 1 holds the record IDs of DISPO Officers.

Table Column 2 holds the amount up to which an Officer can comment on.

Table Column 3 holds the amount up to which an Officer can approve or reject an override.

Table Column 4 holds the ID of a DISPO Officer who is the next level financial approver.

An example will make things clear.

The officer with ID 100 can comment on amounts lesser than or equal to 20,000 and can approve or reject overrides with overdraft amount lesser than or equal to 10,000. If this DISPO Officer cannot approve or reject overrides, then 101 is the next Officer who has privileges to approve or reject or comment on the override.

Illustration of the table.

When an FT transaction was input for 20,123, which falls under the officer 101, both the DISPO.OFFICER and COMMENT.OFFICER fields are populated with the respective officers in DISPO.ITEMS record. This implies that only officer 101 can comment and either approve or reject this override.

Now try answering the following questions. The transaction amount is 20,100.

1. No, because the limit to comment on is only 20,000

2. No, because the limit to approve is only 10,000

3. Officer 101 can do it, because his limit to approve/reject is up to 30,000

4. Officer 101 can do it, because his limit to comment on is 40,000

5. Officer 101

6. Officer 102

1. All that you have seen till now is partial DISPO processing. There is much more added functionality for DISPO processing

2. If DISPO field is set to ‘YES’, then DISPO processing can be enabled with limited features.

1. To enable an override for full DISPO processing, the field DISPO.ALLOWED in OVERRIDE application should be set to ‘YES’

2. DISPO.ALLOWED field is set at the core and cannot be modified by any user. The field DISPO should also be set to ‘YES’

3. If an override is enabled for full DISPO processing, then the fields PRECEDENCE, TRANSACTION.IND, CONDITION.CON in the OVERRIDE application can be used

4. You can also set the fields DISPO.AMOUNT and OVERDRAFT.AMT in DISPO.OFFICER application

1. Most of the overrides in T24 are stored in an application called OVERRIDE. The example which was discussed in the previous slide is a record in the OVERRIDE application with ID as ACCT.UNAUTH.OD. Based on the special certifications required for a transaction, DISPO Processing may or may not be allowed for an Override

2. To enable full DISPO Processing for an Override, the first step is to check if the field DISPO.ALLOWED is set to ‘YES’ in the OVERRIDE application. This field is set at the core which means whether or not an Override is allowed for DISPO is decided by Temenos and T24 user cannot modify this field

Now you should be able to differentiate that if the field DISPO.ALLOWED is set to ‘’ (NULL) and the field DISPO is set to ‘YES’, then the override is enabled for partial DISPO processing. If the field DISPO.ALLOWED is set to ‘YES’ and the field DISPO is set to ‘YES’, then the override is enabled for full DISPO processing

In the OVERRIDE application, the fields from APPLICATION to DISPO.OFFICER form a multi-value set. The fields CLASS and DETAIL are not to be used when an override is enabled for dispo processing. All the other fields are used for dispo processing. However, the fields CON.OVERRIDE, TRANSACTION.IND, PRECEDENCE can be used only if the field DISPO.ALLOWED is set to YES which implies that an override is enabled for full dispo processing.

1. A DISPO officer can be set in the CUSTOMER, ACCOUNT, POSTING.RESTRICT and LIMIT applications apart from the OVERRIDE application

2. If the field PRECEDENCE is set for an override, then the officer assigned in that particular application will take precedence over the officer set in the OVERRIDE application. When no officer is identified in the application, then the item will be assigned to the default officer specified in the override record

3. The value in this field must be input in the format ‘APPLICATION NAME>FIELD NAME FOR OFFICER IN THE APPLICATION’. Example : ACCOUNT>DISPO.OFFICER

To check the functionality of the field PRECEDENCE, set the DISPO.OFFICER field in ACCOUNT record - 35475 to a valid DISPO officer - 101. Open the record ACCT.UNAUTH.OD in the OVERRIDE application, and set the field PRECEDENCE as ACCOUNT>DISPO.OFFICER and in the field DISPO.OFFICER, set an officer other than the one set in the ACCOUNT record - 100. Attach the officer 101 in the field DISPO.OFFICER in a user record. Input an FT transaction by debiting the account 35475. Accept the overrides and view the transaction in DISPO.ITEMS. Note that the fields DISPO.OFFICER and COMMENT.OFFICER are defaulted to 101 as set in the ACCOUNT record and not to 100 as set in the OVERRIDE record.

1. To disable DISPO processing for a transaction, the field TRANSACTION.IND should be set to ‘YES’

2. When an accounting entry is raised, a small description is given about the transaction which is called as ‘NARRATION’. T24 describes different types of transactions in an application called TRANSACTION. The ID of a record should be numeric and a maximum of three numbers. For example, record 213 is used for ‘TRANSFER’, 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.IND, the first step is to open an FT record, and note the statement number generated for the transaction. Open the corresponding STMT.ENTRY record and note the value in the field TRANSACTION.CODE - 213. Now view the record - 213 in the TRANSACTION application and note the field GB.NARRATIVE. Set the field DISPO.EXEMPT to ‘YES’. Set the field TRANSACTION.IND in the OVERRIDE application to ‘YES’. Input a new FT record with TRANSACTION.TYPE ‘AC’ as the transaction code is 213 and commit the record. Now try to view the same record in DISPO.ITEMS application. There will be no DISPO item for this transaction as you have exempted transaction type 213 from DISPO processing.

There will be no dispo item as you have enabled TRANSACTION.IND

In TRANSACTION application set the field DISPO.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.

It is also possible to exempt overrides generated for a particular ACCOUNT or CUSTOMER record from DISPO processing. This can be done by specifying the field DISPO.EXEMPT to ‘YES’ in a record in ACCOUNT or CUSTOMER application.

1. You can set conditional DISPO processing using the field CON.OVERRIDE which will hold the ID of another override

2. For the transaction to be enabled for DISPO processing, the actual override and the override specified in this field should be generated. If either of the overrides is generated, the transaction will not be subject to DISPO processing and will not have an entry in DISPO.ITEMS.

3. Both the overrides generated in the transaction will be subject to DISPO processing

To understand the functionality of the field CON.OVERRIDE, check out for override records which have the field DISPO.ALLOWED set to ‘YES’. Open the record LIMIT.UNAVAIL in the OVERRIDE application and set the field CON.OVERRIDE to ‘EXCESS.ID’ which is ID of an override record and is enabled for full DISPO processing. Check if both the records LIMIT.UNAVAIL and EXCESS.ID has the field DISPO.ALLOWED set to ‘YES’ and DISPO.OFFICER set to the same officer – 105. In the record 105 in DISPO.OFFICER application, add both the override IDs. Input a new LD record and note that both the overrides are generated. Accept the overrides and commit the transaction. Now view the record in DISPO.ITEMS. Note that both the overrides generated are recorded in the DISPO item. Input another LD record and validate the transaction. Note that only one override has been generated for this record. Accept the overrides and commit the record. Copy the record ID and check if there is any DISPO item for this transaction. There will not be any DISPO item as the LD has generated only one override and therefore the transaction is not enabled for DISPO processing.

No dispo item will be found which matches the ID, as this record has generated only one override and is therefore not enabled for dispo processing

1. The field DISPO should be set to ‘YES’ and the field DISPO.ALLOWED to ‘’ (NULL) to enable partial DISPO processing. The field DISPO.ALLOWED should be set to ‘YES’ along with the field DISPO set to ‘YES’ for full DISPO processing. If an override is enabled for partial DISPO processing, then the fields PRECEDENCE, TRANSACTION.IND, CONDITION.CON in the OVERRIDE application cannot be used. You cannot set the fields DISPO.AMOUNT and OVERDRAFT.AMT in DISPO.OFFICER application

2. Create Officers using DISPO.OFFICER application

3. Set up the override record with all the required options

4. If the PRECEDENCE field is set, then set the DISPO.OFFICER field in the appropriate application

5. Assign the DISPO officers to USER profiles

6. 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. Create an account

2. Ask the trainer to modify ACCT.UNAUTH.OD in your training area with precedence set as ACCOUNT>DISPO.OFFICER

3. Create a DISPO.OFFICER record with your name

4. Attach the Officer to a new USER profile

5. Log in as another user, enter an FT

6. Authorize the FT, transaction will go to INAO

7. Log in as the USER to whose account the DISPO.OFFICER is attached

8. Open the Dispo Item assigned to you

9. Authorize the Override

After completing this learning unit, 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, it is possible that you come across two types of messages.

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.

In case of Error Messages, you need to correct the data input in the particular fields and commit the transaction again.

A record is not saved till all errors are corrected. You cannot even put the record on hold.

Override Messages: These are warning messages, at least most of the time. User has only one option to Accept Overrides. If accepted, T24 saves the record and the override message is stored as part of it in the field OVERRIDE. If you do not want to accept the Override, you may either put the record on hold to correct it later or amend the record and commit it again.

1. Constraint means limitation or restriction.

2. From a T24 perspective, constraints are a set of conditions on transactions to prevent certain activities.

3. One can either enable or disable constraint processing in T24

1. Have you ever been able to generate an override message for a condition of your choice?

2. Have you ever been able to generate an error message for a condition of your choice?

At this point you may be thinking if you really can generate errors and overrides for a condition of your choice in T24.

T24 allows you to create errors and overrides for custom defined conditions using the Constraint Processing.

Constraint Processing may or may not be enabled at different levels in T24. Different applications are used to set this at different levels.

The application EB.GC.PARAMETER is used to enable constraint processing for all the companies in a T24 set up. The ID should be ‘SYSTEM’

The application EB.GC.PARAMETER is used to enable constraint processing for a specific company. The ID should be <COMPANY CODE>. Eg.: GB0010001

The application EB.GC.ACTIVE is used to enable constraint processing for a specific application in T24. The ID should be <APPLICATION NAME>. Eg.: FUNDS.TRANSFER

The field COM.PROCESSING in EB.GC.PARAMETER decides whether or not constraint processing is enabled for a specific company or for all companies. If this field is set to ‘NO’, then constraint processing is disabled and if set to ‘YES’ constraint processing is enabled

EB.GC.PARAMETER can have two types of records. The ID of the record may be ‘SYSTEM’ or <COMPANY CODE> Eg.: GB0010001

Values set at the global level (in the SYSTEM record) will be overridden by the values set in the records created for specific company.

EB.GC.ACTIVE is a FIN type file and the values that are set here are company specific. This application is used to disable or enable constraint processing for a particular application. The ID of the record should be <APPLICATION NAME> Eg. LD.LOANS.AND.DEPOSITS. The field APP.PROCESSING should be set to ‘YES’ to enable or ‘NO’ to disable constraint processing.

The following is the order of precedence in setting up constraint processing

Application level (EB.GC.ACTIVE)

Company level (EB.GC.PARAMETER record with ID as <COMPANY CODE>)

Global level (EB.GC.PARAMETER record with ID as ‘SYSTEM’)

For example, if the field COM.PROCESSING in the records ‘SYSTEM’ and ‘GB0010001’ is set to ‘NO’ in the EB.GC.PARAMETER table and if the field APP.PROCESSING in the record LD.LOANS.AND.DEPOSITS is set to ‘YES’ in the application EB.GC.ACTIVE (in GB0010001 company), then constraint processing is still enabled for the application LD.LOANS.AND.DEPOSITS.

What could be the next step after constraint processing is enabled for an application?

The next step to do after an application is enabled for constraint processing is to define the conditions and the message to be generated. This can be achieved through EB.GC.CONSTRAINTS. The ID should be the application name. Eg.: LD.LOANS.AND.DEPOSITS.

TEST.FIELD : This field holds a valid field from the respective application (record ID is the application name). Eg.:The value in this field is given as INTEREST.RATE which is a valid field in the application LD.LOANS.AND.DEPOSITS.

T24 performs a validation check on this field. If a wrong field name from the application is entered, an error is thrown at the user.

OPERAND : This field holds the operand against which a condition is generated.

EVAL.VALUE : This field holds the value or set of values for comparison against which an override or an error is generated.

SEPERATOR : This field holds the separator to be used for the values mentioned in the field EVAL.VALUE

ERROR.OVERRIDE : This field holds the type of message to be generated, either an override or an error.

NARRATIVE : This field holds the actual message to be generated as an error or override.

FIRST.VALID.DATE : This field holds the value date from which the constraint becomes active. The date in this field should be current date or a date greater than today.

You are now ready to generate the override set in constraint processing. Input an LD record with the value in the field INTEREST.RATE greater than five.

Note that the overrides set by the core and the overrides set in constraint processing are generated. The value given in the field NARRATIVE in the LD.LOANS.AND.DEPOSITS record in the EB.GC.CONSTRAINTS application is generated as the override.

An override ‘Debit Amount is less than 100000’ needs to be generated when a record in the FUNDS.TRANSFER application is committed with the field DEBIT.AMOUNT set to a value less than 100000

Now that you know how to generate an override, you can generate an error message also. Give the conditions for an application (Eg.:FUNDS.TRANSFER) in the EB.GC.CONSTRAINTS application. To generate a message as an error, set the field ERROR.OVERRIDE to ‘ERROR’.

Eg.: If a record is committed in the FT application, an error should be generated if the field TRANSACTION.TYPE is not equal to ‘AC’.

Note that the error message is generated as it is given in the field NARRATIVE in EB.GC.CONSTRAINTS application when the field TRANSACTION.TYPE is not set to AC in FUNDS.TRANSFER application.

An error ‘DEBIT CURRENCY SHOULD BE USD’ needs to be generated when a record in the FUNDS.TRANSFER application is committed if the field DEBIT.CURRENCY has a value other than USD

What if you wish to generate same errors or overrides for different applications?

Eg.: When contracts are input in applications such as LD, MM and FT, if the loan amount or deposit amount or debit amount transacted is greater than 200000, an error message “Amount should be less than 200000’ needs to be generated.

You could simply create three records in EB.GC.ACTIVE and EB.GC.CONSTRAINTS (one for each application) and set appropriate conditions for the specific fields. 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. So then what else can you do to accomplish this setting?

1. T24 has the functionality to generate the same error or override message for multiple applications, based on specific fields

2. Grouping users is done to set same set of privileges for a group of users in USER.SMS.GROUP. Grouping applications for constraint processing is similar to that

3. To group applications that generate same error or override, EB.GC.GLOBAL is used

EB.GC.GLOBAL is the application in which all the application names and their respective fields for which you wish to check the condition and raise the same override or error are stored. The ID of the record in EB.GC.GLOBAL can be any user defined value. Eg.: ABCD, FT, 1235, TOM, etc..

APPLICATION : This is a multi value field which specifies the application name for which the override or error has to be generated

TARGET.FIELD : The field holds the field name from the application mentioned in the previous field for which the condition has to be checked.

Both these fields form a associated multi value set.

Even before you set up the record, the applications that are to be used in EB.GC.GLOBAL should be enabled for constraint processing. As you know by now, this can be achieved by using the application EB.GC.ACTIVE.

Eg.: The field DEBIT.AMOUNT in FUNDS.TRANSFER, the field AMOUNT in LD.LOANS.AND.DEPOSITS and the field PRINCIPAL in MM.MONEY.MARKET should generate an error message if the respective fields holds a value greater than 200000

After the applications are grouped in EB.GC.GLOBAL, a record in EB.GC.CONSTRAINTS is to be created with ID set to GLOBAL. When there are multiple applications involved in constraint processing, the ID of the record in EB.GC.CONSTRAINTS should be ‘GLOBAL’. If only one application is involved, the ID is the application name itself.

The field TEST.FIELD should contain a field name of the application which is the ID of the record in EB.GC.CONSTRAINTS application. What will you specify in this field if the ID is set to ‘GLOBAL’?

In the record ‘GLOBAL’ the field TEST.FIELD should hold the ID of the record (in which the applications are grouped) from EB.GC.GLOBAL application.

1. An application can have two constraints defined in EB.GC.CONSTRAINTS

If you recollect the example you have seen in the earlier slides, the applications LD.LOANS.AND.DEPOSITS and FUNDS.TRANSFER have application specific records in EB.GC.CONSTRAINTS. The conditions were - If interest rate is greater than 5%, an override to be raised and if TRANSACTION.TYPE is not AC, an error to be raised respectively.

You have also set the group which is a part of the record ‘GLOBAL’ in EB.GC.CONSTRAINTS application in which LD, FT and MM are included. The constraint set for this record is - If amount is greater than 200000, then an override is to be raised.

2. Will the conditions set in the application specific records as well as the conditions set in the GLOBAL record be executed for LD and FT? Yes. If both the conditions are executed, then this is known as Cumulative constraint processing.

3. Can you specify that the conditions specified in application specific records alone should be executed for LD and FT? Yes. This is known as Single constraint processing.

The field COM.METHOD in EB.GC.PARAMETER and the field APP.METHOD in EB.GC.ACTIVE are the ones which decide whether or not a company or an application is enabled for ‘SINGLE’ or ‘CUMULATIVE’ constraint processing.

A value SINGLE denotes that only one constraint can be applied.

If an application has constraints set up in the application specific record as well as GLOBAL record in EB.GC.CONSTRAINTS, which constraint takes the precedence if the field APP.METHOD is set to SINGLE?

The constraint which is defined in the application specific record in EB.GC.CONSTRAINTS takes the precedence and only the error or override stored in this record can be generated.

A value CUMULATIVE denotes that multiple constraints can be applied.

If an application has constraints set up in the application specific record as well as GLOBAL record in EB.GC.CONSTRAINTS, then, both constraints will be generated.

The value set in the field APP.METHOD in EB.GC.ACTIVE takes precedence over the value set in the field COM.METHOD in EB.GC.PARAMETER application.

Since CUMULATIVE processing is enabled for FT, constraint set for the application as well as the constraint set in the GLOBAL record are executed.

Since SINGLE processing is enabled for LD, only the constraint set for the application in the application specific record is executed.

Note that though the value in the amount field is greater than 200000, an error is not generated but the application specific override is generated as the field APP.METHOD in LD record in EB.GC.ACTIVE is set to SINGLE and the application level setting takes the precedence.

Since CUMULATIVE processing is enabled for MM, constraint set in the GLOBAL record is only executed as it does not have a constraint set in the application record.

When contracts are input in applications such as LD.LOANS.AND.DEPOSITS, MM.MONEY.MARKET and FUNDS.TRANSFER, if the fields CURRENCY and DEBIT.CURRENCY is not equal to USD, an error message ‘CURRENCY SHOULD BE USD’ is to be generated

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

Eg.: When contracts are input in LD application by the user CHAITANYA, she should only be allowed to use a value 21051 in CATEGORY field. If she inputs any other value other than 21051 , an error ‘CATEGORY SHOULD BE 21051’ is to be generated.

This is almost similar to setting up a group in EB.GC.GLOBAL

To set constraint for a specific user, create a record in EB.GC.GLOBAL with ID as any text and specify the application and the field name against which condition is to be set.

Eg.: USER is the record ID in EB.GC.GLOBAL

After creating the record in EB.GC.GLOBAL, a record in EB.GC.CONSTRAINTS is to be created with ID set to GLOBAL/////<USER NAME>. Use five forward slashes in between. Eg.: GLOBAL/////CHAITANYA

As you already know, the field TEST.FIELD should hold the ID of the record (created for user specific constraint) from EB.GC.GLOBAL application. The other fields should hold the conditions and the error message to be generated.

The actual expansion of the ID in EB.GC.CONSTRAINTS is GLOBAL/CUSTOMER/PORTFOLIO/ACCOUNT/CURRENCY/USER which means that you can also set conditions specific to a customer, an account, etc.,.

If you recollect the constraints set for LD.LOANS.AND.DEPOSITS, it has application specific record, record with ID as GLOBAL and a user specific record in EB.GC.CONSTRAINTS. The constraints were - If interest rate is greater than 5%, an override to be raised ; If amount is greater than 200000, an override to be raised and If category is not equal to 21051, an error message to be raised.

If the field APP.METHOD is set to SINGLE, then the user specific constraints are only executed. One important thing to note here is the order of precedence for constraints to be executed. User specific constraint is to be executed first, application specific constraint is the second and group specific constraint is the last.

Eg.: When a contract is input in LD with AMOUNT set to 300000 CATEGORY set to 21052 and INTEREST.RATE set to 9%, only one error for the field CATEGORY is raised and no other constraints are executed as LD enables only SINGLE constraint processing.

As you know if you set the field APP.METHOD in EB.GC.ACTIVE for LD to CUMULATIVE, all the constraints will be enabled for a contract if it is input by this specific user. If any other user inputs the contract, then the constraint pertaining to the field CATEGORY will not be executed as it is user specific.

User should only be allowed to input ‘EUR’ in the field DEBIT.CURRENCY in FT application. 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.GC.CONSTRAINTS can be created specific to a user, an account, a customer, etc.,. Now if there are different specific conditions defined in this application for a customer, portfolio, account, currency and user which means different specific records created and if the constraint processing is set to single for the company, then which constraint will take the precedence? How will you control the precedence in such a scenario?

To overcome this, there are a set of fields in EB.GC.PARAMETER which controls the precedence of constraints when single constraint processing is enabled. The fields PRECEDENCE.USER, PRECEDENCE.CURR, PRECEDENCE.ACCT, PRECEDENCE.PORT and PRECEDENCE.CUST will define the order of precedence. These fields can hold a value from one to five. A value of one in any of the fields means that, this specific constraints takes the precedence over the other.

You can achieve this by creating another record in EB.GC.GLOBAL with the required applications and relevant fields, attach the ID of this record in the field TEST.FIELD and specify other conditions in EB.GC.CONSTRAINTS. This is similar to what you have already done.

However, you can also achieve this by using another application EB.GC.GROUP

Normal way of achieving this grouping is to create a record with the required applications (which were already a part of the group) in EB.GC.GLOBAL, and attach it in EB.GC.CONSTRAINTS application with the condition.

Eg.: Create another group for LD and FT with their relevant fields, with ID set to CURRENCY. Attach this ID in the record GLOBAL in EB.GC.CONSTRAINTS.

To create a subgroup use the application EB.GC.GROUP. ID of the record can be text.

APPLICATION : This is a multi value field which specifies the list of applications which are members of this subgroup. Only the applications which have a record in EB.GC.ACTIVE can be input in this application.

Eg.: Generate an error ’CURRENCY MUST BE USD’ for the applications LD and FT if the currency used is not equal to USD

As soon as a record is created and authorized in EB.GC.GROUP, the field GROUP is updated with the ID of the subgroup record in the corresponding record in EB.GC.ACTIVE application.

GROUP : This is multi value field and is not inputtable by the user. This field holds the ID of the records in EB.GC.GROUP

Create a record in EB.GC.GLOBAL with the required applications and their relevant fields. Create a record in EB.GC.CONSTRAINTS whose ID is the same as the ID in EB.GC.GROUP. Attach the ID of the record created in EB.GC.GLOBAL in the field TEST.FIELD in EB.GC.CONSTRAINTS application and specify the relevant conditions.

Eg.: The field DEBIT.CURRENCY and CURRENCY in FT and LD should be USD. Otherwise, an error should be thrown.

Take a look at the records. In both FT and LD the error ‘CURRENCY MUST BE USD’ is raised.

As the field APP.METHOD is set to SINGLE in EB.GC.ACTIVE, in FT, error is raised for DEBIT.AMOUNT field as the value in this field should be less than 200000.

For applications MM.MONEY.MARKET and FUNDS.TRANSFER, the fields CURRENCY and CREDIT.CURRENCY respectively should accept only EUR. Otherwise an error ‘CURRENCY NOT EQUAL TO EUR’ should be raised.

Use EB.GC.GROUP application to achieve this.

For applications MM.MONEY.MARKET and FUNDS.TRANSFER, the fields CURRENCY and CREDIT.CURRENCY respectively should accept only EUR. Otherwise an error ‘CURRENCY NOT EQUAL TO EUR’ should be raised.

Use EB.GC.GROUP application to achieve this.

How can an override generated by constraint processing be made a blocking override?

Eg.: When a credit account with currency other than USD is input in a FT transaction, an override message ‘CREDIT CURRENCY IS NOT USD’ needs to be raised. This override should only be approved by user belonging to a particular class.

The fields COM.DIAG and APP.DIAG can hold the value ‘YES’ or ‘NO’. A value ‘YES‘ denotes that diagnostics recording is enabled. This field decides whether or not the constraints are to be logged.

The field COM.DIAG.LIFE holds the number of days after which the logs should be deleted.

The settings in the field APP.DIAG in EB.GC.ACTIVE takes the precedence over the settings in the field COM.DIAG in EB.GC.PARAMETER application.

When the condition set for a particular field is breached or violated, the constraint is triggered. At this point, a log will be created in the file EB.GC.DIAGNOSTIC. This is a live file and updated by the system.

All the details of the constraint are stored in this record. The field DATE holds the date on which the log was entered and the field DEATH.DATE will hold a date which is equivalent to the date of the log + the number of days given in the field COM.DIAG.LIFE.

Eg.: If the log date is 7th August 2008 and the COM.DIAG.LIFE will hold a value of 8, then the death date will be 19th August 2008.

1. Who will actually delete the logs from the file EB.GC.DIAGNOSTIC and when?

A COB job named EB.GC.DIAGNOSTIC.COB deletes the log if the value in the field DEATH.DATE is less than today

2. EB.GC.DIAGNOSTIC.COB checks the field DEATH.DATE for all the records and if this is less than today, then the log record is deleted from the file.

3. The job EB.GC.DIAGNOSTIC.COB is a ‘D’ frequency job and is run daily.

Eg.: If the log date is 7th August 2008 and the COM.DIAG.LIFE will hold a value of 8, then the death date will be 19th August 2008. This record will be deleted from the file during COB on 20th August 2008. Note that only working days are calculated to arrive at death date.

1. T24 allows you to create override and error messages using the ‘Constraint Processing’

2. EB.GC.PARAMETER is used to enable constraint processing at company level or SYSTEM level

3. EB.GC.ACTIVE is used to enable constraint processing at application level

4. EB.GC.CONSTRAINTS application decides whether an error or override message has to be generated

5. EB.GC.GLOBAL allows constraints to be established at Global level across multiple applications

6. EB.GC.GROUP enables creation of sub groups