CUS16.Deal Slip [PDF]

Zitiervorschau

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