T24 Utilities.pdf

T24 UTILITIES

INTRODUCTION The previous generation of banking systems had fixed screen, menu and report designs that required considerable expense for even simple changes. However, when T24 was designed, great emphasis was placed on providing the client with the ability to customise their system as required. To this means the utilities were developed and are delivered as standard. All the utilities are documented in detail in the T24 System Administration and User Guides, as well as in the on-line helptext. In this section, these applications are highlighted to show the scope of customisation that can be achieved by using the standard utilities.

Application Menus The main method for displaying available menus, the Menu Explorer, can be incorporated as part of a composite screen. Again, the text that appears represents HELPTEXT.MENU records and instructions within them, so that when the text (in the example below, ‘Trade finance dept’) is clicked, it displays the contents of the HELPTEXT.MENU that underlies it. When text represents an enquiry, version or application, this is run upon being double-clicked.

Figure 2 – Application Menus It is possible to link a single menu to a user, so that as soon as a user enters the system that menu is displayed. This is done through the INIT.APPLICATION field on the USER profile. If a user has an INIT.APPLICATION set, he will not be able to use any applications that lie outside of that menu. If no menu is linked to the USER profile, all HELPTEXT.MENU records which are not accessed through another HELPTEXT.MENU can be accessed as dropdown menus from the File menu. The HELPTEXT.MAINMENU file may still be used as before, and is still supported, whereby a single menu contains only other menus and may be entered in the INIT.APPLICATION field. However, use of HELPTEXT.MENU for this role is now the more flexible and preferred choice. The Menu Structure The HELPTEXT.MENU record can be used to launch applications, versions of applications, enquiries and even other menus. In effect, selecting an option from a menu has the same effect as entering it in the command line. Anything that can be entered in the command line can be entered on the APPLICATION field of the HELPTEXT.MENU. See the Application Menu chapter in the System Administration Guide for more information.

VERSION VERSION is a standard T24 application allowing the creation of customised screens for input, printing, display etc. It will be rare for any client to use the standard (main) screen input for all T24 applications. In fact we supply many useful Versions covering the majority of T24; we encourage clients to copy and amend them to suit local requirements. The creation of versions can be divided into three main categories; input of the header or title; the fields required for input or display; and the defaults to be pre-filled when using that specific version. All T24 trading applications are capable of supporting more than one product, e.g. LD.LOANS.AND.DEPOSITS supports loans, deposits, commitments etc. and it also supports a wide variation of options e.g. discounts, maturity, liquidation, rollovers, schedules to highlight a few. In order to support this functionality, the main LD contract has over one hundred fields. Although all the fields are necessary, only a few are needed for the input or maintenance of a particular contract type. VERSION allows you to create screens that reflect each contract type, presenting only the necessary fields and defaulting data into other fields. Each VERSION you define is referenced by the name of the application and the name of the version separated by a “,”. For example, a LD version for inputting call deposits could have an id of LD.LOANS.AND.DEPOSITS, CALLDEP. To ‘run’ the VERSION simply enters the application name with the version reference. SMS control can be defined specifically for the VERSION by entering the name of the VERSION, with the comma, in USER in the field VERSION. Subsequently you can restrict access to the contract types as well as the application itself. The creation of VERSION records can be divided into three main categories; input of the header or title; the fields required for input or display; and the defaults to be pre-filled when using that specific VERSION. Screen Builder The Screen Builder, in ToolBox allows you to create screens using a wizard. The wizard provides predefined layouts. Defaults The last section of the Version record allows the user to pre-fill values at input using that Version, make fields non-input; no change; mandatory. Version also allows the usage of subroutines (small programs written locally) that can add local validation to the application. An example of this could be a check that ensures that the Passport Expiry Date (a local reference) was greater than the system date. More information on the use of sub-routines can be found in the Application Program Interfaces section of this manual. For more information on the creation and use of versions, see the Version chapter in the System Administration guide for more information.

ENQUIRY The ENQUIRY allows you to construct views of the T24 database by enabling you (with given syntax) to construct statements that extract the database records according to specified criteria. These statements are extremely versatile, and can be used to access and manipulate data, or can be expanded and combined to create a flexible and powerful data presentation in form of either a screen or report. In addition to presenting simple or complex data from a single or multiple tables, you can: •

Drilldown enquiries (using an item from a summary ENQUIRY as a selection for a detail one)

•

Export ENQUIRY result into a Windows application such as an Excel worksheet

•

Launch an ENQUIRY as context sensitive while working with a related application

Creating an Enquiry ToolBox provides a wizard for create simple enquiries, much like the Screen Builder. Enquiries can later be customized using the ENQUIRY application.

Figure 4 – Example of a simple Enquiry

ABBREVIATION Abbreviations, or shortcuts can be created to run any T24 application, enquiry, version, etc. For example, abbreviations could be set up as follows: Abbreviation

Full command

LD

LD.LOANS.AND.DEPOSITS

LDSP

LD.LOANS.AND.DEPOSITS,SPECIAL

SPECIAL

LD,SPECIAL I

NOTE: In the example SPECIAL, the abbreviation of LD has been used in the command. Abbreviations can be used in menus where the text would exceed the space available for the command. All abbreviations can be used by all users, subject to the SMS restrictions for each user. In addition, user abbreviations can be created for use by only the assigned user.

Local Reference Local reference gives you the ability to add your own fields to a file. For example, you may wish to record a customer’s passport number on the CUSTOMER file. This can be achieved by use of the LOCAL.TABLE and LOCAL.REF.TABLE applications. Most T24 applications have a field called LOCAL.REF; this field can be replaced by up to 999 user-defined fields. Any new field that you want to add to a file as a local reference field must be entered on LOCAL.TABLE. Here you specify the name of the field, the type, minimum and maximum length, allowed values (vetting table) or replacement files to use such as CUSTOMER. The example below shows a simple field called PASSPORT.NBR being added.

Figure 5 – Local Table Input Record The field now needs to be linked to an application. To do this, a record must be added to LOCAL.REF.TABLE, with the id of the record set to the application name. Up to 999 fields can be linked to an application; fields can be added as simple fields or associated with other fields. In the example below, the local reference field for passport number is being linked to the CUSTOMER file.

Figure 6 – Local Ref Table Input Record Note that once a field has been linked to an application (updated on LOCAL.REF.TABLE), it cannot be removed. See the Local Reference chapter in the System Administration Guide for more detailed information.

Override Another aspect of the control of T24 concerns the override messages given at input time to the user. In the plainest form the inputter confirms the override, although this option is not recommended. T24 allows the client to specify classes of authorisation for overrides on the user profile. According to these classes either one of the inputters (or authorisers) must have the authority to approve the override before the record can be completed. A further option is provided where local development can be used to customise the validation of the override messages by use of user defined sub-routines (see the Application Program Interface section in this manual). NOTE: If the inputter has the class on their user profile, the override is flagged as approved at input stage. Another user without that class can then authorise the record. If neither the inputter nor first authoriser has the override class, a user who does have the correct user profile must also authorise the record. This is reflected in the record status, a status of INAO means the record is partially authorised but awaits a user with the correct authority. For audit purposes, the override message, code required and who approved it, is stored in the audit information fields.

The three component applications for override settings are: OVERRIDE.CLASS OVERRIDE.CLASS.DETAILS USER OVERRIDE.CLASS Each record on OVERRIDE.CLASS is a T24 application, and details the override message and what class of authority is required. Since the override messages can include variable data such as accounts, amounts and currencies, these are substituted with placeholder markers of ‘&’, e.g. Screen message of ‘ACCOUNT-256 UNAUTHORISED OVERDRAFT USD 100.00’ would be input as: ACCOUNT and UNAUTHORISED OVERDRAFT & & In addition to the override class, more complex override checking can be defined by referencing a record in OVERRIDE.CLASS.DETAIL, as detailed next. OVERRIDE.CLASS.DETAILS This application allows the definition of what can be termed literal checks and sub-routine checks. As already shown, an override message can contain variable data, in the example there are three placeholders shown as ‘&’. These are referred to as &1, &2 and &3. A literal check could be if &2 (currency in our example) is USD the class ABC is required. A sub-routine example could take the values in &2 and &3 and convert to local currency amounts. The class required could then depend on the amount in local currency. Local reference fields that generate overrides can also be included in this decision process and complex authorities for approval can be created.

Figure 7 – Override Class Details Input Record

Delivery Most of the information that is sent out to customers is produced through delivery, e.g. confirmations, advices, statements, etc. The manner in which the information is presented depends on the carrier being used, such as SWIFT, telex and print. The type of the message generated is dependant upon the application creating the message and the activity, e.g. maturity of a money market deal. In all the existing applications in T24, this is hard-coded. However, in the Repos module and new modules being developed, “soft delivery” is being used. This means that you can define what message type is generated by the application when a particular activity occurs. For example, you might want to generate an additional free format message, or instead of the standard message type being generated, you might want to generate an inter-branch message used by your bank. It is hoped that gradually existing applications will be amended to use soft delivery. See the Repos section in the Application Delivery User Guide for more detailed information. The method used for sending messages out through delivery and the way they are presented, is dependant upon the message being sent and whom it is being sent to. Records can be created on DE.PRODUCT to specify the carrier to be used (e.g. SWIFT, PRINT etc.), the address the message should be sent to, the number of copies and the language to be used. This can be specified by company, customer or account and also by message type and application. Therefore, a customer can have two printed copies of their statements sent to different addresses, one in English, the other in French, whilst all other messages are sent via SWIFT. See the Product table (DE.PRODUCT) section in the Delivery User Guide for more details. Although the format of SWIFT messages generated by T24 should never be changed, the format of the printed delivery massages can be changed as required. You can either amend the supplied layouts or design new documents from scratch. Printed messages are defined on either DE.FORMAT.PRINT for standard printing in delivery or DE.FORMAT.TEMPLATE for printing via the delivery WorkLink. Different layouts can be specified for different

customers (using the format in the id of the record that can be specified in DE.PRODUCT), the application format (which depends upon the activity which generated the message and is passed through from the application) and the language. See the DE.FORMAT.PRINT and DE.FORMAT.TEMPLATE sections in the Delivery User Guide for more detailed information. Although SWIFT and PRINT are standard interfaces that are delivered with T24, you may wish to add new interfaces or carriers. For example, you may wish to use the SWIFT carrier (i.e. you want to create standard SWIFT messages to the normal SWIFT addresses), but instead of using one of the supplied interfaces, such as ST200 or ST400, you may wish to interface with an in-house routing device. Or, you may wish to create a completely new interface, to send messages either via fax or email. Both of these scenarios can be achieved by using the DE.CARRIER and DE.INTERFACE tables. DE.INTERFACE defines the interface to be used, which can be simply writing to a flat file or calling a user-written subroutine to interface to an external or internal device. DE.CARRIER defines how the messages are to be formatted, the type of addresses to be used and the interface. See the section Creating a new interface in the Delivery User Guide for more information.

Repgens The utility REPGEN.CREATE (Repgens) is used to create reports that cannot be created by the ENQUIRY application. The format of the report, the data required, calculations and manipulation of the data is entered and the report code is automatically generated. The steps involved in the creation and output of a report are: REPGEN.CREATE REPGEN.SOURCE REPGEN.SORT REPGEN.OUTPUT

Details files used, fields printed, etc Creates object code Initial sorting of data prior to printing Produces report (to screen or printer)

Repgens can also be produced during the end of day using the batch job EB.PRINT. See the Report Generator chapter in the System Administration Guide for more information.

T24 Information Server (GIS) This optional module is specifically designed as an interface to external systems using standard Structured Query Language (SQL). In essence, a selection of T24 data files are ‘normalised’ into tables, currently for the Oracle database. This normalisation occurs at end of day and during the on-line process and ensures the Oracle database is up-to-date. The Oracle database can now be used to provide information such as: ▪ ▪ ▪

Input data to other systems Spreadsheets or similar packages accepting SQL commands SQL report utilities

This allows greater flexibility in the output from T24 Where the output is required for investigation or reporting purposes, a hard copy may not be the best solution. A direct feed would be more appropriate. Reports can be provided in PC format suitable for inclusion in Management reports prepared in applications such as Word Processors or Databases. It is possible to provide output for mail merging so for example a mail shot can be sent to customers with savings accounts with high balances advising them of a new account product.

See the T24 Information Server User Guide for more information.

Open Financial Service (OFS) The Open Financial Services module (OFS) provides a standard interface to allow update and interrogation of T24 applications. OFS provides a real time transaction and batch based mechanism, which accepts messages in a specific format. OFS complements the existing T24 Transaction Server (GTS) module and will support the existing field based GTS message syntax described in the GTS chapter of the user guide. OFS will provide the following functionality: • • • • • • • • • •

Allow real-time update of T24 applications using messages supplied in specified OFS syntax. Allow interrogation of the T24 database by returning information based on ENQUIRY layouts in a specified layout Optional offline store and forward capability Optional audit trail for each message processed Customisation of message processing using user defined routines Allow batch update of the T24 database using files containing messages specified in either GTS or OFS syntax Multi-company processing Support for sub-values Enhanced error message details Ability to run on platforms other than Unix (i.e. NT)

A variety of external sources to use OFS have already been identified, these include: •

Home Banking applications

•

ATM processing

•

External dealing system feeds

See the Open Financial Service User Guide for more information.

TAKEOVER.MAPPING The TAKEOVER.MAPPING application is designed to load data from a sequential (flat) file into the required T24 format. Records are loaded as IHLD. The records can then be input and authorised, to ensure that the data validates through the T24 application. The utility EBS.AUTO.FUNCTION (described in the next section) can be used to input and authorise the records, to automate the input and authorisation process. The TAKEOVER.MAPPING record defines the location of the flat file, and the mapping of the data e.g. the data that will be used for a customer name starts at position 12 and is 25 characters in length. Special conversion programs may be required to extract data from existing systems and write them as flat files for use in the takeover process.

The example below shows a simple record that could be used in creating new CUSTOMER records in T24.

Figure 8 – Example of creating new Customer records in T24

EBS.AUTO.FUNCTION This utility can be used when a large number of records need to be processed. For example, when taking over data from existing systems, it is common to input the new records en masse by use of TAKEOVER.MAPPING. Typically the records are input but need to be validated by T24 to preserve data integrity; therefore the records are put on the unauthorised file with a status of IHLD. The EBS.AUTO.FUNCTION can then be used to perform the same actions that the user would take in order to validate and authorise the records. Typically this would be done in two stages. First of all the records would be I(nput), to validate them. Then they would be authorised. To perform these actions through EBS.AUTO.FUNCTION, two records would need to be created. The first EBS.AUTO.FUNCTION record would use the I(nput) function and function keys to validate the record. Records requiring overrides can either be left for manual processing or approved automatically. A second EBS.AUTO.FUNCTION record would then be used to display the screens, and using the A(uthorise) function and function keys, complete the takeover process. An example is shown below to enable the records to be input.

Figure 9 – EBS Auto Function Input