# 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

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

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

When importing a winbooks file the following issues and or inconsistencies may be found

**Issue 1**
We may import an account with CENTRALID 'V03' and code 45100000 Having this centralID means that it will be set as tax payable account id according to https://github.com/odoo/enterprise/blame/d8d4812414dba8825a1c785c29d00f7d0fd98360/account_winbooks_import/wizard/import_wizard.py#L174 However, this means it needs to be a `liability_payable` account with reconcile enable, in order to comply with the following check https://github.com/odoo/odoo/blame/ad6c9001b447f5ffebafe1581512f48708c7d746/addons/account/models/account_tax.py#L80

*Note*
Even if we set it as liability_payable, the import may fail later on in case the same account is used in a sales move where those types of account are not allowed https://github.com/odoo/odoo/blame/1b657cf1e1ce43874a3ede307b2f8ad68216aa56/addons/account/models/account_move_line.py#L1247 A solution is to skip the `_check_payable_receivable` check for winbooks lines

**Issue 2**
Move line data may reference an unkown journal, causing a validation error because no journal is retrieved from the database and a move always need a journal

**Issue 3**
Account created during import may be marked for deprecation, which occurs at the end of the import process.
However, if the account has been used in a tax repartition line, trying to set it as deprecated will raise an error.
https://github.com/odoo/odoo/blame/2cdc41c012f637849ba030989ce928b6b1152e7e/addons/account/models/account_account.py#L1028

opw-4850314

Forward-Port-Of: odoo/enterprise#91581
Forward-Port-Of: odoo/enterprise#89426

## How to reproduce:

https://github.com/user-attachments/assets/bf44f9fd-0402-4d70-8b55-5baf192d42e8


- Enable Consignment
- On Receipt operation type, enable 'Use existing lots'

- Create product P, tracked by lot
- Create lot SN-001 & SN-002
- Add 1 unit on hand with lot SN-001
- Create Receipt for 10 units of P -> Confirm
- Open receipt on Barcode App
- Scan "SN-002" => 'undefined' value added to 'dbQuantCache'
- Scan "SN-001" => Uncaught Promise > quantsByLocation is not iterable (cannot read property undefined)

---

## Test result without fix:
```
2025-07-18 09:30:33,801 20801 ERROR oes_test_18 odoo.addons.stock_barcode.tests.test_barcode_client_action_picking: FAIL: TestPickingBarcodeClientAction.test_barcode_lazy_cache_scan_two_lots
Traceback (most recent call last):
  File "/home/odoo/projects/odoo-src/multiverse/src/18.0/enterprise/stock_barcode/tests/test_barcode_client_action_picking.py", line 3508, in test_barcode_lazy_cache_scan_two_lots
    self.start_tour(url, 'test_barcode_lazy_cache_scan_two_lots', login='admin')
  File "/home/odoo/projects/odoo-src/multiverse/src/18.0/odoo/odoo/tests/common.py", line 2264, in start_tour
    return self.browser_js(url_path=url_path, code=code, ready=ready, timeout=timeout, success_signal="tour succeeded", **kwargs)
  File "/home/odoo/projects/odoo-src/multiverse/src/18.0/odoo/odoo/tests/common.py", line 2235, in browser_js
    self.fail('%s\n\n%s' % (message, error))
AssertionError: The test code "odoo.startTour('test_barcode_lazy_cache_scan_two_lots', {"stepDelay": 0, "keepWatchBrowser": false, "debug": false, "startUrl": "/odoo/147/action-stock_barcode.stock_barcode_picking_client_action", "delayToCheckUndeterminisms": 0})" failed

TypeError: quantsByLocation is not iterable (cannot read property undefined)
    at LazyBarcodeCache.getQuants (http://127.0.0.1:8565/web/assets/3d6bda7/web.assets_web.min.js:21482:279)
    at BarcodePickingModel._processBarcode (http://127.0.0.1:8565/web/assets/3d6bda7/web.assets_web.min.js:21748:631)
    at async http://127.0.0.1:8565/web/assets/3d6bda7/web.assets_web.min.js:21661:75
 
```

OPW-4942192

Forward-Port-Of: odoo/enterprise#91433
Forward-Port-Of: odoo/enterprise#90492

Issue
-----
On iOS 18.5, users can get a `NotSupportedError` when trying to scan a barcode from the (barcode) main menu.

Steps to reproduce
-----
- Open barcode
- Click the center scan button
- Scan a barcode

--> Traceback

Discussion
-----
There are 2 issues occuring here.

1. We play either an ogg or mp3 file. However, the method to know if the format is supported by the browser returns one of 'probably', 'maybe', ''.

https://developer.mozilla.org/en-US/docs/Web/API/HTMLMediaElement/canPlayType#return_value

This means that when we do

https://github.com/odoo/enterprise/blob/70e5013ea022ed04ff27db71ea3ecccb55ae1f70/stock_barcode/static/src/main_menu/main_menu.js#L37

We might end up using ogg even if the browser doesn't actually support it, as 'maybe' is truthy.

To reduce the risk of this happening, we can specify the codec as "vorbis" (all ogg files of Odoo are vorbis). This is already done in mail:

https://github.com/odoo/odoo/blob/cd4c1d599ea9403ce3791e239ad765d946446a47/addons/mail/static/src/core/common/sound_effects_service.js#L46

2. The browser might not have the permission to play the sound. In such cases, the best we can do is try to play the sound and log potential errors.

-----
Ticket:
opw-4820022

Forward-Port-Of: odoo/enterprise#91579
Forward-Port-Of: odoo/enterprise#91158

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

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

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

When printing the delivery slip of a dropship operation using the DIN 5008 layout, the customer's address is correctly displayed, but the VAT of the vendor is shown beneath it.  This is misleading. Actually we do not need vat at all.

**Step to reproduce:**
- Install `l10n_din5008_stock` and `sale_management`
- Go to setting 
    -> configure document layout -> set `DIN 5008` as layout 
    -> enable `dropshipping`
- Create a product, enable Purchase, and select Dropship route.
- Assign Azure Interior as the vendor in purchase tab.
- Create a SO with that product and Deco Addict as customer, confirm it
- Click on purchase smart button, confirm it,  click on dropship smart button
- print delivery slip Observation: Below the customer's address, the vendor's VAT is printed.

**Issue:**
- issue lies in this condition 
- `not (o.picking_type_id.code == 'outgoing' and main_address.id != o.partner_id.commercial_partner_id.id)`
- as `o.picking_type_id.code` is `dropship`
- here, condition evaluates to true, which incorrectly assumes the customer and vendor is same, and prints partner i.e vendor's VAT

**Fix:**
- no need to display vat,so we remove it

<img width="1519" height="244" alt="image" src="https://github.com/user-attachments/assets/d8630fa5-c568-4208-a97e-7e4ceb371109" />


**Before**

<img width="803" height="366" alt="image" src="https://github.com/user-attachments/assets/e2148bb0-7413-4efe-b312-ba7a577e0b62" />

**After**

<img width="615" height="244" alt="image" src="https://github.com/user-attachments/assets/526cfae3-4d8b-4755-b59c-54dfce79526c" />


opw-4929680


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

Forward-Port-Of: odoo/odoo#218757

# Steps to reproduce:

- Configure an early discount payment term (e.g., 2/7 Net 30).
- Configure the analytic distribution model with the account used when a discount is granted (e.g., 657000 on the BE fiscal position).
- Create an invoice using the early discount payment term.
- On bank reconciliation, register the transaction taking into account the early payment discount (e.g., 98% of the invoice amount_total).

On the third line with account 657000, corresponding to the early discount payment, the analytic distribution model does not apply.

In contrast, when manually registering a payment for the invoice, the analytic is correctly applied.

When the bank reconciliation lines are created, _lines_check_apply_early_payment_discount gets its values for the early payment lines from _get_invoice_counterpart_amls_for_early_payment_discount_per_payment_term_line, which does not check if there is an analytic distribution model.

enterprise pr: https://github.com/odoo/enterprise/pull/90641

opw-4868986



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

Forward-Port-Of: odoo/odoo#217933