Professional Documents
Culture Documents
DEL1-Delivery Outward - Induction Only-R13.01
DEL1-Delivery Outward - Induction Only-R13.01
01 1
DEL1-Introduction to Delivery-Outward-R12.01 2
1. An important aspect of all banking transactions is the proof that it happened. To a lay man this proof
could be a simple print out that gives him details of his last transaction. In T24, these confirmations are
referred to as advices.
There are 2 types of Advices that can be generated in T24
2. The first type is a Deal Slip
-Peter decides to open an account in the bank. He has submitted all the documents required to open an
account and wants a status update.
-Once the account has been created, Peter will be issued with a Deal slip as a confirmation.
Therefore a deal slip
2.1 Can be generated for any application
2.2 Can be generated during any of the functions i.e., Input, Authorise, Copy, Delete etc)
2.3 Can be generated only online
2.4 Is normally printed and handed over to the customer across the counter
3.The second type are Delivery Advices.
For example:
-Peter is a customer of bank xyz. He wants to open a Fixed Deposit with the bank. He approaches a
banker and tells him to do the same
-The banker inputs a DEPOSIT in T24 using the LD application. Once this LD record is authorised,
automatically an advice will be generated. This advice produced is called a Delivery advice and is not
given to Peter immediately.
Therefore a delivery advice is
3.1 Generated only for contract based applications like FT, LD, MM etc.,
3.2 Generated only when contracts are authorised
3.3 Generated both online and offline (i.e. during COB)
3.4 Normally printed during COB
DEL1-Introduction to Delivery-Outward-R12.01 3
1. T24 as a software supports both inward and outward advices i.e. it can send and
receive advices when need be.
2. An example of an Inward Advice is an instruction received from another bank to
execute some transaction in T24 through SWIFT
3. An example of an Outward Advice is an instruction sent from T24 to another bank
through SWIFT. Some other examples of outward advices are printing of account
statement of a customer’s account, SMS to the customer about a transaction,
EMAIL account statements or send a SECURE MESSAGE to a customer through
Internet Banking.
4. A Delivery Carrier is the mode in which the Delivery Message is sent or received.
DEL1-Introduction to Delivery-Outward-R12.01 4
1. What is SWIFT?
SWIFT stands for Society for Worldwide Interbank Financial Telecommunication by
which messages are securely and reliably exchanged between banks and other
financial institutions. These messages are not printed, they are sent electronically. The
header and trailer required by SWIFT are generated automatically as they are
standard. The maximum size of a SWIFT message is 2000 characters.
2. What is a PRINT Advice?
Print carrier is used to print the delivery advices, that needs to be send to customers.
This means that a PRINT advice is sent to the physical network printer configured for
that T24 server. It is possible to define different formats so that a document can be
printed in different versions or languages as required by particular customers.
3. SMS stands for Short Message Service. It is a text message that is sent to a mobile
telephone over a communications network. In T24, a message is sent to a third party
SMS Gateway called Clickatell through a java sms interface. Clickatell then sends the
actual message to the mobile device.
4. eMail stands for Electronic Mail. Its an electronic message that is transferred
between computers through a server. In T24, a XML message is generated that is sent
to a Java email interface. From this interface the XML is converted to an email object
and is sent to a SMTP server.
5. A Secure Message is created in a application called EB.SECURE.MESSAGE. The
message from this application is displayed to the customer when he/she logs into T24
using Internet Banking.
DEL1-Introduction to Delivery-Outward-R12.01 5
1. In T24, Delivery is called a subsystem because it has its own set of routines and
applications that work together to produce a delivery advice. The Delivery System
manages the flow of all messages from T24, such as confirmations, payments and
advices
A. T24’s delivery subsystem. The routines and applications that make up the delivery
subsystem have a logic built into it that tell the system where to pick up
information from and how to present this information to produce a delivery advice.
3. The delivery system can be turned ‘ON’ or turned ‘OFF’ just like a switch that
controls a light bulb. This is accomplished by starting/stopping services. As we
move further in this course we will try to understand how to do this.
4. The key components that make up the delivery subsystem are services.
A service is a background process that runs in a Multi-Threaded fashion.
DEL1-Introduction to Delivery-Outward-R12.01 7
1. Who decides what data should be a part of the delivery Advice?
1.1 The T24 application. Within the application logic, it calls a core API called
APPLICATION.HANDOFF
5. What next?
5.1Give a format to the advice i.e. design the advice. You will learn about this
in the next learning unit
6. Finally?
6.1 Send the Advice to the physical device, i.e. to the printer or to the SWIFT
machine. You will learn about this in the next learning unit
DEL1-Introduction to Delivery-Outward-R12.01 8
1. In T24, there is a core subroutine that triggers off everything related to Delivery.
This routine is called APPLICATION.HANDOFF.
DEL1-Introduction to Delivery-Outward-R12.01 9
1. Like every application in T24, the Delivery system also maintains an unique ID for all the
Delivery Advices it creates. This unique ID is called the “Delivery Reference ID”.
2. You are now going to learn the components that make up this ID with an example.
3. The first character in the ID determines whether the Advice is an Inward or Outward
Advice. If the ID begins with a “D” then it means that this an Outward Advice. If the ID
begins with a "R" it means that this is an Inward Advice.
4. The next component of the advice is the date on which the advice is produced. The date is in
the format YYYYMMDD.
For E.g.: 20080427, means that this delivery advice is produced on 27-April-2008.
5. The next 5 digits denotes the port number assigned by jBASE to every T24 session
6. The next 5 digits denotes the time in seconds since midnight.
7. The last two digits are a unique sequence number which denotes the number of transactions
within a second.
In a real time scenario, when we are running COB, multiple Delivery messages are created at
the same time. Which means that the ID of 2 or more messages will be the same.
However, they have to be unique. So, to differentiate between the number of transactions
per second, we have it appended as the last part of the delivery reference ID.
For e.g.: Let assume at the time 48051 (number of seconds since midnight) and on the date 09-
July-2007, the system produces 2 PRINT messages. Then the Delivery reference ID’s for
both the messages would be D20070709-00010-48051-01.
However, NO two messages can have the same Delivery Reference ID. Therefore, to
DEL1-Introduction to Delivery-Outward-R12.01 10
differentiate between the 2 messages, T24 will maintain the number of transactions per second, viz. (for
this example) D20070709-00010-48051-01 and D20070709-00010-48051-02
DEL1-Introduction to Delivery-Outward-R12.01 10
1. There is a common file into which details from a transaction are written.
2. This is called the Dump File - F.DE.O.HANDOFF
3. This file contains one record per advice.
4. The ID of a record in this file is the Delivery Reference ID
5. Details stored in F.DE.O.HANDOFF can be viewed from within T24 by running the
enquiry DE.HANDOFF.DETS
DEL1-Introduction to Delivery-Outward-R12.01 11
APPLICATION.HANDOFF, writes the data that is required to produce a delivery
advice to a record in F.DE.O.HANDOFF. -- A record in DE.O.HANDOFF is made up of
10 rows.
-Each row can hold infinite amount of data separated by a delimiter specific to jBASE.
-Row number 9 is used for USER Defined values, i.e. suppose a client wants some
data to be a part of the advice, then you can write a subroutine that would populate
data into this row of the HANDOFF record
-Row 10 is not filled with any data and is reserved for later use.
DEL1-Introduction to Delivery-Outward-R12.01 12
Before you set out to creating a delivery advice - Design an Advice and decide what
information you want in it. A sample DEBIT ADVICE is shown on your screen.
1.The angular braces that you see are place holders for values that will be substituted
from the transaction at run time.
DEL1-Introduction to Delivery-Outward-R12.01 13
APPLICATION.HANDOFF, as said earlier is the subroutine that is responsible for
writing data into the file called F.DE.O.HANDOFF. This file contains one record per
delivery advice. The data in this file in not structured.
1. For e.g.:
In the above diagram, if you wanted to access the value 14648, which is the account
number, then you would look at field position 1.2 in F.DE.O.HANDOFF, because it is in
the first row and is the second value after the jBASE delimiter (VM – Value Marker)
The legend on the right hand side of the slide describes the data that resides in
HANDOFF record for your understanding.
DEL1-Introduction to Delivery-Outward-R12.01 14
Now you have values in F.DE.O.HANDOFF.
However, as you see this data has no meaning. Its just raw data, like data in a data file
doesn’t have any meaning without DICT information.
Therefore, just like the DICT information you need to define variables. These variables
will give meaning to the data that is present in DE.O.HANDOFF’s record.
The variable names defined here are not to be confused with the Field names present
in STANDARD.SELECTION of the application. These are defined separately for the
Delivery Subsystem.
For eg: The variable name DATE is not a field name in the STANDARD.SELECTION
record of FUNDS.TRANSFER application.
While deciding a variable name you also have to decide on the attributes of the
variable like its DATA TYPE and the maximum length of characters it can hold
DEL1-Introduction to Delivery-Outward-R12.01 15
1. You have defined the variable names. How are you going to assign values to the
variables?
2. You have to map the variable names (decided in the previous slide) to positions in
the F.DE.O.HANDOFF’s record. This is done so that the Delivery subsystem
knows which data resides in which position in HANDOFF record. Compare this to
a STANDARD.SELECTION record, where you tell the T24 application what are
the field names and which position in the data file does the field name correspond
to.
3. For e.g.: The variable name DATE is mapped to position 2.1 in the HANDOFF
record. This means that the first value in the second row of the HANDOFF record
contains the transaction date which will be used by the delivery subsystem to print
in the Delivery Advice.
Using the example stated just now, go through each and every mapping in this slide to
understand how the process of mapping is done
DEL1-Introduction to Delivery-Outward-R12.01 16
You are now going to link the concepts that you learnt to actual applications in T24.
1.The first step to producing a delivery advice is to Input and authorise a transaction.
2. This step is done by the T24 User
3. The next step is to store the values required to produce a delivery advice in a file
called F.DE.O.HANDOFF
4. This step is done by passing values to the routine APPLICATION.HANDOFF. No
action is required by the T24 User, as you just learnt this is done automatically by the
underlying application
5. The next step is to Define variable names
6. This is done by creating records in an application called DE.MESSAGE in T24. The
records in DE.MESSAGE comes pre-configured with every release of T24
7. Now you have to Link Variable names to positions in F.DE.O.HANDOFF
8. This is done by creating records in an application called DE.MAPPING in T24. The
records in DE.MAPPING comes pre-configured with every release of T24
DEL1-Introduction to Delivery-Outward-R12.01 17
@ID Numeric Input
FIELD NAME A short descriptive name by which this field will be known to the
Delivery System. (The variable names that we described in Slide titled “Defining
Variable Names” will be entered in this field)
DEL1-Introduction to Delivery-Outward-R12.01 18
Messages in ‘Repair’ state are stored in a file called the repair queue (F.DE.O.REPAIR)
DEL1-Introduction to Delivery-Outward-R12.01 18
@ID <DE.MESSAGE ID>.<APPLICATION>.<Curr No>
Eg: 900.FT.1
INPUT POSITION The position in DE.O.HANDOFF (dump file) from where the “variable”
defined in DE.MESSAGE gets its value
The data in this field should be numeric. It can either be an actual position in DE.O.HANDOFF,
or it can be reference to the field INPUT REC NO
(To relate to what we have learnt till now, this is the field where we have to enter the Data
Position explained in Slide “Mapping Variable names to Data positions”)
FIELD NAME Specifies the name of a field as defined in the appropriate DE.MESSAGE record.
Ensure all fields defined as mandatory in DE.MESSAGE are mapped.
HEADER NAME Field name used in Delivery Header (We will look at a Delivery Header later in
this presentation. Delivery Headers are created in an application called DE.O.HEADER)
DEL1-Introduction to Delivery-Outward-R12.01 19
This is the first stage that the Delivery advice goes through. Its called the MAPPING
STAGE. The T24 user does not have any control over the mapping stage i.e. as soon
as the transaction is authorised the MAPPING stage is complete.
2. Then you map the variable names declared in DE.MESSAGE to values held in the
record of the file F.DE.O.HANDOFF in an application called DE.MAPPING. The ID
of a record in DE.MAPPING is a combination of the DE.MESSAGE id the
Application name and the Curr Number.
Eg: 900.FT.1 (means that the message type is 900, the application for which this
mapping record is going to be used is FT and 1 is the Curr Number)
3. The mapped information is used in the final output of the Delivery Advice.
NOTE Great care is needed when setting up the Mapping Table as the system cannot
check if all the mandatory variables defined in DE.MESSAGE have been mapped with
positions in DE.O.HANDOFF
DEL1-Introduction to Delivery-Outward-R12.01 20
As stated earlier, you can use the enquiry DE.HANDOFF.DETS to view the contents of
the HANDOFF record.
1. Login to your area, and at the command line type ENQ DE.HANDOFF.DETS
2. In the enquire selection box, type the Delivery Reference ID in the field
DELIVERY.REF
3. Click on the FIND button
4. You will be able to see the output of the enquiry. Note that position 2.2 is mapped
to the Transaction Reference as per the mapping record.
DEL1-Introduction to Delivery-Outward-R12.01 21
Sometimes the FT might get authorised, but no Delivery advice produced. In this case.
Open the application FT.TXN.TYPE.CONDITION. The record ID here is the
Transaction Type. In the record set the field DR.ADVICE.REQD and
CR.ADVICE.REQD to “Y”.
For e.g.: You will open the record AC in FT.TXN.TYPE.CONDITION, if you are doing a
‘AC’ type FT transaction.
DEL1-Introduction to Delivery-Outward-R12.01 22
1. Going back to the Overview slide, the question - What is the data that needs to be a
part of the Delivery Advice - has been answered
2. Now, you are going to decide how should the delivery advice be sent? i.e. you will
have to decide - which carrier to send the advice through - PRINT or SWIFT or BOTH
DEL1-Introduction to Delivery-Outward-R12.01 23
1. Using DE.PRODUCT we can achieve a lot of functionality. It is one of the most
important applications related to the Delivery Subsystem.
A record in this application helps the Delivery Subsystem decide how should the
Delivery Advice be sent? Either by SWIFT or by PRINT? It also helps the delivery
subsystem decide many other parameters which you will see in the forthcoming slides
The next slide will make you understand this concept better
DEL1-Introduction to Delivery-Outward-R12.01 24
You will now learn the components that make up the ID of DE.PRODUCT. Each component is
separated by a “DOT”
1. The first component of the DE.PRODUCT ID is the COMPANY.CODE. For eg: GB0010001.
The mnemonic can also be specified and the system will automatically convert it to the company
code.
2. The next component of DE.PRODUCT is optional. You can create a product for a specific
customer or a specific account. If it’s a customer number then the DE.PRODUCT ID should be
“C-Customer No” or if it’s an account number then the DE.PRODUCT ID should be “A-Account
No”. While creating the product for a specific account or customer if you don’t remember the
Customer number or the account number you can specify the account or customer mnemonic.
T24 will automatically convert the mnemonic to the appropriate value.
3. The next component is a mandatory component of DE.PRODUCT ID. You have to specify the
Message Type here. You can create a product record for a specific message type by mentioning
the ID of DE.MESSAGE or for all Message Type by typing the keyword “ALL”
4. The last component is also a mandatory component. This is where you will specify the name of
the application. The format is “xxyy”, where “xx” is the short form of the application like FT for
FUNDS.TRANSFER and “yy” is an optional component where you can mention a sub product
code like OT or AC etc., (You saw an example of a sub product code being passed to
APPLICATION.HANDOFF in Slide titled “DEMO-1-How to view the mapped contents?”). If you
want to create a product for ALL the applications producing a delivery advice then instead of
mentioning in the format “xxyy” you can type the keyword “ALL”.
5. NOTE: When choosing a record in DE.PRODUCT, if there is a record present for both
ACCCOUNT and CUSTOMER, T24 will always chose the record with ACCOUNT number first
6. FOR EG: If you want to create a product record for all 950 type messages generated as a result
of transaction on an account number 15377 then you will have to create a record in
DE.PRODUCT with ID as
GB0010001.A-15377.950.ALL
DEL1-Introduction to Delivery-Outward-R12.01 25
1. How will T24’s Delivery Subsystem search for a record in DE.PRODUCT?
2. It will search for a record in DE.PRODUCT that is the MOST SPECIFIC match to
the details from the transaction.
3. The order in which it will search for a record is the MOST SPECIFIC to the MOST
GENERIC.
3.1 First it will search for all account specific records.
3.2 Then it will search for all Customer specific records,
3.3 Then it will search for records that are message specific,
3.4 Then it will search for records that are application specific,
3.5 If none of the above records are present then it will search for the most generic
record, which is for ALL message types and ALL applications generating Delivery
advices.
DEL1-Introduction to Delivery-Outward-R12.01 26
QUESTION?
In T24, there is a Customer 100224 with an account 10003 who belongs to the
company GB0010001. In what order with the delivery subsystem look for a record in
DE.PRODUCT for a Message Type 910 generated from an application FT?
Answer:
D, E, B, A, C, H, I, G, F
DEL1-Introduction to Delivery-Outward-R12.01 27
DEL1-Introduction to Delivery-Outward-R12.01 28
1. You can specify how the delivery advice should be sent in the field Carrier Addr
No. This field is also used to specify which particular address should the delivery
advice be send to.
For e.g.: When you specify the value SWIFT.1, the delivery advice will be sent through
the SWIFT carrier and ID of the address will end with SWIFT.1. You will be able to
understand this better when you learn where the delivery advice should be sent.
This field is a multi value field. Therefore, for a particular PRODUCT more than one
advice can be generated. In the above example both PRINT advice and SWIFT advice
are generated.
2. You can specify the language that should be used while formatting a record in the
field Language.
3. You can specify the format version number that is to be used by the delivery system
while selecting a record in DE.FORMAT.PRINT to format a record; in the field Format.
4. You can specify the number of copies of a message required in the field Copies.
DEL1-Introduction to Delivery-Outward-R12.01 29
1. Going back to the Overview slide, we have answered the questions - What is the
data that needs to be a part of the Delivery Advice and how should the delivery advice
be sent
2. Now, we are going to decide where the advice has to be sent? i.e. you will have to
tell the delivery subsystem the address of the customer if it’s a PRINT Advice or the
SWIFT code of the bank in case of a SWIFT Advice.
DEL1-Introduction to Delivery-Outward-R12.01 30
DEL1-Introduction to Delivery-Outward-R12.01 31
This is a sample screen shot from a record in DE.ADDRESS. Notice that this record
contains the address details of the first address of the CUSTOMER 111366, and
cannot be altered.
For creating the PRINT.2 address the record can be manually input in this application
with ID ending with PRINT.2
DEL1-Introduction to Delivery-Outward-R12.01 32
@ID Delivery Reference ID
Msg Disposition Same data can be used to create both a PRINT and SWIFT advice.
This field denotes processing status of the multi-value set of data for each copy of the
message (Not shown in the above screen shot, can be seen when message is
formatted, acknowledged or in Repair queue)
DEL1-Introduction to Delivery-Outward-R12.01 33
DEL1-Introduction to Delivery-Outward-R12.01 34
DEL1-Introduction to Delivery-Outward-R12.01 35
DEL1-Introduction to Delivery-Outward-R12.01 36
1. Going back to the Overview slide, we have answered the questions - What data
should be part of the advice, How should the advice be sent, Where should the
advice be sent. You also learnt that these steps collectively form the Mapping
Stage.
2. Now, you are going to give the advice a format i.e.. you are going to design the
advice?
3. This is done by creating appropriate records in more than one application. You have
to create a record in an application called DE.FORMAT.PRINT to design a PRINT
advice and create a record in an application called DE.FORMAT.SWIFT in order to
design a SWIFT advice.
DEL1-Introduction to Delivery-Outward-R12.01 37
1. The Formatting Stage describes how the delivery advice should look like
5. Advices ready for delivery must be placed in correct ‘Carrier’ queues otherwise
called “Formatted” Queues.
DEL1-Introduction to Delivery-Outward-R12.01 38
1. As stated earlier, the Formatting stage is started by the USER. This is done by starting
services BNK/PRINT.OUT incase of a PRINT advice and BNK/SWIFT.OUT in case of a
SWIFT advice. Both these services actually invoke a multi threaded subroutine called
DE.OUTWARD. This routine is the starting point of the FORMATTING stage of the Delivery
ADVICE.
2. The first application to be read is DE.CARRIER. A record in DE.CARRIER is read to find out
which application is to be used to format an advice. How is a record in DE.CARRIER read? It
is read using information present in the DE.PRODUCT record. For e.g.: If the Carrier Addr
No field in DE.PRODUCT record is PRINT.1 then the record to be read in DE.CARRIER is
PRINT.
3. Inside the DE.CARRIER record information regarding which application should be used to
format the advice is present. The corresponding record in this application is formed by
reading information from the HEADER record.
4. If the application to be used for formatting is specified as PRINT inside the DE.CARRIER
record; then a record in DE.FORMAT.PRINT is used to format the delivery advice. The
appropriate record to be read in DE.FORMAT.PRINT, was decided in the previous step itself.
The delivery advice is now formatted according to this record.
5. Once the delivery advice has been formatted, it has to be written into the respective formatted
queue. The name of the formatted queue is F.DE.O.MSG.<FORM.TYPE>. This FORM.TYPE
is the name of a record in DE.FORM.TYPE, that defines the width and depth of each printed
form, and states which physical printer the output should be sent to. The name of the
FORM.TYPE to be used is present in the DE.FORMAT.PRINT record.
6. If the application to be used for formatting is specified as SWIFT inside the DE.CARRIER
record; then a record in DE.FORMAT.SWIFT is used to format the delivery advice. The
DEL1-Introduction to Delivery-Outward-R12.01 39
appropriate record to be read in DE.FORMAT.PRINT, was decided in step number 3. The
delivery advice is now formatted according to this record.
7. Once the delivery advice has been formatted, it is placed in the appropriate formatted
queue called F.DE.O.MSG.SWIFT. The formatted queue where the Delivery advice
resides in case of SWIFT may differ. You will learn about this in the next few slides
DEL1-Introduction to Delivery-Outward-R12.01 39
INTERFACE: This is only used when messages are processed using the generic
interface (i.e. when carrier-module is "GENERIC"). The data in this field is a valid
record in DE.INTERFACE
An Interface is like a gateway from which messages can come in or go out of T24
system. For a detailed explanation of Interfaces take our course T3DEL (Tier 3 course
on DELIVERY module)
DEL1-Introduction to Delivery-Outward-R12.01 40
As a recap, this is the delivery advice that we wanted to produce at the beginning of
the presentation. Now, you will have to design this advice. You will first learn how to
design this advice conceptually, and then you will relate it to the DE.FORMAT.PRINT
record in T24
DEL1-Introduction to Delivery-Outward-R12.01 41
Now that the variables have data, we need to align them and display them in the
required format. Designing a delivery advice is similar to designing enquiries.
1.Any string that needs to be printed as it is, should be specified within QUOTES. For
example, The string DATE should be specified within quotes in order to appear the
way its shown in the advice in the previous slide
2.Any variable name that holds a value should be specified with just the name of the
variable without quotes. For e.g.: The variable DATE contains the value date of the
transaction.
3.The row and column of the output should be decided too.
4.For e.g.: in the 11th Row 5th column the string “DATE” will be printed. Then in the
same row but the 22nd column the value held in the variable DATE will be printed.
Go through the debit advice in the previous slide and the table defined in this slide to
understand the layout of the advice.
DEL1-Introduction to Delivery-Outward-R12.01 42
If you notice there is a Horizontal Line in the advice. Now you will have to make sure
that this horizontal line spans across the page. So, as stated before any string to be
displayed as is, should be within quotes. The number of hyphens are not enough to
cover the entire page. So you will have to create another set of hyphens, but they have
to start from the same row, so instead of specifying a defined row value you can
specify a relative row value. In this example a +00 means that start printing from the
same row, however if you notice that the column value is different. This means that
after the first set of hyphens have been displayed in the same row but a different
column mention the remaining set of hyphens so that the line covers the entire width of
the page.
A value of +03 means that 3 rows after the current row, a value of +02 means 2 rows
after the current row printed, so on and so forth.
DEL1-Introduction to Delivery-Outward-R12.01 43
@ID <DE.MESSAGE TYPE>.<Application Format>.<Format version number>.<LANGUAGE>
Eg: 900.1.1.GB
DE.MESSAGE Type - 900
Application Format - 1 (This value is populated in the DE.O.HANDOFF file and is also present
in the Message Header).
NOTE: We will look at a Delivery Header later in this presentation. Delivery Headers are
created in an application called DE.O.HEADER
Format version number - 1 (This value is defined in an application DE.PRODUCT, which we will
see later in the presentation)
LANGUAGE - GB (This value is defined in an application DE.PRODUCT, which we will see
later in the presentation)
FORM TYPE The first decision to be made in creating a new print format layout is the size of
the stationery to be used. In the field, Form type, the name of the form type to be used should
be entered. If this field is left blank, "default" stationery will be used. The name of the form type
should exist on the Form type table, DE.FORM.TYPE. This table describes the form width
(number of characters), depth (number of lines), the printer to be used and special print
attributes to be used when the report is printed
LINE(S) Specifies how far down a page the item defined in FIELD/'TEXT' should be printed.
Relate it to specifying which row in Slide 21
INDENT Indent specifies the position of the field across the page and is expressed as the
number of characters across the page. Relate it to specifying which column in Slide 21
FIELD/TEXT What is actually to be printed at the position specified. This could be a variable
name from DE.MESSAGE or it can be a string that is specified in “” (quotes). This field can also
DEL1-Introduction to Delivery-Outward-R12.01 44
contain certain reserved words defined by T24. Relate it to specifying Field Name in Slide 21
DEL1-Introduction to Delivery-Outward-R12.01 44
DEL1-Introduction to Delivery-Outward-R12.01 45
Continuing from the example that you saw in the previous Learning UNIT titled “T24
Outward Delivery - PART I”. You are now going to format your advice. As you know
this is a PRINT advice, you will have to start the service BNK/PRINT.OUT defined in
TSA.SERVICE, in order to format the advice.
STEPS:
1.Start the TSM and BNK/PRINT.OUT service to start by setting the
SERVICE.CONTROL field in the respective TSA.SERVICE records to “START”
2.Login to jBASE and from the jshell prompt type START.TSM -DEBUG to start the
TSM
3.Open another telnet session to the server and from the jshell prompt type tSA
followed by the number assigned for the particular tSA by TSM to run the service
BNK/PRINT.OUT
DEL1-Introduction to Delivery-Outward-R12.01 46
Open the corresponding record in DE.O.HEADER,
Notice that the fields Disposition and Msg Disposition have been set to
“FORMATTED”
DEL1-Introduction to Delivery-Outward-R12.01 47
STEP 1: Open the FT record and click on the “i” icon near the Delivery Outref field
STEP 2: in the Popup that will appear click on the “View Outward Message” Link
STEP 3: Details of the Delivery Advice as a result of enquiry. Click on “View Delivery
Link” to see the formatted advice
DEL1-Introduction to Delivery-Outward-R12.01 48
When you click on the View Delivery Link on the previous screen, the formatted
delivery advice is displayed to you. Take a minute to go through the Formatted
Delivery Advice and understand its contents.
DEL1-Introduction to Delivery-Outward-R12.01 49
Resubmitting?
This is achieved by amending the DE.O.HEADER record, changing the DISPOSITION
field to "Resubmit" and authorising the record. The DISPOSITION will be changed to
"Resubmitted", the error message removed; the message will be removed from the
Repair queue and added to the Un-formatted queue for a further attempt at formatting.
DEL1-Introduction to Delivery-Outward-R12.01 50
Input a FT transaction and authorise it
DEL1-Introduction to Delivery-Outward-R12.01 51
Open the record and note down the delivery reference ID’s
DEL1-Introduction to Delivery-Outward-R12.01 52
Open the record in DE.O.HANDOFF. Notice that MSG.DISPOSITION field is ‘REPAIR’
and the DISPOSITION field is set to ‘UNFORMATTED’
DEL1-Introduction to Delivery-Outward-R12.01 53
In the above example, the error message has occurred in the MAPPING stage, as the
DISPOSTION field says UNFORMATTED. We have not yet started the formatting
service PRINT.OUT. To rectify the error, create a record in DE.ADDRESS, for that
particular customer before resubmitting the message
- Open the record in edit mode, and change the field MSG DISPOSTION to
‘RESUBMIT’.
- Commit and authorise the record in DE.O.HANDOFF
DEL1-Introduction to Delivery-Outward-R12.01 54
T24 delivery system will move the record from the repair queue F.DE.O.REPAIR to the
unformatted queue. Make sure that you correct the error before proceeding.
DEL1-Introduction to Delivery-Outward-R12.01 55
DEL1-Introduction to Delivery-Outward-R12.01 56
DEL1-Introduction to Delivery-Outward-R12.01 57
1. Going back to the Overview slide, we have answered the questions - What data
should be part of the advice, How should the advice be sent, Where should the advice
be sent. You also learnt that these steps collectively form the Mapping Stage. You
then learnt how to format the advice and the applications involved. This stage is
collectively called the Formatting stage.
2. Now, you are going to send the formatted advice to the final stage i.e. you are going
to send it to the appropriate carrier?
DEL1-Introduction to Delivery-Outward-R12.01 58
In case, of a SWIFT advice, T24 checks if it has to use an INTERFACE to send the
SWIFT advice or does it have to use the default swift queue to place the formatted
SWIFT advice. An Interface is like a gateway, and in T24 its defined in an application
called DE.INTERFACE. We can write a set of routines and attach it to this application.
These routines will take care of sending a SWIFT delivery advice to a swift machine.
If we use the default SWIFT queue, then we have to manually start a service
TSA.SERVICE>XXX/SWIFT.OUT
DEL1-Introduction to Delivery-Outward-R12.01 59
Overview:
When we authorise a contract based transaction, T24 internally calls a routine called
APPLICATION.HANDOFF. We pass 9 arrays to this routine as arguments. These arrays are
stored in a DUMP FILE called DE.O.HANDOFF. After populating the values in
DE.O.HANDOFF, T24 internally calls the Mapping routine that in-turn picks up variables defined
in DE.MESSAGE and maps it with their corresponding values specified in DE.O.HANDOFF,
using the application DE.MAPPING.
The appropriate Product record DE.PRODUCT is read to determine to whom the message
should be sent, how many copies and which carrier should be used. The carrier, as specified
on the product table, is used to access the carrier table, DE.CARRIER. This file contains the
carrier to be used for formatting, address table look-ups, the carrier module and the interface to
be used. The Address table DE.ADDRESS is accessed to determine the address to which the
message should be sent, e.g. the print address, the SWIFT id.
Once an advice is “Mapped” its called an “Unformatted Advice” and is stored in respective
Unformatted queues. The ID of the advice is stored in a queue called F.<CARRIER>.OUT.LIST,
where CARRIER is substituted with PRINT or SWIFT depending upon the which CARRIER the
advice has to be sent through. The actual unformatted advice is present in a file called
F.DE.O.MSG
For an advice to be formatted, we have to manually start services, depending upon which
carrier the particular advice has to be sent to. If it’s a print advice, then we will have to start
PRINT.OUT, and if it’s a swift advice we have to start the service SWIFT.OUT
The formatting service in-turn calls a T24 routine called DE.OUTWARD. This subroutine is
responsible for carrying out the formatting of a delivery advice based on the carrier invoked.
The T24 delivery sub-system then formats the advice according to the record in
DE.FORMAT.PRINT or DE.FORMAT.SWIFT.
The record once formatted is placed in formatted queues. In case of PRINT advices, ID’s of the
advice alone are stored in a file called F.DE.O.PRI.FORMS, and in case of SWIFT advices, the
ID’s are stored in a file called F.DE.O.PRI.SWIFT . The FORM.TYPE is substituted with data
specified in the field FORM TYPE in the corresponding DE.FORMAT.PRINT record.
DEL1-Introduction to Delivery-Outward-R12.01 60
T24, generates a SWIFT advice just the same way it generates a PRINT advice. The
service to be started to format a SWIFT advice is SWIFT.OUT.
DEL1-Introduction to Delivery-Outward-R12.01 61
DEL1-Introduction to Delivery-Outward-R12.01 62
T3DEL-The Delivery
DEL1-Introduction Subsystem-2008-H1-01
to Delivery-Outward-R12.01 63
F. <CARRIER>.OUT.LIST - Contains the List of Unformatted ID’s. This file is
updated as a result of the Mapping stage
F.DE.O.MSG - Contains actual message (Mapped but unformatted)
F. DE.O.PRI.FORMS - Contains the List of Formatted ID’s for PRINT message
F.DE.O.MSG.<FORM.TYPE> - Contains actual formatted PRINT advice
F.DE.O.PRI.SWIFT - Contains the formatted messages IDs for default SWIFT
CARRIER
F.DE.O.MSG.SWIFT - Contains the formatted messages for default SWIFT
CARRIER
F.DE.SENT.<CARRIER> - Messages that have been successfully sent
F.DE.O.MSG.<INTERFACE> - Messages that the interface must pick up from
T24
F.DE.O.HOLD.KEY – Messages placed on HOLD are stored here
F.DE.O.REPAIR – Outward messages that go into REPAIR are stored here
DEL1-Introduction to Delivery-Outward-R12.01 64
T24 core delivery module has been enhanced to introduce new email and SMS
carriers. This has facilitated creation of email / SMS as a core delivery message.
65
Explanation of the Overview Diagram:
1) Message is generated in T24 as per the user requirements. Then the generated
message is passed to the Java SMS interface using a jBASE API called CALLJ,
as XML data.
2) The interface, using the data it received, constructs the XML requests based on a
predefined XML schema defined by the client and sends it to the client over the
HTTP/S.
3) The client SMS gateway contacts the addressed handset and delivers the
message. It comes back with the response and the response is passed back to
T24 as acknowledgement.
66
A secure message is a message that a customer will see when he/she logs in through
his/her Internet Banking (ARC-IB) account into T24. Basically, an enquiry is running in
the front end, that displays all the secure messages for that customer from an
application called EB.SECURE.MESSAGE.
67
DEL1-Introduction to Delivery-Outward-R12.01 68
DEL1-Introduction to Delivery-Outward-R12.01 69