@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.
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
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
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!
