Immutable Ledger vs Immutable Entry (Journal)

1

In version-13, Immutable Ledger was introduced. To cancel an entry, it generates ledger entries with today’s date (which I think is wrong, because ledger entries shouch be linked to a journal entry). As a result, You may no longer enter any new transaction involving the items in the entry with posting date before today’s date nor amend the cancelled entry

In SAP, cancellations are achieved through reversal journals.

As an Illustration,

This was a query on SAP Business One site:
I use SAP B1 2008.

I know we can cancel certain documents in SAP after they have been posted.

Ex. We can cancel a Sales Order by Selecting Data → Cancel from the menu.

Is it possible to cancel a posted Goods Receipt (or a Goods Issue)?

I don’t find any “Cancel” menu.

The only way I can cancel a Goods Receipt is to raise an identical Goods Issue.

But this method has its problems:

As we adopt a FIFO method of stock valuation, we cannot impose our chosen issue price. It is the system which calculates it.

Hence, we may end up with an issue price which does not cancel with the receipts price.

ANSWER:

Not possible to cancel posted GRPO. But you can return received goods through purchase return

Comment by questioner:

But with GR, if you try to cancel with a corresponding GI, you may end up with GR and GI not being exactly equal amounts (because I use FIFO method of valuation) and the issue price is determined by the system.

My comment:

Is it better to implement Immutable Journals (Sales Orders which do not generate ledger entries need not be immutable) instead of Immutable Ledgers? I think so.

Notice that the Reversal Journal Entry maintains continuity of Costing (Such as FIFO, etc), Plus, generated Ledger entries are linked to Journal Entry (which is what accounting calls as Book of Original Entry).

1 Like
2

Isn’t the real problem just determining the value of the return, meaning the amount paid at the time of sale? FIFO, immutable ledgers, and the like are just distractions: If someone paid with a coupon, or had any other kind of discount, it’ll still blow the idea out of the water.

The only real way to handle this is to deal directly with invoices, and cull the individual items from them to generate another invoice sans those items, and a refund for the rest.

3

Precisely! The correct way to deal with invoice transaction cancellation if you want an immutable system is NOT to CANCEL the Posted transaction (submitted Stock Entry). This goes against Accounting Principles that Posted Transactions should never be Cancelled. Instead it should be reversed by another entry. Cancellation should be effected by a Reversing Transaction Entry which creates the cancelling Ledger entries when posted. Then, Creating a new Transaction if needed, which then posted or submitted (in ERPNext terminology) will create Ledger entries to reflect the correct business situation. In this why, there is no need to tamper with the way ERPNext in version-12 brilliantly generates the ERPNext ledger entries.

In version-13-beta, the ledger generation process as I had been explaining is just plain wrong and goes against accounting principles.

Version-13 can have a checkbox for Immutable Invoice. If this is checked, Cancellation creates reversion entries on date. Thus, this solves the problem of backdated transactions if you business case demands Immutable.

However, if the checkbox is NOT checked, the powerful ERPNext version-12 ledger process which recalculates the Costing (very heavy duty computing) remains in place.

At present, this incorrect implementation of Immutable ledger is forcing (and will force) many ERPNext users to remain in Version-12 because I think, majority of business cases is more concerned with backdated transactions rather than Immutable ledgers (which is in the first place wrong in Accounting concept).

Also, in this ERPNext version-13 Immutable Ledger, any Stock User should be very careful about posting entries. Any cancellation can make the System unusable. (In my case, to implement version 13, I have to disallow Cancel in the user permission settings. to avoid this possibility).

1 Like