Quoting a Product With No Routing Yet in EDGEBIC

A quote simulation in EDGEBIC needs a routing to schedule, so quoting a product with no routing stops before it can return a date or a cost. In EDGEBIC by User Solutions, the promise date comes from placing the routing's operations into your shop's real capacity, and material and labor cost come from those same steps. With no routing, there is nothing to schedule and nothing to price, so the simulation reports that no routing was found. The honest fix is not a workaround: it is to build even a rough routing first, so the engine has real work to plan.

Why the routing is the input, not an option

It helps to see why the routing is not optional. When you simulate a quote, EDGEBIC creates a temporary job for the product and quantity, then runs the live scheduling engine to place that job's operations into the capacity your shop has left after every committed order. The output is a start date, an end date, and the work hours the job consumed.

Every part of that output depends on the routing. The operations tell the engine which work centers to schedule and in what sequence. The setup and per-unit times tell it how long each step takes. The work centers tell it whose capacity the job competes for. Strip the routing away and the engine has no steps to place, no times to add up, and no work centers to queue behind. There is simply no simulation to run.

This is the same finite capacity logic that plans your real production, borrowed for the quote. A routing is the price of admission to a capacity-aware answer, and it is what separates a real promise date from a lead-time rule of thumb.

What you see when the routing is missing

Try to simulate a product with no routing and the run stops cleanly with a message that no bill of routing was found for the product. The simulation returns no success, no date, and no cost, and it leaves nothing behind, because the temporary job is always cleaned up whether the run succeeds or fails.

This is a good failure. A quoting tool that invented a date for a product it cannot schedule would be worse than useless. EDGEBIC declines to guess and tells you exactly what is missing, so you fix the input rather than send a fictional promise.

The fix: build a routing you can schedule

The path forward is to give the product a routing, even a rough one. For a brand-new part that has never been made, that means capturing your best engineering estimate: the operations you expect, the work centers they will run on, and approximate setup and per-unit times.

A skeleton routing is enough to produce a real answer. Three approximate steps let the simulation schedule the job against your current backlog and return a start and end date that already account for the shop's load, plus a cost built from those hours. Mark the quote as based on a preliminary routing, widen the window slightly to cover the uncertainty, and you have a defensible number today. As the real process firms up, refine the routing and re-simulate; the estimate sharpens the moment the routing does.

The principle worth holding onto: a rough routing the engine can schedule beats a precise spreadsheet the engine cannot see. Only the first one produces a date the shop can keep.

The cost side needs the routing too

The routing does more than produce a date. It is where the cost comes from. Labor is each work center's work hours times its rate, and those hours only exist because the routing's steps generated them. Material comes from material-type routing steps, or falls back to the product's unit cost times quantity.

A product with no routing has no labor at all, and only the unit-cost material fallback would apply, which prices just the end product's own cost and misses everything inside it. So even if a date were somehow produced, the cost would be hollow. Building the routing fixes both halves of the quote at once. The full cost mechanics are in pricing a quote from the schedule.

When routings should have come across but did not

A common version of this problem is not a brand-new part at all. It is a product imported from an ERP or spreadsheet whose routing steps were left behind. The item master arrives, the product exists, and every attempt to simulate it stops with a no-routing message.

The fix is to bring the routing data across alongside the products. EDGEBIC's import masks map routings from a spreadsheet or database extract, so the operations, work centers, and times land with each item rather than the product arriving as an empty shell. Once the routings are in, the same products simulate normally. This is import-and-map, not a native connector, and it is covered in the ERP integration approach. Until the steps are present, an imported product with no routing behaves exactly like a new part that was never routed.

Sub-assemblies still need their own routings

One nuance for multi-level products: if the quoted product is built from sub-assemblies, each sub-assembly needs its own routing too, because the simulation rolls the child routings' hours, labor, and material up into the parent quote. A parent routing that references a sub-assembly with no routing of its own will under-report, reading close to zero hours for the work that actually lives in the child. Route the sub-assemblies as well, and the rollup prices the whole product correctly. The mechanics are in quoting products with sub-assemblies.

The takeaway

Quoting a product with no routing does not fail silently or produce a fake number. The simulation stops, tells you the routing is missing, and cleans up after itself, because a capacity-aware date and an honest cost both depend on real steps to schedule and price. Build even a skeleton routing for a new part, import routings alongside products from an ERP, and route sub-assemblies so the rollup is complete. A rough routing the engine can schedule is worth far more than a precise guess it cannot see. Start with the EDGEBIC quoting guide, see how the schedule becomes a price in pricing a quote from the schedule, and see the platform in full on the EDGEBIC overview.