Problem: A loyalty rewards points member don't receive their points for their confirmed order if they don't sign into their account when signing their quotation online from a link they received in their email. This bug only occurs if the quotation is set to "online signature" only. The bug is not reproducible when the quotation is set to both "online signature" and "online payment" or if website_sale_loyalty is not installed.

Purpose: It is expected that customers should receive their reward points for their order without needing to sign in because they accessed the link to sign the quotation from their email. It should be consistent with the behavior exhibited from having "online payment" set for the quotation or without website_sale_loyalty installed.

Steps to Reproduce on Runbot:
1. Install Sales app,  website_sale_loyalty, loyalty, sale_loyalty
2. Create a loyalty program that reward points based on orders
3. Create a quotation for a partner, set "online signature" in Other info, and click "Send by email"
4. Access the email in Settings > Technical > Emails
5. Copy the "Accept & sign" link and paste into incognito window
6. Sign the quote as a public user
7. Observe that the loyalty card  for the partner did not update the points

opw-4205826

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

Forward-Port-Of: odoo/odoo#182545

Content of the IMP:
---

In the form picking view, it is possible to edit the move lines that are related to a given move by using the `SMLX2ManyField`. However, untill you save the record, available quantity of quants present in the  DB are not updated. This commit ensures that the quants proposed for your  move line creation have an available quantity (even if currenlty dirty) and that the quantity used for the next move line creation is both related to the demand of the move, and the real availability of the quant used to create it.

[FIX] stock: avoid move line reset when opening detailled ops
---

This reverts [1] commit b45e249f8f5f36cffdb1ff615953eac7bb45b995.

### Steps to reproduce:

- Enable Multi-step routes
- Create a storable product: put 5 units on shelf 1 and 5 on shelf 2
- Create and "mark as todo" a delivery order for 3 units
- Click on the detailed operation and change the reservation from shelf 1 to shelf 2 > save (the subrecord not the record)
- Reopen the details operation
#### > The records get resets in front of you

### Cause of the issue:

One of the main problems of [1] is that it modifies dirrectly the data's of the props of the component used by the X2many dialog:
https://github.com/odoo/odoo/blob/7e01d83ac08f9b076e0cd7d7e644679d5264ff7d/addons/stock/static/src/fields/stock_move_line_x2_many_field.js#L48
As such, as soon as you mount that component, you will reset the data's used by that same component. Worse, the component is doing this to itself. Hence, if you did not perform a save before opening the details operation you will reset the values to match the DB's data. Furthermore this data change modifying the props of the component we are looking at will force to reload the component with the newly hardcoded data (which explains that you see your last change resetting in front of you).

In addition, the `quant_id` field of the stock.move.line model is a very particular field as it is neither stored or computed but is used by the create and the write for the stock.move.line data's to match some of the quant informations:
https://github.com/odoo/odoo/blob/7e01d83ac08f9b076e0cd7d7e644679d5264ff7d/addons/stock/models/stock_move_line.py#L85
https://github.com/odoo/odoo/blob/7e01d83ac08f9b076e0cd7d7e644679d5264ff7d/addons/stock/models/stock_move_line.py#L310-L311
Therefore this field will never be set on a move. line that was not  modified in JS and is not saved yet. In order to take into account  the offset between the DB Data and the data's we are setting on the form of stock move it is therefore necessary to perform an rpc to **guess**  what quant was used to create a given line. HOWEVER, as teached by the JS framework formation:
```
The first rule of customizing Odoo in JS is: do it in python
```
So that you should not do that matching in JS but rather where it belongs.

Finally, modifying the props of a component during the `onMounted` is a super hacky way to use OWL as it is the first Hook for which OWL does not destroy the component because of props inconsistency...

opw-4294650

Original issue of the reverted "FIX":
---

### Steps to reproduce

- In the setting enable Multi Step Routes
- Create a storable prodcut and put 5 units on shelf 1
- Create and Mark as Todo a delivery order for 3 units of your product
- Set the quantity of the move to 0 and save the record
- Click on the "burger list icon" of the stock move to edit the
  detailed operations and make the reservations for your 3 units
- We want to make the reservation in 2 lines targetting the same quant
- Add a new line selecting your shelf 1 quant and set the qty to 1
- Try to add a second one the quant is not proposed

### Cause of the issue:

When a quant has been selected at least once and the record is not yet saved the js data of the record contains the info of the quant used to create/update the move line because of the non stored not computed dummy field `quant_id` of the stock move. As such the quant will be considered to already having been used in this transaction and hence not available:
https://github.com/odoo/odoo/blame/54e06a1b25ed9e317e368e89979c7c77ddbffc08/addons/stock/static/src/fields/stock_move_line_x2_many_field.js#L52-L54

### Note:
The IMP fixes the original issue + more.
This reverted commit already required an other fix: Commit ea4fca8faa4ee84693e645514085a65b92364842

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

Forward-Port-Of: odoo/odoo#187462
Forward-Port-Of: odoo/odoo#186400

**Current behavior:**
Having a manufactured product with components, all with
'average' costing, a series of receiptions for the components at
difference price points, followed by an MO, followed by another
reception at (again) a new price point will result in an
imbalanced "Cost of Production" journal if the aforementioned MO
is unbuilt.

**Expected behavior:**
The unbuild operation doesn't leave the journal imbalanced.

**Steps to reproduce:**
1. Create a stored product with average, real_time costing

2. Create a BoM for this product, with 2 stored components (also
with average, real_time costing)

3. Create a PO for the components (price is arbitrary), confirm
and receive the product

4. Create another PO for the components with a different price
from the previous PO, confirm and receive

5. Create an MO for the final product, confirm and
consume/produce all

6. Create a final PO for the components with prices different
from the previous two orders, confirm and receive

7. Create a second MO for the final product and
confirm/consume/produce-all

8. Unbuild the MO from step 5 -> in the "Cost of Production"
journal, observe that there is an outstanding balance

**Cause of the issue:**
When the unbuild operation happens, the current price of the
final product informs the SVL's `value` and `unit_price` fields-
which of course is not the same as when the MO was completed.

We end up with a `unit_price` on the SVL for the final product
which is not equal to the sum of the component SVLs'
`unit_price` which leads to the generation of account move lines
that won't be balanced.

**Fix:**
During an ubuild operation, stock moves for finished products
which may have this issue (i.e., have non-standard costing) with
linked SVL records will use that SVL's unit cost for the unbuild
SVL (and ensuing journal entries) as opposed to taking the
current cost.

opw-4062415

Forward-Port-Of: odoo/odoo#188016

**Steps to reproduce:**
- Make sure that PyPDF2 is in version 1.26.0
- Install l10n_mx_edi
- Switch to a Mexican company
- Create an invoice:
  * Customer: [a Mexican customer]
  * Payment Way: [Effectivo]
  * An invoice line with a product having a UNSPSC Category
- Confirm the invoice
- Generate CFDI via "Send & Print" button
- Register a payment with "Efectivo" Payment Way
- Update Payments on the invoice
- Go to the payment
- Force CFDI
- Make sure the CFDI status of the payment is "Signed"
- Print "Payment Receipt"

**Issue:**
PyPDF2 raises a traceback:
"IndexError: list index out of range".

**Cause:**
PyPDF2 is executing this code to format a warning: file = filename.replace("/", "\\").rsplit("\\", 1)[1] where filename is something liked "<xxx>" (coming from the qweb compilation). Therefore, there is no index 1.
The warning is coming from lxml and is due to the fact that we are evaluating a xml value as it is in a qweb template:
"FutureWarning: Use specific 'len(elem)' or 'elem is not None' test instead." And since this commit:
https://github.com/odoo/odoo/commit/fd67b56fc695526d09706d2b6218519ea255fc30 Python's "warning.py" is overridden in PyPDF2.

**Solution:**
Use "len(cfdi['cfdi_node'])" as advised to check if the xml node has children in the payment receipt template.

opw-4359466
opw-4366016

Forward-Port-Of: odoo/enterprise#75227

### Steps to reproduce:
- Create two storable product: Final Product (FP) and Component (COMP)
- Create and confirm an MO for FP with a raw move: 1 x COMP
> The move should be: "not available" since 0 unit of COMP are in Stock
- Go to the barcode module > Operations > Manufacturing
- Remove the MO Ready filter > Click on your MO and then exit barcode
- Go back to the MO in the back end (mrp module)
#### > The raw move has been reserved and is hence marked as available.

### Cause of the issue:

Exiting the barcode will launch an rpc call of the `split_uncompleted_moves` in order to split uncomplete moves in 2 if necessary (for the records to be appropriately set the next time you enter the barcode):
https://github.com/odoo/enterprise/blob/71f979d5bdf88207cb94c83bd6a69633da649d1e/stock_barcode/static/src/models/barcode_picking_model.js#L1327-L1329 https://github.com/odoo/enterprise/blob/71f979d5bdf88207cb94c83bd6a69633da649d1e/stock_barcode/models/stock_move.py#L9-L11 Furthermore, since c29f61fdded2e80d0bb3c06199c6a196feac8076 in case of a production the component move are rather splitted on the move lines to avoid odd split of the component moves on the MO. However, in that case if a unassigned move is splitted, a move line will be generated and associated to that move, which makes it reserved and hence available.

opw-4338827
---

Forward-Port-Of: odoo/enterprise#74244