'Meetings' module in Priority - complicated!

My CEO asked me several years ago to develop a module in Priority in which would be recorded all the visits to our display rooms by outside visitors. I developed something but no one used it and so it lay forgotten. About a month ago, the CEO again made the request as we now have a receptionist who is 'prepared' to enter the relevant data, so I examined what I had developed previously. 

The first major problem was that my original development assumed that visitors would already have an entry in the Contacts table of Priority, linked to a customer. The CEO specifically requested that this module be able to record details of any visitor, not just those who already have a record. This required adding three fields to the Visits table: name, mobile number and email. I went a bit further with this: if the name already exists in the Contacts table only once, the mobile number, email and customer will be taken from the Contacts table and added to the Visitors table. If the name exists several times, the user can choose one of the customers to which the contact is connected. I added a mechanism to connect the visitor to a customer post factum, assuming that a suitable customer had been created.

My original development included the possibility of chaining visits: if the outcome of a visit is a continued visit then the module would automatically add a new visit with the same details as the original visit but taking place a week later. On the basis of this chaining, I developed a report which would give details of all the chained meetings, including free text. This included some code to find the 'head' of a chain and then continue from there.

Whilst discussing the module with the receptionist who is going to enter the data (this was not the training session), I realised that a meeting could take place with several outside visitors. How would this work? My solution was to add a details table in which extra visitors could be added; in order to simplify reports, the contact details in the main screen would be added to this details table. As a result, any report which wants to list all the participants need access the details table only.

But this addition ruined the chained meeting report: apart from the singular data of a meeting (person, place, time, etc), there are also multiple data - the free text. Adding more multiple data - the participants - caused the text to appear for every participant. This is what happens with many documents in Priority: an order has a header, order lines and order text. One expects that each will appear separately. This is achieved by creating what we call an HTML document, which is a complicated type of procedure.

Here the real problems started and it took me a while to figure out what to do. My intention was to build a list of visits then send this list to the procedure which would print them out. First I had to develop the HTML document which is far from simple. There were two main "gotchas" -

• The procedure starts with an INPUT stage, where there is a parameter PAR linked to the field DOCNO. As there is no screen with the same name as the Visits table, one has to enter into the continuation sub-form the name of the screen. This is the same as in WWWCUSTCAMPAIGN.
• In order to display the name of each sub-report in the final document (e.g. 'Participants'), one enters the HTML definitions sub-form of the the sub-report and records D in the field 'display title'.

After a bit of playing around, I managed to get the HTML document to display as I wanted it. The next step was to write a separate procedure which would build the chained list of visits. I cannibalised my original procedure, getting the key fields for each visit then inserting them into a linked table of visits. This took a few attempts to get right, but eventually I succeeded. 

So now I have what seems like an effortless way of printing chained visits. Tomorrow I will be giving the training session so there may be more changes on the way. One problem which I can foresee is that at the moment all the participants have to come from the same company, or not come from any company at all. It is conceivable that they will want to document a visit in which participate several people from several companies. This will probably mean adding a customer field to the details table and changing the 'find person' code.