@ElectricalAccess
Finally chased down the root issues here. Going to attempt to provide the full background below, and also the steps Electrical Accessories needs to take to fix this and make sure it doesn’t happen again.
First, what changed between v3.8 and v.3.9 was there was actually a bona fide bug in how PartRequests informed demand in the Waterfall.
Note that a Part Request by definition means you are requesting MORE parts from inventory than what is merely required by the work order BOM Qty. So, if you had BOMABC with a component RAW123 qty per top of 2, and then you had an order for Qty 10. That would create work order demand for Qty 20 of part RAW123. The PartRequest module exists for the situation when, for whatever reason, you end up realizing (due to scrap or some reason) you actually are going to need and consume two extra beyond Qty 20, for a total of Qty 22. So you would issue a part request for Qty 2 extra.
When that part request is created, that is a request for an extra two parts from inventory, in other words it is demand for that part to get used somehow someway (e.g. picked and used on a work order). Thus the waterfall demand should increase from Qty 20 demand of RAW123 up to Qty 22.
Previously, in version 3.8, waterfall wasn’t showing an approved part request as demand, which was incorrect and a bug. After version 3.9, part requests would correctly show as demand in the waterfall.
One problem ElectricalAccessories may be running into, is that you may be creating part requests, and then not properly registering the pick of material to the work order pick list to fulfill the PartRequest. Even though the PartRequest increases demand of the material on the waterfall, if you then pick (i.e. overpick) per the Qty being requested for that work order, that overpick and subsequent ship/invoice will fully remove the demand from the waterfall, so that you don’t overbuy.
So, the demand from the part request is getting added to the waterfall (correctly), however the pick for the part request is not getting registered on the work order. This exact situation is happening right now with order 16788.1-3 (https://__________.cetecerp.com/part/1795/waterfall#)
What that means is that, if and when the Part Request is closed and the pick was never registered, you will end up with demand from the Part Request on the waterfall that never had anything corresponding to it to pick/fulfill/ship that part request overage Qty. Thus, the demand on the waterfall will only go away once the order closes/ships.
If this happens, then there are two ways to rectify that situation:
1- you can go to the appropriate work order and overpick the correct Qty onto the work order to register the fulfillment of the part request as the proper Pick on the work order that the parts were sent to. That will have the effect of reducing the net demand on the waterfall once that work order ships/invoices.
In other words, on this pick list for work order 16788.1-3 (https://__________.cetecerp.com/otd/order/53677/pick_parts) - increase the pick qty by Qty 3600 to match the Qty that was requested via this part request (https://______.cetecerp.com/otd/partrequest/28079/edit). Then, do the same for the qty 6 that was requested via this part request (https://.cetecerp.com/otd/partrequest/28084/edit)
2- you can go to the PartRequest itself, re-open the Part Request, set the PartReques to unapproved (i.e. “pending approval”), and then close the Part Request again. Unapproved part requests do not get included in the Waterfall, so that will have the effect of removing the demand from the waterfall.
One final note. It’s possible that you are using the part request module to request parts to pick for work orders’ default BOM qty demand… not for overage/extra demand than anticipated by the BOM order. That is not how the PartRequest module was designed or intended to be used. If that is true, we would recommend changing process to use the “Release To Pick Queues” module to release work orders for picking, not the PartRequests module.
I hope this clears everything up for you, apologies for the confusion.
Thanks
