I believe that there is a bug in the system relating to the interaction of the system’s default Suspense Account and the use of Tax Codes (i.e. GST).
The issue arises when a transaction (in my example, a Receipt) has been saved and then is edited. In the first screenshot, a Receipt transaction has been coded to a Sales account with a Tax Code of GST 10%. When this transaction is saved, it correctly shows the GST component (in this case, $100.00) as per the second screenshot. However, as shown in the third screenshot, upon edit and deletion of the Sales account (by “clicking on” the “x” in the Account field), the GST attribute (in this case, GST 10%) appears to be retained (as shown in the fourth screenshot).
I believe that whenever a transaction is edited (with the result that it falls within the ambit of the system’s default Suspense Account), the Tax Code that was entered in the original transaction SHOULD NOT be preserved.
The question is where would you stop? Should the description also be cleared? The unit price? Quantity? Customer? How is the program to know? I can think of examples where you want to edit only a single parameter. How frustrating would it be if the program took control and started editing or deleting things you wanted preserved?
It’s easy to say software should be tailored for a specific aspect of your personal workflow. Much tougher to satisfy a wide range of users with different procedures. I note that in all my years moderating this forum, no one has made your specific complaint before.
Incidentally, this has nothing to do with the Suspense account.
It really is an issue with the Suspense Account as it is the only account for which a Tax Code CANNOT be set (or changed). If it was any other account, then the Tax Code could be altered.
Any balance in Suspense signals a problem. Never attempt to clear the Suspense account with a journal entry. That only hides problems and usually makes both your Balance Sheet and Profit and Loss Statement inaccurate. Problems that caused transactions to post to Suspensemust be identified and corrected.
Simply said it is an accounting error trap to avoid having mistakes in the accounts, and therefore should not have any ability to set ot alter a Tax Code but must be cleared asap.
Most programs have modal data entry. They will prevent you from saving any data which does not meet their consistency check.
Manager instead allows you to save partly entered data despite it not meeting core data requirements but collects the erroneous entries in the suspense account.
Doing so does not magically make invalid data entry valid, the user has to do that. And while the Manager business file contains overtly erroneous data no values or reports should be used because some will simply be wrong.
@ozcpa, you just happened to notice this behavior on transactions in Suspense. Everywhere in the program, automatically populated data remains unchanged when you edit one field that caused another to autofill.
