No that is part of the question, but a completely separate point. I actually like your suggestion about using history and audit for this as this is precisely the kind of thing where history and audit should be used and would shine - it would be er a history and audit trail.
Knowing why something has changed is important because you can’t fix it until you know why.
The first question and most important question is to do with reconciliation of returns to government. These should always reconcile for legal reasons otherwise how does the government know that you are not cooking the books?
Let’s use VAT returns for example. I submit my VAT returns to the government. First I want my VAT returns in Manager to be the same as what I have submitted to HMRC. So in the event of an audit - everything is reconciled and there is no suggestion of me fiddling the books.
The second point is one of the current flaws in the current design is that there is no backup of my VAT return at the time of submission within Manager. I could submit it today, the program changes tomorrow - I have lost any snapshot of that return linked to that date. I have a backup of pretty much everything else. I should have a backup of anything that I submitted to the government. Not a backup that I can create half an hour before the audit, but one that is created at the time of submission and that I cannot alter. So a backup of the figures used to make that submission is missing.
By all means, let’s go with using history and audit to track changes to previous year’s submissions - as I think that is a good idea. Although I still don’t see how that will tell us why something changes. But having a backup within the program of government submitted paperwork that is stamped with the date of submission at the time is critical for points 1 and 2. To allow reconciliation with returns, proof that you are not cooking the books and lastly a copy of what the original figures were at the time. So I am still keen on a pdf copy for these points.
We need to reconcile manager return with online submitted return - hence pdf copy showing proof of this
We need a backup of original to compare with current - again pdf copy will have this. We should always have a backup for the exact same reasons we backup everything else!
History and Audit trail to show that something has changed and where.
Finally a method to reconcile the previous year(s) and understand why the figures have changed.
I can see real value in having a simple way of knowing if a report sent to another entity has changed.
Knowing why, is far too broader question in the general case, to expect Manager deliver an answer in a form everyone can easily understand. Lock dates can be removed, the total in a taxable income depends on almost every entry in Manager prior to end of the financial year including prior years, accounts can be combined or divided up, any of which can be done incorrectly. Tax codes, start dates, reporting method changed. And that is before any improvements to the code and report format is considered.
I’m happy to use Manger’s current features and my backup to readily answer the why, so would be more than happy with Manager only added a simple method of checking if changes resulting in a nett change in reported figures has occurred.
That is exactly what I’m talking about, even if I have not articulated it well.
If users do make those changes, that would be on them and it would be expected that any printed/static report would change if you are talking strict hard copies, but I’m not. I have only for the first time in 4 years changed the format of my COA (and seriously regretting it—not because of manager, but because I now can’t compare new vs old, and because manager doesn’t either)
I think perhaps our idea of static might be different, and my implementation would work perfectly in this scenario because the static report would be pulled from the database and directly compared against the values between today and in the past. The user in your scenario would already know “well, I split this account here, yes, that’s why the BS reports differently for that account”. It is pretty simple, really.
If you stored values for each COA for the P&L and BS on given user specified dates, then users could identify when their data is broken. YOU could identify that in the upgrade process where people are going to have problems and alert them to that fact. It is a data integrity issue and I’m not the only one who thinks this. Yes, COAs changes from time-to-time, but certainly not everytime you update the program. However, mostly they wouldn’t and these snapshots or static reports could identify all the issues I have raised.
In reality, this is something you could do internally and not even make it a fully fledged feature. Within the upgrade process I think you should take a snapshot of the COA and compare those values before and after the upgrade, that would identify to you and us, that there’s a problem, instead of burying your head in the sand and leaving it to us to find out later.
To me the solution is obvious, hire a qualified accountant to supervise your job or at least hire an accounting consultant to set a finance and control manual to help you avoid mistakes and ensure your data is always reconcilable even if there were mistakes. Even if you lose control for a while, you can still hire the accountant just once for reconciliation.
I don’t know why people always look for means not hire an accountant when in doing so the result is almost always a software that use convoluted work flows to compensate for its users lacking accounting knowledge. The end result of that is your system being:
Dumb
Increased internal complexity to make the appearance “user friendly”
Unreconcilable
As an example I give you non other than – you guessed it – the infamous QuickBooks. I dare you mess up things like my clients do and then be able to reconcile it in reasonable time using QuickBooks.
I have clients that lost it in Manager, Odoo, IFS, Dynamics and even Tally but we were able to reconcile things within a couple of days at most but I can’t say the same about QuickBooks.
Just hire an accountant and have him earn his living and enjoy your life as well as manager being simple and straight firward.
I do own the mistakes I make, I don’t blame lubos or manager for that.
What I do have issue with is the changing of queries and calculations behind the scenes.
The fact is, if he changes a query or a calculation, then it wasn’t bug free and there’s a data or reporting integrity issue. I’m not the only one to have experienced this.
If the software was free of bugs/errors, then why change those underlying fundamentals?
That is my whole and really only significant gripe: if a query changes, it needs to be validated against the users data. You can’t just say “assume it is correct,” because even as recently as just last month, reported values in the 20836 era are different to today’s values. Admittedly the values today are more correct, but they were also correct in 20517, and if he validated his changes with my data… well, we wouldn’t be having this discussion
