Program Overview:

This program is used to validate a text file that contains a series of variable length transaction records. The transaction file to be validated must have been produced by the data entry program (494792P0). 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.
A Amend   – Amend an existing stock record.
N New        – Create a new stock record.
Z Zap         – Delete an existing stock 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 customer transactions [I R C D] are written to the disk file named 494792VF.DAT for further processing by the Sorting program (in text format). All valid stock transactions [A N Z] are written to the disk file named 494792SF.DAT for further processing by the Stock Update program (in text format). This is unless the user changes the default file names 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 file is created by the Data Entry program (494792P0.exe). 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> <customer validated file> <stock validated file> <printer>

The default file names are as follows: -
Transaction file – 494792TD.DAT
Customer Validation file – 494792VF.DAT
Stock Validation file – 494792SF.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 494792SF.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

The overriding of the default file names is mainly for test purposes or where there is a need to do so. Such a need may arise when there is a need to reproduce a validation file from an old transaction file. The everyday users of this program need not even have to be aware of this overriding feature.

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 Customer 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 Customer 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)

A valid Stock Amendment transaction must be comprised of the following -
Record Type – Must be ‘A’
Part Number – Must be 5 Digits, with an alphanumeric Modulus 11 check digit (weighting factor of 65432) appended to it (i.e. 010006)
Part Description – Must be no more than 19 characters in length
Supplier Code – A numeric value [00 - 99]
Free Stock – A numeric value [000000 - 999999]
Minimum Stock Level – A numeric value [0000 - 9999]
Last Movement Date – In the format YYMMDD
Selling Price – A numeric value [0000.00 - 9999.99]

A valid Stock Deletion transaction must be comprised of the following -
Record Type – Must be ‘Z’
Part Number – Must be 5 Digits, with an alphanumeric Modulus 11 check digit (weighting factor of 65432) appended to it (i.e. 010006)

A valid Stock Creation transaction must be comprised of the following -
Record Type – Must be ‘N’
Part Number – Must be 5 Digits, with an alphanumeric Modulus 11 check digit (weighting factor of 65432) appended to it (i.e. 010006)
Part Description – Must be no more than 19 characters in length
Supplier Code – A numeric value [00 - 99]
Free Stock – A numeric value [000000 - 999999]
Minimum Stock Level – A numeric value [0000 - 9999]
Selling Price – A numeric value [0000.00 - 9999.99]

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

A = Missing customer code.
B = Non numeric customer code, only the check digit may be alphanumeric.
C = Incorrect customer code check digit, not modulus 11 of customer code.
D = Missing part number.
E = Non numeric part number, only the check digit may be alphanumeric.
F = Incorrect part number check digit, not modulus 11 of part number.
G = Customers address missing, there must be an address entered.
H = Customer name missing, there must be a name entered.
I = Missing part description.
J = There was too much information given for the type of transaction.

Processing:

When the program is first starting it checks to see if there was a command-line argument given. If there was then the argument is taken to be the name of the transaction data file, and an attempt at opening this file is made. If the attempt fails then the program reverts to using the default file name (494792TD.DAT). An attempt at opening the default named file is now made, if this also fails an error message informing the user that the file could not be opened is displayed and the program exits returning the user back to the operating system.

If there was another command-line argument given this is taken to be the name of the validated customer transaction file. An attempt at opening/creating this file is made. If the attempt fails then the program reverts to using the default file name (494792VF.DAT). An attempt at opening the default named file is now made, if this also fails an error message informing the user that the file could not be opened is displayed and the program exits returning the user back to the operating system.

If there was another command-line argument given this is taken to be the name of the validated stock transaction file. An attempt at opening/creating this file is made. If the attempt fails then the program reverts to using the default file name (494792SF.DAT). An attempt at opening the default named file is now made, if this also fails an error message informing the user that the file could not be opened is displayed and the program exits returning the user back to the operating system.

If there was another command-line argument given this is taken to be the name of the printer file (where the error report from this program is printed to). An attempt at opening this file is made. If the attempt fails then the program reverts to using the default file name (PRN). An attempt at opening the default named file is now made, if this also fails an error message informing the user that the file could not be opened is displayed and the program exits returning the user back to the operating system. If no command-line arguments were given then all default file names are used.

When all the required files have been successfully opened, a message is displayed on screen informing the user that the program is now validating all the given transaction records, writing valid customer transactions to disk (file being written to), writing valid stock transactions to disk (file being written to), and all erroneous transactions to the printer (or to the given file name).

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.

If a transaction record was read successfully then 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 (its transaction type); where as the other record types will contain NO information within their type element (they will contain a NULL character).

Customer Deletion transaction record

If a customer deletion transaction was read, 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 customer 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 customer deletion records is incremented.

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 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 customer 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.

Customer Creation transaction record

If a customer creation transaction was read, then we run the validation function for a customer creation type transaction record. If the validation function retuned TRUE, then the transaction record is written to the validated customer 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 customer creation records is incremented.

Stock Amendment transaction record

If a stock amendment transaction was read, then we run the validation function for a stock amendment type transaction record. If the validation function retuned TRUE, then the transaction record is written to the validated stock 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 stock amendment records is incremented.

Stock Creation transaction record

If a stock creation transaction was read, then we run the validation function for a stock creation type transaction record. If the validation function retuned TRUE, then the transaction record is written to the validated stock 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 stock creation records is incremented.

Stock Deletion transaction record

If a stock deletion transaction was read, then we run the validation function for a stock deletion type transaction record. If the validation function retuned TRUE, then the transaction record is written to the validated stock 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 stock deletion records is incremented.

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 ‘J’, 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, N-New, A-Amend, Z-Zap or unknown/invalid.

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 two new files:-

Validated Customer Transaction file named 494792VF.DAT, which is processed by the Sort program (program two out of the seven).

Validated Stock Transaction file named 494792SF.DAT, which is processed by the Stock Update program (program five out of the seven).
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 decisions 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 their 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 five of the seven 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. 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 continuing to validate the given transaction, and reporting multiple error codes. This would however lead to some restructuring of this program and the time taken to achieve this may not be justified by the amount of actual re-processing required.

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 amend 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.

Other possible limitations are only checking the quantity to be numeric; this may also need to be checked to ensure it is a non-negative value. The same applies to a customer credit limit. Upon creation should a customer balance really be a non-zero value, as this implies the customer has had issues/receipts before being created?

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.