Does anyone else fear updating manager as much as I do?

Yes I found it thank you. My point is not that it’s so difficult to find, but I was never looking for it in the past, never needed it in the past, so never noticed it at the bottom. What this means is that many other users are using the program without being aware of the newsletter which results in posts like the OP. Hence my point is that the newsletter is not the most effective way to handle upgrades like this one.

Having said that, @Brucanna has stated in the GST Worksheet not reflecting correctly topic that the issue that is causing so many people distress at the moment is that the latest Manager releases are now making GST/VAT return figures inaccurate that were accurate before the upgrade which is really worrying.

The most important thing about an accounting program is to have confidence that the figures shown are accurate. However they are no longer accurate and also no longer meet international accounting standards!

This update should never have been implemented until all problems relating to it were resolved. I won’t be upgrading for some time until this bug has been fixed!

1 Like

So what exactly is different? It comes down to specific accounts. As far as I’m aware, there was no fixed bug which would have changed your tax liability amount on balance sheet.

This issue cannot be possibly related as it’s not impacting balance sheet or profit & loss statement in any way.

There are several:

  • it seems zero balance invoices may be one problem, I was using that as a way to convert GST to non-GST sales. I would create a sales invoice where there was a negative qty with tax and a positive equal quantity without tax, balances to zero and it (did in 20.5.17) create a GST credit (yes, I know it’s probably not the best way, but in the way manager use to account for things, it worked… until it didn’t, lol. I will manually go back and fix those).
  • (I’m not going to articulate this well, apologies in advance, and this one is probably my error, but) Applying tax in/on line items that are capital accounts > personal contributions > drawings… I probably shouldn’t have allocated a tax code on these lines, this was in error, but with a tax code applied, it is treated differently between manager versions. Even though the payment is entered “tax inclusive”, the reported entries under capital accounts is different. One is in total regardless of tax code, the other is after removing the tax value. (Again, I realise there shouldn’t be a tax value on this particular entry, but there is and manager is treating it differently between versions).

Here’s just one example of the second point:


Ahhh, it wasn’t until I dove into the payment / edit screen and noted it’s no longer payment & receipts but it is specifically a payment type. Have you finally separated the payment and receipts as far as tax implementation is concerned? That might be what it is. This had proven an issue in the past where other users had reported problems with returned items and the fact it was considered tax credits/debits (depending on supplier or customer)…

Funny thing is, that particular tax input on my part is incorrectly applied anyway, it was a drawing and should not have any tax implications whatsoever, so this has highlighted where I need to fix the entry, but what I don’t quite understand is it appears to me that one appears as an adjustment to a capital account with tax applied and one without, yet both entries are identical, after all, it’s just the backup database.

I’ve only attached one screen shot below, because they are both identical:

I just checked the BAS related to that particular entry and there is a difference in the total amount owing to the ATO of $2. I’m not about to go and edit a BAS of 4 years ago, but that ripples on through to today, highlighting my initial point that users should not only lock the database, but probably backup/save it, create a new one and transfer the balances so that mistakes like this don’t plague us in the following years.

I also found that $200 has been converted from the top G1-G9 section to the bottom G10-G20 section. The net effect is the same, but it has changed the reporting amount for those sections.

My tax liability as at today’s date has a net difference of $300 (and not in my favour).
If I take the date back to the end of the last financial year, every major figure is out:

  • my assets have increased by $60
  • liabilities up almost $270*
  • equity down almost exactly $200
  • my income to that year end is also down $265

* I think this means that although my tax liability today is $300, that’s based on an adjusted tax liability at the end of last financial year of $270, which I think means the adjusted liability of this year is just $30…

What I think I am going to have to do is split this database in two: create two backups, in one purge all entries prior to last tax lodgement and in the other purge all entries after tax lodgement and bring in new opening balances based on the old version, since that’s what I’ve used to lodge my tax and I’m not going to piss off the ATO at this present time :wink:

Arrrgh… I’ve only just picked up (in a re-read of this before posting) my retained earnings are out in the top screen shots. I didn’t pick it up because the format of the summary report is slightly different and I thought it may have just been calculated differently, but in looking at it again, all these entries ($454 worth) are related to several payments over the date.

This is the same database open in two different versions of manager.

I’m only more confused now, shutting down for the night

In previous versions, if you’ve used tax code on capital accounts, the tax code would be ignored and the tax amount would simply be put into capital account as well.

For example, here is one of the topics discussing the issue:

This has been fixed which means if you use tax code on capital account transactions, tax amount will be put into tax account.

For example, you have put GST 10% tax code on your drawings. That’s incorrect.

As per Simpler BAS GST bookkeeping guide | Australian Taxation Office

For the proportion of private expense not related to your business, GST credits are not claimable.

The previous versions of Manager were guilty of trying to quietly “save users” when they’ve done something incorrect. Newer versions are making it more obvious when something is done incorrectly.

In your case, generate Tax Audit report for the entire history of your business and check how much GST is being allocated to Capital Accounts account. You probably shouldn’t have any GST allocated to this account. So fix these capital accounts entries by removing GST tax code - especially from drawings as these transactions are not GST reportable and thus should have no tax code selected.

Which highlights the significance of this thread. Although you don’t consider it a “bug” that you fixed, it is something that you did in fact “fix” and change what’s presented to the user based on their previous input. Manager now processes the same information differently, which changes the resulting reports, propagating several years, and it’s this that heightens my fear of updating.

I did state numerous times that I now realise I have recorded the information wrong, and I have only learned of that error because manager changed the way it processes that information and the fact that I had just re-printed the documents from the laptop and the numbers didn’t match.

At any rate, that only clarifies one problem, I’ll work the rest out as I go along. Good idea with the tax audit, that’s not a report I’ve used before. Thanks for the clarification re personal contribution taxes.

Just checked the release notes for this, I don’t see anything about this tax change or the tax changes in:

You’ve made a fundamental change that has caused me (and I suspect others) some grief.

Users have had to develop ways to account for things that manager couldn’t do, or poorly implemented, in the past. When that breaks, you really can’t blame users for doing it wrong to begin with.

I think you need to develop a tool to identify to users “stuff” (entries or outputs) that will change as a result of how manager implements features and accountancy principles. Because those sort of fundamental changes can have legal implications.

This change was introduced within new general ledger engine.

General ledger was completely rewritten to address performance issues, all known inventory / forex bugs, expanded custom reports and many other subtle improvements (e.g. when drilling-down into transactions, you will see more relevant columns based on the context).

This was a case when a bug has became a feature for some users. When you rely on broken behaviour and it gets fixed, it will cause some grief.

In your referenced topic, the user was using GST 10% on accounts receivable as a way to multiply tax-exclusive amount.

If you need to multiply tax-exclusive amount, just use formula within the field as per:

https://www.manager.io/guides/18222

For example, instead of entering 100 and selecting tax code to get 110. You could have just typed 100*1.1

I too only noticed the Newsletter info a couple of months ago. I had no idea it existed before. The heading was “Subscribe to Updates” and I have been careful about controlling when I updated, and how often, so I did not investigate that further, thinking that it meant signing on for auto up-dates. I tend not to read through the whole Manager homepage on a regular basis - I just go to it when I want to update. Can’t remember what prompted me to look for it - may have been something on the forum.

Tried to edit my earlier post and got the message “The requested URL or resource could not be found.”

Clarification of previous post:

I too only noticed the Newsletter info a couple of months ago. I had no idea it existed before. I’ve been getting the “Manager Forum Summary” emails all along and I thought that was your “Newsletter”.

I think when I saw the heading “Subscribe to Updates” I thought it meant signing on for auto-updates. I have been careful about controlling when I updated, and how often, so I did not investigate that further. I tend not to read through the whole Manager homepage on a regular basis - I just go to it when I want to update. Can’t remember what prompted me to look for “Newsletter” - may have been something on the forum.

I think you meant creating a tax entry without any sales or purchase. If that’s what you meant, this is working fine for me.

Yes I dread updating Manager - update as little as possible

1 Like

Allow me to disagree. The error previously was that people used tax codes with receivables and payables which duplicated tax. The core of that problem was that settlement of pre-recorded invoices should have had no impact on taxes.

What should have been done is to A) leave the situation as-is since any entry errors are the user’s fault and not Manager’s; or B) disable taxes on receivables, payables and capital accounts altogether (which is not ideal because what if the user has custom receivable and payable accounts? This control will not be present)

Personally I preferred (A) but any of those options will show the correct total on the receipt.

The fix that was actually made was even more buggy because it confuses the user to what amount has been received. Yes, the user has made a mistake of not recording the receipt properly but the view screen gives them a false confirmation that (amount+tax) was recorded when in fact the tax on the receipt has no bearing on the books.

I say let people deal with their own mistakes because there is not point of taking this responsibility on their behalf.

I hope you reconsider this @lubos and chose an other method that preserves the integrity of receipt totals.

The TL;DR:

When you fundamentally manipulate a report to generate any result that is different to before because of any change in the backend… well, it’s never going to end well. Not everyone using the software is an accountant, has a degree in accounting, etc and my whole point is simply based around the fact that manager works one way and when everyone has adapted it to work with and present their data in a required or usable way (and is subsequently used for submitting documentation to the tax authorities), that then when you “fix broken behaviour” you “break” those documents. They are our legal documents.

For example, and I suspect this will come into its own in the near future, this whole debacle about “receipts vs payments” dual tax codes and tax reporting etc:

How many things are you going to break when you finally decide on how you are going to implement that? And is it going to be our fault because we relied on broken behaviour?


rhetorically:

  • The old general ledger engine was a bug?
  • The old engine (that we relied upon) was providing broken behaviour?

We rely on manager to provide us with consistent reports, sheets, exports and views etc that we use in our business scenarios.

You need to look at how manager is used by the community.

We shouldn’t be blaming users because they entered the data the “wrong way”, the tool shouldn’t be making use case decisions the user has already made.

We create work arounds for managers deficiencies and you can’t consistently blame users for those work arounds because you now have a better idea on how to implement or “fix” something.

You are constantly tweaking reports, modifying queries, upgrading and experimenting with users data, and the presentation of that data, and we are being told consistently to stop relying on managers flaws, but we don’t see them as flaws, we see them as features. And you break them. It’s quite disappointing.

You need to stop “tweaking” and breaking the users experience because you are messing with our legal documents. You are causing frustration and anxiety in dozens of users. Every week there are dozens of threads about database corruption, data loss, reporting errors and deficiencies, debates over best practices and how one person sees it differently to everyone else.

You can’t keep saying we are relying on broken functionality. We are working with the tool you have provided us and you break functionality and it’s becoming a burden on users.

I know it’s not a democracy, it is not open source, it’s not up to a vote, and it is your software to do as you please, but now you are alienating users, breaking databases, breaking reports, user generated custom reports, exports, inventory and stock management, tax reporting and all manner of “bugs”… All these things create frustration, anxiety and despair. Last tax time my mental health deteriorated so much so that I was hospitalised, partly due to managers changes, updates, bug fixes, improvements and updated reports at the time. I screamed out for help in these forums but kept getting shut down and deleted. Mods said one thing, and you said the opposite.

The reports I gave my tax accountant two or three years ago do not marry up with the reports that manager creates today. Yes, they are mostly bug fixes or improvements (or broken behaviours, whatever), the point is, manager will generate a different output today to what it generated a couple of years ago. I have re-submitted multiple BAS entries over the years because the GST Worksheets were wrong, in the end, I threw my hands up and walked away. And yet, I can’t even generate those same reports anymore to satisfy an auditor because “you fixed it”.

From what I read elsewhere you have the intention to change the exporting capability again, so what users have put in place now probably won’t work in the future.

As mentioned above, you are going to implement a payments and receipts tax reporting change that will most likely break what users have been doing for years.

Just like reports, just like custom reports… The general ledger engine, balanced invoices, inventory control, tax reporting, GST worksheet calculations, etc etc. It is not all our fault and you need to provide a methodology to provide integrity of reporting (I have submitted a feature request for explicitly that).

I feel sorry for the cloud users who never know what to expect when they wake up tomorrow, and whilst you might argue “if you don’t like it, don’t update” but users are quickly told “you are dozens or hundreds of versions behind” as if it is our fault.

I could not agree with this more.

regardless of the shortcomings of manager, when a user uses a tool to achieve an end, the tool shouldn’t change anything that was previously put in/reported out because those previous reports generated original documentation that is now different.

I said this above, but manager shouldn’t be making and overriding use case decisions that users have already made.

/rant

A difficult problem.

  • Everyone wants the work they have done to be correct and not change.
  • to have access to new features

But what do you do when

  • the prior work was wrong for many user because of old Manager limitations
  • some users find the pain of the transition to better functionality worse than the current benefit.

My management method is a good backup protocol. Both of the data files, program files, and attaching PDF copies of important reports. Which is the process I have followed with all of my programs for many years.

With that protection I look forward to trying new features on my test system, updating my work system when I’m happy with the functionality.

PS
Old versions of the Manager program are available

I too relay on many layers and typology of backups. But only one thing should be a mantra in every accounting program: data from the past, once a period is closed, should never ever change. It’s illegal!

PS: I know that someone may not like the termin “closed”… let’s call it locked since Manager is a perpetual accounting program… but the tax authority doesn’t care of it!

The archived version of Managers data file viewed with the archived version of Managers program has not changed. That is what you show to the tax authority when asked.

The current version of the data file viewed with the current versions of the Manager program can be different for many reasons

  • User changed something
  • Old report was wrong, and fixed in later versions
  • Functionality improved, old method depreciated or bug fixed.
  • data file corruption

All of which must be managed.

The only way to keep everything exactly the same is not change anything, including every entry in the ideas category of this forum.

But managers paradigm is to break archived versions. You must either use it on a different computer or you must delete the hidden files on your computer.

And while validating those archived versions, the newer version is unusable because it will just re-break the old version.

This is not going to be the case soon. A lot of work has been done this year to get there. You will be able to launch two different versions of Manager side-by-side.

Hallelujah

Sorry but this doesn’t work at all. If you update the program you may each time have a different opening balance. So you are showing to the tax authority something that than you, or I better say Manager, may have then deliberately changed.

Everything that should be solvable just using lockdate saving reports and a simple continuous backup of the database.

"Old method depreciated" should remain into the system for its whole lifetime but not be usable from a date clearly stated and viewable inside Manager.

Come on. We are talking of altering opening balances from the past. It’s illegal. And the most serious thing is that the user may not even notice it. We are not here playing to the little accountant.

Since it’s a perpetual accounting software the way the Manager calculates anything before each closing date should never ever change, ie the detailed opening balance, ie each ledger and subledger of the BS, cannot be altered. From that date Manager can do anything it wants being compliant to law and giving me notice of it.

And beware we are not talking about reporting but only of numbers.

So you are telling me that the only way to be sure that everything remains compliant to law is:

  1. never update Manager?
  2. open a new business every fiscal year?
  3. change software to another one that is compliant to law?

I lost all my custom reports, and worst the possibility to reproduce some of them, with a recent update of Manager. I was a little upset but I created all of them with the new engine and in the end it was not an issue… the new custom reporting engine is better then the previous one. But we are talking of reports!

This is a completely different issue. Someone, with a cloud or server version, could even, reasonably, sue Manager for damages for fraudulent alteration of tax data. In the end the programmer changed his fiscal data without his permission.