Delivery

LAKSHMI PALANIKUMAR
Introduction

 The process of sending advices is achieved

through a module in T24 called ‘DELIVERY’
 The Delivery System manages the flow of all
messages from T24, such as
 confirmations,
 payments and
 advices
 Whilst giving users full control over formatting
and language of presentation.
Introduction

 Messages are generated automatically as soon

as contract entry is complete or when a
scheduled diary event occurs.
 All messages may be either printed or sent via
electronic carrier systems, such as SWIFT, Telex.
 Messages from external carrier systems are
received by the Delivery System
 If necessary, formatted according to the user-
determined requirements for printing
Introduction

 For example:
 When a Funds Transfer transaction is entered and
approved
 It usually requires sending of a credit advice to
one address and a debit advice to another,
together with one or more payment messages.
Classification of
Advices Type of Advices

Deal Slips Delivery Advices

Generated for any application Generated only for contract based
applications.
Can be generated during any of the
functions (I,A,C,D etc) Generated only when contracts are
authorized.
Can be generated only online
Generated both online and offline
Normally printed and handed over to
the customer across the table Normally printed during COB.
Classification of
Advices
 Delivery advices

Inward Outward
(Advices received from (Advices sent to
other banks) customers and other
banks)
Delivery Carriers
Carrier

Print Swift Telex

Delivery carrier

 SWIFT (Society for Worldwide Interbank

Financial Telecommunication) carrier
 Swift carrier is used to send and receive SWIFT
messages
 SWIFT is the standard that is followed by banks all
over the world to communicate with one another
 Header and trailer required by SWIFT are
generated automatically as they are standard
 Maximum size of a Swift message is 2000
characters
Delivery carrier

 Print Carrier
 Print carrier is used to print the delivery advices.
 It is possible to define different formats so that a
document can be printed in different versions or
languages as required by a particular customers
 Telex
 Not used
 Similarly for each interface different carriers has
to be defined.
Sample Print advice
Sample Swift advice
Flow of Messages

 The main process within Delivery involves

mapping, formatting and the Carrier Control
processes.
 These processes are run as phantom/services
jobs
Flow Of A Delivery
Advice
Authorize a record in a contract based
application
Pass back delivery
reference ID

APPLI CATI ON. HANDOFF

Write data to DE.O.HANDOFF

Error
I nternally call DE.O.MAP.MESSAGES
Map data bya
Authorise re ferrin
record ga
in to DE.MA
contract PPI NG
based
application

Automatic Creation of DE.O.HEADER

Repair Q
Updated in
DE.O.HEADER
Unformatted
Q

Start the Print and Swift services in

TSA.SERVI CE

Read DE.PRODUCT – Obtain the carrier to

be used

Read DE.ADDRESS – Obtain the address

for the carrier

DE.FORMAT.PRI NT

Read DE.FORMAT.XXX

DE.FORMAT.SWI FT
Error

Formatted Q
Updated in
DE.O.HANDOFF
TSA.SERVICE

 Services are controlled by use of TSA.SERVICE

 TSA.SERVICE management will control these
services either on a start/stop basis or automatically.
 The processing is now common and is the same
concept used for running the Close of Business
processes (COB).
 Formatting is controlled by a service for each carrier
such as SWIFT.OUT/IN,PRINT.OUT/IN, on TSA.SERVICE
 Each service can be run separately and given the
appropriate number of agents to deal with the
volume for that carrier
TSA.SERVICE

 Enter TSA.SERVICE in the Command line

 Start the Services individually

 TSM
 PRINT.IN
 PRINT.OUT
 SWIFT.IN
 SWIFT.OUT
TSA.SERVICE
TSA.SERVICE
DE.PARM

 It is a file containing a single record that holds a

number of parameters for controlling the
processing of messages.
 Parameters that allow the operator to shut
down the carrier control modules, and the
inward and outward formatting modules.
 Shut-down can be:
 Urgent (after the message currently being
processed.)
 Normal (when all queues have been processed.)
DE.PARM
DE.MESSAGE

 This table defines the contents of each basic

Message Type
 DE.MESSAGE contains only variable names and
attributes for each message
 Attributes of the field such as
 Field name,
 Length of the field,
 Single value or a multi-value,
 Mandatory or optional etc are specified here
 It also determines whether a testkey is required for
each message type
DE.MESSAGE

 Also specifies whether messages of each

message type can be deleted, copied or
translated
 Whether test-keys are required for Telex
messages
 It is the DE.MESSAGE table that we define the
fields that hold the data extracted from the
DE.O.HANDOFF record.
DE.MESSAGE
Workshop 1 -
DE.MESSAGE
 Input a new field in the message type “900”
Solution 1
DE.MAPPING

 Variables defined in DE.MESSAGE are assigned

with a value through DE.MAPPING
 It maps variable name with the array position in
Handoff for each message type
 Id to this table contains 3 elements.
 Message type. Application. Format
 Example : 900.FT.1 or 900.LD.1
DE.MAPPING

 Defines where data for outward messages and

message headers is located within the raw
message data passed to Delivery from the
banking applications
 It is the DE.MAPPING table that allows us to
map the fields defined in the DE.MESSAGE table
with the various values in the DE.O.HANDOFF
record
DE.MAPPING

 The banking applications do not format and

send messages themselves.
 They send between 1-9 records to the Delivery
System which then uses the Mapping Table to
locate each field from the raw data
 Great care is needed when setting up the
Mapping Table as the system cannot check that
correct fields are being referenced within the
banking application records.
DE.MAPPING

 Note that both header and message must be

mapped.
 The following fields must be Mapped, but
CUSTOMER and LANGUAGE can be blank:
 CUSTOMER
 COMPANY
 CUS.COMPANY
 LANGUAGE
 DEPARTMENT
 TRANS.REF
DE.MAPPING

 MessageType.
ApplicationName.Subclassification
 Where, Sub classification is hard coded by default
to 1
 Through parameterization we can set the value
for sub classification
 Parameterization is available for some
applications
 For example LC uses the application called
EB.ADVICES to set the sub classification
DE.MAPPING
DE.FORMAT.PRINT/
SWIFT
 DE.FORMAT.PRINT table defines a format for a
printed document.
 It is possible to define different formats so that
a document can be printed in different versions
or languages as required by particular
customers.
 This table used to design the layout of the
advice, specify headings (if any), the
indentation, the position of fields etc.
DE.FORMAT.PRINT/SWIFT

 This table is used to determine how the message

should be formatted
 For producing a formatted print message,
formatted SWIFT message, etc.
 The formatted message is then placed on the
appropriate Formatted queue e.g. Formatted
SWIFT, Formatted Print, etc.
 Record id to this file contains 4 elements
 Message type. Application format. Copies.
Language
 Example : 900.LD1.1.GB
DE.FORMAT.PRINT
DE.FORMAT.SWIFT
 Similarly formatting of data, or the
advice layout for SWIFT messages are
done in a file called DE.FORMAT.SWIFT
APPLICATION.HANDOF
F
 When a transaction, that requires the sending of
a message, is authorized, the Delivery process
“APPLICATION.HANDOFF” is invoked.
 This passes all the details of the message to a file
called “DE.O.HANDOFF” whilst passing back a
unique identifier to the application, the Delivery
reference id.
 Now Raw message is available in DE.O.HANDOFF
 Then delivery advice can be generated by
formatting using DE.MESSAGE, DE.MAPPING
and DE.FORMAT.PRINT records.
APPLICATION.HANDOFF

 APPLICATION.HANDOFF routine
 Gets triggered as soon as a contract is authorised
 Will extract values from the contract and write it
on to DE.O.HANDOFF.
 We cannot instruct APPLICTION.HANDOFF
 What values need to be picked up from the contract
 Which position in DE.O.HANDOFF the extracted
values need to be written to
DE.O.HANDOFF

 It is a 10 dimensioned array whereas each

dimensioned array is a dynamic array.
 First 7 arrays are used by the system to populate
values.
 Last 3 arrays to be used by users to populate user
defined values.
 DE.O.HANDOFF is not an application and hence
cannot be viewed from T24.
 Handoff information can be viewed by using
SEE.HANDOFF from the jbase prompt or Enquiry
DE.HANDOFF.DETS from T24
 SEE.HANDOFF <Delivery Reference Id>
 ENQ DE.HANDOFF.DETS
DE.O.HANDOFF

 ID : Delivery Reference ID
 Contains 10 fields (10 dynamic arrays)
DE.O.HANDOFF
APPLICATION.HANDOFF will write values into any of the position
in arrays 1 to 8 in DE.O.HANDOFF
Arrays 9 is reserved for user defined values
Array 10 not used

100069 Customer Number - Position 1.1

080801VMUSD Value Date - Position 2.1
26937VM080802VM30.42 Currency - Position 2.2
2VM21051 Draw down account - Position 3.1
Maturity Date - Position 3.2
1500 Interest Amount - Position 3.3
CUR Interest Rate - Position 4.1
2010.01 Status - Position 4.2
Loan Amount- Position 5.1
Dynamic array 8
Currency- Position 6.1
Dynamic array 9 Limit Reference No- Position 7.1
Dynamic array 10
DE.O.HANDOFF

 Now we have the values in DE.O.HANDOFF.

How we take it to the advice?
 Define variables that can hold values extracted
from DE.O.HANDOFF
DE.O.HANDOFF

 Now that we have the variables

defined, how do we populate data into
them?
 Link the variables and appropriate
position in DE.O.HANDOFF
DE.O.HANDOFF
Now that the variables have data,
we need to just format them and display them in the required
format similar to formatting enquiries
Link the steps in T24

 Input and authorize a contract

 Populate of DE.O.HANDOFF are done by T24
 Define the variables in DE.MESSAGE
 Link the variables and positions in DE.MAPPING
 Positions are available in DE.O.HANDOFF
 Format the advice
 DE.FORMAT.PRINT or
 DE.FORMAT.SWIFT
Output of DE.O.HANDOFF

 SEE.HANDOFF works only from Classic mode

 Execute SEE.HANDOFF <Delivery Reference
ID> from the database prompt
Output of DE.O.HANDOFF
DE.PRODUCT

 Product information consists of status (normal,

hold or delete), carrier/delivery address, which
version of the format should be used and how
many copies should be made.
 Product records may be specified for:
 A particular company
 A customer
 An account (Note that this is only applicable
for Statement types message)
DE.PRODUCT

 And each of the above may be specified for:

 All message types
 Specific message types
 All banking applications
 A specific application
DE.PRODUCT

 The key of the Product table is composed as

follows:
 Company code followed by "."
 C-customer number followed by "." or A-account
number followed by "."
 (Not present for company level records)
 Message type or "ALL" followed by "."
 Application, "ALL" or xxyy where xx is the
application code and yy is the Funds Transfer
product code
DE.PRODUCT
DE.PRODUCT
DE.CARRIER

 This file contains details of all the carriers

available in Delivery.
 To enable any of the carriers specified on
DE.CARRIER, you must specify the carrier on
the Delivery Parameter file, DE.PARM.
 The id of the carrier table is the name of the
carrier, as used in DE.PRODUCT
 Each record contains the address type to be
used for the carrier
DE.CARRIER
The types of carriers available are
DE.CARRIER

 ADDRESS
 Specifies the type of address to be used for this
carrier. This is usually the same as the record id.
 FORMAT.MODULE
 Specifies the formatting module to be used
 The rules describing the formatting of the
messages should therefore exist on the file,
DE.FORMAT.format-module,
 e.g. DE.FORMAT.SWIFT
DE.CARRIER

 CARRIER.MODULE
 Specifies the name of the carrier module.
 For most of the existing modules this will be the
same as the formatting module .
 Eg., PRINT,SWIFT
 For new interfaces it will be GENERIC. If GENERIC
is specified, messages will processed by
DE.CC.GENERIC.
 IN.FORMAT.MODULE
 Specifies the inward formatting module to be
used.
DE.CARRIER
DE.ADDRESS

 DE.ADDRESS File contains

 The names and address of a bank's customers
and also of each company within the banking
organization.
 Address for Print carrier for each customer is
created automatically by the system when the
customer record is authorized.
 SWIFT address has to be created manually. The
delivery address for the Customer has to be
created explicitly
DE.ADDRESS

 Record contains 3 elements

 Company code. C-Customer .Carrier
 Example:
 US0010001.C-1000.PRINT.1
 US0010001.C-1000.SWIFT.1
DE.ADDRESS
DE.ADDRESS

Delivery address should be of this format.

Length of this field should be either 8 or 11 characters
only.
First four should be characters only.
DE.DISP.CONTROL

 In addition to all the conditions available in the

Delivery Product file this table can hold a
variety of special controls.
 For example, it may specify:
 All messages for Hong Kong branch must be held
until midnight.
 All messages with amounts greater than two
million dollars are urgent and require immediate
confirmation.
DE.DISP.CONTROL

 All messages for a particular carrier must be

rerouted. (In this case the Alternate Carrier List is
looked up to find the new carrier.)
 Print a copy of all messages, which have a
Message Type of 100 and an amount of more than
USD 500000 or GBP 200000.
DE.O.HEADER

 DE.O.HEADER shows the status, format used,

carrier and address of the Delivery message.
 Record id is Delivery reference key
 Field(4) ‘Disposition’ shows the status of the
message. If the Disposition is
 FORMATTED -Message can be viewed.
 UNFORMATTED-Formatting phantom has to be
initiated
 REPAIR-Error details would be available. Change
the Disposition manually as ‘RESUBMIT’ after
making necessary correction and
authorize the record.
DE.O.HEADER
 This record is automatically generated by
the system .
 None of the fields can be altered except
the field “MSG.DISPOSITION”.IF the value is
repair.
How do we generate
the advices?
 A new Loans transaction has been input using
the Loans And Deposits module in T24 with the
following values
 LD ID - LD0710900075
 Customer Id - 100282
 Currency - USD
 Value Date – 24 APR 2007
 Maturity Date – 24 APR 2008
 Category – 21053
How do we generate the
advices?
 Interest Basis - E
 Rate Of Interest – 15
How do we generate
advice?
Delivery Reference ID

 D20080624001735373300
 X" "D" - message is to be delivered (outward
message) or
 "R" - message has been received (inward
message)
 "YYYYMMDD -" the date
 "NNNNN" - the system user number of the
inputter
 "SSSSSSS" - the time in seconds since midnight
 "QQ" - the sequence number of transactions
within a second
Delivery message
Print advice
Swift advice
Workshop 2

 Input & authorize FT transaction of Type “OT”

and see the Print and swift advices for that
transaction.
Solution 2
 Step 1 –Input and authorize the
contract .View the delivery message
generated
Solution 2

Step 2 – context enquiry to view the delivery advice

Solution 2-Print advice
Step 3 – The delivery print advice
Solution 2-swift advice

Step 2 (contd)- context enquiry to view the delivery advice

Solution 2-swift advice

Step 3 (contd.,) – The delivery swift advice

Workshop 3

 Input FT transaction of type “AC” and authorize

to see the delivery messages generated.
Solution 3
 Step 1 : Input FT of type “AC” and authorize
Solution 3
 Step 2 –The output shown below for
Debit advice
Solution 3
 Step 3- The output shown below is
Credit advice
Workshop 4

 Identify the Record Ids for the following tables

 DE.MESSAGE
 DE.MAPPING
 DE.CARRIER
 DE.ADDRESS
 DE.FORMAT.PRINT
 DE.FORMAT.SWIFT
Solution 4

 ID of DE.MESSAGE
 Message Type e.g. 320
 ID of DE.MAPPING
 Message Type. Application.Format
 E.g. 320.LD.1
 DE.CARRIER
 Carrier Name e.g. PRINT
Solution 4

 DE.ADDRESS
 Company name-Customer No.Carrier type
 E.g. GB0010001-100130.PRINT.1
 DE.FORMAT.PRINT
 Message type.Application format.Copies.Languag
 E.g. 320.1.1.GB
 DE.FORMAT.SWIFT
 Message type.Application format.Copies.Languag
 E.g. 320.1.1
Workshop 5

 Create address of customer automatically in

DE.ADDRESS.
Solution 5
 Step1 - Input a new customer
record and authorize .
Solution 5
 Automatically the address
(PRINT.1)of the customer gets
created in DE.ADDRESS
Errors in Advice
Example

 Here the advice is been generated to be sent by

swift and it is not able to locate the swift
address.
 Most errors, which occur during formatting,
would normally be because an address record is
missing
 To correct the error,
 Add the Address record to DE.ADDRESS
 Amend the DE.O.HEADER record changing the
MSG.DISPOSITION to “RESUBMIT” and authorize
the record.
Example
Adding of customer’s swift address in DE.ADDRESS
Example
Resubmitting of message in DE.O.HEADER
Example
 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.
Example
Output – Swift advices
Formatted
messages
Why we need delivery
Routine?
 APPLICTION.HANDOFF is a core routine from
that you can suppress (or) add any fields .
 What values need to be picked up from the
contract
 Which position in DE.O.HANDOFF the extracted
values need to be written to
 Information from applications other than from
the contract may be required
 User may require other calculations to be
performed and the result incorporated into the
advice
Delivery routine
 Theroutine is attached to the
DE.MAPPING record and populates
user defined information into the
DE.O.HANDOFF (8-10th array)
Delivery routine

 Routine has 2 parameters

 The HANDOFF record
 Error Message Variable
 New fields must be included
 DE.MESSAGE,
 DE.MAPPING
 DE.FORMAT.PRINT or SWIFT, depending on the
carrier
Example

 Ensure that, for all delivery messages of type

320 which are generated by the LD application
when a deposit is made into a customer’s
account contains the customer’s account officer
name in the advice apart from the existing
details.
Delivery routine

 Step 1- Define the field in DE.MESSAGE

Delivery routine

 Step 3-Write the routine that will populate a

position in the APPLICATION.HANDOFF with the
required information
SUBROUTINE GET.ACCT.OFFICER(MAT
HANDOFF.REC,ERR.MSG)
$INSERT I_COMMON
$INSERT I_EQUATE
$INSERT I_F.CUSTOMER
Delivery routine

Y.CUS.ID = 0
R.CUS.REC = ‘’
FN.CUSTOMER = 'F.CUSTOMER'
F.CUSTOMER = ''
CALL OPF(FN.CUSTOMER,F.CUSTOMER)
Delivery routine

CUS.ID = HANDOFF.REC(2)<1>
CALL
F.READ(FN.CUSTOMER,CUS.ID,R.CUST,F.CUSTOME
R,ERR)
HANDOFF.REC(9)<2> =
R.CUST<EB.CUS.ACCOUNT.OFFICER>
RETURN
END
Delivery routine

 Information can be read from and written into

the APPLICATION.HANDOFF array
 One of the parameters of the routine –
HANDOFF.REC
 Compile and Catalog the subroutine
Delivery routine

 Step 3 - Add new field to DE.MAPPING

Delivery routine

 Step 4 – Attach routine to DE.MAPPING

Delivery routine
 Step5 – Make required changes to
the DE.FORMAT PRINT or SWIFT
depending on the carrier
Delivery routine
 Step6 – Now produce the advice
by inputting and authorizing the
transaction
Delivery routine
Workshop 6

 For all 320 messages that are generated out of

the LD application, the WORKING.BALANCE of
the account needs to be displayed.
Solution 6

 Step 1 –write a subroutine that will extract the

account number and working balance of the
corresponding account and pass the working
balance to the APPLICATION.HANDOFF
Solution 6
Solution 6

 Step2 -Amend the DE.MESSAGE

record to hold a new that will in
turn hold the WORKING.BALANCE
Solution 6
• Step 3 – Amend the DE.MAPPING record
and map the field created in
DE.MESSAGE
Solution 6

 Step4 – Amend the

DE.FORMAT.PRINT record to
display the new field created
Solution 6

 Step5 – Input and authorize LD

Contract and see the delivery
message
Solution 6

Final output
ENQUIRIES

 To view delivery messages using enquiries

 ENQ DE.MSG.SUM
ENQUIRIES
Print advice
Swift advice
ENQUIRIES

 ENQ DE.HANDOFF.DETS
 To see the datas of Handoff record
ENQUIRIES

 Pass the delivery reference ID in the field

DELIVERY.REF
ENQUIRIES

The output is a delivery handoff

details
OTHER POINTS

 DE.MM.PRINT.MSG
 Can be executed only from the ‘Classic’ mode
 Used to print the Formatted message, or display
them on the screen.
 Type DE.MM.PRINT.MSG from the Awaiting
application prompt.
 Type ‘D’ on prompt
 Specify ‘Delivery key‘ on prompt
OTHER POINTS
OTHER POINTS
OTHER POINTS

 DE.ALTERNATE
 When REROUTE is specified for a Message, this
table is used by the Outward Message Formatting
module to replace the original carrier.
Summary

 Delivery system in T24 is used to send and

receive advices
 Advices can be sent either a customer or to
another bank
 Print, Swift and Telex are the 3 carriers used by
the delivery system
 DE.MESSAGE – Used to define the various
message type
 DE.MAPPING – Used to link the fields defined in
DE.MESSAGE to positions in the
APPLICATION.HANDOFF
Summary

 DE.PARM is the main parameter file of delivery

 Delivery routine is used to fetch data not
available in the APPLICATON.HANDOFF so that it
can be displayed in the delivery advice.
Thank You