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.
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.
@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.
From @nabinhait explanation, I have notes:
- 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.
There is no Transaction Date field in Purchase Invoice or Purchase Order
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.
Thanks. This clarifies many things.
I think we shouldn’t ban backdated stock entries. There are always corrections and oversights.
Rather, making back dated stock entries should be a special permission. If a company does not wish to make back dated entries (ie, once inventory has stabilised) - we can remove the permission. Perhaps, given that multiple periods could be impacted, run it as a job
From a regulatory/audit perspective - this shouldn’t be allowed post fiscal close. ie, once a period is closed and/or the 13th period is opened, back dated stock entries should not be allowed.
We I have a use case, we make some sales Invoices where Update Stock is checked. SO basically we are affecting both Stock Ledger and also the accounting ledger.
Now the issue is we might need to cancel the invoice and amend it some silly mistake in this case the invoice date is generally not changed so basically we are trying to post a back-dated entry which would cause an issue. Though this use case is for mistakes which don’t happen quite often but still you don’t want the system to be harsh even for silly mistakes.
The solution to the above problem: What I have thought that if the immutable ledgers are indeed introduced (which I also think is a GOOD thing), then I would stop posting Stock Update from Sales Invoices and probably run a CRON Job like 5-days later to post the stock entries. So basically my people in accounting would get a time line for 5-days to edit or amend invoices in back-dates.
Also I am presuming that Immutable Stock Ledgers would somehow allow adjusting the STOCK Value by posting back-dated Stock Reconciliations as I had pointed out since Stock Value and Stock Qty are 2 different things and not managed by same people in our organisation.
All in all I know its a great feature to have immutable ledgers esp Stock Ledgers, I am saying it from experience since many time we used to do Stock Reconciliation for a particular item and only to find that some Stock Entry for that Item Code was not submitted and that still caused a lot of headache with immutable ledgers this kind of a problem is resolved.
I know to every change there is a lot of resistance and I know I am the one who is resisting this change since in the future it would cause a lot of pain for its implementation but I hope the team in erpnext would try to make the transition as smooth as possible
If we put immutable as mandatory, users will have no control over their own data.
Most business saying this in simple way → “I want xxx qty and xxx stock balance in my financial report on xxx date” Its impossible to have it if immutable is mandatory
There’s always pros and cons…Immutable is a good thing but again in real business practice, lets to be honest, I believe most organizations cannot only moving forward…they would want and MUST turn back time for different reasons and purposes.
Let them or user admin decide using permission manager, system setting option…where & when they want to lock backdated over certain period…it’s very wise choice for all
Thanks
This is not true, under the immutability implementation proposed by the developers. It will be entirely possible to say exactly that.
From multiple ERPNext implementation experiences
- User enters an incorrect value or incorrect qty and finds out later that it’s incorrect. He/she wants to cancel and amend it. Cost of Goods sold would be posted with an incorrect value in immutable ledgers and Gross Profit report will show incorrect values
- User enters provisional values for incoming stock or opening stock to continue using the system and update with the true values later when it is possible
- User wants to add additional landed costs (I guess LCV still modifies SLEs in v13 from what I see in the code)
- Company receives stock and wants to pay the supplier based on a profit margin which is determined in the future and cannot be determined at the time of receiving stock
2 Likes
Thanks @peterg for the explanations:
In this case, you can still cancel, but the impact of cancellation will be on the cancellation date, not the original date, so during the period of submission to cancellation, you will get your stock value assuming the entry happened, your stock value post amendment will be fixed from the date of amendment.
You can surely correct your mistakes, but if your are correct past mistakes, the correct impact will happen from the day you fixed them.
You can definitely have this, by creating a group of your “Current Assets” with and “Adjustment Account”. If you have made corrections at a later date, the will be explicitly maintained separately.
If you have made transactions post 1st Jan, then the deliveries must be posted post 1st Jan. However if you want to move the P&L impact to the previous fiscal, you should be able to pass a journal in the previous year against “un booked expenses” or something, and then cancel it in the current year against “previous year expenses”. It is a tedious work around, but possible. I am sure there is an accounting methodology for this.
While this is true, this is desirable since - during the period in which it is not corrected, it would have shown wrong values anyways. If the numbers are significant, I think an additional journal should be made against the invoice to correct the values.
If the provisional values are reasonable, this is not a problem. Unless the items are high value, most opening valuations are guesstimates anyways.
This is only a problem if the item is billed before the costs are loaded, in which case it would make sense to book COGS independently.
In short, adjustments are possible (accounting is the art of the possible) but these will be explicit.
Update: I think @nabinhait has already decided to allow both the models (choice to overwrite stock valuations or not). For the record, I think this a bad idea, but yeah that is my opinion, will let the module owner decide 
Thanks everyone for your thoughts. Closing this thread for now. Will wait for @nabinhait for the next announcement!
3 Likes