Project Name
Extended Odoo 18 PLM With 11 Custom Features in One Module
Our client is a multi-country manufacturer operating across East and Southern Africa, with registrations in Uganda, Rwanda, Tanzania, and Zambia. Running Odoo 18 with native PLM, the organisation needed collision-safe item codes alongside legacy Arena PLM imports, structured revision tracking, BOM audit history, and stronger ECO governance.
Delivery and packing data, including MOQ, lead time, dimensions, CBM, and pallet drawings, also lived outside Odoo, requiring procurement and logistics teams to switch systems. Ksolves extended Odoo 18 PLM with eleven targeted customisations in a single upgrade-safe module, without modifying native PLM functionality.
The implementation had to address critical gaps in Odoo around item codes, revisions, BOM history, packaging data, and PO usability.
- No Country-Aware Item Codes: Odoo's native Internal Reference field is free text, with no mechanism to generate structured codes containing country identifiers, limiting traceability across POs and BOMs.
- Duplicate Code Risk on Import: Legacy Arena PLM codes coexisted with new Odoo-generated codes. Without collision checks, new sequence numbers could duplicate imported codes and silently disrupt PO matching and BOM references.
- Revision Not a First-Class Field: Revisions existed only as suffixes in Arena item codes, such as -0A. Odoo had no dedicated revision field for filtering, sorting, or reporting, and ECO application did not update the product master.
- No Historical BOM Audit Trail: Odoo's native ECO process overwrote BOM quantities and archived the previous BOM. Once replaced, historical quantities were not recoverable within Odoo without Arena or backups.
- Packaging Data Outside Odoo: MOQ, lead time, minimum shipping quantity, dimensions, CBM, and pallet drawings lived in a third-party tool, forcing procurement and logistics teams to switch systems for product and PO information.
- Cluttered PO Product Display: Odoo prepended internal references to PO product dropdowns, creating strings such as [F0001UG] BAT,EOL, Product Name and making product selection harder for procurement teams.
Ksolves, an AI-first Odoo development company, developed a solution that used a pure inheritance layer, preserving native PLM features such as approvals, BOM versioning, ECO types, and revision controls. We implemented customisations through @api.depends, _inherit, and a single action_apply override using super(). No native PLM code was modified.
- Country-Aware Item Codes: plm.category adds prefixes and auto-generates four-digit sequences with country suffixes such as UG, RW, TZ, and ZM. Unknown countries use WW.
- Duplicate-Safe Sequence Generation (P6): _get_safe_sequence() checks each generated code against existing records and advances the sequence when a duplicate is found.
- Protected Auto-Generated Codes (P2): product.template.write() blocks manual changes to default_code for PLM-category products, keeping codes sequence-controlled.
- Revision as a First-Class Field: A dedicated revision field starts at 01, while full_item_code combines the item code and revision, such as F0001UG-01. Approved ECOs automatically increment the revision.
- ECO Revision Sync: The action_apply() override runs the native ECO process first, then updates the product revision automatically.
- Historical BOM Preservation: Changed BOM lines are flagged as historical before ECO application, with the revision and ECO reference retained for auditability.
- Where Used Tab: A computed field displays active and historical BOM usage, including quantity, version, BOM type, revision, and ECO reference.
- 14 Fields Centralised in Odoo: Delivery and packing fields cover MOQ, shipping quantity, lead time, dimensions, CBM, weights, package details, and pallet drawings, all accessible from the product form.
- Bracket Prefix Suppressed on PO Lines: View inheritance hides the internal reference prefix from PO product dropdowns, giving procurement teams a cleaner product display.
Technology Stack
| Category | Technology |
|---|---|
| ERP Platform | Odoo 18 Community + Enterprise PLM |
| Backend | Python 3.11: ORM, compute fields, overrides |
| Frontend / UI | Odoo XML views: QWeb / Owl |
| Database | PostgreSQL 15 |
| Integration | Native mrp_plm module |
The solution consolidated all 11 requirements into a single upgrade-safe module. It eliminates item-code collision risks, improving revision and BOM traceability, centralising packaging data, and keeping native PLM functionality intact.
- Item Code Uniqueness Guaranteed at Creation: Every auto-generated code is checked against the database before acceptance, preventing conflicts with legacy Arena imports or manually entered codes.
- Revision as a First-Class Odoo Field: Revision is now stored directly on product.template, automatically incremented after each ECO, and displayed alongside the full item code on the product form.
- Full BOM Audit Trail in the Where Used Tab: Historical BOM lines retain their revision, ECO reference, and historical status, allowing teams to trace previous BOM states directly within Odoo.
- 14 Delivery and Packing Fields Centralised in Odoo: MOQ, lead time, shipping quantity, dimensions, CBM, weights, and pallet drawings are now available directly on the product form and across procurement workflows.
- Cleaner PO Product Display: Internal reference prefixes are suppressed from PO product dropdowns, giving procurement teams cleaner product names and making product selection easier.
With 11 targeted customizations delivered through a single upgrade-safe module, the client now has stronger control over item codes, revisions, BOM history, and packaging data, all within Odoo. Native PLM workflows remain fully intact, with no modifications to core functionality. The result is a more connected product lifecycle workflow with less reliance on external systems.
Does Your Odoo PLM Still Lack Revision Tracking, BOM History, and Country-Aware Item Codes?
