### Issue:

Currently, leaving the barcode app will split moves/move lines in the backend in order to keep track of the changes made on the move lines to match the next time you go into the barcode app.

#### Use case 1 (split move):
- Create a storable product P tracked by lot
- Adjust the onHand quantity to put 2 quants in stock:
    - quant1: Location: WH/Stock, lot_id: LOT0001, quantity: 3.0
    - quant2: Location: WH/Stock, lot_id: LOT0002, quantity: 3.0
- Create and confirm a Delivery order for 3 x P
> The move of the delivery should have reserved 3 units form LOT0001
- Enter the barcode app, scan you DO-name
- Scan your product barcode then scan LOT002 three times
- Leave the barcode app and come back
#### > The barcode line 3/3 was updated to 3/6: 0/3 LOT001 and 3/3 LOT002.

#### Use case 2 (split move line):
- Create 2 storable products P and COMP.
- Adjust the onHand quantity to put 10 units of COMP in stock.
- Create a bill of material for P with one line: - 1 x COMP
- Create and confirm an MO for 10 units of P.
- Set the qty_producing to 5 units -> 5 units of comp are reserved
- Enter the barcode app, scan you MO-name
- The component line should be 5/5 since 5 units are reserved.
- Adjust the registration to 1/5.
- Leave the barcode app and come back
#### > The barcode line 1/5 was updated to 1/1 and 0/9 instead of 0/4.

### Cause of the Issue:

In both cases, the problem comes from the fact we leave the barcode with a different reservation than the initial one.

In the first use case, a new move will be created with a quantity of 3 in order to handle the new line created with LOT002 as soon as you have scanned your products. Therefore even though you entered the barcode app with a reservation demand of 3 units you leave it with 2 move lines with a cumulative quantity of 3 + 3 = 6:
- line1: quantity: 3, lot_id: LOT001, picked: False
- line2: quantity: 3, lot_id: LOT002, picked: True The next time you enter the app you will therefore see a reservation demand of 6 rather than 3.

In the second use case however, a move line is simply created by the `split_uncompleted_moves` when you exit the barcode app: https://github.com/odoo/enterprise/blob/0f4e8ce54be746db02e9f4a6974e387d90608a08/stock_barcode_mrp/models/stock_move.py#L18-L29 
And the quantity of the new move line is based on the `prodcut_uom_qty` of the move rather than the initial reservation demand (quantity when entering barcode). This explains why reservation demand changed from 5 to 10 when you left and came back.

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

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

Forward-Port-Of: odoo/odoo#200721
Forward-Port-Of: odoo/odoo#193465

Versions
--------
- 17.0+

Enterprise PR: https://github.com/odoo/enterprise/pull/81461

Steps
-----
1. Have a internal user with only Sales: Own Documents access;
2. assign the user to a subscription;
3. as admin, create an invoice for the subscription;
4. assign yoursel as salesman on the invoice;
5. confirm the invoice;
6. log in as the other user;
7. try to create an invoice for the subscription assigned to you.

Issue
-----
Access error.

Cause
-----
Unlike the the other `_compute_amount_*` methods of sale.order, `_compute_amount_invoiced` isn't computed with `sudo`.

This isn't an issue when just using `sale`, as it's computed with only sale order fields, but if an override attempts to check `invoice_ids`, it will throw an error if it has an invoice you don't have access to.

Solution
--------
In `sale`:
- The bring the compute method in line with other `_compute_amount_*` methods, add `compute_sudo=True` to the `amount_invoiced` field.

In `sale_subscription`:
- Add a test to prevent regression.

opw-4554639

Forward-Port-Of: odoo/odoo#202264
Forward-Port-Of: odoo/odoo#201768

In a grouped kanban view (e.g. project tasks), especially on a slow network, quickly move several records from a column to another, and click on a record to open it.

Before this commit, we switched to the opened record directly, without waiting for the ongoing rpcs (web_save, resequence), for each moved record. However, the `async` protection in the orm service prevent destroyed components from doing rpcs. As a consequence, a crash can occur if some moved records could not be saved before leaving the kanban view.

This commit ensures that we wait for all those operations to be done before leaving the kanban view. That way, all moved records are properly saved, and no crash occurs.

Issue reported on our prod.

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Forward-Port-Of: odoo/odoo#202192
Forward-Port-Of: odoo/odoo#201761

**Problem**:
When archiving the only pos config linked to the preparation display, the configuration of the preparation display shows that no pos config is linked to it (it's linked to all pos configs). However, when pos config starts, it doesn't load the preparation display on _load_model as the domain for it is to load when the specific pos config is linked, or no configs are linked. This confuses the clients as the archived pos will not be seen in the preparation display configuration.

Additionally, there is another issue related to live synchronization in version 18.0. When clicking the "Order" button, the request is sent only if the file is linked to a preparation display see here https://github.com/odoo/enterprise/blob/18.0/pos_preparation_display/static/src/override/point_of_sale/pos_store.js#L37.

As a result, if the display is linked to an archived POS config, live synchronization will not function correctly.

- How to reproduce:
    * Assign one pos config to preparation display
    * Archive the assigned config
    * Open another pos config.
    * Kitchen display is not loaded

**Solution**:
Change the domain to include displays with no configs, or with no active config.

opw-4504623

Forward-Port-Of: odoo/enterprise#81722
Forward-Port-Of: odoo/enterprise#80117

### Issue:

Currently, leaving the barcode app will split moves/move lines in the backend in order to keep track of the changes made on the move lines to match the next time you go into the barcode app.

#### Use case 1 (split move):
- Create a storable product P tracked by lot
- Adjust the onHand quantity to put 2 quants in stock:
    - quant1: Location: WH/Stock, lot_id: LOT0001, quantity: 3.0
    - quant2: Location: WH/Stock, lot_id: LOT0002, quantity: 3.0
- Create and confirm a Delivery order for 3 x P
> The move of the delivery should have reserved 3 units form LOT0001
- Enter the barcode app, scan you DO-name
- Scan your product barcode then scan LOT002 three times
- Leave the barcode app and come back
#### > The barcode line 3/3 was updated to 3/6: 0/3 LOT001 and 3/3 LOT002.

#### Use case 2 (split move line):
- Create 2 storable products P and COMP.
- Adjust the onHand quantity to put 10 units of COMP in stock.
- Create a bill of material for P with one line: - 1 x COMP
- Create and confirm an MO for 10 units of P.
- Set the qty_producing to 5 units -> 5 units of comp are reserved
- Enter the barcode app, scan you MO-name
- The component line should be 5/5 since 5 units are reserved.
- Adjust the registration to 1/5.
- Leave the barcode app and come back
#### > The barcode line 1/5 was updated to 1/1 and 0/9 instead of 0/4.

### Cause of the Issue:

In both cases, the problem comes from the fact we leave the barcode with a different reservation than the initial one.

In the first use case, a new move will be created with a quantity of 3 in order to handle the new line created with LOT002 as soon as you have scanned your products. Therefore even though you entered the barcode app with a reservation demand of 3 units you leave it with 2 move lines with a cumulative quantity of 3 + 3 = 6:
- line1: quantity: 3, lot_id: LOT001, picked: False
- line2: quantity: 3, lot_id: LOT002, picked: True The next time you enter the app you will therefore see a reservation demand of 6 rather than 3.

In the second use case however, a move line is simply created by the `split_uncompleted_moves` when you exit the barcode app: https://github.com/odoo/enterprise/blob/0f4e8ce54be746db02e9f4a6974e387d90608a08/stock_barcode_mrp/models/stock_move.py#L18-L29 
And the quantity of the new move line is based on the `prodcut_uom_qty` of the move rather than the initial reservation demand (quantity when entering barcode). This explains why reservation demand changed from 5 to 10 when you left and came back.

Community: odoo/odoo#193465

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

Forward-Port-Of: odoo/enterprise#80953
Forward-Port-Of: odoo/enterprise#77068

### Issue:

The current qty forecast of rental orders does not rely on incoming and outgoing quantities that could happen prior to the location period and would hence modify the availability forecast.

### Steps to reproduce:

- Create a storable product that can be rented put 100 units in stock.
- Create a sale order for 10 units of that product, confirm and confirm the delivery planned for next week.
- Create a rental order for 5 units of that product for a period ulterior to the delivery.
- Look at the forecast rentable quantity.
#### > It should be 90 but it is 100.

### Cause of the issue:

The forcasted quantity of a rental order line is based on the `qty_available` of the product:
https://github.com/odoo/enterprise/blob/01b6a70348ffa11a9ead2558571b1ccfa1dd3cbb/sale_stock_renting/models/sale_order_line.py#L115-L129 https://github.com/odoo/odoo/blob/3264e3399918b9627693e78d684ac9ac4ad3bd7d/addons/stock/models/product.py#L31-L43 However, this quantity does not take the incoming and outgoing moves that are planned to happend prior or during the location. In case the renting period starts at an ultarior date than today, it should rather be based on the `virtual_available` quantity of the product:
https://github.com/odoo/odoo/blob/3264e3399918b9627693e78d684ac9ac4ad3bd7d/addons/stock/models/product.py#L44-L55 (note that since we need to take into account each of the incoming and outgoing moves that could happen prior to the location, the `from_date` context key needs to be set to today).

opw-4552760

Forward-Port-Of: odoo/enterprise#81532
Forward-Port-Of: odoo/enterprise#81127

### Issue:

You can not print label for an mo is the qty_producing is at 0.

### Steps to reproduce:

- Create a storable product FP tracked by LOT.
- Create a bom for that product with 1 operation containing an instruction of type: "print label"
- Create and confirm an MO for 10 units and set a lot by hand (but ensure that the qty_producing of the MO is still at 0).
- Process the operation in the shopfloor and print label
#### > The printed label is empty.

### Cause of the issue:

The qty of label printed depends solely on the qty_producing of the workorder but in case this one is not set we should rather rely on the qty to be produced.
https://github.com/odoo/enterprise/blob/2a91cb194d070879b5e1e5f5fa03178aa2dcc7ec/mrp_workorder/models/quality.py#L344-L351 https://github.com/odoo/enterprise/blob/2a91cb194d070879b5e1e5f5fa03178aa2dcc7ec/mrp_workorder/models/quality.py#L327-L332

opw-4583573

Forward-Port-Of: odoo/enterprise#81478
Forward-Port-Of: odoo/enterprise#80802

Versions
--------
- 17.0+

Community PR: https://github.com/odoo/odoo/pull/201768

Steps
-----
1. Have a internal user with only Sales: Own Documents access;
2. assign the user to a subscription;
3. as admin, create an invoice for the subscription;
4. assign yoursel as salesman on the invoice;
5. confirm the invoice;
6. log in as the other user;
7. try to create an invoice for the subscription assigned to you.

Issue
-----
Access error.

Cause
-----
Unlike the the other `_compute_amount_*` methods of sale.order, `_compute_amount_invoiced` isn't computed with `sudo`.

This isn't an issue when just using `sale`, as it's computed with only sale order fields, but if an override attempts to check `invoice_ids`, it will throw an error if it has an invoice you don't have access to.

Solution
--------
In `sale`:
- Bring the compute method in line with other `_compute_amount_*` methods, add `compute_sudo=True` to the `amount_invoiced` field.

In `sale_subscription`:
- Add a test to prevent regression.

opw-4554639

Forward-Port-Of: odoo/enterprise#81658
Forward-Port-Of: odoo/enterprise#81461

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

Tax lines are not created in cases where Odoo expects them to be $0 [1]. This is problematic for cases where tax is computed externally and the tax is not in fact $0. There is now no tax line to adjust to the right amount.

To reproduce:

1. Configure Avatax
2. Configure the Discount product to have the "Non-taxable product" Avatax category
2. Create an invoice to Azure Interior
3. Select the Avatax fiscal position
3. Add 1 FURN_6667 with default unit price $295
4. Add 1 Discount with unit price -$295
5. Click "Compute Taxes"

The invoice is fully discounted but $30.24 tax must still be paid. This is correct. It's reflected in the invoice total, but the tax lines are not in the journal items.

`_set_external_taxes()` goes through the summary to set the right tax amounts, but cannot find the line.

This solves the issue by using a new hook in accounting that prevents these $0 tax lines from being excluded.

opw-4493544

## PR note
Alternative to https://github.com/odoo/enterprise/pull/80095.

Forward-Port-Of: odoo/enterprise#80097

Steps to reproduce the issue:

1. Activate the Odoo Mexican Localization Reports module
2. In a Mexican company, create a new Account with 1 as code
3. Go to Trial Balance and download COA SAT (XML)
5. In the General Settings with developer mode active, Download XSD files
6. Go to Trial Balance and download COA SAT (XML) again
7. You get a UserError with an unclear message

Explanation:

The Mexican Chart of Accounts have clear rules regarding `account.account.code`. The only way to verify those accounts is through the XSD files check, but they are not automatically downloaded and the error received with those files downloaded is not user friendly.

Fix reasoning:

Instead of regulating the code when downloading the XML. We'll add warnings on the Chart of Accounts to notify the user when a code is incorrect. To make the report error clearer to the user, we added a RedirectWarning that displays the accounts with faulty codes before generating the xml.

opw-4287338

Forward-Port-Of: odoo/enterprise#81439
Forward-Port-Of: odoo/enterprise#73943