Steps to reproduce:
1. Create a storable product with tracking set to 'By Quantity'.
2. Update the Quantity on Hand (e.g., 100 units).
3. Change the product tracking to 'By Serial Number'.
4. Create a Repair Order for this product.
5. Add a line, select a specific Serial Number, and click Save.
6. Observe that the serial number disappears.

Cause:
When reserving stock that was originally created as 'Generic' (no serial), the `_prepare_move_line_vals` method returns `lot_id=False`. The repair view uses `_compute_lot_ids` to display selected lots, which filters out any move lines where `lot_id` is False. This causes the new line to be effectively invisible to the UI immediately after creation.

Solution:
In the `_set_lot_ids` inverse method, explicitly force the `lot_id` into the create values dictionary (`move_line_vals`). This ensures that even if Odoo reserves generic stock, the resulting move line is born with the correct Serial Number identity, keeping it visible and valid.

opw-5156267

Forward-Port-Of: odoo/odoo#247885
Forward-Port-Of: odoo/odoo#247150

**Steps to reproduce:**
- Install Website/Event/Sales apps
- Create a new event and set a ticket price
- Create a fiscal position (with specific tax) for a country with `auto_apply` enabled
- Publish the event
- Register to the event as a anonymous user
- The process bypasses the address form and goes directly to payment
- The resulting sale order will have no fiscal position
- Prices won't be impacted by taxes related to the user billing address

**Issue:**
Address form is skipped before payment for event registration of a public user as `_needs_customer_address` is not overwritten properly in some module. This is probably due to a refactoring that changed how the required information is evaluated in the payment flow (see related commit).

**Fix:**
Set `_needs_customer_address` to `True` by default to avoid such issues in
dependant modules. Might need to remove this feature in master as the workarounds are
not that clean (geo_ip, check on fiscal position enabled, overwrite everywhere, others ?).

Similar fix is done for appointments with payment enabled.

related: https://github.com/odoo/odoo/commit/d43f0423667835512e16c3fd3474328da63a948d
original-task: https://www.odoo.com/odoo/project/49/tasks/4307281

opw-5143124

This PR improves payment move synchronization and fixes an error that is caused while changing amount of a Payment that has multiple liquidity lines.

Steps to reproduce:
1. Create payment with x amount and validate it.
2. Open the payment journal entry.
3. Reset to draft and update the liquidity line amount from x to (x - y)
4. Create another liquidity line with amount y to balance entry and post it.
5. Draft the payment and try to update the amount.

A traceback will appear. `ValueError: Expected singleton`

Cause:
The lines for payment JE are prepared for the case assuming that there will be only 1 liquidity line, but since we have more than 1, we get a Singleton error.

Description of changes made:
While preparing values for move in `synchronize_to_moves()` check for multiple liquidity lines and append all values to write.
Further, the `_prepare_move_line_default_vals()` is also improved in order to manage different type of move lines individually.

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

Forward-Port-Of: odoo/odoo#246675

Steps to Reproduce:
1- Auto-plan a task starting on 25 November 2025 with 40 allocated hours. 2- The computed end date becomes 26 November, instead of extending into early December. => As a result, the allocated period is shorter than the required hours.

Source:
When selecting 25/11/2025 as the start date, the system tries to schedule the task within the remaining days of November (25–28).
However, these four days are not enough to cover 40 hours.

The system then searches for available intervals in the next month. But the intervals from November are still kept in the list, so when the algorithm iterates again, it reuses the previously consumed intervals (25 and 26). This causes the scheduler to allocate the remaining hours to those same days, leading to an incorrect result where the task spans only 25–26 November, instead of continuing from 1 December.

Solution:
Remove already-used intervals before recomputing the schedule.

opw-5364327

Forward-Port-Of: odoo/enterprise#106160
Forward-Port-Of: odoo/enterprise#101262

Occasionally the test_kardex_report test fails:

```
Traceback (most recent call last):
  File "/data/build/enterprise/l10n_pe_reports_stock/tests/test_ple_kardex_report.py", line 126, in test_kardex_report
    self.assertSequenceEqual(
AssertionError: Sequences differ: ['M1|[18 chars]|1||02/01/2024|01|FBILL202401|0002|02|product_[313 chars], ''] != ['M1|[18 chars]|1||01/01/2024|01|FBILL202401|0001|02|product_[313 chars], '']

First differing element 0:
'M1|0[17 chars]|1||02/01/2024|01|FBILL202401|0002|02|product_[21 chars]0|1|'
'M1|0[17 chars]|1||01/01/2024|01|FBILL202401|0001|02|product_[21 chars]0|1|'

- ['M1|0000|1|99|FURN9999|1||02/01/2024|01|FBILL202401|0002|02|product_order_no|NIU|3.00|0.00|1|',
?                             ^                           ^

+ ['M1|0000|1|99|FURN9999|1||01/01/2024|01|FBILL202401|0001|02|product_order_no|NIU|3.00|0.00|1|',
?                             ^                           ^
```

The issue was reproducible locally by disabling nested loop joins: `self.env.cr.execute("SET LOCAL enable_nestloop = off")` to nudge Postgres to use a different join strategy.

The test creates a PO that is picked and invoiced in two steps (first quantity 3, then the remaining 2). As a result, the `stock.valuation.layer` ends up being linked to two `account.move.line`s because the join goes through the same `purchase_order_line`. So it will appear twice in the `_get_ple_reports_data()` query. A `DISTINCT
ON (stock_valuation_layer.id)` was already there with the goal of picking one of them. Which one depends on the order, but it's not deterministic: the valuation layer's `id`, `product_id`, and `create_date` will all be the same.

This commit makes the behavior deterministic by sorting on PO line and SO line ids.

runbot-error-238888

Forward-Port-Of: odoo/enterprise#107047