DEV Community

Ankit Desai
Ankit Desai

Posted on

Odoo MRP for Discrete Manufacturing — What the Demo Doesn't Show You (Config Deep-Dive)

#ai #webdev #programming

The Demo Always Looks Clean. Real Implementations Are Different.

If you've evaluated Odoo for manufacturing, you've seen the demo. BoM loads, manufacturing order fires, work orders sequence across the screen. Satisfying. Logical.

Then the client asks something specific — three-shift operation, custom variant routing, rework flow, configure-to-order logic — and the answer gets vague.

This post covers what happens after the demo: the actual configuration decisions that determine whether Odoo maps to your floor or forces your floor to map to it.

MRP Is a Planning Engine, Not a Scheduling Board

Most people configure the Odoo MRP module as a production calendar. That's the smallest part of what it does.

What MRP actually manages:

  • Demand-driven MO generation from sales orders or scheduler runs
  • Multi-level BOM explosion — parent and child manufacturing orders sequenced automatically
  • Automated replenishment triggers (draft POs or sub-MOs when stock < reorder point)
  • Scrap recording at the workcenter level with variance capture

The key mental model: MRP traces the full component tree when demand fires, checks on-hand stock, applies lead times, and surfaces shortages before they stop the line.

Configured well, it's a genuine planning engine. Configured as a simple order entry tool, you'll end up reconciling shortages manually every morning.

Bill of Materials Architecture: Get This Wrong and Everything Else Is Wrong

The BoM is not just a parts list. It drives:

  • MO generation and component reservation
  • Work order creation via routing
  • Standard cost rollup
  • Replenishment signals to purchasing

BoM types and when each applies:

Standard BoM      → finished products, discrete manufacturing
Kit BoM           → sold-as-assembled bundles, no WIP posting
Sub-assembly BoM  → components requiring their own MO before parent consumption
BoM with variants → multiple SKU configs from a single master BoM
PLM-versioned BoM → engineering change control with approval workflow
Enter fullscreen mode Exit fullscreen mode

The cost rollup problem:
Odoo calculates standard cost by rolling component costs upward through the BoM hierarchy. A wrong BoM structure means wrong product costs, which means wrong inventory valuation, which means finance is reconciling manually every month.

BoM with variants — when to use it:
If you manufacture 40 variants of one product (size × finish × option), you do not want 40 separate BoMs. A single BoM with variant attributes and conditional components handles this cleanly. The wrong approach here creates a maintenance nightmare at the next engineering change.

# Odoo ORM example: query active BoM for a specific product variant
from odoo import models, fields, api

class MrpBom(models.Model):
    _inherit = 'mrp.bom'

    def get_bom_for_variant(self, product_tmpl_id, product_id):
        """Returns the applicable BoM for a given product variant."""
        domain = [
            ('product_tmpl_id', '=', product_tmpl_id),
            ('active', '=', True),
        ]
        bom = self.search(domain, limit=1)
        # Odoo handles variant filtering via product_id on the line level
        return bom
Enter fullscreen mode Exit fullscreen mode

Routing Configuration: Where Scheduling Accuracy Lives or Dies

Routing defines how a product moves through your floor: workcenters visited, sequence, time per operation, capacity consumed.

Work orders are generated from routing operations. Each maps to a workcenter. Each workcenter carries capacity parameters the scheduler uses to produce lead times.

The three configuration decisions that drive scheduling accuracy:

1. Time mode per operation 

Fixed time    → same duration regardless of qty (setup, inspection)
Per-unit time → scales with order qty (machining, assembly)
Per-lot time  → time per batch, for batch-process operations
Enter fullscreen mode Exit fullscreen mode

Mixing these up across your routing steps produces scheduling output that doesn't reflect your floor.

2. Workcenter capacity parameters 

Capacity:     number of simultaneous operations (machines or operators)
Efficiency:   actual vs. theoretical throughput (typically 75-90%, not 100%)
Availability: percentage of shift time available after breaks/changeovers
Enter fullscreen mode Exit fullscreen mode

If these are all set to 100%, your scheduled dates are theoretical maximums. You will miss them consistently.

3. Parallel vs. sequential operations

For concurrent production steps, set operations to parallel. Sequential is the default. Leaving concurrent operations as sequential makes the scheduler stack them end-to-end — lead times double, scheduling becomes incorrect.

Shop Floor Module: The Operator Interface Problem

Here is what consistently breaks manufacturing implementations:

The back office is configured carefully. Routing is correct, workcenters are set up, quality checks are defined. Then operators are pointed at the standard manufacturing interface.

The standard interface requires 4–6 clicks to log a work order step. Between machine cycles. On a device mounted at head height. With gloved hands.

Low adoption follows. Production data stops flowing in real time. Reporting reverts to manual. ROI disappears.

The Shop Floor module exists specifically for this problem:

Operator view:
- Work orders for THIS workcenter only (not the whole floor)
- Simplified login (badge scan or PIN)
- Single-tap time logging: Start / Pause / Done
- Quality checks appear inline as mandatory steps
- Scrap recording with reason codes

Supervisor view:
- Real-time status across all workcenters
- Running / Paused / Blocked / Done
- Operator assignments and queue depth
Enter fullscreen mode Exit fullscreen mode

The quality checkpoint implementation matters: quality steps defined in the routing appear as mandatory blocks. Operators cannot advance a work order past a quality gate without completing the check. Pass/fail is logged against the MO automatically.

Implementation rule: Mount tablets at each workcenter during UAT, not after go-live. Train on the Shop Floor module, not the back-office manufacturing screens. These are different interfaces for different users.

PLM: Activate It on Day One, Not When It Hurts

The typical pattern:

  1. Go-live without PLM
  2. Engineering changes go directly into production BoMs
  3. An operator runs a work order on an outdated specification
  4. Quality audit follows
  5. PLM gets activated

Activate it on day one. The setup cost is low. The cost of not having it compounds.

ECO workflow configuration:

Stage 1: Engineering Review    → engineering manager approval
Stage 2: Quality Gate          → quality manager approval
Stage 3: Approved              → BoM version publishes automatically
Enter fullscreen mode Exit fullscreen mode

Version behavior on manufacturing orders:

  • New BoM version approved → applies to all future MOs automatically
  • MOs already confirmed → continue on previous version until completion
  • No mid-run specification changes without explicit override

This is the correct behavior. In-progress orders should not switch BoMs mid-run. Configuring PLM stages correctly ensures version stability without manual intervention.

The End-to-End Flow in a Real Implementation

Putting the modules together in sequence:

Sales Order confirmed
        ↓
MRP scheduler runs (or MTO rule fires immediately)
        ↓
Manufacturing Order created
 - BoM version resolved (latest approved)
 - Components reserved (or purchase triggered)
 - Work orders generated from routing
        ↓
Work Order 1 appears in Shop Floor (Workcenter A)
 - Operator logs time → Start → Done
 - Components consumed and confirmed
        ↓
Quality check fires (if attached to routing step)
 - Operator completes check → Pass/Fail logged to MO
 - Fail → quality alert raised, work order blocked
        ↓
Work Order 2 unlocks (sequential routing)
        ↓
Final work order Done → MO auto-closes
 - Finished goods posted to stock
 - Actual vs planned costs calculated
 - Linked SO proceeds to delivery
        ↓
Engineering change needed?
 - ECO raised in PLM (NOT direct BoM edit)
 - Approval stages → new BoM version published
 - Future MOs pick up new version automatically
Enter fullscreen mode Exit fullscreen mode

One connected process, one database. No spreadsheet handoffs, no status trackers.

Real Setup Walkthrough: Custom Metal Enclosure Manufacturer

Three workcenters, two shifts, multiple variants, quality inspection before shipment.
Step 1 — BoM structure

Master BoM (with variants: size, finish, hardware type)
 ├── Sheet metal [required, qty scales with size attribute]
 ├── Frame sub-assembly [required → triggers sub-MO]
 │    ├── Steel tube
 │    └── Welding rod
 ├── M6 hardware kit [conditional on hardware_type = standard]
 └── Premium hardware kit [conditional on hardware_type = premium]
Enter fullscreen mode Exit fullscreen mode

Step 2 — Routing

Operation 1: Cutting & Bending    → Workcenter: Press/CNC   | Time: per-unit | 12 min/unit
Operation 2: Welding              → Workcenter: Welding Bay  | Time: per-unit | 25 min/unit
Operation 3: Final Assembly + QC  → Workcenter: Assembly     | Time: fixed     | 45 min
  └── Quality check: Visual inspection + dimension verify (mandatory before Done)
Enter fullscreen mode Exit fullscreen mode

Step 3 — Replenishment

Sheet metal:      min-max rule, 5-day supplier lead time, safety stock = 2 weeks demand
Frame components: make-to-order (sub-MO triggered with parent MO)
Hardware kits:    reorder point, 3-day lead time, order qty = 50 units
Enter fullscreen mode Exit fullscreen mode

Step 4 — Shop Floor

3 tablets, one per workcenter
Operator login: PIN (gloves-compatible)
Supervisor dashboard: live status all 3 stations
Quality gate at Op 3: blocks Done until inspection complete
Enter fullscreen mode Exit fullscreen mode

Step 5 — PLM

ECO stages: Engineering Manager → Quality Manager → Approved
BoM versioning: active from day one
All BoMs linked to PLM before first production run
Enter fullscreen mode Exit fullscreen mode

Discussion

Curious what others have run into with Odoo manufacturing implementations:

  • What was the first configuration decision that caused downstream pain?
  • How did you handle BoM version control before PLM was in place?
  • Any specific workcenter/routing setups for batch vs. discrete that worked well?

Full implementation guide (MRP, BoM, routing, shop floor, PLM, step-by-step setup):
https://theintechgroup.com/blog/odoo-erp-manufacturing-guide/

Drop your implementation questions in the comments — happy to go deeper on any of the configuration areas above. 👇

Top comments (0)