Engineering data management should connect a specification, its supporting files and the revision authorised for use. Start with a change record that identifies the affected item and the evidence being reviewed. Then test whether someone can reconstruct the previous and current states without relying on a filename or a colleague’s memory of when the change happened.
A drawing, an assembly instruction and a component structure may describe related parts of the same design. They still need identifiable versions and a clear relationship. Write the intended links before choosing the system: which document supports which specification, who reviews the change and what tells the user that the revised information is ready to use?
The original revision-trace exercise below uses a fictional equipment assembly. Product examples come from Odoo 19 PLM engineering-change and version-control documentation, retrieved on 24 October 2026. Broader document management and business systems discussions remain separate.
What should an engineering change identify?
Odoo engineering change orders can target a product or its bill of materials. Its engineering-change guide describes those targets. Use them as a narrow example when defining what the proposed change actually affects. A revised design file and a changed component requirement should have an explicit relationship in the brief.
Odoo ECOs have a Description field for the improvement summary. Odoo also provides a Responsible field for the ECO assignee. Agree the information the reviewer needs from those fields. A useful summary explains the purpose of the change, while ownership identifies who can answer a question about it.
Odoo supports an immediate or specified-date effective setting for changes. Write the intended effective point on the acceptance sheet. This helps the reviewer distinguish a proposal being prepared from the revision intended for use at a particular point in the process.
For the fictional assembly, propose a change to a mounting detail and its supporting PDF. Give the item, specification and file separate identifiers. Ask the engineering owner to confirm which relationships should change together and which supporting material should remain unchanged.
How can a proposed revision remain distinct?
For an ECO whose Apply on field is set to Bill of Materials, Odoo’s Start Revision creates a copy of the production BoM with a new version number. Odoo displays component differences in a BoM Changes tab. The Revision smart button is available only with Bill of Materials selected in Apply on and after Start Revision has been pressed. Revision prerequisites. These documented mechanisms supply concrete demonstration questions: can the reviewer identify the proposed state and compare it with the current one?
Keep the comparison connected to the actual requirement. For the sample mounting change, identify the altered component reference and the corresponding drawing detail. Ask the demonstrator to show each in the proposed system. A difference report is useful when the reviewer can explain why the difference belongs to the intended change.
Odoo keeps ECO modifications separate from the production BoM until changes are applied. Use a separate test environment to inspect the proposed review route and the distinction between states. Record the actual configuration and observed identifiers with the exercise, so another person can repeat the comparison.
| Revision question | Proposed evidence | Review action |
|---|---|---|
| What is changing? | Item and specification references | Confirm the change target |
| Why is it changing? | Concise improvement summary | Check that the reason is understandable |
| Which files support it? | Identified drawing or instruction versions | Inspect the relationship to the specification |
| Who owns the proposal? | Responsible role or assignee | Route clarification to the right person |
| When should it apply? | Intended effective point | Compare it with the configured revision state |
| What was used previously? | Previous revision and supporting material | Reconstruct the earlier state |
The table is an original traceability sheet. Its purpose is to make the required relationships assessable using representative records.
How should design files remain connected?
Odoo PLM permits CAD files, PDFs and images to be attached to a BoM. Odoo can manage added, modified and removed files within an ECO. The version-control guide describes these own-product behaviours. Decide which supporting files belong to the sample revision and inspect their actual attachment context.
Odoo links the new files to the production BoM after the ECO is approved and applied. Keep the file-selection decision with the change record. A reviewer should be able to identify the supporting material for the proposed state and then locate what the accepted state actually references.
Odoo retains archived design files through the ECO rather than permanently deleting them. Include an earlier supporting PDF in the exercise and ask the reviewer to retrieve it through the documented history. Assess whether the available evidence meets the team’s traceability requirement, including any context needed to interpret that earlier file.
The specification itself should explain which revision is relevant to the user’s task. Agree the presentation of that information with the engineering owner. This is a proposed requirement for the broader data-management design, rather than an assumption that every file type receives an identical built-in control.
Include an applicability note with each supporting file: what item or revision does it describe, and which earlier instruction does it replace? Have the reviewer answer using the retained record. This can reveal a document that is correctly stored but connected to the wrong specification.
Original specification-and-file revision exercise
Prepare a fictional assembly called Sample Mount with an initial component reference, a short assembly instruction and a supporting PDF. Give each an explicit identifier. Create a proposed amendment that changes the mounting detail and the related supporting material. Write the expected old and new relationships before entering the exercise in a test copy.
First, ask a reviewer to locate the current specification and identify its supporting files. Retain the observed references. Then create the proposed revision through the appropriate documented route and ask the same reviewer to explain the difference. Record whether the change target, reason, owner and intended effective point are clear.
Next, inspect the supporting files within the proposal. Compare their content and identifiers with the written exercise. Ask another colleague to retrieve the previous state using the history available to them. A successful retrieval should identify the relevant specification and supporting material together, not just a familiar document name.
Finally, demonstrate the agreed acceptance route in the separate test environment and inspect the resulting current references. Record what changed and what remained available in the historical record. Keep any unresolved relationship or approval requirement as a specific question with an owner.
Use the sheet to assess engineering information through a meaningful change, rather than through the number of file formats a system accepts. For a separate component-structure decision, see bill of materials software. To discuss the specification relationships and remaining traceability requirements, get started with the revision exercise.
By Spout Team. AI-assisted drafting by Codex using the linked primary documentation.