Khichdi InfoTech
Skip to content

Odoo Manufacturing · advanced · 10 min read

Choosing the Right Manufacturing Architecture

Decision framework for MTS, MTO, ETO, subcontracting, variants, and configurators in Odoo — matching product mix to routes, apps, and custom scope.

Last reviewed 2026-07-30 · Estimated effort: 6+ weeks for multi-team change

Table of contents

Manufacturing architecture in Odoo is how product families map to routes (manufacture, buy, MTO), stock strategy (MTS buffers versus pull-to-order), subcontract flows, and optional work center depth.

Mixed estates are normal: catalog lines may be MTS with reorder rules while custom lines are MTO with configurators and subcontract finishing. Document per family — one global route fails hybrid businesses.

Customization extends architecture when CPQ, vendor portals, or APS exceed standard MRP. Performance tuning matters when high MO volume or planning screens strain operators.

Architecture debates often stall on app names instead of build behavior. The useful question is what should happen to stock and MOs when a typical order confirms — not whether Manufacturing checkbox is on.

This article provides a decision framework before you configure routes on thousands of products.

MTS suits predictable demand and forecastable components — use reorder rules or planner-driven MOs, SO consumes FG stock. MTO suits order-specific production — SO confirmation triggers MO or procurement when FG is not stocked.

ETO adds unique BoMs per job, often via configurators or engineering workflows. ETO without BoM snapshot discipline breaks costing and procurement.

  • MTS: FG buffer, component orderpoints, forecast optional
  • MTO: SO-linked MO, longer quoted lead times
  • ETO: configurator or engineering BoM per order
  • Hybrid: segment by product category not single company flag

Include subcontract when vendors perform meaningful value-add with your components — not when you simply buy finished goods. Architecture must define resupply locations and who owns in-transit visibility.

Multi-tier subcontract (component → sub-assembly at vendor A → finish at vendor B) needs explicit BoM levels and timing in the model.

Bounded option grids use variants with per-variant BoMs. Rule-heavy customization uses configurators or Customization modules to explode dynamic BoMs at quote time.

Avoid forcing ETO into variants — SKU explosion becomes unmaintainable. Avoid forcing simple color options through custom CPQ — variants are cheaper.

Light architecture: BoM-only MOs without routings for kit-style builds. Heavy architecture: routings, work centers, capacity views for load planning.

Heavy depth requires maintenance of operation times — if times are fiction, planning misleads. Link Performance when shop-floor data volume slows UI.

External ecommerce, CPQ, or MES integrations define boundaries: what creates the MO, what posts consumption, what remains system of record.

High-volume MTS with many daily MOs may need Performance review of planning views and automated MO confirmation rules.

  • Document architecture per product family on one page: route, BoM type, subcontract, configurator.
  • Prototype architecture on two families — one simple MTS, one complex MTO/ETO.
  • Separate bought-finished-goods catalog from true manufacturing SKUs in product categories.
  • Match planning depth to operational maturity — skip routings until times are measurable.
  • Cross-link Customization for CPQ and subcontract portals; Performance for scale.
  • Revisit architecture after first peak season with KPI data.

  • !Single MTO route on entire catalog including stocked commodities.
  • !Subcontract modeled as PO-only without stock architecture.
  • !Configurator chosen to avoid cleaning variant attributes.
  • !Enterprise routings on lines that never use work orders.
  • !Architecture copied from unrelated industry demo.
  • !No documented boundary for custom module versus standard config.

The right manufacturing architecture matches how each product family actually builds and stocks — MTS, MTO, ETO, and subcontract can coexist with clear rules.

Next, write one-page architecture notes per family and validate against a pilot SO and MO before enterprise rollout.

MTS vs MTO vs ETO decision path for Odoo setup.
Standard fit?

Configure and train

Odoo covers ≥80% of the process

Unique process?

Custom module

Competitive advantage depends on it

External master?

Integrate

Another system owns the data

Unclear ROI?

Defer / pilot

Scope is speculative

Odoo MRP with sales, CPQ, subcontract, and warehouse boundaries.
  • Client / Channel

    Users & devices

  • Odoo Application

    Business logic

  • PostgreSQL

    System of record

  • Workers / Cron

    Async work

  • clientapp(HTTP)
  • appdb(ORM)
  • appjobs(queue)
Light vs heavy manufacturing architecture features.
OptionBest whenTrade-off
ConfigureStandard Odoo covers the needLimited uniqueness
CustomizeDifferentiating workflowUpgrade cost
IntegrateExternal system of recordSync complexity

Frequently asked questions

Can one Odoo database run multiple architectures?

Yes — per product or category routes. Problems come from undifferentiated defaults applied to every item.

When is standard Odoo enough without custom modules?

When BoMs are stable, options fit variants or standard configurator, subcontract follows standard resupply, and shop floor accepts MO or work order screens.

How does retail ecommerce fit?

Ecommerce often drives MTS replenishment MOs separate from MTO custom lines. Use retail patterns sparingly and only when online demand truly feeds production planning.

Should architecture change after migration?

Migration is a chance to fix legacy route sprawl — not only lift-and-shift. Plan architecture review before bulk BoM import.

Deciding Odoo manufacturing footprint?

Share your product mix and build models — we will recommend architecture paths and custom scope.

Business technology and software delivery