How a Large-Scale Metal Packaging Manufacturer Runs Multi-Order, Shared-Line Production on One Odoo System
Metal packaging production has a structural problem most ERP systems were never built to solve: multiple customer orders, each with its own SKU, routinely share a single production board and run through the same opening stages before splitting into separate finished goods. This case study covers how one high-volume manufacturer digitized that exact workflow, from customer requirements and automated pricing through technical specs, shared-board manufacturing, quality control, and delivery, inside a single connected Odoo environment.
The Client
The client is a high-volume metal packaging manufacturer producing tinplate and metal packaging components (tins, cans, and related metal container products) for industrial and consumer goods brands. Like most metal packaging producers, its production model is defined by shared tooling: a single design board (the sheet layout used for stamping, printing, and coating) is frequently used to run several customer orders and product codes at once through the earliest production stages, before the sheet is cut and each resulting semi-finished piece is routed to its own finishing process.
This isn't a shop running one job at a time. The production campus spans an estimated 500,000+ square feet (roughly 46,000+ m²) of manufacturing and warehouse space, built around twin production lines that share machines, tooling, and shifts across every order in progress. At that footprint, a single design board rarely carries just one customer's job: it typically runs several orders and product codes through coating, printing, and cutting at once, then splits into dozens of independent finishing routes. Multiply that across 40+ orders a month, and the plant is effectively running dozens of interleaved production threads at any given time, each one needing its own pricing, technical spec, QC trail, and delivery record traced back to the right customer.
Facility size is a visual estimate derived from the aerial photograph, not a confirmed engineering measurement.
Before and After
| Before | After |
|---|---|
| Product configuration and pricing depended on spreadsheets and one or two people's pricing knowledge | Pricing engine calculates material, process, labor, and packaging cost automatically and returns a proposed sell price with margin controls |
| Commercial quotes and technical specs could drift apart, since sales and engineering worked from separate references | Confirmed technical documentation inherits directly from the accepted quote, so commercial and engineering data never diverge |
| Board-sharing across orders was tracked informally, making it hard to trace which orders and SKUs ran on which sheet | Every board-matching plan is traceable back to the specific orders and product codes it carries |
| Quality issues were logged on paper and consolidated at the end of a production run, delaying detection | QC is recorded on tablets at multiple checkpoints per run, with defect rates calculated and flagged automatically against thresholds |
| Material usage and shrinkage were only visible in a single end-of-period summary | Material consumption is tracked at the point of use, by stage, board, and order |
| Delivery paperwork was handled manually and separately from order status | Delivery documents generate as PDFs and are available to customers through a self-service portal |
The Challenge
Metal packaging manufacturing has a data-modeling problem that generic MRP setups handle poorly: the relationship between orders, product codes, shared boards, semi-finished goods, production stages, and QC records is many-to-many, not the simple one-to-one flow most out-of-the-box manufacturing modules assume.
- A single order can contain several product codes, and several orders can share one board-matching plan to make efficient use of sheet material.
- Opening stages (coating, printing, cutting) run on the shared board; downstream of the cut point, each product code needs to follow its own distinct routing.
- Sell price is not a fixed number: it depends on dimensions, material, gauge, printing, coating, accessories, packaging, order volume, expected shrinkage, and the specific processing method chosen.
- Quality control needs to capture data at multiple checkpoints, by defect category and type, with photos, by machine, shift, and production stage, and needs to identify the full scope of an issue when it occurs on a shared board.
- Warehouse teams need to know exactly which order or board a given material was issued against, where each semi-finished piece currently sits, and which finished goods are ready to ship.
- Leadership needs connected data across the whole flow to track progress, throughput, quality, and material efficiency, and to identify the root cause behind any unusual result.
The Solution
The implementation was built as one continuous data chain rather than a set of disconnected screens: customer requirement → product configuration → automated pricing → quotation → confirmed technical documentation → board matching → multi-stage production → QC → warehouse → delivery documents and customer portal. The goal at every step was inheritance, not re-entry: data created upstream should never need to be typed again downstream.
Standardized requirement intake and product configuration
Sales configures each product directly at the quote line: product line and type, dimensions, material and gauge, quantity, print and color requirements, coating and finish, construction, accessories, packaging, and any special processing. Required-field and compatibility checks catch missing or inconsistent input before a quote goes out, rather than after production has already started asking questions.
An automated, three-tier pricing engine
The pricing engine determines the expected material structure, quantities, routing, and shrinkage for a given configuration, then calculates material, machine, labor, outside processing, packaging, and overhead cost. Output is deliberately split into three distinct price layers rather than a single number:
| Price Layer | What It Represents | Control Rule |
|---|---|---|
| Estimated cost | Calculated cost based on standards and data available at the time of quoting | Data source, formula version, and calculation date are logged |
| Proposed sell price | Estimated cost plus margin and commercial policy | Automatic alert when margin falls below threshold |
| Approved sell price | The final price after discount or exception handling | Approver, reason, and change history are mandatory |
Quotation management with full version history
Every quote configuration, pricing input, cost basis, margin, proposed price, final price, preparer, approver, and version is retained. Whichever configuration the customer confirms is the one that carries forward into the order and the technical documentation, eliminating the gap between what was quoted and what gets built.
Confirmed technical documentation as the single source of truth
Technical documentation centralizes specifications, expected bill of materials, routing, shrinkage allowances, QC checkpoints, packaging, and tooling references, all under version control. A minimum Draft / Confirmed status gate, plus full history, means production, planning, and QC always work from documentation that has actually been signed off.
Multi-order board matching
Demand across open orders is aggregated by product code and delivery date, then matched onto shared boards: the system calculates board count, repeat layout, expected yield after cutting, and any shortfall or surplus, and keeps every board-matching plan linked back to the specific orders and product codes it serves. Planning gets full visibility before a production order is even released, not a rough estimate discovered after the fact.
Shared stages, then independent routing
Coating, printing, and cutting can run as shared work orders across multiple product codes; after the cut point, each code proceeds through its own distinct routing with a formal predecessor-successor relationship between work orders. Start/finish confirmation, good/defect quantities, timing, shift and operator, machine, and handoffs are captured at each stage, with bottlenecks flagged automatically.
Cutting orders that track multiple outputs at once
A single board or large sheet can generate several semi-finished outputs across different product codes simultaneously. Dedicated cutting work orders record each output's code, parent order, expected versus actual yield, pass/defect quantities, shrinkage, and next routing step or location, so nothing gets lost in the handoff from shared board to individual product stream.
Material flow and WIP visibility
Physical material flow, from raw material to board/sheet to semi-finished goods to finished goods to packaging, is mapped to discrete inventory locations: raw material, issued-to-production, in-process by stage, pending QC, defect/rework, pending packaging, finished goods, pending shipment. Every movement is linked to its production order, board, stage, product code, and originating order, laying the groundwork for future barcode/RFID automation.
Material standards, shrinkage, and cost allocation
Actual consumption is reconciled against standard usage across board-sharing, trial runs, print/coating defects, scrap, machine, shift, and operator, with shared-stage costs allocated back to individual product codes by area, position count, output volume, weight, or standard usage rules, surfacing abnormal material consumption and improving costing accuracy.
Tablet-based QC at multiple checkpoints
Quality control runs on tablets directly at the point of inspection rather than on paper collected and reconciled later. Inspectors log pass/fail results, defect categories and types, quantities, and photos, with board-level defects distinguished from product-code-level defects so the true scope of an issue is clear immediately. Defect rate is calculated automatically (defects ÷ total inspected), checked against configurable thresholds, and flagged when it exceeds them, catching problems while they're still contained rather than after they've spread across a shared board.
Two-way traceability
Any order can be traced forward (order to product code to board to shared stage to semi-finished good to individual routing to finished good), or a defect can be traced backward to every stage, board, product code, and order it may have affected. Finished goods can also be traced back to the production order, semi-finished component, board, and confirmed technical documentation or material batch used to make them.
Warehouse, delivery documents, and customer portal
Material is issued against the specific production order or board, WIP is tracked between stages, and finished-goods packaging is confirmed before shipment. Custom delivery document PDFs generate automatically and are made available to each customer through a self-service portal, with access-token checks ensuring a customer can only view their own delivery records: no manual file sharing, no cross-customer document exposure.
Performance Snapshot: 5 Months of Production
The QC inspection count is derived from an average checkpoint rate per production order rather than a raw system export, and is presented as an estimate pending full data reconciliation.
Processing Time: Before and After
Across the core quote-to-plan sequence (product setup and approval, quotation, price approval, plan consolidation and handoff, and production scheduling), average processing time dropped from 105 minutes to 24 minutes per cycle, a 77% reduction.
QC time versus QC coverage
Before implementation, defect reconciliation happened once, at the end of a production run, taking about 30 minutes per order. After implementation, each order typically receives an average of 8 QC touchpoints (5 random inspections plus 3 end-of-line checks) at roughly 3 minutes each, totaling about 24 minutes per order: a 20% reduction in total QC time while checkpoint coverage increased eightfold. Across 442 production orders, that represents an estimated 44.2 hours saved on QC alone.
Estimated Total Time Savings
Because the exact number of net-new product configurations created within the 200 orders isn't yet confirmed, total time savings are presented as a range rather than a single figure:
| Scenario | Basis | 5-Month Estimate |
|---|---|---|
| Conservative | Counts only the processing steps that repeat on every order | ~280.9 hours |
| Upper bound | Assumes all 200 orders required a new product setup | ~314.2 hours |
These figures reflect time-on-task savings only, based on directly measured before/after process steps. They do not yet include the additional, unquantified benefit of 500+ inventory documents processed, reduced data-entry errors, fewer wrong-version production runs, contained defect spread, or faster quote turnaround on win rate. They are also not a substitute for a full ROI calculation, which would also need to account for software, infrastructure, and change-management cost.
Why This Generalizes Beyond One Plant
Any manufacturer that runs multiple SKUs or customer orders across a shared production step (metal packaging, printed tin, coated sheet products, and similar batch-and-split manufacturing) faces the same underlying data problem: a many-to-many relationship between orders, product codes, shared production runs, and downstream routing that generic, single-SKU-per-order MRP setups were never designed to model cleanly.
This implementation shows that problem is solvable inside Odoo's standard manufacturing, inventory, sales, and quality building blocks, configured around the plant's actual production logic rather than left in a generic default state: shared work orders with formal predecessor-successor relationships, cutting orders that split into multiple tracked outputs, and a pricing engine that reflects the business's real cost structure instead of a flat per-unit rate. The same architecture extends to any manufacturer running shared-tooling, multi-SKU batch production.
Frequently Asked Questions
Can Odoo handle production where multiple customer orders share the same manufacturing run?
Yes. Through configuration of shared work orders, board/sheet-matching logic, and cutting orders that track multiple outputs, Odoo can model a production run that starts as one shared process and splits into several independently tracked semi-finished and finished goods, without losing traceability back to the originating orders.
Does a custom pricing engine like this require code customization?
A pricing engine of this complexity, factoring in material, dimensions, process, shrinkage, and margin policy, is typically built through a combination of configuration and targeted development on top of Odoo's standard sales and manufacturing modules, keeping the core system upgradable while still reflecting the business's real costing logic.
How does the system prevent production from starting on unapproved technical specs?
Technical documentation is version-controlled with a minimum Draft/Confirmed status gate. Production orders, material issuance, and planning are only permitted to reference a confirmed version, and any change after approval requires a new version or a formal exception approval flow.
Is tablet-based QC only useful for metal packaging manufacturing?
No. Any manufacturer with multiple in-process inspection points, rather than a single end-of-run check, benefits from the same pattern: structured defect logging, photo capture, automatic defect-rate calculation against thresholds, and traceability by machine, shift, and production stage.
Running Multi-Order, Shared-Line Production?
If your plant shares tooling or production runs across multiple orders and SKUs, standard out-of-the-box ERP configuration usually falls short. See how a connected Odoo setup can be built around how your production floor actually works.
Talk to an Odoo Implementation SpecialistCase study prepared as a reference for Odoo implementation engagements with manufacturers running multi-order, shared-tooling production, including metal packaging, coated sheet, and similar batch-and-split manufacturing environments. Estimated figures are marked accordingly and are subject to confirmation against full system exports.
