Quality Checks in Odoo 20: Points, Alerts and Control Plans

Quality in Odoo is not a separate inspection department bolted onto the side of production. The Quality app lives inside the same database as Inventory and Manufacturing, so an inspection can be triggered by a receipt, a delivery, or a specific work order operation, and a failed inspection can immediately shape what happens to the stock. The system is built from three pieces that work together: quality control points define the plan, quality checks are the inspections themselves, and quality alerts handle everything that goes wrong. Most of that machinery is long-standing Odoo capability that carries into Odoo 20 unchanged. What version 20 adds is narrower but practical: a controlled way to bypass checks on inventory transfers, and a failure location you can set the moment a check fails. This article walks through all three pieces, then covers the two changes.

Control points: where the plan lives

A quality control point (QCP) is a rule that tells Odoo when to create a quality check automatically. You configure them in the Quality app, under the control points menu, and each one is scoped in three dimensions:

What it applies to — specific products, product categories, or everything (leave the product or category field blank and the point applies to all of them).
Which operation triggers it — an inventory or manufacturing operation type, such as receipts, deliveries, or manufacturing itself. If the Manufacturing operation is selected, you can narrow the point further to a specific work order operation, so the check appears at exactly one step of the routing instead of on the manufacturing order as a whole.
Who owns it — a quality team, and optionally a specific responsible user. The team manages both the control point and the checks it generates.

Two settings decide how much inspection actually happens. Control per sets the granularity: one check per operation as a whole, one per unique product in the operation, or one per quantity — with an optional partial-transfer test, where you enter a percentage and only that share of the items is checked. Control frequency sets how often the point fires:

All — a check is created every time the conditions are met.
Randomly — a check is created for a percentage of operations that you specify.
Periodically — a check is created at regular intervals, in days, weeks, or months.
On-demand — checks are only created when someone requests them manually.

Taken together, your set of control points is your control plan: the documented scheme that says which products get inspected, at which operations, how often, and by whom. Each of those decisions is one control point — and because the points are data rather than code, the plan can evolve without a developer.

Each control point also carries the working instructions for the people who will process its checks: an Instructions tab describing how to perform the check, and a Message If Failure tab describing what to do when it fails — for example, instructing the operator to raise a quality alert. A Notes tab holds background for the quality team that operators never see.

The check types: nine ways to inspect

The Type field on a control point (or on a manually created check) determines what “doing the check” actually means:

Instructions — the operator reads instructions and confirms the step. This is the same mechanism as a step on a work order: when you add a step to a work order, Odoo stores it in the Quality app as a control point of this type.
Pass – Fail — the product is judged against a written criterion; the operator records a simple pass or fail.
Measure — the operator records a measurement, which must fall within a tolerance of a norm value for the check to pass. This is the type for dimensions, weights, and temperatures.
Take a Picture — a photo of the product must be uploaded before the check can be completed, leaving visual evidence for the quality team to review later.
Register Consumed Materials — the operator confirms the materials actually consumed during the manufacturing operation.
Register Production — the operator confirms the quantity produced during the operation.
Print Label — the operator is prompted to print a label for the product or its packaging; a printer can be linked to the control point through the IoT setup.
Worksheet — the operator fills out an interactive worksheet, built from a quality worksheet template that is duplicated for every check the point creates.
Spreadsheet — the same idea with an interactive spreadsheet template, suited to checks that involve calculated values.

Checks do not have to come from a control point. Anyone can create a single quality check manually — useful for a one-off inspection or an unprompted spot check — and a check created from an inventory operation pre-fills the operation, product, and control-per settings from that operation.

Processing checks where the work happens

Checks appear where the underlying order is being processed, not in a separate queue that operators must remember to visit. On a manufacturing or inventory order that requires checks, a purple Quality Checks button appears at the top of the order; clicking it opens a pop-up listing every check required for that order. Pass – Fail checks are completed with Pass or Fail buttons; other types present a Validate button once their requirement — measurement entered, picture attached, worksheet filled — is satisfied.

Checks tied to a specific work order operation are processed in the Shop Floor app instead. The operator works through the work order's steps on the tablet view, and when the quality check step is reached, a pop-up explains how to complete it. Marking the step's checkbox completes the check as passed, which keeps fast, routine verifications to a single tap.

When a check fails: quality alerts

A failed check answers the question “did this pass?” A quality alert is the record that answers “what are we doing about it?” Alerts can be raised from a failed check, created directly from the Shop Floor tablet view when an operator spots a defect mid-operation, or created manually in the Quality app. The alert form captures the context an investigation needs:

The product or variant, and the lot involved, where applicable.
The work center where the issue originated, or the picking during which it was found.
The responsible quality team and individual, plus user-defined tags for classification.
A root cause, selected from your configured causes, and a priority of one to three stars — higher-priority alerts sort to the top of the alerts board.

Four tabs at the bottom of the form carry the substance: a Description of the issue, the Corrective Actions that fix the affected products, the Preventive Actions meant to stop the issue recurring, and a Miscellaneous tab holding the vendor, company, and date assigned. That corrective/preventive pairing is what turns the alert system from a defect log into a basic CAPA workflow.

Alerts are managed on a Kanban board whose stages are fully configurable, so the board can mirror your real process — triage, investigation, action proposed, action validated, done. Beyond the board, alerts can be reviewed in graph, calendar, and pivot views, and grouped or filtered by team, root cause, or dates. Grouping by root cause over a quarter is usually the fastest way to see which failure mode deserves engineering attention first.

What is new in Odoo 20

The Odoo 20 release notes list two Quality changes, both aimed at the moment reality collides with the plan:

Bypass quality checks. Quality admin users can now validate inventory transfers without performing the quality checks attached to them. This is an escape hatch for the legitimate exceptions — a trusted internal transfer, a re-check of stock already inspected — and because it is restricted to quality admins, the bypass itself stays an auditable, deliberate act rather than a habit available to every warehouse user.
Failure location. When a check fails, the Failure Location can now be set directly from the quality check's form view. Failed goods can be routed to the right location — quarantine, rework, scrap — at the moment of failure, instead of being parked wherever the transfer happened to put them and sorted out later.

Neither change alters the underlying model: control points still generate checks, checks still pass or fail, and alerts still carry the follow-up. They simply remove two pieces of friction that previously pushed teams toward workarounds outside the system.

Getting the plan right

A few configuration habits separate a quality system people trust from one they route around. Keep control points narrow — one product family, one operation, one clear instruction — rather than writing a single mega-point with vague instructions. Use Measure checks wherever a number exists; a recorded measurement inside a tolerance is evidence, while a pass–fail judgement is an opinion. Reserve All frequency for genuinely critical characteristics and use random or periodic sampling for the rest, or inspection volume will bury the team. Finally, write the Message If Failure before you need it: the operator holding a defective part at 2 a.m. should not have to guess whether to raise an alert, scrap the item, or call a supervisor. In Odoo 20, the plan, the checks, and the alerts are all in place — the work is deciding what your plan actually says.