@BKen - one word of caution: you might want it to be a warning or something they can override. I had a recent client do exactly this (stop overshipping) and they ran into issues when there was a difference between their customer’s order UOM and their inventory UOM.
For example, they might stock a part in EA. The customer orders in FT. When they go to ship, the conversion shows them shipping slightly over the order quantity because of UOM conversion so the shipment would be stopped.
Jeff,
Good point. I have played around with Raise Exception or Show Message. We do not use different UOMs, so I think we may be OK. How did your client determine the quantity previously shipped (linked to the SO Line)?
Brian - off the top of my head I believe there was a Remaining Qty field on the shipment entry screen.
There is a remaining quantity, but it is based on the order release, not the order line and it does not show negative (so IMO it is not correct). Also, this is NOT a database field.
I have never tackled shipping (no one has asked me to), but I did block over-receiving and perhaps some of that can help:
But you’re right, you have several additional challenges that I did not. But you might use a similar trick for summing the total shipped qty, for example.
Mostly, though, I want to say this: I think this plan has some negative consequences.
So, the way I understand it, order is for, say 15 EA on 3 releases (5 per), and rather than ship the same thing 3 times on the same pack slip, your people ship 15 against only one of the releases.
Problem is that there are still 2 open releases creating demand and showing in Time Phase.
This is why we force our receiving people to never over-receive (at the release level). We (and the ERP) think there is still outstanding PO qty, when the supplier has no intent of ever sending more on that PO.
Conversely, you are possibly thwarting your customer’s efforts to separate these out into releases. I imagine there was some reason they didn’t order 15 on one line…
It always strikes me as odd, though, that there is no AR equivalent to the AP 3-part match. It’s not as important for shipping?
EDIT: I clarified this thought 
. I mean that our users cannot over-receive any PO release.
Jason,
The way you understand it is close. We will sometimes have multiple releases if we have enough quantity on hand to supply only a portion of what the customer wants to order. Many customer’s want to get what they can and will wait for the remaining quantity to be produced (or purchased). If the part sales department determines that we have 3 pieces available and the customer is requesting 10 pieces, the part sales department will create 2 releases on the line, release 1 would be for 7 pieces back-ordered, and release 2 would for be for the 3 pieces Epicor shows we have on hand.
The real issue is fat fingering on the Handheld for the picking process (Epicor Mobile Wireless Warehouse). It I could create a popup or an exception on the Handheld, to prevent picking more than the Sales Order Release is Requesting, this issue would be resolved. But, I don’t know how to run a trace on the handheld, so I do not know which business objects are firing when the Reserved/Allocated items get picked on the handheld. Is that even possible?
Well, I don’t know about tracing the handheld, so hopefully someone does and can chime in.
But isn’t picking just part of the Material Queue? I think it’s a STK-SHP transaction? Can you take a swing at it in the regular client with the Queue?
Something else to consider. This problem only affects certain types of companies…
SO… if you are trying to make a BPM that validates the total shipped, you need to also search for any open/unshipped Packslips to make sure that you haven’t doubled up things.
Tim,
That was why I was trying to find a way to capture the display data on the Order Line for Shipped Quantity (OrderDtl.TotalShipped), but it is not a database field, so I am not sure how to capture that detail in order to verify a condition.
If you used the fulfillment workbench process you would not have an issue. Allocated what is available, then you can only pick what is allocated and you can only ship what is picked. much cleaner.
I don’t disagree with the statement (TBH I wouldn’t know enough to disagree anyway), but I have a hard time understanding why FWB is necessary for picking. Meaning a STK-SHP transaction is literally impossible without the help of FWB, right? And that’s not true of other transactions. I can do STK-STK or STK-MTL without ever opening FWB (we went years without ever using FWB).
I suppose this is a tangent/rant, but I cannot see why picking cannot have its own Business Objects like the others do. This obstructs a lot of programming efforts that could be much simpler - or what is it I am missing that FWB is critical for?
Terry,
We do use FW, but we are also paying for EMWW. So we take the sales order and reserve and allocate per the SO Line/Release (yes, the quantity matches the Sales Order). Then our pickers look at the material queue on the handheld and they have to manually enter the quantity picked (and on the hand held, the keyboard pops up and blocks the entry location, so it is easy to fat finger the quantity incorrectly because you do not see the entry location) and then the hand held process the incorrect quantity without any popup message or warning. That is the heart of the issue.
Here is what we see on the Material Queue on the handheld:
The picker selects the item, then the item goes to the My Material Queue tab (the picker moves to the My Material queue tab and selects the item):
After that, the shipper goes to Customer Shipment Entry, Actions - Picked Orders, and grabs the item that has been picked. Once it is Picked, it ignores what was reserved and allocated and only looks at the quantity picked and allows you to ship what was picked in quantities greater than requested.
So how do I stop Over-Picking?
Can you use the scan incrementor in this case so that they have to scan a barcode to increment the quantity rather than type it in?
Frustrating that the keyboard behaves like that.
Utah,
That is not a bad idea, but not all parts are barcoded, and if we are shipping 100 pieces, counting would be much more efficient than scanning 100 pieces.
No doubt, I didn’t know the nature of your product, but yeah that would be unbearable 
something go split, sorry I posted on the wrong thread.
@BKen there is a setting in the shipping section of the app that says, “Over Packing Control Mode” and then they have: Stop, Warn, None as options.
Does that not trigger in this situation if you chose “Stop?”
Utah,
Nope, that did not do it. …but it got me looking around (so thank you SO much for pointing me in the right direction).
Under settings, Issues and Return (settings), you see the following screens:
Now, when I try to over pick I get this:
So user error on my part. I am marking this one solved and will give Utah credit.
@BKen Would the set quantity to remaining fill in the amount? And if it did would that speed up the process and not cause issues?
Greg,
Yes this would speed up the process. You get Extra-Credit. If that quantity is not correct, the picker could always click in the box and change it. Thank you.
You could try server tracing and enable the trace flag for api calls.
<add uri="trace://ice/fw/restapi" />