Judging by the changes in manager, it looks like @lubos might be considering adding timestamps or exposing already existing timestamps to all transactions, but that’s just a guess.
Anyway, create dates would really be helpful for reconciling changes after a point in time. Consider this scenario:
I have closed the tax books on 30th June somewhere in mid July (say 15th of July). Later in August, I unlocked the June period to perform annual closing adjustments. These adjustment affected my tax report. The authorities payed me a surprise visit for tax audit this month and I had to work overtime to reconcile the tax report file vs the current tax report (for which History have been of great help), however I couldn’t help but to think how easy it would’ve been had we had created dates. I just select transactions with dates on or before 30th June created after 15th of July (vat filing date).
Also, modified dates would help in case any figures were later changed.
So guys, could we please have created and modified dates up for discussion?
The date and time a report is created or modified is already included in the History file, along with the creation or modification parameters. If a report covers a transaction that is corrected, the currently defined report is the correct version. Views of older versions that once appeared on screen are no longer valid. Likewise, printed copies of older versions are no longer valid. What is the purpose of annotating a printed report with a date when the entire report could have easily been faked? In fact, what is the purpose of even keeping an old printed report?
Personally, I think users are often trapped by attempts to recreate old paper-based environments they or their auditors or tax authorities are familiar with. Manager’s environment is digital, and it has always seemed wiser to me to rely on what is on screen than what was printed at some time in the past. I realize there is philosophical resistance to this viewpoint by some users. But why shift to an integrated, computer-based system if you are not going to take advantage of its benefits? Why use it as a glorified, electronic typewriter? That is my input.
My preference is via two separate features. Firstly a simple way of knowing if the figures have changed since a document was sent out
Secondly history search options
Both on the history tab enabling finding changes made after a certain date (eg your lock date or the date a report was sent to a tax authority) to transactions dated before a certain date (eg the end of a financial period). Hopefully this is what Lubos was alluding to here
Yes, but there’s a good reason for that. The tax authorities as well as the external auditors will require that you reconcile your tax accounts, either on the spot (they gave us 7 days only) or submit a voluntary disclosure to amend the previous return that has changed. So I cannot escape this.
Currently, I export everything in the links of my tax report and take a backup. However, the reconciliation is by cross lookup of two large datasets, which is much less efficient than filtering the most recent dataset.
Or as @Patch suggested. I am not a huge fan of system reconciliations because I think they are grossly inefficient, but I am open to any idea that improves reconcilability by the user.
Reconciliation was Lubos summary, what I was actually wanting was
Which involved Manager recording actual not calculated values in history when a document was sent out. Subsequent display of that entry in history then highlights any values where the current calculated values differ from the static values saved when the document was sent out. The user then uses the other tools described above and their knowledge of what and why there businesses file has changed to determine the appropriate action.
Then intention is for Manager to provide a virtual lock date function. The user enters
A virtual lock date
The date the virtual lock date could have been set
Manager then shows all the history changes which would have been block it that lock date had been set.