Control points
Rules deciding where a check appears — incoming receipt, a specific manufacturing operation, before despatch — by product, category or operation type.
Quality systems fail in the same way everywhere: the inspection happens, the result goes on a sheet of paper, and nobody can answer which batch it belonged to six months later when a customer complains.
Putting quality inside the ERP fixes that one thing, which is most of the value. The check is raised by the transaction that needs it, the result is stored against the lot, and the alert that follows has somewhere to live.
Businesses running Odoo with OdooBots
An Odoo quality management system raises inspections from the transactions that need them and stores the results against the lot or order they belong to. Control points trigger a check on a receipt, a manufacturing operation or a delivery; checks are pass or fail, a measurement within a tolerance, or an instruction to follow; failures raise quality alerts with an owner and a cause; and because the result sits on the lot, traceability from a customer complaint back to a supplier batch is a query rather than an archaeology exercise.
Odoo Quality is an Enterprise application. On Community you can record inspection results through configuration and custom fields, but the control point engine, the alert workflow and the measurement handling are not there, and we would rather say so before you plan around them.
Six parts make up a quality system in Odoo, and all of them are triggered by work that was going to happen anyway.
Rules deciding where a check appears — incoming receipt, a specific manufacturing operation, before despatch — by product, category or operation type.
Pass or fail, a measurement against a tolerance, or a worksheet of instructions, recorded by the person doing the work rather than written up afterwards.
A failure raising an alert with a team, an owner, a root cause and a resolution, so a recurring problem is visible as a pattern rather than as repeated firefighting.
Supplier material checked at receipt and held rather than put away, so a bad batch is caught at the gate instead of on the shop floor.
Checks between manufacturing operations so a defect is caught at the stage that caused it, not after three more operations have added cost to it.
Inspection results stored against the lot or serial, with failure rates by product, supplier and operation available as a report rather than a reconstruction.
A goods receipt hits a control point, so the storekeeper records the check before putting the material away. A manufacturing operation carries its own check, recorded by the operator at the machine. A failure raises an alert against the lot, the supplier and the operation. Months later a customer complaint about a specific batch resolves into the receipt it came from and the inspection record taken at the time.
None of that requires anyone to remember to do quality separately, which is why it survives after the consultant leaves.
These are the configuration decisions that are cheap to make now and structural to change once transactions exist. We walk through each one before a single record is migrated.
Every control point costs a few seconds of someone’s time, every time. Putting them everywhere is the fastest way to have them clicked through without being done.
A measurement against a tolerance gives you data you can trend; pass or fail gives you a tick. Which one per check is a deliberate choice.
Hold, scrap, rework or accept with concession, and who decides. Without this the alert is raised and nothing moves.
Lot or serial tracking has to exist for quality records to attach to anything. If it is not switched on, this is the prerequisite.
A named team with a response expectation, because an alert queue nobody reads is worse than no alerts at all.
What a pattern of failures from one vendor actually triggers, so the data changes a decision rather than filling a report.
Quality is Enterprise. If you are on Community, the scope is either an upgrade or a custom build, and that is decided before the project starts.
Odoo moves features between Community and Enterprise from one version to the next, so the list below is what holds today and is confirmed against your own version during the diagnosis rather than taken as permanent.
This is one of the clearer splits in Odoo: the Quality application itself is Enterprise, and what it adds is the engine rather than the records.
On Community you can still hold inspection data, but you are building the trigger and the workflow rather than configuring them.
We would rather say this before you buy licences than after. These are the areas where we scope real development, recommend a bolt-on, or tell you another tool is the better answer.
Controlled procedures, revision approval and read-acknowledgement are document management rather than ERP, and Odoo Quality does not cover them.
Quality alerts record a cause and a resolution. A full corrective and preventive action process with effectiveness review usually needs custom work.
Internal audit schedules, findings and closure tracking are outside the standard application.
Control charts, capability indices and trend alarms need the measurement data exported to a tool built for it.
Instrument calibration schedules sit in Maintenance rather than Quality, and the link between them is configuration you should ask for.
Who is qualified to perform which check is an HR and compliance question, not a Quality one.
Implementing An Odoo quality management system needs more than installing the application. It should reflect how your business already works, and change only what is worth changing.
Understand where inspections happen today, what is recorded, whether lots are tracked, and which customer or regulator is asking for the evidence.
Settle where control points belong, which checks are measurements, what happens on failure and who owns alerts, before anything is configured.
Set An Odoo quality management system up around how you work rather than installing it at its defaults, and build only what configuration genuinely cannot reach. See Odoo customization.
Masters, open items and opening balances prepared and loaded. Data cleaning is scoped explicitly, because it is usually the largest single task. See Odoo migration.
Your team runs real transactions in a test database before go-live, including the awkward cases that never appear in a demonstration.
Role-based training for the people who key transactions daily, then cutover, hypercare and ongoing support and AMC.
We do not publish one price, because the same application costs very differently depending on the factors below. We do publish what moves the number, and the price is fixed in writing before work starts.
We argue for fewer control points than clients ask for. A check at every step gets clicked through within a month; a check at the three places failures actually originate gets done properly and produces data you can act on.
Product capabilities stated on this page are documented by Odoo. The configuration advice, edition notes and limitations come from our own implementations.
Tell us where inspections happen today and whether lots are already tracked. Those two answers decide the scope, and the diagnosis call is free.