Steps to reproduce
------------------
1. install l10n_sa_edi and l10n_sa_pos
2. onboard the company for ZATCA and link a printer to the PoS
3. make a PoS order with a customer and print the receipt 

-> the ZATCA QR code is too small to be scanned.

Why it's happening
------------------
The phase 2 QR code is big because it also contains the invoice hash, signature and public key. We render it at 200 px, which is too small to scan a QR with that much data. The QR image also has no max width, so it gets cut when the receipt is narrow.

The fix
-------
Render it at 400 px, and add `max-width: 100%` so it is not cut on a narrow receipt.

opw-6399766

Before
<img width="647" height="1036" alt="image" src="https://github.com/user-attachments/assets/6bcb8526-71a8-4d9f-8372-219959416214" />


After
<img width="649" height="1031" alt="image" src="https://github.com/user-attachments/assets/70f5fdb5-ba71-4fbe-8f03-ef0a1b29be2e" />

Forward-Port-Of: odoo/odoo#278499
Forward-Port-Of: odoo/odoo#277813

### Batch per all moves, not per product

**Problem:**
In https://github.com/odoo/odoo/pull/250526, moves are batched in order to prevent memory error in databases
with many stock.move. However, the batching is done on the moves per product,
meaning batches can be very small relative to the limit, and this causes
unecessary queries compared to batching per all moves to process.

**Solution:**
Iterate through all moves rather than per product, and use/save the per product
results directly in the relevant dicts.

---

### Batch and prefetch for initial product std_price

**Problem:**
When initializing products' standard price before replaying valuation, the
first stock.move is read. This happens before any prefetching or batching
occurs, so a query is made per move and contributes to performance issues.

**Solution:**
Batch and prefetch the products' first moves, then initialize the standard
price.

---

### Use cached is_in and is_out values

**Problem:**
In `_get_valued_qty()`, `_is_in()` and `_is_out()` are called for each move,
but these methods are already called for these moves and cached as `is_in` and
`is_out`.

**Solution:**
Replace the method calls with the cached fields. If the move is not done, we
fallback to the methods as the cached fields will be false for not done moves.

---

**Perf Tables:**
Record: product.template, each with AVCO automated valuation and a done in move

Today:
|Record count|Time before|Queries before|Time after|Queries after|
|------------|-----------|--------------|----------|-------------|
|1k          |1.08s      |264           |697ms     |235          |
|5k          |2.74s      |864           |2.23s     |864          |
|10k         |4.83s      |1375          |4.56s     |1870         |

At Date:
|Record count|Time before|Queries before|Time after|Queries after|
|------------|-----------|--------------|----------|-------------|
|1k          |3.10s      |6109          |925ms     |386          |
|5k          |14.68s     |30299         |3.50s     |1564         |
|10k         |26.98s     |59173         |7.16s     |3590         |

opw-6134244

Forward-Port-Of: odoo/odoo#261624

### Batch per all moves, not per product

**Problem:**
In https://github.com/odoo/odoo/pull/250526, moves are batched in order to prevent memory error in databases
with many stock.move. However, the batching is done on the moves per product,
meaning batches can be very small relative to the limit, and this causes
unecessary queries compared to batching per all moves to process.

**Solution:**
Iterate through all moves rather than per product, and use/save the per product
results directly in the relevant dicts.

---

### Batch and prefetch for initial product std_price

**Problem:**
When initializing products' standard price before replaying valuation, the
first stock.move is read. This happens before any prefetching or batching
occurs, so a query is made per move and contributes to performance issues.

**Solution:**
Batch and prefetch the products' first moves, then initialize the standard
price.

---

### Use cached is_in and is_out values

**Problem:**
In `_get_valued_qty()`, `_is_in()` and `_is_out()` are called for each move,
but these methods are already called for these moves and cached as `is_in` and
`is_out`.

**Solution:**
Replace the method calls with the cached fields. If the move is not done, we
fallback to the methods as the cached fields will be false for not done moves.

---

**Perf Tables:**
Record: product.template, each with AVCO automated valuation and a done in move

Today:
|Record count|Time before|Queries before|Time after|Queries after|
|------------|-----------|--------------|----------|-------------|
|1k          |1.08s      |264           |697ms     |235          |
|5k          |2.74s      |864           |2.23s     |864          |
|10k         |4.83s      |1375          |4.56s     |1870         |

At Date:
|Record count|Time before|Queries before|Time after|Queries after|
|------------|-----------|--------------|----------|-------------|
|1k          |3.10s      |6109          |925ms     |386          |
|5k          |14.68s     |30299         |3.50s     |1564         |
|10k         |26.98s     |59173         |7.16s     |3590         |

opw-6134244

Forward-Port-Of: odoo/odoo#261624

### Steps to Reproduce:
1. Make sure that the Sale and Inventory modules are installed
2. Enable Multi-Step Routes and Packages in Inventory Configurations
3. Warehouse configuration > Outgoing shipments > Select Pick then Deliver (2 steps)
4. Routes > Deliver in 2 steps (pick + ship) > Pull From > Destination Location > Select WH/Output
5. Routes > Deliver in 2 steps (pick + ship) > Push To > Action > Change to Pull From
6. Operation Types > Delivery Orders > Packages > Enable Move Entire Packages
7. Go to any product, ex. Drawer > On Hand > Set original on hand qty to 16 and new lot to 50
8. Create a new SO and make 2 lines, with the same product, and change the second line's price to something else, ex. 80.0
9. Deliveries > WH/PICK/00001 > Set quantity to 4 > Put in Pack > Validate and Create Backorder
10. WH/PICK/00002 > Put in Pack > Validate
11. WH/OUT/00012 > Mark PACK0000001 Done > Save. Observe how the first line quantity is changed from 3 to 4
12. Mark PACK0000002 Done > Save > Validate > Observe how it's asking for a backorder even though we already packed all 5 items.

### Description of the issue/feature this PR addresses:
Instead of using the `product_qty` from the stock move, use the quantity of the move line to correctly allocate the quantities in StockPackageLevel

### Current behavior before PR:
In the Shop Floor when loading packages, marking the package level as done causes issues on the quantity processed on the corresponding move lines. On stock transfers, we currently allocate the Quantity Done to the wrong product line.
The total quantity is correct, but the distribution across lines does not match the Demand values.
This causes the transfer to remain stuck in Reserved, even though the shipment was already processed operationally.

### Desired behavior after PR is merged:
The correct quantity from the move line is used and this resolves the issue with quantity distribution not matching move line quantities when using packages.

opw-6040640

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

### Steps to reproduce:

- Create 3 AVCO products: Super Kit, Kit, Comp
- Super Kit BoM: 2 x Kit
- Kit BoM: 1 x Comp
- Create and confirm a purchase order for 1 X Super Kit at 100
- Validate the receipt of 2 Comp
- Go to the valuation
> Both units of Comp are valued at 100 for a total of 200

### Cause of the issue:

The issue has been introduced by:
https://github.com/odoo/odoo/pull/158849/changes/713701a5035d342263e3fef2a2819b5696b6d063 To be more precise, the price unit of each unit of Comp is expected to be computed by the `_get_price_unit`. This method used to rely on the `product_qty` appropriately:
https://github.com/odoo/odoo/pull/158849/changes/713701a5035d342263e3fef2a2819b5696b6d063#diff-687527af1723e60816358020c4d83687479df62ca0cfd71079f0a82afb4b3efeL27 However, backorder adapt the move demand and hence did not provide the appropriate demand in this flow that computation logic was changed to rely on the `bom` and `bom_line` quantities:
https://github.com/odoo/odoo/blob/29977a6a80442af49ecefa7fef54f085483d8f77/addons/purchase_mrp/models/stock_move.py#L20-L40 This new computation is not correct in case of nested boms since the `bom_line` only carries the unit demand on the last explosion stage.

### Additional issue:

If nested kit boms lead to the creation of 2 moves with the same `cost_share` and `bom_line_id`, these moves will be merged without summing their `cost_share` leading to an under pricing of the kit since its related `stock_move`'s `cost_share` will not sum up to 100 percents anymore.

This issue is tested in `test_avco_purchase_nested_kit_explode_cost_share_backorder_2` and fixed similarly to demand merging:
https://github.com/odoo/odoo/blob/613f3cb7b2f4813ce6c8f53718a6cca841b081ad/addons/stock/models/stock_move.py#L1122-L1134

### Note:

We also modify the test `test_valuation_with_backorder` to be understandable and to make appropriate asserts.

opw-6253776

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

With "Round Globally" tax rounding, invoicing a 100% down payment and then creating the final regular invoice yields a credit note of 0.01 instead of an invoice of 0.00. The sales order is still flagged as fully invoiced, so the customer is left with an unexpected refund document.

A down payment line can only store a `price_unit` rounded to the 'Product Price' decimal precision, while the product lines it must offset are aggregated from their raw amounts. When a product subtotal falls on a half cent (e.g. quantity 0.5 at 1.01 => 0.505), the final invoice carries a raw residual of -0.005. `_round_tax_details_base_lines` rounds that aggregate to -0.01 and `_distribute_delta_amount_smoothly` assigns the cent to the largest base line, leaving its `balance` one cent away from its own `price_subtotal`. Since `amount_untaxed` derives from the balances, the invoice totals -0.01 and `_create_invoices` switches it to a refund.

The product amounts have already been invoiced and rounded on the down payment invoice, so the aggregation must target those rounded amounts. Declare them through `manual_total_excluded_currency`, which is read from the base line dict and feeds `target_total_excluded`. `total_excluded` is unchanged, so no posted or displayed amount moves.

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

Steps to reproduce
---
1. Confirm a purchase order and receive it a few days later.
2. Open Purchase, Reporting, Purchase and add the "Effective Days To Arrival" measure.

Observed: the value is counted from the line's scheduled date instead of the order date, and can even be negative when the scheduled date precedes the confirmation date.

Issue
---
The metric is meant to be the effective lead time, the number of days between the order confirmation and the actual receipt, falling back to the planned "days to receive" when nothing has
been received yet according to [task](https://www.odoo.com/odoo/project/809/tasks/3691573).
The query instead computes age(date_planned, COALESCE(date_done, date_order)), so once a receipt exists it returns date_planned - date_done (the gap between the
scheduled date and the receipt) rather than date_done - date_order.
https://github.com/odoo/odoo/blob/c06be48ce7277a667719fd756e0a1f63e91cda27/addons/purchase_stock/report/purchase_report.py#L20-L28

opw-6226523

Issue
-----
Adding packagings of products through the catalog sometimes doesn't work.

Steps to reproduce
-----
- Create multiple products with some packaging
- Create a PO
- Open the product catalog
	- Add products & packagings (click the product then the pack button)
- Go back to the PO

=> Some lines might not have the packaging but instead a single unit

Cause
-----
The problem is a race condition with the
`/product/catalog/update_order_line_info` route

https://github.com/odoo/odoo/blob/427d398880c381981e088f7001f855a10d1cd581/addons/product/controllers/catalog.py#L32-L33

The problem comes from the call to `_update_order_line_info` where the bahviour is different depending on the order in which the calls are treated.

https://github.com/odoo/odoo/blob/427d398880c381981e088f7001f855a10d1cd581/addons/purchase/models/purchase_order.py#L1195-L1238

The expected flow is for the call to add the product to be treated first, then the call to add the packaging. If the order of the calls is reversed, the packaging call does not go into either of the conditions and nothing happens, then the "add product" call is handled and a line for a single unit is created.

This is caused by the JS where the "add product" calls are handled in order by processing them in a promise queue

https://github.com/odoo/odoo/blob/427d398880c381981e088f7001f855a10d1cd581/addons/product/static/src/product_catalog/kanban_record.js#L68-L78

The "packaging" calls, however, are fired directly, meaning there is no guarantee the line has already been created.

https://github.com/odoo/odoo/blob/427d398880c381981e088f7001f855a10d1cd581/addons/purchase/static/src/product_catalog/kanban_record.js#L34-L47

-----
Ticket:
opw-6401919

Issue:
---
Fiscal position is wrongly set to `self.env.user.partner_id.country_id`
instead of `partner_shipping` country, if `partner_shipping_id` is not
changed in the checkout process.

Steps:
1- Create two auto detect fiscal positions: France, Germany
2- Set portal user's partner address country to France.
3- Using portal user, shop from website, and create a delivery address.
4- Pay and confirm the order.
5- Using the admin user, you check the SO's FP which is correctly set
   to Germany.
6- Using portal user, again shop from website, and don't change
   address. Keep previous shipping address which is Germany.
7- Confirm and pay the order.
8- Using admin user, check the new SO's FP. It's set to France.

Cause:
---
`_compute_fiscal_position_id` in SO depends on `partner_shipping_id`.
When the `partner_shipping_id` is not changed, the fiscal position
value set in create will remain.
This value is set in `Website._prepare_sale_order_values()`.
The `fiscal_position_id` is set to self.fiscal_position_id, which is
`_get_fiscal_position(self.env.user.partner_id)`.

Fix:
---
If the user has already a SO, we can use last SO's shipping address
and invoice address to calculate FP in `_prepare_sale_order_values`.

opw-6357638

### Steps to Reproduce:
1. Go to login page and click "Don't have an account?"
2. Create an account with a space in the email
3. Try to login with just the email with no space -> fail
4. Log in with the space -> success

### Description of the issue/feature this PR addresses: 
**Issue:** There is no email validation that occurs when users create a new account. Therefore, if they accidentally add a space to the email, they have to login with the space or change their login. However, there are also users who use this field as a username, rather than an email.

**Solution:** Make email validation upon account creation optional as a new `ir.config.parameter`. This way, users can choose whether they want to use the email field as a validated email or just a username.

### Current behavior before PR: 
Since emails are validated, if users accidentally add special characters to their email when signing up, they have to include it every time they login, unless they manually change their login.

### Desired behavior after PR: 
There will be no email validation by default, but users can activate it (and deactivate if they change their mind in
the future). There will be a new `ir.config.parameter` called `auth_signup.validate_email`.

opw-6378031

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