How to Auto-Generate Manufacturing Orders from Quotes in Odoo

If you're already running Odoo and you sell configurable products, you've probably felt this specific pain: a sales rep builds a quote in the sales module. The customer accepts. Now somebody has to translate that quote into a manufacturing order with the right BOM, the right components, and the right routing. And somebody usually means the ops manager or the production planner, typing things by hand from the accepted quote into the manufacturing module.

It works. It's slow. It's error-prone. And it doesn't scale.

The good news is Odoo can auto-generate manufacturing orders from accepted quotes. The bad news is there are three very different ways to do this, they all look similar on the surface, and picking the wrong one can cost you months of engineering effort and a lot of frustrated users. This post walks through all three — vanilla Odoo, custom automation, and a proper CPQ layer — so you can figure out which one fits your business.

The reader we have in mind: someone who's already using Odoo, is spending real time on manual quote-to-MO work, and wants to know whether the fix is a quick configuration change or a bigger project. If that's you, this is the map.

First — what "quote to MO" actually means in Odoo

Odoo has a native workflow that connects the sales module to the manufacturing module. In principle, it's simple: a sales order for a manufactured product can trigger a manufacturing order automatically, using the product's bill of materials to determine what needs to be produced.

Three things need to be true for this workflow to fire cleanly:

• The product must have a BOM. Odoo needs to know what components go into the finished good.
• The product must be set to make-to-order (MTO). This is a checkbox on the product record telling Odoo that this product is produced on demand rather than stocked.
• The product must be manufactured, not purchased. Odoo needs to know that the fulfillment method is "Manufacture" (as opposed to "Buy" for purchased goods).

When all three are true, the moment a customer accepts a quote for that product, Odoo raises a manufacturing order behind the scenes. The production team sees it. The components get reserved. The whole thing flows.

This is genuinely how it should work. The reason people struggle is that "the product must have a BOM" gets complicated when your products are configurable — meaning a single quote can produce different physical outputs depending on customer choices.

Approach 1 — Vanilla Odoo (native workflow)

What it looks like: You configure your products in Odoo's standard product model, assign each variant its own BOM, mark them all as MTO. When a sales order comes in for a specific variant, Odoo pulls that variant's BOM and generates the manufacturing order.

Where it works well: Products with a small, stable set of variants. A chair with three color options and four sizes is 12 variants — Odoo handles this without breaking a sweat. Each variant has its own BOM, the sales rep picks the right variant when quoting, the workflow fires clean.

Where it breaks: Products with configuration complexity beyond simple variant selection. A pressure gauge with 20 options that combine in thousands of ways can't be modeled as thousands of variants. Even if you tried, the product catalog becomes unusable, the BOMs proliferate, and the sales rep can't find the right variant to pick.

Signals you've outgrown vanilla:

• Your sales team routinely quotes products that aren't in the catalog as saved variants — they build the quote line-by-line from components
• Your ops team is manually building BOMs for accepted quotes because no matching BOM exists in the system
• Product managers are creating dozens of new variants per week just to keep up with actual quoted configurations
• A single product family has more than 50 variants, and it's still growing

Bottom line: If your products fit into 5-20 predefined variants per family, vanilla Odoo works well. Setting it up right is genuinely a few days of implementation work, not weeks. Don't over-engineer this if you don't need to.

Approach 2 — Odoo + custom automation

What it looks like: You hire a developer to write custom Odoo modules or scripts that generate BOMs dynamically based on configuration inputs. The sales rep fills in a form (or a spreadsheet, or a set of product options), the automation figures out the correct component list, and the resulting sales order carries enough information for the automation to generate the right manufacturing order.

Where it works well: Moderate configuration complexity with well-defined rules that don't change often. If you have 5-10 configuration parameters that combine according to stable logic, a developer can encode this in Odoo custom code and it'll run reliably for years.

Where it breaks: Three specific failure modes.

Failure mode 1 — Configuration rules change more often than the developer can update the code. Sales adds a new option. Engineering realizes a combination is invalid and needs to be blocked. Marketing renames a product category. Each of these is a code change. Eventually the automation lags reality and the sales team stops trusting it.

Failure mode 2 — Multiple people need to author configuration logic. The developer becomes a bottleneck. Product managers who understand the products best can't update the rules without filing a ticket. Response times slow down. Ownership becomes unclear.

Failure mode 3 — Testing gets hard. Custom automation generating BOMs dynamically is inherently harder to test than picking from a predefined list. Edge cases surface in production. A misconfigured BOM causes a wrong manufacturing order, which causes a wrong build, which costs real money.

Signals you've outgrown custom automation:

• Your developer backlog for CPQ-related tickets is more than two weeks deep
• Configuration rule changes require code deployments that gate other Odoo work
• Product managers describe their job as "waiting for engineering to update the configurator"
• Quote errors reaching production have caused rework costs that would fund a proper CPQ implementation

Bottom line: Custom automation is the right choice when you need more than vanilla Odoo but not full CPQ capabilities, and when you have engineering capacity to own it. The maintenance cost is real and grows over time — budget for it explicitly rather than treating it as a one-time build.

Approach 3 — Odoo + a CPQ layer

What it looks like: A CPQ (Configure, Price, Quote) module sits on top of Odoo. Sales reps use a guided configurator UI to build quotes — the CPQ enforces valid combinations, calculates pricing dynamically, and generates a proper multi-level BOM for each configured product at quote time. When the customer accepts, the sales order releases a manufacturing order with the BOM already attached. Nothing to retype, nothing to translate.

Where it works well: Products with real configuration complexity — engineering rules, dependent options, dimension-based components, multi-level BOMs. Anywhere a sales rep would otherwise need to consult engineering to figure out whether a quote is even manufacturable.

What it specifically fixes:

• Sales reps quote in minutes, not hours. The guided flow prevents invalid combinations upfront rather than surfacing them later in engineering review.
• The BOM is generated correctly at quote time. No translation step between "what was quoted" and "what gets built" — they're the same object.
• Non-developers can author configuration rules. Product managers or sales ops can update option lists, pricing, and dependency rules through an admin UI rather than filing developer tickets.
• Approval workflows fit naturally. Special pricing, non-standard configurations, or engineering-review flags can trigger approval steps before the quote goes to the customer.
• The whole thing stays in one Odoo instance. No sync issues between a standalone CPQ tool and Odoo — the CPQ layer uses the same product data, the same BOMs, the same everything.

Where it doesn't help: If your products are genuinely simple and vanilla Odoo works, a CPQ layer is overkill. If your configuration complexity is small enough that custom automation handles it cleanly, adding a CPQ layer is more machinery than you need. CPQ becomes worth it when the alternative — manual work, engineering escalations, or maintaining custom code — costs more than the CPQ itself.

The honest comparison

Here's how the three approaches compare on the dimensions that actually matter:

Notice the pattern. Vanilla Odoo and CPQ are similar in most dimensions — the difference is what kind of products they can handle. Custom automation sits in the middle: it can handle more than vanilla, but the maintenance cost is what makes it a poor long-term choice for most businesses.

How to decide which one fits

Three questions worth answering honestly:

1. How much time does a sales rep spend on a typical quote? Under 15 minutes on average means vanilla Odoo probably works. Over 30 minutes is a signal that the quoting process is fighting your product model. Anywhere between is a gray zone where the answer depends on quote volume.

2. How many BOM variants do you maintain, and how often do you add new ones? Under 50 variants and adding fewer than 5 per month means vanilla handles it. Over 200 variants or adding 20+ per month means you've almost certainly outgrown vanilla — the question is whether custom automation or a CPQ layer is the right next step.

3. Who owns configuration rules? If the answer is "engineering" and updates take days, custom automation will hurt you long-term. If the answer is "product managers" and they can update rules in real time, a CPQ layer is likely already justified.

Three "vanilla is fine" answers means don't over-engineer. Three "outgrown vanilla" answers means CPQ. Mixed answers usually mean custom automation is a reasonable middle step — but budget for maintenance and plan the CPQ migration for when the maintenance cost catches up.

Where AktivCPQ sits in this

Full disclosure since it's relevant: AktivCPQ is our own product, built specifically as the CPQ layer for Odoo. We built it because we kept seeing manufacturers on Odoo hit the vanilla-Odoo ceiling and either build brittle custom automation or migrate to standalone CPQ tools that then required expensive integration back to Odoo.

What AktivCPQ specifically does: sits on top of your existing Odoo instance, uses the same product catalog and BOMs, adds the guided configurator UI + dynamic BOM generation + engineering rules layer. Accepted quotes flow into Odoo sales orders which flow into manufacturing orders with the correct multi-level BOM attached. No sync issues, no separate database, no integration middleware.

If your business is at the "vanilla Odoo isn't enough" threshold, our cornerstone Odoo CPQ guide covers the concept in more depth, and our comparison of AktivCPQ vs standalone CPQ tools covers why we think the integrated approach beats bolting a separate CPQ tool onto Odoo.

The takeaway

Auto-generating manufacturing orders from quotes in Odoo is genuinely a solvable problem. The right solution depends on your product complexity, your quote volume, and who owns configuration logic in your organization.

Vanilla Odoo works for simple, stable product catalogs. Custom automation extends that to moderate complexity but adds maintenance debt that grows over time. A CPQ layer becomes cheaper than either alternative once your configuration complexity crosses a threshold you can measure — quote time, variant count, and change ownership.

If you want to think through which approach fits your specific business, our team is happy to work through it on a call. Bring a product family you currently struggle to quote consistently — we'll show you what each of the three approaches would look like for that specific product, so you can decide with real information rather than sales pitches.

If you'd rather read more first, our Real Cost of a Disconnected Stack covers the broader economics of consolidating around one platform, which usually becomes the decisive factor once quote-to-MO is working smoothly.