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:
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.
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.
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.
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.
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:
@peterg
The situation here became something like this. Let me assume a product P being sold, made of R1, R2 Raw Material:
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.
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.
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.)
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.
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.
@peterg thanks a lot for all your clarifications - we were thrown a curve ball when it was said that backdated stock transactions will not be permitted. It is clear now that we can choose a prior transaction date to post Purchase receipts or Delivery notes.
My follow up question is as follows: For Year End Closing Dec 31 - if we post on Jan 15 some delivery notes or other transactions, will the year end closing statements - like balance sheet / P&L show the impact of those transactions? More generally - are period reports based on posting dates or transactions dates?
Excuse my confusion, I can understand if posting date can’t be, and yes it shouldn’t be, backdated because it will be “cheating” (you work on the post today as if you did it yesterday).
But transaction date (if I understand correctly) is the date when actual transaction/document happen. So it should be “as-is” for the date and the value. Otherwise it might cause fraud.
But here, the posting date is said causing the burden. Posting date should always be going forward (you can’t go back in time). But transaction date may be causing the recalculation, because the actual happen is in the past.
So I see here the toll is not caused by posting (or transaction date for that matter), but just because there is only one date used.
Even in the Stock-related doctype, the field allowed to be edit is labeled as Posting Date. I think this should be re-labeled as Transaction Date. And the posting date is the date user enter/create the doctype.
The rate for outgoing is not filled (NA). If it is filled (take from previous relevant Queue), it can be used as carry forward Rate, e.g for transfer incoming in WH2. They should be balanced out anyway. Or if it is used for sales it can be used to calc COGS, or write-off as
Where is Credit in GLE taken? It should be from Qty*Rate, right? But if the outgoing Rate is NA, it must be from calculation (I guess from the Queue). This can be heavy because everytime there will be calculation.
The immutable GLE table may be correct for the final balance. But it is still wrong for the periodical (daily/weekly/monthly) balance.
As in my other post somewhere here, make use of the Stock Reconciliation doctype. Make one more purpose and name it Stock Adjustment or something. Use this to handle the backdated stock entry.
These are my quick notes so I may be wrong or not precise.
Reporting would have to be based on transaction date, otherwise it would be pretty incoherent. As for closing vouchers, my assumption is that they’ll block new transaction dates like they do now, but I haven’t seen this said explicitly anywhere.
To be sure, I’m not trying to dismiss anyone’s concerns about this change. There are some big implications, especially w.r.t. valuation in perpetual inventory systems, and I don’t know enough about how different companies do this to really understand the implications for everyone. There definitely are issues and things that don’t seem to be fully figured out yet (hence the delay, I assume), but they’re a bit more specific than I initially thought when first hearing about this change.
That sounds about right, at least as I understand it. For the most part, the only place this will really be visible to users (apart from audit) is in how valuation gets calculated. That’s the tricky part.
Correct. This part isn’t implemented yet in the v13 development builds.