To retrieve by receipt number is not a problem. To present a pick list of receipts by day is not a problem. To present a pick list of receipts by customer is not a problem. In fact, I would think that you should have functions for picking by number/customer built-in to answer inquiries or to verify that a receipt is legit (if someone shows you a receipt, you can pull it up on the system to make sure it is the real thing).

The report should probably just be a cursor with the appropriate data plugged-in. So the report doesn't need special variables or anything. You build the cursor based on the information stored in the tables. If you can print the receipt when it is initially entered, it should not be a problem to print it again at a later time.

If it is easy for you to retrieve the data from the tables, it should be easy to code the retrieval. Then just output the results.

I just think this is a cleaner method. Our users have to re-print things all the time. If the data is there, print it.

This is only my opinion.

Joe


>>Why don't you just retrieve that data when needed?
>
>Joseph,
>This was the first thought I had in mind. But then I was asking, how should the supervisor define what he wants to retrieve. There are many options:
>which receipt number, which specific day, which customer and so on.
>This is a very intensive task to make a form with all this options, and also a report with many variables, called from this form.
>Now, this case is -hopefully- used only once a year. I thought, it would be easier to produce an always up-to-date textfile, which the supervisor can open in the old manner, when something very odd is happening.
>Or he calls me (once a year?), because for me it would be easy to retrieve this information from the table.