Vendor Portal | Supplier Quotes & Deliveries

Answering a request

On the same page the vendor already opens, a line-by-line form: unit price, when they can supply it, and a message. One button sends it.

If they cannot supply it, there is a second button and a box for the reason — so a "no" arrives as a "no", instead of as a silence you chase by telephone a week later.

Once an order is confirmed, both forms disappear. A confirmed order is not open to being re-priced by the person being paid.

Telling you it is on its way

Date, carrier, tracking reference, and a note for part shipments. Applying it moves the expected date on the order lines, so when is it coming has an answer inside Odoo rather than in somebody's inbox.

Sending the invoice

The document itself — a PDF, or a photograph of one, up to 10 MB — together with the vendor's own reference, date and total.

One button in the back office turns that into a draft vendor bill with the file already attached to it. Draft, never posted: the figures came from outside, and a portal that posts to your ledger without a person reading it first is not a portal, it is a hole.

Nothing touches the order until you apply it

This is the design, not a workflow preference.

A portal user is an outsider. If sending a quotation wrote the price onto the purchase order, the document a buyer reads and the document a buyer approves would not be the same document — it could change in between, from outside, at any moment. So everything a vendor sends is stored as a submission sitting beside the order. It can only be read, until a buyer opens it and applies it.

Applying is one click. It can only happen once. It records who did it and when. Rejecting is also one click, and the reason goes on the order.

The same rule is why no group in this module may create a submission by hand. What a vendor sent is evidence; a buyer who could type one could also type the price he wishes the vendor had quoted, and nothing would tell the two apart afterwards.

What the door refuses

• A line from another order. The line identifier arrives in a form post, and on its own it is a number, not a permission. It is checked against the order it claims to belong to — twice, once in the controller and once as a database constraint — because without that a vendor could answer somebody else's order line and it would look like your own order on screen.

• A negative price, which falls back to what was asked, and a negative invoice, which is refused outright.

• A second copy of something already sent and not yet handled, so a double click is not two submissions a buyer has to choose between.

• A quotation on a confirmed order, a shipping notice or invoice on one that is not confirmed, and anything at all on an order that is done or cancelled.

• A file that is not a document — PDF, PNG or JPEG only.

Access

The module widens nothing. Odoo gives portal users read-only rights on purchase orders; they still have exactly that, and there is a test that fails if it ever stops being true.

Every route checks the document with Odoo's own _document_check_access before it does anything, and only then acts as superuser to store the submission — the same shape core uses for its own portal write, the one that updates delivery dates. The check is what proves the caller is entitled to this order. The superuser step is what lets a read-only user leave something behind. Doing the second without the first is how a portal becomes an open door.

Series

Community 16.0, 17.0, 18.0 and 19.0.