Continuing with your train of thought - a ledger can be rendered immutable manually after a PCV or automatedly (with a checkmark) at end of specified time period - daily, weekly, monthly, etc…This would allow large companies the option of real time immutability of ledgers and small companies options to do so manually until a PCV is made…
Document level immutability (cannot delete or cancel - but can replace with another of same posting date) can be standard (until PCV). This discussion is a question of impact of posting date on ledger.
@rmehta - philosophically this seems a serious enough issue for a lot of companies that would leave us struggling with decision to permanently stay on V12 or find other software that allows us to run business the way it should be. I am sure that everyone loves erpnext but for sure we cannot live with a ledger that is not in agreement with the reality on closing date. I am afraid that we could lose community members (think customers) due to the way this is being implemented. Is it difficult to implement an optional immutable ledger (for example with daily automated PCV )? Philosophically shouldnt accounting software adapt to business and not vice versa??.. why risk it then???
Probably, a better way is to simply stop recomputing the future stock values and allow the backdated FIFO costing to be naturally picked up by the next transaction.
Thanks everyone for sharing your views. Unfortunately there is still some confusion on how this is implemented.
Please note that you can still post accounting entries in previous periods, so there is nothing to stop you or the auditors from from making adjustments. So from an accounting / legal perspective there is no change. Except that ledgers will not be overwritten.
Only the stock ledger cannot be posted beyond the last transaction.
Cancellations for stock entries will work but the impact of cancellation happens in the forward direction only.
Can someone very briefly share a use case where you would want to rewrite the stock balances and a simple accounting adjustment will not work?
line 320-322:
entry['remarks'] = "On cancellation of " + entry['voucher_no']
entry['is_cancelled'] = 1
entry['posting_date'] = today() <----
def check_freezing_date(posting_date, adv_adj=False):
"""
Nobody can do GL Entries where posting date is before freezing date
except authorized person
"""
I have been using V13 in a real life environment for the last 6 Weeks. This is a deliberate decision and we assumed the risks inherent in using a beta version.
Companies need to be able to post backdated stock transactions, especially the SME segment which has been your avowed target segment.
The reality is that there are too many scenarios where this will be necessary either as a deliberate action by the business or as a result of errors.
Do not go ahead with this implementation of immutable ledgers. Your market will kick against it strongly.
I would like to add to this discussion what I learned from another thread on what immutability means - as there could be confusion - as was the case for me… Very nice and timely summation / clarification posted by @peterg can be found at
The changes will be much less dramatic than people have sometimes thought. As I understand it (based on discussions here and the partial implementation in v13 beta):
The cancellation workflow is unchanged. You can still cancel if you wish, and you can still reverse an invoice with a credit note if you wish, your choice. The only thing you can’t do on an immutable ledger is delete cancelled documents.
The transaction date/posting date distinction will be made more consistent on the backend. Transaction date will represent when the business event happened, and posting date will represent when it was input to the system.
Backdated transaction dates will be allowed, but backdated posting dates will not. The only real implication here, as I understand it, is how this impacts stock valuation. This is, I believe, the sticking point.
Closing vouchers will serve to lock transaction date periods, same as now.
In other words, though a lot changes on the backend with (positive) implications for audit, the only real user-facing impact is in how stock valuation gets calculated on backdated transactions.
So it seems a lot of the fears around inability to back date transactions were misplaced - frankly including mine.
Key for us is the definition of backdating. If backdating means no posting dates before today, that is a deal breaker. If backdating means no posting dates, before the last posting date for this item, that we would support.
Also,
I fail to see the difference between a cancellation and a deletion of something that occurred in the past with transactions dated after it. Both will change balances for subsequent dates that are in the past. If deletion is not allowed, cancellation should not be either
It seems the latter: you can backdate posting times as far as the last posting time for the item.
Cancelled documents still represent ledger entries…two sets, in fact: one creating the document and one cancelling it. It is informationally equivalent to a invoice → credit note workflow. If the cancelled document were deleted, the ledger entries would be orphaned.
One outcome is that we will fix is cancellation so it is on the original date. I think @Deepesh_Garg will make a fix next week.
Only thing we are stopping from backdating is stock transactions because of its compounding effect on subsequent transactions. Overwriting timelines is bad from a software design perspective too.
Request people to make shorter posts so the discussion is more participative!
Clarification - again - I thought we could backdate transaction dates but posting date will be entry date. So NO backdated (transaction date) delivery notes? Also document immutability requires that invoice cannot be cancelled - it must be credited. Are we permitting cancellation?
What is on the table for discussion? Are we open to revamping ERPNext (example posting to journal entry as suggested) or this discussion is limited to immutability within the current ERPNext setup? Just seeking clarification on the scope…
As part of an organization using ERPNext (hosted on erpnext.com), we don’t really have an option when it comes to this (immutable stock ledgers) as it would be done as part of an upgrade. But, I would like to add my opinion:
Not having to create backdated (backdated beyond an old transaction of same item/RM) is definitely an ideal situation. We would expect all operations to reflect physical movement (and that is definitely immutable sequence). So, theorectically, the immutableness of stock ledger sounds logical.
But, practically there are some situations where backdated entries need to be done. For example, during the COVID time, as there was severe staff shortage, we had to complete some deliveries without proper entries (Purchase Receipt => Manufacturing => Delivery cycle). Now, in case Delivery date is locked (export/tax regulations), our stock In (Purchase Receipt) and Out (Delivery) too has to be date locked (read, backdated).
If we sincerely analyze all our operational situations, in 90% of the cases the onus lies on timely entries. If I don’t make excuses of being small organization with limited staff, I think I can safely say that immutable stock ledgers would be not a big issue. But, that is again ideal world.
But, a toggle would definitely put it there with ‘best-of-both-worlds-category’. Or, maybe restricting the backdate to be within a financial quarter (based on financial year definition). That might limit a lot of impact.
I realize that this has been in discussion for multiple years. And team would have invested sweat to get this to a stage to be broadcasted as being part of v13. And, a software always has some limitations - we have to learn to live with that.
So, basically a torn-in-both-direction opinion from me.
I have at least 5 years of navision and 4 years of adempiere / idempiere. Am implementing erpnext for current company operations. This immutable will be disaster based on my experience. Anyway software is yours. If it risks my career or job I will have to find other solution.
ERPNext has very powerful code. I like the simplicity and power of ERPNext as it stands on solid Frappe. ERPNext has a core team who controls the commits, manages the timelines, and documents the software with Online Manuals and Youtube Videos, and Webinars. It also has a respectful and helpful forum. ERPNext community is on a journey.
