I was recently tasked with creating a document that shows general details about a customer, how many price quotations have been issued to the customer, a list of the price quotations themselves, a list of customer orders, service calls, etc. There is a standard document called WWWSHOWCUST that shows some of this data but for some reason it is laid out in a very unattractive manner, and anyway I wanted to include data that isn't included in the standard report (as well as discarding certain sections).
I started off with a 'simple' HTML document: at the beginning, the document is presented with a list of customers and then one by one, the various data are shown, where each type of datum resides in its own report (that is, one report for sales opportunities, one for price quotations, etc). To complicate matters slightly, I decided to add a parameter at the beginning that defines from which date the data will be displayed (or in other words, don't display price quotations (for example) from before this date. So far, so good.
Then I considered the possibility that a user might not want to see all the data; for example, there is a certain amount of duplication between orders and projects (at least, in the way that we work), so there's little reason to show both. I decided that I would have a series of global variables that could be chosen, and depending on these values, the corresponding report would be shown.
To the left is shown the parameters' screen; the checkboxes are connected to variables :$:A1, :$.A2, etc.
Today's tip is concerned with how those choices are translated into which reports are shown. Let's say that price quotations will be shown if variable :$.A4 = 'Y'. First of all, this parameter is passed to the report, along with CST, which holds the current customer number. In the report one adds the inscrutable line DUMMY.DUMMY whose expression is = 1 and :A4 = 'Y'. For reasons that have never been explained, every DUMMY.DUMMY expression has to start with = 1. If the second half of the expression is true, the DUMMY.DUMMY will be true and the report will be printed. If not ....
This technique enables the HTML document to have one format, where every user chooses what to display, instead of 7! (5040) different combinations!
A later request, that I was able to serve partially, was to display only data belonging to a given branch. This is not a problem for the reports that display price quotations, etc (one simply passes a parameter containing the branch numbers) but it's a problem for reports that don't display data per branch - our company header and the current customer's data. True, it is possible to define that a customer belongs to a specific branch, in which case there would be no problem (one would add the branch in the HTMLCURSOR stage), but we don't do this as customers are free to order from different branches (this is intended to reduce the number of duplicate customers). At the moment, if one passes to the procedure a range of customers, there will be a header for every customer even if there is no data for that customer. Not good.
The problem is how to filter the data (or weed out unwanted customers) before the procedure gets to the HTMLCURSOR stage. I spent about an hour working on this but didn't resolve the situation to my satisfaction. I can see now that I was filtering after the HTMLCURSOR stage whereas in fact I have to do so before this stage, at the very beginning. Maybe I will be able to find a solution after all.
No comments:
Post a Comment