Why a Quoted Date Can Move in EDGEBIC (and How to Lock It)

A quoted date in EDGEBIC can move because it is a snapshot of live capacity, and EDGEBIC holds no capacity against a quote. In EDGEBIC by User Solutions, the promise date is built by scheduling the quoted job into the real gaps your shop has right now, and those gaps change as new orders land. A quote reads its date and then lets go; nothing is reserved. That is honest and it is exactly why two quotes can both look feasible against the same slot. The way to lock a date is to convert the accepted quote to an order, which commits real capacity around everything already scheduled.

The date is built from a moving floor

Every credible promise date starts the same way: the simulation borrows the live finite capacity scheduling engine and places the quoted job into the capacity left after every committed order. The date it returns is accurate because it accounts for the backlog as it stands.

But the backlog does not stand still. The moment another order is scheduled, or an existing one shifts, the open gaps the quoted job would have used are different. Run the same simulation a week later, on the same routing and quantity, and the job queues behind more work and finishes later. Nothing about the job changed. The shop under it did. A date that moves between two runs is the simulation refusing to pretend the floor froze the day you first quoted.

Quoting reserves nothing

The second reason a quoted date can move is more fundamental: a quote holds no capacity at all. EDGEBIC has no reservation or hold mechanism behind a quote. The simulation creates a temporary, invisible job, schedules it against current capacity to read the dates and costs, and then deletes it. The floor is untouched, which is what lets you simulate freely, but it also means the slot you just quoted against is still fully open.

The consequence is worth stating plainly, because it surprises people: two quotes against the same tight capacity can both come back feasible. Neither one held the slot, so each simulation saw it as available. This is not a defect. It is the direct result of a quote being a plan rather than a booking. Capacity becomes real only when a real order is scheduled.

A worked example of the double-promise

Your bottleneck mill has a two-week opening. On Monday you quote Customer A a job that fits it, and the simulation returns a date inside that window. On Wednesday you quote Customer B a similar job, and because A's quote reserved nothing, the mill still looks open, so B's simulation also returns a date in the same window. Both quotes are green and both look deliverable.

Both customers accept. Now you cannot make both in that slot, because the mill can only run one job at a time. Nothing broke; the quotes were feasible when simulated because neither committed capacity. The fix is procedural, not technical: convert A's quote to an order as soon as it is accepted, so the next scheduling run commits that capacity. Then re-simulate B. It now schedules behind the committed A job and returns an honest, later date you can take back to Customer B before they are blindsided.

How to lock a date: convert, then schedule

If a quote holds nothing, the way to protect its date is to stop it being a quote. Converting an accepted quote creates a manufacturing order carrying the product, quantity, dates, direction, cost, and customer link, and the order then waits for the next scheduling run to place it on the calendar. That scheduling run is where real capacity is committed, around everything already scheduled.

So the sequence that protects a promise is: simulate to build the date, win the order, convert promptly, and let a scheduling run commit the slot. Until you convert, the capacity stays available to any other job, including the next enquiry that walks in. Prompt conversion is not paperwork; it is the mechanism that turns a plan into a booking. The full conversion flow is in how a quote becomes an order, and the sharpest version of the problem, a tight date confirmed by backward scheduling and an expedite priced honestly, is in quoting a rush order.

What to tell a customer sitting on a quote

Because the date is not reserved, the honest thing to tell a customer is that the quote is valid as simulated but the slot is not held. The promise was built against the shop as it stood the day you ran it, no capacity is set aside, and other orders may take that capacity before they commit. If they want the date protected, the way to do it is to accept, so you can convert and schedule.

Framed that way, the truth also does useful work. A customer who understands that waiting risks the slot has a real reason to commit, rather than assuming the date is theirs indefinitely. That is more defensible than a padded date and more effective than a false guarantee.

The snapshot rule and the refresh banner

There is a built-in reminder that a date is a snapshot. When capacity or rates change after you simulate, the quote view shows a banner asking you to refresh and re-run before sending. Following it re-anchors the quote to the current floor, so you are never quoting off a stale plan. This is the same reason quotes carry an expiry, covered in quote expiry dates. A promise date has a shelf life precisely because it can move.

The takeaway

A quoted date can move for two honest reasons: it is a snapshot of a floor that keeps changing, and EDGEBIC reserves no capacity behind a quote. Both are features, not faults, because a date that ignored the backlog or pretended to hold capacity it did not would simply be a nicer lie. Refresh a quote when the banner asks, tell customers the date is valid but not reserved, and convert the moment they commit so a scheduling run locks the slot. That is how a moving date becomes a kept promise. See the full workflow in the EDGEBIC quoting guide, why capacity-based dates beat a fixed rule in why quote against real capacity, and the platform in full on the EDGEBIC overview.