Specialist ERPsUse Case

Odoo MRP + private AI

AI for Odoo Manufacturing (MRP): BOMs, Work Orders and Shortages

Short answer

AI on Odoo Manufacturing reads manufacturing orders, BOMs, work orders and stock moves through the external API or a read replica, then answers questions such as which orders will miss their date because a component is short. It proposes changes for a planner to approve and does not write to Odoo on its own.

ERP: Odoo Manufacturing, Odoo MRP, Odoo Inventory
Industries: Discrete manufacturing, Electronics assembly, Light industrial, Contract manufacturing
Written for: Production Manager or Operations Director running Odoo MRP

Discuss your Odoo Manufacturing environment See use cases

Odoo's Manufacturing app is easy to start with and easy to bend. A small plant can go from spreadsheets to bills of materials, routings, work centers and manufacturing orders in weeks. The cost of that flexibility shows up two years later: duplicated BOM variants, routings nobody trusts, reordering rules set once and never revisited, and a planner who rebuilds the real schedule in a spreadsheet every Monday.

The data to fix most of this is already in Odoo. Every manufacturing order sits in mrp.production, every component demand is a stock.move, every operation is an mrp.workorder tied to an mrp.workcenter, and every shortage is visible as a reservation that could not be made. What is missing is someone with time to read it all, every day, across every open order.

That is the realistic job for AI here. It does not replace the Odoo scheduler or the MRP run. It reads the output, explains it, flags what looks wrong and lets a production manager ask questions in plain language instead of building another saved filter.

This page covers what AI can and cannot do on Odoo Manufacturing, how it connects, what to keep private and how a first project is usually scoped. If Odoo's own features or a simple dashboard answer your question, we say so below.

What usually gets in the way

The problems we hear most from production manager or operations director running odoo mrp teams running Odoo Manufacturing.

BOM sprawl and stale routings

Variants, phantom kits and copied BOMs accumulate in mrp.bom and mrp.bom.line. Nobody can say which BOM is the one actually built, and scrap factors and operation times drift from reality.

Shortages found at the work center

A manufacturing order shows Waiting for components, but the planner only sees it when the shop floor complains. Reservation failures are visible in the data well before the start date.

Work order times that do not match reality

Expected duration on mrp.routing.workcenter is a guess. Real time from the work order time tracking is in the database but rarely compared to the plan.

Reordering rules nobody tuned

Min and max values on stock.warehouse.orderpoint were set at go-live. Lead times, seasonality and supplier changes have since moved the real need.

Planning knowledge lives in one head

The planner knows which supplier is always late and which operation always overruns. That knowledge never reaches the system or the next hire.

Where AI earns its place in Odoo Manufacturing

Each use case names the ERP objects it reads or writes, so your ERP team can judge the integration effort before anyone commits budget.

Ask the shop floor questions in plain language

A production manager asks which open manufacturing orders are blocked and why. The assistant translates to a query on mrp.production and stock.move, shows the query and returns a ranked list.

Touches: mrp.production, stock.move, stock.move.line, product.product

Outcome: Replaces a daily manual filter-and-export routine; typically saves a planner 30 to 60 minutes a day.

Component shortage early warning

Compares demand from confirmed manufacturing orders with on-hand, incoming purchase receipts and lead times, then lists orders likely to slip with the missing component named.

Touches: mrp.production, stock.quant, purchase.order.line, product.supplierinfo

Outcome: Moves shortage discovery from the day of production to several days earlier, which gives purchasing room to expedite.

BOM and routing hygiene review

Finds BOMs with no recent manufacturing orders, components with zero cost, duplicate variants and routings whose recorded time differs strongly from the plan.

Touches: mrp.bom, mrp.bom.line, mrp.routing.workcenter, mrp.workorder

Outcome: A reviewable cleanup list instead of a vague feeling that the BOMs are a mess.

Planned vs actual duration analysis

Compares expected and real duration per operation and work center, and suggests updated times for an engineer to approve.

Touches: mrp.workorder, mrp.workcenter.productivity, mrp.routing.workcenter

Outcome: More credible scheduling and costing; quoted lead times get closer to what the floor delivers.

Reordering rule recommendations

Reads consumption history and supplier lead times and proposes min and max values per product and warehouse. Changes go to a buyer for approval.

Touches: stock.warehouse.orderpoint, stock.move, product.supplierinfo

Outcome: Fewer stock-outs on fast movers and less cash tied up in slow ones, without a full planning project.

Scrap and yield pattern detection

Groups scrap orders by product, work center, operator shift and component lot to point at where yield loss concentrates.

Touches: stock.scrap, mrp.workorder, stock.lot

Outcome: Directs a quality or process engineer to a short list of causes rather than a month of data pulling.

Draft shift handover summary

Builds a plain summary of what finished, what is late and what is blocked at the end of a shift from work order and manufacturing order states.

Touches: mrp.workorder, mrp.production, mrp.workcenter

Outcome: A consistent handover that a supervisor edits in minutes instead of writing from scratch.

Reference architecture

A read-only service connects to Odoo through the external API or a PostgreSQL read replica, indexes the manufacturing objects and runs an open-weight model on infrastructure you control. Anything that changes Odoo goes through a proposal and approval step.

1
Data access
XML-RPC or JSON-RPC on the Odoo external API using a dedicated user with read access, or a streaming PostgreSQL replica for heavy analysis. Newer Odoo versions also offer a JSON-based external API.
2
Semantic layer
A mapping from Odoo models and fields (mrp.production state, date_start, product_qty, bom_id) to business terms, so the model reasons about orders and shortages and not table names.
3
Retrieval and reasoning
Structured queries for numbers, retrieval over BOM notes, chatter messages and attached work instructions for text, with every answer showing its source records.
4
Model serving
Open-weight models such as Qwen, Llama or Mistral class served with vLLM or Ollama on your GPU server or private cloud.
5
Action gate
Proposed changes (a new min quantity, an updated routing time) are queued for a named approver and applied through the Odoo API under that person's access rights.

Integration notes for your ERP team

Create a dedicated API user and use API keys instead of passwords; restrict it to the Manufacturing, Inventory and Purchase groups it needs to read.
Use search_read with explicit field lists and domains; avoid pulling whole models, which is slow on large stock.move tables.
For analysis over months of history, use a PostgreSQL read replica with a read-only role rather than the application API.
Custom fields from Studio or custom modules (x_ prefixed) must be added to the semantic mapping or the model will not know they exist.
Odoo version matters: field and model names such as routing and work center structures changed between major versions, so confirm yours before building queries.
Odoo scheduled actions (ir.cron) can trigger a nightly refresh of the index; avoid hitting the scheduler during the MRP run window.

Deployment options

On-prem next to a self-hosted Odoo

Plants running Odoo Community or Enterprise on their own servers

Model, index and Odoo replica sit on the same network. No manufacturing data leaves the building.

Private cloud in your region

Odoo.sh or hosted Odoo users with data residency rules

Inference runs in your own tenancy and pulls through the API over a restricted connection.

Air-gapped plant network

Defense, aerospace or regulated plants

A periodic replica is copied into the isolated network and the AI works from that. Answers lag by the sync interval, which is the honest trade-off.

Compliance and data control

How the architecture supports your obligations. Certification and accountability stay with your organisation; the design keeps the evidence straightforward.

ISO 9001 traceability

Lot and serial links on stock.lot and stock.move.line are used for genealogy questions; the AI reads them and never edits them.

Access control

Queries run under the asking user's Odoo access rights and record rules, so multi-company and warehouse restrictions carry over.

GDPR and data residency

Employee and customer fields are masked or excluded from the index where not needed; inference stays in your chosen region.

Export-controlled data

For ITAR or EAR work, the architecture lets you keep model, index and logs entirely on US-person-controlled infrastructure. The obligation stays with you.

Where Netray fits

ERPray

Grounded questions and shortage dashboards over live Odoo data, with the query shown and Odoo permissions respected.

Custom build

Needed for BOM hygiene scoring, routing time recommendations or write-back with approval into custom Odoo modules.

How an engagement runs

Phase 1 . 1 week

Discovery

-Odoo version, edition and hosting review
-List of 10 questions the planner asks most
-Data and access plan

Phase 2 . 1 to 2 weeks

Connect and map

-Read-only API user or replica
-Semantic mapping for mrp and stock models
-Custom field inventory

Phase 3 . 3 to 4 weeks

Pilot

-Shortage early warning on live orders
-Plain-language Q&A for planners
-Accuracy review against a manual check

Phase 4 . Ongoing

Extend

-BOM and routing hygiene report
-Reordering recommendations with approval
-Runbook and monitoring

Questions to ask any vendor, including us

A short list that separates real Odoo Manufacturing AI work from a chatbot demo.

Which Odoo version and edition are we on, and does the vendor support it?
Does the AI query as the asking user, or as one powerful service account?
Can I see the exact query behind every number?
What happens to Studio fields and custom modules we have built?
Can the whole stack run on our own servers with no external API calls?
How are write-backs approved and logged?
How do you measure answer accuracy before we rely on it?
What does the load on our Odoo instance look like?

Frequently asked questions

Does Odoo have built-in AI for manufacturing?

Odoo has been adding AI features such as assistants and text generation in recent releases, but they are general purpose and tied to the vendor's cloud options. For private deployment, deep questions over mrp.production and stock data, or custom approval flows, a separate layer is usually needed. Check what your version includes first.

Can AI replace the Odoo MRP scheduler?

No, and it should not. The scheduler and the procurement run are deterministic and auditable. AI reads their output, explains why an order is late and proposes parameter changes. A planner decides, and the scheduler continues to do the actual planning.

Will it write to Odoo?

Read-only is the default. If you want write-back, such as updating a reordering rule, it creates a proposal that a named person approves, and the change goes through the Odoo API under that person's access rights with a log entry.

Does it work with Odoo Community?

Yes. The external API and the PostgreSQL schema are available in Community. Some Enterprise-only modules, such as Quality or PLM, add models that Community lacks, so the available questions differ by edition.

How much data is needed to get useful results?

Shortage warnings and Q&A work from current data on day one. Duration analysis and reordering recommendations need several months of completed work orders and stock moves to be credible. Sparse history gives weak suggestions and we say so.

Is a GPU required?

For a mid-size plant with a few users, a single modern GPU server running a 7B to 32B parameter model is typically enough. Heavier models or many concurrent users need more. Sizing depends on your question volume and is part of discovery.

How long does a pilot take?

A read-only pilot on one plant usually runs 4 to 8 weeks including mapping and accuracy checks. Custom modules and multi-company setups extend that. We scope after reviewing your version and customization.

Related guides

Odoo Manufacturing + private AI

AI for Odoo Manufacturing That Reads Your Own Database, Not a Vendor's Cloud

Add grounded, natural-language AI to Odoo Manufacturing without sending MRP, BoM, or work order data to a public model. On-prem or private cloud, ORM-native.

ERPNext + Frappe + private AI

AI for ERPNext, Built on the Frappe Framework You Already Run

Ground AI in ERPNext's Frappe DocTypes for Work Order, BOM, and Job Card questions, deployed on-prem or in your own cloud, without exposing data to a third party.

Acumatica + private AI

AI for Acumatica Manufacturing Edition, Built on Your Own Data

Add AI to Acumatica Manufacturing Edition without giving up control of your shop and cost data. Private LLMs and agents grounded in your Acumatica instance.

SYSPRO + private AI

AI for SYSPRO, Grounded in Your Own Manufacturing Data

Add AI to SYSPRO without moving your manufacturing data to a public model. On-premise and private-cloud LLMs for SYSPRO in Australia, NA, and beyond.

Global Shop Solutions + private AI

AI for Global Shop Solutions, Built for How Job Shops Actually Run

Add AI to Global Shop Solutions without sending your quoting, scheduling, and job cost data outside your shop. Private, on-prem AI for GSS job shops.

QAD + on-prem AI

AI for QAD Adaptive ERP in automotive and industrial manufacturing

Add AI to QAD Adaptive ERP or Enterprise Edition for automotive and industrial manufacturing, grounded on QXtend and QAD's API layer, on-prem or private cloud.

Plan it with numbers

Free Tool

Talk it through with an engineer who knows Odoo Manufacturing

Bring one real question your team cannot answer from the ERP today. We will map the data path, the model, and where it runs, and tell you honestly if AI is the wrong tool for it.

Start the conversation See ERPray

All AI for ERP guides