A wholesale enquiry often begins as a paragraph: a few product names, several quantities, a destination and a request for the best price. It is easy to accept that text. It is harder to turn it into a reliable quote without silently resolving ambiguities.
I would keep a free-text message for context while giving requested items and quoted offers their own structure. This is a proposed design for a small quotation workflow, not a description of a deployed system.
Separate the request from the offer
A customer's request records what they want. A quote records what the seller is offering under stated conditions. They can differ, so one mutable list should not represent both without a history.
Give the request its own identifier and revision. A quotation should refer to the request revision it answers. If the buyer later changes quantities, the earlier offer still has a clear meaning instead of appearing to apply to the new list.
Free text remains useful for requirements that do not fit established fields. It should supplement the structured items rather than become the only place where the quantity exists.
Give each line a stable identity
Each requested line needs a stable identifier, a product reference where known, the requested edition or format, and a quantity with a unit. Preserve the original title or product link as a reference when catalogue matching is incomplete.
A unit matters. Three box sets, three copies of a single release and three physical discs are not interchangeable quantities. Display the unit close to the input so the user can see what the number means.
Do not merge lines merely because their display titles match. Two releases of the same programme can represent different products or different requirements.
Allow unresolved product matching
A buyer may paste a title that does not identify a unique edition. Preserve that request and mark the mapping as unresolved. An agent can ask a question or propose a matching product later.
Avoid filling the gap by selecting the first catalogue search result. That turns an interpretation into a fact and can make the eventual quote look more precise than the enquiry supports.
A useful review screen shows the customer's original description beside the matched catalogue item, making the decision visible before an offer is issued.
Treat alternatives as proposals
Store substitution preference separately from the product reference. The buyer might require exact items, allow proposals for approval, or specify particular acceptable alternatives.
If the seller proposes another edition, preserve a link between the requested line and the proposed quote line. Record the changed product, quantity and price explicitly. Do not overwrite the original request to make the two appear identical.
A preference to receive suggestions is not the same as approval of a particular substitution. The workflow needs a distinct acceptance action if the buyer chooses that offer.
Make price meaning explicit
A quote line should state the currency, priced unit, unit price, quantity and line amount. At the quote level, identify the treatment of any additional charges and show the total under those stated assumptions.
Use a decimal-safe representation appropriate to the currency and pricing rules. If values are represented in minor units, the currency's rules must be part of that convention; if fractional unit pricing is supported, define the rounding point as well.
Do not infer a mixed-order discount from the sum of all quantities. A tier rule needs an explicit scope, such as one product, a defined group or the whole order. The calculated price should reference the applicable rule or be an explicitly entered offer.
Version the quote before sending it
An issued quote should be a stable snapshot of the offer. Corrections create a new revision, while the earlier revision remains available for understanding what was sent.
Include validity and relevant fulfilment assumptions. Availability checked at a particular time is different from stock reserved for the buyer. Keep those states separate in both the data and the wording shown to users.
Acceptance should identify the specific quote revision. If that revision has been superseded or no longer meets the workflow's validity conditions, show the current situation rather than silently applying the acceptance to a different offer.
Keep workflow status separate from payment
Draft, issued, awaiting clarification, accepted and expired can describe quotation progress. Payment and order creation are later concerns with their own identifiers and states.
An accepted quote should not automatically be described as paid. Nor should issuing a quote imply that an order has been placed or that inventory has been reserved.
Keep an audit trail of material changes, including who changed the requested quantity, who proposed an alternative and which revision was accepted. That history is more useful than a single status field repeatedly overwritten.
Test the mismatches, not just the happy path
Useful cases include an unresolved edition, a box-set quantity confused with disc count, two equal titles with different formats, a partial-availability response and an alternative awaiting approval.
Also test a quantity change after issuance, an acceptance aimed at an old revision, a repeated submission and a quote with more than one charge component. The system should preserve meaning when requests evolve, not merely produce a formatted total.
The user interface can still be simple: a repeatable item row, destination and timing fields, a message box and a clear review step. The structure exists to remove guessing from the conversation.
For business context, DVDWholesaleShop's US bulk-order guide asks buyers for titles, quantities, formats and destination details. The model discussed here is an independent design proposal and does not claim that the store uses this internal implementation.
Top comments (0)