This PR changes the way Accounting Ledger(General Ledger) and Stock Ledger works in ERPNext.
As mentioned by @rmehta in his earlier post posting backdated entries has the following disadvantages:
Posting back dated stock entries is computationally expensive since all the future entries needs to be reposted which takes a lot of time
If the stock valuation is based on FIFO(First In First Out), on posting back dated stock transactions the entire fifo queue gets regenerated which upsets the valuation in the subsequent transactions
Currently on cancellation of any transaction we delete the GLE/SLE which shouldn’t be done as per International Financial Reporting Standards
Change:
On cancellation of any transaction instead of deleting the General Ledger Entry(GLE) or Stock Ledger Entry(SLE) a new GLE or SLE will be posted on the date of cancellation that will reverse the impact of that transaction.
Also you won’t be able to delete the cancelled transaction anymore since it will be linked to the corresponding GLE or SLE
Back dated entries that affect the Stock Ledger will be allowed only after the last stock transaction’s posting time which means there will be no need of any reposting of future transactions.
We have looked at several alternatives and this is a huge pain area based on our experience of supporting hundreds of ERPNext instances. Stopping back dated stock transactions will result in much fewer downstream “investigations” who why certain reports are inconsistent over time.
This change will be pushed in Version 13. Maybe its time
There are many instances when data entry was missed for earlier month or period and discovered during year-end or period-end audit. Many small companies cannot afford or do not have procedures to audit inventory or other transactions prior to closure of the accounting period and so transactions occur in parallel for new period while back dated journal entries are made to reconcile stock, payments, bank balance etc.
Will this still be permitted? For example if we setup quarterly accounting periods - can we make entries for prior quarter while new transactions occur in the current quarter? Say until a PCV is made for that period? Since we already have mechanism to update subsequent reports - why disable / delete that completely? Can it be offered as a choice? Perhaps requiring very high level user permission and warning of impact before submitting a back dated entry?
Seems that completely taking away this option / flexibility may actually cause headaches and force small companies to conform to only one way of operation??.. It will raise the cost of doing business if we are to use ERPNext as we have to audit / promptly close out the prior period before any transactions are posted for new period?
Yepp, fully agree…just finished the “end of the year check” Based on the bank transaction file I identified several purchases that I forgot to enter…So just updated and corrected all info for the full 2019…
If this were no longer possible indeed it would be a problem for small companies not having a professional accounting team keeping everything upto date
Even the most popular accounting systems in India like tally, busy are much more flexible than this, yet have robust report generation.
Agree with @becht_robert in that small firms (major share of erpnext users) might not be working in an ecosystem where everything is punched correctly in one go and on time.
The lack of this flexibility will be a deal-breaker for many. May be a survey of end users could bring more insights before merging this?
there was already a long discussion on this and I believe it was made clear that back-dated entries are allowed but will only be posted in chronological order to avoid re-calculations and re-posting while reports will be made available to show your ledgers in the actual order they’re supposed to be
The more I think about it the more worried I am about the change this approach is going it make. I am sure others also have a lot of questions. The proposed change can make auditing very difficult for companies. I suggest that there should be a demo setup where the people can try changes. This will build up use cases which can be reviewed and if anyone sees anything inconsistent then they can report. In my opinion this will make people more comfortable with the change and help test the system.
Secondly I have few use cases for which I wanted to understand the impact the changes will have:
Suppose items were supplied with Delivery Note and Invoice to customer. Before they make payment which may days after the delivery, customers accounts team comes back with small changes that they want in the invoice and delivery note. The user amends the invoice and delivery note.
After this change how will be the transactions ledger be like?
How will it impact the reconciliation with GST and in future with ewaybill?
What will be transaction date. What date does the system show the item left the store? If we cancel it delivery note will the item show up in the store on the date we cancelled it? After amendment what day will it be shown to leave the store?
If there is a fixed asset item that was bought in July and was not entered in the system by mistake. During audit the say in December missing entry was found and entered, how will impact the depreciation?
I’d love to see that everything in ERPNext are captured as series of immutable events. i.e. not only accounting, I mean every module, document, et. all.
Before launching an immutable functionality in EPRNext, I do believe a deeper discussion must be had. Many users do appreciate the possibility of modifying the entries, given that mistakes do occur. I believe that the permissions and roles modules, plus the possibility of keeping track of deleted items and activity per user, is enough not to warrant the forceful imposition of an immutable functionality per se.
If some sort of state tracking is desired this could be tracked by a second server, like in a backup fashion. A diff tool showing the changes clearly should be enabled to allow auditors and third parties understand why such changes were needed.
I think it’s a little bit beyond just the state-tracking… it’s also computationally expensive especially for those who have loads of stock ledger entries like in retail and manufacturing. We’ve experienced it many times when changing a back-dated stock entry causes the system to freeze and sometimes even never completes the entire cycle of reposting!
I’m not sure there are many systems, even among the top-tier like SAP, that repost all ledgers from the point of the back-dated transaction. If there’s a way to get sround this burden, that’d be fantastic
In any case, I also agree that this is a very significant change and it’s impact across all categories of users needs to be carefully and thoroughly assessed
From a user end point, can’t this be done just in the background? As an accounts user one can simply edit any transaction, the reports generated just show the latest transaction values.
SME’s do have corrections to do from time to time. Apart from the hassles with authorities (who as you know look for minutest of issues), even customers are used to the present system of having one invoice number and that itself being modified of corrected. Infact even a “-1” suffix adds to a lot of confusion and debate.
A win-win for end users and system operations would be to have all the processing be immutable in the background, with permission based visibility of the background ledger. This way operators and end users have a “simple” ledger they are used to while background processing is optimised.
Cancelling an old transaction will affect balances of subsequent rows, while in immutable ledger if you reverse a transaction, the balance only changes at the very last row.
This is a significant change, cannot be hidden from the anyone’s view.
@Tropicalrambler I agree there needs to be more discussion. I feel partial immutable ledger is a better balance between the two schemes:
For a transaction which is only 2 days old, cancellation may not be computationally expensive
Therefore I propose a that we have configurable cut-off date for beyond which cancellation is prohibited.
So very old records cannot be cancelled
I think this can at least be a good transition towards a complete immutable ledger.
If ERPNext is still aiming at SMEs users, I think a too rigid system would not be appropriate for them.
Many, if not most, SMEs don’t have all the personnel to do all functions like accounting. So mistakes happened. And many corrects this mistakes, and even posting transactions, by end of period (week, month, fiscal period, etc). Handling it everyday (because the system is not allowing backdated transactions) would be a hassle.
), what steps I need to follow now?