Quoting a Multi-Item Order in EDGEBIC: One Quote per Line, Held Together by the Sales Order

A quote in EDGEBIC names one product. A customer PO usually names five. That mismatch is not a gap so much as a design choice, and working with it rather than against it produces a package quote that is easier to negotiate, easier to partially accept, and easier to convert.

EDGEBIC by User Solutions holds the lines together through the customer and sales order links rather than inside a single record. This post covers the method, the arithmetic for a package price and date, the one place where summing the lines genuinely misleads you, and what you assemble by hand. It sits under the EDGEBIC quoting guide.

Why a quote holds one product

The quote's central field is Product (BOR), and the reason is the simulation. When you click Simulate, the engine builds a temporary job for that product and that quantity, schedules its routing against your real current capacity, reads off the dates and the allocated work hours, prices them, and deletes the temporary job. That machinery is built around one routing.

So a five-line enquiry becomes five quotes. Three fields are what turn those five rows back into a package:

Set all three the same on every line and the grid's filters will bring the package back as a set whenever you need it. The full linking mechanics are in linking a quote to a customer and sales order.

Simulating the set

You do not simulate five quotes one at a time. Tick the Select checkbox on the rows you want and click Simulate, and the run covers all of them. If nothing is ticked, Simulate runs on every not-yet-simulated quote in the current filter, which is why filtering to the customer first is a good habit before you press it.

Each row then fills in Start Date, End Date, Est. Hours, Est. Cost, Profit, and Margin against the load you have right now.

Reading the package numbers

Take a three-line enquiry from Acme on PO ACME-PO-4471. The first line is the documented Widget-A simulation; the other two are computed on the same documented routings and rates, with illustrative dates.

Four things to read from that.

The package price is a sum. $21,350 across the three lines.

The package cost is a sum. $11,900, which is labor plus material only on every line, with no overhead component anywhere in it.

The package margin is computed, not displayed. Profit is $21,350 minus $11,900, so $9,450, and margin is $9,450 over $21,350, which is 44.3 percent. The grid paints a margin color per line. It does not paint one for the package, so this is your arithmetic. It is worth doing, because a package can sit comfortably green while one line inside it is amber and quietly funded by the others.

The package date is the maximum, not the sum and not the largest line. August 20, and notice that it comes from the 40-piece line rather than the 200-piece one. A small item behind a booked machine routinely finishes after a large item that had a clear run. Anyone eyeballing the biggest line for the delivery date will get this wrong regularly.

The one place the sum misleads

Here is the check that separates a package quote you can defend from one you cannot.

Every line was simulated independently against the same picture of current load, and a quote reserves nothing. When line one was simulated, lines two and three did not exist. When line three was simulated, line one still did not exist. All three were told the same machines were free.

In the example above, all three lines route through CNC-Mill-1. Line one alone puts 101 hours on that mill. The August 20 package date was computed as though those hours were not there for the other two lines, so it is a floor rather than a forecast.

Three ways to handle it, in increasing order of effort:

Stagger the target start dates. Each quote has its own Target Start Date, which on a forward quote is where the simulation begins. Setting them to reflect the order you would actually run the lines approximates the sequencing, and the resulting dates are noticeably more honest than three simulations all starting the same morning.

Identify the shared machine and add allowance on that line only. You do not need to pad the whole package. Only the lines competing for the same work center are understated, and usually only one machine is doing the damage.

Re-check after conversion. Once the lines are real orders, a Drive Schedule run plans them against each other properly, and the resulting dates are the ones production will work to. Building in a short gap between accepting the order and confirming the acknowledgment date is a cheap habit that catches this.

Scenarios do not solve it, and it is worth saying so plainly: scenarios belong to one parent quote and the comparison charts compare siblings only, so there is no way to model the three lines competing as a block. The wider version of this behavior is covered in why a quoted date can move.

Sending, accepting, and converting

Sending. The Send action produces the quote summary for the rows you have checked, so the package can go out together. Consolidating those into one customer-facing document with a package total and a single delivery date is yours to do, and the total and date you use are the ones computed above.

Partial acceptance. This is where one quote per line earns its keep. A customer taking three of five lines means converting three and setting two to Rejected. Nothing has to be unpicked, and the two rejected lines keep their simulated numbers for reference.

Converting. Tick the accepted rows and use Convert All. Already-converted rows are skipped automatically, and you get one Manufacturing Order per quote, each named MO followed by the quote number, each carrying its product, quantity, dates, cost estimate, markup, unit price, scheduling direction, and customer link. Conversion is one-way and guarded, so a quote cannot produce a second order.

Managing them afterward. The orders arrive as separate jobs. Grouping them by their shared sales order is how they stay a package on the production side too, which is covered in how to group orders by sales order.

Housekeeping worth doing on a package

Keep the expiry dates aligned. They default to 30 days from the quote date. Lines with different expiry dates on the same PO produce an awkward conversation when the customer accepts in week five.

Watch the refresh banner. If work center rates or capacity change after simulation, the quote view warns that estimates are stale. On a package that means re-simulating the whole set, not the one line you happened to open.

Re-simulate the set together after any line changes. A quantity change on one line does not alter the others' stored numbers, but it does alter the real competition between them, so the package date deserves another look.

Check the per-line margin colors, not just the package. Green above 20 percent, amber above 10, red when negative. A package average can conceal a line you are losing money on, and finding that after conversion is expensive.

For the broader picture of quoting in a job shop, see job shop quoting and scheduling.

The takeaway

One product per quote, held together by the customer, the customer reference, and the sales order. Simulate the set in one action, sum the price and cost, compute the package margin yourself, take the latest end date, and then add allowance where lines share a machine, because each was simulated as though the others did not exist. Bring a real multi-line PO to a walkthrough of EDGEBIC and we will quote it as a package against your actual load.