When the Lot Carries the Design: Architecture for Parametric Manufacturing in Odoo

Picture a typical manufacturer. The product is one — call it "item X" — but every order is different. A different size. A different packaging material. A different label depending on the sales channel. A different set of options depending on the customer's requirements. One week the order is from a major retail chain under their private label. The next week it's from another distributor — same item, but with different labels for different regions.

It might be a food-and-beverage product. It might be a construction element configured by size and class. It might be a protective product with a classification rating. It might be industrial packaging. It might be an automated component that gets mounted into a larger system. The industry is different every time. But the problem is the same.

These are completely different manufacturing operations. And yet they share one common problem: the product you manufacture is not one product. It's a family of closely related products, where small changes in configuration propagate through the recipe, through the operations, through the procurement plan, and through traceability on the finished stock.

Standard ERP systems stumble over this in predictable ways.

How it usually unravels

The industry's approach for the last twenty years has been to create a product variant for every possible configuration. Works fine when you have three sizes and two packaging options. Fails when you have thousands of combinations.

The results I see at clients:

SKU explosion. A product with a few option packages, a few classifications, a few finishes, and continuous size ranges generates tens of thousands of SKUs. The product catalog becomes unusable. Warehouse staff lose trust in the system. Sales people look up products by names only they know.

Recipe proliferation. Every variant requires its own BoM (Bill of Materials). Maintenance becomes a full-time job. A single material change requires editing hundreds of BoMs. In reality this never gets done all the way — some BoMs remain stale, others are updated, nobody knows which are current.

Traceability breaks. The lot number on the finished product tells you when it was produced, but not which configuration it represents. Want to recall a specific variant? Good luck.

Planning lies. MRP sees 50 orders for a given product template and plans accordingly — but those 50 orders may require 50 completely different component sets. The requirements MRP calculates are fiction.

The industry has worked around this for decades: custom configurators bolted onto the side of the ERP, rule engines written in eccentric proprietary languages, Excel sheets that never match actual production, and long technical specifications attached as PDFs to every order.

None of these workarounds solve the architectural problem. They only mask it.

A different architecture

Over the last two years, working on real production cases across several different manufacturing archetypes — process, mass production, engineer-to-order, and configure-to-order — I've built what I believe is a cleaner foundation. The project is a set of Odoo modules under the AGPL-3 license.

There are three central ideas, each of which departs from the way most ERP systems handle configurable products.

Idea 1: The lot carries the design

In most ERP systems the lot number is just an identifier — a stamp on the finished unit that says "I was produced in this batch on this date." That's metadata about the product.

In the architecture I'm describing, the lot number is the configuration. The lot record carries every parameter that defines this specific physical object: dimensions, material choices, selected options, classification ratings, the list of rules that were applied when it was created. When you recall a lot, you're not recalling a batch — you're recalling a specific configured product specification.

This may sound like a small difference. It isn't. It means the following:

• You stop creating a product variant for every possible configuration. One product template, many lots, each with its own fingerprint.
• Traceability becomes meaningful. A defect claim on a specific lot tells you exactly which dimensions, materials, and rules produced that unit. Not just "some item manufactured in April."
• Quality control has something concrete to validate. You don't check "did we build the item correctly" — you check "did we build this specific configuration correctly."
• Service and warranty become executable. A customer reports an issue years later. You look at the lot, see the exact specification, buy compatible replacement parts.

Technically, the implementation lives in a module that extends the standard stock.lot model with a parameter-definition field and a Properties object storing all parameters as JSON. The lot form gets a "Design Parameters" tab and the parameters become visible, searchable, and accessible to every calculation further down the chain.

Idea 2: The bill of materials is a planning view, not a production recipe

Standard ERP systems treat the BoM as the source of truth for what the product is made of. Every manufacturing order either uses the BoM directly, or creates a variant-specific BoM for that order.

In the new architecture the BoM is a general planning template. It answers questions like "roughly how much raw material do we need for one item of this class?" — good enough for procurement, rough capacity planning, and price calculation at quote time.

The actual production recipe — the exact component list, the exact operation sequence, the exact quantities — is generated at the moment the manufacturing order is created, derived from the lot's configuration through a chain of decisions. The MO is the execution view. The BoM is the planning view. They don't need to match perfectly, and insisting they match is what produces the BoM proliferation.

This separation reflects directly how real manufacturing functions:

• Procurement plans months ahead against approximate requirements.
• The production floor executes against precise specifications, known only when the order enters the schedule.
• Attempts to make these two views identical are a fight with physics.

The technical name for this in the code is the O-variant pattern (zero-coefficient placeholder). Every BoM line has coeff_default=0.0 — meaning "this is a planning placeholder, not an executable quantity" — plus a rule that, at execution time, extracts the real coefficient from the matrix engine.

Idea 3: Decision rules live in a real engine

Every manufacturer I've worked with has some version of the same document: a large Excel file, a ring-bound notebook, or a wiki page titled something like "configuration rules" or "engineering standards." It describes the logic that determines how a product is configured, what materials go into which variants, what operations are required for which options.

In most ERP implementations that document becomes custom Python code, scattered across computed fields, constraints, and onchange handlers. It works — until it doesn't. When the rules change (and they always change), the cost of modification is high, the risk of breaking something is real, and nobody except the original developer understands what's going on.

The architecture I'm describing externalizes these rules into a real decision engine — specifically, DMN (Decision Model and Notation), an open standard for business rules, executed by an open-source engine. The rules are written as decision tables that a production manager or engineer can read, understand, and modify. They're versioned, testable, and portable.

The decision chain has four levels:

T0 — Validity. Is this combination of parameters physically possible? T0 rules say "yes" or "no" before anyone commits to a quote. Hit policy: collect. Output is a list of messages with severity levels (error/warning/info) — errors block, warnings inform.

T1 — Derivation. Given valid parameters, what derived values follow? If the customer selected a specific classification, it follows that there's a specific minimum thickness, a specific number of fixing points, specific structural requirements. Hit policy: first. Output is a dictionary of derived values added to the context.

T2 — Component selection. Given parameters and derived values, which specific components and sub-assemblies does this product require? Hit policy: first. Output is a dictionary of coefficients for each BoM line.

T3 — Operation sequence. Given the component list, which operations, in what order, at which work centers, with what setup times, produce this product? Hit policy: collect. Output is a list of work orders.

Each level is a decision table. Each decision table is human-readable. Each level can be modified without touching the ERP source code. The output of one level becomes the input of the next.

How this actually works in production

Concepts are cheap. Here's the concrete workflow:

The quote arrives. The sales configurator shows the customer (or the salesperson) a form: dimensions, classification, option packages, finishes. As the form is filled in, T0 rules run in real time, preventing invalid combinations. T1 rules execute, showing derived values. Total quote price is calculated from the T2 component list against current prices.

For the sales interface there's a separate module that implements an OWL 3D preview with Three.js. It's a real-time visualization using GLB models or SVG profiles extruded dynamically. The customer sees what they're ordering before they order it.

The quote becomes an order. The order line references a generic product and carries the configuration as structured attributes. No new SKU is created. No new BoM is created.

Procurement plans. MRP runs against the generic BoM plus attributes to estimate raw-material demand. Long-lead-time items are ordered based on typical consumption, not exact consumption.

The manufacturing order is created. At this moment — when the MO is generated — the full T0-T3 chain executes against the configuration and creates:

• A lot number carrying the complete configuration fingerprint.
• A production-specific component list (the output of T2).
• A production-specific operation sequence (the output of T3).
• Reservation of exact components against this lot.

Components flow through the factory. Every consumed component is reserved against the specific finished lot. This is the role of the forced-lot reservation mechanism — it propagates tagged component lots through the entire procurement chain, so the specific product receives exactly its own components, not "compatible" ones from stock. That's a separate technical article, but for the production manager the observable behaviour is simple: "the system pulls the right components for this order, period."

The product is manufactured. The MO executes against its specific recipe. Quality controls reference the lot's specification. Deviations are logged against the lot.

The lot is shipped. The traceability record now contains everything: what was ordered, which parameters were selected, which rules triggered, which components were consumed, who worked on it, what the quality results were. Years later that record still answers every question anyone asks about this specific physical product.

The architecture in practice

The system is already validated on real production cases across several different manufacturing archetypes:

Process manufacturing. Typical for industries where the base product is the result of a recipe, but packaging, labelling, and regulatory requirements vary by market and channel. The T0-T3 chain handles regulatory constraints, unit-of-measure conversions, and compatibility rules for co-packing in the same batch.

Mass production. Typical for industrial products with continuous parameterization (geometry, materials, blends). The T2 level calculates raw-material consumption from geometric properties — an example of rules that work in a continuous parametric space rather than against discrete option lists.

Engineer-to-order. Typical for industries where every order is individual and defined by a classification rating, custom dimensions, and option packages. The T0 level enforces regulatory constraints. The T1 level derives structural requirements from the classification. The T2 level selects components, reinforcements, and mechanisms.

Configure-to-order. Typical for industries where the choice of one component determines the requirements of others. Example: the load characteristic determines the structural profile; the profile plus dimensions determine a specific mass; the mass determines the drive component choice. This is the most physically-intensive archetype and stress-tests the decision engine's ability to handle purely multi-step derivations.

Different industries. Different configuration models. One architecture.

Under the hood

What I've described so far is the functionality. Underneath it there's a technical structure — Odoo modules organized in four layers:

Foundation. Universal parameter definitions, profiles (carrying SVG render and JSON schemas), parameter attachment to lots, grouping of design assets (3D models, SVG profiles, images) by type.

Formulas. Reusable BoM-line formula templates with syntax validation. A popup editor with a code widget and a variables panel for the production engineer. Integration with an AI assistant that generates formulas from a domain description — a topic for a separate article.

Engine. The core — T0/T1/T2/T3 DMN rules, O-variant pattern, automatic selection of the correct product variant from many possibilities in a single template given attribute values, child lots (parameters propagate to every semi-finished lot), MTO-stop logic (if a lot with a matching configuration already exists in stock, the MO isn't created again).

Sales UI. Real-time 3D preview integrated into the quote form.

Industry modules. Specializations for each manufacturing archetype — each with its own T0/T1/T2/T3 JSON definitions, domain-specific parameters, and specific product templates.

All modules are AGPL-3 and run on Odoo 18 and 19.

What this is and what it isn't

This isn't an ERP rewrite. It's a set of Odoo modules — extensions to the existing manufacturing, inventory, and procurement apps — that introduce the lot-as-carrier pattern, the DMN decision chain, and the supporting infrastructure for forced component reservation.

It's not magic. If your configuration logic is poorly understood, externalizing it into DMN rules won't fix it. What it will do is force clarity: you cannot write a decision table you don't understand. That sounds harsh. It's actually the primary benefit. Several manufacturers have already noticed that the process of modelling their rules in DMN revealed ambiguities and contradictions in their own internal standards — ambiguities that had been causing quality problems for years.

It's not for every manufacturer. If you make one product in one configuration, you don't need this. If your configurability is limited to a handful of discrete options and doesn't propagate through the BoM, standard Odoo variants are probably enough. This architecture pays off when configurability is the central challenge of your work — when the answer to "what does your product look like" is genuinely different for every customer.

What's next

The repository will be opened publicly in the coming weeks, once the first wave of real deployments stabilizes. If you're a manufacturer whose configuration logic is eating your ERP alive, or a production manager watching BoM-maintenance costs that don't make sense, I'd like to talk with you.

Also coming: several technical articles on individual aspects of the architecture — the mechanism for forced lot reservation across the full procurement chain, AI-assisted generation of BoM formulas via the MCP terminal, and the engineering specifics around the chosen technologies.