|
Introduction (a) Overview A suite of four programs, written in COBOL, has been designed to process transactions for Zenith Paints. Transactions include the issue (sale) of stock, return (receipt) of stock, deletion of a customer record from a customer master file, and creation of a new customer record on the customer master file. The transaction file, written on a disk in the A:\ drive is first processed by Program 1. All files, except the original customer master file and stock master file, are written to the A:\ drive disk. This produces a valid transactions file and a printed error report. At this point the user may wish to correct errors on the original transaction file and re-execute Program 1 (which will over-write the valid file from the previous run). Executing Program 2 will produce a new sorted transaction file (for processing by Program 3) and print a report of the sorted transactions. Program 3 will then process the transactions and will produce a new customer master file, update the stock master file, and print a report of transactions that could not be processed. The new customer master file is written to the A:\ drive and requires to be renamed as CUSTMAST.DAT and used to replace the original CUSTMAST.DAT (on the computer hard disk) before processing further transactions. Since the stock master file is updated during running of Program 3, it is not possible to simply correct transaction errors and re-execute. Corrected transaction errors will have to be processed as a separate batch (or included in a new batch) of transactions, and only once the stock master file has been replaced with the recently produced updated version. Program 4 will produce a printed report of the newly updated customer master file and indicates customers with excessive balances. (b) Program 1 (TB17P1) reads transactions from a transaction file (TB17TD.DAT) and validates the fields of each record in turn, producing a valid transactions file (TB17VF.DAT) to be further processed by Program 2. Transactions that contain invalid data/errors are not written to the valid file but are printed on an error report (TRANSACTION FILE ERROR REPORT) which details the nature of the error or errors for each record rejected. (c) Program 2 (TB17P2) performs two functions. Firstly, the valid transaction file from Program 1 is sorted into ascending order by customer code. Where more than one transaction exists for a single customer, the records are sorted by record type, i.e. issue (I type), then return (R type), then deletion (D type), and then creation (C type). This is necessary for the method of processing used in Program 3. The sorted transaction records are written to a sorted transaction file (TB17SD.DAT) for further processing by Program 3. Following the creation of the sorted transaction file, Program 2 then produces a printed report of all transactions in this file (SORTED VALID TRANSACTION FILE REPORT). (d) Program 3 (TB17P3) is responsible for processing the transactions in the sorted transaction file produced by Program 2. Using a master customer file (CUSTMAST.DAT), customer records are updated to reflect changes in customer balance when issue or return transactions are performed. In addition, for issue and return transactions, the stock file (containing details of stock levels and prices) (STCKMAST.DAT) is also updated to reflect changes in stock levels and stock movement date for items specified in the transaction record. Deletion type transactions allow for the removal of a customer record from the master customer file, but only when the customer's balance is zero. Creation type transactions allow for new customers to be added to the customer master file. The updated customer master file produced by Program 3 is referred to as the new customer master file (TB17NF.DAT). Transactions that cannot be processed are printed on an error report (TRANSACTION ERROR REPORT), which details the reason why the transaction cannot be processed. (e) Program 4 (TB17P4) produces a printed report (UPDATED CUSTOMER MASTER FILE REPORT) of the new customer master file produced by Program 3, and produces a grand total of customer balances. Customers having a balance that exceeds their allotted credit limit are indicated on the printed report along with the sum outstanding.
(f) General assumptions It is assumed that the data in the stock master file and customer master file has previously been validated. It is also assumed that the system date is set correctly. The new customer master file, produced by Program 3 is named TB17NF.DAT. It is assumed that this file will be renamed CUSTMAST.DAT prior to Program 3 being used in a subsequent run. The user may wish to act upon errors that are reported from Programs 1 and 3 before executed the subsequent program. As such, it was thought unsuitable to produce an overall control program that would run Programs 1 to 4 (as sub-programs) in a single run. A control program would however be relatively simple to implement with minor modifications required for each program (i.e. changing "STOP RUN" to "EXIT PROGRAM").
(g) Check digits Both the customer code and part number record items consist of 4 and 5 digit numbers, respectively, followed by a check digit. The check digit is determined using the Modulo 11 method and is tested in Program 1. The modulo 11 check digit is calculated for each customer code (all transaction records) and part number (for issue and return records) and compared against the check digit of the record read from the transaction file to ensure that these code numbers have been correctly transcribed. Method for Modulo 11 calculation: For an example code, 01234: [( 0*6 ) + ( 1*5 ) + ( 2*4 ) + ( 3*3 ) + ( 4*2 )] divided by 11 with remainder, R. 11 - R = check digit. When R = 1 then check digit is set to "0". When R = 0 then check digit is set to "X". For the above example, 30/11 = 2 remainder 8. 11 - 8 =3. Hence, 012343 is correct code.
(h) File/record structure charts File/record structure charts:.
(i) Description of test data and file outputs
To ensure the programs are capable of processing data as specified a test file of 102 records was created (TB17TD.DAT). This file contains records that contain errors for programs 1 and 3 as well as a number of valid records that test the normal function of each program. A summary of the expected results is shown below. A combination of lower and upper case characters were used to test Program 1's ability to convert lower to upper case check digits and record type codes. For Program 3 the customer master file and stock master file were also created with test data that comply with the transaction test data. A print out of each file is given below. The print out of TB17TD.DAT also indicates whether the record is valid or contains an error (or errors), specifying what that error should be. For creation type records, the name field is used where ever possible, to specify the error type (validity). Likewise, the name field is also used in records in CUSTMAST.DAT to indicate either errors or whether processed or not. Transaction File TB17TD.DAT Number of records: 102 Number of Program 2 error records: 26 Customer Master file CUSTMAST.DAT Number of records: 58 Number of Program 3 error transactions: 12 Number created: 5 Number deleted: 5 Stock master file STCKMAST.DAT Number of records: 20 Number of records altered: 9 New customer master file TB17NF.DAT Number of records: 58 Number of debtors: 2 Each of the files produced (TB17VF.DAT, TB17SD.DAT, TB17NF.DAT) are printed below, followed by the actual print outs from each program (error records for Program 1 and 3, all records for Programs 2 and 4). Program 1 should produce an error for each error type as well as a small number of multiple errors. A blank line in the test data should be ignored rather than produce an unrecognised error response. The program was also tested to detect empty address fields whether ";" delimiters were used or not. Program 2 and 4 were tested for varying address line numbers. Program 3 test data was designed to produce each possible error type. Also, normal processing was checked by creation and deletion of records of the customer master file and whether the stock master file was correctly modified. For a single part number (100005), 4 successive customers performed a series of transactions that first reduced stock level to 10 (customer 01007); the next customer (10015) then asks for an issue of 100 items producing an error response; the next customer (10023) returns 100 items; the next customer (10031) requests 105 items which should now be valid if the stock master file is being correctly updated with each customer record. Multiple transactions by a single customer were performed. Program 4 also included test data for 2 customers where their balance exceeded their credit limit. The execution of Programs 1 to 4 produced the expected results as proposed above. |