Why the Wheels Came Up 660 Short: Low-Level Codes, Scrap and Effectivity
A manufacturer builds the CT-500 utility cart: four wheels (WH-08), one handle assembly HA-12 (a phantom containing two grips GR-04 and one tube TB-02), plus an in-house paint step. The MRP run for a planned order of 500 carts due in W12 shows wheel gross requirement 2,000, on-hand 350, no scheduled receipts, and a planned order of 1,650. Purchasing says wheel scrap runs about 3%, and there are also 300 dealer service kits SK-01 due in W12, each containing two wheels. WH-08 carries a low-level code of 1 in the item master because it was originally created under the cart. A pending engineering change replaces TB-02 with TB-03 effective W10, but the new item's effectivity date was keyed as 10/01/2027 and the old tube is still on the CT-500 BOM. Separately, the paint step was modeled as phantom PT-01 with a two-day lead time and zero stock; every MRP run creates a planned order for 500 PT-01, and a new planner keeps releasing it and then cancelling the resulting requisitions.
1. Reconstruct the correct wheel requirement for W12 and quantify the error in the current plan. Explain the mechanism behind the gap.
Read the worked answer
Correct gross requirement: carts 500 x 4 = 2,000; add 3% scrap (component scrap applied as a yield uplift) = 2,000 x 1.03 = 2,060; service kits 300 x 2 = 600. Total gross requirement for WH-08 in W12 = 2,660. Less on-hand 350 = 2,310 net, so the planned order should be 2,310, not 1,650. The plan is short by 660 wheels - and the 60-unit scrap allowance is missing on top of that if the netting is done on the discounted figure.
Mechanism: the wheel requirement of 2,000 is exactly 500 x 4, so the quantity-per is right. The missing 600 is the service-kit demand, and that is a low-level code problem. WH-08 is coded level 1 because its first parent was the cart. MRP processes items level by level and nets each item once, when its level is reached. With the wheel at level 1, gross requirements are calculated and netted before SK-01's demand is exploded; the kit's 600 wheels arrive later in the run and generate a second, late, small planned order instead of being consolidated. Correct low-level coding (whichever is deepest - here the kit path, so level 3 or the true deepest level) accumulates all gross requirements before netting.
Also check the scrap convention: some systems use quantity/(1 - scrap%) = 2,062, others multiply by 1.03 = 2,060. Either is acceptable; mixing the two across the item population is not, because nobody can reconcile the plan to actual usage.
2. What should be done about the tube effectivity error, and what is the risk if it is left until the next run?
Read the worked answer
The BOM is planning the obsolete tube. The effectivity date for TB-03 was keyed into the future (2027), so the CT-500 structure still points at TB-02 and MRP continues to release TB-02 orders past the intended W10 cut-in.
Risk chain: continued purchase of a part that is about to be discontinued (or a part that no longer fits), leftover TB-02 stock at the changeover that must be written off or reworked, and a W10-W12 build that cannot be assembled because TB-03 was never bought. The cost is not just scrap - it is a line stoppage at the changeover week, which is the worst possible time.
Actions:
- Correct the effectivity date and run a where-used against TB-02 to find every other parent that shares the error; engineering changes rarely touch one BOM.
- Review open purchase orders and planned orders for TB-02 and cancel or defer them, and check whether any are already in transit.
- Define the cut-in rule: date-based effectivity, or depletion of TB-02 on-hand, or serial-number effectivity. Pick one and document it, because MRP will do exactly what the effectivity field says and nothing more.
- Confirm TB-03 has a validated item master - lead time, lot size, safety stock, source - before it goes live. An item that suddenly appears in a BOM with a default lead time is the next exception flood.
After the fix, re-run MRP and reconcile the change in planned orders before releasing anything.
3. How should the paint step be modeled, and what should be done about the recurring PT-01 planned order?
Read the worked answer
Paint is an operation, not a material. Modeling it as a phantom material with a two-day lead time creates three problems: MRP offsets the cart's components earlier by two days for no valid reason, it creates a planned order that looks actionable, and it invites release/cancel churn that pollutes the exception list and erodes planner trust in the system.
Preferred fix: put paint as a routing operation on CT-500 (or on the painted-body assembly), so capacity is loaded through the routing and no material order exists. If the company genuinely needs a paint subassembly item for tracking or costing, keep it, but then it is a real stocked item with a real lead time and real receipts.
If the phantom structure must stay: mark PT-01 as a phantom, set lead time to zero, and configure it so no planned order can be released or converted to a purchase requisition - phantoms exist to pass demand straight through to their children on the same dates. Then clean up the existing open requisitions and add PT-01 to a short 'do not release' list while the structure is corrected.
Broader point: phantom items are an engineering convenience for grouping components that are always built together, and they should have no stock, no lead time and no independent planning action. Any phantom that generates messages a human must chase is misconfigured.