Why does SAP doing it one way mean that that’s the “correct” approach? If that’s how you feel, perhaps you should be using SAP?
1 Like
Sorry. Research.
Immutable Ledgers is a breaking change.
The power of open source lies in contributing ideas.
Yep, and new ideas means not just copying SAP. You’ve brought up many interesting points in this thread, but in my opinion the fact that SAP does it one way isn’t an argument for doing it that way.
And, of course, to reiterate: if you want to do reversals with separate Entry documents, you still can.
Probably (and it is just an idea!!..) create an easy way to reverse transactions maybe will help most of us…
Is that another way of saying that the ERPNext administrator is going to spend the rest of his life correcting screwed Stock Entry dates?
1 Like
Avoid Cancelling any Stock Entry. I learned this when I entered a Stock Reconciliation for Opening inventory stock balances. I realized I placed the wrong warehouse. So, I cancelled the Entry assuming that it is easy to Amend since it is the one and only entry for Stock.
But, it turns out, the current implementation of Immutable Ledger creates Reversing Entries at Stock Ledger’s on today’s date, as explained by the first post. So, I cannot submit the Amended entry because the Cancelled GL Entries with today’s date causes my stock recon entry dated Jan 1 to be Backdated.
Sadly, you can’t correct screwed Stock Entry dates. So, the admin is screwed.
I read in another post where one Admin was lucky he had version 12 backups for majority of his sites, but for the 2 sites he was not able to backup when upgrading to version 13, he got screwed.
So, it’s a failure that freezes all stock management, or just for that particular item?
Is it possible to disable cancelling Stock Entries?
I think it is for individual Item
In my case, since it is Stock Recon for Opening Inventory, my entry included all items.
Without the first post which explains how reversing GL entries are generated with today’s date, we will never be able to know where the Item entry for today’s date came from since we have no entry with today’s date.
I don’t use stock much, so I’m not familiar with the process there, but journal entries already have that functionality. There’s a “Create reverse entry” command built in.
I agree, though: If something similar doesn’t exist for stock entries, it’d be a handy thing! It should be relatively easy to create with a user script, too.
1 Like
Yep, in the role permission manager, though I’m not sure preventing cancelling really changes the issue here. Even if you do a reversal entry, you’ll still be prevented from any transactions that precede it.
In my opinion, the present implementation of Immutable Ledger is wrong. Ledgers are immutable but the Books of Original Entry are Mutable (meaning, Stock Entries and Journal Entries can be cancelled after cancellation.)
I think, the correct way of implementing Immutable Ledger - if your business case demands it - is to make everything Immutable, especially Journal and Stock Entries.
So, to cancel a Stock Entry for Material Receipt, you create a reverse entry Material Issue to virtually return the Stocks on the day of cancellation. This way, the Original Entries supporting the Stock Ledger Entries for both the Receipt and Cancellation (return) are maintained.
In the verion-13-beta implementation, you can two sets of Stock Ledger entries without any original entry (Stock Entry) to stand on. I think this is Not Acceptable in Accounting Principles requiring that all Ledger entries must be supported by Journal Entries.
We understand that Mutable Ledgers caused problems with some business cases which require that Ledger Entries must be sequential and any disordered sequence is not acceptable.
However, as we see in this implementation, A LOT of business use cases may find ERPNext difficult to use because of immutable ledger.
My discussion with PeterG and my research on SAP Business One made me realize one thing. We can actually have the best of both worlds.
Immutable Ledgers must also require Immutable Journals. Meaning No Cancellations should be allowed. For those other systems implementing Immutable journals and ledgers, when you press cancel, a NEW journal entry is created reversing the original entry. When accepted, the Ledger entries are created based on the New (cancellation) Journal Entry. This way, there are no Cancelled entries (docstatus all remain submitted).
To do this, it is very simple to do. Just disallow Cancel in all roles and user permissions of affected documents. When you disallow Cancel, and create a button that automatically creates reverse Journal entry to implement cancellations (while retaining all original journal entries) - as I illustrated that SAP is doing, you have your Immutable Ledger and Immutable Journal.
However, if your business case does not require immutable ledgers, you can still cancel and have accurate job costing. Mutable Ledger of ERPNext is actually a powerful differentiator which is thrown away in version-13-beta.
I suggest:
- Bring back Mutable Ledger.
- Have an Immutable Ledger checkbox in the Chart of Accounts setting.
- If Immutable Ledger is not checked, the Mutable Ledger is implemented (like version 12)
- If Immutable Ledger is checked, the Cancel button functionality is changed as follows:
- Create new Reversing Entry (for Stock Entry Material Receipt, issue new Stock Entry Material Issue to create a virtual return - vice-versa. A remark on both Entries may be placed: example - for Material Receipt #101 - have a remark “Cancelled by Stock Entry # 300”, and for the new cancelling Stock Entry #300 - have a remark "Cancels Stock Entry 101’)
Journal Entries (Stock Entries are never cancelled).
- Create new Reversing Entry (for Stock Entry Material Receipt, issue new Stock Entry Material Issue to create a virtual return - vice-versa. A remark on both Entries may be placed: example - for Material Receipt #101 - have a remark “Cancelled by Stock Entry # 300”, and for the new cancelling Stock Entry #300 - have a remark "Cancels Stock Entry 101’)
The BEST thing about this setup is, you can SET and UNSET immutable Ledger setting any time.
When you set Immutable Ledger ON, the cancel button creates New STock Entries for reversals (like SAP).
When you set the Immutable Ledger OFF, you get the powerful ERPNext assurance that your Cost of Goods will be RECALCULATED for every entry, in case you need to cancel and still need 100% FIFO or other costing accuracy.
For version-13, with Immutable Ledger implementation which Cancels the Original Entry and creates out of thin air, reversing Stock Ledger Entries on a later date - preventing any possibility of Amending Stock Entries, we throw a powerful advantage of Mutable Ledger, when a Simple functionality change will do.
For version-13, I will also have to revise all User Permissions to disallow Cancel permissions with Immutable Ledger.
May I request, bring back Mutable Ledger, and just implement Immutable Ledger as a Check box setting. This way we can have Immutable Ledger if our business case requires it, but we will have the very powerful Mutable - recalculation - of ERPNext if we need it.
3 Likes
I thought this is the process of cancelling a doc in ERPNext. Because I think (at least in some countries), “cancelling” a journal entry is not allowed, but “reverse” it is allowed.
I don’t really had the detail but this was my suggestion also:
Precisely. This is why I realized the Immutable Ledger implementation of ERPNext for version-13-beta is wrong based on the explanation of the first post. While it tries to never cancel any ledger entry, it cancels the journal (stock) entry.
The way other systems like SAP does this to implement Immutable Ledger is to also require immutable Journal. So, when a user wants to Cancel a Stock Entry, SAP creates a new Journal Entry on the cancellation date reversing the original entry. When the user accepts the cancellation, the general (stock) ledger entry is generated. So, there are no cancelled (docstatus = cancelled) journal entries. You preserved the first journal entry and its connection to the general (stock) ledger entry, and you also have the cancellation journal entry and its corresponding general (stock) ledger entry which reverses the first fournal entry. This is how immutable ledgers and immutable journals are created. All entries have remain submitted (docstatus=submitted)
In the ERPNext Immutable Ledger, your first journal status is cancelled (docstatus=cancel), so the journal entries are mutable, yet your general ledger entries are not cancelled. But a general ledger entry is generated (without any journal entry supporting) to reverse the first set of general entry.
So, if ERPNext implements immutable ledger correctly by also implementing immutable journals, and this can be done by generating reversing journal entry instead of generating general ledger entry, Immutable can just be a check box. If the check box is checked, then when the user cancels, a reversing journal entry is generated on today;s date. But if the immutable checkbox is unchecked, then the usual version-12 process is performed, where the journal entry is cancelled and amended.
May I also add that the Immutable Ledger generates an Imprecise costing (especially FIFO), because it puts back the cancelled Costs on a later date. This cannot be avoided if you want immutable ledger and immutable journal where there are no cancellations and all journal entries and stock ledgers are sequential.
However, if your business case does not require Immutable Journal and Immutable Ledger, like in a Cost accounting perspective, then the version 12 ERPNext mutable ledger implementation is actually a powerful differentiator because all costs are recalculated (admittedly heavy calculation). So, you are always assured that your costs are correctly calculated.
With the Immutable checkbox, we have the best of both worlds, and the control is by the User - System Manager.
With version-13 immutable ledger, we are throwing away this powerful mutable differentiator of ERPNext.
1 Like
I get it, but it may create a pain point for future updates if we have two options (Mutable, Immutable Ledger).
Actually, No.
The current Immutable Ledger may be Incorrect because it allows the cancellation of the Original Stock (Journal) Entry, but results to Two sets of Stock (General) Ledger entries - the first is the Ledger entry that is retained (not cancelled) from the original Journal entry, and the New set of Stock (General) Ledger entry dated Today (the day of the Cancellation) which reverses the original Stock Ledger entries. So you have two sets of Ledger Entries, but No journal entry (since the cancelled journal entry has a docstatus of cancelled)
The other systems like SAP Business One DOES NOT generate ledger entries for cancellation. Instead, they generate a new Reversing Stock (Journal) Entry with Today’s date. (Notice the difference. ERPNext generates Ledger Entries NOT Journal Entry - which is supposed to be the Originating record of a business event). When you accept the Reversing Journal Entry by posting it (submit in ERPNext), the Ledger Entries are generated for the REversing Journal Entry. Note that this is the CORRECT implementation because Journal Entries have corresponding Ledger Entries (Immutable Journals + Immutable Ledgers).
So, it is simply an Implementation process.
This is why we can have an immutable checkbox, because the underlying process for generating Ledger entries remain the same (unlike the new Immutable Ledger described by the first post, which messes up the ledger entry generation.)
This checkbox implementation allowing Shifting from Immutable to Mutable and vice versa can be very powerful in many business cases.
First, during the Setting Up stage of new systems, where dates from documents are all over the place, you can confidently enter any and all document you see because you can cancel and amend any way. Stress level will be way down. (I can only imagine the stress level for Immutable Ledger where a single error in date like error in year or month posting will be difficult or impossible to correct).
Then, when the System has been implemented and smoothly running, you can now turn on the Immutable Check box where all Journal Entries are never cancelled. Cancelling a transaction creates a Reversing Journal Entry - which generates reversing Ledger entries, and implementing the Objective of the Immutable Ledger for Neat and Sequential Ledger Entries.
In other posts, I have already seen some comments that Some businesses, after upgrading to ERPNext version 13, had to revert back to version 12 because the immutable ledger problem of Backdating error was simply unworkable for their business case. I recently experienced the same - which made me realize that the only way to correctly and safely implement ERPNext Immutable Ledger entry is to disallow Cancel in all permission rights. (I also realized that I can implement this Immutable Ledger in version 12 by doing the same.)
So, if ERPNext goes with this present Immutable Ledger implementation, my opinion is it is both wrong and unnecessary.
I agree to have a reversal entry (GL) for every trx we cancel, BUT I disagree with its behavior in v13 as it seems to be a disaster and here is why:
Cancellation date is being today’s date…and it won’t be cancelled in backdated
It’s very stupid to see Debit and Credit values at the same line for such reversal entry. Instead, it must show the same values as interval by means (4 lines should be there)
The original entry:
DrXX
CR XX
The reversal entry:
DrXX
Cr XX
Finally, Users may make mistakes and have had to fix something NOT belong to item rate…it could be the remarks or something that has no effect on the item cost within the same date or period which must be enabled same as v12…
IF this approach is going to be adopted without any chance to change, I would recommend the following:
- Make it optional in accounts setting - so users could see what best approach they want OR;
- Enable the user to select the reversal date AND based on that selected date, user won’t be able to do any backdated trx. PLUS, give the user a hint message before cancelling that document that it won’t be possible to do any backdated trx to that item if once the cancelation document submitted.
We won’t be upgrading to v13 with such enforceable ledger behavior…or we might switch to another platform like odoo…
Regards,
2 Likes
In some other accounting app, this “immutable” is simply done by a checkbox that allow edit the field or not.
If checked to not allow then the field is read only (after save) so to change it is done by reversing it.
No. They don’t have an immutable checkbox. Rather, they make their systems Immutable by generating Reverse Entries for the transaction to be cancelled. (For Inventory received, a reversing Inventory Return, and so on.)
In my experience, ERPNext version-12 mutable ledgers were wonderful confidence builders especially during the introduction phase. I realize that we can have the best of both worlds by simply adding an immutable checkbox which emulates the Immutable journals of other systems if checked, and retains the original behaviour of version-12 mutable journals and ledgers if unchecked.
1 Like