How Lead Time Offsets a Replenishment Release Date in EDGEBIC
User Solutions TeamA replenishment release date is the need date minus the item's lead time. A build cannot start on the day the units are needed and still finish on time; it has to release earlier by exactly the time it takes to produce. EDGEBIC by User Solutions treats this offset as the core arithmetic of timing a build, and understanding it is the difference between a plan that finishes on schedule and one that is late by precisely the lead time you forgot to subtract. This post explains the offset, shows where it lives in the shipped inventory calendar, and is honest about which part of it is here today and which is on the roadmap.
For the wider planning picture, see the inventory and planning pillar. For how a shortfall becomes a build in the first place, see how a forecast becomes a replenishment suggestion.
Need Date, Release Date, and the Gap Between Them
Two dates matter for any planned build:
- The need date is when finished units must be available.
- The release date is when the build has to start.
The gap between them is the lead time. The arithmetic never changes:
release date = need date − lead time
An item needed by week 10 with a five-day lead time has to release around the end of week 9. Release it on the need date instead and you finish five days late, guaranteed, before a single capacity constraint is even considered. The lead-time offset is the safety margin you build into the timing so the units are ready when demand arrives.
Where the Offset Lives Today
When the inventory calendar projects a stocked product's balance forward and it dips below the reorder trigger, EDGEBIC computes a suggested quantity for the shortfall bucket. Firming that suggestion creates a build order, and at that moment you set its suggested start. The natural start is the need date minus the lead time, so the build finishes by the bucket it is meant to cover.
From there the finite scheduler takes over. It places the build across the work center's shifts, respects capacity and instance limits, and returns a real start and finish. This is the important guardrail: the lead time is a planning estimate, but the scheduler tests it against actual capacity. If the shop is full, the real finish can land later than the lead time promised, and the scheduler shows that slip before you commit rather than after the customer is expecting delivery.
A Worked Offset
Take an assembly needed by week 10, quantity 100, with a two-day assembly lead time.
| Item | Need date | Lead time | Release date |
|---|---|---|---|
| Assembly | Week 10 | 2 days | Week 9, Thursday |
You firm the replenishment with a suggested start near week 9 Thursday. The scheduler allocates it, say, to the assembly work center on the day shift Monday through Wednesday of week 9 and returns a finish inside the week 10 window. The commit is valid. Had assembly capacity been full, the scheduler would have slid the finish and surfaced the miss, letting you expedite, split, or re-time before anyone is promised the wrong date.
The Multi-Level Cascade Is Roadmap
The offset above times one item. Real material planning cascades it down a bill of materials: a parent's release date becomes the need date for each component, and each component offsets by its own lead time. A table needed in week 10 with a two-day assembly lead time releases in week 9; its tabletop, with a three-day make lead time, needs to release earlier still; its purchased legs, with a five-day supplier lead time, need to be ordered earlier again.
That automatic cascade is on the MRP roadmap, not shipped. There is no multi-level bill explosion that walks a product tree and offsets every component by its lead time, and there is no purchasing module to raise a requisition for a bought part. What is here today is single-item planning: you plan each stocked item, watch its projected balance, and time its build with the release-equals-need-minus-lead-time arithmetic. The cascade across a full bill is future work. For the honest map of what is shipped versus planned, see what EDGEBIC does today vs the MRP roadmap.
Why This Matters at Finite Capacity
Lead time on its own is an infinite-capacity assumption: it says "this takes N days" without asking whether the machine is free. That is exactly why the offset feeds a finite scheduler rather than standing as the final answer. The offset gets the release date into the right neighborhood; the scheduler decides whether the neighborhood is achievable. The difference between planning at infinite capacity and scheduling at finite capacity is covered in finite versus infinite capacity scheduling.
Get the offset right and your builds release early enough to finish on time. Get it wrong and every plan is late by the amount you failed to subtract. The arithmetic is simple, but it is the hinge the whole timing of a replenishment turns on.
Expert Q&A: Deep Dive
Q: Our assembly has a two-day lead time and the customer needs 100 units by week 10. When should the build release, and what does EDGEBIC do with that?
A: Release date equals need date minus lead time, so week 10 minus two days puts the release near the end of week 9. When you firm the replenishment for that item, you set the suggested start around that date, and the finite scheduler allocates it across the assembly work center's shifts and returns a real finish date. If capacity is tight and the real finish lands in week 10 or later, the scheduler surfaces the slip before you commit, which is the point of scheduling at finite capacity rather than trusting the lead time blindly.
Q: Legs for our table are purchased with a five-day lead time. Can EDGEBIC time that purchase from the table's due date automatically?
A: Not automatically across the bill today. The arithmetic is clear, week 10 need minus five days puts the purchase release near week 8, but the automatic cascade from a parent's release date down to each purchased component is roadmap, and there is no purchasing module shipped to raise the requisition. In current practice you plan the purchased item as its own stocked line, watch its projected balance, and release replenishment against it. The multi-level explosion that would time it from the parent is future work on the MRP roadmap.
Frequently Asked Questions
Ready to Transform Your Production Scheduling?
User Solutions has been helping manufacturers optimize their production schedules for over 35 years. One-time license, 5-day implementation.
User Solutions Team
Manufacturing Software Experts
User Solutions has been developing production planning and scheduling software for manufacturers since 1991. Our team combines 35+ years of manufacturing software expertise with deep industry knowledge to help factories optimize their operations.
Share this article
Related Articles
How to Add a Supplier and Raise a Purchase Order in EDGEBIC
The Purchasing sub-tab in four moves: create the supplier, raise the order header, add lines with a promised date, and set the one status that decides whether the scheduler believes any of it.
What Stock a Job Actually Drew From Inventory in EDGEBIC
A hidden window in Job View shows exactly what a job took from stock, and whether it was finished product that skipped the shop or components drawn to build it. The only way in is a double-click.
Exploding a Parent's Demand Into Component Demand in EDGEBIC
How a planned order becomes requirements on its components: quantity-per, why the explosion dates at the parent's release, and why it explodes the quantity you will actually start.