A Make-to-Stock Replenishment Cycle in EDGEBIC, Step by Step

Make to stock replenishment scheduling is a loop, not an event: project the balance, catch the breach early, firm a build order, schedule it against real capacity, and let the completion receipt restore the stock. This walkthrough follows one stocked product through that entire loop in EDGEBIC by User Solutions, with every quantity and every ledger entry shown. It is part of our worked examples series, and it describes EDGEBIC's inventory planning capability the same way the rest of the series treats scheduling: numbers first.

The product is a standard bracket, BRACKET-STD, and its planning policy is the whole story in nine fields:

Demand is a simple forecast: 40 pieces expected the week of June 15, and 55 the week of June 22. Today is Saturday, June 13. On hand (60) is above safety stock (50), so nothing looks wrong if you only glance at the shelf. The projection says otherwise.

Stage 1: The Projection Catches the Breach Before It Happens

The planner opens the inventory calendar for BRACKET-STD, set to four weekly buckets. The system rolls the projected available balance forward: each week's opening stock, plus scheduled receipts, minus that week's demand.

Week one ends at 20, already under the 50-piece safety stock, and week two goes 35 pieces negative: a genuine projected stockout. The first breached week lights up red, and the projected stockout date reads June 13.

The suggestion column deserves a close look, because the arithmetic is exactly the kind of thing a planner should be able to verify by hand. The replenishment target is reorder point plus one reorder quantity: 80 + 200 = 280. Week one's projected balance is 20, so the raw need is 280 minus 20 = 260. The product uses a fixed order quantity of 200, and 260 does not fit in one lot, so the system rounds up to two lots: 400 suggested. A suggestion is advice, though. In this walkthrough the planner firms a single lot of 200, accepting that week one will dip briefly because the build will complete before the deeper week-two demand lands. Both choices are legitimate; the point is that the math behind the recommendation is visible, not buried.

Stage 2: One Click Turns the Suggestion Into a Build Order

In the suggestion row the planner types 200 and clicks Firm. One manufacturing order appears:

• An auto-generated replenishment job number tied to the product.
• Quantity 200, due June 20, start date June 15 (due date minus the 5-day lead time).
• Flagged build-to-inventory, with its demand source recorded as replenishment.

Nothing else changes. The inventory ledger is untouched, on hand is still 60, and no machine time is reserved yet. Firming is a planning commitment, not a physical one, and the system keeps those layers separate on purpose.

The projection refreshes immediately and shows why the planner can now relax:

The 200-piece receipt lands in the June 20 bucket (the order's due date, since it has no schedule yet), and weeks two through four turn healthy. Week one still shows its dip to 20, which the planner accepts knowingly: the build is due before the big demand hits.

Stage 3: The Build Order Competes for Real Press Time

Next the planner runs Generate Schedule. This is where make to stock replenishment scheduling differs from a spreadsheet reorder report: the build order goes through the same finite capacity engine as every customer order, on the same calendar, against the same machines. If you are new to why that matters, the primer on finite versus infinite capacity scheduling is the background.

Two details of engine behavior are worth knowing:

1. Producers schedule before consumers. Because this order builds stock rather than consuming it, the engine sorts it ahead of any order for the same product that might want to be satisfied from stock. A stock-builder never eats its own output.
2. A build order never nets itself from stock. The engine's consume-from-stock shortcut applies to demand orders; a build-to-inventory order always runs its routing.

The workload is 0.5 hours of setup plus 200 x 0.02 = 4.0 hours of run time: 4.5 hours total. PRESS-1 has 8 free hours on Monday, June 15, so the engine places one clean block:

The order flips to scheduled with those dates. And here is a subtle, satisfying knock-on: the projection now knows the build completes June 15, which falls in the first week, not the second. The scheduled receipt migrates from the June 20 bucket into the June 13 bucket, and even week one's dip disappears:

The whole four-week horizon is now above safety stock. Still no ledger movement; on hand remains 60 until parts physically exist.

Stage 4: The Floor Runs It, Five Minutes Early

On Monday morning the press operator opens the shop-floor kiosk, taps Start at 08:00, and taps Complete at 12:25. The operation records its actual start and end alongside the planned times, and the operation's status computes to Completed. The order itself stays open: confirming that 200 good pieces exist is a supervisor decision, not a punch. The kiosk workflow is the same one used for customer jobs in the quote-to-ship walkthrough.

Stage 5: Completion Posts the Receipt That Restores Stock

The supervisor selects the order and clicks Mark Complete. Three things happen in sequence, and the sequence is the audit story:

1. The order's status flips to Completed with the date and the supervisor's name, and an audit row lands in the schedule change log.
2. Because the product is stocked and the order is build-to-inventory, the system posts a receipt of +200 to the inventory ledger, commented "Build to Inventory," tied to the order, at $4.50 unit cost.
3. The on-hand cache updates to 260, and the moving average cost recalculates (unchanged here at $4.50, since the receipt cost matches the existing cost).

The ledger now reads like a bank statement, which is exactly the intent:

The receipt posting is also deliberately idempotent: if the completion is retried after a hiccup, the system sees an active receipt already exists for this order and refuses to post it twice. No double-counted stock.

Stage 6: The Loop Closes

The receipt triggers a projection refresh. The completed order no longer appears as a planned receipt; instead the +200 shows as an actual ledger movement in week one. Projected balance: 220, 165, 165, 165 across the four weeks. Suggested builds: zero everywhere. Days of cover work out to roughly 38 days at the forecast rate. The safety-stock breach that started this story is gone, and every step of its resolution is reconstructable from the ledger, the order, the schedule, and the change log.

Variations Worth Trying

Scrap-adjusted lots. Set the product's yield to 90 percent and the same 200-piece suggestion inflates to 223 (200 divided by 0.9, rounded up), because the system plans for what survives inspection, not what starts. Press time grows to 4.96 hours, still one shift.

Min-max instead of reorder point. Switch the reorder method to min-max with a minimum of 60 and maximum of 300, and the trigger and target change: the suggestion becomes the quantity that refills to the maximum, rounded up to whole lots.

A rejected batch. QC finds a material defect after completion. Reopening the order posts a reversal: the +200 receipt is flagged as reversed, a matching -200 entry is added, and on hand returns to 60. Five ledger rows now exist and all five stay forever. History is appended, never edited.

Forward netting with a customer order. Add a 150-piece make-to-order demand for the same bracket dated one day after the build completes. With forward netting active, the engine sees 260 available by that date, satisfies the customer order entirely from stock, consumes zero press hours for it, and posts a -150 issue at persist time. On hand after both: 110. Stock building and stock consuming reconcile inside one scheduling run. When the two also compete for the same machine rather than only the same stock, a stock build and a customer order sharing one laser follows both routings to the end.

Why Run Replenishment Through the Scheduler at All?

Plenty of shops run reorder reports in a spreadsheet and toss build orders over the wall. The cost of that habit is invisible until the press is busy: a reorder report assumes capacity, while make to stock replenishment scheduling in EDGEBIC proves it. The 4.5-hour press block in this walkthrough occupied real capacity that a customer order could not silently double-book, and the projection updated from the scheduled completion date rather than a hopeful lead-time offset. That is the same finite-capacity honesty User Solutions has built scheduling tools around since 1991, for manufacturers from Cummins (33 locations) to BAE Systems. If your forecasts and item policies live in an ERP today, the import-export masks bring them across from Excel, CSV, or database extracts without retyping.

Want to see your own reorder policies projected this way? Contact US with one stocked item's history and we will walk the loop with your numbers.