PCID tables not staying in sync with partbin tables

I have experienced exactly this situation myself: right now I have seven confirmed cases where the PkgControlItem.ItemQuantity doesn’t match the PartBin.OnhandQty for the same PCID. I was able to track down why it’s happening, though it’s likely something different in your case.

We have customized the Process by ID screen with a dropdown for PackageControlIDCode. When the user selects from the dropdown, it auto-generates one new PCID and puts the PCID number in the “To PCID” field. The problem was when people were issuing material to a job. In the Base implementation of Process by ID, the “To PCID” field is grayed out when issuing to a job. However, our users were sometimes making a selection from the dropdown, which was re-activating the “To PCID” field. They would get an error, but the damage was already done at that point: the two quantities were now out of sync.

I found the root cause by examining the transactions related to one of the corrupted PCIDs in Part Transaction History Tracker, noticing a transaction issuing the mismatched quantity to a job, and reproducing the situation in our test environment.

We have fixed the Process by ID customization so it will no longer re-activate the grayed out field, which should stop the bleeding, and now I just have the seven items to clean up.

Good luck with figuring out your problem!

1 Like

I’ve seen the PCID mismatch where an item was recived then moved then unreceived without moving it back to where it came from.

The upshot is the PartBin table has a PCID but the PCID record itself is shown as empty and has no items in the PkgControlItem table.

We received a “This PCID is not in this Warehouse and Bin” error message.

Opened a case and waiting on what Epicor says.

We run into FIFO layer errors every so often - Epicor has data fixes for those.