In **`balance_pymes_line_32300`** (`CURRENT LIABILITIES > Current payables > Other current payables`), amounts are **doubled** because account **551** is included twice.

* **Formula using `account_codes`:**

  ```xml <field name="formula">-1034 - 1044 - 190 - 192 - 194 - 500 - 501 - 505 ...551 - 5566 - 5595 - 5598 - 560 - 561 - 569</field> ```

  → Explicitly includes account **551**.

* **Formula using `domain`:**

  ```xml <field name="formula" eval="['|', ('account_id.code','=like','550%'), '|', ('account_id.code','=like','551%'), '|', ('account_id.code','=like','554%'), ('account_id.code','=like','5525%')]"/> ```

  → Includes **all accounts starting with 551**, so **551** is also counted here.

This overlap causes the balance to be counted twice, inflating the reported value.

**steps to reproduce:**

1. With a Spanish company, go to **Accounting > Dashboard > Bank > Transaction > New**.
2. Select an account, search for **55100**, and add it.
3. Go to **Reporting > Balance Sheet > Other current payables**.
4. Notice that the reported amount is **double** the actual accounting data.

Overlapping formulas: specific account `551` and `5525` are counted in `account_codes`, while the `domain` formula already includes `551%`, leading to duplication.

**Fix**

Remove explicit account codes from `account_codes` if they are already covered by the `domain` prefixes to avoid double-counting. and also made sure to correct the same issue in the whole report.

opw-5075035

Forward-Port-Of: odoo/enterprise#94494

The system will crash with error when user tries to enable barcode scanner in settings.

**Steps to produce: -**
- Install `Inventory` module.
- `Inventory > configuration > products > Barcode Nomenclatures`.
- Delete the `Default Nomenclature` record.
- Go to settings uncheck `Barcode Scanner` and save settings.
- Now, again `enable` that and save.

Error: -
```py
ValueError: External ID not found in the system: barcodes.default_barcode_nomenclature

ParseError: while parsing /home/odoo/src/enterprise/saas-18.4/stock_barcode/data/data.xml:40, somewhere inside <record id='scale_up_alias_1' model='barcode.rule'>
            <field name='name'>Scale Up Receipt</field>
            <field name='type'>alias</field>
            <field name='pattern'>WH-RECEIPTS</field>
            <field name='alias'>WHIN</field>
            <field name='barcode_nomenclature_id' ref='barcodes.default_barcode_nomenclature'/>
            <field name='sequence'>0</field>
        </record>
```

**Root cause: -**
- At [1], the records use the ref of `default_barcode_nomenclature` which is defined in barcode module. So, when the ref is deleted and we are trying to use it then it gives error.

**Solution: -**
- This commit resolves the error by prevent the deletion of `default nomenclature`.

[1]: https://github.com/odoo/enterprise/blob/400171c9cebc46ecdd907ada210c65f3bbd2dd66/stock_barcode/data/data.xml#L40-L71

**sentry-6823596992**

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

Forward-Port-Of: odoo/odoo#226594

Steps to reproduce:
-----------------
1. Go to Timesheet → My Timesheet → List View → New OR Edit already filled time.
2. Change time in the Time Spent field.
3. Press Shift + Tab.

Observation:
-----------------
The focus changes, but the Time Spent field reverts to its old value instead of keeping the newly entered one.

Issue:
-----------------
- For new records, the component retrieves the value only from the state, which
is updated in the `onWillUpdateProps` lifecycle. This lifecycle triggers only on
saving or editing, not when simply changing focus.
https://github.com/odoo/enterprise/blob/e14b991927df14f41535e92dd01ea2ecac44a404/timesheet_grid/static/src/components/timesheet_display_timer/timesheet_display_timer.js#L123-L128

-  The same behavior occurs when editing existing records, leading to incorrect
value display.
https://github.com/odoo/enterprise/blob/e14b991927df14f41535e92dd01ea2ecac44a404/timesheet_grid/static/src/components/timesheet_display_timer/timesheet_display_timer.js#L31-L33

Solution:
-----------------
-  For new records, since the default value is 0, the fix makes the component
fall back to the updated record value if the state value is not yet available.

-  For existing records, if the timer is running, the timer’s value is
displayed. otherwise, the component falls back to the updated record value.


opw-4922847

Forward-Port-Of: odoo/enterprise#95141
Forward-Port-Of: odoo/enterprise#94729

- Create an invoice with some products and post it
- Go to Accounting > Journal items and ser for the ones belonging to the invoice.
- Set the checkbox for the product sales one and set whatever tax grid (you'll have to reveal that column).
- Accept the changes.
- Now go back to the invoice.
- You'll see a new tracking message. Something like

Journal Item #1093 updated

- It contains a link and from that link you can go to the journal item form.
- In that form you can edit the *amount in currency* field.

Issue:

- If a user do so, it leaves inconsistent invoice amounts: totals aren't recomputed, analytic lines aren't recomputed either.

How it should behave:

- Amount in currency shouldn't be editable here. Mainly when the journal entry is already posted!

opw-4951629

A vídeo showing the issue:
📹️ https://www.loom.com/share/f7cd1d8f4138458f9b6c190233b0b9df?sid=eec77c17-a4a6-4698-8604-10aaa7e33f47

MT-10887 cc @moduon

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

Forward-Port-Of: odoo/odoo#225346
Forward-Port-Of: odoo/odoo#223187

### Steps to reproduce:
	- Open Field Service module.
	- Create a new task. In the Customer field, select “Bloem GmbH”.
	- Open the task’s project.
	- In the Invoicing tab, create a new line for any employee and any service.
	- Return to the task and in the Timesheets tab, add a new timesheet.
	- Click the Mark as done button.
	- Click the Sales order button.

### Cause:
When creating the sale order out of the fsm task we use _get_tax_included_unit_price to get the price of the SO line but we are passing the order currency twice to this method so it doesn't convert the price as when it checks the currency and the product_currency it found they are the same so no need to convert

https://github.com/odoo/odoo/blob/6653355b8bc063ceadf08af17fbf2c4a250553e6/addons/account/models/product.py#L239-L240

### Fix:
We pass the product currency instead of the order currency in order to be able to convert the price according to the currencies

opw-5045071

Forward-Port-Of: odoo/enterprise#95134
Forward-Port-Of: odoo/enterprise#94947

to reproduce:
=============
1. make helpdesk team billable and records timesheets
2. create a helpdesk ticket and link it to a sale order
3. log timesheets on the ticket
4. print the timesheet report **from the sale order** -> the task column will contain only the helpdesk team name, while it should contain "helpdesk team / ticket name"

Problem:
========
in helpdesk_timesheet we inherit `hr_timesheet.timesheet_table` to adapt it to helpdesk tickets, but we use `show_ticket` to display the ticket name, which is only set in `hr_timesheet.report_timesheet` and `hr_timesheet.timesheet_project_task_page` but not in `sale_timesheet.timesheet_sale_page` which is the one used when printing the report from the sale order.

Solution:
=========
`show_ticket` should be set with value `bool(lines.helpdesk_ticket_id)` which is equivalent to `line.helpdesk_ticket_id` in the t-if condition. so we can directly use `line.helpdesk_ticket_id` and remove the `show_ticket` variable.

opw-5002650

Forward-Port-Of: odoo/enterprise#95179

**Steps to reproduce:**
1. Install `l10n_mx` and `l10n_mx_edi`.
2. Create an invoice with:
   * Enable *CFDI to Public*.
   * Confirm, then send to SAT.
3. Create a credit note with:
   * *Usage* = `Returns, discounts or bonuses` (G02).
4. Download the generated XML for the credit note.

**Observed behavior:**
- The `<UsoCFDI>` tag in the XML shows `S01` (No fiscal effects).

**Expected behavior:**
- The `<UsoCFDI>` tag should show `G02` for credit notes under regime 616 when explicitly selected.

**Root cause:**
- For regime 616 (`Público en general`), the code always defaults to `S01`.
- The condition only allowed `G02` when refunding a global invoice (`is_refund_gi`), not for normal credit notes.

**Solution:**
- Allow `G02` usage to be preserved for credit notes (tipo_de_comprobante = 'E') even when `CFDI to public` is active, as this is now permitted by SAT regulations for fiscal regime 616.

**ref:**
http://omawww.sat.gob.mx/tramitesyservicios/Paginas/documentos/catCFDI_V_4_20250820.xls

opw-5012917

Forward-Port-Of: odoo/enterprise#93071

Description of the issue/feature this PR addresses:
This PR addresses a KeyError that occurs when attempting to generate a PDF quotation for multiple sales orders at once in Odoo. The issue arises when one or more selected orders do not have a valid PDF stream (e.g., due to missing data like order lines or incorrect templates). The error occurs because the system tries to access result[order.id]['stream'] for a sales order that doesn't have the stream generated, causing the server to fail.

Current behavior before PR:
Before this PR, when attempting to print the quotation for multiple sales orders, the system will throw a KeyError if any of the selected orders do not have a valid PDF stream generated. This can happen if a sales order is missing data (such as products or a client) or has an incomplete quotation template. The error prevents users from generating quotations for a group of sales orders, even if only one order is missing the necessary data.

Desired behavior after PR is merged:
After merging this PR, the system will check if the PDF stream exists before attempting to access it. If a sales order does not have a valid stream (due to missing data or other issues), it will be skipped without causing a server error. This allows users to print multiple quotations at once without the system failing due to one incomplete order. The feature will improve robustness when handling orders with missing or incomplete data and prevent unexpected crashes.



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

Forward-Port-Of: odoo/odoo#227517
Forward-Port-Of: odoo/odoo#227347

Scenario:
- go to /shop
- increase zoom to 175% (or decrease height of window)
- search "a" and let the suggestions dropdown open

Result: the dropdwon menu is shown on top of the search bar, where there
is the less space available.

Cause:

When the dropdown doesn't fit fully in the viewport below the searchbar
it is always added on top even if there is less space available.

The code was added in 15.0 62c265ee7d7cf36db01bf6a95b2c5ea9843ba2d3 with
the intent of putting the dropdown on the top if it increased the page
height when putting it below (eg. when we put a search bar in the
footer).

But in saas-18.2 refactoring (b9b3a605e0f4c5da3a258c980107d6162da7f44f),
the code was rewritten and now:

- the dropdown has a scroll bar if it is too big to fit on viewport

- if the dropdown doesn't fit fully below the searchbar in the viewport,
  it is placed above the searchbar even if there is less space

Fix: place the dropdown below the searchbar if there is more space below
than above.

opw-5019685

Forward-Port-Of: odoo/odoo#225220

currently an error occur when user proceed except expired delivery.

Steps to Reproduce:

 - Install the `product_expiry` module.
 - Create a product with the configuration:
   - In `Track Inventory`, select `By Lots`.
   - In the `Inventory tab`, check `Expiration Date`.
 - In the newly created product, click `Lot/Serial Numbers` button, create a new `Lot/Serial Number`, and clear the `Removal Date` of that Lot/Serial Number.
 - Go back to the newly created product and update the `Quantity On Hand` of the linked `Lot/Serial Number` by clicking `Update`.
 - Now go to `deliveries` and create a new `delivery` and add the newly created product and `validate` > `Proceed except expired`.

`TypeError: '<' not supported between instances of 'bool' and 'datetime.datetime'`

This error occurs when user proceed except expired delivery, The removal_date of the move line is computed based on the lot's removal date and the move line's expiration date. If the lot does not have a removal date and the move line also does not have an expiration date, then removal_date on the move line is set to False [1], which raises the error here [2]

This commit ensures that it only compares with the move line removal_date if it is present.

[1]- https://github.com/odoo/odoo/blob/70a7babcc830f72bd069a5bb1504748363e4e848/addons/product_expiry/models/stock_move_line.py#L56

[2]-https://github.com/odoo/odoo/blob/70a7babcc830f72bd069a5bb1504748363e4e848/addons/product_expiry/wizard/confirm_expiry.py#L48

sentry-6864176071

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

\* = website_event_booth_exhibitor, website_event_booth_sale_exhibitor, website_sale_collect

**Issue:**
1. Several tours across multiple modules were failing on runbot because
some steps triggered a page reload or redirect without using
`expectUnloadPage: true`, which caused those steps to fail.
2. In the `webooth_exhibitor_register` tour, the behavior of the last
step before calling the `_getSteps` function differs depending on the
installed modules:
- With only `website_event_booth_exhibitor` installed, the last step
does not trigger a page reload.
- With `website_event_booth_sale_exhibitor` also installed, the same
step triggers a redirect to the checkout page, which caused the tour to
fail.

**Fix:**
1. Added `expectUnloadPage: true` to steps that trigger a
reload/redirect, so the tour now waits for the new page to load before
continuing.
2. Updated `_getSteps` in both modules:
- Moved the problematic step of the `webooth_exhibitor_register` tour
inside `_getSteps`.
- In `website_event_booth_sale_exhibitor`, the same step was updated
with `expectUnloadPage: true` to correctly handle the checkout
redirection during the payment flow.

runbot-[231586](https://runbot.odoo.com/odoo/error/231586)





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

…ay change

**Steps to reproduce**
- Create a public holiday without a calendar during a work day.
- Create a leave for an employee overlapping the public holiday
for a time off type generating Timesheets. Validate it.
- Expected: on the day of the public holiday, no timesheet is
generated for the `hr.leave` to avoid duplication.
- Either delete the public holiday, or set a calendar on it
different than the one defined on the employee.

- Issue: the public holiday timesheet has been deleted, but its
deletion should've lead to the creation of the `hr.leave` timesheet
that we didn't create at the time the public holiday existed.

- Second issue: after that, change the calendar of the public holiday
to the same as the employee's. Still a missing timesheet.

**Solution**
We can use `_reevaluate_leaves` to find the leaves affected by changes
in public holidays.
`_generate_timesheets` then re-generates the timesheets as if the leave
was just validated (the call to `list_work_time_per_day` ignores the
already present resource.calendar.leave).
We also check missing public holidays timesheets to fix the second issue.

opw-4819697

Forward-Port-Of: odoo/odoo#227299
Forward-Port-Of: odoo/odoo#216901

### [FIX] html_builder, website: pass `isPreviewing` to action with colors

With the commit 4448303436fd2d5afe235263e13a9d5daa2d14e1, the `apply`
method of actions should receive an argument `isPreviewing`. This has
not been done for `BuilderColorPicker`.

This commit adds the argument `isPreviewing` when calling `apply` in
`BuilderColoPicker`.

task-4367641

### [FIX] html_builder, *: make options with BuilderMany2One previewable

*: web, website

With the initial [website builder refactor], the options based on
`BuilderMany2One` were not previewable (they were in the previous
builder).

This commit brings back that behaviour. To do so it adds props to
`SelectMenu` and options to `Navigator` to receive the information
needed for the preview

Steps to reproduce:
- On `/blog`, open website builder
- Click on the author of a blog post
- In the sidebar, click on "Contact" to open the dropdown
- Hover other authors than the current one
- Bug: the hovered author is not previewed in the dom
  (like in was in the previous builder)

[website builder refactor]: 9fe45e2b7ddbbfd0445ffe25a859e67a316d02b2
task-4367641