Friday, August 21, 2026
2 changes · 17.0
Resolved issues and error corrections
Self-billing invoices received through Peppol can again be imported into a dedicated self-billing sales journal. The fix also avoids an error screen for databases where the optional self-billing component is missing, making invoice processing more reliable.
Original PR description
This PR https://github.com/odoo/odoo/pull/277239 has been merged before being rebased on https://github.com/odoo/odoo/pull/259935/changes/568e3e1d4f100e22bd5e724a6afa6d0437f56830 This commit restores the possibility of importing a self-billing invoice into a dedicated self-billing sale journal, and prevents a traceback from being shown in case the user's DB has no `account_peppol_selfbilling` module installed (which is auto-installed with `account_peppol` by default, but we got a feedback of a user having this issue). task-no feedback : https://www.odoo.com/odoo/project/49/tasks/6481452 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The manufacturing BoM overview now calculates available production quantities correctly when the same component is listed more than once. This prevents the report from understating how many products are ready to produce, helping planners rely on more accurate stock-based production information.
Original PR description
## Problem When the same component appears on multiple lines of a BoM, the BoM Overview report merges those lines via `_merge_components()`. The merge corrupts `base_bom_line_qty`: ```python def…
## Problem
When the same component appears on multiple lines of a BoM, the BoM Overview report merges those lines via `_merge_components()`. The merge corrupts `base_bom_line_qty`:
```python
def _merge_components(self, component_1, component_2):
qty = component_2['quantity']
component_1["quantity"] = component_1["quantity"] + qty
component_1["base_bom_line_qty"] = component_1["quantity"] + qty # BUG
```
After line 756, `component_1["quantity"]` is already `q1 + q2`, so `base_bom_line_qty` becomes `q1 + 2*q2`. Two errors:
1. It reuses the scaled quantity field instead of the raw per-BoM `base_bom_line_qty`
2. It double-counts `component_2`
## Impact
`base_bom_line_qty` feeds `_compute_current_production_capacity()` → `producible_qty` → the "X Ready To Produce" status on the report. Whenever a component is repeated across BoM lines, the producible quantity is understated (e.g., shows "1 Ready To Produce" when 2 is correct).
## Fix
```diff
- component_1["base_bom_line_qty"] = component_1["quantity"] + qty
+ component_1["base_bom_line_qty"] = component_1["base_bom_line_qty"] + component_2["base_bom_line_qty"]
```
Sum the per-line base quantities instead of reusing the already-merged scaled field.
## Test
Added `test_bom_report_producible_qty_repeated_component` — BoM with the same component on 2 lines (2 + 2 = 4 per unit), 8 in stock → asserts `producible_qty == 2`. Without the fix this returns 1.
Note: the existing `test_bom_report_capacity_with_duplicate_components` doesn't catch this because it only stocks 2 units (less than the 4 needed), so the buggy floor calculation still returns 0 — matching the expected assertion.