How to Set a Quote Expiry Date in EDGEBIC

To set a quote expiry date in EDGEBIC by User Solutions you fill the Expiry Date: field in the Quote Configuration dialog. It defaults to thirty days after the quote date and must fall after the quote date. The expiry date records how long the quoted price and dates are valid, which matters because a simulation is a point-in-time snapshot that drifts as capacity changes. The control lives alongside Quote Date: in the dialog's Important Dates group.

For the wider quote-building walkthrough, read how to build and price a quote. This task is documented behavior of EDGEBIC, and the full task library is in the how-to hub. If the quote does not exist yet, start with how to create a quote.

Before You Start

• You are creating or editing a quote, so the Quote Configuration dialog is open.
• You know the quote date, because the expiry date must be later than it.

Step 1: Open the Dialog

On the Quote tab, click ➕ Quote for a new quote, or the ✏️ (Edit) action for an existing one. The Quote Configuration dialog opens with an Important Dates group holding Quote Date:, Expiry Date:, and Target Start Date:.

Step 2: Set the Expiry Date

The Expiry Date: field defaults to thirty days after the quote date. Change it to the date the quoted price and dates should lapse. It must be after the quote date.

Step 3: Save

Click Save. The expiry date persists on the quote.

Step 4 (When It Lapses): Mark It Expired

Because the system does not auto-expire quotes, mark a lapsed quote yourself. Open it, set Status: to Expired, and save. A lapsed quote then drops out of the Draft filter but still shows under All.

Why the Expiry Date Matters More Than It Looks

The expiry date is not just paperwork. A quote's promise dates and cost come from a simulation run against a specific snapshot of your shop: the load, holidays, work-center rates, and capacity as they stood the moment you clicked simulate. All of those move. A holiday gets added, a machine goes down for maintenance, a rate changes, three new jobs land on the bottleneck. The longer a quote sits, the further its simulated numbers drift from what the shop can now actually do. The thirty-day default is a reasonable window in which the drift is usually small enough to honor without re-running. Past it, the numbers are a guess wearing the authority of a quote.

That is why the expiry date pairs with a discipline rather than a lock: re-simulate anything older than its expiry window before reviving it. The date is the reminder, not the enforcement.

Where Expiry Sits in the Quote Lifecycle

A quote moves through statuses you set by hand: Draft, Submitted, UnderReview, Approved, Rejected, Expired, and the system-set Converted. Expiry is one status among these, and setting it is informational, exactly like the others. Two points are worth holding: the system never moves a quote to Expired on its own when the date passes, and an Expired quote is not blocked from conversion, because the conversion guard only stops a quote already marked Converted. So Expired communicates "these numbers have lapsed, re-verify before use," and nothing more mechanical than that.

Worked Example: Reviving a Sixty-Day-Old Quote

A customer accepts a Widget-A quote you raised sixty days ago, well past its thirty-day expiry. You do not convert it as-is. The original start of July 20 and cost of $9,230 predate two months of load changes. You open the quote, click Refresh to pull current routing data, and re-run ▶️ Simulate. The new run returns today's capacity-aware start and end dates and cost. If the cost moved, you click Apply Markup → Unit Price or adjust the manual cost override so the price reflects reality. Only then do you set Status: to Approved and convert. The expiry date did its job: it flagged the quote as stale so you re-checked before promising.

What Changes When You Save

Saving stores the expiry date. It does not schedule anything, does not change the quote's status, and does not touch production. The expiry date is a record of validity, not an automatic trigger. The validator warns if you set it before the quote date, but it never flips the status for you.

Running a Shorter Validity Window

If your shop's cost or capacity moves fast, a thirty-day window may be too long. Set the expiry date closer in, say two weeks past the quote date, on each new quote. Because there is no global auto-lapse setting, a shorter window is enforced by a habit, not a switch: periodically filter the quote grid, spot the quotes past their expiry date, and set each one's Status: to Expired by hand. The expiry date documents the intended validity window on every quote; the review turns that intent into a status the grid can filter on. Pair the two and stale quotes stop slipping through as if they were current.

This matters most for the quotes you are proud of. A margin that looked healthy at simulation time can evaporate if a key material's cost rose or the bottleneck filled up since. The expiry date is the low-effort guardrail that forces a second look before you honor an old number.

How to Check It Worked

Reopen the quote and confirm the Expiry Date: reads the date you set and falls after the Quote Date:. If you marked a lapsed quote as Expired, confirm it no longer appears under the Draft status filter but is still visible under All.

Common Mistakes and Gotchas

• No automatic expiry. The date passing does not change the status. Build a manual review to flag lapsed quotes, or they sit as Draft indefinitely.
• Expiry before quote date warns, but check it. The validator flags an expiry earlier than the quote date. Fix the dates so the window makes sense.
• An expired quote can still convert. The conversion guard only blocks Converted. Treat Expired as a prompt to re-verify, not a lock.
• Old simulations are stale, not just old. A quote past its expiry window was simulated against capacity that has since moved. Refresh and re-simulate before reviving it, or you promise dates the shop can no longer hit.

Keeping expiry dates honest is what makes a revived quote trustworthy. A thirty-day window is not arbitrary caution; it is the span in which a simulated promise is usually still close enough to the shop's real state to honor without re-running. Treat the date as the smallest possible insurance against promising a number the floor can no longer hit. When a lapsed quote comes back, run the delivery-date simulation again before you send fresh numbers.