@Brucanna as always Lubos how he wants to implement suggestions. I am merely making suggestions based on my own user experience of the product.
Perhaps it would help if one asked what is the actual purpose of a lock date in order to determine how best to implement the requested feature and whether it should optional or mandatory.
To me, the main benefit of the lock date is to prevent cloned transactions from being created in a previous quarter or financial year. Perhaps what I should be requesting is that cloned transactions update to today’s date as it has never made any sense to me that the cloned transaction retains the date of the original transaction as in every single clone transaction I have always wanted today’s date.
So my main requirement for the lock date would disappear if this failing of cloned transaction was addressed.
The second reason for having the lock date is to make users aware that they are changing a previous financial year. This is important in order to ensure that Vat and Corporation tax calculations etc are not affected accordingly. So it just serves as a warning to users wanting to update the previous financial year.
As many users (especially novices) do not activate the lock button, it is not protecting inexperienced users from making mistakes. So I still submit that the default state should be for a lock date to be set. I like the idea of having a temporary unlock functionality to make changes before locking again. Anti virus firewall products have this feature when you can disable the anti virus for your specified length of time before protection is re-enabled again.
I don’t know what a business financial model in Manager would be, so can’t comment on that as it’s out of my depth of accounting knowledge. But I am sure Manager could accommodate different case uses and intelligently determine whether a lock date is relevant or not.
It actually used to be that way. But users complained that when they had many similar transactions to enter (such as invoices to a membership group) that could not be completed in one day, they wanted to be able to clone the first without having to change the date for every one. There was discussion (you might even have been part of it) about how it made sense to populate today’s date when copying one transaction type to another, since that was part of a progressive workflow. But clones should be exact clones, and that was standardized across the entire program. (The only exception is automatic reference number sequencing, since an exact clone would violate legal requirements in many jurisdictions.)
If may be a failure from your perspective, but it was a desired feature for many others.
That is an argument without merit for those who are not under VAT schemes or are not paying corporation taxes from within the program (such every user who is a sole trader). For you, this might matter, but it illustrates why the program cannot be designed for the workflow of only certain user types.
One of Manager’s underlying design philosophies has been not to impose practices on users. A default lock state would be a big imposition. An unobtrusive lock icon would not impinge on anyone’s practices.
The value of a lock date is it negates the disadvantage of a perpetual accounting system. By far the majority of users will check a period, then when they are happy it is correct, like to be able to assume it will remain correct.
The most common reason for data loss is inadvertent user error. There is a large number of ways users can make mistakes. That is what lock date guards against.
There is always a date before which changes to a Manager business is not expected. For the first period it is the start of the first period. As a perpetual accounting system, for subsequent periods it is the start of the next period.
If you really think it is common for users to not care if old data is accidentally modified, then any warning could depend on a lock date being set, so only display when the temporary disabled check box is set. Not as good imo but a possibility.
I am not sure who, if anyone specific, this comment is directed towards. But if me, I never said I thought users don’t care if old data is accidentally modified. I am sure they do. Historically, modifications to the underlying program have been of more concern in that respect than accidental edits to past accounting period transactions by users. Neither a lock date nor a warning would do anything to protect against that.
I honestly can’t remember. I wonder if Manager could have the equivalent of a form default or something in settings that defines what happens when you clone something. For me, I have never needed to clone quotes and invoices to have the original date! It is because of this exact issue that the Lock Date Icon is necessary and even then does not prevent me from making a mistake in the current financial year.
That would take you further away from a clone being a clone. I think people need to accept that no accounting program can prevent all user input errors. The practice of accounting requires attention to details. Manager does a good job of minimizing possibilities, but cannot eliminate all. Just be happy that in 98% of transactions you don’t have to figure out where the debits and credits go.
But in a perpetual accounting system there is no subsequent periods or a start of next period.
All you have is the selected period of time for which the user wishes to capture/display/report the data. That period of time can be completely variable - day, week, month quarter, etc.
So once again I ask, how does Manager, being a perpetual accounting system, constitute what an “old period” or a “subsequent period” is for any particular user’s business so as to have Manager activate your suggested warning “Warning Lock date not active, transactions in old periods not protected” ?
You can’t say financial year, as Manager doesn’t know a user’s financial year start date which could be any of - Jan1, Apr 1 or Jul 1.
Nothing is wrong, what @FCP is suggesting is an icon of a lock to show status of the lock date, just in case you removed the lock temporarily and forgot to reapply it.
Dear @lubos,
Concerning the lock date, I have faced same issue of forgetting to lock the date after unlocking. Many a times I unlocked a date on request by a staff and later forgot to lock again giving ample opportunity to other staff with limited access to do the changes.
I am sure other users may have experienced many time to have forgotten to lock the date after unlocking.
So, to protect the unintended unlocked dates, I will strongly support ideas summarized as below from different users.
A temporary unlock. One can unlock the software for x minutes
An alert always visible (near History and Backup?) showing “Lock Date Unset” or “Lock Date 23/06/2021”
Hope, we can get a solution from @lubos soon enough.
Or, like in many OSs, to edit a locked data one should always see a warning, accept it and insert his credential to check if he is an administrator. Like when you try to install a software in wi.dows 10.
@lubos I was just wondering whether there is any plan to implement my suggestion a few months back to add a lock icon to the top menu bar, or something like it, to ensure it is easy for users to see whether the lock date is on or not.
I also liked a suggestion someone else had made, which is to only unlock for that particular user / administrator unlocking the date. I don’t know whether that is something easy to implement or not, but I think the lock icon would be a great start. Thanks
@FCP, there are 196 suggestions in the ideas category. Many have been there for years. The developer generally does not comment on plans for new features.
You are not the only one. All those who use lock date for whatever control are desperately waiting & wanting the implementation. @lubos , hope it comes soon enough.