For an Odoo business in Belgium or France, a failed inspection, a shop-floor anomaly, or a customer complaint should not end up in an isolated inbox. Odoo 19 Enterprise Quality Alerts give a nonconformity a shared record: the affected product or operation, responsible team, priority, root cause, and actions. They do not fix the issue on their own; they make its treatment visible and manageable.
Separate the check from the nonconformity
A quality control point creates checks at a defined frequency. A quality alert is appropriate when a defect or risk deserves investigation. It can be created from Quality, a manufacturing order, an inventory operation, or Shop Floor. Depending on its entry point, Odoo may already populate the product, order, or work center: verify that context before assigning the case.
This separation avoids two pitfalls: turning every successful check into administrative work, or losing a serious anomaly in a simple note. For Odoo Belgium, Odoo France, and Odoo Enterprise, clearly define what triggers an alert and who may close one.
Make every alert useful from the start
A good title states the symptom and context without prematurely deciding the cause. Add the product, variant, lot or serial number when traceability requires it, along with the relevant order, work center, or vendor. Assign a quality team, an owner, and a priority consistent with customer, regulatory, or operational risk.
The root cause should remain a verified finding, not a hypothesis added to close a case faster. Use consistent tags to find recurring defects; avoid an overlong list that each team uses differently.
Keep corrective and preventive actions distinct
In the alert, distinguish corrective action — controlling products or operations already affected — from preventive action — reducing the chance of recurrence. Holding stock, sorting received items, or informing a customer can be corrective. Changing an instruction, control point, bill of materials, or training is more likely preventive.
Each action needs an owner, a due date, and evidence of verification. If a product change is needed, route the decision through your company’s PLM or change process instead of treating an alert as authorisation to alter a bill of materials.
Match the Kanban flow to real decisions
Stages such as “To qualify”, “Under analysis”, “Actions in progress”, “To verify”, and “Closed” can be enough. The goal is not to multiply statuses: someone should be able to understand the risk state and next decision. Define an explicit rule for reopened cases, blocking alerts, and escalation to production, purchasing, or customer-service owners.
Monitor at least time to qualification, overdue alerts, the most frequent root causes, and the reopen rate. These indicators help decide where to strengthen a check or instruction; they should not be used to judge the person who raised the issue.
Test the full cycle before rollout
Fictional Underside scenario: during a receipt in Belgium, an operator finds a series of parts with unreadable markings. They create an alert linked to the product, lot, and receipt; the quality team then isolates the series and assigns purchasing. After vendor analysis, it documents sorting the received parts as a corrective action and adds a marking check at receipt as a preventive action. The owner checks effectiveness on the next delivery before closing the case.
- Create an alert from a failed check and another without a prior check.
- Verify prefilled fields, permissions, owner, and priority.
- Test attaching evidence and searching by product, lot, and root cause.
- Move the case through every stage, including a reopening.
- Confirm that a preventive action is verified before closure.
Official source and scope
Reference: Odoo 19 documentation on quality alerts. Verify the enabled modules, rights, and workflow applicable to your environment. Acceptance scenarios and governance recommendations are Underside’s analysis.
Frame your Odoo quality alerts with Underside, connecting detection, decision, and continuous improvement.