Symptom: When attempting to open a sale from Lists > Sales By Date, you receive one or both of these errors:

Line Items Missing
This invoice is supposed to have 1 line item(s) and 2 were found. We suggest that you cancel this operation and run a database recovery for the ITEM.TPS file, then try the operation again.
To run the recovery, select Maintenance > Rebuild Indexes > Recover Damaged Data Files.

-and/or-

Payment Total Mismatch
The total of all payments on the invoice does not match the current amount paid as saved on the invoice. The original amount paid recorded for the invoice is 20.09 and the total of all payments is 62.48.
Saving the invoice will adjust the amount paid to the total of all payments.

Cause: Each sale entered in the system creates multiple records in different database files, all pointing back to the invoice record. If something happens that causes the program to not be able to save those files properly before closing, like a system crash or loss of network connection, it risks corrupting some of those files or losing records from them that were not completely saved.

In the case of these two error messages, it usually indicates that records have been lost from the invoice file, but the item and payment records still exist.

As sales are entered, multiple records are created in different parts of the database. Sale 1000 creates invoice record 1000, item records for each item on the sale with pointers to invoice 1000, and one or more payment records with pointers to invoice 1000. As you continue entering sales, the invoice numbers are numbered sequentially.

If you are up to invoice 1023, and there are payments applied to each invoice, but then something happens that corrupts or removes invoice records 1020-1023 from the invoice file, but the other files are still intact, then those items and payments are now pointing to non-existent invoices. As new sales are created, their invoices are numbered sequentially, and they will become 1020, 1021, 1022, and 1023, each adding their own new item and payment records. So now invoice 1020 has the items and payments that were entered with the new sale, but the old item and payment records are still pointing to invoice 1020. When you open the invoice, its record shows that there was a single line item, but it has item records for 2 line items. And it shows that the total amount for the invoice was 20.09, but there are payment records totalling 62.48.

The problem is that because the individual payment records or item records are not bad, there is no way for the recovery process to mark them bad. And the existing invoice records are also not bad, but some were missing, so there is nothing for the recovery process to do there, either.

Solution: Understanding all of the above, the best course of action is to restore a backup from before the issue began.

Look at List > Payments By Date with it set to Show: By Number. The Ref No column shows the invoice number for that payment. You should be able to find a point where they skip backwards. With my above numbers, the payment list goes 1019, 1020, 1021, 1022, 1023, 1020, 1021. If I go to List > Sales By Date, I can open sale 1019 without error. 1020 and 1021 give the above errors, and 1022 and 1023 do not exist. That will allow you to narrow down when the issue began.

By default, the system automatically creates a backup the first time the program is opened every morning. Those backups are held in C:\WQS\BackupA on the server machine. If the program is not being shut down overnight, or if that option was disabled, you should be manually creating backups on a regular basis, so you would need to locate and restore the last backup created prior to the beginning of the issue. The default location for manual backups is C:\WQS\Backup.

It is vitally important if you have a station that is regularly crashing or losing its network connection that you identify and resolve the cause of that issue to prevent it from causing further database corruption.