[ADD] sale_mrp_modular_type: add modular types to scale BOM quantities from sales order#1271
Draft
aykhu-odoo wants to merge 1 commit into
Draft
[ADD] sale_mrp_modular_type: add modular types to scale BOM quantities from sales order#1271aykhu-odoo wants to merge 1 commit into
aykhu-odoo wants to merge 1 commit into
Conversation
|
|
aykhu-odoo
changed the title
aykhu-odoo
force-pushed
the
19.0-modular-types-aykhu
branch
3 times, most recently
from
e8ee34a to
16e5b0e
Compare
…s from sales order
In some manufacturing cases, the quantity of components depends on
values decided at the time of sale (like number of sections, length,
area, etc.). Currently, BOMs are fixed, so handling this kind of
requirement means either duplicating BOMs or manually adjusting
quantities, which is not practical and leads to mistakes.
This change introduces *modular types* to handle this more cleanly.
Products can be configured with modular types (like sections, meters…),
and BOM lines can be linked to those types. Instead of being fixed,
those BOM quantities now act like base values.
When such a product is added to a sales order, the user can enter values
for each modular type. These values are then used when creating the
manufacturing order, where component quantities are computed as a function of:
- the base BOM quantity
- the modular type multiplier defined on the sales order
The goal is to avoid duplicating BOMs and remove the need for manual
adjustments, while still keeping the flexibility to handle different
configurations per order.
This keeps the flow simple for users and makes sure the manufacturing
data always matches what was defined during the sale.
A dedicated modular type model is introduced and linked to products
(m2m) to define available dimensions, while BOM lines reference a single
modular type (m2o). This separation allows reusable configuration on the
product side while keeping BOM logic simple and explicit.
The computation is applied at MO generation time.
The computation is applied at MO generation time.
aykhu-odoo
force-pushed
the
19.0-modular-types-aykhu
branch
from
16e5b0e to
977abad
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
In some manufacturing scenarios, the quantity of components depends on values defined at the time of sale (e.g., number of sections, length, area). However, BOMs in Odoo are static, which makes it difficult to handle such cases cleanly.
Today, users either duplicate BOMs for each variation or manually adjust quantities after order confirmation. Both approaches are error-prone and hard to maintain.
This PR introduces modular types to address this limitation in a structured way.
Key Changes
Result