ERPNext.com Frappe Cloud Support Partners Foundation

Discrepancy between the number of serial numbers and the amount of stock

We have a discrepancy between the number of serial numbers and the amount of stock for this same item within ERPnext.
The result is that we still have 12 Items that physically exist that have a serial number in ERPNext but due to the discrepancy in the stock can not be delivered to a customer.

When we look in our s serial number list we can see 12 “DUO-BOXED” items in the warehouse “Finished Goods”

When I go to the Item “DUO-BOXED” we can see that there is no stock.

In the Stock Ledger we can also see that there should be 0 stock in warehouse “Finished Goods”.

But in the stock balance, we find that there should be 12.

We have checked for date trouble (a stock entry that might have been later than a delivery) but this does not seem to be the case

As a fix, we have tried adding stock with a “Stock Entry” a “Material Receipt” for 12 DUO-BOXED and adding these serial numbers but that is not possible:

We know that we did something wrong, but what? We love ERPnext because it keeps track of everything and connects everything but somehow we managed to screw up here.

Does anyone have a suggestion on what we might have done wrong and more importantly what we can do to fix it?

It might be worth investigating your past 10 or so transactions involving this Item code to see if any of the same serial numbers show up on an invoice somewhere or some other Stock Entry ticket.

If you are trying to find out “how” it happened, it helps to know everything that has taken place in the past 30 days with the Item code and from there the individual serial numbers.

Please also, include in your next post the version of ERPNext you are using and how long you have been on that version. At this point the more data you can uncover about the system and the Item code, the closer you can get to finding the offending incident that left the database so confused.

BKM

Hi BKM,

Thanks for your quick reply!

To start with the basics:

Our ERPNext verion: v13.6.0 (version- 13)

Frappe Framework: v13.6.0 (version- 13)

We installed version 13 in the beginning of May and have been updating regularly.

Comparing the stock balance and the stock ledger we can see that on 21-05 the discrepancy started.

The day before we had 43 units in both the ledger and the balance.

At the end of 21-5 we see 44 units in the legger and 56 units in the balance.

Upon further inspection I see that one transaction of -1 unit resulted in a balance change of 13. That must be the mistake.

Looking deeper at the delivery-note attached (DN-01069), there does not seem to be anything wrong.

I have also checked the invoices, delivery notes, stock entries and reconciliations around that date. There, too, do not seem to be any anomalies.

Can any of you think about a probable cause and, more importantly, a solution?

Thanks for thinking with us!

Open those Stock Ledger Entry of this item and cross verify it.

Please check and see the entire history of stock transactions for a Serial Number (that should be there in stock, but is not) in the Stock Ledger. That should give you an idea about the associated transactions for the Serialized item and hopefully that will help you identify where the problem is.

Hope this helps.

Thanks

Jay

We also faced a Similar scenario after upgrading to v13. We couldn’t find the exact reason however we doubt that it happened due to back dated cancellation/deletion of stock transaction which didn’t trigger the reposting of stock ledger.

As a workaround you can correct your ledger by posting a dummy stock entry “material receipt” of just 1 qty in a date prior to the error date. This will recalculate all your future transactions and your ledger will reconcile. The dummy entry you can either cancel or make another stock entry “material issue” in the same date to nullify the impact.

2 Likes

Thanks! That seemed to do the trick!
Any idea how what is causing this problem?

The main culprit in V13 is “Repost Item Valuation”. We witnessed that If the repost job have to process large volume of transactions which involves Batches or Serial Numbers then it locks the stock ledger and the stock transactions which are posted during the process (while the repost is running in background) showed high frequency of errors/discrepancies.

Check below link for reference and join hands to further investigate /upvote this issue for quick solution!!!

1 Like