Philosophy, Ethics, Real Time Inventory and Immutable Ledgers

It is possible for the Date of the Cancelled Document and the Cancellation Date (set Today) to belong to different periods.

You should really reread Nabin’s explanation of the posting date/transaction date distinction. It clarifies all these issues.

1 Like

One outcome is that we will fix is cancellation so it is on the original date. I think @Deepesh_Garg will make a fix next week.

Only thing we are stopping from backdating is stock transactions because of its compounding effect on subsequent transactions. Overwriting timelines is bad from a software design perspective too.

Request people to make shorter posts so the discussion is more participative!

Any other “blocking” problem?

1 Like

Is backdating also disallowed for periodic inventory?

Clarification - again - I thought we could backdate transaction dates but posting date will be entry date. So NO backdated (transaction date) delivery notes? Also document immutability requires that invoice cannot be cancelled - it must be credited. Are we permitting cancellation?

What is on the table for discussion? Are we open to revamping ERPNext (example posting to journal entry as suggested) or this discussion is limited to immutability within the current ERPNext setup? Just seeking clarification on the scope…

As part of an organization using ERPNext (hosted on, we don’t really have an option when it comes to this (immutable stock ledgers) as it would be done as part of an upgrade. But, I would like to add my opinion:

  1. Not having to create backdated (backdated beyond an old transaction of same item/RM) is definitely an ideal situation. We would expect all operations to reflect physical movement (and that is definitely immutable sequence). So, theorectically, the immutableness of stock ledger sounds logical.
  2. But, practically there are some situations where backdated entries need to be done. For example, during the COVID time, as there was severe staff shortage, we had to complete some deliveries without proper entries (Purchase Receipt => Manufacturing => Delivery cycle). Now, in case Delivery date is locked (export/tax regulations), our stock In (Purchase Receipt) and Out (Delivery) too has to be date locked (read, backdated).

If we sincerely analyze all our operational situations, in 90% of the cases the onus lies on timely entries. If I don’t make excuses of being small organization with limited staff, I think I can safely say that immutable stock ledgers would be not a big issue. But, that is again ideal world.

But, a toggle would definitely put it there with ‘best-of-both-worlds-category’. Or, maybe restricting the backdate to be within a financial quarter (based on financial year definition). That might limit a lot of impact.

I realize that this has been in discussion for multiple years. And team would have invested sweat to get this to a stage to be broadcasted as being part of v13. And, a software always has some limitations - we have to learn to live with that.

So, basically a torn-in-both-direction opinion from me.

1 Like

I have at least 5 years of navision and 4 years of adempiere / idempiere. Am implementing erpnext for current company operations. This immutable will be disaster based on my experience. Anyway software is yours. If it risks my career or job I will have to find other solution.

Good luck.

1 Like

ERPNext has very powerful code. I like the simplicity and power of ERPNext as it stands on solid Frappe. ERPNext has a core team who controls the commits, manages the timelines, and documents the software with Online Manuals and Youtube Videos, and Webinars. It also has a respectful and helpful forum. ERPNext community is on a journey.

In practical terms, what would the negative impact of an immutable ledger be for you in this context? Even if your deliveries have posting dates in August, they can still have transaction dates back in July.

Isn’t posting date the transaction date?

No, that’s the whole point. Like I said before, you should really reread Nabin’s explanation of the posting date/transaction date distinction. It clarifies all these issues.

There’re many scenarios that require backdated stock entries… We have to look from end users business perspective, not from tech stuffs which is the users don’t care too much

This immutable forces the users to always bring forward all cancellations/adjustments only…in other words…they should have final audited stock balances ( or let’s assume 80-90% valid) before using erpnext.

There’re many other cases…they do adjustment for many reasons like taxes, internal purpose etc…system should not lock down it… bringing adjustment forward only is not acceptable. They are the users and the data are theirs. Let the users themselves decide in flexible way whether they’re capable enough to use this feature. And based on real experience…even not many enterprises can adopt this properly… backdated is required. tracking/versioning is already there for user admin for audit purpose

It doesn’t make sense even for enterprises…they do adjustment/correction here and there most of the time for many internal reasons.

I’m in the opinion…We cannot force user to go with erp align with current date in every situation. System should be flexible enough and put them (end-users) in control.


User-perspective means transaction dates, and backdated transaction dates are allowed. Can you be specific about a scenario where a user needs backdated posting dates too?

what if the scenario e.g. tax purpose report per last year requires user to backdated adjust stock balance value? is it possible? The adjustment is posted forward per current posting date, right? Immutable doesn’t allow to adjust posting date of backdated value/qty…

the reason behind may vary e.g. previously the value is incorrect but adjustment comes today…some users cannot accept the adjustment is brought forward only.

Why not using Stock Reconciliation for stock adjutment made on back date?
Maybe making new purpose in the list as “Stock Adjustment” that can similarly do like Stock Reconciliation. The difference is this adjustment can be done anytime while the reconciliation only at year end.

Yes, a stock adjustment for last year can have a backdated transaction date, as can any journal entry that might be needed to help recalculate valuation. I know I keep posting this, but I think it clears up a lot of misconceptions about what an immutable ledger actually means:

The situation here became something like this. Let me assume a product P being sold, made of R1, R2 Raw Material:

  1. In May month, we had to manufacture a certain quantity of P. For that, we had received R1 and R2 in April - which we couldn’t enter into stock because of some government restriction (lack of staff). Then, by end of may the Product P was shipped out of our warehouse. All the while, the in-house staff did all physical movement - minus ERPNext movement.
  2. In June, more R1/R2 arrived - they were ordered in March. At that time, the staff made PR on those. But, the PR of previously received R1/R2 (in may) was never entered until end of June.

We cannot simply shift the delivery date of P (or, actually, SI) because of taxation laws.
So, in effect, sitting in June, we had to make old entries on R1/R2/P into our stocks - all the while there were already entries of R1 and R2 in month of June.

In the hindsight, the solution is simple - don’t enter new entries until old are entered. But, practically that means “wait fairly long to assure date ordering” - which is quite a big constraints for small organization which run on staff doubling their responsibilities of data entry and actual work.

Hi Shreyansh,

Right, so a Purchase Request was missed. It should have been entered on May 10th, but only on June 20th was it realized to be missing. Maybe even the Purchase Order/Invoice were missing, too. So, in June, you make a backdated stock entry with the format:

Posting date (no backdating allowed): June 20
Transaction date (backdating fine): May 10

Your stock levels, though wrong for more than a month, will be correct going forward, and your reports will include the event on May 10th. If you use perpetual inventory, the system will create a GL Entry on the same dates, as well. In other words, there’s nothing stopping you from posting May’s entries in June (even after delivery). The only thing you’re prevented from doing is pretending that they actually were posted in May.

Would that workflow present you with trouble?

(There is one actually messy part here, related to how FIFO valuation queues get calculated on backdating, but that’s a somewhat different issue.)

1 Like

Your point is valid - if there were a way to differentiate between posting and transaction dates - that might not have created a problem for me in this scenario (or even other similar situations).
Even though the link that you had added above did talk about such an distinction, the original post (here) talks about restricting transaction (here I assume transaction dates) prior to last transaction (in my sample case, June).

Back dated entries that affect the Stock Ledger will be allowed only after the last stock transaction’s posting time which means there will be no need of any reposting of future transactions.

Am I mistaken or reading wrong?

The computational expensive part being described is related to valuation queues, and in @nabinhait ‘s explanation those valuation queues are tied specifically to posting date. Likewise, I interpret the post you’ve linked to be referring to posting rather than transaction date. In a few other places, as well, the devs have said that the limits on backdating will apply to posting dates and not transaction dates.

The language is inherently a bit confusing, though, so some clarification about current technical plans would definitely be valuable.