How EDGEBIC Turns a Quote Into a Promise Date You Can Keep

Realistic delivery date quoting works only when the date comes from the same engine that runs the shop. In EDGEBIC by User Solutions, a quote's promise date is produced by scheduling a temporary version of the job against your live capacity picture and then throwing it away. This post follows that path in detail: what gets built, what the engine loads, what the returned date includes, and what carries onto the real order at conversion.

For the concept, read quote simulation explained. For the hands-on version, read how to create a quote. Everything here describes documented behavior of EDGEBIC.

Stage 1: Pre-Flight

Before anything is built, the simulation validates. The product must resolve, the quantity must be greater than zero, and the product must have a routing.

That last check is the one that fires most often, and it fails cleanly: the quote returns a message saying no routing was found rather than throwing an error or, worse, returning a plausible date built on nothing. A product with no routing has no work content, and a promise date derived from no work content would be a guess dressed as arithmetic.

Stage 2: The Temporary Job Is Built, Direction-Aware

The simulation needs a real job for the engine to schedule, so it builds a temporary one carrying the quoted product, the quoted quantity, and dates derived from the quote.

The date construction is where the quote's scheduling direction does its work, and it is asymmetric on purpose.

Forward. The quote's target date is the job's target start and its earliest start. The simulation begins there and reports where the work lands.

Backward. The quote's target date becomes the job's due date, and the earliest-start floor is set to today rather than to the target date. The target start is deliberately left unset.

Both of those backward details prevent a specific failure. If the floor were set to the target date, the earliest possible start would equal the deadline, and the engine's own feasibility pre-check would immediately conclude the backward plan cannot fit, forcing a forward fallback on every single backward simulation. And if a target start were set, the job would be promoted to an anchored job, and anchoring outranks backward direction entirely, so the quote would silently stop being backward.

In both directions, the quote's target date also becomes the temporary job's due date. That triple duty (target start in forward, finish-by in backward, due date in both) is the reason the quote dialog labels the field carefully and the reason direction has to be a deliberate choice rather than a default nobody looks at.

Stage 3: The Engine Runs on the Real Picture

The temporary job is handed to the finite capacity engine, which loads the same inputs a real scheduling run loads:

• Work centers, with their capacity, instances, and rates.
• Products and their routings.
• Existing production schedules, so current load is respected.
• Plant holidays.
• Setup-time data, so changeovers cost what they really cost.

One filter matters: any leftover temporary quote jobs are excluded from the existing-schedules picture, so one simulation can never contaminate the next.

The engine then runs on a background thread. It differs from a production scheduling run in exactly one respect, which is that nothing is written to the schedule tables. Your Gantt, your work-center load, and every committed job are untouched. When the run finishes, the temporary job is deleted, and it is deleted whether the run succeeded, returned nothing, or threw.

Stage 4: The Numbers Are Read

Three readings come out of the resulting schedule, and each one answers a different question.

The window. Start date and end date come from the produced schedule. This is the promise date, and it is a calendar span.

The hours. Total hours are summed from the hours actually allocated to resources, not from the date span. A job that starts Friday afternoon and finishes Monday morning spans roughly 66 clock hours and may hold six hours of work. Costing from the span would overstate labor several times over, which is why the two numbers are reported separately and never substituted for one another.

The cost. Each work center in the result has its hours multiplied by a rate: a per-step routing rate if set, otherwise the work center's own rate. Material-type work centers contribute material cost; the rest contribute labor. When no material-type work center produced a cost, the product's unit cost times the quantity is used as a fallback.

Sub-assembly work is included. When a routing references a sub-assembly product that has its own routing, that routing's hours, labor, and material roll up into the parent recursively, respecting each step's quantity multiplier. The documented topology of a product built from a bracket assembly built in turn from a base plate resolves to 22.5 hours per unit, or 225 hours at a quantity of 10.

Worked Example: A Steel Bracket, 200 Units

Take a bracket with a three step routing: cutting at 0.1 hours per unit with a 0.5 hour setup, drilling at 0.05 per unit with a 0.25 hour setup, and deburring at 0.02 per unit with no setup. Each work center runs 8 hours a day, Monday to Friday, one machine each. Today is July 4, 09:00. The customer wants August 15.

The engine walks the routing in dependency order:

The result: start July 4, end July 9 08:45, a lead time of five days, and 34.75 hours of allocated work.

Read those two numbers together. Thirty-five hours of work took five calendar days, because the deburring step ran past a shift boundary and continued the next morning, and because each step waited for its predecessor. Neither of those is inefficiency. Both are what a promise date has to include.

Costing at $45, $38, and $22 per hour:

At 25% markup that is $8.75 per bracket. Against a requested August 15, the July 9 completion leaves 37 days of margin, and the quote can go out with confidence.

Stage 5: Checking Feasibility Correctly

There is no stored yes-or-no flag on a quote. The comparison is made on demand, and how you make it depends entirely on direction.

On a backward quote, compare the returned end date against the target date. That comparison is meaningful because the target date is the finish-by date. If the end date is on or before it, the plan fits. If it is after it, the backward pass did not fit and the engine fell back to forward, so the comparison catches exactly the case you care about.

On a forward quote, that same comparison is meaningless, because the target date is a start. Compare the end date against the customer's wanted date, which on a forward quote lives outside the quote record, or switch the quote to backward and let the engine answer directly.

This is why the direction field is worth thirty seconds of thought at quote creation. It is not a preference, it is the shape of the question you are asking.

Stage 6: Conversion Carries the Plan Forward

When the customer accepts, converting the quote creates one manufacturing order. Three guards run first: the quote must not already be converted, no order may already reference it, and the order name must not collide.

The new order carries the product and quantity, the target date as its due date, the simulated window as its target start and planned end, the estimated cost with its labor and material split, the estimated hours, the markup and unit price, and the customer and sales order links.

It also carries the scheduling direction, and that one item is what makes the promise reproducible. A backward quote becomes a backward order, so the real scheduling run right-aligns the same way the simulation did rather than pushing the work as early as possible. The direction holds unless an anchored target date, recorded actuals, or planner-pinned step dates force forward, which are the documented precedence rules. Backward scheduling in EDGEBIC covers that precedence in full.

Carrying the cost fields matters for a different reason: once actuals arrive from the shop floor, quoted hours and actual hours sit side by side on the quote. That column is the feedback loop that makes the next quote better. An empty right-hand side means no actuals yet rather than zero hours.

The order is created, not scheduled. It joins the calendar at the next scheduling run. Quote to ship in EDGEBIC follows one order through that whole journey.

The Feedback Loop That Improves the Next Quote

Carrying the estimate onto the order is not bookkeeping. It creates the only comparison that makes quoting better over time.

Once actuals arrive from the shop floor, the quote shows quoted hours next to actual hours. An empty right-hand side means no actuals yet rather than zero, which is a deliberate distinction: a zero would read as a job that took no time.

Two divergence patterns are worth naming, because they point at different fixes.

Hours diverge, dates hold. The routing is wrong. Setup or run times on one or more steps do not match what the shop actually does, and every future quote for that product inherits the same error. Fix the routing, not the quote.

Hours hold, dates slip. The routing is right and capacity was consumed after the simulation ran. That is a commercial process issue rather than a data one: the quote sat too long, or too much was promised into the same week. Re-simulate closer to commitment and convert promptly.

Reading that column monthly, across the jobs that completed, turns quoting from a fixed estimating standard into something that gets measurably more accurate. It is the same discipline as tracking quoted versus actual lead time, applied at the routing level.

What the Date Does Not Include

Three limits, stated plainly.

No capacity is held. EDGEBIC provides quote simulation and what-if promise dates. It has no capacity reservation mechanism. Two quotes simulated the same morning both see the same free hours because neither consumed any. When both convert, the second queues behind the first.

It is a snapshot. The date reflects the shop at the moment you simulated. The quote view raises a banner when rates or capacity have changed since, and the default 30 day expiry exists because a stale simulation is fiction.

A concurrent scheduling run can blur it. The simulation reads current database state to rebuild the capacity picture. If a real scheduling run is committing at that exact moment, the simulation may see partially committed state. Simulations are fast and the overlap is rare, but for a high-value promise it is worth simulating when the shop is not mid-run.

Where to Go Next

• What-if scenarios explained covers what to do when the base date misses the customer's date.
• Quoting mistakes lists the configuration errors that make a promise date wrong.
• The quoting pillar is the full workflow, and what is production scheduling covers the underlying discipline.
• The EDGEBIC complete guide maps the platform.