Welcome to “T24 Outward Delivery - PART II” learning unit.

In this learning unit you

will learn how the T24 delivery sub system works during the stages called Formatting
and Carrier Control. This unit will enable you to set up, work and troubleshoot with
applications involved during this stage.

T3DEL-The Delivery Subsystem-R12.01 1

 After completing this course, you will be able to:

1. Learn the flow of the Outward Delivery subsystem with respect to the stages
Formatting and Carrier Control

2. Understand the applications that are read during this stages

3. Configure records in this application if need be

4. Understand the overall working of OUTWARD Delivery

T3DEL-The Delivery Subsystem-R12.01 2

 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 from the
Learning UNIT titled “T24 Outward Delivery - PART I”

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.

T3DEL-The Delivery Subsystem-R12.01 3

 1. The Formatting Stage describes how the delivery advice should look like

2. The formatting stage is invoked by starting services like BNK/PRINT.OUT and

BNK/SWIFT.OUT .i.e. this stage is completely in control of the USER. Only if the
services are started the delivery advice is formatted, till then the advice will be
sitting in the unformatted queue

3. The format of PRINT advices are user defined

4. SWIFT advices will have to follow an internationally agreed standardized format

5. Advices ready for delivery must be placed in correct ‘Carrier’ queues otherwise
called “Formatted” Queues.

6. Number of applications are involved in determining the process of formatting a

delivery advice -
DE.CARRIER
DE.FORMAT.PRINT
DE.FORMAT.SWIFT; etc., you will learn about these applications in detail as
the course progresses.

T3DEL-The Delivery Subsystem-R12.01 4

 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

T3DEL-The Delivery Subsystem-R12.01 5

 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

T3DEL-The Delivery Subsystem-R12.01 5

 The DE.CARRIER file contains details of all the delivery carriers available.
1.The ID of a record in DE.CARRIER should be a valid entry in the DE.PARM table. DE.PARM
is the Delivery Parameter file that contains only one record called SYSTEM.STATUS, which
contains delivery setup parameters. In this example as you can see the CARRIER record
SWIFT has been defined as an Outward Carrier in the DE.PARM record
2.You can specify which application should be used for formatting a delivery advice in the field
Format Module. This field can contain the value SWIFT or PRINT. The value SWIFT will result
in a record being read from the DE.FORMAT.SWIFT application used to format the advice; and
the value PRINT from the application DE.FORMAT.PRINT.
3.The delivery advice has to be send using a respective carrier. This is specified in the field
Carrier Module. For, the PRINT advice this field will hold the value PRINT. For the SWIFT
advice this field can hold the value “SWIFT” or “GENERIC”. If the value SWIFT is used, then the
formatted advice resides in the default SWIFT queue which is F.DE.O.MSG.SWIFT. If the value
is set to GENERIC then the SWIFT message is sent to the SWIFT machine through an
Interface. An Interface is like a gateway from which messages can come in or go out of T24
system.
4.If the value in the previous field is “GENERIC” then the Interface to be used in order to send
the delivery advice should be specified in the field Interface. The value in this field must be a
valid entry in the application DE.INTERFACE. The actual formatted message in this case will
reside in the file F.DE.O.MSG.<Interface Name>
For e.g.: The Carrier Module is set to “GENERIC”, the value in Interface is
MODEL. Therefore the record in DE.INTERFACE will be MODEL and the formatted message
will reside in the file F.DE.O.MSG.MODEL.

NOTE: The routine DE.OUTWARD will in-turn call the interface routines. These routines are
user-defined, will not be there by default, which contain the logic of reading from the appropriate
file that contains the formatted messages and send it to the appropriate SWIFT machine

T3DEL-The Delivery Subsystem-R12.01 6

 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

T3DEL-The Delivery Subsystem-R12.01 7

 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.

T3DEL-The Delivery Subsystem-R12.01 8

 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.

T3DEL-The Delivery Subsystem-R12.01 9

 1. The ID in DE.FORMAT.PRINT is of the syntax
<DE.MESSAGE TYPE>.<Application Format>.<Format version number>.<LANGUAGE>
E.g.: 900.1.1.GB
Where, the DE.MESSAGE Type is 900
The Application Format is 1 (This value is populated in the DE.O.HANDOFF file and is also present in the
Message Header, from where the Delivery subsystem reads the value).
The Format version number is 1 (This value is defined in the DE.PRODUCT record and is updated into the
Message Header, From where the Delivery subsystem reads the value)
The LANGUAGE is GB (This value is defined in the DE.PRODUCT record and is updated into the Message
Header, From where the Delivery subsystem reads the value)
2. 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
3.LINE(S) Specifies how far down a page the item defined in FIELD/'TEXT' should be printed. Relate it to
specifying which row in Slides “Layout of the PRINT Advice”
4. 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 Slides “Layout of the PRINT Advice”
5. FIELD TEXT specifies 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 contain certain
reserved words defined by T24. Relate it to specifying Field Name in Slides titled “Layout of the PRINT
Advice”
6. If you want to convert the value held by a variable before displaying it, you can do so by specifying
predefined formats in the field Conversion. For e.g.: FIELD TEXT 2 field contains DATE, this is the
variable that holds the value date in the format 20080111 i.e. in the format YYYYMMDD, but if you want to
display it in the format 11 JANUARY 2008, then in the conversion field you will have to specify the value
DATE/F. This refers to the full date format. The table that you see on the screen now contains all the valid

T3DEL-The Delivery Subsystem-R12.01 10

 values that can be used to convert the date before it is displayed in the advice. Please note that this is
only for display purpose and will not change the value in the database. The field Conversion works
similar to specifying Conversions in the ENQUIRY application.

T3DEL-The Delivery Subsystem-R12.01 10

 1. In the earlier slide it was mentioned that the field “Field Text” can also contain certain
reserved words. This slide gives you one such example. In order to print the address on the
Delivery Advice enter the keyword “TO.ADDRESS” in the field “Field Text”. When you do so,
the address mentioned in the field TO.ADDRESS from the Delivery Header record is printed in
the advice.
As you have already learnt the address of a customer is stored in the DE.ADDRESS
application. You can specify which fields of DE.ADDRESS record do you want to print in the
delivery advice. This is done by specifying data in the Conversion in the following syntax:
CUS*<Name of field in DE.ADDRESS record>
For e.g.: CUS*NAME.1 will print the data contained in the field NAME.1 of the corresponding
DE.ADDRESS record
The table that you see now contains sample values that can be given in conversion field starting
with CUS. The examples have been marked with numbers on the slide
Note that the PRINT.1 address for a particular DE.ADDRESS does not contain POST.CODE
and COUNTRY. These values will not be printed on the advice rather it will be substituted with
a blank space in the advice.

2. You can specify a format mask for a particular field by entering it in the field Mask. For e.g.:
The transaction Ref should be delimited by “/”. The data in the field “FIELD TEXT” will be
displayed in accordance to the mask specified in this field

T3DEL-The Delivery Subsystem-R12.01 11

 1. In the DE.FORMAT.PRINT record you can print values on the screen based on
some condition. If the condition is TRUE then the string will be printed if FALSE it
will not be printed. You can specify the name of the variable in DE.MESSAGE on
which you want the condition to be based on in the field Dependent On, A
corresponding operator like “EQ” “NE” “GT” “LT” etc., can be specified in the field
Depend Operand. You can specify the corresponding condition in the field
Depend Cond. For e.g.: You can see the string “WE HAVE TODAY EXECUTED
THE FOLL”, this string will be printed if the RECORD STATUS of the contract that
generated the advice is not equal to REVE, that means the record is live and not
reversed.

2. In the next example if you see the string “WE HAVE TODAY REVERSED THE
FOLL” will be printed if the RECORD STATUS of the contract that generated the
advice is equal to REVE, that means the record is reversed. The table on the
screen shows you a comparison of the fields and how would the corresponding
output look like.
Please note that the condition can be based on any variable that has a value in
DE.MESSAGE.

3. You see that the LINES.23 field has been set to +00 and the Indent value has
been set to 36. This means that the string “OWING” will be appended just after the
previous string. A value of +00 means that don’t print on the next line but print on
the same row where the last string ended.
You can specify if this field can be allowed to overflow onto the next page, if there is
not enough space in the current page, by entering a the value “YES” in the field
Page Overflow. If a field overflows a page when PAGE OVERFLOW is set to NO,
the advice is sent to the Repair Queue.

T3DEL-The Delivery Subsystem-R12.01 12

Codes to be translated by the Formatting modules will have a prefix (defined on the
appropriate Format table) inserted before accessing the Translation table. If a prefix is
not specified, SW (the default) will be used. Field tags use this prefix, e.g. SWIFT field
tag 50, meaning "Ordering customer" will be entered on the Delivery Translation table
with a key of SW50. If a different description of a tag is required when it occurs in a
particular message type then the description should be entered in a
DE.TRANSLATION in the form SWtt-mmm for example, SW50-900 for tag 50 in
MT900.

13
The list of existing codes can be viewed by executing the command
“DE.TRANSLATION L”.
Open a existing record and view the translation description.

Record ID: The ID is composed of a prefix (default SW) and a field.

A code requiring translation should be prefixed with 'SW' if it is a SWIFT code.
Otherwise it should be given a meaningful prefix to differentiate it from other codes
with the same value, or from other translations required for the same code - such as
shorter versions for abbreviated messages.
Example SWIFT field tag 50, meaning 'Ordering Customer' will be entered on Delivery
Translation with a key of SW50.

Description : A meaningful expansion of the code.

14
 1. You can get language specific conversion done by specifying the keyword TABLE in the
Conversion field. If the value is TABLE then the delivery subsystem will look for a
corresponding record in an application called DE.TRANSLATION.
For e.g.: The TRANSFER TYPE variable contains the value AC in case of this contract. Now
in the print advice you don’t want to display the value “AC”, but the string “ACCOUNT
TRANSFER”. Then in the field conversion specify the value as TABLE FT.
2. The corresponding record in DE.TRANSLATION will be FTAC. The field Description in the
translation record will contain the string to be printed. This is a language multi-value field,
therefore depending on the language of the advice, the Description will be displayed. The
major use of the translation table is when you want to display meaningful sentences in the
advice rather than cryptic codes.
3. Three types of record are possible in the DE.TRANSLATION application. The table that you
see on the screen gives you an example of the three types of records.
3.1 If the conversion is specified as just the keyword “TABLE”, then the record looked up in
DE.TRANSLATION is SW followed by the value of the variable
3.2 If the conversion is of the syntax “TABLE XXX”, then the record looked up in
DE.TRANSLATION is XXX followed by the value of the variable
3.3 If the conversion is of the syntax “TABLE XXX/”, then the record looked up in
DE.TRANSLATION is XXX/ followed by the value of the variable
An example of this is shown on the slide with CURRENCY variable and the value as USD.
The corresponding record ID’s in DE.TRANSLATION has also been given

Please go through the contents of the table to understand the records created in
DE.TRANSLATION. Also notice the Output on the screen and try to understand this output
with the contents of the DE.FORMAT.PRINT record on the left hand side of the screen

T3DEL-The Delivery Subsystem-R12.01 15

The setup translation application, DE.AUTO.TRANSLATION is provided mainly to
setup the Delivery Translation table initially, but can also be used to update the
Translation table from time to time.

The Translation table will be delivered with various records, which should not be
deleted. In addition, there are records required by formats, which are file dependent
and must be added to the Translation table after the files have been updated. E.g.
category codes are passed to Delivery for translation in printed messages.

16
When T24 is installed, after the files mentioned above have been entered, records
must be copied from the appropriate files to the Translation table using
DE.AUTO.TRANSLATION before the Delivery services can be run to process
messages.

As seen in the input screen of DE.AUTO.TRANSLATION it is possible to choose the

file, prefix, separator as well as the field to use for the text.

When run, Update mode can be for New (create new records only) or ALL update all
records. The last run date is recorded to show the last activity.

If a field is specified on the format tables as requiring translation, the field, with the
appropriate prefix will be looked up on the Translation table. If the record is not found
on the Translation table, the message will go into Repair. Therefore, it is important
always to keep the Translation table up to date. If new records have been added to
any of the above files, the Translation table must be updated accordingly, either by
running set-up translation or by entering the records directly onto the Translation table.

17
DESCRIPTION A standard detail field that can be used to specify what this particular
record is set-up for and the fields used to create the resultant DE.TRANSLATION
records.

FILE.NAME This is the file that will be read when creating DE.TRANSLATION
records.

PREFIX The prefix is the initial part of the DE.TRANSLATION record key that this
application will create. Used by delivery by identifying this part of the id means that the
user can specify a short meaningful prefix.

SEPERATOR The seperator is used in building the key to the DE.TRANSLATION

record that will be created or updated.
If the user wants to create records such as TXNL/1000 then TXNL is the prefix chosen
and entered in the PREFIX field, / as the seperator defined here and 1000 is the id of
the TRANSACTION file.

FIELD.NAME The name of the field from where this utility will extract the description
for the DE.TRANSLATION record.

UPDATE This option is to specify if NEW records only are to be created, or whether
ALL records should be done - both new and existing.

LAST.RUN This date field is provided for future expansion but can be entered for
information purposes at present.

18
 FQY and API are Reserved for future expansion

T3DEL-The Delivery Subsystem-R12.01 18

 1. It is possible to convert the data in a field by displaying the data from another
application by using the LINK function in the Conversion field. The syntax is as
follows:
LINK*Name of the Application>Field in the application>Sub Value or Multi Value
position of the field or “L” to pick up language multi value
For e.g.: LINK*CURRENCY>CCY.NAME>1
Instead of specifying the value USD in the output, the value US Dollar can be printed
by reading the record USD in the CURRENCY table and displaying the contents of the
field CCY.NAME.
Remember, you can use the LINK functionality, only if the data contained in
FIELD.TEXT is the ID of the application to be linked to.

2. It is possible to display an amount field in WORDS. This is done by specifying the

keyword “WORDS” in the Conversion field. A corresponding record is read in the
application DE.WORDS. This application contains 1 record per language code in the
LANGUAGE table. Based on the language of the advice the corresponding
DE.WORDS record is read. The UNITS, TENS, HUNDREDS position are described in
this record.
For e.g.:
The FIELD.TEXT displays the variable CURRENCY.AMT. The value held in this
variable is 825,000/- The conversion for this field has been set to WORDS. The advice
is in English, therefore the corresponding record read in DE.WORDS is GB. Using the
logic in DE.WORDS, the amount is converted and finally the print advice contains the
string “Eight Hundred and Twenty five thousand” in the output instead of 825,000.

T3DEL-The Delivery Subsystem-R12.01 19

 1. You are now going to learn a sample SWIFT message type - MT900, which stands
for Confirmation Of Debit
2. For e.g.: On 13 May 2008, Crédit Suisse, Zürich, requests Chase Manhattan
Bank, New York, to pay $233,530 (USD) to Berliner Bank (a/c no. 9-9876543),
Berlin, under reference 5482ABC
3. Chase sends the following confirmation to Crédit Suisse:
4. Once the money has been withdrawn from Credit Suisse’s account, Chase
Manhattan Bank, New York, sends
5. A MT 900 message to
6. Credit Suisse, Zurich, informing them that money has been withdrawn from their
account and credited to Berliner Bank

T3DEL-The Delivery Subsystem-R12.01 20

 Unlike the PRINT advice, the SWIFT advice has a standard internationally agreed
upon format.
1.A SWIFT message is divided into 2 portions, the SWIFT message header and the
Data portion.
2.The data portion of the SWIFT message contains tags. All swift tags have a
predefined meaning which should be populated with appropriate data.
3.A sample SWIFT message, generated for the scenario in the previous slide, is on
the left, the explanation of the tags is given in the table on the right of the presentation.
The sender and receiver of the message is in the SWIFT message header and is
standard for all SWIFT message Types.
If you notice, the BIC code of the sender and receiver bank has been
specified in the HEADER.
The data portion of the SWIFT message contains tags, For e.g.: TAG
20 in MT900 message should contain the Transaction Reference Number. Tag 21 in
MT900 message should contain Related Reference number. TAG 32A, is a
combination of 3 values, the Value date of the transaction, the Currency CODE, and
the Amount.

In T24, a record in the application DE.FORMAT.SWIFT, defines how the data content
of a message is to be converted for SWIFT. The header and trailer required by SWIFT
are standard and generated automatically. They are not specified in this application.

T3DEL-The Delivery Subsystem-R12.01 21

 1. The ID of a record in DE.FORMAT.SWIFT is of the SYNTAX Message Type, followed by the
Application Format and the Format version number.
For e.g.: 900.1.1
Only one Format SWIFT record allowed per Message Type; therefore the Application Format and
Format Version Number is always 1. The Message Type entered must be on the DE.MESSAGE table.
2. You will Specify the SWIFT Tag in the field “Field Tag”. The value entered must be on the
DE.TRANSLATION table prefixed by 'SW'. This not only provides validation for the Field Tag, but also
enables descriptive 'enrichment' when a message needs to be printed, displayed on the screen.
For e.g.: The TAG 20, will have an entry in DE.TRANSLATION called SW20, which will contain a
description of the tag
The content of the field i.e.. data is held in the corresponding variable defined in DE.MESSAGE and is
specified in the field “Field Name”.
For e.g.: The value C11126A1378 is held in the variable TRANS REF
3. If you notice TAG 32A is a combination of 3 fields, the date, currency and amount.
How should such a field be formatted?
When specifying the format of this field Value date will have its Field tag entered as 32A,
4. but Currency Code and
5. Amount will then be entered in this record without Field Tags.
Specifications of Value Date, Currency Code and Amount must be consecutive on the Format SWIFT
record
Please notice that the Value date for SWIFT is six digits and not 8 digits which is the normal date format
in T24. Therefore the Conversion DATE has been applied which will change the date from
YYYYMMDD format to DD MM YY format (As learnt on slide titled “DE.FORMAT.PRINT”)

T3DEL-The Delivery Subsystem-R12.01 22

 You can notice the Conversion specified as AMT for the Field Name SWIFT AMOUNT. This conversion
removes a sign if it exists.

T3DEL-The Delivery Subsystem-R12.01 22

T3DEL-The Delivery Subsystem-R12.01 23
 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

T3DEL-The Delivery Subsystem-R12.01 24

 Open the corresponding record in DE.O.HEADER,
Notice that the fields Disposition and Msg Disposition have been set to
“FORMATTED”

T3DEL-The Delivery Subsystem-R12.01 25

 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

The name of the executed enquiry is MB.DE.MSG.SUM

T3DEL-The Delivery Subsystem-R12.01 26

 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.

T3DEL-The Delivery Subsystem-R12.01 27

 Steps To Generate A Delivery Advice - RECAP

1. Input a contract and authorise it. APPLICATION.HANDOFF will populate values

in DE.O.HANDOFF

2. Define variables to hold values from DE.O.HANDOFF

3. Link the variables and the positions in DE.O.HANDOFF

4. Format the advice

5. Finally the PRINT Advice is ready

T3DEL-The Delivery Subsystem-R12.01 28

 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?

3. This is done by starting Services (record in TSA.SERVICE) for different types of

carriers.

T3DEL-The Delivery Subsystem-R12.01 29

 1. Carriers are nothing but the mode of transportation of an advice to its final
destination. The Carrier Control stage send the appropriate advice to the physical
printer or to the SWIFT machine for e.g. ST400.
2. In case of PRINT ADIVCE, we have to start a service TSA.SERVICE
>XXX/DE.PRINT.
3. For SWIFT Advice, if we are using an INTERFACE, then we need not start a
service. The interface routines will take care of sending the advice to the SWIFT
machine
4. For SWIFT Advice, if we are not using an INTERFACE, we have to start a service
called TSA.SERVICE > XXX/SWIFT.OUT

T3DEL-The Delivery Subsystem-R12.01 30

 This slide shows you the delivery advice once the Carrier Control Phantoms have
been started. Once messages have been output to the spool queues, the
MSG.DISPOSITION in DE.O.HEADER is updated to "ACK" and the message is
removed from the formatted queue

Note: If HOLD.OUTPUT on DE.ADDRESS is set to “Y”, i.e. all printed output for a
customer for a particular address is to be held, (e.g. if the customer has no contact
address but just comes into the bank on a regular basis to collect all correspondence),
the messages are not spooled but instead are written to the hold control file,
HOLD.CONTROL and in a file called F.CUSTOMER.HOLD. The message is
acknowledged by delivery at this stage. When the customer comes in, all his
messages and reports can be printed using PRINT.CUST.OUTPUT or by verifying a
record in HOLD.CONTROL. The ID to a record in HOLD CONTROL can be found in
the F.CUSTOMER.HOLD file.

T3DEL-The Delivery Subsystem-R12.01 31

 A delivery advice goes through 3 stages to be complete. This slide will help you
understand the life cycle of a delivery advice.

1. The first part of the life cycle is called the Mapping Stage.
In this stage we decide what to display in the delivery advice i.e.. its contents. When a
user authorises a record, it goes from the $NAU file to the LIVE file, during this
transition the mapping phase is also executed. A user need not intervene for the
Mapping phase to be executed.

2. The next part of the life cycle is called the Formatting Stage
In this stage we decide How to display the delivery advice i.e.. its format, in other
words how should the delivery advice look like. This stage is invoked by starting
individual services like PRINT.OUT and SWIFT.OUT, which in turn take care of
formatting the delivery advice. The USER needs to start the service for the delivery
advice to be formatted, so the control is in the hands of the user.

3. The final part of the life cycle is called the Carrier Control Stage
In this stage we decide where to send the output i.e. either to the PRINTER if it’s a
PRINT Advice or to the SWIFT machine if it’s a SWIFT Advice. This stage is invoked
by starting services for different type of advices.

T3DEL-The Delivery Subsystem-R12.01 32

 1. Delivery messages can be resubmitted in T24 in case an error occurred

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

An example of an error that can occur is because a of a missing DE.FORMAT.PRINT

record. To correct the error, add the FORMAT record to DE.FORMAT.PRINT, amend
the DE.O.HEADER record changing the MSG.DISPOSITION to "Resubmit" and
authorise the record.

The MSG.DISPOSITION will be changed to "Resubmitted" and a new multi-value set

will be added to the end of the record with the same details as the message being
resubmitted. This is so that the history of the message is available, with the fact that
the first time an attempt was made to format the message an error occurred, the error
message still being set on the original copy of the message. When the message is
resubmitted, the message will be added to the Unformatted queue for another attempt
at formatting and removed from the Repair queue

T3DEL-The Delivery Subsystem-R12.01 33

T3DEL-The Delivery Subsystem-R12.01 34
T3DEL-The Delivery Subsystem-R12.01 35
 You are now going to see a demo of how to resubmit a delivery advice in T24

T3DEL-The Delivery Subsystem-R12.01 36

 1. What if the Customer orders the Bank to use another address for a while, since he
is not available at his permanent residence?

2. The delivery advice must be re-routed. This can be done by setting the
MSG.DISPOSITION field in DE.O.HEADER to REROUTE

3. This action will then cause the delivery system to look into an application called
DE.ALTERNATE to decide the address

4. When a Message is to be 'Rerouted' this file is searched for a record providing a

replacement for the Carrier Addr-No, Language, Format and Copies parameters that
would otherwise be taken from the DE.PRODUCT record. The original Language,
Format and Copies will be unchanged if they are not on the DE.ALTERNATE record.

T3DEL-The Delivery Subsystem-R12.01 37

 Suppose the customer 111204 is not available at his PRINT.1 address and the message needs
to be send to his PRINT.2 address. You will have to create a record in DE.ALTERNATE based
on the DE.PRODUCT record. The ID of a record in DE.ALTERNATE should be of the syntax
Company Code, followed by C- Customer Number or A - Account Number, followed by the
CARRIER name followed by a value 1, 2 or 3.
The Customer number or the Account number portion of the ID is not mandatory
E.g.: GB0010001.C-111204.PRINT.1

How will you decide the ID of the record to create in DE.ALTERNATE?

You will be able to answer this question with the help of a simple example. The DE.PRODUCT
record read during the mapping stage was GB0010001.C-111204.900.FT. Inside this record the
Carrier Addr No field was set to PRINT.1. Now this customer is not available temporarily at his
PRINT.1 location and wants you to send the delivery advices to his PRINT.2 location. The
record in DE.ALTERNATE should be created at the same level as that of the DE.PRODUCT
record. Which means that if a customer level record is read in DE.PRODUCT, then a customer
level record should be created in DE.ALTERNATE. Therefore the ID of a record in
DE.ALTERNATE, in this case will be GB0010001.C-111204.PRINT.1

1.You can change where the advice must go to and how it must go in the field Carrier Addr No.
In this example this field should contain PRINT.2
2.You can change the Language if required in the field Language
3.The Format Version Number and then number of Copies can also be changed.

4.Once the record in DE.ALTERNATE application is read, the DE.O.HEADER record is updated
accordingly. If a record is not found matching the current transaction details in
DE.ALTERNATE, the advice is sent to repair.

T3DEL-The Delivery Subsystem-R12.01 38

 1. Using the DE.DISP.CONTROL application the Message Disposition of a Delivery
Advice can be changed based on certain conditions

2. Disposition checks are done at the Mapping stage itself

3. Conditions should be based on fields in DE.O.HEADER record

4. Record ID in DE.DISP.CONTROL is numeric

5. When transaction is entered and goes through mapping stage, the disposition
control table is examined in numerical order until a record is found whose
conditions are satisfied or there are no further records on the Disposition control
table. Thus, if a message matches conditions specified on disposition control
records 10 and 50, only record 10 will be applied to the message. Therefore, it is
important when entering records on the Disposition control table to assign the key
according to the importance of the record.

6. Multiple conditions within the same record is always searched with the AND
clause.
For e.g.: If we have 2 multi value sets in the DE.DISP.CONTROL record like
CARRIER = SWIFT, AMOUNT GT 100000, the system joins these two condition
with AND.

T3DEL-The Delivery Subsystem-R12.01 39

 You will now see how to create a record in DE.DISP.CONTROL. Imagine that you have a requirement, where
all MT900 generated from the FUNDS.TRANSFER application for currency equal to USD and amount greater
than 100,000 must be put on hold.

1. Create a record in the DE.DISP.CONTROL application with ID as 1

2. The field against which the condition will be based should be entered in the field “Field Name”.
3. The operand should be entered in the field “Operand”. The operand can be equal to, less than, greater
than or not equal to
4. The value should be entered in the field Condition.
Fields “Field Name” to “Condition” for a multi value set, therefore multiple conditions can be set. All conditions
will be joined with the AND clause.
5. If all the conditions are met, then action to be performed is entered in the Status field. The following values
can be entered in the status field: HOLD, DELETE, WAIT, REROUTE, RESUBMIT, RELEASE, PRINT.
The values HOLD, RELEASE and WAIT affect the status of the advice in DE.O.HEADER
The values ‘DELETE’, ‘REROUTE’ and ‘RESUBMIT’ affect the Message Disposition of the advice in
DE.O.HEADER
PRINT causes the copy of the advice to be printed
- When the STATUS is HOLD, the advice is written into F.DE.O.HOLD.KEY. To remove the advice from HOLD
file, the Status of the message has to be changed to RELEASE in the DE.O.HEADER record
- When the STATUS is DELETE, no further processing takes place. The Delivery Advice is not produced
-When the STATUS is REROUTE, records are searched in DE.ALTERNATE to reroute the advice.

An advice can also he set to HOLD for a certain amount of time in the F.DE.O.HOLD.KEY file.
'HOLD HH:MM' (where HH:MM is the time of day to release a message) For e.g.: HOLD 21:30 will
hold the record in the HOLD file till 9.30 pm.
WAIT HH:MM (Where HH:MM is a period of time) For e.g.: WAIT 06:00 will hold the record in the
HOLD file for 6 hours.

T3DEL-The Delivery Subsystem-R12.01 40

 To release a record from the HOLD file for a particular Date and time, you need to start the
service in TSA.SERVICE called BNK/DE.DISP.TIMECHECK

T3DEL-The Delivery Subsystem-R12.01 40

 It is recommended that the archiving process be run after the end of day has been
completed, but before users are allowed to sign on. However, since archiving removes
data, which is no longer, used, it can be run whilst the system is being used.
The system on which archiving is to be run should be fully backed up to tape. It is
important to note that archiving is a one-way process: data cannot be restored
afterwards, except by fully restoring the database back to the point of pre-archiving.

T3DEL-The Delivery Subsystem-R12.01 41

 It is recommended that both the services DE.EOP.OUTWARD and DE.EOP.INWARD
are run. However, if no inward messages are received by T24, it is not necessary
to run Inward End of Period. A report will be produced listing any messages, which are
awaiting acknowledgement and still outstanding from the previous period. A field
EOP.AWACK.REPORT in DE.PARM indicates whether this report has to be produced
or not. A blank value indicates, the report has to be produced. A value of NO
indicates that the report need not be produced.

T3DEL-The Delivery Subsystem-R12.01 42

T3DEL-The Delivery Subsystem-R12.01 43
T3DEL-The Delivery Subsystem-R12.01 44
T3DEL-The Delivery Subsystem-R12.01 45
T3DEL-The Delivery Subsystem-R12.01 46
 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. If an INTERFACE is being used, then the
formatted advice is put in a file called F.DE.O.MSG.<INTERFACE>. The FORM.TYPE is
substituted with data specified in the field FORM TYPE in the corresponding DE.FORMAT.PRINT
record, and the INTERFACE, if used, is substituted from the DE.CARRIER record.
In order to send the advice to the physical printer or the SWIFT machine, services DE.PRINT. and
SWIFT.OUT are started for PRINT and SWIFT advices respectively.

T3DEL-The Delivery Subsystem-R12.01 47

  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
 F.DE.O.HISTORY – Contains all the formatted Delivery Advices that are sent
out of T24.

T3DEL-The Delivery Subsystem-R12.01 48

T3DEL-The Delivery Subsystem-R12.01 49
T3DEL-The Delivery Subsystem-R12.01 50
 1 What is the name of the core T24 routine that is run as the service
BNK/PRINT.OUT?
• DE.OUTWARD
• DE.INWARD
• DE.OFS.PROCESSING
• DE.O.OUTWARD
2. There can be more than one record in DE.FORMAT.SWIFT for a particular
message type?
• TRUE
• FALSE
3. An advice in written in the HOLD file that is F.DE.O.HOLD.KEY. How can this
advice be removed from the HOLD file and be sent for formatting?
• Set the MSG.STATUS field in the corresponding DE.O.HEADER to RELEASE
• Set the MSG.DISPOSITION field in the corresponding DE.O.HEADER to
RESUBMIT
• Set the MSG.DISPOSITION field in the corresponding DE.O.HEADER to
REROUTE
4. When is the DE.ALTERNATE table accessed?
• When the MSG.STATUS field in the corresponding DE.O.HEADER is set to
RELEASE
• When the MSG.DISPOSITION field in the corresponding DE.O.HEADER is set to
RESUBMIT
• When the MSG.DISPOSITION field in the corresponding DE.O.HEADER is set
to REROUTE

T3DEL-The Delivery Subsystem-R12.01 51

 5. If an interface is to be used, How will you tell the delivery subsystem to use it?
• Specify the name of the interface in DE.FORMAT.PRINT
• Specify the name of the interface in DE.CARRIER
• Specify the name of the interface in DE.FORMAT.SWIFT
• Specify the name of the interface in DE.PRODUCT
6. The APPLICATION.FORMAT to be used in DE.FORMAT.PRINT is passed to the delivery
subsystem by the application logic i.e.. its hard coded.
• TRUE
• FALSE

T3DEL-The Delivery Subsystem-R12.01 51

 1 What is the name of the core T24 routine that is run as the service
BNK/PRINT.OUT?
• DE.OUTWARD
• DE.INWARD
• DE.OFS.PROCESSING
• DE.O.OUTWARD
2. There can be more than one record in DE.FORMAT.SWIFT for a particular
message type?
• TRUE
• FALSE
3. An advice in written in the HOLD file that is F.DE.O.HOLD.KEY. How can this
advice be removed from the HOLD file and be sent for formatting?
• Set the MSG.STATUS field in the corresponding DE.O.HEADER to RELEASE
• Set the MSG.DISPOSITION field in the corresponding DE.O.HEADER to
RESUBMIT
• Set the MSG.DISPOSITION field in the corresponding DE.O.HEADER to
REROUTE
4. When is the DE.ALTERNATE table accessed?
• When the MSG.STATUS field in the corresponding DE.O.HEADER is set to
RELEASE
• When the MSG.DISPOSITION field in the corresponding DE.O.HEADER is set to
RESUBMIT
• When the MSG.DISPOSITION field in the corresponding DE.O.HEADER is set
to REROUTE

T3DEL-The Delivery Subsystem-R12.01 52

 5. If an interface is to be used, How will you tell the delivery subsystem to use it?
• Specify the name of the interface in DE.FORMAT.PRINT
• Specify the name of the interface in DE.CARRIER
• Specify the name of the interface in DE.FORMAT.SWIFT
• Specify the name of the interface in DE.PRODUCT
6. The APPLICATION.FORMAT to be used in DE.FORMAT.PRINT is passed to the delivery
subsystem by the application logic i.e.. its hard coded.
• TRUE
• FALSE

T3DEL-The Delivery Subsystem-R12.01 52

 1. In this Learning Unit, you learnt about Outward Delivery in T24

2. You will now be able to

2.1 Explain the flow of the Outward Delivery subsystem with respect to the
stages Formatting and Carrier Control
2.2 Understand the applications that are read during this stages
2.3 Configure records in this application if need be
2.4 Understand the overall working of OUTWARD Delivery

T3DEL-The Delivery Subsystem-R12.01 53

T3DEL-The Delivery Subsystem-R12.01 54