Quotation system development

What this covers, and where it stops

This is the pre-order half of the job: capturing the requirement, assembling a priced document, approving it, sending it, tracking the customer's decision and recording exactly what was accepted. Order creation, fulfilment, invoicing and reconciliation are the half that follows, and they are scoped separately because they answer to different people and different rules.

You probably need something more controlled if any of the following is true. Two people can quote the same job at different prices. Nobody can say which version the customer is holding. A discount went out that nobody senior would have approved. A quote from four months ago is still being treated as current. Or the number on the document is decided by whoever saved the file.

One number, and it is never reused

Start here, because it costs almost nothing to build and a great deal to retrofit. Every quotation gets one identifier allocated by the system rather than typed by a person. Revisions stay under that identifier as versions. A superseded version is kept rather than overwritten. Nothing reuses a number that has already been issued, even if the original was withdrawn the same day.

That one rule is what lets you answer the only questions that matter in a dispute: what did we send, when, at what price, and who approved it. It is also what removes the spreadsheet of documents that a quotation system was supposed to replace, because the sequence lives in the system that issues the numbers.

What goes into a quote

A quote is a structured record before it is a document. Customer context, including who receives it and where it is sent. Line items, with quantities or units where those apply. The pricing inputs that produced each figure. Notes and terms. A validity period. And a version identity that travels with all of it.

Separate the reusable part from the transaction-specific part. Standard scope wording, terms and section structure belong to a template that a named person maintains. Prices, quantities, dates and names belong to the transaction. Mixing them is how a quotation ends up carrying last year's terms with this year's prices. Odoo's documentation describes one product's approach to that separation, with reusable quotation templates carrying validity settings, line items and a customer-facing preview. It illustrates the shape rather than recommending the tool, and the defaults it documents will not automatically fit your business.

Where the customer context comes from is its own decision. It may be typed, it may come from an existing customer record, or it may be pulled from an opportunity your sales team already keeps. That connection is a sibling piece of work and it belongs with CRM and integrations.

Pricing rules and discounts

This is where a quotation system earns its place. Figures are resolved from an agreed rule rather than from memory: list price, customer or tier pricing, quantity breaks, and whatever your business genuinely does for a repeat client. The rule produces the number, and the number carries the inputs that produced it so somebody can check the arithmetic later without recreating the conversation.

Discounts need a policy before they need a field. Decide the threshold a salesperson may approve alone, what happens above it, whether a floor exists below which the system refuses outright, and whether a discount is recorded as a percentage, an amount or an overridden unit price, because those three reconcile differently once an order exists. An out-of-policy figure should route to a named reviewer rather than being quietly possible.

A worked example

The roles, policies and system responses below are assumed for teaching and the real scope stays to agree. The acceptance evidence describes tests to run rather than results already achieved.

Who may approve, revise and send

An illustrative lifecycle runs draft, review, approved, sent, revision required and superseded, ending in accepted, rejected or expired. Your real states depend on how your business sells, and the useful exercise is naming them deliberately rather than adopting somebody else's list.

Then attach permissions, because states are only as good as the rules about who may move a quote between them. Who may edit the inputs. Who may approve a version. Who may send it, which is not always the same person. Who may revise an approved quote, and whether revising it automatically returns it for approval. Who may inspect the history.

Treat renewed approval after a material change as a control you configure, not a universal rule. Your business decides what counts as material: a price change, a scope change, a longer validity, a different recipient. What should not be configurable is whether the approval is recorded at all. Every version should be able to show who approved it and when, which is precisely what the approval row in the table is asking you to test.

Validity, supersession and expiry

Validity is a business rule rather than a formality. It belongs to a version, it should be visible on the document, and the system should know what to do when the date passes instead of leaving a stale quote quietly available to accept.

Three states get confused, and each prompts a different decision. Superseded means a newer version exists, so the question is whether the customer has seen it. Rejected means the customer said no, so the question is why, because that is some of the most useful sales data you will collect. Expired means time ran out, so the question is whether to reissue at the same price or requote.

Acceptance should be associated with the version it applies to, together with whatever evidence you agree to keep. Odoo's documentation describes one configured approach, where an online signature flow can retain signed-by and signed-on information against the quotation. Whether a signature, an email confirmation or a purchase order is the right evidence in your business is a scoping decision, and a system recording an acceptance is not the same thing as a legal opinion about the contract.

After acceptance

An agreed handoff settles four things: which quotation version is the input, which customer and line data transfers, who owns the work downstream, and what happens to an exception such as a line that cannot be delivered as quoted. Order creation, fulfilment, invoicing and reconciliation design begin on the other side of that boundary and are scoped as their own piece of work.

The document people actually read

The rendered document is not a detail. Totals that align, line items that do not break awkwardly across a page, dates in a format nobody misreads, and terms that stay attached to the version they belong to. We look at the rendered file before it goes anywhere, because a quotation is often the first part of your operation a customer inspects closely, and a misaligned total costs more trust than it should.

Where your quotes begin

Two starting points behave differently. If a customer picks items from a catalogue and asks for a price, the quotation begins from a selection and most of the work is rules and approval. If quotes begin from a conversation, an enquiry form or an internal sales process, the work starts earlier, with capturing a requirement well enough that two people would quote it the same way.

Bring the current process, the change you want, who is involved, the tools already in use and any constraint that is fixed. Keep credentials out of a first message. Tell us how you quote today and we will say what we would control first, what belongs in a later phase, and whether a custom build is the right answer at all.