Some other test adds a fiscal position with tax mapping. This creates 2 problems

1. The new taxes have a tag, which means we evaluate the right hand of

https://github.com/odoo/enterprise/blob/8d3fe30c627eada1186c15480876fb2e8f7ddb59/delivery_shiprocket/models/shiprocket_request.py#L239

However, since l10n_in is not installed,

`tax.env.ref(f"l10n_in.tax_tag_{gst}gst", False)`

does not return anything (False is not a fallback)

https://github.com/odoo/odoo/blob/1e96a3d127e8f521d3027f7110026ae84e11ed5e/odoo/api.py#L588

So we end up looking for `None` in `tax_tag_ids`, which leads us to compare the `_name` properties, see

https://github.com/odoo/odoo/blob/1e96a3d127e8f521d3027f7110026ae84e11ed5e/odoo/models.py#L6545-L6558

2. The test added in 4d5df93 was assuming the default company 15% tax, which was not always true

Solution
-----

1. Provide a fallback for the `ref` lookup
2. Force a 15% tax in the test

-----
runbot-232692

Forward-Port-Of: odoo/enterprise#97998

[REV] account_iso20022: Wrong XML generated for Switzerland

This reverts commit https://github.com/odoo/enterprise/commit/a0e981171808d4e475249431424955ab2223f5da.

This commit was introduced after this fix https://github.com/odoo/enterprise/commit/c160b2ead711797ca7362649971038cc245c5611. Though that original fix was correct, it had some unwanted side-effects: due to the payment method being forced on some payments in order to use SEPA, the sepa_pain_version field was used to generate the corresponding XML nodes, most of the time keeping its default value of pain.001.001.09. For Swiss banks supporting pain.001.001.09 (which becomes mandatory in November 2026), it was not a problem, and everything worked fine. This was the case of the customer for whom the fix was made (ticket 4535542). For the ones still not supporting it, and expecting pain.001.001.03, the bank refused the file, since the it contained unsupported nodes, like BICFI, or a subnode to ReqdExctnDt.

The commit we revert here tried to patch the symptoms without really understanding the cause of the issue, by not forcing the payment method everywhere. It breaks again the case of the original ticket (because ScvLvl is not passed to "SEPA" on EUR payments), and essentially makes no sense. We revert it in favor of a better fix.

ticket-4535542

=======================

[FIX] account_iso20022: Swiss variant: introduce config parameter to force SEPA nodes in the file

https://github.com/odoo/enterprise/commit/c160b2ead711797ca7362649971038cc245c5611 made it so we now force SEPA payments into Swiss ISO20022 files when they're made in EUR to an IBAN account. Though all in all correct, this fix forgot to consider the fact that the SEPA nodes would be generated using the sepa_pain_version field, with defaults to pain.001.001.09 version of the ISO standard. As it is today, the Swiss file is still generated using pain.001.001.03 in Odoo (some task will change that soon, since the support for that old version will be dropped in November 2026). Having such pain.001.001.09 nodes in the file causes it to be rejected by a lot of Swiss banks, because they don't support that version yet, or simply because of the file mixing both versions of the standard.

Since no one had asked us to enforce SEPA nodes within the file before recently, we make the choice to keep the fix behavior only when a config parameter is explicitly set to enable it. In all other cases, the former behavior is restored. We also now display the PAIN version field in the journal's form view when this config parameter is set, to give more control on the format of the generated file.

ticket-4535542

**Steps to reproduce:**
- Add some folders
- Create a new company
- Assign some folders to the new company
- Archive the company
- Click on Documents app
- AccessError is raised when opening it

**Issue:**
The issue seems to be related to caching issue on the field `type` when fetching the documents with `search_panel_select_range` and going through `_compute_display_name`:
`folders = accessible_records.filtered(lambda d: d.type == 'folder')`

This error was quite inconsistent and might be related to the cache missing some prefetched data on a record it shouldn't have been able to read. There is a need to ensure only the folders available to the user are able to be fetched.

**Fix:**
Added the `type` field in the `search_panel_fields` but this might not be needed if the issue comes from elsewhere.

For now the issue was mitigated by explicitly checking for the user companies in the domain of the searchs, but it needs to be checked as this behavior might break other flows.

opw-4931278

```
  File "/home/odoo/src/odoo/19.0/addons/account/models/account_tax.py", line 611, in _validate_repartition_lines
    raise ValidationError(_("Invoice and credit note distribution should have a total factor (+) equals to 100."))
odoo.exceptions.ValidationError: Invoice and credit note distribution should have a total factor (+) equals to 100.
```
- During the database migration, a traceback occurs because the [total_pos_factor](https://github.com/odoo/odoo/blob/18.0/addons/account/models/account_tax.py#L558) is being calculated as 0. When this happens, the float_compare [function](https://github.com/odoo/odoo/blob/18.0/addons/account/models/account_tax.py#L559) returns -1, which incorrectly satisfies the validation condition and triggers a ValidationError.
- To resolve this, we need to add an additional condition to check whether total_pos_factor is 0, similar to the condition already implemented [here](https://github.com/odoo/odoo/blob/18.0/addons/account/models/account_tax.py#L562) in the code.

tbg-1970
opw-5228357

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

… correct remaining value when sbc dropship

**Problem:**
When selling and delivering a subcontracted and dropshipped fifo product, 
the incoming stock valuation layer has a remaining_qty and a remaining_value.
(This also happens with 'standard price' and 'avco' but it's mostly problematic for 
fifo products. This being said the fix solves all 3 cases)

Some context: 
When we confirm a SO and validate the delivery of a dropshipped (not sbc) product,
two svls are created, 
   - one with a negative quantity and value.
   - one with positive quantity and value.
 
Both have a zero remaining value and remaining quantity.
The outgoing svl does not trigger run_fifo or decrease the remaining_qty 
and remaining_value on any svl.
In other words the fifo logic is not applied.
If it was the case, the dropship delivery would impact the fifo valuation and 
other layers which we don't want as the product never really entered the stock.
 
In the use case of this PR, a subcontracted dropshipped fifo product being delivered, 
the outgoing svl(s) are linked to the dropship and have the correct values. 
But the incoming svl is linked to the subcontract order and has a remaining value
and remaining quantity which will impact the fifo logic when it shouldn't.

**Steps to reproduce:**
- enable the subcontracting setting and the dropshipping setting.
- create a storable product, with a fifo category and positive cost.
- create a subonctracted bom with a consumable component.
- in the purchase tab of the product set a vendor which is the same
as the subcontractor of the bom.
- in the inventory tab select only the dropship route
- create and confirm a SO for this product.
- on the PO enter a positive unit price and confirm
- validate the dropship delivery
- click on the valuation smart button

**Current behavior:**
the stock valuation layer linked to the subcontract picking (the one with a 
positive quantity) has a positive remaining quantity and remaining value.

**Expected behavior:**
As the product is dropship remaining quantity and remaining value should be 0

**Cause of the issue:**
When action_done is called on the picking:
1) In the super method,
action_done is called on the move.
There, _create_dropshipped_svl is called.
https://github.com/odoo/odoo/blob/3c83171923124c7ea63a4d33262a87cddf004b2b/addons/stock_account/models/stock_move.py#L289
Inside _get_dropshipped_svl_vals only the value for the (first) outgoing svl
is returned because the location_id (subcontrating location) is valued.
https://github.com/odoo/odoo/blob/3c83171923124c7ea63a4d33262a87cddf004b2b/addons/stock_account/models/stock_move.py#L226

2) In the mrp_subcontracting override, button_mark_done is called on 
the mrp.production associated with the picking.
https://github.com/odoo/odoo/blob/3c83171923124c7ea63a4d33262a87cddf004b2b/addons/mrp_subcontracting/models/stock_picking.py#L90
Therefore action_done is called on the finished products move the mrp.production.
https://github.com/odoo/odoo/blob/3c83171923124c7ea63a4d33262a87cddf004b2b/addons/mrp/models/mrp_production.py#L1731
The move is a 'in' move so this lead to the creation of an in svl.
https://github.com/odoo/odoo/blob/3c83171923124c7ea63a4d33262a87cddf004b2b/addons/stock_account/models/stock_move.py#L289
The problem is that there is no mechanism to prevent the in svl from having 
a remaining_value and remaining_qty

**fix**
The mrp_subcontracting_dropshipping override of _action_done (on stock picking)
is where, when needed, the other ougoing layer is created specifically in this 
subcontracting dropshipping use case.
https://github.com/odoo/odoo/blob/3c83171923124c7ea63a4d33262a87cddf004b2b/addons/mrp_subcontracting_dropshipping/models/stock_picking.py#L27-L32
Because the conditions are the same, imo, it's a good place to set the value of 
remaingin_value and remaining_qty of the incoming svl to 0.

opw-5184644

Forward-Port-Of: odoo/odoo#233041

Issue:
-------------------------------------
Lots/serial numbers were always displayed in the barcode module during Manufacturing Order operations, regardless of whether the Show Reserved Lots/SNs option was enabled in the Manufacturing settings.

Steps to Produce:
-------------------------------------
- In Manufacturing settings, disable the Show Reserved Lots/SNs option.
- Create a Manufacturing Order and reserve component lots.
- Go to the barcode app
- Lots/SNs appear even though the Show Reserved Lots/SNs option is disabled.

After this Commit:
-------------------------------------
A correct value is now passed to the condition controlling the lot and serial number visibility.
Lots/SNs are shown only when Show Reserved Lots/SNs is enabled in Manufacturing settings, or when they have been picked or scanned, helping users focus only on relevant information and reducing the chance of picking or scanning mistakes.

Task Id: [3908929](https://www.odoo.com/odoo/project/966/tasks/3908929)

Steps to reproduce the bug:
- Create a storable product "P1" and "P2" with vendor "azure interior"
- for P2 subcontracting BoM referencing "azure interior" as subcontractor and component "C1"
- Create a receipt for partner "azure interior" including 1 unit of P1 and 1 unit of P2
- Validate the receipt
- Create a return for both P1 and P2

Problem:
A picking is created with destination location set to the subcontracting location for both products,
instead of setting the partner location only for subcontracted products.

Solution:
Ensure only the move line for subcontracted products uses the subcontracting destination location,
while other returned products go back to the supplier location.

When the `picking_id.partner_id`` is changed, it triggers a write on the
picking, which in turn triggers a write on its moves, but only on the
ones that are not scrapped.

However, since the `scrapped`` field is a stored computed field, and as
it hasn't been accessed before, it needs to be computed. And because
its computation depends on `location_dest_id`, that field also needs
to be recomputed. as a result, the `location_dest_id`` of the moves that
we manually set may be changed unexpectedly.

Therefore, in the `_create_return`` function, we check that the
picking’s `partner_id` is different from the moves’ partner_id before
updating it, to avoid unnecessary writes and the chain of recomputations
that could alter our values.

Resetting the picking’s partner_id based on the move’s partner_id could
actually be removed in master, as it serves no real purpose,
the move.partner_id itself is already derived from the picking’s
partner_id. We just keep it in stable versions to avoid any unexpected
behavior changes.

opw-5208289