Program functions
Overview | Data entry | Sorting | Validation | Update | Reporting | Inquiries
Case Study (Intro & data files | Batch (input | sort | validate | update) | Reports | Inquiries )
Data processing
Overview
In any Data processing system, programs (or computer instructions) are used to manipulate the data. This page deals with properties (or functions) these programs typically have.
Case Study: Debtors (Accounts Receivable)
(1): Introduction
In order to demonstrate how batch input is achieved, and basic report types, we will use a Debtors' (Accounts Receivable) Sub-system as a Case Study.
- Basically;
* A Debtor is a person who owes you money.
* A Debtors' Ledger is a systematic collection of individual accounts.
(2): Debtors (Accounts Receivable) - data files
The following datafiles are used for the batch file case study;
|
Data entry
Interactive online
Data entry is Online: Here the applications program prompts the operator for the different fields.
Advantages
- Some (batch type) errors are impossible
- Field length, type, and a certain amount of content are validated at the time of input
- Operators, because they have to fix errors themselves know which ones not to make again.
Disadvantages
- Comparative slowness, and tying up CPU time.
- For this reason, larger installations often have a front end processor (extra CPU), or intelligent terminals (such as PC's) just to look after the data entry.
Batch
Traditional Practices
In traditional systems data entry was Offline: Here
- No applications program is written for this;
- The data is keyed straight onto floppy disks (or a hard disk), exactly as the staff perceive it.
- Any validation comes later.
Modern Practices
- The idea of the data being keyed in twice, and the hardware checking discrepancies was mostly abandoned as labour costs rose and machine/processing costs dropped. A compromise is where the data being keyed is displayed on a screen and the operator has the opportunity to check visually whether the data is correct/sufficient, and to alter anything in error.
(3/4): Debtors Batch input
Transactions have occurred, hence they are typed into a batch transaction file. Just prior to this happening some batch checking totals are done using the source forms, usually, the number of transactions and the total dollar value of the batch. This is placed in a 'batch header'. The transactions are then entered, in the order they arrived in.
Notes:
- The transactions are not in a sorted order.
- An invalid account has been enterer (10015) to show how a batch system handles errors.
|
Sorting
Interactive online
Sorting occurs when files need to be reorganised, such as in the case of disk optimisation, or to improve performance of the index in an index sequential file.
Batch
In batch processing is used to get the VALID data from the validation program (which was entered in random order) into the same order as the master file.
Obviously the primary key for the sort is the key of the master file, but a secondary key could be the transaction type so that all transactions of the same type come together, perhaps even in a special order.
A simple example is for maintenance: we could get 3 amendments before the deletion of a record (to bring the information up to date), or alternatively, to know as soon as possible that an (illegal) attempt at mixed maintenance's has been perpetrated (i.e try to delete a record then amend it!).
(5): Debtors - Sort Batch
Prior to update the batch file is sorted;
|
Validation
Interactive online
The following checks are made:
- Field of appropriate type (alpha or numeric)
- Is the field optional or mandatory (essential)
- Is the content within a particular range, or list (eg month is 1-12, sex is F or M)
- Should the content be a member of a particular list, either in a file or in a table. (eg valid department numbers)
- Does a code have a particular pattern or algorithm associated with it (eg check digit).
- Does the value in this field relate to any other field (eg if the person is on a salary they don't have an award rate).
- Does the information have to be entered in any special sequence. (More appropriate to batch processing).
- Does this transaction have the correct relationship with the master file (eg you can't pay a person who is not there, or create someone who already exists).
Batch
Data is validated as for interactive but for batch processing, further validation is done on the batch header: at least for
- Batch no,
Date,
Document count, and
Batch value.
This information is then matched against the actual document input to the system, and action taken if there are inconsistencies.
The major purpose is to ensure documents are not lost or entered twice.
(6/7/8): Debtors - Validate Batch
- This may be a two part process;
Validate accuracy of transactions
Produce batch Validation/error report
Here each transaction is examined.
- Fields are checked, such as; account number, transaction type, non-zero amounts etc.
- A batch transaction counter is incremented by 1
- The batch total amount is increased.
- A report record may be generated that shows the transactions -- with or without errors.
Notes:
- As the Transaction batch file is sorted in the same order as the Masterfile a sequential read of both files may be done to validate the Account Number.
- Other Tables may be used (and stored in the computers memory) to check for valid transaction types.
The following Batch /Error Report would be printed;
The batch would then be corrected as;
.. and the Batch Sort/Validation/Update would proceed.
|
Update
This is the process of changing the information on the master file
Interactive online
In interactive systems updating occurs immediately after the data is entered and validated.
Batch
In batch processing updating data is the third program, following the batch validation and sort.
(9): Debtors - Update Batch
Update the transaction file with the Batch Transaction file.
Since both the transaction and batch transaction files are sorted a single sequential read will enable the transaction file to be updated, to become;
|
Reporting
- Reports may be
Regular, or
As required
Interactive online
In interactive systems most reports are spooled (saved) to a hard disk. It may then be viewed on the screen. A hard (paper) copy can be requested, or the report may be sent electronically to another computer, or the report may be deleted.
Batch
These reports are almost always on hard copy (paper) as they will be referred to several times by different people, and kept for checking and reference later.
(10): Debtors - Reports
Many reports may be generated by a Data Processing system. Using the Debtors' System we will display a few of the types of reports commonly encountered.
* Masterfile Reports
* Lists
* Complex relationship (Multi-level)
* Summary
* Label
* Pre-printed
Masterfile - Debtors
These reports display the contents of the masterfile
List
These reports display sections of a masterfile, eg. Client phone list
COMPLEX RELATIONSHIPS - Aged Trial Balance
SUMMARY - Transaction Analysis
These reports often list analysis codes and the current status of transactions when applied to these codes.
LABELS
PRE-PRINTED - Statements, Cheques
Forms such as Statements and Cheques are often pre-printed, in the company colours and with appropriate logos.
Hence, programs need to be designed to handle customised forms.
Debtor statements is also an example of complex / multi-level reporting.
|
Inquiries
Interactive online
These are usually online, the program asking for the nature of the inquiry and key, and then producing the results on the screen (eg Q. Which file do you want, which person? A. Current balances C. LYON). This type of work is used in banks, travel agents etc, and the super-efficient ones give a computer printout of the results as well. (eg Bank statements on demand). Note that this last example which primarily is an inquiry, is part 'report' and part update, as the 'date last statement' will have to be changed on the file.
Example: Debtor Inquiry following
Batch
In a batch-processing environment the inquiry is handled by looking up the latest report.
(11): Debtors - Inquiries
|
[10/9/92 Rev: 12/9/97] © 1992-97 V/2-Com (Verhaart), P O Box 8415, Havelock North, New Zealand.