Odoo for Manufacturing: MRP II, WMS and Quality on the Shop Floor

Industrial Odoo is what happens when an ERP built for SME management has to govern real factory operations: orders executed on machines, lots that must be traced and a warehouse that does not wait. This guide documents which Odoo modules hold up on the shop floor (MRP II, WMS, quality, traceability), which ones demand caution, how the ERP connects to the OT layer, and which implementation process avoids the usual pattern: a system that works for six months and is then abandoned.

Why Odoo is popular and why it gets complicated on the shop floor

Odoo was born in 2005 as TinyERP, a management ERP for SMEs: sales, purchasing, accounting and a warehouse designed around customer orders; e-commerce arrived with version 8. In that domain it works very well, and that is where its popularity among SMEs comes from: it is modular, the licence cost is contained compared with the classic ERPs, the community is huge and almost any local partner knows how to install it.

The problem appears when a plant asks for real MRP II. Odoo has manufacturing modules, but much of its original design does not assume the constraints of a workshop: a running machine does not stop to wait for someone to reorder the work queue, a raw material warehouse needs decisions in seconds and a night shift does not call support when the order does not add up. When the configuration forces the plant to behave like an online shop, the plant always wins: people stop recording, the data drifts away from reality and the ERP turns into an accounting system nobody looks at.

The sequence repeats itself in many industrial SMEs: Odoo is implemented with the standard configuration, the limitations are discovered at month three, the gaps are patched with spreadsheets and custom development, and a year later nobody understands the complete system. Two years later the company considers "changing ERP", when the ERP was never the underlying problem.

Odoo can work on the shop floor, but it demands three things the standard installation does not provide:

• Knowing which modules genuinely work in industry and which ones are better left switched off.
• A clear integration architecture with machines and OT systems, not a collection of improvised connectors.
• A configuration that respects the real flow of the operation instead of forcing it into e-commerce flows.

That is exactly the approach we follow in the Odoo for industrial SMEs solution from Captia Service: the ERP as the backbone of the operation, not as a catalogue with factory modules bolted on.

Modules that do work in real plants

Manufacturing and MRP II

Odoo's manufacturing module covers the essentials of an MRP II: it explodes the bill of materials (BOM), calculates net requirements against stock and open orders, and generates purchase and production orders with their dates. For an SME that plans in Excel today, that leap alone changes the operation: purchasing stops depending on the manager's memory and production orders carry their consumptions and routings with them.

Its limits are also well known. Odoo's planner handles finite capacity in a limited way and is not designed for real-time rescheduling. Our usual configuration accepts that: Odoo generates the medium-term plan, and the short-term adjustments (the next 24 to 48 hours) are managed with rules or with an external sequencer that respects the plant's real constraints, instead of asking the MRP for something it was not designed to do.

Inventory and WMS

Odoo's inventory, with routes, locations and removal strategies, handles warehouses of low to medium complexity well: raw material, work in progress and dispatches for a typical industrial SME. In complex logistics installations (warehouse automation, picking waves, dozens of docks) the sensible choice is for Odoo to act as the accounting mirror of a specialised WMS, with the synchronisation between the two defined precisely: which system owns each piece of data and at what moment it is consolidated.

Quality

The quality module lets you define control points per operation, inspection sheets, alerts and lot holds. Where it shines is when the results are not typed in by hand: if the reading from the scale, the vision system or the machine parameter arrives automatically at quality control, the record stops being an administrative burden and becomes a by-product of the process itself.

Lots and serial numbers

Odoo's lot and serial number traceability is solid and it is critical in regulated sectors: food and beverage, chemicals, components with customer requirements. As with quality, the key is to automate the capture with barcodes, RFID or machine data. Traceability that depends on an operator remembering to scan is traceability with holes in it.

Modules that work, with caveats

Maintenance

The maintenance module is fine for scheduling preventive work, logging corrective jobs and keeping the history per asset. It falls short as an advanced CMMS, but it fits very well as a receiver of work orders: in plants that already monitor their equipment, an alert from a predictive maintenance system can automatically become a work order in Odoo, with the spare part reserved in inventory. There the module contributes what an ERP does best: closing the administrative loop on something that happens in the physical world.

Purchasing and suppliers

For standard orders against a price list, the purchasing module works without friction and feeds directly from the MRP. Complex processes (framework contracts, volume tiers, supplier qualification with documentary requirements) need careful configuration or integration with dedicated procurement tools.

Human resources and timesheets

Clocking in, absences and timesheets cover the administrative need. What you should not do is use manual timesheets as the source of production times when machine data exists: the real time of an order should come from the start and finish events on the floor, not from what gets written down at the end of the shift.

Modules that rarely fit in industry

Projects: designed for agencies and professional services. In make-to-order manufacturing it can serve for engineering milestones, but it does not replace the manufacturing order as the plant's unit of management.

CRM: useful for the company's sales team, irrelevant to the factory operation. Enabling it does no harm, but it must not shape the design of the industrial flow.

Point of sale: for shops. If a factory uses it (direct sales at the warehouse, an outlet), it should be isolated from the production inventory circuit so it does not contaminate the plant data.

The discipline of not enabling modules "because they come included" is one of the most profitable design decisions in an Odoo project: every active module adds screens, permissions, data to maintain and paths to error.

The ERP connected to the plant: why OT integration decides the project

An industrial ERP is worth what its data is worth, and a factory's data is born in the machines. If the only way in is the keyboard, the ERP lives hours or days behind reality: theoretical stock does not match physical stock, orders show as open when they finished long ago and the real manufacturing cost is an estimate. The difference between an Odoo that gets used and an Odoo that gets tolerated is almost always here.

Connecting the ERP to the plant means the relevant events flow in both directions without manual intervention:

• From the floor into Odoo: order start and finish, good and rejected quantities, real consumptions, relevant stoppages, inspection results.
• From Odoo to the floor: the order queue with its materials and routings, priority changes, quality holds on specific lots.

This is Captia Connect territory. The ERP to shop floor integration solution solves exactly that bridge: capturing events from machines and lines, normalising them and synchronising them with the ERP under a defined data contract. When the Odoo project and the connectivity project are designed together, the ERP goes live already fed with real data; when they are designed separately, the integration ends up as a fragile bespoke development nobody wants to touch.

For the technical foundation of that layer (why a unified namespace beats point-to-point integrations), the reference is our guide to OT/IT architecture and the unified namespace.

Reference architecture: Odoo plus the OT layer

The architecture we install in real plants has four layers, each with a clear responsibility:

Two design rules avoid most of the problems. First: every piece of data has a single owner. The physical state of the machine belongs to the OT layer; the administrative state of the order belongs to Odoo; the middleware translates, it does not decide. Second: the integration is built read-first (the floor reports to Odoo) and only later write (Odoo instructs the floor), because read errors can be detected and corrected without stopping production, whereas a write error stops a line.

A note on layer 4: if the goal is measuring efficiency, the reference indicator is OEE, and calculating it well has more nuances than it seems. Our complete OEE guide covers the formulas, the typical measurement mistakes and how to feed it with automatic data instead of manual reports.

Master data: the BOM rules

No part of an industrial Odoo project has a worse ratio between how boring it looks and how decisive it turns out to be. The MRP calculates from the BOM, the routings and the lead times: if that data is wrong, the system generates wrong orders with total precision. Before going live you have to answer uncomfortable questions:

• Does the BOM reflect what the plant really consumes, including scrap and auxiliary materials, or is it the theoretical list engineering drew up five years ago?
• Do the routings carry measured times per operation, or inherited estimates nobody has checked against machine data?
• Are the supplier lead times the ones agreed in the contract or the ones actually met in practice?
• Who owns each master record and through what process is it modified?

A worked example of the kind of detail that matters: in a plastic injection BOM, the difference between recording the theoretical resin consumption per part or the real consumption including sprues and purges can be several percentage points. With theoretical consumption, the resin stock in Odoo is always a surplus on paper and a shortage in the silo, the MRP buys late and the plant ends up phoning the supplier, which is exactly what the system was supposed to eliminate. The solution is not a module: it is measuring real consumption for a few weeks, correcting the BOM and establishing who maintains it.

Phased implementation: how Captia approaches it

Phase 1: operation flow analysis (around two weeks)

Mapping the current flow end to end: where decisions are made, what data each decision uses, where the process breaks today. The design comes out of this: which part of Odoo will be rigid (the module standard) and which part must be flexible (configuration or integration). This analysis connects with our process integration work: the ERP is the central piece, but the project is the complete flow.

Phase 2: base configuration (around four weeks)

Structure without transactions: products, BOMs, routings, work centres (the machines modelled as resources with capacity), warehouses and locations, suppliers and price lists. It is also the master data cleansing phase described above.

Phase 3: OT integration (around four weeks)

Building the middleware on top of the connectivity layer: read first (floor events update Odoo), then write (Odoo orders reach the floor). Every message with its data contract, its queue and its retry; an integration that silently loses events is worse than no integration at all.

Phase 4: parallel-run validation (two to four weeks)

The old system and Odoo run side by side. Every divergence between the two gets investigated: sometimes the error is in the new configuration, sometimes the old system had been wrong for years and nobody knew. The old system is not switched off until the figures match consistently.

Phase 5: gradual go-live

First one production line, then the next. No big bang: the cost of starting everything at once is that any problem hits the whole factory on the same day, with the entire team learning the system at the same time.

After go-live: adoption and support

An ERP is not finished on go-live day. The first weeks concentrate the users' real doubts, and without a training and support plan the system degenerates into shortcuts and after-the-fact entries. That accompaniment is a discipline in itself; we cover it in the guide to industrial digital training and support.

Typical mistakes that kill an industrial Odoo

• Replicating the old system inside Odoo. Customising the ERP until it behaves like the previous software inherits all its vices and adds the cost of maintaining the developments on every version upgrade.
• Customising before mastering the standard. A good share of the bespoke developments we find in audits replicate functions the standard module already did with a different configuration.
• Going live without cleansing the master data. The MRP amplifies the quality of the data it receives, in both directions.
• Leaving the shop floor integration "for phase 2". Phase 2 never arrives, and in the meantime the ERP is fed by hand and loses credibility precisely in the period when it needs it most.
• Confusing training with adoption. One training session the day before go-live does not build habit. Adoption is won in the weeks that follow, with close support and by correcting the flows reality proves awkward.
• Not defining who owns the system. Without an internal owner with authority over configuration and data, every department pulls the ERP its own way and the whole degrades.

Many of these mistakes are not specific to Odoo: they are failures in managing a digitalised workflow. That is why we usually pair ERP projects with business process automation work in the administrative circuits that surround the factory: orders, delivery notes, invoicing, quality documentation.

Costs and return: where the money comes from

An industrial Odoo project with shop floor integration sits, as the usual order of magnitude in the market for an SME, in the range from tens of thousands to slightly above one hundred thousand euros across licences, implementation and integration. The specific figure depends above all on three factors: the number of flows to integrate with the plant, the state of the master data and how much customisation the company decides to take on.

The return does not come from the technology itself, but from concrete operational effects:

The practical consequence: the return only materialises if the ERP receives real data. An Odoo fed by hand barely reduces inventory and does not give reliable costs, because its picture of the plant always runs late. It is one more reason why OT integration is not an extra on the project, but its condition of profitability.

What Odoo is not

It is not a smart factory on its own. It is the administrative record of what the factory does. The intelligence (better sequencing, failure prediction, consumption optimisation) lives in systems that lean on the ERP, not inside it.

It does not replace human decisions. The planner still decides what gets released and when; Odoo calculates requirements and shows consequences. An MRP left in automatic mode without supervision generates orders nobody has thought about.

It is not an MES or a SCADA. It does not supervise machines in real time or manage second-by-second execution. Asking it to do so leads to customisations impossible to maintain; the correct answer is the layered architecture described above.

It does not work with dirty data. If the BOM is wrong, Odoo generates wrong orders. The master data project is not optional.

Frequently asked questions about industrial Odoo

Odoo can be the administrative heart of an industrial operation if it is configured with shop floor judgement and connected to the physical reality of the factory. At Captia we always start the same way: a diagram of the current operational flow, on which we decide which modules sustain it, what gets integrated with the OT layer and in what order it is deployed. Tell us how your plant works today and we will look at your case.