PCID tables not staying in sync with partbin tables

So we have been using PCID’s for a little over a year now, and we have some customization/automation written using the Epicor BO’s to do some tasks, (Epicor screens can be clunky and not good for more than one transaction, story of our lives, right?)

Anyways, we’ve been seeing a lot of times when the partbin table and the PkgControlItem tables get out of sync. Partbin will say that there are 50 and the PCID will say that there are 100 or something like that. So far, just about without fail, the partbin record is the correct one. Other issues that we have seen is the PCID item is simply not in the database, even though the PCID is on the partbin table, or the bins from the PCID header don’t match the bin from the partbin table.

I don’t see a way to fix these without some not really recommended editing of the tables, but that’s what we’ve needed to do so far. Running PartBin on hand fix (or whatever it’s called) doesn’t fix it.

Has anyone else using PCID’s seen this behavior from these tables? On one hand I’m hoping that it’s our customizations that are doing something wrong so I can fix them, on the other, I haven’t been able to recreate the problem behavior on demand so we haven’t been able to track down a bug in either my, or Epicors code, so I’m not sure where I can fix anything.

Anyone?

1 Like

I’m going to bump this, because we are still trying to figure out what is causing this. I have plenty of evidence that it does happen (the records are messed up), but we still haven’t been able to figure out how to recreate the issue. Is there anyone else out there that has had the PartBin and the PkgControlItem tables get out of sync?

We are pretty sure it has something to do with quantity adjustments, both regular and cycle count, but again, we haven’t been able to actually make it fail on demand. Until we can do that, I can’t really put in a ticket, because they can’t investigate if the problem isn’t recreateable.

Brandon I am sorry you are dealing with this, I still don’t know what is causing some of our part demand records to be off between partdtl and partbin tables…

I can only imagine trying to get someone to answer questions about inaccurate demand/on hand as it relates to PCID…

What is Epicor saying? I assume you have an escalated case with them?

Nope, I know that if I submit a case with no way to recreate the issue, they will most likely just close the ticket. So until I can find a way to recreate the problem, I’m not going to bother trying to submit a ticket. Hence the call to users here to see if anyone else has any clues on how to recreate.

I’m sorry man.

Yeah, I feel the same way most of the time. Sometimes it’s still worth throwing a Hail Mary support ticket though.

My only thought on your problem is… have you looked at Transfer Orders? Business Logic seems to get thrown out the window with Transfers, in my experience.

We use PCID for order fulfillment. Going through the entire Fulfillment Workbench, Material Request Queue workflow, picking into PCIDs for shipment. This creates PCIDs in the SOPICK status.

So far I haven’t been able to replicate it, but sometimes we end up with inventory stuck in a PCID that no longer exists.

It seems to happen when we add in item into a PCID, and then remove it, using ‘unpick sales order’ and then add the same item to a different PCID. Both PCIDs eventually get shipped and invoiced, the PCIDs get archived, but sometimes, after all that, we wind up with inventory that is still in the no longer existent PCID.

I have gotten specific datafixes from Epicor support each time this happens.

What if you created a CDC (or a couple of Data Directives) to log the quantity changes for PartBin and PkgControlItem for a day or two? Watch for them to go out of sync then bounce those against PartTran to see if you can identify a pattern.

1 Like

You mean like warehouse transfers? Or site transfers?

I think we have seen problems with warehouse transfers, using the material queue. It’s muddy though, because we don’t know exactly when they went out of sync, and everything has a cycle count on it. So we aren’t sure if it’s transfers, or quantity adjustments, or shipping/unshipping.

We have not done any site transfers, so it’s not that.

We do have that on, and are combing through those trying to figure out the pattern. We’ve gotten closer to seeing when it’s happening, but still no luck on recreating the issue intentionally.

1 Like

Thanks @hackaphreaka . Now at least we know that we aren’t alone. So it’s less likely that’s it’s one of our own customizations doing it.

1 Like

Yeah, combing through that is a PITA. What if you trigger a delayed BAQ comparing the quantities for the parts that changed? Write the part number to a queue and once the record is 30 seconds to a minute old, run the BAQ for that part to see if the quantity is in sync. It would take the manual work out of it and limit the time window a bit.

There’s no deferred transactions involved here, are there? :thinking:

I’m pretty sure there are, and I’m guessing, and that’s why the inconsistent behavior is there.

The PartBinDeferred (all the deferred tables) are unfortunately not available in a baq. Although, I suppose we might be able to get them via UBAQ.

Or an Epicor Function…

Yeah, I was talking about site transfers, but I guess it’s not that.

Are you seeing any particular usernames show up more than others? In addition to Mark’s logging ideas, how about just watching some folks process inventory transactions for 20 minutes? You might be surprised by what you see them doing…

Mark I was JUST about to chime in here saying I have been tempeted in writing data directives on part tran to try and capture when this happens, but I would never do that because… well… it’s part tran.

Would you suggest creating a data directive on part tran?

Mark, it makes sense to do the report, I might have to try that.

I was thinking more along the lines of PartBin and/or PkgControlItem in Brandon’s case. They are in Azure private cloud if I recall correctly, so one could write to an Azure function that waits a predetermined amount of time then calls an Epicor Function with the part number. The function would compare the quantities in the two tables (maybe look up PartBinDeferred too) and log the time when different. After that, I may do a query of PartTran for that part. If there are a lot of transactions going on for that part though, it may be difficult to track. :person_shrugging:

1 Like

That’s the hard part Mark, I wish I could tell right when the transaction happened and maybe even alert the user.

Not sure.

I can’t even narrow down what/who is causing this issue.

My other thought was to go back to the fundamentals and turn on client tracing… Then at least you could compare good traces of the material transactions with the bad ones and maybe just maybe see what is happening?

Still super messy.

We have cdc turned on on all those related tables unfortunately it didn’t happen consistently enough abs the cdc data gets really large really fast when partbin etc is involved

So it’s beeen tough

Ok, I created a case. We’ll see if they are any help.

1 Like