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 @nabinhaithere, 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…
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.
Financial Accounting IFRS edition by Weygandt, et al.
There are two assumed cost flow methods:
First-in, first-out (FIFO)
Average-cost
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
Materiality principle in Accounting does not require the recomputation of future transactions of backdated entries. When a backdated entry is needed, the business is not required to recompute already done Stock transactions. Rather, the subsequent transactions will simply pick up the backdated entry. Review can show, based on timestamps, how backdated entries were picked up. ERPNext does not have to make it hard on itself. Accounting allows business some slack.
Perhaps I’m misunderstanding, but isn’t the whole point of the Landed Cost Voucher that it updates an already submitted/immutable entry? Under what circumstance would you want to submit a Landed Cost Voucher before landing costs are known?
It’s not immaterial when you’re adding landed costs like $100 to a $500 worth of goods…
It’s quite material when the additional $100 goes to Stock Adjustment account rather than Cost of Goods Sold.
As you like. You might look back at Nabin’s explanation of the immutable ledger will work, though, because as things stand it appears you are misinterpreting what the changes will actually entail vis-a-vis the mutability of vouchers.
Trust you’re doing good. Any updates so far? Currently, it looks like some kind of limbo state cos we need to sort this out before we can put it to any serious use. The current issues with immutable ledgers make it a no-no in most cases so we’re hoping that the option of using the old system (with some enhancements) is made available in the next beta release. At least we are familiar with that system and we can immediately begin working with that in less-critical environments
As you know, the real major testing only comes in production use and so far, this is the only thing holding us back
As always, thanks to you and the entire team for the awesome work done so far
Hello @nabinhait!
First of all, Thanks for your hard work and noteworthy efforts to make an amazing system for everyone.
I am stuck in the data import process after working on the new implementation for the last few months, we have updated to v13 and realized that it no longer supports backdated postings. Now you know; it is very hard to rollback. We in-house implementing ERPNext in our Enterprise Level Company. But Frankly speaking, we are still not ready for the immutable ledger.
As you said
Can I ask you for an update, what’s the overall progress? because, it will help us to rethink the current implementation plan.
Inventory is without doubt the most complex aspect of any ERP. It would be good if you can resolve the issues with recalc/valuation of inventory.
a. For computational ease - we can run recalculation of inventory as a batch.
b. There is no alternative but to allow for such revaluations however - inventory is messy and as such there are numerous situations where we need to back post.
