The manufacturing order reads the current version
A manufacturing order created after the effectivity date takes v3's components and v3's cost. The one launched before it keeps v2 to the end, and says so.
PLM · Inventory and Manufacturing
Every product with its versions. One of them is what the shop floor builds.
This is the room.
One product, opened: its versions in the header, the bill of materials of the current one below, the drawing and the certificate on the version they belong to, and the change in progress reading in from the people reviewing it.
The things a product record needs, none of them in a drive folder.
What a version carries, who reviews a change and which document goes out with it are yours to set.
Versions of the bill of materials
Two versions open side by side, the lines that differ marked, the cost of each. The one marked current is the one every new manufacturing order reads.
Engineering change orders
A change is a record: what it affects, why, who reviews it, and the date it takes effect. Nothing on the shop floor moves until it is approved.
Drawings and certificates on the version
The drawing, the declaration of conformity and the test report sit on the version they describe, so v2's certificate never goes out with a v3 panel.
Where used
One part, every product and every open order that carries it, before you change it.
Every change, logged
Who changed which line, when, on which version, and the ECO that allowed it.
Your product, shaped for you. And for someone nothing like you.
What adapts: what a version is (a revision of one product, or a variant made for one client), the fields it carries, the documents attached to it, whether a change needs a change order and who reviews it. Two businesses can run PLM and disagree on every one of those.
A bespoke furniture maker
A product is a piece, and a version is the variant made for one client: the finish, the width, the hardware, the client's approved drawing. A change asked by the client is a new variant on the same piece, signed off by the client, with no engineering change order in the way.
An electrical equipment maker
A product is a reference, and a version is a revision that every unit built after a date follows. It carries the declaration of conformity, the test report and the drawing per revision, and a change is an engineering change order reviewed by production, purchasing and quality before it takes effect.
The change takes effect on a date, everywhere at once.
ECO-2026-0009 is approved on 18 September and effective on 1 October. That date is a field on the change, and every record that carries the old driver reads it: v3 becomes the current version of the panel; the manufacturing orders launched before the date finish on v2, the ones planned after it are built on v3; the purchase order still open for 200 old drivers is flagged for purchasing to reduce or cancel; the 20 drivers left on the shelf after the last v2 order are shown as what they are, stock without a use, before anyone finds them in a count. The tool that only holds engineering settles all of that by email.
The versions, the changes, the documents.
Versions
Every product with its current version, the one before and the one in draft, and the orders reading each.
The versions, the changes, the documents.
Every product with its current version, the one before and the one in draft, and the orders reading each.
Reviewed together, on the record.
An engineering change is not engineering's alone. Production wants to know which orders finish on the old version; purchasing wants a price for the new part before it agrees; quality wants the test report attached. In Enobase all three review the same change order, comment on the line they care about, and approve on the record, so the change carries its own reasons and the approval is a field, not a thread in someone's mailbox.
The version is what manufacturing builds.
A version is not a file that leaves for another system. The manufacturing order reads it, the purchase order reads its parts, the quality check reads its test plan, and the procedure reads its steps, because they are all records in the same workspace.
Purchase
PurchaseThe new part on v3 needs a price and a supplier before the date. Purchasing asks, the quote lands on the part, and the first order for it is drafted.
Quality
QualityThe non-conformity that started the change closes on it, and the test plan for v3 is the one the next batch is checked against.
Knowledge
KnowledgeThe assembly procedure is a page linked to the version, revised with it, so the shop floor reads v3's steps on the day v3 is current.
The drawing as a document
The drawing as a documentThe drawing and the declaration of conformity are documents on the version, generated from its fields, signed, and sent with the batch.
Every order says which version it built.
A version is not a file that leaves for another system. The manufacturing order reads it, the purchase order reads its parts, the quality check reads its test plan, and the procedure reads its steps, because they are all records in the same workspace.
The PLM tool you would otherwise buy stops at the released revision.
It keeps the version, the bill of materials and the approved change clean. Then it pushes the revision to your ERP by connector, and the date, the price, the stock and the open orders are settled by hand on the other side.
Versions of the bill of materials, compared
- A spreadsheet
- A tab per version
- A PLM tool
- Yes
- A suite module
- Yes
- Enobase
- Yes, lines that differ marked, cost of each
A change order with approvals
- A spreadsheet
- By email
- A PLM tool
- Yes
- A suite module
- Yes
- Enobase
- Yes, reviewed by production, purchasing and quality on the record
Drawings and certificates on the version
- A spreadsheet
- In a folder
- A PLM tool
- Yes
- A suite module
- Yes
- Enobase
- Yes, as documents generated from the version
An effectivity date the orders read
- A spreadsheet
- No
- A PLM tool
- No
- A suite module
- Sometimes
- Enobase
- Yes, a field every open record reads
The supplier's price on the new part
- A spreadsheet
- Typed in
- A PLM tool
- No, in the ERP
- A suite module
- Yes, in their purchasing
- Enobase
- Yes, quoted on the part before the date
The stock of the old part after the date
- A spreadsheet
- Counted later
- A PLM tool
- No, in the ERP
- A suite module
- Yes, in their inventory
- Enobase
- Yes, shown as stock without a use
The manufacturing orders open on the old version
- A spreadsheet
- No
- A PLM tool
- No, in the ERP
- A suite module
- Yes, in their MRP
- Enobase
- Yes, each one says which version it builds
Time to live
- A spreadsheet
- A day
- A PLM tool
- Weeks, plus the connector
- A suite module
- Months
- Enobase
- One to two weeks
| What you need | A spreadsheet | A PLM tool | A suite module | Enobase |
|---|---|---|---|---|
| Versions of the bill of materials, compared | A tab per version | Yes | Yes | Yes, lines that differ marked, cost of each |
| A change order with approvals | By email | Yes | Yes | Yes, reviewed by production, purchasing and quality on the record |
| Drawings and certificates on the version | In a folder | Yes | Yes | Yes, as documents generated from the version |
| An effectivity date the orders read | No | No | Sometimes | Yes, a field every open record reads |
| The supplier's price on the new part | Typed in | No, in the ERP | Yes, in their purchasing | Yes, quoted on the part before the date |
| The stock of the old part after the date | Counted later | No, in the ERP | Yes, in their inventory | Yes, shown as stock without a use |
| The manufacturing orders open on the old version | No | No, in the ERP | Yes, in their MRP | Yes, each one says which version it builds |
| Time to live | A day | Weeks, plus the connector | Months | One to two weeks |
Questions about PLM
Yes. On its own it is the product record with its versions, its documents and its change orders, reviewed and approved. Turn Manufacturing on and the orders read the version; turn Purchase on and the new part gets its price and its order.