I am still trying to understand the implications of this change. If this means I am no longer allowed to amend/add a back-dated account/stock transaction, it means ERPNext will almost become unusable in our organization.
So let us examine the requirements that asked for this new feature.
Fine. But is there any quantification about this computational cost. As per I understand, this is only used very rarely. People using this don’t really care how much time it takes to do the forward entries. Or are you saying it affects all the transactions irrespective of whether it is current dated or back dated?
Right. However that is exactly the purpose of back-dated entries. We have done a mistake earlier, which is getting corrected by this back-dated entry. Otherwise why will anyone do a back-dated entry?
But at the end every body lives happily ever after…
That could be a compelling reason to make this change if it is true. However I am not sure this change will help or the only way to resolve that. Once a document is submitted, we don’t allow modifying the same document. We have to amend it and the action will be audited. As long as your employees cannot delete the records behind your back, they can’t cheat you without your knowledge. With this change, they can still reverse the actions with a current dated transaction, so effectively they can still cheat someone who doesn’t monitor their transactions, right?
So, what are the compelling reasons to do this change or not do it?
For: We are humans and we do mistakes, so we need a mechanism to fix it. It could be a missing stock entry or voucher entry. We want that to update the valuation of subsequent transactions. Will the new approach provide a way of achieving this? I guess no.
Against: This could lead to accounting frauds, so not recommended by some companies. can this be done without disabling back-dated entries. Perhaps to certain extent, by providing a report of all back-dated entries. We could also make this difficult by asking for a new authorization level, so that normal employees cannot do the same. Another approach would be to disable it by default and provide a global default to turn it on.