In this piece
Odoo email and PDF quotations: review products and prices first
A customer asks for three boxes of bolts and five seal kits. The PDF is readable. The commercial decision is still unfinished: how many pieces are in a box, which catalog item matches, and is the customer’s suggested price approved?
Treat Odoo email and PDF quotation review as a controlled transformation. Retain the request, resolve each product and unit against the approved catalog, obtain prices from the agreed authority, and bind approval to the exact draft revision before sending. Ambiguous lines and changed terms return to review instead of becoming guessed commitments.
Research checked: 5 November 2026. Product facts use Odoo’s official 20.0 documentation source. The request, catalog and prices below are synthetic. The downloadable checks have not run against Odoo or an AI model. They specify the behavior an implementation should demonstrate.
What should the intake workflow create?
The intake workflow should create a sales draft that preserves the customer’s request and exposes every unresolved line. Give extraction and draft preparation only the authority they need. Sending a quotation and confirming an order need separate decisions, because an internally reviewed draft is not evidence that the customer has accepted its terms.
Odoo 20 documents separate sending and confirmation actions; confirmation creates a sales order. It also documents a configurable Mandatory Product setting. Requiring a linked product does not establish that the selected item matches the customer’s request.
Define the desired behavior before choosing the intake mechanism. In our proposed policy, a technical intake identity can prepare a draft and attach review evidence. It cannot send, confirm, promise delivery or create new catalog products. An authorized person releases the reviewed quotation through the approved sales process.
Those are requirements to implement and test, not claims about default permissions in an Odoo installation. A hidden button does not establish a restriction on another write path. Ask the implementation owner to demonstrate the result using the actual integration identity and the application’s own controls.
| Step | Allowed result | Required evidence |
|---|---|---|
| Capture request | Retain the message and attachments with a request reference. | Original content and received revision. |
| Prepare candidates | Suggest customer, products, quantities and terms. | Source location for each suggested value. |
| Resolve commercial lines | Select approved catalog items, units and prices. | Resolved identifiers, pricing context and remaining holds. |
| Review draft | Approve the current revision for the permitted next action. | Reviewer, revision and material values reviewed. |
| Release quotation | Send through the authorized sales process. | Current approval and the exact document sent. |
Which native Odoo features should you demonstrate first?
Demonstrate the required input path and resulting quotation on the installed Odoo version before specifying custom work. Check which app, configuration or module accepts the request, what it creates and which actions remain possible. An available document feature may solve part of the process without establishing product matching or commercial approval.
The PDF Quote Builder documentation describes composing outgoing quotation documents. That page does not establish an intake path for arbitrary customer PDFs.
Bring one real, permitted sample to the demonstration and record the exact output. Does the process preserve the source line? What happens to an unknown product code? Can a prepared line be sent before review? Confirm the specific version, edition, hosting and module requirements for the proposed route; avoid extrapolating from a similarly named app.
Odoo’s pricelist documentation says suggested prices can be overridden on a sales order. Selecting a pricelist therefore does not by itself prove your price-approval rule is enforced.
If an external workflow is needed, confirm its access and hosting fit before implementation. Keep the quotation review contract the same whichever mechanism prepares the draft. This article evaluates the sales decision; it does not claim that every native intake option is absent or that a custom AI workflow is necessary.
What must a reviewer see for every quotation line?
A reviewer needs the original request alongside the resolved commercial line and any reason it remains on hold. Preserve the difference between what the customer wrote, what extraction suggested and what the business approved. That separation makes an incorrect product, unit or price visible without asking the reviewer to reconstruct the entire email thread.
| Evidence | Example | Decision it supports |
|---|---|---|
| Source reference | RFQ-204.pdf, page 1, line 1. | Can the reviewer locate the request? |
| Customer wording | “3 boxes BOLT-M8-20, 100 pieces each”. | What quantity and item were requested? |
| Catalog resolution | Approved product identifier and selected variant. | Does the line refer to the intended sellable item? |
| Unit conversion | 3 boxes × 100 pieces = 300 pieces. | Is the priced quantity expressed in the correct unit? |
| Price context | Customer, currency, applicable date and approved rule. | Why is this the permitted unit price? |
| Exception | Two catalog candidates or a requested price change. | Who must resolve the remaining question? |
| Approval reference | Reviewer and draft revision. | Does the approval cover the current line? |
Keep customer identity review separate from product resolution. A recognizable company name is insufficient when there are several customer accounts with different terms. Use the customer-field ownership and matching guide if HubSpot participates in that customer handoff.
A model can propose a match, but the review packet should retain the candidate and the reason it was selected. An unknown customer part number needs an approved mapping or clarification. It should not quietly become a new catalog item because creating a line is easier than resolving its meaning.
How do units and prices change a draft quotation?
Resolve units and price authority before treating a draft amount as a quotation total. A correct text extraction can still produce the wrong commercial amount if a box becomes one piece or a target price becomes an approved price. Keep unresolved lines visible and label any subtotal that excludes them as incomplete.
Consider the fictional request RFQ-204. It contains three lines. The example catalog and approved prices are invented for the calculation; they are not Odoo defaults, market prices or model outputs.
| Customer request | Review decision | Illustrative calculation | Remaining action |
|---|---|---|---|
| 3 boxes BOLT-M8-20, 100 pieces each. | Use 300 pieces of the approved catalog product. | 3 × 100 × EUR 0.18 = EUR 54.00. | Confirm packaging and applicable price. |
| 2 filter cartridges FX-2. | FX2-A and FX2-B remain plausible catalog variants. | No price or line total selected. | Ask which variant is required. |
| 5 seal kits SK-4, target EUR 12 per kit. | Keep the requested price separate from the approved example price of EUR 15. | 5 × EUR 15 = EUR 75.00; requested amount is EUR 60.00. | Approve the commercial price or negotiate the request. |
The first and third lines give a partial subtotal of EUR 54.00 + EUR 75.00 = EUR 129.00. That excludes the unresolved filter line, tax and shipping. Showing EUR 129.00 as the complete offer would hide the unfinished decision.
The kit price difference is EUR 15.00 across five kits. A workflow that copies the customer’s target price into the approved unit-price field makes that concession without a business decision. Preserve both values so the reviewer can see what approval would change.
Now remove “100 pieces each” from the first line. The document still says three boxes, but the conversion is unresolved. Hold the line unless an approved catalog or customer agreement establishes the pack size. A model’s familiar-looking estimate is not that agreement.
If a revised request changes three boxes to four, re-evaluate the quantity and pricing context. At the same illustrative rate, 400 pieces would be EUR 72.00, but the applicable rule may also need review. Do not carry the earlier approval forward merely because the product code stayed the same.
When must an approved quotation return to review?
An approved quotation should return to review whenever a material value covered by that approval changes. Define those values explicitly: customer account, product or variant, quantity, unit, price, currency and commercial terms. Compare the approved revision with the current draft at release, and require another decision when they no longer match.
In our proposed policy, an approval authorizes sending one specific draft revision. It does not authorize order confirmation, a substituted product or a later price change. Keep the exact released document with its revision so a reviewer can establish what the customer received.
Apply the guard wherever release can occur. A user-interface check cannot protect a separate integration call if that call can bypass the rule. Ask for a demonstration of the prohibited action using the intake identity, then inspect the business record and outgoing message evidence.
There is also a difference between a duplicate request and a new revision. A forwarded copy of the same request should be linked to its existing intake record under the agreed identity rule. A changed attachment requires comparison and a new review decision. The Odoo and n8n recovery guide covers retry and duplicate-effect handling after that business distinction is made.
How do you accept the workflow without inventing AI accuracy?
Accept the workflow by inspecting its business outcomes on an agreed set of requests, including ambiguous and changed inputs. Measure model behavior only after running the selected model on those inputs. A designed checklist is useful for specifying expected behavior, but it cannot establish extraction accuracy, reviewer time or the reliability of an unexecuted connector.
The 12-case quotation review matrix includes the worked lines, missing pack size, unknown customer codes, currency ambiguity, repeated requests, changed attachments and prohibited send/confirm attempts. Every execution state starts as NOT_RUN.
- Choose the intake scope. Name the supported document types, languages, customers and catalog families. Keep unsupported requests in a manual queue.
- Approve the expected commercial result. Have a responsible sales reviewer establish product, unit, price and hold decisions before evaluating model suggestions.
- Retain the full review packet. Save source locations, proposed values, final decisions and the draft revision for each line.
- Inspect blocked transitions. Demonstrate that held lines and a stale approval cannot release a quotation under the agreed policy.
- Record corrections and effort. After a real run, measure how much work reviewers perform and which errors survive to the final draft.
- Decide the next scope from observed failures. A recurring variant ambiguity may need catalog work or customer clarification before a different model.
For mapping suggestions across a larger import, use the separate Odoo AI mapping validation guide. This acceptance packet concerns the quotation’s commercial lines, not a general benchmark for document extraction.
Pair every prohibited action with a valid action that succeeds. A workflow that refuses every send is safe from sending the wrong quotation, but it has not completed the sales task. The release evidence must show the correct reviewed document reaching the permitted next step.
What would we automate first?
We would start with a narrow catalog and a draft-only intake role, then make one reviewer complete the entire commercial review with source evidence visible. Expand after observing the actual corrections and exceptions. Demonstrate native capabilities first and commission only the missing behavior that has a clear owner and acceptance condition.
The custom-versus-off-the-shelf decision guide helps compare a module with a maintained workflow. For Wavect’s API integration service, bring one representative request, its approved quotation and the exceptions that currently take the most review. That defines a concrete first delivery.