Steps to reproduce:
1. Install `accounting` and `account_check_printing` modules.
2. Configure a bank journal:
   - Enable the `Manual Numbering` option for checks.
   - Set an `Outstanding Payments Account` for checks under the `outgoing payments` tab on the journal.
   - Ensure the Check Sequence is properly configured.
3. Create three vendor bills (two for the same vendor and one for a different vendor).
4. Go to the list view of vendor bills and select all three of them.
5. Click the `Pay` button and in the payment wizard:
   - Enable the `Group Payments` option.
   - Choose `Checks` as the payment method.
   - Confirm the wizard to register the payment.

Observed Behavior:
- Multiple payments are created simultaneously.
- Each payment has its own check number (e.g., 0001, 0002), correctly assigned.
- However, all the related journal entries (account.move) have journal item labels that incorrectly use the same check number (e.g., all journal items have label Check - 0001 instead of Check - 0001, Check - 0002, etc.).

Issue:
- Journal entries are created during payment creation `create()`, at which point the payments are still in draft state.
- The check_number is only computed and the check sequence is incremented when the payment is posted `action_post()`.
- As a result, all journal entries generated during draft state receive the same initial check number.

Solution:
- Override the `_get_trigger_fields_to_synchronize` method to include the `check number`, ensuring that any updates to the check number on a payment are also reflected in the related journal entries.

opw-4886452

Forward-Port-Of: odoo/odoo#220150

**Steps to reproduce:**
- Install `pos_sale`.
- Create a sale order for a POS product with quantity 1 and UoM `Dozens`.
- Confirm the order.
- Go to Point of Sale → open a session.
- Click Actions → Quotation/Order and select the recently created sale order.
- Check the POS order line quantity.

**Issue:**
- The POS order line shows quantity as 1 unit, while the sale order line used 1 Dozen, so it should be 12 units.

**Cause:**
- The POS order line was directly using the quantity and price from the sale_order_line without applying the proper UoM conversion.
https://github.com/odoo/odoo/blob/8f937d4c4a6c4cece698a5e904ba7a0cf2fbb24c/addons/pos_sale/static/src/overrides/models/pos_store.js#L152-L153

Solution:
- Updated logic to set quantity and price_unit in the POS order line based on the converted sale order lines after UoM calculations.
https://github.com/odoo/odoo/blob/8f937d4c4a6c4cece698a5e904ba7a0cf2fbb24c/addons/pos_sale/static/src/overrides/models/pos_store.js#L84-L86
- Also updated the value assigning of 'has_valued_move_ids' to converted line
  because quantity calculation is based on 'converted_line'.
https://github.com/odoo/odoo/blob/8f937d4c4a6c4cece698a5e904ba7a0cf2fbb24c/addons/pos_sale/static/src/overrides/models/pos_order_line.js#L50-L53

opw-4900767


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

Forward-Port-Of: odoo/odoo#221123
Forward-Port-Of: odoo/odoo#217734

**Current behavior:**
Modifying the "Product Price" global precision and purchasing some product in a foreign currency sometimes leads to problematic SVL creation, which will make a posted vendor bill unable to be reset to draft when it logically should be permitted.

**Expected behavior:**
No SVL, can reset vendor bill.

**Steps to reproduce:**
1. Activate a foreign currency, set the "Product Price" precision from 2 -> 3, make an exchange rate to the foreign currency with a rate: `0.2710027100271003`

2. Make a product with avg costing, real time valuation, with a standard price = `0.875`

3. Create a purchase order in the foreign currency for the avco product:
* `price_unit: 0.237`
* `product_qty: 5500`

4. Confirm -> receive -> create invoice -> post
* Can't reset the bill to draft
* There is an additional SVL that shouldn't have been generated

**Cause of the issue:**
There will be a negligible rounding diff between the price units of the journal item and SVL created on reception. When the invoice is posted, this will captured and when multiplied by a large enough invoicing qty, will create a large enough value to trigger creation of pdiff SVL.

**Fix:**
Zero out the price unit difference if it is functionally equivalent to zero when rounded according to the maximally precise "precision record" involved in the sequence, that is:

A) The bill currency
B) The SVL currency
C) The "Product Price" global precision value

opw-4873246

Forward-Port-Of: odoo/odoo#221023
Forward-Port-Of: odoo/odoo#217650

Description of the issue/feature this PR addresses:

This commit addresses early submissions of surveys due to timer expiry.
Differences in server/client clocks can leave the survey in an incorrect state.

Current behavior before PR:

The server, seeing a submission come before the time limit that was triggered by the client timer, lets the survey continue.
Clients are receiving error messages when trying to do more submissions, which bump against the cheating prevention.
This is true if the client is "ahead" of the server.
Currently, a difference would only be addressed if above 5 s.
This is not enough as the client being "ahead" by 1 s can cause this issue. This was detected in real use. Looking at server logs has led me to this cause.
Here's a diagram that could help understand the issue with the current behaviour:
<img width="455" alt="Survey Timer bug" src="https://github.com/user-attachments/assets/1804f848-ad4b-4b8a-97fe-7562b76ea66c" />
The above diagram shows how, for a survey with a 30 min timer, a 1 sec difference between the clocks can lead to an early submission.

Desired behavior after PR is merged:

The fix here is to tighten when to apply the time difference to when it is above 500 ms.
This should help avoid the early submission bug but conversely also not allow late submissions, even below 5 s, making the timer fair across users.

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

Forward-Port-Of: odoo/odoo#220431
Forward-Port-Of: odoo/odoo#207485

Versions
--------
- 18.0+

Steps
-----
1. Have a combo product Foo;
2. ensure the combo items have a weight set;
3. enable & publish a shipping connector;
4. add combo product to cart;
5. go to checkout;
6. attempt to select shipping connector as delivery method.

A similar message appears when trying to add a delivery method to a backend order if the order has downpayment lines.

Issue
-----
> The estimated shipping price cannot be computed because the weight is
  missing for the following product(s): Foo

Cause
-----
The combo product doesn't have a weight, as it's not a discrete item, but a collection of multiple items.

The shipping connectors haven't been updated yet to account for this, and still expect every non-service product to have a weight.

Solution
--------
When looking for lines without weight, filter out products of type `combo` (similar to how `service` products are handled) using a new `_get_invalid_delivery_weight_liens` helper method, added to `sale.order.line`.

Also ignore lines where `product_qty` is zero, e.g. `display_type` lines & down payment lines.

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

opw-4940973

Forward-Port-Of: odoo/odoo#221696

Currently, an error occurs if the date is missing when setting a work location via the calendar.

**Steps to reproduce:**
- Install the `hr` module.
- Activate the **Remote Work** feature from the employee settings.
- Open the Calendar (Month view), hover over a date, and click **Set Location** (or location icon).
- Remove the date in the wizard and unfocus the field.

**Error:**
`AttributeError - 'bool' object has no attribute 'strftime'`

This error occurs when the `date` field is `False`, and `_compute_day_week_string` attempts to call `strftime()` on a boolean value - [1].

After addressing the compute function issue, saving the record without a date results in another issue during employee location setup, where `weekday()` is called on a boolean - [2].

[1] - https://github.com/odoo/odoo/blob/e787d0a642bd710a8a80f8abc660c3ff4a385740/addons/hr_homeworking/wizard/homework_location_wizard.py#L25
[2] - https://github.com/odoo/odoo/blob/e787d0a642bd710a8a80f8abc660c3ff4a385740/addons/hr_homeworking/wizard/homework_location_wizard.py#L35

This commit prevent the computation if the `date` field is not set.

Sentry - 6658596690

Forward-Port-Of: odoo/odoo#213308

Problem:
When `s_carousel` is placed inside an `s_table_of_content` and the navbar of the TOC is hidden (visibility set to "Hide" on desktop), saving and reopening the editor results in a traceback.

Cause:
The traceback occurs due to the following sequence: In `WysiwygAdapterComponent.startEdition`, calling `await super.startEdition()` will invoke `createInvisibleElement()` if the navbar is hidden. This, in turn, activates the scroll spy by calling `_activateScrollSpy()` while starting the TOC snippet. That triggers `widgets_start_request`, which starts the `s_carousel` snippet.

However, at this point the `wysiwyg` instance has not yet been attached to the `wrapwrap` element. That happens later, at: https://github.com/odoo/odoo/blob/f12050f75ae9ae1125c0c01ec504a24bd401b1ea/addons/website/static/src/components/wysiwyg_adapter/wysiwyg_adapter.js#L318 and only after the `await super.startEdition()` call at: https://github.com/odoo/odoo/blob/f12050f75ae9ae1125c0c01ec504a24bd401b1ea/addons/website/static/src/components/wysiwyg_adapter/wysiwyg_adapter.js#L232

This delay causes a race condition when starting widgets like `s_carousel` that rely on the presence of the `wysiwyg` instance.

Solution:
Attach the `wysiwyg` instance to the DOM before
`await super.startEdition()` in
`WysiwygAdapterComponent.startEdition`.

Steps to reproduce:
- Add a Table of Content block
- Insert a Carousel inside the content
- Set the TOC navbar visibility to "Hide" on desktop
- Save the page
- Reopen the editor
- A traceback occurs

opw-4971409

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

Forward-Port-Of: odoo/odoo#221200

# How to reproduce the issue

With l10n_es fiscal position:

- Create a bill in a previous period (e.g., amount 1000). Partially credit note this bill for 500.
- Register a partial payment of 250 on this bill.
- In the tax report, go to model 349.

Under the Rectificationes section, the new rectified value will be 250. This is incorrect, as the rectifications in this report should only reflect the value of the original move from a past period after applying the credit note. Payments or other transactions should not impact this report.

This commit adjusts the computation of the report (and the BOE export) to ensure that, instead of using `amount_residual` (which includes payments and other transactions), the report uses the sum of the credit notes linked to the move included in the rectification report.

Also changed the test test_mod349_credit_note. The rectification section is supposed to show the adjusted amount after rectification. In the test a bill of 400 is fully refunded. Instead of 400, the report should show 0.
(https://www.boe.es/buscar/doc.php?id=BOE-A-2010-5098 in TIPO DE REGISTRO 2: REGISTRO DE RECTIFICACIONES. in 153-165 Numérico Base Imponible Rectificada section)

opw-4895636

Forward-Port-Of: odoo/enterprise#91350
Forward-Port-Of: odoo/enterprise#89431

\* = bpost, dhl{,_rest}, easypost, sendcloud, ups, usps{,_rest}

Versions
--------
- 18.0+

Steps
-----
1. Have a combo product Foo;
2. ensure the combo items have a weight set;
3. enable & publish a shipping connector;
4. add combo product to cart;
5. go to checkout;
6. attempt to select shipping connector as delivery method.

A similar message appears when trying to add a delivery method to a backend order if the order has downpayment lines.

Issue
-----
> The estimated shipping price cannot be computed because the weight is missing for the following product(s): Foo

Cause
-----
The combo product doesn't have a weight, as it's not a discrete item, but a collection of multiple items.

The shipping connectors haven't been updated yet to account for this, and still expect every non-service product to have a weight.

Solution
--------
When looking for lines without weight, filter out products of type `combo` (similar to how `service` products are handled) using a new `_get_invalid_delivery_weight_liens` helper method, added to `sale.order.line`.

Also ignore lines where `product_qty` is zero, e.g. `display_type` lines & down payment lines.

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

opw-4940973

Forward-Port-Of: odoo/enterprise#91243

**Problem:**
When trying to make a refund in Mexico, with a gift card in the order, the order should be refunded on said gift card.
But when doing so, two problems arise:
- In the case of a gift card, *line[2].refunded_orderline_id* is not set, so we are trying to read the property of an undefined variable.
- Another problem is that the order can not have any line that have a positive subtotal in the case of a refund. This was not taking the gift cards into accounts, as it makes sense for them to be positive in such a case.

**Steps to reproduce:**
- Set your company to a Mexican company
- Make a purchase for a gift card
- Make another purchase for a random product
- Start the refund process and enter the gift card code we created before
- Try to finalize the purchase, a traceback appears
- If we were not trying to read an undefined variable, the purchase would still not go through as some lines are positive in a refund

**Why the fix:**
When refunding with a gift card, we should refill the gift card by the order's cost instead. With this in mind, it makes sense for the gift card to have a positive price even though we are in the context of a refund, which usually only permits negative priced lines.

opw-4892935

Forward-Port-Of: odoo/enterprise#91385
Forward-Port-Of: odoo/enterprise#89892

**Steps to reproduce:**
1. Install sale_subscription, payment_demo and eCommerce
2. Go to Website → Configuration → Settings and clear the Salesperson field
3. Create a subscription product with recurring plan and publish it.
4. Place an order for this product as a portal user and complete payment.
5. Log back in as admin, open the related Sale Order, and click Preview

**Issue:**
A traceback occurs:-
```"ValueError: Expected singleton: res.users()"```
This happens in _prepare_partner_addresses because user_id is not set on
the Sale Order.

**Cause:**
https://github.com/odoo/enterprise/blob/6b449769d4bf2cdf6517a026706fd6ea55832975/sale_subscription/controllers/portal.py#L233
The code calls has_group on order_sudo.user_id without checking if user_id
exists, leading to an empty recordset and singleton error.

**Solution:**
Add a fallback to handle cases where user_id is not defined, defaulting to False
for multiple_addresses_enabled.

opw-4947508

Forward-Port-Of: odoo/enterprise#91013

**Steps to Reproduce:**
- Install `sale_subscription`.
- Create a product (recurring product) with:
    - Type: Service
    - Invoicing Policy: Prepaid/Fixed Price
- Create a subscription plan Yearly with:
    - Billing Period: 1 year
    - Align to period start: enabled
- Create and confirm a subscription for the product using the Yearly plan.
- Create and confirm the first invoice (shows remaining days like 
    185 days – 06/30/2025 to 12/31/2025 in product description).
- Create and confirm second invoice (check 1 year – 01/01/2026 to 12/31/2026).
- Go back to the subscription and create an upsell.
- Confirm the upsell and generate its invoice.

**Observation:**
- The upsell invoice line shows the wrong duration: 
    1 year (06/30/2025 to 12/31/2026).
- This is incorrect because the expected duration is: 
  185 days (from 06/30/2025 to 12/31/2025) + 1 year (01/01/2026 to 12/31/2026)

**Issue:**
- The duration calculation is based on the ratio of the first date and the end 
  date, but for the Upsell's ratio is always 1, so it considers fix duration, 
  i.e 1 year, 1 month
https://github.com/odoo/enterprise/blob/4bb43da79dba7ac1d0772fde814b3da6bade7db6/sale_subscription/models/sale_order_line.py#L346-L347

**Solution:**
- Corrected the logic to calculate the upsell duration by combining the remaining
  current period (e.g., 185 days) with the standard 1-year period ratio.

Reference PR: https://github.com/odoo/enterprise/pull/68163/commits/cfed2d369960896f0f4d91a90eb24f3641627419
opw-4853426

Forward-Port-Of: odoo/enterprise#91362
Forward-Port-Of: odoo/enterprise#88963