Skip to main content

Purchase Price History

Purpose​

Purchase Price History compares proposed purchase prices with earlier confirmed purchases for the same commercial vendor, product and company. Policies can warn, block confirmation or require approval when a variance exceeds the configured threshold. The app adds comparable prices, variance, history and exception controls to native Purchase screens.

Comparisons use the product’s reference unit and company currency, applying the line discount before currency conversion. Average comparisons are weighted by quantity. The app does not overwrite the proposed price with the historical price.

Before you start​

Install the package matching your Odoo version with native Purchase/Inventory (purchase_stock). The manifest declares no Enterprise-only dependency. Prepare reliable vendor/product records, convertible units and currency rates, plus historical confirmed purchases where comparison is needed.

This guide describes the 19.0 source workflow. Selected differences were inspected in other listed releases; no runtime confirmation or approval was executed for this guide.

Access and roles​

Purchase users can inspect line history, enter reasons, request approvals and acknowledge warnings on accessible orders. Price Guard Approver can decide requests, but must also belong to an allowed approver group on the governing policy and have the exception’s company active. Price Guard Policy Manager configures policies and company settings and includes both approver and Purchase manager access.

Company rules apply to policies, exceptions and their source snapshots. The app does not bypass access to purchase history. A normal Purchase manager role alone should not be treated as the dedicated policy-manager role.

Setup and menu​

A policy manager opens Price Guard Settings under Purchase configuration and enables the guard for the company. Set the history horizon and per-vendor/product and total history limits. The limits bound the comparison; if exceeded, confirmation stops and asks for a narrower horizon or an increased configured limit.

Open Purchase Price Guard Policies. Scope a policy by company, vendor or vendor tag, buyer or buyer group, product or category, currency and dates. Higher priority and more specific scopes take precedence; the policy shows its precedence explanation. One policy is selected for each line.

Choose Last Confirmed Purchase, Average of Last N, Period Average, Lowest in Period, or Highest in Period. Configure percentage and/or absolute thresholds and whether either or both must be exceeded. Set Warn, Block, or Approval, price-decrease handling, and the separate no-history action. For approval policies, configure allowed approver groups. A threshold equal to the variance does not count as exceeded.

Workflow​

  1. Create or open an RFQ and enter the vendor, products, quantities, units and prices.
  2. Review Last Comparable, Comparable, Variance %, the guard action and status on its lines. Use History or Open Comparable History to inspect source purchases and receipt progress.
  3. Check whether a line has no historical baseline. Its result follows No-History Action, which may allow, warn, block or require approval; the app does not invent a comparison price.
  4. Correct a price or policy mismatch before confirmation. For an approval result, enter the exceptional-price reason and select Request Price Approval. A permitted approver reviews Price Exceptions and chooses the relevant decision.
  5. Confirm the RFQ normally. A blocking result stops confirmation. An approval result requires a matching current approval. A warning opens Purchase Price Warning; provide the reason required by the policy and acknowledge it to continue the normal confirmation or approval flow.
  6. Review the order’s Price Exceptions and reporting after confirmation. Purchase Price Variance uses confirmation snapshots. Approvers can use Export Price Exception Decisions; policy managers can use Rebuild Price Variance when an intentional rebuild is needed.

The guard runs again on native approval as well as confirmation. Editing a line, changing the comparison inputs or changing the policy can make a previous decision stale. Review the current values and submit a new request instead of treating an earlier approval as permanent permission.

Practice scenario​

In an authorised test database, fictional Cedar Packaging has a prior confirmed purchase at 10 per unit in the company currency. Configure a product/vendor policy using Last Confirmed Purchase, a 10% threshold and Approval. Enter a new RFQ at 12 per unit with the same unit and no discount. The source-derived expectation is a 20% increase requiring approval. Request a decision, obtain it from an eligible approver and confirm through the normal workflow. This scenario has not been executed.

Repeat at 11 per unit. With only that percentage threshold enabled, equality to 10% is not a breach. Include a separate first-purchase case to check the policy’s no-history choice.

Troubleshooting and limitations​

History is restricted to positive-quantity, non-display, non-down-payment lines in the purchase state with an approval date, in the same company and commercial vendor/product combination. It is purchase history, not a vendor-bill or landed-cost comparison. A received quantity is displayed as context; receipt completion is not the history eligibility rule.

If history exceeds a configured cap, adjust the horizon or ask a policy manager to review the limit; results are not silently truncated. Incompatible units stop normalization. Check company currency, conversion date, discount and unit before interpreting a variance.

Approvals are snapshots. Stale requests must be renewed, and a Block policy is not overridden through the approval button. Warning acknowledgement can proceed with confirmation, so use it only after reviewing the order.

Qualified catalogue pairs are 15.0, 16.0, 18.0, 19.0 and 20.0. A 17.0 source package exists without a qualified live-demo pair here. Older forms and unit APIs differ; 20.0 uses its updated unit and access-policy APIs. The inspected history filter remains specific to the purchase state across these comparisons. Selected comparisons do not establish equivalent runtime behaviour.

Live Test — Odoo 19.0 · Choose your exact Odoo version in the Corvus catalogue.

Related guides: Purchase Order Import and Purchase MOQ & Freight.