Philosophy, Ethics, Real Time Inventory and Immutable Ledgers

[Joseph_Marie_Alba1]

@rmehta

In v13, we took the decision to stop editing stock value so that we don’t disturb the timeline.

Probably, a better way is to simply stop recomputing the future stock values and allow the backdated FIFO costing to be naturally picked up by the next transaction.

[rmehta]

Thanks everyone for sharing your views. Unfortunately there is still some confusion on how this is implemented.

1. Please note that you can still post accounting entries in previous periods, so there is nothing to stop you or the auditors from from making adjustments. So from an accounting / legal perspective there is no change. Except that ledgers will not be overwritten.
2. Only the stock ledger cannot be posted beyond the last transaction.
3. Cancellations for stock entries will work but the impact of cancellation happens in the forward direction only.

Can someone very briefly share a use case where you would want to rewrite the stock balances and a simple accounting adjustment will not work?

[Joseph_Marie_Alba1]

@rmehta

beyond the last transaction.

in make_reverse_gl_entries:

line 320-322:
        entry['remarks'] = "On cancellation of " + entry['voucher_no']
	entry['is_cancelled'] = 1
	entry['posting_date'] = today()    <----

def check_freezing_date(posting_date, adv_adj=False):
	"""
		Nobody can do GL Entries where posting date is before freezing date
		except authorized person
	"""

[olamide_shodunke]

Hi @rmehta

I have been using V13 in a real life environment for the last 6 Weeks. This is a deliberate decision and we assumed the risks inherent in using a beta version.

Companies need to be able to post backdated stock transactions, especially the SME segment which has been your avowed target segment.

The reality is that there are too many scenarios where this will be necessary either as a deliberate action by the business or as a result of errors.

Do not go ahead with this implementation of immutable ledgers. Your market will kick against it strongly.

Olamide

[rahy]

@rmehta

Only the stock ledger cannot be posted beyond the last transaction.

Is it stock ledger or stock voucher / stock journal entry?

@rmehta

Cancellations for stock entries will work

Stock entry means stock JE?

[zerodiscount]

I would like to add to this discussion what I learned from another thread on what immutability means - as there could be confusion - as was the case for me… Very nice and timely summation / clarification posted by @peterg can be found at

[discussion] Immutable Ledger

Nabin posts a good explanation earlier in this thread (hard to find because it’s gotten huge!) The changes will be much less dramatic than people have sometimes thought. As I understand it (based on discussions here and the partial implementation in v13 beta): The cancellation workflow is unchanged. You can still cancel if you wish, and you can still reverse an invoice with a credit note if you wish, your choice. The only thing you can’t do on an immutable ledger is delete cancelled documen…

The changes will be much less dramatic than people have sometimes thought. As I understand it (based on discussions here and the partial implementation in v13 beta):

• The cancellation workflow is unchanged. You can still cancel if you wish, and you can still reverse an invoice with a credit note if you wish, your choice. The only thing you can’t do on an immutable ledger is delete cancelled documents.
• The transaction date/posting date distinction will be made more consistent on the backend. Transaction date will represent when the business event happened, and posting date will represent when it was input to the system.
• Backdated transaction dates will be allowed, but backdated posting dates will not. The only real implication here, as I understand it, is how this impacts stock valuation. This is, I believe, the sticking point.
• Closing vouchers will serve to lock transaction date periods, same as now.

In other words, though a lot changes on the backend with (positive) implications for audit, the only real user-facing impact is in how stock valuation gets calculated on backdated transactions.

So it seems a lot of the fears around inability to back date transactions were misplaced - frankly including mine.

[rahy]

Yes…
And I think we need to start separating between immutable and capability to backdate posting

[tonto]

@zerodiscount

• Backdated transaction dates will be allowed, but backdated posting dates will not. The only real implication here, as I understand it, is how this impacts stock valuation. This is, I believe, the sticking point.

Key for us is the definition of backdating. If backdating means no posting dates before today, that is a deal breaker. If backdating means no posting dates, before the last posting date for this item, that we would support.

Also,

@zerodiscount

The cancellation workflow is unchanged. You can still cancel if you wish, and you can still reverse an invoice with a credit note if you wish, your choice. The only thing you can’t do on an immutable ledger is delete cancelled documents.

I fail to see the difference between a cancellation and a deletion of something that occurred in the past with transactions dated after it. Both will change balances for subsequent dates that are in the past. If deletion is not allowed, cancellation should not be either

[peterg]

@tonto

Key for us is the definition of backdating. If backdating means no posting dates before today, that is a deal breaker. If backdating means no posting dates, before the last posting date for this item, that we would support.

It seems the latter: you can backdate posting times as far as the last posting time for the item.

@tonto

I fail to see the difference between a cancellation and a deletion of something that occurred in the past with transactions dated after it. Both will change balances for subsequent dates that are in the past. If deletion is not allowed, cancellation should not be either

Cancelled documents still represent ledger entries…two sets, in fact: one creating the document and one cancelling it. It is informationally equivalent to a invoice → credit note workflow. If the cancelled document were deleted, the ledger entries would be orphaned.

[Joseph_Marie_Alba1]

@peterg

Cancelled documents still represent ledger entries…two sets,

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

[peterg]

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

[rmehta]

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?

[Joseph_Marie_Alba1]

Is backdating also disallowed for periodic inventory?

[zerodiscount]

@rmehta

Only thing we are stopping from backdating is stock transactions

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…

[shreyansh]

As part of an organization using ERPNext (hosted on erpnext.com), 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.

[adamtang79]

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.

[Joseph_Marie_Alba1]

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.

[peterg]

@shreyansh

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

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.

[Joseph_Marie_Alba1]

@peterg

transaction dates

Isn’t posting date the transaction date?

[peterg]

@Joseph_Marie_Alba1

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.

[discussion] Immutable Ledger

In this post, I will try to explain what we are currently doing, the drawback and advantages of that method. At the same time, what changes we are proposing and implication of that. Let’s take following entries to explain our scenario. Stock Valuation Method: FIFO Fiscal Year Records: [image] Stock Ledger Entry [image] Accounting GL Entries [image] Now, let’s say, we do a back-dated incoming entry on 15-02-2016 for the same item with 4 qty at $1100. Currently, based on the back-dated e…