Skip links

Quality Management in Odoo

Why it belongs in your ERP

Quality data separated from production data is quality data nobody uses.

If inspections live in a spreadsheet and production lives in your ERP, connecting a defect to a batch, a supplier, an operator or a work order is a manual exercise. So it does not happen, and the patterns that would tell you something stay invisible.

In the same system, the connections are already there. A failed inspection knows which lot it belongs to, which supplier the material came from, and which work order produced it.

That is the argument for doing it in Odoo rather than alongside it.

What Odoo provides

Quality control points. Where an inspection happens — at receipt, during manufacturing, before delivery — defined per product or per operation.

Quality checks. The inspection itself. Pass or fail, a measurement within a range, or an instruction to follow.

Quality alerts. Raised when something fails. A record of the problem, who is handling it, and what stage it is at.

Teams and stages. Alerts routed to the right people, moving through stages you define.

Root cause and action fields. So an alert records why, not just what.

FIGURE 1: THE FOUR PIECES

Control points

  • Where an inspection happens — receipt, production, delivery.

Quality checks

  • The inspection. Pass/fail, a measurement, or an instruction.

Quality alerts

  • Raised on failure. Owner, stage, root cause, action.

Teams and stages

  • Routing, so alerts reach the right people.

Where to put control points

Three natural places, and most businesses need at least two.

On receipt. Inspecting incoming material. Catches supplier problems before they enter production, which is by far the cheapest place to catch them.

During manufacturing. At a specific operation. Checks a characteristic while the work is in progress, rather than at the end.

Before delivery. Final inspection. The last chance before the customer.

The principle from risk-based thinking applies: put the checks where failure is likely and costly. Inspecting everything equally is expensive and still misses things.

Choosing the check type

Pass / fail. Simple, and the right choice for a visual or a yes-or-no condition.

Measure. A value with a tolerance. Use this wherever the characteristic is numeric — it produces data you can analyse, and pass/fail throws that away.

Instructions. A procedure the operator follows and confirms.

A worthwhile habit: if a characteristic can be measured, record the measurement rather than a pass. A run of measurements drifting towards the tolerance limit tells you something a run of passes never will.

Alerts, and what they need

A failed check raises an alert. What happens next is what makes this useful or decorative.

A useful alert records:

What failed, linked to the product, lot and operation.

Root cause. Not “operator error” — why the process allowed it.

Corrective action. What changed.

Verification. Did it work.

Odoo has fields for these. Whether they get filled in is a discipline question, not a software one.

Without root cause and verification, an alert log is a record of problems that recurred — which is exactly the pattern most quality systems fall into.

FIGURE 2: ALERTS THAT WORK AND ALERTS THAT DO NOT

Working

  • Linked to lot, supplier and operation
  • Root cause recorded, not “operator error”
  • Action taken and verified
  • Reviewed for patterns

Just a log

  • A list of things that went wrong
  • “Fixed” with no cause identified
  • Closed without verification
  • Nobody looks at it between audits

Traceability

The advantage that only exists in an integrated system.

Lots and serial numbers, tracked through receipt, production and delivery.

What that gives you:

Backwards. A customer reports a defect. Which lot? Which materials went into it? Which other customers received material from the same batch?

Forwards. A supplier reports a problem with a batch they shipped you. Where did it go? What did we make with it? What is still in stock?

That second one is the containment question, and answering it in minutes rather than days is the difference between a contained problem and a recall.

It requires lot or serial tracking to be switched on and used consistently — which is a decision to make early, because retrofitting it is difficult.

Supplier quality

Because purchasing and quality share a database, supplier performance becomes visible without assembling it.

Which suppliers generate the most quality alerts. By volume, and as a proportion of what they ship.

Which ones deliver late.

Which ones cause the most rework.

Why this matters: supplier decisions usually get made on price, because price is the number everyone has. Quality cost is real and invisible unless something is tracking it.

A supplier who is five percent cheaper and generates three times the rework is not cheaper.

Connecting it to nonconformities

Odoo’s quality alerts handle the record. The CAPA discipline is yours.

Four habits that make the difference:

Record small things too. Three minor issues with the same underlying cause is a bigger finding than any of them alone — and you cannot see that pattern if you only log the significant ones.

Root-cause the recurring ones. Start with whatever happens most.

Verify. Come back and check the problem stopped.

Review the log periodically. Not just before an audit.

FIGURE 3: FROM CHECK TO CLOSURE

Check fails

  • Linked to lot, operation, supplier

Alert raised

  • Routed to the right team

Root cause found

  • Why the process allowed it

Action verified

  • Come back and confirm it stopped

Setting it up sensibly

1. Decide where inspection actually matters. Not everywhere. Where failure is likely or costly.

2. Turn on lot or serial tracking for anything where traceability matters. Do this early — it is difficult to add later.

3. Start with receipt inspection on your problem suppliers. Cheapest place to catch problems, and it produces supplier data quickly.

4. Use measurements rather than pass/fail wherever the characteristic is numeric.

5. Define your alert stages and teams, so failures reach somebody.

6. Make root cause a required habit, not an optional field.

7. Review the alert log monthly. The patterns are the point.

What it does not solve

A weak process. Recording defects faster does not reduce them.

Containment culture. If alerts are closed by fixing the instance, moving them into Odoo changes nothing.

Unclear standards. If nobody agrees what acceptable looks like, no system settles it.

The software provides the structure. The discipline is separate, and it is the part that determines whether any of it works.

The short version

Quality data belongs in the same system as production data, because the connections — lot, supplier, operation, customer — are what make it useful.

Put control points where failure is likely and costly, not everywhere.

Record measurements rather than pass/fail wherever you can. A drift towards the limit is a warning; a pass is not.

And turn on lot tracking early. The ability to answer “where did that batch go” in minutes is worth more than everything else on this page.

Quality records in spreadsheets, separate from production?

Get in touch. We set up quality control in Odoo so defects connect to lots, suppliers and work orders — which is where the useful patterns are.

Leave a comment

Drag