Specialist ERPsERP Platform

Odoo Manufacturing + private AI

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

Short answer

AI for Odoo connects a private LLM to the Odoo ORM and PostgreSQL database so planners, buyers, and shop-floor leads can ask plain-English questions about mrp.production, mrp.bom, and stock.quant and get answers grounded in live data, with the underlying domain filter shown. It runs on-prem or in a private cloud next to your existing Odoo Community or Enterprise instance, so customer BoMs, costs, and supplier terms never leave your infrastructure.

ERP: Odoo Manufacturing, Odoo Enterprise, Odoo Community
Industries: Manufacturing, Distribution
Written for: Operations Manager

Discuss your Odoo Manufacturing environment See use cases

Odoo grew from a lightweight open-source accounting tool into a full manufacturing ERP largely through Studio, custom modules, and a very permissive ORM. That flexibility is the reason mid-market manufacturers picked it over heavier platforms, and it is also why every Odoo instance ends up looking slightly different from every other one after two or three years of go-lives, acquisitions, and app-store additions.

The result is an ERP where the data model is genuinely powerful (any user with ORM access can, in principle, query any linked model) but where almost nobody outside the implementation partner actually knows the field names well enough to use that power. Planners ask the same questions in Slack every Monday morning that a well-built AI layer could answer in seconds directly from mrp.production and stock.quant.

Odoo's own AI additions (IAP-based suggestions, the built-in Spreadsheet AI helper) are useful for surface-level tasks but route through Odoo's cloud services and are not designed for grounded, auditable question-answering over your specific customizations, your specific chart of accounts, or your specific work center naming conventions. Manufacturers running Odoo self-hosted, in a VPC, or under a customer NDA that restricts data flow need something that stays inside the boundary they already control.

This page covers what AI on top of Odoo Manufacturing actually looks like in practice: which models and APIs it touches, where a private LLM fits next to a self-hosted or Odoo.sh instance, and what questions to ask before you let anyone plug an AI agent into your production database.

What usually gets in the way

The problems we hear most from operations manager teams running Odoo Manufacturing.

Reporting stops where dashboards stop

Odoo's built-in dashboards and the Spreadsheet app cover the questions someone anticipated when they built the view. Anything ad hoc ("which work orders are behind because of the same component shortage") means exporting to Excel or filing a ticket with whoever wrote the last custom report.

Studio and custom modules drift from the vendor baseline

Every added field in Studio, every inherited model, every custom module from the App Store makes the next major version upgrade (17.0 to 18.0, for example) riskier and makes generic documentation less useful, because your instance is no longer quite the instance the manual describes.

Multi-company and multi-warehouse hides true availability

With intercompany rules, multiple stock.warehouse records, and routes that vary by company, a simple question like "do we have enough of this component" requires knowing which warehouses count and which don't, knowledge that usually lives with one planner.

Odoo-specific talent is scarce and unevenly priced

Functional-technical consultants who know both manufacturing operations and the Odoo ORM well enough to build reliable customizations are in short supply outside the largest partner firms, and turnover on that one internal expert is a real operational risk.

The ORM's power is locked behind field names nobody remembers

mrp.production, mrp.workorder, stock.move, stock.quant, purchase.order.line: the data to answer almost any operational question is there, but only someone who has spent real time in Odoo's technical documentation can write the domain filter to get it.

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.

Natural-language BoM and work order queries

Planners ask questions like "which open manufacturing orders are waiting on a component from this supplier" in plain English and get an answer built from a live query, not a cached report.

Touches: mrp.production, mrp.bom, mrp.bom.line, stock.quant

Outcome: Cuts the daily round of Slack messages to the planning team from a running list to a self-serve question, freeing planners for exceptions.

Shop-floor work order assistant

Operators ask a tablet-based assistant for the current routing step, linked quality checks, or the reason a work order is on hold, without leaving the work center screen.

Touches: mrp.workorder, mrp.routing.workcenter, quality.check

Outcome: Reduces the number of times a supervisor is pulled away from the floor to answer a routing or quality-check question.

Purchase order follow-up agent

An agent reviews open purchase.order.line records against promised dates and drafts a follow-up email to the buyer for review, rather than a human scanning the purchase dashboard every morning.

Touches: purchase.order, purchase.order.line, stock.picking

Outcome: Turns a manual morning review into a queue of drafted follow-ups a buyer approves in minutes.

Work order exception triage

When a work order stalls, the agent checks linked stock moves, quality checks, and maintenance.request records to summarize the likely cause before an operations manager investigates.

Touches: mrp.workorder, maintenance.request, stock.move

Outcome: Shortens the time between a stall being noticed and someone knowing why it happened.

Quality alert and non-conformance drafting

When a quality.check fails, the assistant drafts a quality.alert with the relevant lot, work order, and prior similar failures pre-filled, for the quality lead to review and submit.

Touches: quality.check, quality.alert, stock.lot

Outcome: Cuts the time to file a usable non-conformance record from a distracted-form-fill to a two-minute review.

Multi-company, multi-warehouse inventory visibility

A single natural-language question resolves across every stock.warehouse and company the user has access to, instead of requiring a saved filter per site.

Touches: stock.quant, stock.warehouse, res.company

Outcome: Gives group-level operations visibility without building and maintaining a cross-company reporting view by hand.

Customization and Studio field documentation

The assistant reads ir.model.fields, Studio-added views, and custom module code to answer "what does this field actually do and who added it," turning tribal knowledge into a searchable answer.

Touches: ir.model.fields, ir.ui.view, custom module source

Outcome: Reduces onboarding time for new administrators and lowers the risk when the one person who remembers a customization leaves.

Reference architecture

The AI layer sits beside your existing Odoo deployment (self-hosted, Docker, or a private VPS) and reads through Odoo's own ORM and API rather than bypassing it, so every answer respects the record rules and access groups already defined in Odoo.

1
Odoo connector
Connects via XML-RPC, JSON-RPC, or the Odoo external API using a dedicated read-focused API user, so queries run inside Odoo's own record rules and multi-company access controls.
2
Semantic layer
Maps mrp.*, stock.*, purchase.*, and quality.* models (including Studio-added fields) to business terms planners and buyers actually use, so "late orders" resolves correctly without a developer writing the domain filter each time.
3
Model serving
An open-weight model (Llama, Qwen, Mistral, or similar) served with vLLM or Ollama on customer-owned or customer-controlled GPUs, sized to Odoo's typical transaction volumes for mid-market manufacturers.
4
Retrieval and agents
Retrieval-augmented generation grounds answers in live ORM queries; agents that draft purchase follow-ups, quality alerts, or documentation require explicit human approval before any write-back.
5
Governance and audit
Every question and the generated domain filter are logged, mapped to the requesting Odoo user and their existing access groups, so the audit trail matches what Odoo itself would show.

Integration notes for your ERP team

Connects through Odoo's XML-RPC or JSON-RPC external API, or a dedicated REST module, using a scoped API user rather than a superuser account.
Domain filters are generated to match Odoo's own ORM search syntax, so results respect record rules, multi-company rules, and field-level access already configured.
Studio-added fields and custom modules are indexed from ir.model.fields so the assistant stays current after a functional consultant adds new fields.
Optional read-replica PostgreSQL connection for heavier analytical questions that would be slow through the ORM API alone.
Write-back actions (draft POs, quality alerts, follow-up emails) go through Odoo's own base_automation or a queued action a human approves, never a direct database write.
Version-aware: the connector is built and tested against your specific Odoo version (13 through 18) rather than assuming a generic schema.
Works with self-hosted, Docker-based, and Odoo.sh deployments; Odoo.sh's own infrastructure constraints (no root SSH) are handled through the standard API layer, not a workaround.

Deployment options

Air-gapped on-prem

Manufacturers self-hosting Odoo behind their own firewall, especially those serving defense or export-controlled customers who cannot allow ERP data to reach any public API.

The model, retrieval layer, and Odoo connector all run on customer-owned hardware with no outbound path; PostgreSQL access stays local to the network.

Private or sovereign cloud

Companies already running Odoo.sh or a managed VPS who want AI without operating GPUs themselves.

Deployed in a dedicated tenant or VPC under the customer's own cloud agreement, isolated from Odoo's own SaaS infrastructure and from any shared multi-tenant AI service.

Hybrid

Groups with a mix of self-hosted plants and Odoo.sh-hosted subsidiaries after an acquisition.

A central retrieval and governance layer connects to each Odoo instance through its own API user, with per-site data residency preserved rather than centralized into one database.

Compliance and data control

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

GDPR / regional data protection

Deployment inside the customer's own infrastructure means personal data in HR, CRM, or customer records never transits a third-party AI API, simplifying the lawful-basis and data-transfer analysis.

Customer NDAs and flow-down clauses

Manufacturers who accepted "no cloud AI on our data" terms from an OEM customer can point to an architecture where the model runs on infrastructure they control, not a SaaS AI vendor's servers.

PCI DSS (where a payment module is active)

The AI layer is scoped to read-only access outside cardholder-data tables; payment records are excluded from retrieval by default.

SOC 2 expectations from downstream customers

Access logging, role mapping to existing Odoo security groups, and no external data egress give you concrete answers for a customer's vendor security questionnaire.

Where Netray fits

ERPray

Odoo's ORM-based data model, once mapped to a semantic layer, is a good fit for ERPray's grounded natural-language question answering and dashboards, especially for planners and buyers who don't want to learn Studio.

Custom build

Manufacturers with heavy Studio customization or unusual custom modules often need a bespoke connector and agent set built around their specific fields rather than a generic template.

How an engagement runs

Phase 1 . 2-3 weeks

Discovery

-Inventory of Studio fields, custom modules, and relevant mrp.*/stock.*/purchase.* models
-Access and security-group review
-Priority use cases ranked by planner and buyer pain
-Deployment option recommendation (on-prem, private cloud, hybrid)

Phase 2 . 6-8 weeks

Pilot

-Working connector against a non-production Odoo instance
-3-5 use cases live for a pilot group
-Accuracy review against known correct answers
-Governance and logging validated against existing Odoo access groups

Phase 3 . 4-6 weeks

Production

-Cutover to the production Odoo instance with a read-only service account
-Full audit logging in place
-Runbook for adding new use cases without redeploying the whole system
-Handoff documentation for your internal Odoo administrator

Phase 4 . Ongoing

Scale

-Expansion to additional companies or warehouses in a multi-entity instance
-Additional agent use cases with write-back approval workflows
-Model refresh as open-weight options improve
-Quarterly review of usage and accuracy against real questions asked

Questions to ask any vendor, including us

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

Does the AI layer read through Odoo's own ORM and record rules, or does it require a separate, wider database credential?
Where does the model actually run, and can you show us the network path to confirm no data leaves our environment?
How does the system handle Studio-added fields and custom modules without a developer re-mapping them by hand each time?
What happens when our next major-version upgrade changes field names or removes a model the AI relies on?
Is every generated query and answer logged against the requesting user's own Odoo access group?
What is the actual hardware requirement, and can it run on GPUs we already own or plan to buy anyway?
Can we start with question-answering only, with no write-back, before considering agents that draft or submit records?
What happens to the deployment if we ever cancel: do we keep the connector code, the prompts, and the logs?

Frequently asked questions

Can AI work with a heavily customized Odoo instance?

Yes, but the semantic layer has to be mapped to your actual fields, including anything added through Studio or a custom module, rather than assumed from a generic Odoo schema. That mapping is most of the discovery-phase work and is what determines whether answers are trustworthy.

Does this replace Odoo's own AI features?

No. Odoo's built-in AI (IAP suggestions, Spreadsheet AI) handles narrow, surface-level tasks and routes through Odoo's own cloud services. A private AI layer is for grounded, auditable question-answering and agents over your specific data, run on infrastructure you control.

Is this only for large Odoo Enterprise deployments?

No. It works with Odoo Community and Enterprise, self-hosted or on Odoo.sh, and scales down to a single-plant instance. The main requirement is a reasonably well-understood data model, which discovery work establishes regardless of company size.

How do you handle multi-company and multi-warehouse access control?

The connector uses a scoped API user and generates queries that respect Odoo's own record rules and company-level access, so a user only ever sees what their existing Odoo permissions already allow. Nothing bypasses Odoo's access model.

What happens if an Odoo version upgrade changes the schema?

Version upgrades are handled as a planned, tested step: the connector and semantic layer are validated against the new version before cutover, similar to how any other integration or customization is retested during an Odoo upgrade project.

Can the AI write data back into Odoo, like creating a purchase order?

It can draft records, such as a follow-up email or a quality alert, but any write-back requires explicit human approval through Odoo's own workflow or a reviewed queue. Nothing is written directly to the database without a person confirming it.

What does this cost compared to a custom reporting project?

Costs vary with the number of use cases, the deployment model, and how much Studio customization needs mapping, but the mechanism is comparable to a mid-sized custom reporting or BI project, with the AI layer covering a much wider range of ad hoc questions over time.

Related guides

Ask your ERP anything

Natural Language Query for ERP Data: Ask SAP, Infor, or Oracle a Question in Plain English

See how natural language query over SAP, Infor, Oracle, and NetSuite data works: grounded text-to-SQL, role-based permissions, and a visible audit trail.

RAG + SQL + permissions

A Private LLM Grounded on Your ERP Data

How a private LLM answers questions on your ERP data: RAG plus text-to-SQL, role-based permissions inherited from the ERP, and where each fits.

Agents + approval gates

AI Agents for ERP, Running On-Prem

A practical guide to on-prem AI agents for ERP: what they can safely automate, where human approval belongs, and how to design the guardrails.

ERP AI Buyer Guide

How to Choose an ERP AI Implementation Partner

A CIO checklist for picking an ERP AI implementation partner: the architecture questions to ask, red flags, pricing models, and what to demand in the SOW.

ERP AI Cost Guide

What ERP AI Actually Costs: A CFO's Guide

A CFO's guide to what ERP AI actually costs: GPU hardware, model licensing, integration and connector work, and realistic ongoing run-rate ranges.

ERP AI readiness

Is Your ERP Ready for AI? A Readiness Assessment Checklist

Is your ERP actually ready for AI? A practical checklist covering master data quality, access and permissions, GPU sizing, and governance before you fund a pilot.

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