Program Overview:

Before this program is used it is imperative that the validated file used has been produced by the Validation program (494792P1.exe). If this is not the case then the outcome of this program is not guaranteed to be in anyway reliable or useable.

This program is used to sort the already validated transaction file into ascending customer code order. The resulting sorted file is then printed under suitable page headings. There is also an additional requirement to sort the file so that, if there are multiple transactions for the same customer, a creation type transaction should NOT be followed by any other valid transaction for that customer.

The text file which contains the validated transaction records must be named 494792VF.DAT, and be located in the same directory from where the sort program is located and executed from. This is unless the user changes this default file name by entering additional program parameters at the command line. Below describes how the default file names can be overridden: -

494792P2.exe <validated file> <sorted file> <printer>

The defaults file names are as follows: -

Validated file           – 494792VF.DAT
Sorted file               – 494792SD.DAT
Printer                    – PRN

If the user wishes to override one of these files they must also enter the file names of all the files preceding it. For example to override the printer to a text file named test.txt, they must enter the following command: -

494792P2.exe 494792TD.DAT 494792VF.DAT test.txt

However if the user only wishes to change the name of the validated file, they may enter the following command: -

494792P2.exe VAL.DAT

Sorting:

The validated file is first sorted into ascending customer code order using a standard sort utility (the qsort function). When this sort has completed successfully, this sorted list is then sorted so that, if there are multiple transactions for the same customer, a creation type transaction will NOT be followed by any other valid transaction for that customer. This second sort is done by the reading in each transaction and checking the type code of the current transaction, to see if it is a creation type ‘C’. If it is a creation type, it is then compared against the next transaction. If the two have the same customer code they are swapped so that the transaction type ‘C’ now appears immediately after that of the other transaction. This process occurs until the complete list of transactions has been sorted into the order required.

Printing:

After the transactions have been sorted into the appropriate order they are then printed out (in the sorted format). At the top of every page printed is the customer name (Zenith Paints), the name of the report (Sorted Transaction Report), the current system date (dd/mm/yyyy) and the current page number.

Below the page title information follows the page headings, record type ([IRCD]), customer name, part number, customer name, customer address, customers balance and the customer’s credit limit. If a given transaction does not contain the information required for the given heading then a ‘-‘ character is printed instead of leaving the section blank (easier reading of the report).

Design decisions:

This was quite a straight forward program to design, as its primary function is to sort the already validated records into ascending customer code. The additional requirement of the Update program (494792P3.exe) which was to sort the file so that, if there were multiple transactions for the same customer a creation transaction would NOT be followed by any other valid transaction for that customer. This was implemented quite easily when it was found to be a requirement of this program.

When the printout is produced for the sorted transaction the same list of sorted transactions is used as when the sorted transactions were written to disk. This saved writing the transactions to disk and then going back to the start of this file to read each transaction and then print it. It was much simpler to use this list as it contains everything that was written to disk, as it was effectively written to disk in the first instance, and is not modified in any way between the disk write and the printout. The printing of a ‘-‘ character when a transaction does not contain that information makes the printout much easier to follow and neater.

Limitations:

There are not many limitations to this program; the main limitation is that of sorting the transactions so that, if there were multiple transactions for the same customer a creation transaction would NOT be followed by any other valid transaction for that customer. This is limitation will cause the delay of processing valid transactions for the customer to be created. If the customer is allowed to be created first then issues and receipts maybe processed in the Update program quite legally. This would save a lot of time when it comes to re-entering those transactions and also reprocessing them through the various programs.

The reliance upon the user to have previously run the transaction file through the validation program to produce the validated file is also a limitation. This is because this program does not do any transaction validation, and so invalid transactions will happily pass through this program. With the exception of unknown type transactions, as they will generate an error when read from the validated file, and cause the program to exit after displaying an error message to the user.

All of the programs are limited to using a Hewlett Packard printer as all printouts use Hewlett Packard specific escape codes to format the output. If the printer is changed for a different make then this program will need modification and recompilation. The modifications are all contained within the printer.h header file and so should not cause any problems if this task is required.