Our PORel.ReceivedQty is wrong and I don’t know how to fix it…
The PO release is a drop shipment release for 75,000.
Seven (7) drop shipments have been received, totaling 66,500, leaving an open quantity of 8,500. One of the drop shipments was for 51,600; the other six were small amounts.
PO Tracker shows all the shipments.
The corresponding SO release shows 66,500 received and an open quantity of 8,500.
When I go to drop shipments, it shows that the open quantity on the PO release is 8,500.
Purchase Advisor (in the On Hand tab) shows demand of 8,500
However, the actual value of PORel.ReceivedQty is 51,600 (retrieved by BAQ). So the six smaller shipments are not being included in the population of this field.
How do I fix this? I looked at the rebuild processes, but the one related to “order” releases is meant for sales order releases.
I’m not sure how Drop Shipments would affect it, but there are two stages for receipts: “arrived” and received". If you only mark a PO receipt as “arrived”, the PO will look like it has zero outstanding, but the QOH won’t have gone up by the receipt.
Drop shipments don’t have the “arrived” step. They simply have a Received/Shipped checkbox. And all of these have been received against the correct PO line release.
It’s very strange that part of the system gets the right answer and another part of the system does not…
the first thing I would do is check the Part Transaction History. Try matching the transactions related to this PO.
Just spitballing… I’d check: tran dates and UOMs. Make sure TranType is correct and that none actually ended up in inventory. Look for receipts that were reversed and then re-received.
After re-reading the original post a couple of times, I think the problem might not exactly be what you think it is.
It seems like everywhere Epicor reports the qty’s (like in PO tracker and SO release), the value shown is correct. The only place that looks “wrong” is in YOUR BAQ. So I’m guessing your BAQ does not process the same way those other screens derive the values shown.
The BAQ literally pulls the value of PORel.ReceivedQty. When my bigger, more complicated BAQ did not work, I had the same thought as you. So I wrote a separate query that does nothing but retrieve the value from the table.
When I submitted the issue to Epicor, they said they would give me a data fix. So maybe this is a semi-known issue? Does not explain WHY this happened, which is really annoying…
So I guess the next order of business is to write a query that compares the total qty on the receipts to the current value of PORel. ReceivedQty to ensure there are no others… Sigh.
Thanks for looking at this.
Going to mark data fix as the solution (although not a totally satisfactory one…)
UPDATE
Checking all the open PO Releases revealed 39 cases where the sum of the receipts is greater than the PORel.ReceivedQty. And all are drop shipments.
So… have changed the title of this post and submitted the data to Epicor with a request that they look at it from the Drop Shipment perspective.
Data fix may be the solution to the ones that exist, but we really need to know how to prevent this from occurring in the future. Onward…
Using the Part Tran History? Doesn’t that have a default cutoff date of today?
What if a transaction was done with a bad date (a future date) and then someone corrected it by unreceiving it (also with that future date). That wouldn’t show with the default cutoff.
