[Breaking Change v13] Introducing Immutable Ledgers in ERPNext

ERPNext
61

The one’s not a side effect of the other, though. They’re actually very separate issues. Many of the concerns you raise are extremely valid, but I think you’re lumping together three very different things under the name “Immutable Ledger”. (The lead post in this thread is too, FWIW.)

  1. The cancellation workflow
  2. Forward-only stock entry posting
  3. The actual immutability of the stock and accounting ledgers

For (1), I think we’re going to just have to agree to disagree. If you don’t like the aesthetics of document cancellation, that’s your prerogative of course, but I believe you are incorrect in attributing problems to it. The cancellation workflow is informationally and semantically equivalent to the reversal document workflow you have described, and none of the problems you’re describing would be avoided by the reversal entry workflow. All of the (very real) problems you are describing are cause by a different thing: (2) Forward-only stock entry posting. That’s the real issue here.

This is incorrect. Look for the GL Entry or Stock Ledger Entry doctypes. The system prevents you from manually creating new entries here, but they’re readable and otherwise permissionable like anything else.

An immutable ledger is a basic condition of any trustworthy accounting system. Accountants use pens, not pencils. It should have been this way from the start, and it’s not something you want administrators turning on or off with a checkbox.

What still needs serious rethinking, however, is Forward-only stock entry postings. Unlike Immutability, which is central to all accounting standards, stock valuation is complicated. The correct answer here is probably going to involve Stock Accounting Periods, but figuring out how to balance flexibility and system integrity is non-trivial.

2 Likes
62

If you want an Immutable system, it should be the Journal entries that SHOULD BE immutable.

63

There’s nothing “mere” about aesthetics :slight_smile: Human perceptions are fundamental to any information system.

But, I can assure you that I’m not mixing anything up.

The title of this thread is “Introducing Immutable Ledgers in ERPNext”. It’s the ledgers, not the entries, that are immutable. In real-world accounting, vouchers, invoices, and entries get changed all the time for any number of reasons (including cancellation).

If you think that the ledgers are mere “computational aids”, all I can say is that you and the developers understand this project very, very differently.

64

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.

65

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.

1 Like
66

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.

1 Like
67

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.

68

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.

6 Likes
69

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 :slight_smile:

Side note: even blockchain principle is using this terms of ledger and transactions for immutability.

70

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.

71

Correct. This is the power of ERPNext version-12.

72

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.

73

@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.

3 Likes
74

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)

76

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.

77

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!

Cheers

1 Like
78

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.

79

You’re right… and I think that’s all the more reason why people with concerns need to make them known now :blush:

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…

Kind regards,

1 Like
81

Thanks for this reference.

1 Like
82

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.

13 Likes