In IT systems, data must be converted from human-readable form to computer- readable form. This process is called data input. Data can be input into a computer
Application Software and Application Controls (Study Objective 5) 157
application in many different ways. For example, data can be keyed into blank fields on a computer screen from a keyboard; data can be read from bar codes; or data can be received electronically via EDI or the Web. No matter the manner of input, controls should be in place to ensure that the data entered are accurate and com- plete. You probably know the old computer acronym GIGO, which stands for “Garbage in, garbage out”—a short-hand method of saying that if you enter incor- rect data, you will obviously get incorrect results. Input controls are intended to prevent or detect the “garbage in” so as to avoid incorrect output, or “garbage out.” To illustrate some input controls, Exhibit 4-8 presents a Microsoft Dynamics GP® screen capture of the input screen to add a new employee to the payroll records.
As the data input person prepares to enter data for a new employee, input controls should be in place to ensure the authorization, accuracy, and com- pleteness of that data input. These input controls are of four types:
1. Source document controls
2. Standard procedures for data preparation and error handling 3. Programmed edit checks
4. Control totals and reconciliation
Exhibit 4-8
Employee Maintenance Screen in Microsoft Dynamics® GP
Source Document Controls
In many IT systems and applications, data are keyed in to input screens simi- lar to the Microsoft Dynamics GP®example in Exhibit 4-8. Before those data can be keyed in, the data must be captured and recorded on a source docu- ment. A source document is the paper form used to capture and record the orig- inal data of an accounting transaction. For example, before filling in the blank fields in Exhibit 4-8, the data entry person needs to know the new employee’s name, address, hire date, and many other pieces of information. For new employees, the source document would be a personnel action form, a sample of which appears as Exhibit 4-9.
The data entry person often refers to a copy of the source document to enter the data into the blank fields on the screen. It should also be noted that many IT systems do not use source documents. In cases where the input is automatic, such as Web-based sales, no source documents are generated. Where no source documents are used, the general controls described earlier, such as computer logging of transactions and making and keeping backup files, become more important. Where source documents are used, to minimize the potential for errors, incomplete data, or unauthorized transactions as data are entered from source documents, several source document controls should be used.
Form design: Both the source document and the input screen should be well designed so that they are easy to understand and use, logically organized into groups of related data. For example, notice that employee name and address blanks, or fields, are located very close to each other, since they are logically related. Source documents should have clear and direct instructions embedded into the form. The personnel action form in Exhibit 4-9 has the following instruction line: “Please check the status of the employee.” Finally, the source document design and input screen design should match each other. Ideally, the fields on both forms should be the same and the fields should be in the same order. The closer the source document matches the input screen, the easier it is for the data entry person to complete the input screen without uncertainty and errors.
In many applications, it is not possible to fit all necessary data on a single input screen. This problem is solved by having several related input screens to enter all data. Exhibit 4-10 illustrates a second screen for new employees that allows the input of pay rate data on a pay code screen.
Form authorization and control: The source document should contain an area for authorization by the appropriate manager, such as the bottom left of the form in Exhibit 4-9. The source document forms should be prenumbered and used in sequence. Prenumbering allows for ongoing monitoring and control over blank source documents. If the source document sequence is monitored to ensure that there are no missing numbers in the sequence, most likely no trans- actions will be lost. Finally, blank source documents should be controlled by being kept in a secure area so as to prevent their being misused to initiate an unauthorized transaction.
Retention of source documents: After data from source documents have been keyed into the computer, the source documents should be retained and filed in
Exhibit 4-9
Personnel Action Form FORM DATE 6/12/2003
PERSONNEL ACTION FORM
Part A-Employee Date of Hire
Employee Name Birth Date
Address Sex
SS# Telephone
In Case of Emergency Notify Name
Address
Home Phone Work Phone
Relationship Cell
Part B-Employer
Change From To STATUS
Job Title
Pay Rate Please check the status of the employee:
Hourly OVERTIME STATUS ❒ Exempt ❒ Non Exempt
Billing Rate ❒ Administrative
Salary ❒ Direct with benefits
Status (FT/PT) ❒ Indirect with no benefits
Project Assigned Reasons for Change
New Hire Effective Merit Increase Effective Date
Project Transfer to Effective Date
Termination (Date)
Other (please explain below) Comments:
SAFETY REQUIREMENTS: