ODOO 19 · ENTERPRISE · EXTENDS ODOO PLM
PLM Advanced
Odoo PLM records when a change should take effect, who approves it and what it changes. This module makes that change actually happen — at the planned moment, on every product it touches, with a signature behind it and a document to show for it.
Start with one line of Odoo's own source
Open an engineering change order. Set an effective date. Nothing happens on that date — and the field says why:
# mrp_plm/models/mrp_eco.py
effectivity_date = fields.Datetime('Effective Date', tracking=True,
help="For reference only.")
There is no scheduled action behind it. Somebody has to remember to press Apply Changes. Press it a day early and production already running switches revision — and afterwards nobody can tell which revision anything was built to, because only the current one is ever shown.
01
A cut-in point that actually cuts in
Each change order chooses when it becomes effective. A scheduler applies it then — and only then.
Manual
The default. Strictly native Odoo — nothing changes until you ask.
At effective date
Applied automatically on the date you planned, and never before it.
After an order
Finish the batch already running on the current revision, then cut in. The classic shop-floor rule.
Stock used up
Keep consuming the component being removed until what is left reaches your threshold.
For the stock rule you choose the basis — free to use, on hand, or forecasted so that goods already on order are consumed too — a threshold, and optionally a single location. The components to watch are detected from the change itself.
Governance is never bypassed
Reaching the cut-in point is only half of it. A change is applied automatically only if it could also be applied by hand at that instant: the right stage, a revision that has been started, every mandatory approval granted, and a signature if the type demands one. When the date arrives and something is missing, nothing happens in silence — the change is held back, the reason is written on the record, and an activity lands on the person responsible.
The date has passed, but a mandatory approval is missing: the change is held back and says so.
02
The revision that was actually produced
Odoo reads a product's version live. Apply one change and every past order starts reporting today's revision. Months later, during a recall, the question cannot be answered.
| Native Odoo | With PLM Advanced | |
|---|---|---|
| Revision an order was planned to | today's | frozen at confirmation |
| Revision it was built to | today's | frozen at closing |
| Revision moved mid-production | invisible | flagged on the order |
| Revision behind a serial number | not recorded | on the lot itself |
Both snapshots are plain stored values. Nothing recomputes them, which is the point: they survive every later change, and backorders get their own.
A finished order keeps reporting the revision it was actually built to.
03
A lifecycle worth the name
Odoo's module is called Product Lifecycle Management, yet a product only ever has two states: archived, or not. Every part now carries a real one.
In Design · Prototype
Not ready for a released product. Putting one into a released bill of materials is reported — or refused.
Released
Approved for production. What everything is set to on install, so nothing changes the day you install this.
Phase-Out · Obsolete
Still consumable, or not at all. Designing one back in is exactly what the guard exists to stop.
The guard has three settings per company — off, warn on the bill of materials, or refuse to save. Out of the box it is off, and off means genuinely silent.
04
Who actually makes the part
Odoo has no concept of a manufacturer — the word does not appear in its product module. Its vendor price list answers who sells it to me, never what part is it. Two distributors of the same component look like two unrelated things, and a second source cannot be recorded at all.
INTERNAL PART
MCU-01
what you buy
APPROVED MANUFACTURER PARTS
ST · STM32F103C8T6
approved · active
Microchip · ATSAMD21
approved · end of life
VENDORS
Mouser
Farnell
who ships it
Each part carries its approved manufacturer list: manufacturer, part number, your approval, and separately what the manufacturer says — active, not recommended for new designs, end of life, obsolete, with the last-time-buy date. Vendor lines hang off those manufacturer parts, so the chain is complete.
Sourcing risk
| No approved source | Nothing left that may be bought. |
| Not recommended for new designs | Still shipping, but every source is NRND. Move now, not in a panic. |
| Single source | One discontinuation away from stopping the line. |
| Second sourced | Two or more usable sources. |
The day a manufacturer declares a part end of life, the products depending on it move into the report by themselves.
The approved manufacturer list: your approval and the manufacturer's status, side by side.
Every product one discontinuation away from stopping the line, in one list.
05
The two steps around the change order
Before — the change request
Odoo starts at the change order, when somebody has already decided what to do. Engineering starts one step earlier: a problem reported by the shop floor, quality or a customer, raised from the very order or serial number it happened on, triaged by a reviewer — and which may perfectly well be turned down, with the reason on record. What survives becomes a change order in one click, with the trail running both ways.
After — the change notice
Applying a change in Odoo flips a flag and tells nobody. A change notice is the numbered document that goes out when it goes live: what changed, from which revision to which, who approved and who signed, sent to a distribution list, with a dated acknowledgement per recipient and a PDF to hand over. It is frozen at issue.
Deviations and concessions
Every factory departs from the released definition now and then: a substitute part, a batch slightly out of spec. Without a record it happens anyway, in an email or not at all. The point is not to forbid it but to bound it — named orders, a date range, a quantity, a signature. And the case that actually hurts is handled: a permission attached to an order but no longer in force makes that order say so, in red.
The change notice: numbered, frozen at issue, with its distribution list.
A deviation attached to this order is no longer in force, and the order shouts about it.
06
Compliance, down to the last screw
Answering per product is easy and useless. The question an audit asks is whether everything inside can be proven.
| Scooter | compliant |
| ↳ Controller board | compliant |
| ↳ Microcontroller | not compliant |
Native Odoo would answer compliant for the scooter. It is wrong, and this is the screen that says so — one button walks the whole tree and lists every component that cannot be proven, with its path.
RoHS, REACH SVHC and conflict minerals ship with the module and are not mandatory on purpose: installing must not turn a whole catalogue red overnight. Declarations carry the status, the exemption relied upon, the source of the evidence, its expiry — expired evidence is no evidence — and the file itself. They can be recorded per manufacturer part, because two approved sources for one internal part number can give opposite answers.
Two components that cannot be proven, found two levels down, with their path.
07
One change, forty products
An Odoo change order carries a single product and a single bill of materials. The documented answer to a connector used in forty assemblies is to duplicate the change order forty times. Forty approvals. Forty chances to forget one.
| A change set | What it does |
|---|---|
| Declare the substitution once | Replace, remove, add or re-quantify a component. |
| Find the bills of materials | One button runs the where-used search for you. |
| Create the change orders | One perfectly native Odoo change order per bill of materials, each with its revision started and the substitution already carried out. |
| Decide once | One stage, one cut-in point, one signature, one notice — for all of them. |
| Apply all | Each in its own savepoint: one badly configured order never takes the other thirty-nine with it, and the set counts as applied only when all of it is. |
One substitution, three bills of materials, one signature, one notice.
08
Know what a change reaches, before approving it
Odoo shows the diff of one bill of materials and stops. One button now answers the three questions that decide whether to approve:
- Products reached — the full multi-level where-used, with the path down to the component. Native Odoo counts one level up and stops.
- Orders already running — every manufacturing order still open on the revision about to change.
- Cost — standard cost of one unit before and after, and the delta.
09
A signature, not a status
Odoo's approval records who clicked and when. It does not ask them to prove it was them, does not record what they meant by it, and the row can be edited afterwards. For a regulated industry that is not a signature.
Re-authentication
The password is asked again at the moment of signing. The difference between "the record says Marie approved" and "Marie proved it was her".
Meaning
Reviewed, approved, released for production, rejected or witnessed — stored with a snapshot of the signer's name and login.
Tamper-evident
Every signature is SHA-256 chained to the one before. Signatures can never be modified nor deleted, and one action re-verifies the whole chain.
Signatures are chained, and can never be edited nor deleted.
Safe to install on a live database
Nothing changes until you ask
Cut-in trigger defaults to manual. Lifecycle enforcement defaults to off. Regulations ship not mandatory. Every product becomes Released. Install it on Monday, nothing behaves differently on Tuesday.
Native Odoo is left alone
No core model is made stricter, no required field is added to a core table, no approval workflow is replaced. Odoo's own PLM test suite passes untouched, as does the whole Manufacturing suite — 419 tests.
Tested like something you depend on
232 automated tests, plus a 204-check acceptance battery that renders every view for every kind of user, opens every action, prints every report and deliberately does everything in the wrong order.
What this module does not do
Knowing before you buy is worth more than a surprise afterwards.
- No CAD or document vault. No check-in / check-out, no revision control on drawings. Documents stay Odoo attachments.
- Compliance is administration, not calculation. Substance-level data (CAS numbers, ppm thresholds, IPC-1752A import) is not modelled. What is tracked is the declaration and its evidence.
- No supplier portal. The module gives you somewhere to file supplier declarations, not a way to chase them.
- Serial-number effectivity is an output, not a trigger. You can read which revision a serial was built to; you cannot say "from serial 1234 onwards".
- Costing is an order of magnitude. Impact uses single-level standard cost — it informs an approval, it is not a costing run.
- No external service is used. The module sends no data anywhere, requires no activation key and needs no internet access.
Technical facts
| Odoo version | 19.0, Enterprise |
| Depends on | Odoo PLM (mrp_plm) only, and therefore Manufacturing and Inventory. Quality is not a dependency: change requests can be raised from a quality alert if that app happens to be installed, and simply do not offer it if it is not. |
| Adds | Nine models of its own, one scheduled action, one PDF report and two analysis screens. Extends products, bills of materials, manufacturing orders, lots, contacts, vendor lines and Odoo's change orders. |
| Multi-company | Every record carries a company and a record rule, proven by tests rather than assumed. |
| Installation | Copy the module into your add-ons folder and install it. No other procedure. |
| Language | English, fully translatable. |
| Licence | OPL-1 |
A step-by-step manual covering every feature ships with the module, in README.md at the root of the add-on. Support: see the contact address in the module manifest.
Odoo Proprietary License v1.0 This software and associated files (the "Software") may only be used (executed, modified, executed after modifications) if you have purchased a valid license from the authors, typically via Odoo Apps, or if you have received a written agreement from the authors of the Software (see the COPYRIGHT file). You may develop Odoo modules that use the Software as a library (typically by depending on it, importing it and using its resources), but without copying any source code or material from the Software. You may distribute those modules under the license of your choice, provided that this license is compatible with the terms of the Odoo Proprietary License (For example: LGPL, MIT, or proprietary licenses similar to this one). It is forbidden to publish, distribute, sublicense, or sell copies of the Software or modified copies of the Software. The above copyright notice and this permission notice must be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
Please log in to comment on this module