Actually, I do development work. This is why I am putting out an honest opinion about the pitfalls of the implementation of Immutable Ledger. I have also described an alternative. I am confident that the developers of ERPNext understand what I am saying.
Now implementing erpnext for small business will be much harder I believe…
We cannot force all users to use immutable ledger…enterprise and SMB is totally different in real business world.
SMB doesn’t has audited report, lack of resources, mistake always happen. They use erp to make things right so adjustments will always come later…backdated is the solution…immutable is just a ‘confusion’ that makes the system less in flexibility/straight-forward.
The best win-win solution for all is to provide system setting option so user itself can decide whether they’re capable enough to use this feature.
It is a joy to implement ERPNext, as long as you give the server the processing power an ERP server deserves (and extend the http_timeout to at least 6000 for production setups). The flexibility is just amazing.
You can still install V11 or V12. Both work perfectly for SMB. These companies don’t need breaking change features. I guess V11 will serve them for many more years.
In my opinion, these are extremely powerful advantanges that places all other ERP systems far below ERPNext’s power to recompute costs accurately.
This is INCORRECT. Nowhere in IFRS mentions that GLE/SLE should not be deleted. GLE/SLE are internal processes. The only requirement is that any GLE/SLE should be traced to a Journal Entry written in the Book of Original Entry (General Journal).
Allowing the cancellation of a Posted (Submitted) transaction is the one that breaks the standards of IFRS. So, this implementation breaks the standards of IFRS.
Again, this breaks the IFRS standards because you now have two system Ledger Entries without any valid Journal Entry to stand on. So, now, you have One CANCELLED POSTED Journal Entry which broke the IFRS, and Two GLE/SLE without valid Journal Entry.
So, you have Three violations of IFRS.
Yes. You cannot also AMEND the cancelled Journal Entry.
The last stock transaction’s posting time in case of Cancelled Stock Entry is Today. So, in case you are building up to system, one mistake will render all work to waste.
From @rmehta post, https://discuss.frappe.io/t/discussion-immutable-ledger/31153 I think this was where the standpoint was wrong:
In most accounting systems, the ledger is immutable. If a cancellation or adjustment has to be made, it has to be as a new entry that reverses or changes the impact of a previous entry.
Here are some problems related to this:
This immutable is not about system but about accounting principles.
The accounting generally rules that documents (SO/PO/etc) can be cancelled, but transactions can’t (JE/SE, even the ones that are resulting from creating a document).
The analogy from paper-based system: you can change the Sales Order document times and times, but you can’t change the value of the sales (which eventually will be recorded (JE) in the book (GL)). Once it is recorded, the last SO used as reference to the JE entry must be “sealed”. When it should be changed, the JE (the value of the sales) must be reversed and reentered, and both document (SOs) must be kept.
So I tend to agree with @Joseph_Marie_Alba1 on this immutable things
Side note: even blockchain principle is using this terms of ledger and transactions for immutability.
Indeed, and this is exactly what’s happening in the new system here. Documents can be changed, but actual accruals to Ledgers can only be altered with time-forward reversal entries.
There’s a lot of variation around the world in how specific documents get treated in this regard. In some standards, erroneous Sales Invoices should be marked cancelled, and in others they should be reversed with a Credit Note. ERPNext lets you take either approach, depending on your needs. Under the new system, both will produce equivalent entries (sale + reversal) in the general ledger.
Correct. This is the power of ERPNext version-12.
No, it happens on the document level, and then a reversal entry tied to the canceled document (paired with the original entry) is created in the ledger. Nothing in the ledger is removed. That’s the whole point of this change.
You say that accounting standard doesn’t allow for Invoice cancellation. That’s fine. Mine requires it. ERPNext – in versions 12 and 13 both – allows for either work flow. Nothing has changed in that regard. If you don’t want cancellation to be allowed in your system, you can enforce that with 15 seconds of work in the Role Permission Manager.
@Joseph_Marie_Alba1 I think you don’t understand what runs behind the scenes of ERPNext, when a document is cancelled, until version 12, every cancellation of an transaction will physically delete all the entries related to this transaction on the “LEDGER”, and by consequence on the DB, on version 13, on every cancellation of an transaction the Leger will be reversed keeping the ledger incremental and immutable (AKA preserving the history including mistakes, misconduct and misconceptions for auditory purpose, but don’t affecting the balances).
Also what do you call as “Imutable Journals” are the “Genereal Ledger Entries” in ERPNEXT.
And if in the past every time someone cancel a document, the ledger was flushed, ERPNEXT was going against the IFRS, but now on version-13, the ledger will be incremented to balance as zero, following the good standards of IFRS, and following the good accounts principle’s.
I understand very clearly because I look at the code. It is amazing and enjoyable to see python doing very complicated things in a few lines of code.
Yes, this feature of being able to physically delete the associated cancel the transaction and physically delete ledger entries is desireable in many business use cases, especially for those who are doing PARALLEL runs with an exiting system, to prove that ERPNext can produce accurate results.
The problem with this approach is you PERMIT the cancellation of the ENTRY that produced the error. In Accounting Principles, it is the Original Entries that need to be preserved.
But, you reverse the effect of the error by creating another set of ledgers (which has no entry to stand on).
In addition, Cancellation of Journal Entry is useless, since you CANNOT amend it in version-13 because of the Backdate error. So, for version-13, I must warn that you have to disallow Cancel permissions on entry documents. Otherwise you are in a lot of hurt.
In my business use cases, I see a lot of cancels during the time the Users are just learning the system. It is ok, since it is on parallel run, either against an existing software or manual.
Being able to make cancels and easily Amend the error is a great confidence booster to Users.
Then, when the time comes that Users are confident enough, you can force the system to become Immutable, simply by disallowing Cancel in user permissions, and instead, tell the users to create reversing transactions. I looked up many ERP systems, and this is how they do things. Immutable systems are implemented on the Transaction Level NOT in the LEDGER level.
This is why I realized (mainly after some discussion with PeterG) that Immutable ERPNext can be implemented using a simple Checkbox. If you disallow cancels, and generate reversal entries on the transaction level instead, you have an Immutable System and everything is transparent on the traction level.
In the case of version-13-beta immutable ledger implementation, who can guess that a cancelled transaction dated January 1, 2020, has generated a side effect of Ledger entries dated August 20, 2020? And these side effect Ledger entries will generate Backdated errors preventing unsubmitted Stock Entry transactions from being posted.
I really appreciate ERPNext code. This is why I try to explain that Immutable Ledger is WRONG. In accounting principles, to implement Immutable System, It should be Immutable Entry. These entries generate Ledgers. (No ghost ledger entries allowed)
It says right in the ledger entry itself where it came from.
You keep using this word “CORRECT” – in all caps, no less. I don’t know what to tell you, man. I don’t doubt that what you’re describing is correct where you live. The thing is, it’s not correct where I live. Things are different in different places.
The good news, in case anybody watching on is worried? You can already do exactly what you want to do. Both approaches work, in both v12 and v13. The Immutable Ledger doesn’t change that.
While I agree that accounting principles are different in various parts of the world, the highlighted above is likely to result in VERY significant user experience issues. I think the team needs to carefully consider this
Just to be clear, I’m actually all for Immutable ‘Ledgers’ as allowing them to be flushed and/or reposted doesn’t address the main issues that necessitated the move in the first place. We however need to look carefully into HOW this is implemented so it doesn’t cause untold hardships and user apathy
Calculation (and posting) of difference entries also needs to be automated like I’ve mentioned earlier. It’s absolutely not feasible to expect the user to calculate and post difference entries (for forward-posted stock transactions) manually!
Exactly…The forward-posting requirement for stock valuation, not reversal workflows, is the real issue here.
To be fair to the developers, this feature is only partially implemented so far as of beta 4. An explanation of how stock posting will eventually work was made by @nabinhait here, but so far the posting/transaction date distinction has still yet to be implemented in most user-facing contexts.
You’re right… and I think that’s all the more reason why people with concerns need to make them known now
Looking at Nabin’s initial explanation though, I believe having Posting and Transaction dates would help reduce the potential for confusion significantly. Let’s watch as this evolves…
Thanks for this reference.
First of all, thanks everyone for sharing your experience with immutable ledger implementation in v13.
Like you, we are also facing some difficulties in implementing immutable ledgers. We know that in the current implementation, there are a few shortcomings which must be handled to make it successful. And we are consistently trying to improve it based on users feedback.
And at the same time, we also giving serious thought to make it optional. But to bring back mutable ledgers, we have to fix its original problems like reposting issue in case of stock transfer and timeout issue on reposting in case of huge data. For timeout issue, we are trying to process reposting via background job.
I will keep you updated as soon as we found the correct design/solution to handle previous shortcomings and about the progress on immutable implementation.
Thank you so much. We know that Frappe team is hard at work.
Financial Accounting IFRS edition by Weygandt, et al.
There are two assumed cost flow methods:
- First-in, first-out (FIFO)
There is no accounting requirement that the cost flow assumption be consistent with the physical movement of the goods. Company management selects the appropriate cost flow method…
very few companies use perpetual FIFO or average-cost to cost their inventory and related
cost of goods sold. Instead, companies that use perpetual systems often use an assumed cost (called a standard cost) to record cost of goods sold at the time of sale. Then, at the end of the period when they count their inventory, they recalculate cost of goods sold using periodic FIFO or average-cost and adjust cost of goods sold to this recalculated number
This is what I mean by having period closing inventory process. The python process can be activated as an OLAP long running process at the period end to have precise inventory costing, while the Transaction entries which are OLTP in nature can quickly be saved or posted without consuming a lot of computing power resource.
Nabin I have given the reposting issue a lot of thought and I would love to have a discussion about it. I’ll start a thread and link it here.
Most of my ERP implementations are importers and their #1 requirement is to be able to update the cost of a past Purchase once Landed Costs are finalized in the future like Duties, Freight and so on
I have been against mandatory immutable stock ledger because some processes and some industries simply cannot function normally without being mutable, like: Landed Cost Voucher