Looking further, the underlying problem is when Manager does not have sufficient information to determine if a transaction is a sale or purchase, it takes a guess. As a result the totals for sales and purchases are guestimates not actual sales and purchases totals. The solution is for Manager to use guesses to enhance the user interface but always verify any program guesses prior to accepting financial data input.
In more detail
When entering transactions via an invoice, Manager can unambiguously determine if a transaction is a sale or purchase, as separate tabs are provided. It uses this information to process all line items in the transaction and maintain accurate sale and purchase totals for each tax code.
When entering a transaction via “Receipts & Payments” or a “Journal Entry” Manager does not have definitive information to identify if the transaction applies to a sale or purchase. The current design is for Manager to guess. The guess it make is for each line item
- Assume every credit entry is a sale so increases the sales totals (for that tax code)
- Assume every debit entry is a purchase so increases the purchase totals (for that tax code)
The corollary of these assumptions is it:
- Implies a negative value purchase adjustment is exactly the same as a positive value sale adjustment
- Implies a negative value sale adjustment is exactly the same as a positive value purchase adjustment
As a result in Reports → Tax codes, Tax Summary actually displays
||(Line items in JE or R&P decreasing Purchase) + (Line items in JE or R&P increasing sales) + (actual Sales entered via invoices)
||(Line items in JE or R&P decreasing Sales) + (Line items in JE or R&P increasing Purchase) + (actual Purchase entered via invoices)
||Actual tax liability
Some examples where Mangers guess results in false accounting records and reports
Goods returned, illustrated for a purchase but the same occurs with sales
Deposit required prior to work commencing with the balance on completions.
Special offer involving refund of cost of one of the items if a bulk purchase is made
Some financial adjustment such as exchange rate adjustments or credit card fees
Manager is an accounting program, reporting false accounting data is a serious bug.
The best way is to structure Managers user interface so when ever a tax code is entered, it can unambiguously be classified as a sale or purchase. On Receipts & Payments that could be done by allowing the user to specify if it is a sale or purchase as describe in the Why do the costs on a journal entry show in the net sales column? thread. The user interface changes for which maybe as simple as allowing the user to change between Sale/Purchase instead of Receipt/Payment after selecting they want to create a receipt or they want to create a payment.
Only report the difference between purchase and sales. All users who are currently using the sales or purchase data separately would object however these are the same users currently reporting false data.
Remove the ability to use tax codes on journal entries as well as Receipts & Payments. This would result in a significant decrease in program functionality if permanent but is probably a good idea when Sale/Purchase status is unknown.
External correction of Managers accounting error
The incorrectly classified purchases line items (negative) can be found with the following custom report
The equivalent for incorrectly classified sales line items (negative) can be found with the following custom report (Replace “Payment” with “Receipt” and “Amount” with “Amount (sign reversed)”, & update report name
Which displays Managers purchase accounting error. In this test business it shows
Which can be manually subtracted from the sales and purchase data in the tax summary to correct the purchasing accounting errors (Note in this test case no real sales were entered).
The external correction solution described above works because:
Managers core data entry error is, it does not know if a line item on its own pertains to a sale or purchase
Manager users enter most Purchase transactions as “Payments” and most sales transactions are entered as “Receipts”
If the Manager user reads the “Payment” / “Receipt” drop down to mean “Purchase” / “Sales” (typically the only thing a user would need to check is returns are entered showing a negative amount) then Manager does have a definitive way of identify every purchase and every sales line item. Hence the above custom report works.
Manager could implement this internally simply by looking at the existing Receipt / Payment flag to deciding if a transactions a Sale or Purchase. Unfortunately the resultant correction of some old locked data would cause some users a problem. So fixing the problem requires something like this solution.