I have been using the Server version for a number of years
Very pleased with Manager
Currently on version 19.7.62
I have stayed with this version coz I was told that future versions would always be backwardly compatible with previous version backups
But as I am currently thinking of upgrading the server version I decided to test a backup with the Desktop version 21.3.75 first
I struck trouble first off with Sales Invoices - seems the GST component of the receipt is not moved to the new version
Check if you have entries in suspense. The newer versions require users define the account used by tax codes.
Go to Settings â taxcodes
Open the edit screen of a taxcode and check what account is set
The listings in your screen shots do not illustrate your situation adequately. They only show that your customers (apparently) partially paid their invoices. You need to post screen shots of the Edit screens for transactions related to a single sale:
Sales invoice
Receipt
Likewise, the list of transactions does not illustrate the problem. We have no way of knowing what these entries are connected to. Post screen shots of:
Exchange rates in effect at the time of a transaction
Edit screen of the transaction itself
Finally, please answer @Patchâs question about whether you have anything in your Suspense account.
You may conclude that the amount of 1654.06 shown in the receipt unit price is incorrect, but it is the extax amount and is correct if GST is applied to that amount, as it is in version 19.7.62
Here is the receipt as shown in 19.7.62:
Thanks for the link, yeah, itâs the same problem I have
I did do a search before I posted, but did not find anything
As I said, I was assured that backup files would always be compatible with future versions
It would appear that assurance has not been honored
If it is âincorrectâ to apply a taxcode to receipts, why does the current version still have a âAmounts are tax inclusiveâ checkbox?
The older versions handled the taxcode situation correctly
They did NOT apply taxcodes twice
I literally now have thousands of invoices that will need to be amended if I am to upgrade
Any suggestions other than manually editing thousands of receipts?
OK Tut, seems (as usual) the user is wrong
I stupidly did not foresee that the rules would change in future versions making my accounts not upgradeable
You say that the taxcode was âsimply ignoredâ in previous versions
If that was true then the older versions would have had exactly the same problem as the current version
Older versions do not have that problem
In the older versions the extax amount in each line item of the receipt is adjusted by the taxcode rate of the line item if âaccountsincludetaxâ is false
If you examine my screenshots you will see that is true
Any answer to my question on how to to fix this issue for the thousands of invoices I have that are not compatible with the newer versions?
One way that Manager could honor itâs assurance of upgradability would be to adjust receipts for the revised format when importing from a backup
Basically if the version number of the app making the backup is earlier than the version where the logic changed then:
If âaccountsincludetaxâ is false on the original receipt then adjust any line item extax amount by the taxcode rate of the line item of the original receipt and make âaccountsincludetaxâ true
Please advise if Manager would be willing to implement this fix
Itâs not a lot of work
The ârulesâ did not change. The taxable transactions were always the sales invoices, not the receipts recording money received against them. What changed was that the program previously allowed you to apply tax incorrectly on a line item posted to Accounts receivable. This resulted in your invoices appearing to be paid in full, but it meant that the tax amount was being counted twice, once on the sales invoice and again on the receipt. So, if you relied on Manager for reporting output GST, you probably over-reported for all those sales. That means you have a bigger problem than the challenge of correcting thousands of past receipts (not invoices). You may need to correct past tax filings.
No, I did not say the tax code was ignored in previous versions. I just said it was ignored. But I could have been clearer. Your question about âwhy does the current version still have a âAmounts are tax inclusiveâ checkboxâ and your statement that âolder versions handled the taxcode situation correctlyâ were in the same paragraph. I interpreted them (apparently incorrectly) as being about the same subject, the checkbox. You had not checked the box on any transactions you showed, so it really did not make any sense to me for you to be making the point at all. Since the comment did not seem important, I gave it only a brief answer. From my original understanding of your question, I should have said something like âthe new version of the program would have ignored the checkbox if you checked it.â Based on what you have now written, I see that you thought I meant the program was ignoring the tax code itself when you erroneously applied it to receipts recording settlement of sales invoices. I apologize for not explaining in greater detail.
The program has always treated tax codes the same way as far as they affect this subject. The change is that it previously allowed you to apply them in situations where you should not. In other words, it assumed you knew when to apply a tax code and gave you the flexibility to make an accounting mistakeâthousands of times. Now it wonât allow that.
All your sales invoices are fully compatible. Your receipts are what requiring correcting. Every line item on a receipt posted against Accounts receivable needs to have its tax code removed. And the unit prices need to be changed to match the full amount receivable on the corresponding sales invoices including the tax. This is best done, as @Patch said, using Batch Update. The tax codes are easily removed. Changing the unit prices will probably be easiest to change by adding some columns for extra calculations during the spreadsheet phase of the update, then removing the old unit prices.
As a forum moderator, I am the wrong person to ask. But I doubt the developer will incorporate code to correct usersâ past accounting mistakes. You speak of this as a revised format. But it is not. The program no longer allows you to make the same mistake again. The programâs logic did not change.
You ask me what I would do in the position of the program manager
I am a (niche) software developer in a small company
To me, the most important thing I can do as a software manager (which I am) is to honor any commitment that I make to our users, even if it did mean a little work
But as a software developer I know there is very little work in my suggestion - maybe 2 lines of code and some testing before a new release
It was @lubos who gave me the undertaking regarding the future compatibility of importing backups from old versions, so perhaps it should be him that confirms to me whether ManagerIO will honor that assurance or not
Be objective. That undertaking was honored. You can and did import your backup. Your complaint is that the conversion script does not remedy your prior accounting errors. Had your receipts been entered correctly in the older version, you would not be in this situation.
How do you expect the developer to foresee and retroactively correct every mistake a user could make? Did you never look at your financial statements to see if they matched your expectations? Did you ever ask an accountant to verify your accounting practices? Manager is only a tool. It can be misused. The developer cannot realistically be held responsible for a userâs understanding of accounting principles.
I am absolutely objective @Tut
You are taking the route that I have seen you take so often over the years - blame the user!
Let me phase your question slightly differently
How do you expect the user to foresee changes that makes data from previous versions incompatible with future versions?
Anyway, itâs only a rhetorical question, I donât want to get boxed around the ears by you any more
My financial statements using the old version perfectly match my expectations
Not only does my accountant verify our financial statements (for 3 entities), the auditor also accepts them
I repeat, version 19.7.62 works just fine
I also repeat I am very happy with Manager and its interface
Itâs a great product
What I do find disappointing is you (@tut) are always blaming the user - itâs very predictable
Makes me feel sorry for the users Iâve seen you belittle over the years
But I believe you are doing your best, itâs probably just your style
More importantly what I find disappointing is that you seem to be saying this importing bug will not be fixed
This is not about whether the previous versions were right or wrong or whether Iâm a stupid user or not
Itâs about fixing the issue of past backups being compatible with current versions
Let me hear from @lubos regarding whether he is prepared to implement the small fix that it would take to make past backups compatible with the later (and future) versions of the app, as he assured me they would be
I donât. There actually have been some reporting changes that did. But this is not one.
Does your accountant realize you are assessing GST on sales twice for every invoice? Or just looking at whether your books balance and filing taxes in the most advantageous way based on your statements? Likewise for your auditor? And what is the auditorâs role? Is the auditor working for you to verify that your books accurately reflect your financial position and performance? Has the auditor followed a sampling of transactions through your entire workflow? Or is the auditor working for the government, and therefore perfectly happy if you overpay taxes?
Sorry to have spent so much time explaining the problem you complained about. I also apologize for trying to help you avoid making the same errors in the future and possibly keep you out of trouble with your authorities. I can appreciate it is not good news to learn how much work you have before you to unwind the mistakes of the past. But my role is not to enable your continued use of incorrect accounting practices. And even if the developer were to reverse the change that triggered your discovery of the errors, your records would still contain those thousands of incorrect receipts. And your tax accounting would still be wrong.
Oh dear
Tut, you just canât help yourself
I believe you mean well but you just have to throw blame to other people all the time
Even my accountant and auditor now
Well on their behalf I will explain to you how you are wrong in asserting that they did not alert me to the fact that I had paid tax twice (clue: I hadnât)
Below is a series of screenshots made from version 19.7.62 using the fictional company SouthWind
You will see that the tax code for both the invoice and the receipt is GST 10%
You will see that in the Tax Summary report that the amount of GST is not reported twice
You will also see in the Tax Summary report that the amount of GST reported is actually correct
But you have asserted that I paid tax twice
Iâll pass your apology to my accountant and auditor
As I have said multiple times previously - version 19.7.62 works fine and reports GST correctly
However, in attacking my bookkeeping practices, you are missing (or fudging) the point
The point is that I was assured that past backups would be compatible with future versions
They are not - well, at the moment
The problem can be fixed relatively easily, yet you persist in making false assertions that have little to do with the main point
Honestly - itâs a bewildering attitudeâŚ
And what is the balance of your tax liability account in your Southwind company after these transactions? what about Accounts receivable? I cannot replicate your example because I am many hundreds of updates beyond v19.7.62.
