Issue Before This Commit:
============================

The system activate inappropriate rules in routes, including those
where the rule itself is active but it's destination location is inactive.

Steps to Reproduce:
============================

- Install the stock & MRP modules.
- Activate multi-step routes and the MTO route.
- Notice that 'WH: Stock → Pre-Production (MTO)' rule appears,
  even when the rule is active but its destination location is inactive.
- Go to the warehouse, enable the 3-step MRP then switch back to the 1-step MRP.
- Go to the MTO route and see that only active rules are now shown.

With This Commit:
============================

This commit resolves the issue where the unarchiving route unintentionally
restored all associated rules, regardless of their active status. Now, only
rules that are active and it's destination location is active are displayed in routes,
where inactive ones are filtered out based on the destination location's active status.

task - [4577280](https://www.odoo.com/odoo/project.task/4577280)

Forward-Port-Of: odoo/odoo#197754

Issue: In Barcode, performing certain operations and then reverting your changes can drastically affect the state of records: "picked" status or the visual demand of the move.

### Steps to reproduce:

- Create a storable product tracked by SN. Put 2 SN in stock SN1 and SN2
- Create a delivery order for 2 units and mark as to do.
> The two SN's should be reserved on your delivery.
- Go to the barcode app, scan SN1.
- Edit edit the SN1 line to set the qty back to 0.
- Leave the barcode app and come back to the record.
#### > The subline related to SN1 displays now a demand of 0. A new barcode line has been created with a demand of 1 for SN1. In short an extra record was created unecessarily.

### Cause of the issue:

In the barcode app the demand of each line is measured by the quantity present on its move lines. In our set up, the move is related to 2 moves lines with a quantity of 1 that are not picked. Scanning SN1 will update the qty_done of its line to 1. As such, the move line quantity will be set from 1 to 1 and the move line will be picked:
https://github.com/odoo/enterprise/blob/e8c831a540c12019c560cc19abf7abe8785d0e0e/stock_barcode/models/stock_move_line.py#L58-L61 In turns, the picked state of the move will be set to picked: https://github.com/odoo/odoo/blob/7bc38562f1988ba15525c04168e30c06a8f1d33c/addons/stock/models/stock_move.py#L208-L212 Now, editing the qty done of the move once more from 1 to 0 to reset the reservation will not revert the process for 2 reasons:
1. The quantity of the move line will be reset form its current value to 0, altering the demand of the barcode line to 0.
2. Even if the move line was unpicked in this process, the picked compute method of the move will never reset the picked state as the compute method can only set a True value.

We therefore end up with a picked move without any picked move line and for which one of the picked move line has a quantity of 0. Now, leaving the barcode app will launch the split_uncompleted_moves method in order to not lose the changes made to the record and since the move is picked for the wrong reason, the move will be splitted in 2 instead of escaping the split process.
https://github.com/odoo/enterprise/blob/e8c831a540c12019c560cc19abf7abe8785d0e0e/stock_barcode/models/stock_move.py#L21-L22

Enterprise: https://github.com/odoo/enterprise/pull/80675

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

Forward-Port-Of: odoo/odoo#200167

Issue
=====
When product's code is computed, which is depend of the product's suppliers since each supplier can have a specific code, the first supplier is taken regardless if this supplier info is specific to another product variant which can cause to use the wrong code if there is multiple supplier with the same vendor but for different variants of the same product template.

How to reproduce
================
1. Install Puchase and Barcode;
2. Create a product with at least 2 variants;
3. In the "Purchase" tab of this product, add two vendor pricelists with the same vendor but each for a different product variant and each with a different code;
4. Go in Purchase, create a new RFQ for this vendor, add a PO line for each variant and confirm the order;
5. Go in Barcode and open the PO's receipt -> You can see both lines have the same vendor's code (from the first pricelist) regardless the pricelist's product variant.

Cause of the issue
==================
In `_compute_product_code`, it uses the first product (template) supplier info regardless the product variant.

Solution
========
In `_compute_product_code`, we skip a supplier info if it concerns another variant, and we break the supplier info loop only if it concerns the current product variant.

Miscellaneous
=============
The check of the `product.supplierinfo` `read` access right is moved outside of the loop so it is done only one time.

[OPW-4589073](https://www.odoo.com/odoo/project/49/tasks/4589073)

Forward-Port-Of: odoo/odoo#201753

Issue: In Barcode, performing certain operations and then reverting your changes can drastically affect the state of records: "picked" status or the visual demand of the move.

### Steps to reproduce:

- Create a storable product tracked by SN. Put 2 SN in stock SN1 and SN2
- Create a delivery order for 2 units and mark as to do.
> The two SN's should be reserved on your delivery.
- Go to the barcode app, scan SN1.
- Edit edit the SN1 line to set the qty back to 0.
- Leave the barcode app and come back to the record.
#### > The subline related to SN1 displays now a demand of 0. A new barcode line has been created with a demand of 1 for SN1. In short an extra record was created unecessarily.

### Cause of the issue:

In the barcode app the demand of each line is measured by the quantity present on its move lines. In our set up, the move is related to 2 moves lines with a quantity of 1 that are not picked. Scanning SN1 will update the qty_done of its line to 1. As such, the move line quantity will be set from 1 to 1 and the move line will be picked:
https://github.com/odoo/enterprise/blob/e8c831a540c12019c560cc19abf7abe8785d0e0e/stock_barcode/models/stock_move_line.py#L58-L61 In turns, the picked state of the move will be set to picked: https://github.com/odoo/odoo/blob/7bc38562f1988ba15525c04168e30c06a8f1d33c/addons/stock/models/stock_move.py#L208-L212 Now, editing the qty done of the move once more from 1 to 0 to reset the reservation will not revert the process for 2 reasons: 
1. The quantity of the move line will be reset form its current value to 0, altering the demand of the barcode line to 0.
2. Even if the move line was unpicked in this process, the picked compute method of the move will never reset the picked state as the compute method can only set a True value.

We therefore end up with a picked move without any picked move line and for which one of the picked move line has a quantity of 0. Now, leaving the barcode app will launch the split_uncompleted_moves method in order to not lose the changes made to the record and since the move is picked for the wrong reason, the move will be splitted in 2 instead of escaping the split process.
https://github.com/odoo/enterprise/blob/e8c831a540c12019c560cc19abf7abe8785d0e0e/stock_barcode/models/stock_move.py#L21-L22

Community: https://github.com/odoo/odoo/pull/200167

opw-4600565

Forward-Port-Of: odoo/enterprise#80675

### Steps to reproduce:

- Inventory > Configuration > Operations Types;
- Create a new operation type of "Manufacturing" type and set a barcode;
- Go to the Barcode app and on the main menu, scan the newly created manufacturing operation type's barcode;
- On the newly created manufacturing order, add a new product and save;
- Go back on the Barcode main menu, click on "Operations" button and see a button for both the already existing manufacturing operation type and on for the created one;
- You can see the created MO doesn't belong to the new operation type but was created in the already existing "Manufacturing" operation type.

### Cause of the issue:

In the Barcode app, when a manufacturing operation barcode is scanned, we create a new MO and open it directly, but the scanned operation type wasn't used as the default operation type (none was given.)

### Note:

The fix require to add the `picking_type_id` as an invisible in the view so that, the fields apppears in the spec of the onchange and the default values extrated from the context in order to generate the vals of the creation of the new record:
https://github.com/odoo/odoo/blob/8b0dddf8b4fb68fc12f15a71e150cf1607d5cd24/addons/web/models/models.py#L937-L944 In particular, to be active, the fiw require to update the view.

backport of f6ee6e1b2ea15b0ddc5a710d2f5a3c68512514bd

opw-4553213

Forward-Port-Of: odoo/enterprise#80222

Description of the issue this commit addresses:

A traceback is raised when importing some .cod files for bank transactions because the server tries to create a date element with a string that doesn't match the expected format.

---

Steps to reproduce:

1. Install l10n_be_coda
2. Go to the accounting dashboard and import the file `02-minimal-test.cod` from the linked ticket.
3. A traceback is raised

---

Desired behavior after this commit is merged:

The file import doesn't raise a traceback.

---

Note on the fix:

The issue happened because in `_get_coda_file_statement()`, the date is expected to be on the index range 115-120 but the the decoding of the file in `_parse_bank_statement_file()` transformed a "€" in "Ôé¼" which moved the date to indexes 117-122. This wrong translation of encoding happened because cp850 was used - which doesn't support currency symbols - instead of utf_8 because the latter was stopped by a non matching regex that was missing the currency symbols.

This commits includes currency symbols in the validating regex so that the most appropriate encoding is validated as often as possible.

---

opw-4546281

Forward-Port-Of: odoo/enterprise#81329

Backport of [this commit].

Babel has a very long standing bug on computing ISO weeks / year-week.

python-babel/babel#621 fixed some cases but broke others. Debian decided to revert it[^1] rather than actually fix things up and Ubuntu shipped that patch in Noble, which is awesome (not): test cases embedding either behavior flip around depending whether they run or noble or not.

python-babel/babel#887 was opened to fix the issue but left to rot then closed when I mistakenly-ish deleted my personal fork of babel.

While technically we could monkeypatch babel and replace functions wholesale (both versions so it works everywhere), just give up and instead compute the weeknumber ourselves in the context of `read_group([X:week])`:

- For ISO locales, delegate to the stdlib which does that fine.
- For non-ISO locales, assume that the week containing the first day of the year is the first week, and make the executive decision that all days in that calendar week are part of W01. The alternative would be to implement a split / overlapping week system where the same week is both W53 $YEAR and W01 $YEAR+1, and I really have no desire to deal with that from a UI/UX perspective.

Fix tests embedding incorrect week assignments:

- For `test_group_by_week`, redo the entire set (somewhat more declaratively / data driven, though not quite table-driven) to ensure the assignments are correct, and assert that the locales have the properties we assume with respect to 1dow.
- For `test_read_progress_bar`, the entire thing was a fever dream of wonky pseudo-split week where 2019 had no week 1.

[this commit]: https://github.com/odoo/odoo/commit/75c63315169c0a4c6c92403690c54d606680593b

[^1]: https://sources.debian.org/patches/python-babel/2.10.3-1/

opw-4446254
opw-4448239

Forward-Port-Of: odoo/odoo#202475
Forward-Port-Of: odoo/odoo#199658