Oh I just remembered, then you need to create a label/report and print it somehow!
That other stuff is just to create one PCID in the database.
And then there’s scanning and using them…
Oh I just remembered, then you need to create a label/report and print it somehow!
That other stuff is just to create one PCID in the database.
And then there’s scanning and using them…
I pcid’d all day, I feel your pain lol.
We use PCIDs extensively and they are a nightmare. I would avoid them if at all possible.
a couple ways PCIDs can become broken:
Interact with the same PCID from two different PCs at the same time, such as PCID Build/Split/Merge. After the data is read into the GUI display and you do an action such as Return to Stock, the Epicor logic assumes that the PCID still exists in the same state. It could have already been Returned to Stock by a different user. Or the PCID could have been moved from one bin location to another. There’s no sanity check after reading the data into the GUIs. This will do things like create a PCID that exists in two locations at once (logically inconsistent) and/or introduce stock quantities that are both positive and negative at the same time.
If you use EKW / Biscit software, you can attempt to work with PCIDs, and if you have a bad internet/wifi connection, an impatient user will click the Submit button 5 times. You will then have the same transaction submitted to the database 5 times in a row, with no internal logic to validate that the action hasn’t already been performed. I’m betting this bug would happen with any weak wifi connection, not just in EKW software.
Once you have this kind of mess, you have to have a data fix to clean it up. For us, it’s a losing battle. I end up doing things like building dashboards to find where the data integrity has been lost and needs to be fixed; clean things up when I can. Or wait for the users to complain that a PCID is broken.
Wow, thanks for the insight into your experience so far with these.