https://github.com/frappe/erpnext/issues/19778
have posted this issue above, anyone else facing this ?
I’m. And I believe it have something about float and currency decimals…
The report “Stock and Account Value Comparison” shows transactions with differences. Confusion is as follows:
- transactions are stock entries moving stock from one warehouse to another with all items sent and received in same transaction. How can there be a difference?
- stock value is correct and cannot do journal entry as “you cannot create a Journal Entry for Stock In Hand accounts it should be done only through stock transactions.” Cannot do Stock Valuation as it says there is no change so does not allow saving (and anyway error is in account value not stock value).
Why would stock transfer create a difference in account value and how to bring back into sync?
We found similar issue on all V11. When stock is transferred from one location to another there is slight difference due to 3 decimal digits currency we use. The Stock Entry DocType has hard coded 2 decimal digits which ignores precision that was set in Global Settings. The difference amount is stores in Stock Adjustment. Not sure why your instance is doing it unless you are also using 3 decimal digits. I have sent PR to fix this in hotfix, waiting for it to be merged. We fixed it by manually correcting the line however on update it reverts back to original code.
@Muzzy Thank you, will investigate. Supposing that turns out to be the issue how to resync account and stock values since we cannot go back and redo all the stock transactions?
Can’t do anything about historical entries. Maybe pass and adjustment entry to clear the balance.
You won’t be able to redo as the items may have been sold which will throw up errors. And would be lot of work as well to fix each transfer. Best way forward is passing a JV.
Understood, but JV not allowed as indicated because “you cannot create a Journal Entry for Stock In Hand accounts it should be done only through stock transactions.”
You can change the accout type from stock to null. Then pass the jv and change the account type back to stock.
1 Like
On v-13 and is not fixed
Thanks for this. Would anyone be able to share some examples of why this happens when a previous / historical entry is changed or updated?
The error comes up when a drafted form is about to be submitted. Presumably because the value in the draft form is now incorrect since something had been changed from the historical records. If my thinking is correct, then why not just update the value in the form being submitted right before it is finalized as a submitted form? No need to force a GL adjustment.
Unless I’m missing some use cases here why this adjustment needs to be done.