Odoo 20 Production Overview: Review Orders, Components and Delays

By Sajjal Bajaj · Nov 13, 2026 · 6 min read · Odoo Odoo 20 ERP Best Practices Manufacturing Reporting Inventory Management Operations

Short answer: Odoo 20 adds a documented production overview for manufacturing reporting. Treat the feature as part of a controlled business process, not as proof that the underlying decision is correct.

Applies to

Odoo 20 and the applications named in the official source below. Edition, hosting, localization and external service requirements must be confirmed for the installed database.

What is confirmed in Odoo 20

Odoo 20 adds a documented production overview for manufacturing reporting.

This article focuses specifically on the new production overview. It does not repeat the broad release previews already published on this site. The purpose is to translate the confirmed feature into an implementation decision that an owner can test and review.

The business decision

Which order, component or operation needs action, and does the overview link back to reliable source records?

Write the expected outcome before changing configuration. Name the responsible owner, the input that starts the process, the evidence required for completion and the exception that must stop automation. This turns a feature description into a workflow that staff can operate consistently.

What needs fresh review from Odoo 19

Do not copy an Odoo 19 checklist and change only the version number. Odoo 20 can change navigation, permissions, status language, available fields and integration boundaries. Compare the installed Odoo 19 process with the documented Odoo 20 behaviour and record every difference that affects users, reports, automation or external systems.

Review custom modules and Studio changes separately. A standard Odoo 20 feature can behave differently when inherited views, automated actions, security groups or connectors modify the same records. Test with the actual user roles and representative data rather than relying on administrator access.

Questions to answer during discovery

Ask where the source data originates, who is allowed to correct it and which later process depends on the result. Confirm whether a failure should stop work, create a warning or route the record to a person. These decisions are more important than the position of a button because they determine the safe configuration.

Map the complete record journey. Identify what exists before the Odoo 20 action, what the feature creates or changes, and how another team knows it can proceed. Include external providers, imported files, scheduled actions and manual handoffs. A workflow can look complete inside one application while leaving finance, support or operations with an unresolved task.

Agree measurable acceptance evidence before configuration begins. Useful evidence may include a linked source record, a correctly restricted user test, a reconciled transaction, an exception with an owner, or a report that ties back to individual records. Avoid acceptance statements such as “the feature is enabled” because enablement does not prove the business outcome.

A practical rollout sequence

Define the outcome. State the business result and the evidence that proves it.
Confirm availability. Check edition, hosting, installed applications, localization and external service needs.
Map ownership. Identify who configures, uses, reviews and supports the workflow.
Prepare test cases. Include a normal case, missing data, a correction, a refused action and a downstream failure.
Test permissions. Use ordinary roles and verify both allowed and blocked actions.
Release narrowly. Pilot with a controlled group before wider rollout.
Review exceptions. Track unresolved records, repeated manual changes and failed automation.

Data and permission controls

Use the minimum access needed for the task. The person who prepares information may not be authorised to approve a financial, employment, customer or security outcome. Where a feature uses AI or an external service, document which data leaves the immediate workflow, which identity performs the action and how credentials can be revoked.

Keep authoritative information in the appropriate Odoo record rather than copying sensitive material into prompts, spreadsheets and private messages. If an exception needs external evidence, retain the reference according to the organisation’s privacy and document retention policy.

Testing before production

Run the workflow from start to finish and inspect the downstream result, not only the screen where the action began. Check reports, chatter, linked records, notifications and integrations. Repeat the test with incomplete or conflicting data and confirm that the process stops safely or creates an owned review item.

Record the Odoo build, installed applications, important configuration and test result. Screens and behaviour can change through later updates, so a dated test record is more useful than an undated screenshot.

Go live and support

Release the feature with named support ownership and a short operating guide. Tell users what the feature will do, what it will not do and where uncertain records should go. Monitor the first real transactions closely enough to compare them with the accepted test cases.

Set a review date after the initial release. Look for unused configuration, repeated overrides, permission requests, duplicate actions and external service failures. If staff are working around the feature, investigate the reason before adding more automation. The workaround may reveal a missing decision or an unrealistic process assumption.

Illustrative example

A planner spots component risk in the overview, opens the underlying order and confirms the actual shortage before rescheduling.

This is an illustrative scenario, not a client result or a test on a live database. The transferable method is to compare the expected business outcome with the records Odoo creates, resolve differences with an accountable owner and keep enough evidence for another reviewer to understand the decision.

Limits and boundaries

A dashboard summarizes recorded data. Late validation or incorrect routes can still make the picture misleading.

Odoo documentation explains product behaviour. It does not replace accounting, tax, employment, privacy, safety, legal or sector advice. Have the appropriate specialist define regulated requirements before configuration, then test whether the system produces the required evidence.

Common mistakes

Treating availability as readiness. A visible feature still needs ownership, permissions, testing and support.

Testing only the successful route. Missing data, conflicts, retries and refused actions often reveal the real risk.

Using administrator access as the user test. It hides permission and company boundary problems.

Assuming automation owns the outcome. A named person still needs to review exceptions and repeated failures.

What the owner should review

Review adoption, failed actions, manual overrides, records waiting without an owner, permission changes and differences between expected and actual downstream results. Sample individual records as well as totals. Repeated exceptions usually point to unclear policy, incomplete data, training, unsuitable access or an integration boundary.

Read Odoo Manufacturing Backorders: Close Only What Was Produced for the connected workflow and earlier version context.

Official Odoo 20 source

Official Odoo 20 documentation or release notes

Source reviewed from the official Odoo 20 documentation and release notes in November 2026. Confirm the documentation for the installed build before implementation.

If you need help assessing or implementing Odoo 20, see my Odoo consulting services.