PartWIP quantity greater than job quantity

We have a mismatch between data retrieved from a custom dashboard using the PartWIP table and the vanilla Job Manager dashboard. It looks like the PartWIP table tends to overestimate the amount of parts in WIP, sometimes even showing more parts in WIP than the job quantity. This appears to be due to parts getting “stuck” in WIP bins.

Production quantity is 6.
Current actual quantities at the final non-complete operations:

010-030 completed
040 Outside Vendor: 2 (4 passed on to next op.)
060 Inspection Receiving: 0 (4 passed on to next op.)
070 Machining: 2 (2 passed on to next op.)
080 Cleaning: 0 (2 passed on to next op.)
090 Final inspection: 1 (1 passed on and completed)

That means WIP is 5 parts, with 1 completed. Job Manager corroborates this.

PartWIP table is still showing 4 parts in Inspection Receiving bin, though there are labor transactions that show those were passed on to next operation. Thus the total WIP quantity is overestimated to be 9.

where is your question tho?

I guess my question is why Epicor thinks there parts are still in a bin even though the labor transactions have moved them onward. This is an issue that we consistently run into.

the partwip table is a stand alone table, and i think they don’t handle some transactions well, or miss others. I’ve seen discrepancies in WIP reporting since E9 and earlier. It’s not well implemented across the board from my experience.

I would like to refer you to my WIP is Garbage thread. If you need to track WIP by qty for finished goods plan to start building a lot of BPMs to wrangle that beast. There is a pretty nasty bug with qty not being correct from the final operation that is corrected in 10.2.200.31 (so I’m told). Not sure what the partner .300 and .400 patches are for that though.