Program Overview:

This program is used to validate a text file that contains a series of variable length transaction records. The validation process is different for each type of transaction, only the following types of transaction are acceptable and deemed valid -

I	Issue	- Stock issued.
R	Receipt	- Stock received.
C	Creation	- Create a new customer record.
D	Deletion	- Delete an existing customer record.

All invalid transactions are reported on the printer under suitable headings, with an appropriate error code. All error codes are defined on the last page of the printout. All valid transactions are written to the disk file named 494792VF.DAT for further processing by the Sorting program (in text format). This is unless the user changes this default file name by entering additional program parameters at the command line.

The text file which contains the transaction records must be named 494792TD.DAT, and be located in the same directory from where the validation 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 may be overridden: -

494792P1.exe <transaction file> <validated file> <printer>

The default file names are as follows: -

Transaction file        – 494792TD.DAT
Validation file           – 494792VF.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: -

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

However if the user only wishes to change the name of the file which contains the transactions to validate, they may enter the following command: -

494792P1.exe TRANS.DAT

Valid Transaction Types

A valid Issue transaction must be comprised of the following -

• Record Type – Must be ‘I’
• Customer Code – Must be 4 Digits, with an alphanumeric Modulus 11 check digit (weighting factor of 5432) appended to it (i.e. 10006)
• Part Number – Must be 5 Digits, with an alphanumeric Modulus 11 check digit (weighting factor of 65432) appended to it (i.e. 010006)
• Issue Quantity – A numeric value

A valid Receipt transaction must be comprised of the following -

• Record Type – Must be ‘R’
• Customer Code – Must be 4 Digits, with an alphanumeric Modulus 11 check digit (weighting factor of 5432) appended to it (i.e. 10006)
• Part Number – Must be 5 Digits, with an alphanumeric Modulus 11 check digit (weighting factor of 65432) appended to it (i.e. 010006)
• Receipt Quantity – A numeric value

A valid Deletion transaction must be comprised of the following -

• Record Type – Must be ‘D’
• Customer Code – Must be 4 Digits, with an alphanumeric Modulus 11 check digit (weighting factor of 5432) appended to it (i.e. 10006).

A valid Creation transaction must be comprised of the following -

• Record Type – Must be ‘C’
• Customer Code – Must be 4 Digits, with an alphanumeric Modulus 11 check digit (weighting factor of 5432) appended to it (i.e. 10006)
• Customer Name – Maximum of 20 characters in length, and NOT BLANK
• Customer Address – 4 address parts each separated by a ‘;’, maximum of 60 characters
• Customer Balance – 9 numeric characters, which represent the following format 9(7)v99
• Credit limit – 7 numeric characters, which represent the following format 9(7)

The following errors are detected and handled by the validation program: -

Unknown transaction type, only ‘I’, ‘R’, ‘C’ and ‘D’ transactions are allowable.
Non numeric customer code, only the check digit may be alphanumeric.
Incorrect customer code check digit, not modulus 11 of customer code.
Non numeric part number, only the check digit may be alphanumeric.
Incorrect part number check digit, not modulus 11 of part number.
Non numeric quantity.
Customer address incorrect format.
Non numeric customer balance.
Non numeric credit limit.
Customer name missing, there must be an address entered.
Missing part number.
Customers address missing, there must be a name entered.
There was too much information given for the type of transaction.

Processing:

The program starts by opening the transaction file, if a file name is not given at the command line when the program is first executed then the default file 494792TD.DAT is attempted to be opened. If a filename was given as a command line argument to the program then an attempt at opening this file is made. If the transaction file cannot be opened an error message is displayed and the program terminates. If the transaction file was successfully opened then it tries to create a file where the validated transactions are to be written to. If the validated file (494792VF.DAT or user given) cannot be created then an error message is displayed and the program terminates. Upon the successful creation of the validation file, the printer is opened for write access, in order to produce the transaction error report. If the printer is inaccessible then an error message is displayed and the program terminates.

When both required files and the printer have successfully been opened, a message is displayed on screen informing the user that the program is now validating all the given transaction records, writing valid transactions to disk, and all erroneous transactions to the printer.

The main validation loop is now entered by firstly reading a transaction record form the transaction file. If a record was not read successfully then the user is informed, by way of an error message on the screen, that there were no transactions on the disk file. The program then resets the printer back to its default state, closes all previously opened files and terminates as it has nothing to process.

Within the main processing loop a counter which holds a count of the number of records processed is incremented.  A check is then made as to what type of transaction record was read. We know which type is read in because the records type will contain a character; where as the other record types will contain NO information within their type element (they will contain a NULL character).

Deletion transaction record

If a deletion transaction was read, then a check is made to see whether the type element contains the character ‘D’, if it does then we run the validation function for a deletion type transaction record. If the validation function retuned TRUE, then the transaction record is written to the validated transaction file. However if the validation function retuned FALSE, the transaction record is sent to the printer with the error code that was produced by the validation function, and the counter which keeps count of the number of invalid deletion records is incremented.

If the type element did not contain a ‘D’ character, then we check to see if it contained a ‘C’ as the type. If it did then we send the record to the printer with an error code of that indicating that the record was missing a customer name. This is because the customer name is the first part of a creation record that this record does not contain.

If the type element did not contain a ‘C’ character, then we check to see if it contained either a ‘R‘ or ‘I‘ as the type. If it did then we send the record to the printer with an error code of that indicating that the record was missing a part number. This is because the part number is the first part of an issue or receipt record that this record does not contain.

If the type contained none of the valid transaction types then we send the record to the printer with an error code indicating that this is an unknown type of transaction.

Issue or Receipt transaction record

The issue and receipt transactions are stored in the same type of holding space (a structure of user defined type IR_REC); this is because they contain the same information apart from the type element which tells them apart. If an issue or receipt transaction was read, then a check is made to see whether the type element contains either the character ‘I’or ‘R’, if it does then we run the validation function for an issue/receipt type transaction record. If the validation function retuned TRUE, then the transaction record is written to the validated transaction file. However if the validation function retuned FALSE, then the transaction record is sent to the printer with the error code that was produced by the validation function, and the counter which keeps count of the number of invalid issue records is incremented it we had an issue record, otherwise the counter which keeps count of the number of invalid receipt records is incremented.

If the type element did not contain either an ‘I’or ‘R’ character, then we check to see if it contained a ‘D’as the type. If it did then we send the record to the printer with an error code of that indicating that the record contained too much information. This is because a deletion record only contains the type code (D) and a customer code, an issue/receipt record also contains a stock code and a quantity.

If the type element did not contain a ‘D’ character, then we check to see if it contained a ‘C’ as the type. If it did then we send the record to the printer with an error code of that indicating that the record was missing a customer name. This is because the customer name is the first part of an issue or receipt record that this record does not contain.

If the type contained none of the valid transaction types then we send the record to the printer with an error code indicating that this is an unknown type of transaction.

Creation transaction record

If a creation transaction was read, then a check is made to see whether the type element contains the character ‘C’, if it does then we run the validation function for a creation type transaction record. If the validation function retuned TRUE, then the transaction record is written to the validated transaction file. However if the validation function retuned FALSE, then the transaction record is sent to the printer with the error code that was produced by the validation function, and the counter which keeps count of the number of invalid creation records is incremented.

If the type element did not contain a ‘C’ character, then we check to see if it contained an ‘I’or ‘R’ as the type. If it did then we send the record to the printer with an error code of that indicating that the record contained too much information. This is because an issue/receipt record only contains the type code (I/R) a customer code, a stock code and a quantity, where as a creation record also contains a customer name and customer address, as well as credit limit and customer balance.

If the type element did not contain a ‘D’ character, then we check to see if it contained a ‘C’ as the type. If it did then we send the record to the printer with an error code of that indicating that the record was missing a customer name. This is because the customer name is the first part of an issue or receipt record that this record does not contain.

If the type contained none of the valid transaction types then we send the record to the printer with an error code indicating that this is an unknown type of transaction.

Over sized transaction record

If none of the transaction record types contained information, then we have caught an oversized transaction. This type of transaction is dealt with within the getRecord() function. The first 102 characters from the line of text read from the transaction file are sent to the printer, with an error code of ‘L’, indicating an oversized transaction (too much information). Now returning back to the main processing loop, we increment the correct error counter for the type of transaction at error. This is determined by checking a variable which the getRecord() function stores the first character from the read in line of text in. This variable is named errType, and is checked so we increment the correct type of transactions error counter, I-Issue, R-Receipt, C-Creation, D-Deletion, or unknown.

End of transaction processing

The main processing loop continues until we reach the end of the transaction file. When we have processed all the transactions we now print the total number of transactions processed, number of errors for each type of transaction, and the total number of errors. A list of all error codes and their meaning is printed as a lookup table for the error report. We now reset the printer back to its default state, so that the next user to use the printer does not receive a printout in an unexpected format. Finally we close all previously opened files and return to the operating system.

When the Validation program has exited successfully it would have created a new Validated Transaction file named 494792VF.DAT, which is processed by the Sort program (program two out of the four).

Modulus 11 check digit

Modulus 11 check digits must be appended to all customer codes using weighting factor of 5432, and also to all part-numbers using a weighting factor of 65432.

For example a customer code of 24680 will prove to be invalid. In order for 2468 to be valid, the appended check digit should have been six not zero as stated, below shows this to be the fact –

Customer code         2        4        6        8

x                               x        x        x        x

Weight                     5        4        3        2

————————————————–

Product                   10 +    16 +    18 +    16 =    60

Dividing 60 by 11 gives a remainder of 5.
Subtracting 5 from 11 gives 6, this 6 being the check digit.
A check digit of X is used to represent a subtraction of 0 (zero).
A check digit of 0 (zero) is used to represent a subtraction of 1.

Design decisions:

There were various design changes made during the course of this program. The first one was that of the way errors are reported to the printer, it looks a lot neater and easier to understand when the various elements of the transaction are split into there relevant parts. This was thought a better design than merely sending the erroneous line of text to the printer, which would have taken longer for the end user to decipher.

The decision to use a custom function to copy the relevant parts of the read in text line, rather than a standard c function was because I felt I needed more flexibility in the string copying. As this function is used in three of the four programs it was a justified decision in my opinion.

The decision to print the breakdown of the error codes on a new page was made as it was felt it would be much easier to use it as a lookup table without keep trying to flip pages over because the codes were spread over multiple pages.

To start with the file names were hard coded within the program; if any of them were not found then the program would exit. This was changed quite late in the program development, as it would be more practical to allow the user to override the name of any file at the command line (as a command line argument). This way the file names are not hard coded into the program, which makes the program much more flexible. If however a file name is not provided on the command line then the default file names are used.

The way the program is structured should make it quite easy to modify, such as the time when the customer decides they need another transaction type, or an existing transaction type needs further validation. These types of changes should be quite straight forward to implement as the program is divided into very distinct individual functions.

Limitations:

There are various limitations to this program. The main limitation in my opinion is that there is still a lot of room for human error involved in the initial creation of the transaction file. One of the main aims of this overall project was to reduce human error, and this has not been done to a satisfactory level. It would have been a much better design decision to allow the user to enter transactions using a modified version of this program. This modified version would inform the user immediately when an erroneous transaction had been entered and be given the opportunity to re-enter that transaction. This would greatly reduce the amount of human error, as the user may amend any invalid transaction as and when they are entered. This would also speed up the whole process, as multiple attempts at trying to rectify an invalid transaction may be done with immediate effect rather than having to wait until the whole transaction file is processed and then re-enter the invalid transaction only to be processed by this program again.

When a transaction is found to be invalid only the first error is recorded, there may well be more errors contained within the transaction. If the user only corrects the recorded error then the transaction will be rejected when it is processed again and again until it contains no further errors. This limitation could be removed by the method suggested above, with all transactions being validated at the time of input.

There is also no record type to update an existing customers details, such as if they change address, or a more common event they have their credit limit increased. This would not warrant another program dedicated to updating customer details, as the Update program does the task of updating customer balances, deleting customers and creating new customers, based upon the type of transaction. So a new transaction type ‘M’ maybe called for to change an already existent customer’s details.

Another limitation that has now been removed; this was after thinking about the programs limitations. This was the names of the various required files being hard coded (may not be overridden) within the program. This would restrict the user to always using having to use these file names, and modifying the source code if they were to change. Now the user is able to override the default file names, by entering additional parameters at the command line when the program is executed. These parameters are detailed above and knowledge of them may even be restricted to certain persons.

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.