Epicor Kinetic Warehouse (Mobile Warehouse) serial number issues. Any ideas for a workaround?

Epicor ERP 10
, ,
1

Hoping someone can spark an idea for a workaround for an issue while I am waiting on Epicor support or Biscit support to step in with a solution. Basically, we have found that when sales orders for serialized items where the required quantity is greater than 1 are picked through EKW, one too few serial numbers gets processed onto the pick. Here is an example:

I place an order for 6 of a specific serialized item, allocate and release for picking.

From EKW, I complete the pick for 6 and select 6 serial numbers (if I don’t, I correctly get an error message that I don’t have enough serial numbers selected): https://imgur.com/MIJGaGF

All seems well on the handheld, the pick saves, etc. Once we get to the Customer Shipment Entry step, though, we started getting errors about not having the correct number of serials selected. We started to notice a pattern that there was always one too few (orders for 6 would only have 5 serials selected, etc.). The only orders that we didn’t notice issues on were orders for a single unit.

PCID tracker confirms that suspicion: Items tab shows 6 picked: https://imgur.com/Q08zXOb Only five listed in Serial Numbers tab: https://imgur.com/bn0m1nE

A little bit of testing led me to add a pre-proc directive on the IssueReturn.PerformMaterialMovement directive to show the Serial Numbers from the SelectedSerialNumbers dataset. What I found is that it seems to be showing one of the selected serial numbers twice and leaving off one that was selected. In the transaction in this screenshot, I had selected serials ending in 44, 45, and 46, but the info message shows 45 and 46 twice with 44 left off. 44 is then, of course, missing from the PCID Tracker and the subsequent shipment: https://imgur.com/GBdSkaS

Clearly, this is a support issue and I have reached out to both Epicor and Biscit, but I was hoping someone has some ideas for a workaround in the meantime. This is a huge loss in productivity for us because our shipper has to then sift through and find which one is missing (some of our orders have hundreds of serialized parts) and then re-add it.

The same issue doesn’t occur when the pick is completed in the desktop client, but we just went live with EKW about 2 weeks ago and are trying to avoid rolling back. Our live Epicor and EKW versions are 10.2.400.13 and 3.31.0 but I have tested all the way up through 10.2.700.24 and 3.41.0 and confirmed the problem still exists in those versions.

Thanks!

1 Like
2

Dang, what a weird bug. I would start with a trace of the desktop service to get a feel for how the datasets should look when they flow through the process.

Use 3 serial numbers in your test to keep it simple. Then I would try and make a few bpms to catch where in the process the mobile warehouse app is losing the 3 serial numbers…

at that point I would make some kind of bpm/function variable to pass along the original serial numbers from earlier in the process and then add the missing one in the business object method that seems to be losing them on the mobile warehouse side.

Am I explaining this clearly? This isn’t a technical post, more conceptual.

Let me know if I am not making any sense or if my idea won’t work.

3

Do you have any method directives in the process? I’ve found in different processes if a BPM exists with a condition block as the first step you will lose your first serial number.

3 Likes
4

Very interesting, going to check on this now. Thanks for the suggestion, Doug!

5

In fact, I just got a support ticket about a DMR processing where the SNTran didn’t exist for the rejection that we processed. Sure enough, there’s a conditional statement on the update!

6

What do you know?! I just disabled a BPM that checks for overpicks and underpicks and the problem has seemingly disappeared. I am going to implement the custom code block as you suggested in the post above and monitor to see if this completely solves the problem. You’re a legend, Doug! Thanks!

1 Like
7

Wow, nice @Doug.C !