When multiple phantom BOMs existed for a product or template, the system attempted to use all matches, leading to a singleton error on sales order update. This fix ensures only the BOM with the lowest sequence is selected, resolving the ambiguity.

Closes #202645

Description of the issue/feature this PR addresses:
Multiple phantom BOMs for a product or its template caused a singleton error during Sales Order updates. The system failed to correctly choose one BOM when more than one matched the criteria.

Current behavior before PR:
If a product had more than one phantom BOM (same type), confirming or updating a Sales Order line triggered a traceback error due to multiple BOMs being selected at once.

Desired behavior after PR is merged:
Only the BOM with the lowest sequence (highest priority) is selected, avoiding the singleton error and ensuring consistent behavior when handling Sales Orders with kit-type products.



---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

## Summary

- Add company-level `l10n_fr_pdp_late_payment_penalty_rate` (settings: French Electronic Invoicing).
- Export a dynamic **#PMD#** note on outbound UBL FR invoices and credit notes (legal default when rate is empty).
- Extend `l10n_fr_pdp` tests (messages + UBL golden files).

Fixes odoo/odoo#268149

## Multi-repo issues

| Repository | Issue | Branch |
|------------|-------|--------|
| odoo/odoo | #268149 | `dev_l10n_fr_pdp_pmd_penalty_rate` |

## Test plan

- [ ] `-u l10n_fr_pdp --test-enable --stop-after-init --test-tags=/l10n_fr_pdp:TestL10nFrPdpXml`

## Reviewers & code owners

- Requested review: @smetl @chklop
- Prior authors on touched `l10n_fr_pdp` code: @baje @videc @sveaw (recent commits on `account_move`, `res.company`, tests)

---

## Résumé

- Taux annuel `l10n_fr_pdp_late_payment_penalty_rate` sur la société (paramètres FE).
- Note **#PMD#** dynamique sur factures / avoirs UBL FR exportés.
- Tests `l10n_fr_pdp` mis à jour.

Fixes odoo/odoo#268149

## Tests

- [ ] `--test-tags=/l10n_fr_pdp:TestL10nFrPdpXml`

## Revue

- Review : @smetl @chklop
- Auteurs récents du code modifié : @baje @videc @sveaw

### Steps to reproduce:

- In the settings enable: Multi-Steps Routes
- Inventory > Configuration > Warehouse Management > Routes
- Unarchive MTO
- Create a storable product P with MTO buy and a set vendor
- Create and confirm a sale order for 1 unit of P
- Confirm the assocaited PO and change the pol quantity from 1 to 10
> the associated receipt is updated from 1 to 10
- Change the pol quantity from 10 to 7
#### > The quantity on the receipt is updated from 10 to 16.

### Cause of the issue:

Changing the quantity of the POL will adapt the picking related quantity via these lines:
https://github.com/odoo/odoo/blob/3bf89b4f467390807c20f7b007a875a77542e76f/addons/purchase_stock/models/purchase_order_line.py#L115-L117 https://github.com/odoo/odoo/blob/3bf89b4f467390807c20f7b007a875a77542e76f/addons/purchase_stock/models/purchase_order_line.py#L342-L349 by creating new stock moves to be merged:
https://github.com/odoo/odoo/blob/3bf89b4f467390807c20f7b007a875a77542e76f/addons/purchase_stock/models/purchase_order_line.py#L220-L251 Now, the issue is that this flows relies both on a negative `qty_to_attach` of `1 - 10 = -9` and a positive `qty_to_push` of `7 - 1 = 6`. However, the `qty_to_attach` is only used if is positive: https://github.com/odoo/odoo/blob/3bf89b4f467390807c20f7b007a875a77542e76f/addons/purchase_stock/models/purchase_order_line.py#L243-L251 The receipt is therefore updated by a `+6` move to push but not by the `-9` move to attach. Leading to a 10 -> 16 rather than 10 -> 7 result.

opw-6218307

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#264994

### Steps to Reproduce:
1. Have 2 companies (Company A and Company B)
2. Create a global product (visible in both companies)
3. in Company A, for the product BOM make it a normal type ("Manufacture this product") with a couple components, each with 0 units in this company.
4. Set the product to have quantity 50 units in Company A
5. In Company B, for the product BOM make it a phantom type ("Kit") with one component, 100 units so there are 100 units of the product in Company B too.
6. Now only select Company A and on the product page, set the cost to any nonzero amount.
7. Go to Inventory > Reporting > Stock, and see how the quants are all 0. however, if you click into the product page, the on hand quantity SmartButton says 50

### Description of the issue/feature this PR addresses: 
**Issue:** When stock valuation logic does a compute_value in superuser mode, the _bom_find method ignores multi-company record rules. This causes the search to find kits from other companies, leading to incorrect quantity computations.

**Solution:** Force the env to drop the superuser flag (su=False) specifically during the BoM search. This ensures the ORM applies standard ir.rule filters, and isolates BoM results to the current company context.

### Current behavior before PR:
In superuser mode, the BoM search is company-blind and returns the first matching kit found in the entire database. If a kit is found in a different company, the stock report incorrectly explodes the kits and looks for the components in the current company's warehouse.

### Desired behavior after PR is merged:
The BoM search should respect multi-company isolation so the system will only identify a product as a kit if a valid BoM exists within the user's active company or the global context.

opw-6170112

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Version:
----------
- 18.0+


Steps to reproduce:
-------------------
1. Install *quality_control* module.
2. Go to *Settings* and enable *Storage Locations*.
3. Open Quality module go to the Quality control -> Quality points 
4. Create a *Quality Point* with:
  * *Product* set.
  * *Control per* set to *Quantity*.
  * *Operation* set to *Receipts*.
  * *Failure Location* set to *WH/Stock/Shelf1*.
5. Create a *Receipt* with demand of *2 units* for the product used in QP.
6. Mark the quality check as *To Do*.
7. Update the *Done Quantity* to *1*.
8. Open the quality check and click *Fail*.
9. Update the *Done Quantity* back to *2* and save.
10. Open the quality check again, click *Pass*, and validate the receipt.
11. Open the *Detailed Operations* to inspect move lines.

Issue:
------
* Both units (failed and passed) are moved to the *failure location*.

Cause:
------
When a user fails a move line via the QC wizard, the flow is:
  do_fail() → show_failure_message() → confirm_fail()
    → check._move_to_failure_location(failure_location_id, failed_qty)

Inside `_move_to_failure_location`, when `failed_qty == move_line.quantity`,
the condition:
 https://github.com/odoo/enterprise/blob/a33f580455a54a81d89a848f7b493d9dcc9ba2b2/quality_control/models/quality.py#L458
e.g. 1 == 1

was True even when `move.product_uom_qty = 2` (demand still 2). It only
compared the done quantities, ignoring that unfulfilled demand remained.
As a result, `move.location_dest_id` was set to the failure location.

Later, when the user increases the quantity from 1 to 2 on the move form,
the flow is:
_set_quantity → process_increase → _set_quantity_done → _prepare_move_line_vals
In `_prepare_move_line_vals` :
    'location_dest_id': self.location_dest_id.id,

https://github.com/odoo/odoo/blob/47bf284e1e9d8be0d4255418e0a3f67c74fa5114/addons/stock/models/stock_move.py#L1688

The new move line inherits `move.location_dest_id` directly, which at this
point is already the failure location. 

When the user then calls `do_pass()` on the second unit, `do_pass()` only
writes `quality_state = 'pass'` and never touches `location_dest_id`. So
the second (passed) move line silently retains the failure location.

Solution:
---------
Add the guard `move.product_uom_qty <= move_line.quantity` to the condition
so the entire move's destination is only redirected when there is genuinely
no remaining unfulfilled demand:

When demand > done qty, the else-branch runs instead: it reduces the
original move's demand and creates a new separate move pointing to the
failure location, leaving the original move's `location_dest_id` pointing
to stock. Any subsequent move lines created on the original move therefore
correctly inherit the stock destination.

---

opw-6080871