I fully support this approach.
Or better still have the field visibility control work in the opposite direction. Only allow entry/specification of a tax codes (or link to a supplier/customer) when the user has specified if it is a sale or purchase. To expand on what this would mean:
For Journal entries
| Type | Effect |
|---|---|
| Not set | Tax code selector (and supplier/customer selector) not shown. |
| Set to Sale | Tax code amounts are applied to sales totals, increasing the sales totals for credits, decreasing the sales totals for debits. |
| Set to Purchase | Tax code amounts are applied to purchase totals, increasing the purchase totals for debits, decreasing the purchase totals for credits. |
| Deleted/cleared | Tax code selector(and supplier/customer selector) would be hidden, and clicking the update button would delete the tax code / supplier / customer selections. |
Having the dependency operating in this direction would:
-
Ensure funds were always unambiguously allocate to the intended component of the tax code, and as a result the totals become a valid measure not an approximation / upper limit.
-
Enable selection of the other party from a supplier or customer menu rather than needing to combine suppliers and customers then select from a list containing both. This facility could also be added at a later date should it’s implementation now be technically demanding.
For compatibility with user selections from older software versions, where tax codes are used but type is not set, the existing behavior would need to be maintained.
For Receipts & Payments entries
Purchase / Sale type
-
For receipts the “Type” should default to “Sale”
-
For Payments the “Type” should default to “Purchase”
-
Where the default is wrong, the user should be able to change a transaction from a sale to purchase or purchase to sale. Typically needed for Goods returned or some foreign exchange adjustments. Transaction type specification ensures negative line items are also recorded accurately such as refunded cost of last item when bulk purchase, some credit card fee adjustments, or refund of deposit when making a final payment.
I’m not convinced that it is necessary to be able to swap between a payment and a receipt after the user had chosen to create a new payment or create a new receipt. Similarly I have trouble identifying a use case to change between a receipt and payment when importing bank statement. The transaction will be a receipt or payment defined by the sign of the amount (however the sale / purchase type may need to be user modified as described above).
I’m less sure of the value in having Receipts or payments which are neither a sale or purchase. If this is valuable then the “Type” would need to support “Null”, “Sale”, or “Purchase” and hide fields as described for Journal Entries, if not the Type would be a “Sale” or “Purchase” for all transactions created in later software versions.