Stock & MRP Performance for Large Databases

Stock & MRP Performance for Large Databases. Make stock reservation and MRP navigation fast again on aged, high-volume databases - no version upgrade and no data migration required. Make Mark as Done, Check Availability and opening a Manufacturing Order fast again on databases with a large stock-move history — without upgrading Odoo and without migrating your data. This module rewrites the hottest move-graph traversals as bounded SQL that returns the identical result the standard code returns, and ships a read-only diagnostic that shows you exactly how bad the problem is before and after.

In the next few minutes: stock & mrp performance for large databases, then the problem, then what this module does, then why the numbers stay identical, then the move graph health diagnostic. Then what this app deliberately does not do, so you can tell before you buy whether it fits. Everything lives under Move Graph Health. #.

Copy bambooforge_stock_move_perf into your addons path. #. Update the apps list and install BambooForge Stock Performance. #.

No configuration and no data migration are required. The overrides are active immediately. Stock & MRP Performance for Large Databases. Make Mark as Done, Check Availability and opening a Manufacturing Order fast again on databases with a large stock-move history — without upgrading Odoo and without migrating your data.

This module rewrites the hottest move-graph traversals as bounded SQL that returns the identical result the standard code returns, and ships a read-only diagnostic that shows you exactly how bad the problem is before and after. This page is the complete manual. Follow it top to bottom and you can install, verify the speed-up and understand precisely what changed without contacting support. The problem.

Odoo links stock moves to each other through the stock_move_move_rel many-to-many table (move_orig_ids ↔ move_dest_ids). On a young database this table is small. On a database that has run for years — especially with serial/lot tracking, repeated backorders and multi-level manufacturing — it grows a combinatorial, bipartite structure: shared components link to many serial-tracked orders, each backorder keeps chains open, and procurement groups fan out. Link counts in the hundreds of millions and per-move fan-out in the thousands are real.

Mark as Done on a manufacturing/MTO move calls _action_assign, which calls _get_available_move_lines_in / _out — a single such call has been measured at ~15 seconds on a real 210-million-link database. Opening a Manufacturing Order computes the source/child smart-button counts, which walk the whole procurement group — this can time out or never render the form. Under load these long calls pin worker processes and produce 504 Gateway Timeout. The standard code walks this graph through the ORM.

Every hop (move_orig_ids.move_dest_ids.move_orig_ids) materialises hundreds of thousands of records and re-reads the company-rule-wrapped M2M. The result: What this module does. It overrides five methods on stock.move and mrp.production so the graph traversal happens once, in the database, instead of node-by-node in Python: stock.move._get_available_move_lines_in / _out The MTO availability traversal walked on every _action_assign. The 2-hop and 3-hop move-id sets are produced by one bounded SQL statement each (DISTINCT collapses the explosion), then re-resolved through search().

Why the numbers stay identical. This is a performance change, not a behaviour change. Three properties keep the results bit-identical to standard Odoo: 1. Same records.

The SQL helpers only produce a set of move ids; those ids are re-resolved with search([('id', 'in', ids)]), which re-applies the stock.move record rules — including the multi-company rule. Nothing bypasses access control. 2. Same order.

search() returns rows in the model order (sequence, id), which is exactly the order the standard ORM chain yields, so the order-dependent itertools.groupby in the availability functions produces the identical grouping. No sorted() is introduced. 3. Same grouping.

The grouping and quantity-summation bodies are copied verbatim from standard Odoo — only the traversal that feeds them is replaced. The Move Graph Health diagnostic. Go to Inventory ▸ Reporting ▸ Move Graph Health. The report runs read-only SQL and shows: Size — the stock_move_move_rel table size and row count, and the number of stock moves.

Density — average links per move and the worst single-move fan-out. Prune opportunity — how many links only connect moves that are already in a done or cancel state (i.e. trace closed history), as a share of all links. This is an estimate only; the diagnostic never modifies data.

Worst offenders — the twenty highest fan-out moves, with their business reference, product and state, so you can see the real orders behind the numbers. Use it to quantify the problem before installing elsewhere, and to show stakeholders the density of the graph. It is safe to run on production: every query is read-only and uses planner statistics for the big numbers so it does not full-scan a huge table. Frequently asked questions.

Will my reservations or quantities change? No. See Why the numbers stay identical above — the change is limited to how the move sets are gathered; the reservation and quantity logic is untouched. Does it work on multi-company databases?

Yes. Because the move ids are re-resolved through search(), the standard multi-company record rule is applied exactly as before. How we make sure it works. Before every release, 12 automated checks run against this app on Odoo 16, 17, 18, 19 and 20.

Among them: Rollup move origs does not skip done. Orig dest orig search order matches core. Rollup move dests includes self and descendants. Rollup move origs includes self and ancestors.

Available move lines in quantity. The complete list is in the source you receive. Questions people ask. Which Odoo versions does it run on?

Odoo 16.0, 17.0, 18.0, 19.0, 20.0, on the series you buy it for; each series is its own listing. Community or Enterprise? Both. It needs no Enterprise app.

Support. BambooForge Labs — support@bambooforge.dev The complete manual is at docs dot bambooforge dot dev, the demo database is linked from the store page, and support answers within twenty-four hours. Links are in the description.

Stock & MRP Performance for Large Databases. Make stock reservation and MRP navigation fast again on aged, high-volume databases - no version upgrade and no data migration required. Make Mark as Done, Check Availability and opening a Manufacturing Order fast again on databases with a large stock-move history — without upgrading Odoo and without migrating your data. This module rewrites the hottest move-graph traversals as bounded SQL that returns the identical result the standard code returns, and ships a read-only diagnostic that shows you exactly how bad the problem is before and after.

In the next few minutes: stock & mrp performance for large databases, then the problem, then what this module does, then why the numbers stay identical, then the move graph health diagnostic. Then what this app deliberately does not do, so you can tell before you buy whether it fits. Everything lives under Move Graph Health. #.

Copy bambooforge_stock_move_perf into your addons path. #. Update the apps list and install BambooForge Stock Performance. #.

No configuration and no data migration are required. The overrides are active immediately. Stock & MRP Performance for Large Databases. Make Mark as Done, Check Availability and opening a Manufacturing Order fast again on databases with a large stock-move history — without upgrading Odoo and without migrating your data.

This module rewrites the hottest move-graph traversals as bounded SQL that returns the identical result the standard code returns, and ships a read-only diagnostic that shows you exactly how bad the problem is before and after. This page is the complete manual. Follow it top to bottom and you can install, verify the speed-up and understand precisely what changed without contacting support. The problem.

Odoo links stock moves to each other through the stock_move_move_rel many-to-many table (move_orig_ids ↔ move_dest_ids). On a young database this table is small. On a database that has run for years — especially with serial/lot tracking, repeated backorders and multi-level manufacturing — it grows a combinatorial, bipartite structure: shared components link to many serial-tracked orders, each backorder keeps chains open, and procurement groups fan out. Link counts in the hundreds of millions and per-move fan-out in the thousands are real.

Mark as Done on a manufacturing/MTO move calls _action_assign, which calls _get_available_move_lines_in / _out — a single such call has been measured at ~15 seconds on a real 210-million-link database. Opening a Manufacturing Order computes the source/child smart-button counts, which walk the whole procurement group — this can time out or never render the form. Under load these long calls pin worker processes and produce 504 Gateway Timeout. The standard code walks this graph through the ORM.

Every hop (move_orig_ids.move_dest_ids.move_orig_ids) materialises hundreds of thousands of records and re-reads the company-rule-wrapped M2M. The result: What this module does. It overrides five methods on stock.move and mrp.production so the graph traversal happens once, in the database, instead of node-by-node in Python: stock.move._get_available_move_lines_in / _out The MTO availability traversal walked on every _action_assign. The 2-hop and 3-hop move-id sets are produced by one bounded SQL statement each (DISTINCT collapses the explosion), then re-resolved through search().

Why the numbers stay identical. This is a performance change, not a behaviour change. Three properties keep the results bit-identical to standard Odoo: 1. Same records.

The SQL helpers only produce a set of move ids; those ids are re-resolved with search([('id', 'in', ids)]), which re-applies the stock.move record rules — including the multi-company rule. Nothing bypasses access control. 2. Same order.

search() returns rows in the model order (sequence, id), which is exactly the order the standard ORM chain yields, so the order-dependent itertools.groupby in the availability functions produces the identical grouping. No sorted() is introduced. 3. Same grouping.

The grouping and quantity-summation bodies are copied verbatim from standard Odoo — only the traversal that feeds them is replaced. The Move Graph Health diagnostic. Go to Inventory ▸ Reporting ▸ Move Graph Health. The report runs read-only SQL and shows: Size — the stock_move_move_rel table size and row count, and the number of stock moves.

Density — average links per move and the worst single-move fan-out. Prune opportunity — how many links only connect moves that are already in a done or cancel state (i.e. trace closed history), as a share of all links. This is an estimate only; the diagnostic never modifies data.

Worst offenders — the twenty highest fan-out moves, with their business reference, product and state, so you can see the real orders behind the numbers. Use it to quantify the problem before installing elsewhere, and to show stakeholders the density of the graph. It is safe to run on production: every query is read-only and uses planner statistics for the big numbers so it does not full-scan a huge table. Frequently asked questions.

Will my reservations or quantities change? No. See Why the numbers stay identical above — the change is limited to how the move sets are gathered; the reservation and quantity logic is untouched. Does it work on multi-company databases?

Yes. Because the move ids are re-resolved through search(), the standard multi-company record rule is applied exactly as before. Support. BambooForge Labs — support@bambooforge.dev The complete manual is at docs dot bambooforge dot dev, the demo database is linked from the store page, and support answers within twenty-four hours.

Links are in the description.

Stock & MRP Performance for Large Databases. Make stock reservation and MRP navigation fast again on aged, high-volume databases - no version upgrade and no data migration required. Make Mark as Done, Check Availability and opening a Manufacturing Order fast again on databases with a large stock-move history — without upgrading Odoo and without migrating your data. This module rewrites the hottest move-graph traversals as bounded SQL that returns the identical result the standard code returns, and ships a read-only diagnostic that shows you exactly how bad the problem is before and after.

In the next few minutes: stock & mrp performance for large databases, then the problem, then what this module does, then why the numbers stay identical, then the move graph health diagnostic. Then what this app deliberately does not do, so you can tell before you buy whether it fits. Everything lives under Move Graph Health. #.

Copy bambooforge_stock_move_perf into your addons path. #. Update the apps list and install BambooForge Stock & MRP Performance. #.

No configuration and no data migration are required. The overrides are active immediately. Stock & MRP Performance for Large Databases. Make Mark as Done, Check Availability and opening a Manufacturing Order fast again on databases with a large stock-move history — without upgrading Odoo and without migrating your data.

This module rewrites the hottest move-graph traversals as bounded SQL that returns the identical result the standard code returns, and ships a read-only diagnostic that shows you exactly how bad the problem is before and after. This page is the complete manual. Follow it top to bottom and you can install, verify the speed-up and understand precisely what changed without contacting support. The problem.

Odoo links stock moves to each other through the stock_move_move_rel many-to-many table (move_orig_ids ↔ move_dest_ids). On a young database this table is small. On a database that has run for years — especially with serial/lot tracking, repeated backorders and multi-level manufacturing — it grows a combinatorial, bipartite structure: shared components link to many serial-tracked orders, each backorder keeps chains open, and procurement groups fan out. Link counts in the hundreds of millions and per-move fan-out in the thousands are real.

Mark as Done on a manufacturing/MTO move calls _action_assign, which calls _get_available_move_lines_in / _out — a single such call has been measured at ~15 seconds on a real 210-million-link database. Opening a Manufacturing Order computes the source/child smart-button counts, which walk the whole procurement group — this can time out or never render the form. Under load these long calls pin worker processes and produce 504 Gateway Timeout. The standard code walks this graph through the ORM.

Every hop (move_orig_ids.move_dest_ids.move_orig_ids) materialises hundreds of thousands of records and re-reads the company-rule-wrapped M2M. The result: What this module does. It overrides the hottest traversal methods on stock.move, stock.quant and mrp.production so the graph traversal happens once, in the database, instead of node-by-node in Python: stock.move._get_available_move_lines_in / _out The MTO availability traversal walked on every _action_assign. The 2-hop and 3-hop move-id sets are produced by one bounded SQL statement each (DISTINCT collapses the explosion), then re-resolved through search().

Why the numbers stay identical. This is a performance change, not a behaviour change. Three properties keep the results bit-identical to standard Odoo: 1. Same records.

The SQL helpers only produce a set of move ids; those ids are re-resolved with search([('id', 'in', ids)]), which re-applies the stock.move record rules — including the multi-company rule. Nothing bypasses access control. 2. Same order.

search() returns rows in the model order (sequence, id), which is exactly the order the standard ORM chain yields, so the order-dependent itertools.groupby in the availability functions produces the identical grouping. No sorted() is introduced. 3. Same grouping.

The grouping and quantity-summation bodies are copied verbatim from standard Odoo — only the traversal that feeds them is replaced. The Move Graph Health diagnostic. Go to Inventory ▸ Reporting ▸ Move Graph Health. The report runs read-only SQL and shows: Size — the stock_move_move_rel table size and row count, and the number of stock moves.

Density — average links per move and the worst single-move fan-out. Prune opportunity — how many links only connect moves that are already in a done or cancel state (i.e. trace closed history), as a share of all links. This is an estimate only; the diagnostic never modifies data.

Worst offenders — the twenty highest fan-out moves, with their business reference, product and state, so you can see the real orders behind the numbers. Use it to quantify the problem before installing elsewhere, and to show stakeholders the density of the graph. It is safe to run on production: every query is read-only and uses planner statistics for the big numbers so it does not full-scan a huge table. Frequently asked questions.

Will my reservations or quantities change? No. See Why the numbers stay identical above — the change is limited to how the move sets are gathered; the reservation and quantity logic is untouched. Does it work on multi-company databases?

Yes. Because the move ids are re-resolved through search(), the standard multi-company record rule is applied exactly as before. Support. BambooForge Labs — support@bambooforge.dev The complete manual is at docs dot bambooforge dot dev, the demo database is linked from the store page, and support answers within twenty-four hours.

Links are in the description.

Stock & MRP Performance for Large Databases. Make stock reservation and MRP navigation fast again on aged, high-volume databases - no version upgrade and no data migration required. Make Mark as Done, Check Availability and opening a Manufacturing Order fast again on databases with a large stock-move history — without upgrading Odoo and without migrating your data. This module rewrites the hottest move-graph traversals as bounded SQL that returns the identical result the standard code returns, and ships a read-only diagnostic that shows you exactly how bad the problem is before and after.

In the next few minutes: stock & mrp performance for large databases, then the problem, then what this module does, then why the numbers stay identical, then the move graph health diagnostic. Then what this app deliberately does not do, so you can tell before you buy whether it fits. Everything lives under Move Graph Health. #.

Copy bambooforge_stock_move_perf into your addons path. #. Update the apps list and install BambooForge Stock & MRP Performance. #.

No configuration and no data migration are required. The overrides are active immediately. Stock & MRP Performance for Large Databases. Make Mark as Done, Check Availability and opening a Manufacturing Order fast again on databases with a large stock-move history — without upgrading Odoo and without migrating your data.

This module rewrites the hottest move-graph traversals as bounded SQL that returns the identical result the standard code returns, and ships a read-only diagnostic that shows you exactly how bad the problem is before and after. This page is the complete manual. Follow it top to bottom and you can install, verify the speed-up and understand precisely what changed without contacting support. The problem.

Odoo links stock moves to each other through the stock_move_move_rel many-to-many table (move_orig_ids ↔ move_dest_ids). On a young database this table is small. On a database that has run for years — especially with serial/lot tracking, repeated backorders and multi-level manufacturing — it grows a combinatorial, bipartite structure: shared components link to many serial-tracked orders, each backorder keeps chains open, and procurement groups fan out. Link counts in the hundreds of millions and per-move fan-out in the thousands are real.

Mark as Done on a manufacturing/MTO move calls _action_assign, which calls _get_available_move_lines_in / _out — a single such call has been measured at ~15 seconds on a real 210-million-link database. Opening a Manufacturing Order computes the source/child smart-button counts, which walk the whole procurement group — this can time out or never render the form. Under load these long calls pin worker processes and produce 504 Gateway Timeout. The standard code walks this graph through the ORM.

Every hop (move_orig_ids.move_dest_ids.move_orig_ids) materialises hundreds of thousands of records and re-reads the company-rule-wrapped M2M. The result: What this module does. It overrides the hottest traversal methods on stock.move, stock.quant and mrp.production so the graph traversal happens once, in the database, instead of node-by-node in Python: stock.move._get_available_move_lines_in / _out The MTO availability traversal walked on every _action_assign. The 2-hop and 3-hop move-id sets are produced by one bounded SQL statement each (DISTINCT collapses the explosion), then re-resolved through search().

Why the numbers stay identical. This is a performance change, not a behaviour change. Three properties keep the results bit-identical to standard Odoo: 1. Same records.

The SQL helpers only produce a set of move ids; those ids are re-resolved with search([('id', 'in', ids)]), which re-applies the stock.move record rules — including the multi-company rule. Nothing bypasses access control. 2. Same order.

search() returns rows in the model order (sequence, id), which is exactly the order the standard ORM chain yields, so the order-dependent itertools.groupby in the availability functions produces the identical grouping. No sorted() is introduced. 3. Same grouping.

The grouping and quantity-summation bodies are copied verbatim from standard Odoo — only the traversal that feeds them is replaced. The Move Graph Health diagnostic. Go to Inventory ▸ Reporting ▸ Move Graph Health. The report runs read-only SQL and shows: Size — the stock_move_move_rel table size and row count, and the number of stock moves.

Density — average links per move and the worst single-move fan-out. Prune opportunity — how many links only connect moves that are already in a done or cancel state (i.e. trace closed history), as a share of all links. This is an estimate only; the diagnostic never modifies data.

Worst offenders — the twenty highest fan-out moves, with their business reference, product and state, so you can see the real orders behind the numbers. Use it to quantify the problem before installing elsewhere, and to show stakeholders the density of the graph. It is safe to run on production: every query is read-only and uses planner statistics for the big numbers so it does not full-scan a huge table. Frequently asked questions.

Will my reservations or quantities change? No. See Why the numbers stay identical above — the change is limited to how the move sets are gathered; the reservation and quantity logic is untouched. Does it work on multi-company databases?

Yes. Because the move ids are re-resolved through search(), the standard multi-company record rule is applied exactly as before. Support. BambooForge Labs — support@bambooforge.dev The complete manual is at docs dot bambooforge dot dev, the demo database is linked from the store page, and support answers within twenty-four hours.

Links are in the description.

Stock & MRP Performance for Large Databases. Make stock reservation and MRP navigation fast again on aged, high-volume databases - no version upgrade and no data migration required. Make Mark as Done, Check Availability and opening a Manufacturing Order fast again on databases with a large stock-move history — without upgrading Odoo and without migrating your data. This module rewrites the hottest move-graph traversals as bounded SQL that returns the identical result the standard code returns, and ships a read-only diagnostic that shows you exactly how bad the problem is before and after.

In the next few minutes: stock & mrp performance for large databases, then the problem, then what this module does, then why the numbers stay identical, then the move graph health diagnostic. Then what this app deliberately does not do, so you can tell before you buy whether it fits. Everything lives under Move Graph Health. #.

Copy bambooforge_stock_move_perf into your addons path. #. Update the apps list and install BambooForge Stock & MRP Performance. #.

No configuration and no data migration are required. The overrides are active immediately. Stock & MRP Performance for Large Databases. Make Mark as Done, Check Availability and opening a Manufacturing Order fast again on databases with a large stock-move history — without upgrading Odoo and without migrating your data.

This module rewrites the hottest move-graph traversals as bounded SQL that returns the identical result the standard code returns, and ships a read-only diagnostic that shows you exactly how bad the problem is before and after. This page is the complete manual. Follow it top to bottom and you can install, verify the speed-up and understand precisely what changed without contacting support. The problem.

Odoo links stock moves to each other through the stock_move_move_rel many-to-many table (move_orig_ids ↔ move_dest_ids). On a young database this table is small. On a database that has run for years — especially with serial/lot tracking, repeated backorders and multi-level manufacturing — it grows a combinatorial, bipartite structure: shared components link to many serial-tracked orders, each backorder keeps chains open, and procurement groups fan out. Link counts in the hundreds of millions and per-move fan-out in the thousands are real.

Mark as Done on a manufacturing/MTO move calls _action_assign, which calls _get_available_move_lines_in / _out — a single such call has been measured at ~15 seconds on a real 210-million-link database. Opening a Manufacturing Order computes the source/child smart-button counts, which walk the whole procurement group — this can time out or never render the form. Under load these long calls pin worker processes and produce 504 Gateway Timeout. The standard code walks this graph through the ORM.

Every hop (move_orig_ids.move_dest_ids.move_orig_ids) materialises hundreds of thousands of records and re-reads the company-rule-wrapped M2M. The result: What this module does. It overrides the hottest traversal methods on stock.move, stock.quant and mrp.production so the graph traversal happens once, in the database, instead of node-by-node in Python: stock.move._get_available_move_lines_in / _out The MTO availability traversal walked on every _action_assign. The 2-hop and 3-hop move-id sets are produced by one bounded SQL statement each (DISTINCT collapses the explosion), then re-resolved through search().

Why the numbers stay identical. This is a performance change, not a behaviour change. Three properties keep the results bit-identical to standard Odoo: 1. Same records.

The SQL helpers only produce a set of move ids; those ids are re-resolved with search([('id', 'in', ids)]), which re-applies the stock.move record rules — including the multi-company rule. Nothing bypasses access control. 2. Same order.

search() returns rows in the model order (sequence, id), which is exactly the order the standard ORM chain yields, so the order-dependent itertools.groupby in the availability functions produces the identical grouping. No sorted() is introduced. 3. Same grouping.

The grouping and quantity-summation bodies are copied verbatim from standard Odoo — only the traversal that feeds them is replaced. The Move Graph Health diagnostic. Go to Inventory ▸ Reporting ▸ Move Graph Health. The report runs read-only SQL and shows: Size — the stock_move_move_rel table size and row count, and the number of stock moves.

Density — average links per move and the worst single-move fan-out. Prune opportunity — how many links only connect moves that are already in a done or cancel state (i.e. trace closed history), as a share of all links. This is an estimate only; the diagnostic never modifies data.

Worst offenders — the twenty highest fan-out moves, with their business reference, product and state, so you can see the real orders behind the numbers. Use it to quantify the problem before installing elsewhere, and to show stakeholders the density of the graph. It is safe to run on production: every query is read-only and uses planner statistics for the big numbers so it does not full-scan a huge table. Frequently asked questions.

Will my reservations or quantities change? No. See Why the numbers stay identical above — the change is limited to how the move sets are gathered; the reservation and quantity logic is untouched. Does it work on multi-company databases?

Yes. Because the move ids are re-resolved through search(), the standard multi-company record rule is applied exactly as before. Support. BambooForge Labs — support@bambooforge.dev The complete manual is at docs dot bambooforge dot dev, the demo database is linked from the store page, and support answers within twenty-four hours.

Links are in the description.