Collect and review a supplier response

A supplier request records exactly which information you need, who should respond and when it is due. Its submitted response and review decision remain tied to that scope. Use this workflow when a product revision needs a specific answer—for example, the fictional FieldLink S1 revision B needs connector compatibility information from Meridian Components.

This guide covers the internal Suppliers screens. A Compliance Manager prepares and issues the request and can enter an authorized response on the supplier's behalf. A different user with the Qualified Reviewer role decides the submitted revision. Supplier self-service additionally requires a verified active profile and a current, unrevoked delegation for the exact request and purpose; portal onboarding and delivery setup are separate tasks.

Before you begin

Have the correct company, supplier contact and governed product or component subject available. The requested requirements must already exist, with their expected data types and any units or vocabularies. See Getting started if the product revision has not been established.

Use a supplier profile in the same company as the request. Its exact recipients must belong to that supplier's organization. If a response will cite an evidence document or assertion, include that record in the request line before issue; a response cannot introduce an evidence reference outside the frozen scope.

Prepare and issue the request

1. Open ProductTrust → Suppliers → Profiles and find the supplier. For a new profile, enter its name, native contact and company, then save. A company can have only one profile for that contact.
2. If the profile is unverified, select Start Verification. Complete your organization's actual verification work, enter the verification reference and explanatory reason on Verification, then select Verify Supplier. The reference is required. The action records the manager and time; it does not perform an external identity check for you.
3. Open Suppliers → Requests and choose New. Enter a clear name, the supplier, due date and Exact Recipients. Leave an optional campaign blank unless this request belongs to one.
4. On Frozen Scope, add one row for each exact subject and requirement. For example, choose the revision B connector subject and its compatibility requirement. Check the requirement's data type, unit and vocabulary. Add any evidence documents or assertions that the response will be allowed to cite. A subject/requirement pair can appear only once in a request.
5. Save and review the recipient list, date and lines. Select Issue only when that scope is final. The supplier must be verified, the due date cannot be in the past, and the request needs at least one recipient and one line.

Result: the request becomes Issued, with an issue timestamp and a stored scope snapshot. Supplier, recipients, due date and scope lines are frozen. Issue records the request; it does not itself send an email or prove delivery. Use your organization's configured, authorized communication process and confirm receipt separately.

If the scope was wrong after issue, a manager can record a withdrawal reason and rationale and select Withdraw. Create a newly scoped request when needed. Issued requests cannot be copied or have their scope edited to overwrite the original question.

Record and submit the response

6. When the answer is ready to be entered, open the issued request and select Start Response. The request moves to In Progress and creates an active response revision with one value row per frozen request line.
7. Open Current Response from the request's Active Response page. In Structured Values, complete the existing rows. Choose the value kind matching the requirement and enter Value Json in valid JSON syntax. For a Text requirement, an answer such as "Compatible with revision B" includes the quotation marks; a Boolean uses true or false, and an Integer uses a whole number such as 2. Units and vocabularies must match the requirement where specified. More complex types need the format agreed with the person maintaining that requirement.
8. Record the provenance accurately. Manual or internal values use a provenance reference and cannot carry evidence-record links. Document or assertion provenance requires the matching single evidence reference already permitted by the request line. Enter applicable expiry information. If information is unavailable, keep Missing with null; do not substitute an invented answer. A missing value cannot carry units, vocabulary or evidence links.
9. On Supplier Attestation, enter the statement that accurately accompanies this response and save. Return to the request and select Submit Attested Response. Submission requires one value for every frozen line and an attestation. It records the submitting user, time, response snapshot and comparison findings.

Result: the request becomes Submitted, and that response revision is immutable. The findings identify missing, changed, expired, out-of-scope or conflicting values. They inform the review; submission does not establish that every requested answer is adequate.

Review, correct and close

10. A Qualified Reviewer opens Suppliers → Review Queue, selects the submitted request and chooses Open Review. Inspect the active response's values, provenance, attestation and findings against Frozen Scope. The user who submitted this revision cannot decide its review, even if that user also has the reviewer role.
11. In Review & Correction, enter a review reason code and rationale before Accept, or enter a correction reason code and rationale before Request Correction. State what was checked and what remains missing. A submitted revision receives one decisive review; the decision and its author are retained.
12. If correction is requested, the responder selects Start Response again. This creates a successor revision and retains the earlier response. Complete and check every required row, supply the new attestation, and resubmit for a separate decision. Use Suppliers → Response History to inspect the revision chain.
13. After acceptance, a Compliance Manager selects Close when the request is complete. Use Suppliers → Corrections and Suppliers → Overdue for daily follow-up. An accepted request can still appear overdue until it is closed; closed and withdrawn requests are excluded from that overdue calculation.

Result: the request has either a recorded accepted response and closure, or an explicit correction/withdrawal outcome. The original scope, submitted revisions and review decisions remain available for follow-up.

Keep response acceptance separate from evidence approval

Accepting a supplier response does not approve a linked evidence document or make an assertion accepted evidence. Open Evidence → Documents to inspect the actual document and its versions. An upload-pending record or ordinary attachment is not proof of completed processing. Document-version approval requires Review Required, a Qualified Reviewer other than the uploader, and resolution of candidate assertions; evidence processing and its configured services have their own prerequisites.

When review stops, resolve the displayed prerequisite with its owner: supplier verification, company access, expired delegation, wrong value type or a missing review reason. Do not edit a submitted revision to hide a problem. For scope changes use a newly scoped request; for an answer correction use the successor-response workflow.

This guide was reviewed on 29 October 2026 against the Odoo 20.0 supplier models, guarded actions, native forms, access rules and evidence-version review controls. The FieldLink narrative supplies only a fictional example: its demonstration request remains draft and its connector evidence remains upload-pending. No current UI run, automatic delivery, document approval or legal acceptance is established by this article.