We are arguing semantics here, I just said you’ll never be free of bugs but I was specifically talking about were “dozens of examples”, not “official bugs”.
We are coming from different ends of the argument. What I am calling a bug (I prefer “change” or “presentation issues”) you call a myriad of terms: user error, engine upgrades, flawed or unintended behaviour, etc. You put the onus back on the user to not use and adapt your program contrary to your design. You are not taking into consideration how it is used in the broader community, especially when it comes to features you don’t, won’t or haven’t yet implemented.
We create work arounds for those lacking/missing features, and you then break and/or change the presentation of that data based on how you intended to interpret the data and not how the user actually presented and intended it to be used in their business model. That (to us) is flawed.
When I say “bug”, “change”, “broken" or “example”, I am referring to any and all of (and not limited to):
- any reports you’ve deleted or reformatted
- any change to implementation or calculation of taxes
- any underlying assumptions you have made about user data and how it should be presented/interpreted
- any underlying queries you’ve modified
- user generated custom reports you’ve deprecated,
- worksheets you’ve updated
- the bad programming paradigms and behaviours you’ve fixed…
- engines you’ve “upgraded”, or replaced, and yes,
- bugs you have fixed, as well as
- current unfixed bugs
Whatever you call it, it is a frustration we don’t need and you need to take some responsibility for the representation, and changes to the representation of our data.
Users have wasted hours and days creating custom reports that you deprecated in one fell swoop.
What happens when you implement the payments and receipts tax changes you’ve posed for years? What users work arounds are going to fall apart and break existing and previously submitted reports?
You may not be changing the actual data we enter (if we enter 5 units, you record 5 units), but you are changing its implementation and presentation which we rely on for legal purposes. I’m very surprised you are missing that very important point.
It is not just the raw data and its storage but also the accompanying implementation and presentation.
You state:
But they do, and they have and so this feature is anything but pointless.
You say the figures will always be right and won’t change, but they will only “not change” if you do not change the underlying structure, and if you do, you need a way to identify that change. That is exactly my point.
In my other thread you just commented on exactly why you would change the output (and rightly so):
And that is my point EXACTLY!
That’s what I’m asking for, a mechanism that reports when those differences appear. Because bugs do get found. You can’t presume you are immune.
That was precisely the point of this whole thread. It is exactly why I’m frustrated with manager.
My previous example was when my sales data balances and tax reporting fails because you didn’t cater for balances invoices, that is “an example”. Yes it’s now fixed (and then it wasn’t, and now it is again), but it makes all my previous BAS submissions wrong. In no way can you consider those previous presentations “right”. And on this last update (again, right as I go to see my accountant) you changed the implementation of tax calculations again which changed my data (in this case, the change was in error, but that takes me days to get to the bottom of. However, unless I run those reports again at a later time, AND MANUALLY COMPARE THEM TO PREVIOUSLY SUBMITTED REPORTS, I’m not going to readily pick that up until next tax time. That’s why I would like a snapshot of important reports. So that I can report on the errors as they are found.
BTW I am happy to have this conversation elsewhere 