Welcome to “Deal Slips” learning unit of Customisation course.

In this learning unit,

you will learn the importance of creating dealslips and attaching to various T24 related
transactions.

CUS.Deal Slip 1
 After completing this learning unit, you will be able
to

understand the need for a deal slip, its flow and how it is linked in T24
applications

2. to create Deal slips

3. to work on Applications related to deal slips.

CUS.Deal Slip 2
 Do you have a bank account?
I am sure each one of us have a bank account
Have you ever been to an ATM?
All of us would have been to an ATM to withdraw or deposit cash
What happens after you withdraw or deposit money using the ATM?
We normally get a slip stating all required details of the transaction
that just happened

CUS.Deal Slip 3
 Deal slips can be generated for any application in T24.

Usually printed over the counter and given to the customers

They act as a confirmation for a banking transaction that was performed

CUS.Deal Slip 4
 A Deal can be triggered during any of the following functions in T24:

Authorize
Copy
Delete
History Restore
Input
Reverse

FINISH ( This keyword is Application specific and is not triggered for all applications.
The Application that currently uses it is TELLER )

CUS.Deal Slip 5
 When ever a new customer walks in to the bank, in T24 we would have to create a
record in the CUSTOMER application to record his details.
Once the details are recorded, the bank wishes to give the customer a confirmation
note like the one shown below

CUS.Deal Slip 6
 PRINTER.ID, DE.FORM.TYPE, REPORT.CONTROL and DEAL.SLIP.FORMAT
applications in T24 constitute the application involved in creating dealslips in T24. All
these applications are interlinked to produce the final deal slip.

CUS.Deal Slip 7
 There are a set of application that we need to setup in order to print a deal slip in T24.
The first thing that we need to setup is a PRINTER.ID record followed by
DE.FORM.TYPE , REPORT.CONTROL and DEAL.SLIP.FORMAT. Lets look into
each one of these applications in detail as we go along.

CUS.Deal Slip 8
 The PRINTER.ID application is the one links T24 to the formqueue that is created at
the jBASE level.
Now, what is a formqueue?
I am sure all of you would have used the ‘Add Printer’ icon in Windows to add a
network printer. What happens is, you get a logical printer set up in your system that
takes care of routing the print request received from applications to the operating
system. I am sure you know that no application or a database prints. They all send the
requests to operating system and it is the operating system that prints.
A formqueue is like a logical printer. It is defined at the jBASE level. It redirects print
requests received from T24 (Application) to the operating system.
The field ‘Prime Printer Id’ holds the name of the jBASE level formqueue.

Incase you do not want to print but send the output to a repository called &HOLD&,
then, set the value of the field Prime Printer Id to HOLD.

CUS.Deal Slip 9
 &HOLD& : The &HOLD& directory is a directory that gets installed when T24 is
installed. Take a look at the VOC entry displayed above. You will be able to
understand that this directory resides under the bnk.data/eb directory. This directory,
as the name suggests is meant to hold any (Not only deal slips) spooled output which
may not be required to be printed. The advantage of storing it in this directory is that
we can query the content of this directory and reprint any of the reports whenever we
wish to. Take a look at the output of the ‘LIST &HOLD& command. As you can see
above, all the reports that get spooled into this directory have a unique ID to identify
themselves. I am sure we cant remember these numbers. Can you? 
Take a look at the content of the bnk.data/eb sub directory. Note that the &HOLD& is a
directory or in other words a jBASE non hashed file. This brings us to the question, will
all reports that get spooled to this directory be stored as flat files. The answer is YES.
All reports that get spooled to this directory will be stored as individual flat files. If they
are flat files, how do we view them? Well, we could do a JED and view them (See
output of JED <Report ID> above).
I am sure you are not happy with JEDing a file (We seem to read your mind  )
Well, there is no harm in JEDing a report to view, but the issue is, when we have a
1000 records in this directory and we wish to reprint one of them, how on earth are we
going to locate the report that we wish to reprint?

Keep thinking.

CUS.Deal Slip 10
 Since &HOLD& is a flat file and only stores the reports and does not enable querying,
an application named HOLD.CONTROL is used. When ever a report is spooled
into the &HOLD& directory, details about the report such as
1. The name of the user who generated the report – Field USER in HOLD.CONTROL
2. The name of the report (As in REPORT.CONTROL) – Field REPORT.NAME in
HOLD.CONTROL
3. The company for which the report was generated – Field COMPANY.ID in
HOLD.CONTROL
4. The date when the report was generated – Field DATE in HOLD.CONTROL
5. Time when the report was generated – Field TIME in HOLD.CONTROL
6. Was it generated during COB or online – Field RUN IN BATCH in
HOLD.CONTROL (If set to Y, denotes that it is a COB report)
7. The date and time of COB if it is a COB report that has been generated – Field
BATCH DATE TIME in HOLD.CONTROL
8. The T24 application server date – Field BANK DATE in HOLD.CONTROL

Are stored in a record in HOLD.CONTROL application. The ID to this record will be the
ID of the report in &HOLD&.
Please note that the HOLD.CONTROL application only holds details of the report
mentioned above along with the actual report ID. It does not store the actual report.
The actual report will only be stored in &HOLD&.
You may verify the record in HOLD.CONTROL to view the report from &HOLD&. So,
you don’t have to JED the report any more 

CUS.Deal Slip 11
 Now that we have learnt about setting up the PRINTER.ID in T24 we move on to
another application called DE.FORM.TYPE. This application is used to design the form
on which your deal slip should appear. Will you not agree with me when I say all the
things that need to be printed are always on a the same type of stationery. There are
different forms of stationery you could think of in a banking transaction. An account
statement is an ideal example of a banking transaction which is printed and sent to all
customers on an A4 paper, whereas a cheque would be on a form which is rectangular
unlike an account statement. Now this is what we call a form and you can design the
same using the application DE.FORM.TYPE in T24.

There are fields that you can use to alter the layout of the forms you want to print on.
We can change the forms width and depth for instance, also have some space for top
and bottom margin.

The OPTIONS field allows you to define some spooler options

• NOHEAD – Suppress printing of banner page

• NOEJECT – Suppress the page from ejecting at the end of the report
• COPIES n – To print n copies of the report
• DEFER hh:mm – To defer printing until the specified time (24hr time) Eg, 18:00 for
6pm.

Note that the record created in the PRINTER.ID application (with ID HOLD) is

CUS.Deal Slip 12
 specified here.

CUS.Deal Slip 12
 REPORT.CONTROL is the application that links the printer related applications in T24
such as PRINTER.ID and DE.FORM.TYPE to rest of the applications in T24. All
applications in T24 that wish to print will speak to DE.FORM.TYPE and therefore to
PRINTER.ID using this application.
Note that the ID of the DE.FORM.TYPE record that was created earlier has been
specified here in the field ‘Form Name’.

CUS.Deal Slip 13
 Now lets move on to the next application which is the DEAL.SLIP.FORMAT. This is
more or less similar to your ENQUIRY application in T24. Imagine that the bank
needs to send an account statement to a customer, what do you thing should be
there in the account statement ?

Certainly some basic information like the date on which the report is printed, the
bank’s name and address , customer’s account number, customer number, the
transactions for a period etc. This kind of information that we need to have on the
account statement don’t necessarily come from a single application in T24 but from
different applications. Most importantly it needs to be printed in a specific format.
To achive the above, we use the application DEAL.SLIP.FORMAT.

I am sure you would have used the ENQUIRY application in T24. This application
enables us to define and generate reports in T24. How did we define a report using
an ENQUIRY application?
We specified the
1. Fields that need to be displayed
2. The headings to be displayed
3. The position where these headings and fields needs to be displayed

This is exactly what the DEAL.SLIP.FORMAT application also allows us to do.

CUS.Deal Slip 14
 The Id of the REPORT.CONTROL application can be any free text which you think
best describes the reason for which you are creating the deal slip
Report Control Id : Holds the ID of the record in the REPORT.CONTROL application.
This enables us to link to the DE.FORM.TYPE application and the DE.FORM.TYPE
application enables us to link to the PRINTER.ID application in T24
File : Holds the name of the T24 application form which data needs to be fetched and
displayed here. Similar to the field ‘FILE NAME’ in the ENQUIRY application. This is a
multi value field and hence multiple T24 application names can be specified here. The
main application always should be the specified in the first multi value.
Id : Holds the name of the field that acts as the ID for the application mentioned in the
field ‘File’. Look at the second multi value set ‘File.2:COUNTRY and
Id.2:NATIONALITY’. What this denotes is, we are to pick up data from the application
called COUNTRY and the field that links the COUNTRY application to the
CUSTOMER application (The base application which the deal slip is based on) is the
field NATIONALITY.

CUS.Deal Slip 15
 Accessing fields from other Applications (not the main file).
GEOGRAPHICAL.BLOCK is a field in COUNTRY application
Syntax : ApplicationName>FieldName

CUS.Deal Slip 16
 Now that we have created the necessary records in various application like
PRINTER.ID , DE.FORM.TYPE , REPORT.CONTROL , DEAL.SLIP.FORMAT we
need to generate the deal slip from some application in T24. Deal slips, as you know,
can be triggered from any application in T24 on any function. To achieve this, define a
version for the application and attach the deal slip to it and set a trigger for it to print.
Lets see what are the fields that are available in VERSION application to set up a deal
slip.

D.SLIP.FORMAT is where you attach the name of the DEAL.SLIP.FORMAT record

D.SLIP.FUNCTION is where you specify what is the function in T24 that should trigger
the deal slip ( I , A , R, C, D, H and FINISH)
D.SLIP.TRIGGER can be either OL or RQ. OL is to generate a deal slip based on the
function defined in D.SLIP.FUNCTION and RQ to generate it using a hot key. We don’t
use the hot key functionality any more.

CUS.Deal Slip 17
 The Bank wants a report of all customers belonging to a particular SECTOR in the
following format when a Customer record is authorized.

CUS.Deal Slip 18
Can we achieve the task by defining a deal slip?
No

What we want is a report to be displayed not a proof of a transaction

Correct

Does it mean that we need to trigger an enquiry when a customer record is

authorized?
Yes 

Lets see how can do this.

 First step is to create a enquiry for the desired output. Once this is created use the
ENQUIRY.REPORT application to link the ENQUIRY that you have created to the
REPORT.CONTROL application.

When the XML format is chosen using the field ‘Output Format;, then, the output that
gets generated will be in XML format

If no option is chosen then the default is REPORT format.

When the FILE format is chosen the output will be in FILE format with TAB separated
columns.

CUS.Deal Slip 20
 Here you can see that the D.SLIP.FORMAT.1 field in the VERSION now holds the
name of the ENQUIRY.REPORT instead of the DEAL.SLIP.FORMAT record.

CUS.Deal Slip 21
 Sample output of the dealslip in XML format as taken from the &HOLD& record. This
screenshot displays all the header part of the deal slip

CUS.Deal Slip 22
 This screenshot displays all the content that appears on the deal slip output.

CUS.Deal Slip 23
 In order for the Deal slip to be triggered an important step needs to be performed. The
BROWSER.PREFERENCES application gives you an option to route the dealslip to a
print location either on the server or on the local PC. This needs to be set accordingly
based on the need of the bank. In order to see the display of the Deal slip visually on
the screen as a popup we need to set it to Local in the Print Location.

CUS.Deal Slip 24
 1. Deal slips can triggered from the same version twice one while input and another
while authorizing - True/ False
Answer: True

2. The output of a deal slip can be customized such that the fields of the application
are displayed are shown as Bold characters – True / False
Answer: False

3.The output format of the deal slip can be generated in HTLM, CSV formats – True /
False
Answer: False

4. When a default DE.FORM.TYPE is not defined it takes the ID DEFAULT - True /

False
Answer : True

5. When the output of the deal slip need to be stopped from getting printed on the
Printer it can be sent to a hold file - True / False
Answer: True

CUS.Deal Slip 25
CUS.Deal Slip 26
CUS.Deal Slip 27