Copper wire & component manufacturing · Odoo ERP realignment
Sigma Terminal: a precision copper manufacturer that already owned Odoo, and nobody trusted it
Published · Updated
Sigma Terminal is a leading Indian manufacturer of copper wires, rods and custom components for the electrical, automotive and infrastructure industries. The company was already running Odoo Community v12, but it had never been set up for how the plant actually works. KoderXpert audited the configuration, interviewed the people using it daily, and rebuilt production, quality, inventory, BOM and finance workflows inside the same licence: a 40% faster production cycle, no proprietary modules.
Designed, built and delivered by KoderXpert Technologies Pvt. Ltd.
Official Odoo Ready Partner · Ahmedabad & Gandhinagar, India
- Client
- Sigma Terminal
- Industry
- Copper wire, rod & component manufacturing
- Platform
- Odoo Community v12 (realignment)
- Implementation partner
- KoderXpert Technologies
- Headline result
- 40% faster production cycle
01 · Overview
The 30-second version
- Sigma Terminal is a leading Indian manufacturer of copper wires, rods and custom components for the electrical, automotive and infrastructure industries.
- The company was already running Odoo Community v12, but it had never been optimised for real operations. Production had no reliable routing between work centres, stock figures were wrong often enough that nobody trusted them, quality control lived outside the production and purchase flows, BOMs and variants were a tangle, and finance still ran on spreadsheets.
- KoderXpert audited the configuration, interviewed the daily users, and rebuilt production, quality, inventory, BOM and finance workflows from the ground up inside the same Community v12 licence, with zero proprietary modules. Result: a 40% faster production cycle, fewer rejects, far fewer stock mismatches, and a system people actually use.
02 · Where the old setup broke down
What was going wrong before the realignment?
An ERP that looked functional on paper and was quietly worked around on the floor
The problem was not the absence of a system. Sigma Terminal had Odoo. The problem was that the configuration did not match how copper wire, rod and components are actually made, so every team had built a workaround, and the workarounds had become the real process.
Production ran on disjointed workflows
There was no reliable routing between work centres, so a job moved from drawing to annealing to finishing on verbal instruction rather than a system step.
The cost → nobody could say where a batch wasInventory data was unreliable
Stock mismatches were frequent enough that physical checks replaced the system count. Planning against a wrong number is worse than planning against none.
The cost → recounting instead of producingQuality control sat outside the flow
QC existed, but it was not integrated into production or purchase. A check could be skipped, or passed after the material had already moved on.
The cost → rework and rejected productBOMs and variants were poorly structured
Product variants and bills of materials had grown without a structure, which made the system slow, cluttered and confusing for the people who had to use it every day.
The cost → a low-trust systemReports nobody believed
Because the data underneath was inconsistent, reports were inaccurate, so they were rebuilt by hand. Hours went into manual report generation every week.
The cost → decisions on stale numbersFinance ran on spreadsheets
With no integration to operations, billing was delayed, some revenue was missed entirely, and reconciliation was a manual job at every period end.
The cost → revenue leakage03 · The turnaround
Drag it and see the before & after yourself
Slide the orange handle. Left is the worked-around Odoo, right is the realigned one.
- ✗ Production on disjointed workflows, no routing between work centres
- ✗ Stock counts wrong often enough to be ignored
- ✗ Quality checks outside production and purchase flows
- ✗ Cluttered BOMs and variants, slow screens, low user trust
- ✗ Finance on spreadsheets: late billing, manual reconciliation
the workaround era 😵
the same Odoo, trusted ✨
- ✔ Multi-level routing across work centres, material consumption tracked
- ✔ Automatic stock updates, reorder alerts and location tracking
- ✔ QC checks embedded in production and purchase, so nothing skips a gate
- ✔ Simplified variant logic and parent-child BOMs
- ✔ Automated billing, bank reconciliation and live financial dashboards
← drag toward the workarounds · drag toward the rebuild →
04 · The plan
What we aimed to achieve
Six objectives agreed after the audit and before a single line of code was changed. Hover any goal to tick it off.
Streamline production and inventory: digitise both processes so a job and its material move through the system, not around it.
Integrate quality into the daily workflow: make QC a step in production and purchase rather than a separate activity.
Enable real-time, accurate reporting: give operations a live view they do not have to rebuild by hand.
Simplify the system to boost adoption: fewer screens, cleaner variants, faster pages, so everyday users trust it again.
Clean and organise master data: restructure products, variants and BOMs so the system stays sustainable long term.
Connect finance to operations: move billing, payments and reconciliation off spreadsheets and onto the same Odoo database.
05 · What we delivered
What did KoderXpert build?
A platform built around the real workflow, inside the licence Sigma Terminal already owned
Production, quality and inventory workflows were rebuilt from the ground up, fully within the existing Odoo Community v12 licence and with zero proprietary modules. Six feature blocks, one database, and the accuracy and trust the system had lost restored.
Production workflow rebuild
Multi-level routing across work centres, so a manufacturing order carries its own sequence of operations, and material consumption is tracked at each step rather than estimated at the end.
every batch has a locationIntegrated quality module
QC checks embedded directly in production and purchase flows. Incoming copper is checked at receipt, work orders carry their own quality points, and a failed check stops the move.
no gate can be skippedInventory optimisation
Automatic stock updates driven by production and purchase moves, reorder alerts on minimum levels, and location tracking so the count matches the rack.
one stock figure, believedProduct & BOM restructuring
Simplified variant logic and parent-child BOM support, so a component BOM feeds a finished-goods BOM without duplication. Master data cleaned and reorganised for the long term.
a structure that stays cleanAccounting & finance
Automated billing from confirmed orders, vendor payments linked to purchase orders, bank reconciliation with statement import and auto-match, GST configuration for India, and financial dashboards on the same database as operations.
billing that keeps upCustom dashboards & reports
Real-time production, stock and performance tracking built on clean data, replacing the hours that used to go into manual report generation.
reports nobody rebuilds06 · Functional deep dive
How the connected system actually works
The feature list says what was rebuilt. This is what each block actually does for Sigma Terminal, from the receiving dock to the month-end close.
Production: routing that matches the floor
Copper wire and rod pass through several work centres before they are finished goods. The old configuration had no reliable route between them, so the system never knew where a job was.
- Multi-level routing: each manufacturing order carries its own sequence of operations across work centres, so drawing, annealing and finishing are system steps rather than verbal handoffs.
- Work centres as records: capacity and load are visible per centre, which is what lets planning see a bottleneck before it happens.
- Material consumption tracking: copper consumed is recorded at the operation that consumed it, so yield and scrap are known per step rather than guessed at the end.
- Status you can trust: a batch's location in the process is the system's answer, not the supervisor's recollection.
Quality: a gate, not a department
Sigma Terminal already did quality control. The problem was that it happened beside the process, so a check could be missed and the material moved on regardless.
- QC at purchase receipt: incoming copper is checked before it enters usable stock, so a bad lot never reaches the drawing line.
- QC inside work orders: quality points sit on the routing itself, so an operation cannot be closed without its check.
- Failed checks stop the move: a fail holds the material rather than letting it pass through, which is where rework and rejected product used to come from.
- Automated where possible: checks are triggered by the flow, not remembered by a person, which is what reduced rework and rejects after go-live.
Inventory: the count that matches the rack
Unreliable stock was named as a root cause in the audit. Fixing it meant making stock a consequence of production and purchase moves rather than a separate entry.
- Automatic stock updates: a receipt, a consumption or a finished-goods move adjusts stock at the moment it happens, with no second entry to forget.
- Reorder alerts: minimum levels trigger a signal before copper runs short, so purchasing works ahead of the line rather than behind it.
- Location tracking: stock is held by location, so the system can say which rack, not just how many.
- Fewer mismatches, fewer manual errors: the deck records a significant reduction in both, because the reasons for a wrong count were removed rather than corrected after the fact.
Products, variants and BOMs, restructured
Poor BOM structure was the first root cause the audit found, and it explained much of the slowness and clutter users complained about.
- Simplified variant logic: variants now describe real differences (gauge, finish, length) rather than every historical combination that had ever been entered.
- Parent-child BOM support: a component's BOM feeds the finished product's BOM, so a change to a sub-assembly happens once and flows upward.
- Master data cleanup: duplicate and obsolete products, variants and BOMs were cleaned before migration, so the new structure started clean.
- Sustainable by design: the structure was built to stay organised as new products are added, which was one of the five stated objectives.
Accounting: finance on the same database as the floor
Finance had been running on spreadsheets with no link to operations, which is how billing got delayed and revenue got missed. The accounting scope brought it onto the same Odoo instance.
- Core setup: a chart of accounts structured for manufacturing (revenue, COGS, expense heads), India-specific fiscal positions, sales, purchase and bank journals, and analytic accounting for cost and profit centres.
- Receivables and payables: invoices created automatically from sales orders, PO-linked vendor bills, multi-mode payment registration, automated dunning, and aging reports on both sides.
- Bank and cash: multi-bank setup, statement import with auto-match reconciliation, payment matching and knock-off, cash journals, cheque tracking and fund transfers.
- India GST: tax groups with HSN/SAC codes, CGST/SGST/IGST auto-compute, TDS configuration, reverse charge, GSTR-1 and GSTR-3B ready output, and an e-invoice-ready configuration.
- Opening balances migrated: chart of accounts, customers and vendors, outstanding receivables and payables, opening trial balance and bank opening entries.
Dashboards and reports, built on clean data
Reports had been inaccurate because the data underneath them was. Reporting was rebuilt last, once production, stock and BOM data could be trusted.
- Real-time production tracking: order status, work-centre load and consumption in one view, live rather than compiled.
- Stock and performance dashboards: current stock by location, reorder state and throughput, read from the same records that run the floor.
- Financial reporting: P&L, balance sheet, trial balance, cash flow, general and partner ledgers, tax reports and MIS, all from the same books.
- Hours given back: real-time reports replaced the manual report generation that used to consume hours every week.
Why fixing the BOM fixed the reports
A routed work order consumes what its BOM says, passes the quality point its routing carries, and moves stock when it closes. When the BOM was a tangle, every one of those downstream records inherited the mess, and the reports on top of them could not be trusted. Restructuring the BOM was not a data-hygiene task, it was the foundation for everything else.
07 · How we built it
How was the Odoo project delivered?
Seven phases, starting with an audit and ending in optimisation, not a handoff
A system that already exists rarely needs a replacement. It needs its root causes found and fixed. That is why the first phase was an audit rather than a build, and the last was support rather than a sign-off.
Comprehensive system audit find the root causes first
A full review of the existing Odoo v12 configuration plus direct interviews with the people using it daily. Three root causes surfaced: poor BOM structure, disconnected QC and unreliable stock.
Requirement mapping & blueprinting design before touching anything
Each finding mapped to the change that would fix it, and each change mapped to standard Odoo Community capability, which is what kept the build free of paid modules.
Custom development & reengineering production, quality, BOM, reports
Production routing, embedded quality checks, BOM and variant structure and reporting rebuilt in Python, XML and QWeb on the existing instance.
Data cleanup & migration start clean, not just start
Products, variants and BOMs cleaned before migration, and opening balances, partners and outstanding items brought into the accounting setup.
User testing & feedback the daily users decide
The same people interviewed in the audit tested the rebuilt flows against real jobs, and their feedback shaped the final configuration.
Training & go-live department by department
Production, quality, stores and finance trained on the flows they own, then the realigned system went live on the same licence.
Post-go-live support & optimisation stay until it settles
KoderXpert stayed engaged after go-live, tuning routings, alerts and reports as real volume ran through the rebuilt system.
08 · Engineering notes
The decisions behind the platform
The important calls on this project were about what not to do: not to migrate, not to buy modules, not to build dashboards over dirty data. These are the reasons.
Realign, do not replace
The obvious proposal would have been a migration to a newer or paid edition. The audit said the edition was not the problem.
- Same Community v12 licence: the rebuild stayed inside the edition Sigma Terminal already owned, protecting the existing investment.
- Zero proprietary modules: every feature was delivered with standard Community capability plus custom development, so there is no paid dependency to renew.
- Root causes, not symptoms: a poorly structured BOM behaves badly in any version. Fixing it in place was cheaper and faster than carrying it into a new one.
Audit first, interviews included
Configuration review alone would have found the technical problems. It would not have found why people stopped trusting the system.
- Direct user interviews: the people using Odoo daily explained where they worked around it and why, which is how the three root causes were named.
- Trust as a requirement: simplifying the system for adoption was an explicit objective, not a side effect, because a system nobody uses produces no data.
- Same users tested it: the interviewees became the testers, which closed the loop between complaint and fix.
Quality as a step in the routing
The QC problem was not a missing module. It was a check that lived beside the process instead of inside it.
- Embedded, not adjacent: quality points attach to purchase receipts and work-order operations, so the flow itself demands the check.
- Fail holds the material: a failed check blocks the move, which is the behaviour that actually reduces rework and rejects.
- No separate QC system: the checks are records on the same database as the order they belong to, so quality history is part of production history.
BOM structure before anything else
The order of work mattered. Routing, stock and reporting all consume the BOM, so it had to be right first.
- Parent-child BOMs: sub-assemblies own their own BOM and feed the finished product, which removes duplicated component lines.
- Variant logic simplified: variants reduced to real attributes, which is what made screens faster and less cluttered.
- Cleaned before migrated: master data was reorganised in the cleanup phase, so the rebuilt flows never ran on the old tangle.
Finance on the operational database
Spreadsheet finance leaks revenue because it depends on someone remembering to bill. The fix was structural.
- Invoices from orders: billing is generated from the sales order rather than typed from memory, which is where delayed and missed billing came from.
- Bills from purchase orders: vendor bills link to the PO and the receipt, so three-way matching is a record, not a reconciliation.
- Reconciliation by import: bank statements import and auto-match, turning the manual month-end into an exception list.
- GST as configuration: tax groups, HSN/SAC codes, TDS, reverse charge and GSTR-ready reports are settings on the same books, not a separate compliance tool.
Reports last, on purpose
Inaccurate reports were on the challenge list, and the temptation is to fix reports directly. That would have polished the wrong thing.
- Data before dashboards: reporting was rebuilt only after routing, QC, stock and BOM data could be trusted.
- Same source as operations: every dashboard reads the records that run the floor, so there is no reporting copy to drift.
- Less IT dependency: because the reports are live and correct, departments read them directly instead of asking IT to regenerate them.
09 · The impact
What changed after go-live?
One headline number, and four outcomes the teams feel every day
the part clients screenshot ↓- 40% faster production cycle through automation and better routing across work centres
- Automated quality checks reduced rework and rejected products
- Significant reduction in stock mismatches and manual errors
- Higher user adoption across departments, with less dependency on IT
- Real-time reports replaced hours of manual report generation
- Finance moved off spreadsheets: automated billing, bank reconciliation and GST-ready books on the same database as operations
10 · Under the hood
Technologies & core skills
"We were struggling with an ERP system that looked good on paper but wasn't helping us in practice. KoderXpert came in, understood our business, and rebuilt everything the way it should've been from the beginning. Today, we have a powerful system that works for us, not against us."
11 · Quick questions, honest answers
Thinking about a similar build?
Usually not. Sigma Terminal stayed on Odoo Community v12. The audit found the problems were structural (poor BOM structure, disconnected QC, unreliable stock) and would have followed the data into any newer edition. Fixing the root causes in place protected the existing investment and solved the underlying problems without a migration.
Yes. Every block on this project, production routing, embedded quality checks, inventory automation, BOM restructuring, accounting and custom dashboards, was delivered inside the Community v12 licence with zero proprietary modules, using standard capability plus custom development in Python, XML and QWeb.
A comprehensive audit: a review of the existing configuration and direct interviews with the people using the system daily. Configuration review finds the technical faults; the interviews find where people work around the system and why. On this project the audit named three root causes before any design began.
Each manufacturing order carries its own sequence of operations across work centres, so each stage is a system step with its own status. Material consumption is recorded at the operation that consumed it, which gives yield per step and a location for every batch. Better routing was one of the two drivers behind the 40% faster production cycle.
Quality points were attached to purchase receipts and to work-order operations, so the flow itself demands the check and a failed check holds the material instead of letting it move on. Because the checks are records on the same database as the order, quality history is part of production history. This is what reduced rework and rejected products.
Because routing, stock and reporting all consume the BOM. A tangled BOM makes every downstream record wrong and every screen slow. Simplified variant logic and parent-child BOM support were built first, and master data was cleaned before migration, so the rebuilt flows never ran on the old structure.
Stock became a consequence of production and purchase moves rather than a separate entry. Automatic stock updates, reorder alerts on minimum levels and location tracking removed the reasons a count went wrong. The deck records a significant reduction in stock mismatches and manual errors after go-live.
Chart of accounts for manufacturing, fiscal positions and journals, analytic accounting, receivables and payables with automated invoicing and dunning, bank reconciliation with statement import, cash and cheque management, India GST configuration including TDS, reverse charge and GSTR-1 and GSTR-3B ready output, financial reports, and opening balance migration.
Yes. GST is configured as settings on the same books rather than a separate tool: tax groups with HSN and SAC codes, CGST, SGST and IGST auto-compute for intra and interstate transactions, section-wise TDS, reverse charge applicability, GSTR-1 and GSTR-3B ready reports, and an e-invoice-ready configuration for IRN generation.
Inaccurate reports were a symptom of inaccurate data. Rebuilding reports first would have polished the wrong thing. Reporting was rebuilt once routing, quality, stock and BOM data could be trusted, reading the same records that run the floor. Real-time reports then replaced hours of manual report generation each week.
Simplifying the system was an explicit objective. Cleaner variants and BOMs made screens faster and less cluttered, the people interviewed in the audit tested the rebuilt flows, and training was done department by department on the flows each team owns. Adoption rose across departments and dependency on IT fell.
KoderXpert is an Odoo Ready Partner that audits before it builds, fixes root causes rather than symptoms, and will tell you when the edition you already own is enough. Go-live is followed by post-go-live support and optimisation, not a handoff. Talk to KoderXpert about the Odoo you already have.
Own an Odoo that looks functional on paper?
Tell us where the workarounds are: routing on verbal instruction, stock counted by hand, QC done beside the process, finance in a spreadsheet. KoderXpert audits first, fixes root causes second, and will say so if the licence you already own is enough.
Related case studies
- Bhagwati Iron: Odoo manufacturing ERP implementationTen modules, batch traceability, GST-ready books
- Kamakhya Pipes: Odoo manufacturing ERP implementationShop-floor hardware wired into production and stock
- Greentek Reman: Custom Odoo ERP implementationLifecycle traceability from intake gate to resale
Copper wire & component manufacturing · Odoo ERP realignment
Sigma Terminal: a precision copper manufacturer that already owned Odoo, and nobody trusted it
Published · Updated
Sigma Terminal is a leading Indian manufacturer of copper wires, rods and custom components for the electrical, automotive and infrastructure industries. The company was already running Odoo Community v12, but it had never been set up for how the plant actually works. KoderXpert audited the configuration, interviewed the people using it daily, and rebuilt production, quality, inventory, BOM and finance workflows inside the same licence: a 40% faster production cycle, no proprietary modules.
Designed, built and delivered by KoderXpert Technologies Pvt. Ltd.
Official Odoo Ready Partner · Ahmedabad & Gandhinagar, India
- Client
- Sigma Terminal
- Industry
- Copper wire, rod & component manufacturing
- Platform
- Odoo Community v12 (realignment)
- Implementation partner
- KoderXpert Technologies
- Headline result
- 40% faster production cycle
01 · Overview
The 30-second version
- Sigma Terminal is a leading Indian manufacturer of copper wires, rods and custom components for the electrical, automotive and infrastructure industries.
- The company was already running Odoo Community v12, but it had never been optimised for real operations. Production had no reliable routing between work centres, stock figures were wrong often enough that nobody trusted them, quality control lived outside the production and purchase flows, BOMs and variants were a tangle, and finance still ran on spreadsheets.
- KoderXpert audited the configuration, interviewed the daily users, and rebuilt production, quality, inventory, BOM and finance workflows from the ground up inside the same Community v12 licence, with zero proprietary modules. Result: a 40% faster production cycle, fewer rejects, far fewer stock mismatches, and a system people actually use.
02 · Where the old setup broke down
What was going wrong before the realignment?
An ERP that looked functional on paper and was quietly worked around on the floor
The problem was not the absence of a system. Sigma Terminal had Odoo. The problem was that the configuration did not match how copper wire, rod and components are actually made, so every team had built a workaround, and the workarounds had become the real process.
Production ran on disjointed workflows
There was no reliable routing between work centres, so a job moved from drawing to annealing to finishing on verbal instruction rather than a system step.
The cost → nobody could say where a batch wasInventory data was unreliable
Stock mismatches were frequent enough that physical checks replaced the system count. Planning against a wrong number is worse than planning against none.
The cost → recounting instead of producingQuality control sat outside the flow
QC existed, but it was not integrated into production or purchase. A check could be skipped, or passed after the material had already moved on.
The cost → rework and rejected productBOMs and variants were poorly structured
Product variants and bills of materials had grown without a structure, which made the system slow, cluttered and confusing for the people who had to use it every day.
The cost → a low-trust systemReports nobody believed
Because the data underneath was inconsistent, reports were inaccurate, so they were rebuilt by hand. Hours went into manual report generation every week.
The cost → decisions on stale numbersFinance ran on spreadsheets
With no integration to operations, billing was delayed, some revenue was missed entirely, and reconciliation was a manual job at every period end.
The cost → revenue leakage03 · The turnaround
Drag it and see the before & after yourself
Slide the orange handle. Left is the worked-around Odoo, right is the realigned one.
- ✗ Production on disjointed workflows, no routing between work centres
- ✗ Stock counts wrong often enough to be ignored
- ✗ Quality checks outside production and purchase flows
- ✗ Cluttered BOMs and variants, slow screens, low user trust
- ✗ Finance on spreadsheets: late billing, manual reconciliation
the workaround era 😵
the same Odoo, trusted ✨
- ✔ Multi-level routing across work centres, material consumption tracked
- ✔ Automatic stock updates, reorder alerts and location tracking
- ✔ QC checks embedded in production and purchase, so nothing skips a gate
- ✔ Simplified variant logic and parent-child BOMs
- ✔ Automated billing, bank reconciliation and live financial dashboards
← drag toward the workarounds · drag toward the rebuild →
04 · The plan
What we aimed to achieve
Six objectives agreed after the audit and before a single line of code was changed. Hover any goal to tick it off.
Streamline production and inventory: digitise both processes so a job and its material move through the system, not around it.
Integrate quality into the daily workflow: make QC a step in production and purchase rather than a separate activity.
Enable real-time, accurate reporting: give operations a live view they do not have to rebuild by hand.
Simplify the system to boost adoption: fewer screens, cleaner variants, faster pages, so everyday users trust it again.
Clean and organise master data: restructure products, variants and BOMs so the system stays sustainable long term.
Connect finance to operations: move billing, payments and reconciliation off spreadsheets and onto the same Odoo database.
05 · What we delivered
What did KoderXpert build?
A platform built around the real workflow, inside the licence Sigma Terminal already owned
Production, quality and inventory workflows were rebuilt from the ground up, fully within the existing Odoo Community v12 licence and with zero proprietary modules. Six feature blocks, one database, and the accuracy and trust the system had lost restored.
Production workflow rebuild
Multi-level routing across work centres, so a manufacturing order carries its own sequence of operations, and material consumption is tracked at each step rather than estimated at the end.
every batch has a locationIntegrated quality module
QC checks embedded directly in production and purchase flows. Incoming copper is checked at receipt, work orders carry their own quality points, and a failed check stops the move.
no gate can be skippedInventory optimisation
Automatic stock updates driven by production and purchase moves, reorder alerts on minimum levels, and location tracking so the count matches the rack.
one stock figure, believedProduct & BOM restructuring
Simplified variant logic and parent-child BOM support, so a component BOM feeds a finished-goods BOM without duplication. Master data cleaned and reorganised for the long term.
a structure that stays cleanAccounting & finance
Automated billing from confirmed orders, vendor payments linked to purchase orders, bank reconciliation with statement import and auto-match, GST configuration for India, and financial dashboards on the same database as operations.
billing that keeps upCustom dashboards & reports
Real-time production, stock and performance tracking built on clean data, replacing the hours that used to go into manual report generation.
reports nobody rebuilds06 · Functional deep dive
How the connected system actually works
The feature list says what was rebuilt. This is what each block actually does for Sigma Terminal, from the receiving dock to the month-end close.
Production: routing that matches the floor
Copper wire and rod pass through several work centres before they are finished goods. The old configuration had no reliable route between them, so the system never knew where a job was.
- Multi-level routing: each manufacturing order carries its own sequence of operations across work centres, so drawing, annealing and finishing are system steps rather than verbal handoffs.
- Work centres as records: capacity and load are visible per centre, which is what lets planning see a bottleneck before it happens.
- Material consumption tracking: copper consumed is recorded at the operation that consumed it, so yield and scrap are known per step rather than guessed at the end.
- Status you can trust: a batch's location in the process is the system's answer, not the supervisor's recollection.
Quality: a gate, not a department
Sigma Terminal already did quality control. The problem was that it happened beside the process, so a check could be missed and the material moved on regardless.
- QC at purchase receipt: incoming copper is checked before it enters usable stock, so a bad lot never reaches the drawing line.
- QC inside work orders: quality points sit on the routing itself, so an operation cannot be closed without its check.
- Failed checks stop the move: a fail holds the material rather than letting it pass through, which is where rework and rejected product used to come from.
- Automated where possible: checks are triggered by the flow, not remembered by a person, which is what reduced rework and rejects after go-live.
Inventory: the count that matches the rack
Unreliable stock was named as a root cause in the audit. Fixing it meant making stock a consequence of production and purchase moves rather than a separate entry.
- Automatic stock updates: a receipt, a consumption or a finished-goods move adjusts stock at the moment it happens, with no second entry to forget.
- Reorder alerts: minimum levels trigger a signal before copper runs short, so purchasing works ahead of the line rather than behind it.
- Location tracking: stock is held by location, so the system can say which rack, not just how many.
- Fewer mismatches, fewer manual errors: the deck records a significant reduction in both, because the reasons for a wrong count were removed rather than corrected after the fact.
Products, variants and BOMs, restructured
Poor BOM structure was the first root cause the audit found, and it explained much of the slowness and clutter users complained about.
- Simplified variant logic: variants now describe real differences (gauge, finish, length) rather than every historical combination that had ever been entered.
- Parent-child BOM support: a component's BOM feeds the finished product's BOM, so a change to a sub-assembly happens once and flows upward.
- Master data cleanup: duplicate and obsolete products, variants and BOMs were cleaned before migration, so the new structure started clean.
- Sustainable by design: the structure was built to stay organised as new products are added, which was one of the five stated objectives.
Accounting: finance on the same database as the floor
Finance had been running on spreadsheets with no link to operations, which is how billing got delayed and revenue got missed. The accounting scope brought it onto the same Odoo instance.
- Core setup: a chart of accounts structured for manufacturing (revenue, COGS, expense heads), India-specific fiscal positions, sales, purchase and bank journals, and analytic accounting for cost and profit centres.
- Receivables and payables: invoices created automatically from sales orders, PO-linked vendor bills, multi-mode payment registration, automated dunning, and aging reports on both sides.
- Bank and cash: multi-bank setup, statement import with auto-match reconciliation, payment matching and knock-off, cash journals, cheque tracking and fund transfers.
- India GST: tax groups with HSN/SAC codes, CGST/SGST/IGST auto-compute, TDS configuration, reverse charge, GSTR-1 and GSTR-3B ready output, and an e-invoice-ready configuration.
- Opening balances migrated: chart of accounts, customers and vendors, outstanding receivables and payables, opening trial balance and bank opening entries.
Dashboards and reports, built on clean data
Reports had been inaccurate because the data underneath them was. Reporting was rebuilt last, once production, stock and BOM data could be trusted.
- Real-time production tracking: order status, work-centre load and consumption in one view, live rather than compiled.
- Stock and performance dashboards: current stock by location, reorder state and throughput, read from the same records that run the floor.
- Financial reporting: P&L, balance sheet, trial balance, cash flow, general and partner ledgers, tax reports and MIS, all from the same books.
- Hours given back: real-time reports replaced the manual report generation that used to consume hours every week.
Why fixing the BOM fixed the reports
A routed work order consumes what its BOM says, passes the quality point its routing carries, and moves stock when it closes. When the BOM was a tangle, every one of those downstream records inherited the mess, and the reports on top of them could not be trusted. Restructuring the BOM was not a data-hygiene task, it was the foundation for everything else.
07 · How we built it
How was the Odoo project delivered?
Seven phases, starting with an audit and ending in optimisation, not a handoff
A system that already exists rarely needs a replacement. It needs its root causes found and fixed. That is why the first phase was an audit rather than a build, and the last was support rather than a sign-off.
Comprehensive system audit find the root causes first
A full review of the existing Odoo v12 configuration plus direct interviews with the people using it daily. Three root causes surfaced: poor BOM structure, disconnected QC and unreliable stock.
Requirement mapping & blueprinting design before touching anything
Each finding mapped to the change that would fix it, and each change mapped to standard Odoo Community capability, which is what kept the build free of paid modules.
Custom development & reengineering production, quality, BOM, reports
Production routing, embedded quality checks, BOM and variant structure and reporting rebuilt in Python, XML and QWeb on the existing instance.
Data cleanup & migration start clean, not just start
Products, variants and BOMs cleaned before migration, and opening balances, partners and outstanding items brought into the accounting setup.
User testing & feedback the daily users decide
The same people interviewed in the audit tested the rebuilt flows against real jobs, and their feedback shaped the final configuration.
Training & go-live department by department
Production, quality, stores and finance trained on the flows they own, then the realigned system went live on the same licence.
Post-go-live support & optimisation stay until it settles
KoderXpert stayed engaged after go-live, tuning routings, alerts and reports as real volume ran through the rebuilt system.
08 · Engineering notes
The decisions behind the platform
The important calls on this project were about what not to do: not to migrate, not to buy modules, not to build dashboards over dirty data. These are the reasons.
Realign, do not replace
The obvious proposal would have been a migration to a newer or paid edition. The audit said the edition was not the problem.
- Same Community v12 licence: the rebuild stayed inside the edition Sigma Terminal already owned, protecting the existing investment.
- Zero proprietary modules: every feature was delivered with standard Community capability plus custom development, so there is no paid dependency to renew.
- Root causes, not symptoms: a poorly structured BOM behaves badly in any version. Fixing it in place was cheaper and faster than carrying it into a new one.
Audit first, interviews included
Configuration review alone would have found the technical problems. It would not have found why people stopped trusting the system.
- Direct user interviews: the people using Odoo daily explained where they worked around it and why, which is how the three root causes were named.
- Trust as a requirement: simplifying the system for adoption was an explicit objective, not a side effect, because a system nobody uses produces no data.
- Same users tested it: the interviewees became the testers, which closed the loop between complaint and fix.
Quality as a step in the routing
The QC problem was not a missing module. It was a check that lived beside the process instead of inside it.
- Embedded, not adjacent: quality points attach to purchase receipts and work-order operations, so the flow itself demands the check.
- Fail holds the material: a failed check blocks the move, which is the behaviour that actually reduces rework and rejects.
- No separate QC system: the checks are records on the same database as the order they belong to, so quality history is part of production history.
BOM structure before anything else
The order of work mattered. Routing, stock and reporting all consume the BOM, so it had to be right first.
- Parent-child BOMs: sub-assemblies own their own BOM and feed the finished product, which removes duplicated component lines.
- Variant logic simplified: variants reduced to real attributes, which is what made screens faster and less cluttered.
- Cleaned before migrated: master data was reorganised in the cleanup phase, so the rebuilt flows never ran on the old tangle.
Finance on the operational database
Spreadsheet finance leaks revenue because it depends on someone remembering to bill. The fix was structural.
- Invoices from orders: billing is generated from the sales order rather than typed from memory, which is where delayed and missed billing came from.
- Bills from purchase orders: vendor bills link to the PO and the receipt, so three-way matching is a record, not a reconciliation.
- Reconciliation by import: bank statements import and auto-match, turning the manual month-end into an exception list.
- GST as configuration: tax groups, HSN/SAC codes, TDS, reverse charge and GSTR-ready reports are settings on the same books, not a separate compliance tool.
Reports last, on purpose
Inaccurate reports were on the challenge list, and the temptation is to fix reports directly. That would have polished the wrong thing.
- Data before dashboards: reporting was rebuilt only after routing, QC, stock and BOM data could be trusted.
- Same source as operations: every dashboard reads the records that run the floor, so there is no reporting copy to drift.
- Less IT dependency: because the reports are live and correct, departments read them directly instead of asking IT to regenerate them.
09 · The impact
What changed after go-live?
One headline number, and four outcomes the teams feel every day
the part clients screenshot ↓- 40% faster production cycle through automation and better routing across work centres
- Automated quality checks reduced rework and rejected products
- Significant reduction in stock mismatches and manual errors
- Higher user adoption across departments, with less dependency on IT
- Real-time reports replaced hours of manual report generation
- Finance moved off spreadsheets: automated billing, bank reconciliation and GST-ready books on the same database as operations
10 · Under the hood
Technologies & core skills
"We were struggling with an ERP system that looked good on paper but wasn't helping us in practice. KoderXpert came in, understood our business, and rebuilt everything the way it should've been from the beginning. Today, we have a powerful system that works for us, not against us."
11 · Quick questions, honest answers
Thinking about a similar build?
Usually not. Sigma Terminal stayed on Odoo Community v12. The audit found the problems were structural (poor BOM structure, disconnected QC, unreliable stock) and would have followed the data into any newer edition. Fixing the root causes in place protected the existing investment and solved the underlying problems without a migration.
Yes. Every block on this project, production routing, embedded quality checks, inventory automation, BOM restructuring, accounting and custom dashboards, was delivered inside the Community v12 licence with zero proprietary modules, using standard capability plus custom development in Python, XML and QWeb.
A comprehensive audit: a review of the existing configuration and direct interviews with the people using the system daily. Configuration review finds the technical faults; the interviews find where people work around the system and why. On this project the audit named three root causes before any design began.
Each manufacturing order carries its own sequence of operations across work centres, so each stage is a system step with its own status. Material consumption is recorded at the operation that consumed it, which gives yield per step and a location for every batch. Better routing was one of the two drivers behind the 40% faster production cycle.
Quality points were attached to purchase receipts and to work-order operations, so the flow itself demands the check and a failed check holds the material instead of letting it move on. Because the checks are records on the same database as the order, quality history is part of production history. This is what reduced rework and rejected products.
Because routing, stock and reporting all consume the BOM. A tangled BOM makes every downstream record wrong and every screen slow. Simplified variant logic and parent-child BOM support were built first, and master data was cleaned before migration, so the rebuilt flows never ran on the old structure.
Stock became a consequence of production and purchase moves rather than a separate entry. Automatic stock updates, reorder alerts on minimum levels and location tracking removed the reasons a count went wrong. The deck records a significant reduction in stock mismatches and manual errors after go-live.
Chart of accounts for manufacturing, fiscal positions and journals, analytic accounting, receivables and payables with automated invoicing and dunning, bank reconciliation with statement import, cash and cheque management, India GST configuration including TDS, reverse charge and GSTR-1 and GSTR-3B ready output, financial reports, and opening balance migration.
Yes. GST is configured as settings on the same books rather than a separate tool: tax groups with HSN and SAC codes, CGST, SGST and IGST auto-compute for intra and interstate transactions, section-wise TDS, reverse charge applicability, GSTR-1 and GSTR-3B ready reports, and an e-invoice-ready configuration for IRN generation.
Inaccurate reports were a symptom of inaccurate data. Rebuilding reports first would have polished the wrong thing. Reporting was rebuilt once routing, quality, stock and BOM data could be trusted, reading the same records that run the floor. Real-time reports then replaced hours of manual report generation each week.
Simplifying the system was an explicit objective. Cleaner variants and BOMs made screens faster and less cluttered, the people interviewed in the audit tested the rebuilt flows, and training was done department by department on the flows each team owns. Adoption rose across departments and dependency on IT fell.
KoderXpert is an Odoo Ready Partner that audits before it builds, fixes root causes rather than symptoms, and will tell you when the edition you already own is enough. Go-live is followed by post-go-live support and optimisation, not a handoff. Talk to KoderXpert about the Odoo you already have.
Own an Odoo that looks functional on paper?
Tell us where the workarounds are: routing on verbal instruction, stock counted by hand, QC done beside the process, finance in a spreadsheet. KoderXpert audits first, fixes root causes second, and will say so if the licence you already own is enough.
Related case studies
- Bhagwati Iron: Odoo manufacturing ERP implementationTen modules, batch traceability, GST-ready books
- Kamakhya Pipes: Odoo manufacturing ERP implementationShop-floor hardware wired into production and stock
- Greentek Reman: Custom Odoo ERP implementationLifecycle traceability from intake gate to resale
