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

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

**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

**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#219985
Forward-Port-Of: odoo/odoo#217734

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

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

When two timeoff (one with Ignore Public Holidays and the other without) have the same dates, if you modify a public holidays that happend during that time, it will trigger a traceback.

Steps to reproduce:
-------------------
* Marc demo and Abigail Peterson using the same calendar
* Create a "Paid time off" leave for marc demo: June 19 - June 20
* Create a "Extra time off" for abigail: same date
* Update Time off type "Extra Time Off" to "Ignore Public Holidays"
* Approve both leave request previously created
* Create public holidays on June 19 --> traceback

Observation:

When both time off have the same dates it will overide the value in the dictonary
https://github.com/odoo/odoo/commit/0d846ecd1ec7ff5149d580d3494b1a4bab1e68d2#diff-38469def2f870bb866f971f57797dd7c21b6a95d52a8eae72f832f0eea2434f9R464
and when it will try to call the employe_id it will trigger the traceback
https://github.com/odoo/odoo/commit/f72ac3a14d76d4fb53ec3a092d08afafe4c35888#diff-38469def2f870bb866f971f57797dd7c21b6a95d52a8eae72f832f0eea2434f9R561

Why the fix:
------------
Avoid collision between two similar Timeoff

opw-4933820

**Issue**:
Importing a vendor bill from XML may lead to two taxes being applied to the same product if:
- The product exists in the database.
- It matches a product reference in the XML.
- The product has a default service tax (e.g. 22% S).

**Steps to reproduce**:
- Create a product with a service tax (22% S).
- Ensure you have a test XML referencing that product (see tests for an example).
- Go to Accounting > Vendors > Bills.
- Upload the XML file.
- Observe that the product line has two taxes: 22% G (from XML) and 22% S (from product).

**Cause**:
Two taxes are applied because:
- The tax defined in the product: [Line 875 in `account_move_line.py`](https://github.com/odoo/odoo/blob/767341d4ec6aaa4fbd379827da4baf04e561eb32/addons/account/models/account_move_line.py#L875) which is triggered by [L1285C1-L1288C30 in `account_move.py`](https://github.com/odoo/odoo/blob/e705690d2340245a0d18b7e76347575dde9ea2be/addons/l10n_it_edi/models/account_move.py#L1285C1-L1288C30)
- Then, the XML tax is also added: [L1012C1-L1016C44 in `account_move.py`](https://github.com/odoo/odoo/blob/e705690d2340245a0d18b7e76347575dde9ea2be/addons/l10n_it_edi/models/account_move.py#L1012C1-L1016C44)

An attempt to reset the `tax_ids` after setting the product is already present:
  [Line 1319](https://github.com/odoo/odoo/blob/e705690d2340245a0d18b7e76347575dde9ea2be/addons/l10n_it_edi/models/account_move.py#L1319),
but it is ineffective because the original `tax_ids` are re-applied afterward, dues to side effects.

**Solution**:
There are two possible ways to fix this:
- Make sure `move_line.tax_ids = []` works as intended
- Clean the `move_line.tax_ids` recordset.

Chose the second option as it's simpler and avoids modifying unrelated code

**Additional Notes**:
The tax extracted from the XML does not take into account whether the product is a good or a service. For example, if the tax rate is 22%, the logic return taxes[0] if taxes else taxes will always return 22% G, even if the product should be taxed as 22% S.

To solve this, an extra domain filter is added based on the product type to ensure only applicable taxes are considered.

opw-4844469

Forward-Port-Of: odoo/odoo#220261
Forward-Port-Of: odoo/odoo#218309

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

\* = 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

# 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

**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:**
- 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

After this commit https://github.com/odoo/enterprise/commit/40d3314d1b06c8110b476690d2264e86b3492b3e we are not able to cancel a sign request,
if user do not have read/write access on `hr.contract.salary.offer` model

**step to reproduce:**
- install `hr_contract_salary`
- create a new user with following right:
  `Sign        -> Administrator`
  `Contracts   -> Employee Manager`
 `Recruitment -> Interviewer`
- login with test user
- open sign -> All Documents (with demo data 2, there should be 2 documents)
- try to cancel one of them

<img width="1572" height="689" alt="config for user" src="https://github.com/user-attachments/assets/72e89ac7-fed3-4a38-918f-5dbb198bd1e3" />



**Observation:**
- even with Admin rights of Sign, we are not able to cancel a sign request
and we receive a Access Error
`You are not allowed to access 'Salary Package Offer' (hr.contract.salary.offer)
records`

**Fix:**
we use `sudo()` to allow everyone to cancel their sign request


opw-4859774

Forward-Port-Of: odoo/enterprise#89865