Since the rule refactor, additional byproducts are not considered in the post production picking. The problem is when we add a new byproduct, the backend do not add the warehouse_id on the stock move, and without a warehouse id, it was impossible to find a stock rule for it. Now, with the correct warehouse and stock rule, the stock move is added on the transfers.

Testing steps:
---------------------
- go to configuration > settings > enable Multi-step routes 
- go to configuration > warehouses and enable either 2 or 3 step manufacture
- go to configuration > enable byproducts
- create a BOM with some components/byproducts
- create a MO with the BOM above, confirm it.
Now, we can see the 'transfers' button with 2 transfers, one by the components and another one for the final products and the byproducts.
- add a new byproduct with some produced quantity.

Problem:
-------------
No picking for the new byproduct when clicking on the transfer button

Expected behaviour:
------------------------------
The byproduct should be in the list

task: 3982566

Forward-Port-Of: odoo/odoo#170280

From most openpyxl resources it is generally recommended to instantiate it as `read_only=True` or `write_only=True` in order to leverage lazy modes which do not need to eagerly load the entire file in memory.

However this causes memory exhaustion issues in Odoo workers, with file preview / imports failing: apparently we have managed to generate the `res_partner.xlsx` sample file in such a way that `load_workbook(read_only=True)` is incapable of finding the end of the file, so it thinks the file goes up to the limit for the format of 1048576 rows:

    $ python -c 'import openpyxl; w = openpyxl.load_workbook("odoo/addons/base/static/xls/res_partner.xlsx", data_only=True, read_only=True); print(sum(1 for _ in w.worksheets[0]))'
    1048576

even though the file only has 4 rows (including the header).

This means any client which uses this file as basis to create their own export (or a method generating similarly odd / corrupted files) requires parsing on the order of 20~30 million cells to try and import the file, even though in reality they might only have a few dozens or hundreds.

As a result the import *attempt* takes several minutes (4~5 locally, maybe a bit less on beefy server) and ~1.7GB memory, and thus routinely fails if the worker has any sort of existing pressure (e.g. well filled caches) as it hits the hard memory limit (2.5G by default).

Using the "less efficient" standard mode, the ingestion takes ~1.4s and 14.5MB memory. Which is still a far cry less efficient than xlrd.xlsx was (~0.00 seconds and 120k) but at least somewhat reasonable...

The issue has been reported upstream at https://foss.heptapod.net/openpyxl/openpyxl/-/issues/2221

Forward-Port-Of: odoo/odoo#177586

Example of steps:

    - install `inventory`
    - Open a transfer/receipts
    - add a product
    - validate it
    - click on return
    - there is a modal with the product
    - double click quickly on remove button
    - click return
    - traceback

```
psycopg2.errors.InvalidTextRepresentation: invalid input syntax for type integer: "virtual_12"
LINE 1: ...ETE FROM "stock_return_picking_line" WHERE id IN ('virtual_1...
                                                            ^
```
When this modal is opened, a `one2many` is built with “virtual” records,
which are the products selected in the transfer.

These records are virtual because we don't know which ones the customer
will keep - we'll only know for sure when he clicks on “Return”.

So, when this o2m is loaded, the setup of the Record class populates it.

A first call to the `_applyCommands` function is made with a command to
create a record (product) (command 0/CREATE).

Once the o2m has been loaded, the customer (who quickly clicks to remove
several products) ends up at some point double-clicking on the remove
button of the same product will trigger two consecutive calls to `_applyCommands`.

The first call (which is the correct call)
will have the command: `[2, “virtual_12”]` which is a `DELETE`.

But as we've already asked to create the same “virtual_12” record,

we are here:

https://github.com/odoo/odoo/blob/7caddbb653aa8235725b48ff9f28d6119fdc3567/addons/web/static/src/model/relational_model/static_list.js#L580-L585

Here, given that we have a delete `virtual_12` command and that just before
the setup we asked to create `virtual_12`, this condition will just remove
the command that creates `virtual_12` to simplify the operation without
creating a `DELETE` command.

So instead of creating it and then deleting it, we just don't create it.

The problem arises with the second click, which triggers exactly the same
call to `_applyCommands`, asking to delete `virtual_12`.

As this time we don't have any more “record creation” pending, we'll
enter here


https://github.com/odoo/odoo/blob/7caddbb653aa8235725b48ff9f28d6119fdc3567/addons/web/static/src/model/relational_model/static_list.js#L583-L585


The second click will ask you to delete a record that never existed in
the `web_save`... so that's what the python server don't like!

To correct the problem, I apply a variable to the button in the dom,
which I set to true when the first click occurs, and which I check on
the second click to ignore it.

opw-[4043992](https://www.odoo.com/web#id=4043992&view_type=form&model=project.task)

Forward-Port-Of: odoo/odoo#173481

### Steps to reproduce:

- Enable multi-steps route in the settings
- Go to Inventory > Reporting > Locations
- Group the records by "product"

#### > the On hand quantity is only displayed on the records of each group

### Cause of the issue:

The `inventory_quantity_auto_apply` field of the `stock.quant` model is a non-stored computed fields. As such, even if this line: https://github.com/odoo/odoo/blob/7a80215435f98a771065ba41310ac643aeffdaf5/addons/stock/views/stock_quant_views.xml#L147 tries to add its sum to the list view of quants, the `inventory_quantity_auto_apply:sum` will not be present in the `fields` of the `read_group` nor will be added to the `aggregates` of the `_read_group` by these lines:
https://github.com/odoo/odoo/blob/7a80215435f98a771065ba41310ac643aeffdaf5/odoo/models.py#L2711-L2713 Prior to 17.0, this `inventory field` was rather treated by an override of the `read_group` in the `stock_quant` model.
https://github.com/odoo/odoo/blob/3d3155e94ec886e2fdc9a635c4732e8e56179db1/addons/stock/models/stock_quant.py#L309-L312 In 17.0, in commit 687d0ed, this override was replaced by an override of the `_read_group_select` which, to work properly, expects the `inventory_quantity_auto_apply:sum` to appear in the aggregates of the `_read_group` to be called by the `_read_group_select`. Since issue appears, because it is not the case.

### Note:

The issue is only reproducible in 17.0 and saas-17.1 since after saas-17.2 (included), the `inventory_quantity_auto_apply:sum` will appear in the fields of the the `read_group` and hence in the aggregates of the `_read_group`.

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

Forward-Port-Of: odoo/odoo#176181

Issue: the reserved quantity appearing on the SOL wizard is not well behaved with respect to 2+ steps deliveries.

### Steps to reproduce:

- Enable Multi-step routes in the settings
- Inventory > Configuration > Warehouse Management > Warehouses
- Enable delivery in 2 steps
- Create a storable product and put 1 unit in stock
- Create and confirm an SO for 1 unit
- Click on the chart icon next to the delivered qty

#### > the reserved qty is 0 + "No future availability" even though 1 unit is reserved from stock

### Cause of the issue:

The reserved qty displayed on the next to the delivered qty on the SOL is the `qty_available_today` computed field of the SOL model. This field is computed by summing the qties of the stock moves linked to the SOL: https://github.com/odoo/odoo/blob/817186b7b896c9a415bd947baf189bf7f1bde321/addons/sale_stock/models/sale_order_line.py#L69 https://github.com/odoo/odoo/blob/817186b7b896c9a415bd947baf189bf7f1bde321/addons/sale_stock/models/sale_order_line.py#L80-L81

However, when you are not delivering in 1 step, the only delivery move linked to the SOL will be the move which destination is the customer location. To be more precise, confirming the SO in a delivery in two steps a stock move from the Output to the customer will be created and linked to the SOL. During the action confirm of this move a procurement will be run to generate a move from stock to the Output but the SOL will not be referenced anymore so that the SOL will not be linked to it.

### Note:

The behavior is different in saas-17.2 where each of the delivering move is linked to the SOL so that the probably need to be adapted.

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

Forward-Port-Of: odoo/odoo#176891
Forward-Port-Of: odoo/odoo#176756

The aim of this commit is to ensure we always have a company from which to pull values.

Context:
On odoo.com, we have only one website but when users buy something on our website, we create the so, the payment and the invoice with the company which is in the country of the user.
This results in a situation in which the user initiating the question

Before this commit:
It was possible to not have a company there, leading to inconsistencies later on when relying on company to get some values like `tax_calculation_rounding_method`.
For odoo.com, it resulted in a 0.01€ discrepancie between the sale order and its invoice. As the payment transaction was made based on the sale order amount, the invoice remained unpaid forcing the accountants to manually write off the difference.

After this commit:
There is always a default company provided ensuring taxes gets computed correctly and thus having sale order and invoice having the same amount.

Special thanks to PMO for his HUGE help debugging this madness.

task-id: None (issue spotted on odoo.com)

Forward-Port-Of: odoo/odoo#177618

## Analysis
Since a recent commit (https://github.com/odoo/enterprise/commit/25f72c0b716d5fdc15493b74375106e3d6f580fa), the operation_note is fetched independently from the other fields to avoid performance issues.
This causes issues as, when computing data context (e.g. during `onChange`), we assume that all fields in data are available in config:
```
_computeDataContext() {
...
        const data = toRaw(this.data);
        for (const fieldName in data) {
            const value = data[fieldName];
            const field = this.fields[fieldName]; // field == undefined
            if (field.relatedPropertyField) { // traceback
                continue;
            }
...
}
```

## Steps to reproduce
- Create a product "TEST"
- Create a BoM For product "TEST", with a new product "TEST Component".
- Add 1 Operation OP1 (keep default value), set a description
- Add 1 step to OP1, with type "Register Production"
- Create MO for "TEST", Confirm, Plan, 
- Start operation OP1
- On ShopFloor, go to MO, select workcenter, open step
- Update quantity: Error

## Solution
We make a way for manually fetched fields (most probably, all HTML fields which can contain base64 images) and add it to the fields to avoid them being undefined and causing tracebacks.

 ## References
opw-4103712


--
I confirm I have signed the CLA and read the PR guidelines at [www.odoo.com/submit-pr](http://www.odoo.com/submit-pr)

Forward-Port-Of: odoo/enterprise#68497

**Steps to reproduce:**
- Install Accounting and l10n_co
- Switch to a Colombian company (e.g. CO Company)
- Create a bill with a line having an IVA tax and a withholding tax:
  * IVA Compra 19%
  * RteIVA 15% sobre el 19% IVA
- Post the bill
- Create another bill with a line having only an IVA tax
- Post the bill
- Go to "Accounting / Reporting / Colombian Statements / Certificado de Retención en IVA"

**Issue:**
"Monto del Pago Sujeto Retención" column is incorrect. It takes into account the tax amount from the IVA tax of both bills. As there is no withholding tax on the second bill, it should be excluded from the report.

**Cause:**
The report is checking the tax lines where the account is "2408%%" to compute the amount of this column.
So every tax lines with from an IVA tax will be taken into account, even if there is no wihholding tax.

**Solution:**
Computing the correct amount by checking the account and the presence of a withholding tax is pretty complex.
It would require to rely on the invoice lines instead of the tax lines to recompute the tax amounts because the amount of a specific tax is aggregated into a unique tax line (even if there are several invoice lines with different taxes combination) and there is no information about the tax repartition in the tax line.
Recomputing all from the invoice lines would bad for the performance.

As the withholding taxes are always 15% over VAT in Colombian localization, we can simply apply this formula to retrieve the amount subjected to withholding:

[Monto del Pago Sujeto Retención = Retenido Consignado / 15%]

opw-3989661

Forward-Port-Of: odoo/enterprise#68724
Forward-Port-Of: odoo/enterprise#68016