Give production an approved drawing and the right bill of materials, while purchasing knows which revision it is buying for. When a component quantity or assembly method changes, someone must decide who reviews it, when it takes effect, and what happens to work already underway. The Odoo application can organize that decision as a controlled revision process rather than a collection of files with uncertain production status.
Odoo 19.0 documentation describes engineering change orders, bill-of-materials versions, and their stages 1. NASA’s Systems Engineering Handbook explains the broader principles of an approved baseline, change authority, and verification of implementation 2. We use those engineering principles to structure the decision; this does not imply NASA uses Odoo or that its handbook is a Saudi manufacturing requirement.
At ToDoOps, we connect engineering decisions with planning, inventory, and execution. Start with our Odoo application implementation services in Saudi Arabia, then use the workflow below to identify what your factory needs to configure and test.
When a bill of materials needs a change process
A bill of materials describes components, quantities, and operations. An engineering change order, or ECO, organizes the transition from one approved definition to another. Frequent revisions, approvals shared across engineering and quality, or a need to explain which revision was active are practical reasons to examine product lifecycle management, or PLM.
A simpler arrangement may suit a stable product with infrequent changes and clear responsibility. Do not add an application before identifying the decision your team cannot currently control. Odoo’s documentation describes PLM as separately installed from Manufacturing; availability, subscription, hosting, and the installed version belong in the project review.
Write a change request that explains the difference
Identify the product, current revision, proposed drawing, reason for change, and potentially affected orders or materials. Describe the difference itself: an increased component quantity, a substitute part, or a revised operation. “Updated drawing” tells purchasing little about what it should do next.
The baseline principle in NASA’s handbook is that an approved product definition provides the starting point for evaluating changes. Authority, evaluation, approval, and verification connect that starting point to a controlled new definition 2. For a factory, approval of an attachment is incomplete if planning still uses a different material list. Name the production definition that becomes effective and the person who checks it.
Separate technical approval from the practical release decision where your process requires it. A design can be acceptable while training, materials, or an existing production batch still make immediate release inappropriate. The workflow should make that decision visible rather than leave it in a separate conversation.
Move from a review copy to a production revision
In the documented Odoo 19.0 flow, starting a revision creates a review copy with a subsequent version number such as V2. That copy is archived while under review, distinct from the current production bill of materials. Components, operations, and associated documents can be reviewed before the proposed definition is applied.
With appropriate verification and approval stages configured, an authorized user applies the change. The flow archives the previous production bill and activates the revised one. Acceptance should examine the active revision number, quantities, operations, and attachments. Moving a card to another column is not, by itself, proof that the shop floor is using the intended definition.
The reference also describes comparison of changes and access to earlier revisions. Your own organization determines the responsibilities and approval sequence. The standard functions provide a mechanism; the requirements study establishes who may use it and which exceptions must be tested.
Worked example: from two components to two and a half
Assume a batch of ten finished products. V1 requires two units of a component per product; proposed V2 requires 2.5. For illustration only, assume a component unit value of SAR 40. Labour, waste, tax, and overhead are excluded.
| Item | V1 | V2 |
|---|---|---|
| Component quantity per product | 2 | 2.5 |
| Finished products in the batch | 10 | 10 |
| Total component requirement | 20 | 25 |
| Additional component quantity | — | 5 |
| Direct material effect under the assumption | — | SAR 200 |
The arithmetic is 10 × 2 = 20, 10 × 2.5 = 25, and 5 × 40 = SAR 200. This is an illustrative direct material effect, not a manufacturing cost report or a claimed automatic accounting result. The operational question is which requirement purchasing uses for the batch, and whether that revision has actually been approved for release.
Replacing a component introduces a different decision. Remaining stock of the previous component may be used for selected products, considered for supplier return, or handled through another approved disposition. A drawing update alone cannot choose that policy. The quantity-increase example above does not, by itself, create an obsolete component.
Use the implementation project calculators to consider the scope of data, approval workflows, integration, and training. They estimate implementation work; they do not approve engineering designs or calculate the material example for you.
Effective dates and existing orders need their own decision
The reference provides immediate application and a specific effective date. Its version-history guidance notes that an immediate application may leave the effective-date field empty and points to the activity history to investigate timing. Agree where your release decision and effective date will be recorded and how planning will verify them.
The ECO-stage documentation describes the effect of a closing stage configured to apply changes on pending and future manufacturing orders 1. Do not extend that statement indiscriminately to an order already in production with materials consumed. Test draft, confirmed, in-progress, and completed orders in the installed environment. Neither “all open orders remain unchanged” nor “all open orders always update” is a safe acceptance assumption.
Your transition plan may complete one batch under the previous definition and begin another under the new one. It may require selected orders to be reviewed before release. Production, quality, and planning should approve the cutover and examine reservations, purchased materials, and instructions given to operators.
Parallel changes require a conflict review
Two ECOs may start from V1. If the first is applied while the second remains under review, the second has an outdated starting point. Odoo’s reference describes Apply Rebase to incorporate the already applied change while retaining the proposed work.
That mechanism does not replace an engineering review of conflicting edits. If both requests change the same component or instruction, the responsible team must decide the intended outcome and check the resulting production definition. Give each request a reason, owner, and clear attachments, then examine the final bill rather than treating completion of an action as proof of a correct design.
Build acceptance around what the factory will use
Provide a current bill of materials, an approved and proposed drawing, a real change request, and sample orders at different stages. Include the approval roles, how operators receive instructions, and stock associated with the previous revision. This is a more useful starting point than a list of application names.
| Situation | Evidence required |
|---|---|
| Before application | Proposed edits do not alter the current production definition |
| Approval steps | The intended users can approve and apply; others cannot |
| After application | Correct version, components, operations, and attachments are active |
| Draft and confirmed orders | The bill and quantities used in each state are recorded |
| In-progress and completed orders | Prior consumption and historical records are examined |
| Future release date | Timing and order behaviour around the date are tested |
| Concurrent revisions | Accepted changes are retained and conflicts resolved |
Review these requirements with the relevant Odoo applications and industry workflows. The guided sales and inventory demonstration illustrates only its published flow; it is not a PLM acceptance test or a simulation of your production line.
Frequently asked questions
Does installing Manufacturing enable PLM automatically?
The reference used here describes PLM as separately installed. Review the business need, availability, and subscription implications before including it in the scope.
Can a drawing change without changing component quantities?
Yes, a request may concern documents, components, operations, or a combination. The request should identify what changed and how consistency with the approved product will be checked.
Will an in-progress manufacturing order change?
Test its state, consumed quantities, and closing-stage configuration. Document the approved treatment rather than relying on a general statement about open orders.
Can an earlier revision be restored?
The PLM reference describes management of and return to earlier versions. The decision and its effects on work and inventory still need approval and testing, like another release.
What should we bring to the requirements meeting?
Bring one actual change, its drawing and bill, affected order states, and today’s approval responsibilities. These reveal the controls and exceptions the implementation needs to cover.
Begin with your next production change
Select a product due for revision and identify its approved definition, proposed change, and release plan. Explore Odoo application implementation, use the project estimate calculators, then discuss control of your manufacturing changes. We can define standard configuration, integration or customization needs, and acceptance evidence before production release.
References
[1] Odoo — 19.0 documentation: Engineering change orders, ECO stages, and bill-of-materials version control. A reference for review, application, documents, and concurrent changes.
[2] NASA — Systems Engineering Handbook, section 6.5: Configuration identification, approved baselines, change authority, evaluation, approval, and implementation verification. General engineering guidance for structuring a controlled decision.