I just updated to v20.8.31 and my bank balance is now incorrect. I think I was on v20.5.40 prior to the upgrade. This appears to be caused because Receipts and Payments amounts do not include the GST portion. See attached screenshot.
Can you please point me in the right direction to fix this?
I understand that, however, this reported correctly in previous versions and made it easier to enter. It appears it has now changed. I would need to audit every transaction every done. Seems and odd approach by devs
The business received the correct amount of money.
Rather than entering a receipt of $110, we entered a receipt of $100, marked it as 10% GST and left the amounts are tax inclusive box unchecked. This was a faster way to enter the data.
This resulted in a receipt of $110 in prior versions.
However, in this new version it results in a receipt of only $100. Hence, as a result of upgrading to the new version, the bank account balance in manager no longer reconciles with my actual bank account.
All impacted transactions are understated by 10%.
Whilst I agree, I may not have entered the information in the preferred manner, the fact is it worked perfectly and balanced perfectly until this upgrade.
No, this is not a bug. The user who started the topic was not entering transactions correctly, combining receipts and payments on a single transaction, applying tax codes incorrectly, and posting to the wrong accounts.
Properly entered receipts and payments do not exclude GST.
I’m not interested in pushing the debate as to whether this is a bug, fix or feature and am not requesting the functionality be changed. I just wanted to understand the change, fix my accounts and make others aware that they may experience the same issue.
After the upgrade my calculated bank balance in manager.io changed. This was unexpected to say the least and shows a significant change to manager.io in relation to the way it calculates totals. I have manually adjusted the impacted entries to resolve the issue. But I wanted to make others aware of the significant change.
Effectively, the ‘amounts are tax inclusive’ tickbox has no effect in this scenario. Whereas, previously if it was unticked, the total amount was the sum of the entered amount and the calculated tax. After the upgrade, the button has no effect. This is a fundamental difference to the way the program operates. It also affects existing transactions which now have a different total as compared to prior to the upgrade.
I chose to enter the data this way as it fast-tracked the data entry. I believed automatically calculating the tax proportion was a feature of manager.io to simplify my life. Why else would the option be there. Keep in mind all the data was accepted and all balances and reports were correct prior to the upgrade.
In regards to your comments about entering both accounts receivable and accounts payable on the same entry, this was the suggested approach from the support team on this forum. I believe it is still the correct way to do the entry.
In regards to comments about posting to incorrect accounts, that is not the case. All transactions were posted to the correct account and all reports were correct prior to the upgrade.
Whilst you state that the tax column should not be populated for receipts and payments, I don’t believe your statement is correct. I believe this statement is only true where the receipt or payment is against accounts receivable or account payable. Where a receipt or payment is entered directly, tax codes should apply.
The ability to enter a pre-tax amount into manager.io and allow it to calculate the total was a time-saving feature. It seems it has now been removed or is broken. I have adjusted my entries and others will probably need to do the same too.
I have to disagree although we are probably only arguing semantics here.
It doesn’t matter what you call it.
Manager has changed how it deals with tax and initial “amounts”. It was always the case users had to enter the data in a particular fashion now it appears manager is deriving the amount. It should not have changed that.
This is exactly how I have always understood manager should have worked in the past. Why does it not work this way now? How is it the way it worked before was right and acceptable at the time but it’s wrong that we do it that way now?
This exactly leads into my other thread where manager has changed my balance sheet. This is probably why, I have done it this way myself. So this is a third major feature change I have to fix in my data in recent history.
The amount you enter into that column (whether it be debits, credits, amount etc), that flag has always indicated whether the amount entered includes or doesn’t include tax.
Why has that changed?
By whose definition? There are valid use cases for entering them as such. I have suppliers that provide tax exclusive invoices that I pay immediately and enter via payments and receipts.
Users have had to work around poorly implemented manager “features” for years. You shouldn’t say users are doing it wrong because manager has updated how it decides to handle it or how they have had to previously work around such problems.
It’s very wrong of @lubos to make such changes without some form of being able to rectify the affected entries and if it is not determinable at managers end, then it should not be implemented without warning.
Hence my thread about fear of updating. Because unless your brain and Lubos’ brain are in complete sync, something will break.
This is not true. If the tax-inclusive box was ticked, the entered amount (the product of quantity and unit price) has always been interpreted to include tax. So the tax amount was backed out to determine the effective tax-exclusive price. This has not changed. But you would certainly have seen incorrect results if you mistakenly applied the tax code to both invoices and receipts/payments, as you were doing.
I do not understand this claim. Can you illustrate it?
To allow for other situations where the option was appropriate.
Manager does not protect you from mistakes. There is no logic to prevent erroneous entries.
And that is exactly the context in which the comment was made.
I’m not trying debate whether this is a bug or not. I’ve adjusted my entries and have moved on. Others will need to do the same.
Thanks for pointing out the ability to put a formula in the amount field. That will be helpful in future.
“It also affects existing transactions which now have a different total as compared to prior to the upgrade.”
I meant that all existing transactions that are affected by this issue also need to be corrected. It doesn’t just apply to newly entered transaction - but also to existing transactions. Just letting others know they need to fix all impacted transaction - not just future transactions.