Skip to main content

Customer PO Validation

Purpose​

Customer PO Validation adds company-specific purchase-order policies to Sales. It checks missing references and normalized duplicates at configured business stages, supports controlled blanket-PO reuse, and copies the customer's original reference to invoices. It extends existing customer, quotation and invoice screens.

This guide follows Odoo 19 source with a targeted Odoo 20 comparison. The workflow and fictional practice case have not been run in a database.

Before you start​

Install corvus_sale_customer_po_guard for your Odoo version. It depends on Sales (sale_management), with no Enterprise-only dependency declared. Custom addons must be supported by your hosting. Delivery checks need Customer PO on Deliveries; website checkout needs Website Customer PO Rules.

Decide when a reference becomes mandatory and whether repeat references mean a mistake, an authorised release, or legitimate blanket-PO use. Choose the company before assigning customer policies.

Access and roles​

Sales users can read policies and work with accessible orders. Sales Managers create and change policies, assign them to customers/orders, approve duplicate reuse and run the audit. Invoice users have read access to policies for their accounting workflow. Policies and approval records are restricted by allowed companies. Approvals are immutable and cannot be manually edited or removed.

Duplicate detection can find a conflict outside a salesperson's readable orders. Readable Duplicates and the embedded order list show only records that the current user may read; an empty list is not proof that the reference is unique.

Setup and menu​

Open Customer PO Policies under Sales Configuration. Create a policy with its company and optional effective dates. Set Required Stage to Quotation send, Sales order confirmation, Delivery validation, Invoice creation, Invoice posting, or Never require; duplicate check only. Once the required stage is reached, later checked stages also require the reference. Delivery validation needs the stock bridge.

Choose Enforcement: Warn and continue, Block, or Require manager override. A manager override is for duplicate reuse; it does not substitute for a missing reference.

On Comparison, configure case sensitivity, whitespace removal, exact punctuation characters to ignore, and optional leading-zero removal. These affect comparison only. Preview Normalization demonstrates the configured transformation using a fixed sample. Select uniqueness by commercial customer, delivery address, invoice address or entire company; choose all dates, calendar month/year or company fiscal year and the order states to compare.

On Controlled Reuse, choose Unique reference, Blanket PO reuse, or Blanket PO with unique release ID. Optional count and amount caps use zero for unlimited; amount caps are evaluated in company currency. Set an expiry if needed. Release mode requires the release-identifier setting.

Assign Customer PO Policy on the customer's commercial entity, beside its payment-term settings. Assignment is company-specific. New orders resolve that customer's active policy for the order date; this is not a global policy automatically assigned to every customer.

Workflow​

  1. Create a quotation for the customer and enter their exact reference in Customer Reference. Inspect Customer PO Control for the policy and PO Status. If using release mode, enter Release ID.
  2. Continue to the relevant business action. The module checks quotation sending, transition to sent/confirmed, invoice creation and invoice posting. Under Block, a missing or disallowed duplicate reference stops the action with guidance. Under Warn and continue, the status becomes Warning accepted.
  3. For a duplicate, open Readable Duplicates or inspect the list on Customer PO Control. Correct a mistake or review the agreed blanket/release policy. A valid controlled repeat becomes Controlled reuse.
  4. If the policy requires an exception, a Sales Manager chooses Record Manager Override, reviews available candidates, enters a specific reason and selects Approve Reuse. Self-approval is blocked when the order is assigned to that manager unless the policy permits it. Retry the business action after approval.
  5. Create the invoice through Sales. Customer PO contains the original reference; different PO references are included in invoice grouping criteria. The invoice's Sales Orders smart button opens readable source orders. Posting checks the current source-order policy again.
  6. Open Customer PO Exceptions under the Sales order menu for warnings, controlled reuse, overrides and other recorded exceptions. Managers can use Sales → Reporting → Customer PO Reference Audit, set companies, dates and a maximum record count, then choose Run Diagnostic, Audit PDF or Export CSV. The default cap is 500 and the allowed range is 1–5,000. Diagnostics refresh stored statuses; exporting alone does not perform that diagnostic refresh.

Practice scenario​

In an authorised test database, assign fictional “North Pier Retail” a policy requiring a reference at confirmation, unique within the commercial customer, with case sensitivity off, whitespace removal on and hyphens ignored. Configure comparison to Confirmed only. Confirm an initial quotation with PO-0042, then prepare another with po 0042. The source-derived comparison treats these as the same key and blocks the second order under Block. With Require manager override, a different Sales Manager could record a justified reuse decision. This exercise has not been executed.

Troubleshooting and limitations​

No policy means the order has no resolved policy; inspect the commercial customer's assignment, company and effective dates. A missing reference must be supplied. Normalization is not a configurable pattern/regular-expression validator, and no arbitrary reference-format editor is provided in the reviewed policy model.

Material changes to an order or policy can invalidate its approval, producing Override stale or a fresh unchecked status. Reassess and obtain a new decision rather than copying approval fields. The Odoo 19 line-write invalidation list uses an older unit-field name; do not assume every standalone unit edit immediately clears the approval. Downstream policy checks remain necessary.

Audit rows retain their own currencies. Do not interpret a mixed-currency pivot total as a company-currency consolidated amount. The stored status reflects prior checks; a rejected transaction may roll its status update back. Run Diagnostic when you need a refreshed exception list.

Catalogue-qualified versions are Odoo 15, 16, 18, 19 and 20. Odoo 17 source is also present, but that pair is not catalogue-qualified. This workflow is reviewed for 19.0; 15–18 workflows remain unreviewed here. The targeted 20.0 comparison updates invoice-creation integration, access-file format and the unit field watched for line changes. It does not establish runtime compatibility.

For purchase and demo options, use the Corvus apps catalogue and select your exact version. The stock and website guides above explain the optional integration boundaries.

Open the Odoo 19 demo selector for this catalogue-qualified module/version pair. The catalogue listing was verified; no demo was launched in this review.