It may be convenient to have a “Print” button on a screen where a record is displayed, but if the screen also allows the user to edit the record, then you may have a problem. If the user edits the record on screen, hits “Print” and then does not save the record, you have an on-paper representation of the record that was never materialized to the database. Worse, if your screen does not do input validation (perhaps leaving it to the backend), the printout may contain information that was never validated by the system.
This is a significant problem from a legal standpoint, especially in highly regulated industries such as medicine, insurance and finance. I am not a lawyer, but there is the possibility that printouts taken from an application could be used as evidence in a court case, especially if the printout contains the company logo and is mistakenly approved by a company official, who as always trusts the system.
To avoid this situation:
- Only place the “Print” button in a screen that is not editable. It can even be banished permanently to a reporting module that does not do any data entry or modification.
- Enable the “Print” button only if there are no pending changes in the screen. This is tricky and can be error-prone, especially when the system undergoes changes.
- Force a “Save” whenever the “Print” button is clicked. This ensures that the data is first validated and then flushed to the database, and the “Print” functionality only displays saved data or nothing at all.