All parts are average costed. At times there are delays in receiving (can’t resolve, have tried) yet urgency to ship. When the shipment occurs before the receipt, costs are wrong. The path of least resistance is to, when shipping, create the pack and physically ship it, but don’t mark shipped on the pack until later when the receipt and costs have been verified.
BUT
This is impossible because when you create the pack and leave it open, it allocates inventory. Yes its really true, PartAlloc.PickedQty gets updated whenever you add a line to a pack (if you are licensed for AMM), and then when you try to create another pack for the same part, you get an error that there is not enough unallocated inventory. Its logically absurd because when your part class is marked to allow negative inventory, and you have zero on hand inventory, you can create as many packs as you want with no block. But if you have even 1 pc in stock that gets allocated, then you can’t create any further packs for that part. Makes zero sense. Yes I have already created an idea about it.
Back to my immediate problem. I have traced this and the error is generated by CustShipSvc/UpdateMaster. I don’t think there is anything I can do inside there to make it stop caring about the allocation, but my idea is to put an in transaction directive on PartAlloc that sets the PickedQty field back to 0 whenever it tries to update the allocated qty. I would need to figure out how to make sure this fires only when the allocation is occurring from customer shipment entry and not from fulfillment workbench. Is this a terrible idea? What unanticipated havoc will this unleash? Is there a better solution?
Do you have ‘Unpack to Picked Status’ set to true?
I wonder if this may be causing your auto-allocation when you create a pack. We (unfortunately) process some of our orders outside of the FWB workflow and we don’t run into this issue.
Also is the ‘not enough unallocated inventory’ a hard stop or just a warning you can bypass?
Had a similar problem with Allocated Stock and Transfer Orders ended up raising the Transfer Orders with a Bin that held no stock and then moving the stock when picked (or when Bin went negative if they forgot to Pick!!)
We have the same issue as we have to book our transport upto 48 hours in advance and sometimes we are still finishing off production. The workaround suggested to us was to create a different bin in the same warehouse and to use that on the Pack Slip, however we still have to transfer inventory from one to the other when the parts are actually booked in to prevent negatives.
Can I ask why is this is an issue ? Or rather what issue is it causing? If its average costing the receipt of one shipment isn’t going to sway the average that much no? Isn’t that the point of average to smooth out the peaks and valleys?
If there is no inventory and zero cost and you ship the order, it goes out with $0 cogs. If you then receive it from the PO, the avg cost updates to the PO cost (ok) BUT if you then reverse your shipment to try to fix the cost, it averages the $0 inventory in with your real cost, which makes your cost wrong again.
If you have negative inventory but the cost already exists on the part and/or your average cost is pretty stable, its less of an issue.
