Introduction
QTrendControl software provides separate form for corrections of inspection data, for situations in which an user made a mistake during entering inspection data.
Inspection data input is performed by using dynamically generated inspection forms. While inspection data is being entered in the data input form, a user can edit data without restrictions. Such edits are not logged in audit trail. However, once inspection is confirmed and inspection data is transferred into permanent database, data input form is deleted and data insert is recorded in the audit trail. Any subsequent editing or deletion of inspection data is recorded in the audit trail.
User entering original inspection data into permanent database must belong to "data_input" role.
If a mistake has been done during original data input, a user with proper authorization (a user must belong to "data_correction" role) can correct incorrect data.
Note, however that any such editing or deletion is permanently recorded in the audit trail.
Open Inspection Data Correction Form
Open the inspection data correction form, by clicking the button "Correction of Entered Results", from the main switchboard.
This opens the form for correction of mistakes in entered inspection data.
Records are by default sorted chronologically from first to last inspection (ascending). Since our inspection of interest was the lastly entered inspection, let's change sorting to descending sort. We could also use search or filtering functionalities instead of sorting, if we know what are we looking for.
Now, let's expend all sub-datasheets for the inspection record that we wish to edit.
As you can see, record for each inspection consists of several inter-dependent tables. Therefore we must be very careful and consistent when performing such editing!
Let's imagine the following scenario, user who entered the data has mistakenly entered wrong result for pH parameter. The user entered value 7,236 while correct value should be 8,147.
First, let's indicate in the inspection header that we are doing this correction.
Now, let's change the result value for pH parameter.
We have just changed the value in the Result column. However, this is not enough. Column "Result" is a string type column that holds initial information about result value for all data type values, during the data input form filling. However, the database is copying this value into proper database field with appropriate data type. So we must also change value in that data-type aware column.
This is still not enough. While original value (7,236) was complying to predefined limits, new value (8,147) is violating upper specification limit (USL=8,000), so we must also correct all indicators of result violation!
We must change value of column "Result is OK?" from "True" to "False".
We also need to change value in column "Limits Are Violated?" from "False" to "True" and value in column "Limits violated Count" from 0 to 1.
We will also enter a comment about result data change in the "Result Comment" field.
Ok, that is all, we can now check the whole process in the audit trail.
user "demo_user10" performed original data input, while user "demo_user9" performed data correction.
Conclusion
Mistakes happen. Sometimes users will enter incorrect inspection data that has to be corrected afterwards by a responsible person.
Such corrections can be done through separate data correction form, by a user belonging to "data_correction" role.
User who is performing such corrections must understand underlying database structure in depth, because corrections must be done in a consistent way, in order to preserve data integrity.
All inserts, update and deletes are permanently recorded in the audit trail.
