Engineering Change Orders are the backbone of any product lifecycle management system, but the forms they live in tend to accumulate fields the way old houses accumulate extension cords. Odoo’s PLM module has carried fields like “Apply on” and “Update Version” on the ECO form for several releases, each one requiring an explanation of when to use it and when to ignore it. Version 20 cleans house.
A Leaner ECO Form
The “Apply on” and “Update Version” fields are gone from the main form. So is the note that used to tell users they needed to select a product before the BOM field became available. The form now starts clean: pick an ECO type, pick a product, pick a BOM. The noise-to-signal ratio drops considerably.
This is more than cosmetic. Removing fields that required contextual knowledge to use correctly — “Apply on” was especially confusing for new users — reduces onboarding friction and eliminates a class of configuration errors where someone would set the field incorrectly and wonder why their change didn’t propagate.
Apply Changes Now Asks What to Version
The version-control decision that used to happen implicitly now happens explicitly. When an engineer clicks “Apply Changes,” a pop-up appears with two checkboxes: one for incrementing the product version and one for incrementing the BOM version. You can check both, one, or neither.
This is a significant workflow improvement. A component substitution that doesn’t change the product’s form factor probably warrants a BOM version bump but not a product version bump. A packaging redesign might warrant both. Previously, the system made that decision for you based on the “Update Version” field setting. Now the engineer makes the call at the moment it matters — when they’re applying the change and have full context about what just happened.
Compare BoMs: The Feature That Should Have Existed Years Ago
A new smart button called “Compare BoMs” opens a pivot table showing the quantity differences between the current BOM and the proposed revision. Component added? It shows up with a “+2” in the difference column. Component removed? A red “-4” tells you exactly what’s going away.
This is the kind of tool that manufacturing engineers will use on every single ECO. Before this, comparing two BOMs meant opening them in separate tabs and scrolling through component lists manually, or exporting both to a spreadsheet and running a VLOOKUP. The built-in pivot comparison eliminates that entire workflow in a single click.
Default ECO Types Ship Out of the Box
Odoo now includes two pre-configured ECO types: Product Revision for modifications to existing products and New Product Introduction for bringing entirely new items into the system. Each comes with four default Kanban stages: New, In Progress, Validated, and Effective.
Custom ECO types created after installation start with no stages, which is a deliberate design choice. It prevents new types from inheriting assumptions that don’t apply. A regulatory compliance ECO type might need stages like “Submitted,” “Under Review,” and “Approved” — none of which match the defaults. Starting blank forces intentional stage design.
What This Signals for PLM Users
Taken together, these changes suggest Odoo is maturing its PLM offering from a basic change-tracking tool into something that understands manufacturing workflows at a more granular level. The BOM comparison alone will save engineering teams hours per week. The versioning pop-up catches a decision point that was previously invisible. And the cleaner form lowers the barrier for organizations where PLM adoption has been slowed by user confusion.
For companies evaluating PLM solutions, these aren’t headline features that show up in a vendor comparison matrix. They’re the kind of daily-use improvements that determine whether a tool gets adopted or abandoned after the implementation consultant leaves.