Currently, all cash transactions are assumed to be tax-inclusive. This makes using standard unit prices on line items, whether inventory items, non-inventory items, or manual entries impossible. You must first calculate the tax outside the program and add it to the unit price.
I suggest having the same option as on sales and purchase invoices. Functionality would be identical.
(The title sounds backwards, because entries are currently tax-inclusive. Why not a tax-exclusive option? Two reasons: (1) consistency with sales and purchase invoice entry procedures where users have encountered this approach before and (2) it will be more intuitive to add the characteristic of tax-inclusion than to subtract it.
Since the default was to include tax, and now the default is to exclude tax, this caused a bit of confusion this week - an API script started creating bank transactions that doubled up on the tax amountā¦ because I was saving the amount including tax and then adding a tax code.
I understand that changes like this will occasionally cause frustration. I appreciate that the changelog exists, because it allowed me to quickly identify the cause of the problem.
My request is that the changelog continue to be regularly updated (as it has been so far) ā because it is incredibly useful in situations like this.
I donāt understand what you might be referring to, @ShaneAU. Before v17.11.20, all cash transactions, whether receipt or payment, had no option to be designated as tax-exclusive or tax-inclusive. All, without exception, were tax-inclusive. This was true long ago, before Bank Accounts and Cash Accounts tabs were combined into the single Cash Accounts tab. It was true during the period when all cash and bank accounts were handled under the Cash Accounts tab. And it was still true when the tabs were split apart again at v17.9.0. Prior to v17.11.20, the only way to show a tax-exclusive sale or purchase was to enter an invoice. And then, the default was tax-exclusive.
When creating those receipts and payments prior to v17.11.20, there was no Subtotal line. There was a Total line and another listing how much tax was included. So I donāt see how your November 17, 2017 bank transaction could have the components you listed, assuming it was really created on that date.
When the change was introduced at v17.11.20, prior receipts and payments, which could only have been created as tax-inclusive, automatically had the [_] Amounts are tax inclusive box checked. I have confirmed that all my past cash transactions, no matter which version of the program they were created under and whether in a cash or bank account, has the box checked. That is so whether a tax code was applied or not. My interpretation of this conversion action was that it was specifically done to preclude the type of problem you describe.
Since you say you have a $300 bank transaction from before the change, you must have saved a paper copy or PDF. Or perhaps you are maintaining older, operating versions of Manager. Can you provide screen shots supporting you description of what you see, such as a copy of the completed form and verification of the version number of the program?
Exactly. I apologise if my post was unclear, but I understand & agree with this.
This is the problem Iām facing - they were not automatically checked.
However ā since yours were, that indicates the problem isnāt as widespread as I feared, which Iām glad to hear.
There is a copy of all transactions in an external system, and they are copied directly from that system to Manager via the API. Due to some thorough testing done beforehand, I know that the values in Manager matched the external system exactly after the transfers were done.
Now, I can see that the values are exactly 10% higher in each case (all transactions have 10% GST).
Since you state that it is working correctly for you, I am relieved ā I will do further investigation on my end and go even further back with the transactions to see if I can find any that have had that checkbox automatically ticked as a result of the upgrade.
My concern was that a step had been missed, and that checkbox had not been enabled for anyone.
Update: Iāve found other transactions that have had the checkbox enabled. I will assume from this point onward that the transactions without it have somehow been modified after the fact. Thanks for your quick response Tut.
What form do these copies exist in? You say they are copied from that system to Manager, but are they not then being copied to the current version of Manager?
The question is what form did the transactions exist in within the data files converted by Manager, not within some external system.
Regarding your update, do those transactions that had the box checked predate whenever you started your external archiving/copying scheme?
Upon further investigation, Iāve been able to verify that everything is working correctly.
I had a limited amount of time to test initially, but what I saw seemed to indicate a serious bug so I felt it important to raise that possibility as soon as possible.
Thank you for your assistance @Tut - your quick response stating that it was working fine for you meant I could redirect my focus back internally.
So, what happened?
Due to the addition of the new field, the structure of the API request needed updating to match. The transactions that did not have the checkbox enabled in my business were either:
Created after the update (of course - this makes sense)
OR, Created prior to the update, but modified by the API since and regressed as a result (this is what caused the confusion above - none of the transactions Iād looked at had the checkbox enabled).
Iāve been able to prove that all broken transactions were caused by using the out-of-date field list that didnāt include AmountsIncludeTax.
The AmountsIncludeTax field was overridden as a result, and reverted to its default value (false), whenever a bank transaction was modified.
Re-transferring all payments with this field set to ātrueā resolves the issue.
option as on sales and purchase invoices. Functionality would be identical.