Issue before this commit:
=========================
For products tracked by serial/lot with packaging units, the delivery slip correctly shows the packaging unit and quantity before validating the transfer. However, after validating the transfer, the packaging unit and its corresponding quantity are no longer displayed in the delivery slip report.

Steps to Reproduce:
=========================
1. Install stock and sale_management modules.
2. Enable Units of Measure & Packagings and Display Lots & Serial Numbers on Delivery Slips from settings.
3. Create a product with tracking by lot/serial number and configure a packaging unit.
4. Create a SO using this product with a packaging unit and confirm it.
5. Open the related transfer and print the delivery slip before and after validation.

Cause of the Issue:
=========================
The delivery slip report template (stock_report_delivery_has_serial_move_line) does not display packaging unit information after validation for move lines when the packaging unit differs from the product unit of measure.

With This Commit:
=========================
This commit ensures that packaging units and their corresponding quantities are displayed on the delivery slip after validation when the packaging unit differs from the product unit of measure.

Steps To Reporduce: [Video Link](https://drive.google.com/file/d/10DmFKW1Y_Tm-AyKzPrqtFMY8orBkKbIm/view?usp=sharing)

opw-6142052

Forward-Port-Of: odoo/odoo#264235
Forward-Port-Of: odoo/odoo#262722

**Problem:**
The "Custom Dates" and "Specific Date" comparison options are missing from the Comparison dropdown in accounting reports.

**Steps to reproduce:**
1. Go to Accounting > Reporting > Profit & Loss
2. Click the Comparison dropdown
3. Only "No Comparison", "Previous Period", and "Same Period Last Year" are visible — "Custom Dates" is missing

**Current behavior:**
Custom date comparison options are not rendered.

**Expected behavior:**
"Custom Dates" (for range reports) and "Specific Date" (for single date reports) should appear in the Comparison dropdown.

**Cause of the issue:**
The date filter refactor (40484f985f5) restructured how the date mode is stored in options. Previously, `options.date.mode` held 'range' or 'single'. After the refactor, this key no longer exists — the mode is now stored as a boolean in `options.filter_date.range_mode`.

The comparison filter template still checks
`controller.cachedFilterOptions.date.mode`, which is now undefined, so both the range and single conditions always evaluate to false and the custom comparison options are never rendered.

**Fix:**
The comparison template was the only consumer not updated during the refactor. Aligning it to the new data path restores the options without any behavioral change.

opw-6070402

Forward-Port-Of: odoo/enterprise#113391

**[FIX] base: avoid evaluating true domains when validating domain**
During validating, the domain validation may trigger a search on the comodel to ensure the domain is valid.

After [1], the validation still performs the search with Domain True [here] because it ``search_domain`` is override because of
[comodel_domain] is False with ``Domain.True`` to handle this checking if already ``search_domain`` is False or not

```py
Traceback (most recent call last):
  File "/home/odoo/src/odoo/saas-19.3/odoo/service/server.py", line 1643, in preload_registries
    registry = Registry.new(dbname, update_module=update_module, install_modules=config['init'], upgrade_modules=config['update'], reinit_modules=config['reinit'])
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/src/odoo/saas-19.3/odoo/tools/func.py", line 67, in locked
    return func(inst, *args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/src/odoo/saas-19.3/odoo/orm/registry.py", line 224, in new
    load_modules(
  File "/home/odoo/src/odoo/saas-19.3/odoo/modules/loading.py", line 467, in load_modules
    load_module_graph(
  File "/home/odoo/src/odoo/saas-19.3/odoo/modules/loading.py", line 222, in load_module_graph
    load_data(env, idref, mode, kind='data', package=package)
  File "/home/odoo/src/odoo/saas-19.3/odoo/modules/loading.py", line 61, in load_data
    convert_file(env, package.name, filename, idref, mode, noupdate=kind == 'demo')
  File "/home/odoo/src/odoo/saas-19.3/odoo/tools/convert.py", line 716, in convert_file
    convert_xml_import(env, module, fp, idref, mode, noupdate)
  File "/home/odoo/src/odoo/saas-19.3/odoo/tools/convert.py", line 815, in convert_xml_import
    obj.parse(doc.getroot())
  File "/home/odoo/src/odoo/saas-19.3/odoo/tools/convert.py", line 686, in parse
    self._tag_root(de)
  File "/home/odoo/src/odoo/saas-19.3/odoo/tools/convert.py", line 639, in _tag_root
    raise ParseError(msg) from None  # Restart with "--log-handler odoo.tools.convert:DEBUG" for complete traceback
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
odoo.tools.convert.ParseError: while parsing /home/odoo/src/enterprise/saas-19.3/ai/security/security.xml:4
Invalid domain ['|', ('attachment_id.public', '=', True), ('attachment_id.res_access_read', '=', True)]: Cannot search, too many attachments

View error context:
'-no context-'
```

[here]: https://github.com/odoo/odoo/blob/4561e703128963d566a16ab1356c7ef12e44256a/odoo/addons/base/models/ir_attachment.py#L643
[1]: https://github.com/odoo/odoo/pull/260753
[comodel_domain]: https://github.com/odoo/odoo/blame/afca863b750ec58f5414a5d47e2e2a64e3eba598/odoo/orm/domains.py#L1440-L1442

**[FIX] base, mail: Fix UserError checking field desciption**
during opening menu if field is comodel with ``ir.attachment`` it do fail on checking description  field is groupable while
``res_access_read`` search do call because big database can have more attachment. So it will equal with search limit which is used.

To fix,

Value error is raised to prevent blocking

```py
41239-   File "/tmp/tmpci4qg_2w/migrations/base/tests/test_mock_crawl.py", line 344, in crawl_menu
41240-    self.mock_action(action_vals)
41241-   File "/tmp/tmpci4qg_2w/migrations/base/tests/test_mock_crawl.py", line 357, in mock_action
41242-    return self.mock_act_window(action)
41243-           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
41244-   File "/tmp/tmpci4qg_2w/migrations/base/tests/test_mock_crawl.py", line 441, in mock_act_window
41245-    views = get_views(
41246-            ^^^^^^^^^^
41247-   File "/home/odoo/src/odoo/saas-19.3/addons/mail/models/mail_thread.py", line 489, in get_views
41248-    res = super().get_views(views, options)
41249-          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
41255-           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
41256-   File "/home/odoo/src/odoo/saas-19.3/odoo/addons/base/models/ir_ui_view.py", line 2947, in get_views
41257-    result['models'][model] = {"fields": self.env[model].fields_get(
41258-                                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^
41259-   File "/home/odoo/src/enterprise/saas-19.3/web_studio/models/ir_model.py", line 77, in fields_get
41260-    return super().fields_get(allfields, attributes=attributes)
41261-           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
41262-   File "/home/odoo/src/odoo/saas-19.3/odoo/orm/models.py", line 2637, in fields_get
41263:    description = field.get_description(self.env, attributes=attributes)
41264-                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
41265:   File "/home/odoo/src/odoo/saas-19.3/odoo/orm/fields.py", line 933, in get_description
41266-    value = value(env)
41267-            ^^^^^^^^^^
41268-   File "/home/odoo/src/odoo/saas-19.3/odoo/orm/fields.py", line 989, in _description_groupable
41269-    model._read_group_groupby(Query(model).table, groupby)
41270-   File "/home/odoo/src/odoo/saas-19.3/addons/analytic/models/analytic_mixin.py", line 145, in _read_group_groupby
41271-    return super()._read_group_groupby(table, groupby_spec)
41272-           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
41273-   File "/home/odoo/src/odoo/saas-19.3/odoo/orm/models.py", line 2080, in _read_group_groupby
41274-    sql_expr = field.join(table, only_ids=True).id
41275-               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
41276-   File "/home/odoo/src/odoo/saas-19.3/odoo/orm/fields_relational.py", line 1773, in join
41277-    coquery = comodel._search(codomain, bypass_access=self.bypass_search_access)
41278-              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
41279-   File "/home/odoo/src/odoo/saas-19.3/odoo/orm/models.py", line 4778, in _search
41280-    sec_domain = sec_domain.optimize_full(self_sudo)
41281-                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

41305-   File "/home/odoo/src/odoo/saas-19.3/odoo/orm/domains.py", line 484, in _optimize
41306-    previous, domain = domain, domain._optimize_step(model, next_level)
41332-           ^^^^^^^^^^^^^^^^^^^^^^
41333-   File "/home/odoo/src/odoo/saas-19.3/odoo/addons/base/models/ir_attachment.py", line 478, in <lambda>
41334-    search=lambda self, operator, value: self._search_res_access('read', operator),
41335-                                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
41336-   File "/home/odoo/src/odoo/saas-19.3/odoo/addons/base/models/ir_attachment.py", line 645, in _search_res_access
41337-    raise UserError(self.env._("Cannot search, too many attachments"))
41338- odoo.exceptions.UserError: Cannot search, too many attachments

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

Currently an error occurs when user tries to give feedback on livechat that has a chatbot.

Steps to replicate:
- Install `im_livechat` with demo.
- Open Livechat > On Support Bot, Click `Configure Channel` from Kebab menu (3 dots menu).
- Go to Widget page > Copy the support link (bottom one) > and open it in an incognito tab.
- Open the chat > chat atleast once > Close the chat.
- Click on any of the smileys (i.e. give feedback) and click send.
- The error will occur on the terminal.

Error:
```
File '/home/odoo/src/odoo/saas-19.3/addons/mail/tools/discuss.py', line 228, in __init__
    assert bus_channel or not (notification_payload or notification_type), (
AssertionError: Notification parameters only make sense when a bus channel is passed.
```

Cause:
- As the livechat was managed by chatbot, it has no `livechat_agent_partner_ids` linked. This causes `rated_partner` [1] to be an empty recordset.
- So when initializing the Store [2] `rated_partner.sudo().user_ids` becomes an empty recordset. This causes the error to occur as the assertion fails [3] as the `bus_channel` is an empty recordset.

Solution:
- Updated the assertion to keep the behavior similar to the `bus_send()` method.

[1]: https://github.com/odoo/odoo/blob/2b486f35235974584b3434c2ca93297db802ae81/addons/im_livechat/models/discuss_channel.py#L740
[2]: https://github.com/odoo/odoo/blob/2b486f35235974584b3434c2ca93297db802ae81/addons/im_livechat/models/discuss_channel.py#L760-L770
[3]: https://github.com/odoo/odoo/blob/2b486f35235974584b3434c2ca93297db802ae81/addons/mail/tools/discuss.py#L228-L230

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

Currently an error is generated when the user tries to choose theme during
configure the website after set the logo of the company.

Steps to produce an error
- Initilalize DB and set Logo (e.g. [1])
- Install a website and build a website with click `Let's do it`
  and all input your choice
- The error occurs when finally choosing the theme

Error:`UnicodeDecodeError:
'utf-8' codec can't decode byte 0x89 in position 0: invalid start byte'`

This issue occurs because assigning the existing company logo using
`company.logo` returns a `LocalBinaryFile` object instead of raw bytes
after the recent refactor changes with [2]. Attempting to decode this
`LocalBinaryFile` object causes the error.

This commit fix the above issue by using `BinaryBytes(company.logo.content)`,
which returns the expected raw bytes required to set the website logo
from the company logo.

[1]: https://odoocdn.com/openerp_website/static/src/img/assets/png/odoo_logo.png
[2]: https://github.com/odoo/odoo/commit/41fe2ebdb9cc37341362d7af829c087a5f72f9f1

Sentry- 7475955377

Event tickets show a struck-through original price even when a "Fixed Price" pricelist rule is applied, making it incorrectly appear as a discount. This is inconsistent with eCommerce shop behavior.

### Steps to reproduce

1. Create an event with a paid ticket (e.g., 100 EUR).
2. Create a pricelist with a "Fixed Price" rule for that ticket (e.g., 80 EUR).
3. Open the event registration page.
4. The 100 EUR appears struck-through next to 80 EUR.

### Cause

Odoo's website only shows a struck-through original price for discount rules, not fixed price rules. By design, a fixed price replaces the original rather than reducing it. However, the event registration page used a simplified check: it compared the final price to the original and assumed any difference was a discount. This ignored the rule type, incorrectly flagging fixed price rules as discounts.

### Fix Rationale

A new helper method on the event ticket model now queries the applied pricelist rule to determine if it qualifies as a discount.

opw-5993477

Forward-Port-Of: odoo/odoo#264470
Forward-Port-Of: odoo/odoo#263586

Issue:
When a user takes a survey and loses their internet connection just as the form attempts to submit (e.g., during a timed survey's auto-submit), the survey becomes completely unresponsive. Even if the user reconnects, they are unable to submit their answers.

Steps to reproduce:
1. Start a survey that includes a time limit.
2. Disconnect your device from the internet just before the timer runs out.
3. Wait for the timer to reach zero, triggering the auto-submit.
4. Reconnect to the internet and attempt to click "Submit" manually.
5. The action is ignored and the form remains stuck.

Cause:
To prevent duplicate submissions, the form applies a "submitting" lock the moment a submission begins. If a network failure interrupts the process, the code execution halts abruptly. Because the process crashes before reaching the end of its routine, the lock is never removed, leaving the form permanently frozen.

Solution:
Guarantee that the submission lock is released regardless of the network request's outcome. By safely wrapping the submission sequence, the form will now always unlock itself even if an error interrupts the process. This allows the user to simply try submitting again once their connection is restored, while still letting the system report the initial network failure.

Task-5787410

Forward-Port-Of: odoo/odoo#249514

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/fece642d7c [REL] 19.2.13 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/5117146ce2 [FIX] color_picker: prevent gradient from opening when picking a custom color [Task: 6186050](https://www.odoo.com/odoo/2328/tasks/6186050)
https://github.com/odoo/o-spreadsheet/commit/0f6ba0d72e [IMP] packages: rolldown is released in 1.0.0 [](https://www.odoo.com/odoo/2328/tasks/)
https://github.com/odoo/o-spreadsheet/commit/5282e3c377 [REL] 19.2.12 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/dfb655d7b9 [FIX] packages: update odoo dependencies [](https://www.odoo.com/odoo/2328/tasks/)
https://github.com/odoo/o-spreadsheet/commit/5231677171 [FIX] package: package install is broken [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)

Co-authored-by: Florian Damhaut (flda) <flda@odoo.com>
Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com>
Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com>
Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com>
Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com>
Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com>
Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com>
Co-authored-by: Rémi Rahir (rar) <rar@odoo.com>
Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com>
Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>

## Issue
When generating a payslip for an employee of a company located in Colorado, the *CO State Income Tax* could end up positive.

## Steps to reproduce
1. Install *United States - Payroll* (`l10n_us_hr_payroll`)
2. Set the current company's State to Colorado
3. Create an employee and a contract
    - Wage: $0
    - (Set the contract's status to *Running*)
    - (In the payroll tab) State Withholding Allowance: $1000
4. Create a Payslip for the employee
    - Structure: *"United States: Regular Pay"*
5. Compute Sheet
6. **In the _Salary Computation_ tab, the _CO State Income Tax_ line has a positive value**

## Justification
This fix is similar to the one applied for the AL(abama) state income tax by https://github.com/odoo/enterprise/commit/f0eeb55f1e3cf965c6a409675813d4a699e5fca6. That modification was justified by CAS (PO of US localizations for Payroll) in opw-5137280:

> *"Payroll taxes are always funds withheld from employee's paychecks, if there is a positive value it means the tax is a refund, not a withholding. Refunds happen when individuals file their income."*

## Note to reviewer
The test [`test_069_al_state_tax_0_income`](https://github.com/odoo/enterprise/blob/219d2a797ee2099c9d77c2defc9c9c5e1d504ffe/test_l10n_us_hr_payroll_account/tests/test_salary_rules.py#L957-L989) (added by the aforementioned commit https://github.com/odoo/enterprise/commit/f0eeb55f1e3cf965c6a409675813d4a699e5fca6) is wrongly indented and thus never executed. The test passes with the dedicated fix, and fails without it, as expected. Let me know if you want me to indent it correctly (in this commit or in an additional one).



opw-5999856

Forward-Port-Of: odoo/enterprise#116831
Forward-Port-Of: odoo/enterprise#112724

**Steps to reproduce:**
1. Create user with role: User. Sales: Administrator, Accounting: Administrator and Documents: System Administrator.
2. Create a SO, create invoice, confirm, and send.
3. Now go back to the SO, and try to link the INV document to the chatter.

**Cause:**
When linking an existing document to the composer, the underlying attachment is copied. If the source attachment is bound to a specific field (e.g., `res_field = 'invoice_pdf_report_file'`), the `copy()` operation duplicates this field reference. Odoo's native security checks then attempt to verify access to that specific field on the target model (`mail.compose.message`). Because the composer does not have this field, the check fails and throws an AccessError, even if the user has full rights to the source document.

**Solution:**
Explicitly set `"res_field": False` during the copy operation. This strips the original field binding, cleanly converting the file into a standard, generic chatter attachment for the composer without bypassing the standard security framework.

opw-5916364

Forward-Port-Of: odoo/enterprise#107723

__

## Short functional explanation of the error
When we create 2 shifts for the same day for an employee, on a non-working day for their schedule. When trying to create the second one after setting the end date to midnight, we get the error:
`ValueError: Expected singleton: hr.attendance.overtime.line(2, 3)`

## Reproduction Steps
1. Create an Employee. In the Payroll tab, Make sure they have an active contract. Set their Working Hours to a fixed schedule, where they have saturdays as non-working days. In the Settings tab, set an Overtime Ruleset.
2. Click on the overtime ruleset. Then, for each rule, under Action, set the Work Entry Type To Use as Overtime Hours.
3. Go to Attendances. In Configuration > Settings, under Extra Hours, set the Extra Hours Validation as Approved By Manager.
4. Create an attendance for your Employee on a Saturday, from 12h to 18h.
5. Create a second attendance for your Employee on that same Saturday, from 18h to 00h00. Try to Save.
Note: the timezone of your computer, the working schedule and the employee should be set at Brussels time. 

### Expected behavior
The Overtime is registered.

### Unexpected behavior
An error occurs:
`ValueError: Expected singleton: hr.attendance.overtime.line(2, 3)`

## Origin of the issue
The end time of the overtime is defined as follows: https://github.com/odoo/enterprise/blob/47faff7d6c9da5572e3bad3ff5a55b40c2ba81ac/hr_work_entry_attendance/models/hr_version.py#L54-L56 However, in the case where our shift ends after the computed end of the day (in our case, the end time of the shift is 00:00:00 and the end of the day is set at 23:59:59), it creates some problems. The end time of the overtime is set 1 second too early. Later we compute the start time of the overtime as follows: https://github.com/odoo/enterprise/blob/47faff7d6c9da5572e3bad3ff5a55b40c2ba81ac/hr_work_entry_attendance/models/hr_version.py#L57 Thus, the time start of the overtime is also set one second too early. As our second shift starts right after the first one, after the execution of this code, we will get a second shift that starts before the end of the first one.
Then, we add these values in a list:
https://github.com/odoo/enterprise/blob/47faff7d6c9da5572e3bad3ff5a55b40c2ba81ac/hr_work_entry_attendance/models/hr_version.py#L59 which will contain overlapping timeframes, and with which we create an Interval:
https://github.com/odoo/enterprise/blob/47faff7d6c9da5572e3bad3ff5a55b40c2ba81ac/hr_work_entry_attendance/models/hr_version.py#L60 But when we create an Interval with overlapping timeframes, we obtain only one interval as the timeframes are merged.
https://github.com/odoo/enterprise/blob/47faff7d6c9da5572e3bad3ff5a55b40c2ba81ac/hr_work_entry_attendance/models/hr_version.py#L173 As a result, `overtime_intervals` will contain only one time frame with 2 different corresponding overtimes, which causes a singleton error when reaching:
https://github.com/odoo/enterprise/blob/47faff7d6c9da5572e3bad3ff5a55b40c2ba81ac/hr_work_entry_attendance/models/hr_version.py#L179 __
opw-6096454

Forward-Port-Of: odoo/enterprise#117094
Forward-Port-Of: odoo/enterprise#114147

**Steps to reproduce:**
* Install the *Accounting* module with French localization (*l10n_fr_account*).
* Create a *Sales Tax* with:
  * A new tax group (e.g., 'Codifab').
  * Enable *Affect Base of Subsequent Taxes*.
* Create a *Sales Order*:
  * Add the first tax (with *Affect Base of Subsequent Taxes*).
  * Then add the second tax (eg VAT tax).
* Confirm the *Sales Order*.
* Create a *Down Payment Invoice* (percentage-based).
* Open the generated invoice and:
  * Remove the first tax (the one affecting the base).

**Observed behavior:**
* The amount of the second tax group does not update after removing the first tax, leading to incorrect tax computation.

**Cause:**
* In `_import_base_line_extra_tax_data`, the condition: `all(str(tax.id) in extra_tax_data['manual_tax_amounts'] for tax in sorted_taxes)` only ensured partial matching of taxes.
* This allowed reuse of stale `manual_tax_amounts` when taxes were removed or modified, causing incorrect base values for dependent taxes (e.g., *Affect Base of Subsequent Taxes*).

**Fix:**
* Update the condition to enforce an exact match between current taxes and cached `manual_tax_amounts` by checking both size and membership.
* Prevent reuse of outdated tax data when taxes change, ensuring proper recomputation of dependent taxes.
* Align Python logic with the JS implementation for consistency between `account_tax.py` and `account_tax.js`.

opw-6063970

Forward-Port-Of: odoo/odoo#264434
Forward-Port-Of: odoo/odoo#259566

__
## Short functional explanation of the error
When we set the departure of an employee. The version is retrieved using the dismissal date. However, employees can work after their dismissal date, until their departure (in the case of a notice, for example). Therefore, the departure date should be chosen instead.

## Reproduction Steps
1. Go to Employees and create a new employee. In the Payroll tab, set a start date for their contract. Hit save.
2. This will create a version. You can see it top right, with the contract date. Click on the '+' next to it and set a date later.
3. Click on the cog in the top left and click End of Collaboration. Set an End Reason. Set the Dismissal Date to occur during the first version and the Departure Date to occur during the second version. Then, click Schedule.

### Expected behavior
The Departure tab should appear when clicking on the second version, top right.

### Unexpected behavior
The departure tab appears on the first version.

## Origin of the issue
To select the version on which the departure occurs, we use this line of code:
https://github.com/odoo/odoo/blob/be8b1bbad757fda27df579ce36cbc97324f58f62/addons/hr/models/hr_employee_departure.py#L117 `departure_date` should be used instead.

__
opw-6079675

Event tickets show a struck-through original price even when a "Fixed Price" pricelist rule is applied, making it incorrectly appear as a discount. This is inconsistent with eCommerce shop behavior.

### Steps to reproduce

1. Create an event with a paid ticket (e.g., 100 EUR).
2. Create a pricelist with a "Fixed Price" rule for that ticket (e.g., 80 EUR).
3. Open the event registration page.
4. The 100 EUR appears struck-through next to 80 EUR.

### Cause

Odoo's website only shows a struck-through original price for discount rules, not fixed price rules. By design, a fixed price replaces the original rather than reducing it. However, the event registration page used a simplified check: it compared the final price to the original and assumed any difference was a discount. This ignored the rule type, incorrectly flagging fixed price rules as discounts.

### Fix Rationale

A new helper method on the event ticket model now queries the applied pricelist rule to determine if it qualifies as a discount.

opw-5993477

Forward-Port-Of: odoo/odoo#264470
Forward-Port-Of: odoo/odoo#263586

**Description of the issue this PR addresses:**
Previously, when a livechat conversation ended, it was never automatically 
marked as read. The existing `mark_as_read` mechanism depends on the 
composer being focused, but ended livechat conversations hides the composer, 
and the chat window does not focus the thread automatically 
(focus only happens on explicit click).

This made it impossible for the read state to be triggered through the normal 
path, leaving agents with persistent unread indicators on closed livechat 
conversations.

**Desired behavior after PR is merged:**
- Focus the composer when present.
- Focus the conversation otherwise.

This ensures the read state is correctly triggered when the conversation
is effectively in focus.

task-[5900038](https://www.odoo.com/odoo/project/1519/tasks/5900038)

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

Forward-Port-Of: odoo/odoo#263355
Forward-Port-Of: odoo/odoo#253609

### Steps to reproduce:

**Issue 1:**
- Create a list with multiple items and leave the last item empty.
- Press Ctrl + A to select all content.
- Apply a text color from the toolbar.
- The list marker of the last item does not receive the color.

**Issue 2:**
- Create a list and type some text.
- Press Ctrl+A to select all.
- Apply a font size via the font-size input (inline style=`font-size: ...`).
- Then apply a font size via the font-size dropdown (class-based).
- Font size from the dropdown is not applied.

**Issue 3:**
- Create a list item and type some text.
- Convert the text into a link.
- Copy the link.
- Press Enter and paste the link.
- Select the entire list using the mouse.
- Apply font size & observe that font size is not applied to some list items.

**Issue 4:**
- Go to Todo and create a list.
- Select all items (Ctrl + A).
- Apply a background color class from the toolbar.
- Apply a font color using inline styling.
- Observe that the font color is not visible.

### Description of the issue/feature this PR addresses:

- Full-selection detection relied on Range.isPointInRange() checks on list item leaf nodes. When a list item ended with a trailing empty line, the selection often stopped on the `<li>` element and did not include the `<br>` placeholder. As a result, such list items were not considered fully selected when applying text color, and their markers remained unstyled.
- Applying a font-size class on a fully-selected list item could leave existing inline font-size on list item, so new class didn’t take effect.
- Creating links inside list items & repeated copy-paste operations left empty text nodes (feff cleanup). Manual selection doesn't include these nodes, `areNodeContentsFullySelected` reports that list item is not fully selected. As a result, some list items were not considered fully selected, and font size was not applied.
- Background color `(bg-*)` classes also define a color property. When a font color is applied, the color is set on the `<li>`, but the nested `font.bg-*` element’s color takes precedence, causing the applied font color to be overridden.

### Desired behavior after PR is merged:

- List items with trailing empty line are now treated as fully selected, even when selection ends before the `<br>` placeholder.
- Clear any existing font-size styles on the list item before applying the new font-size class, so the dropdown font size applies correctly.
- Empty text nodes are removed before applying font size, ensuring full list item selection and consistent font-size application.
- When a list item (li) has a text color (inline style or text-* class), and nested font element has only a background color class then font element now inherits the color from the li.

task - 5454639

Forward-Port-Of: odoo/odoo#264381
Forward-Port-Of: odoo/odoo#241827

**Steps to reproduce:**
1. Create user with role: User. Sales: Administrator, Accounting: Administrator and Documents: System Administrator.
2. Create a SO, create invoice, confirm, and send.
3. Now go back to the SO, and try to link the INV document to the chatter.

**Cause:**
When linking an existing document to the composer, the underlying attachment is copied. If the source attachment is bound to a specific field (e.g., `res_field = 'invoice_pdf_report_file'`), the `copy()` operation duplicates this field reference. Odoo's native security checks then attempt to verify access to that specific field on the target model (`mail.compose.message`). Because the composer does not have this field, the check fails and throws an AccessError, even if the user has full rights to the source document.

**Solution:**
Explicitly set `"res_field": False` during the copy operation. This strips the original field binding, cleanly converting the file into a standard, generic chatter attachment for the composer without bypassing the standard security framework.

opw-5916364

Forward-Port-Of: odoo/enterprise#107723

__

## Short functional explanation of the error
When we have a subscription product that has already been sold. If we try to import a product with the same ID but where we change the subscription type of the product, the import is executed without issue. However, this leads to undesired behavior:
when we go to the product page and try to manually change the subscription type (set it back to subscription), the change is not applied as a warning is raised.

## Reproduction Steps
Make sure you have debug mode enabled.
1. Create a product, and check the Subscription box.
2. Click on Orders and create a Quotation with this product, then confirm.
3. Go to Products > Products. Select the list view and search for the product you just created. Select it, and click Actions > Export.
4. Check the import compatible field. Select the fields to export: name, id and recurring_invoice. Upon exporting, a file is downloaded.
5. Access that file and change the recurring_invoice to FAUX or FALSE if your computer is in English. Save the changes.
6. Unselect the product and click on the cog, top right > Import. Click on Upload Data File and select the file that you have downloaded upon exporting, then import.

### Expected behavior
A user warning is raised: we shouldn't be able to change the subscription type of the product when it has already been sold.

### Unexpected behavior
The import is processed normally. Then, when we access the product page, and try to check the Subscriptions box again, a warning is raised.

## Origin of the issue
Nothing prevents the import from occurring in that case.

__
opw-6143789

Forward-Port-Of: odoo/enterprise#117111
Forward-Port-Of: odoo/enterprise#115046

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/76bed65119 [REL] 18.3.48 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/70e2c8e1f7 [FIX] color_picker: prevent gradient from opening when picking a custom color [Task: 6186050](https://www.odoo.com/odoo/2328/tasks/6186050)
https://github.com/odoo/o-spreadsheet/commit/e2d2b3493f [IMP] packages: rolldown is released in 1.0.0 [](https://www.odoo.com/odoo/2328/tasks/)
https://github.com/odoo/o-spreadsheet/commit/8b8bc44b6a [REL] 18.3.47 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/1a3ac11b2f [FIX] packages: update odoo dependencies [](https://www.odoo.com/odoo/2328/tasks/)
https://github.com/odoo/o-spreadsheet/commit/c970c1de54 [FIX] package: update package-lock [](https://www.odoo.com/odoo/2328/tasks/)
https://github.com/odoo/o-spreadsheet/commit/d2fa06ba7f [FIX] package: package install is broken [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/c2bb3c8379 [REL] 18.3.46 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/998f03a0d3 [FIX] package: husky should run at post install [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/5b5147ef7f [FIX] workflow: fix the tag definition [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/66808b6063 [FIX] Workflow: fix missing permission to use OpenID Connect [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/af50462f8c [FIX] workflow: Split the workflow in parallel jobs [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)

Co-authored-by: Florian Damhaut (flda) <flda@odoo.com>
Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com>
Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com>
Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com>
Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com>
Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com>
Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com>
Co-authored-by: Rémi Rahir (rar) <rar@odoo.com>
Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com>
Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>

__

## Short functional explanation of the error
When printing delivery slips, the description of kit components isn't shown. Therefore, we only see the components on the slip, and not the kit they come from.

## Reproduction Steps
1. Go to settings. Under Inventory, in the Operations section, enable Packages.
2. Go to Sales and create a new quotation. Select a customer and add a kit product. Click on confirm.
3. Click on the Delivery smart button. Click on Put in Pack and Validate.
4. Click on the small cog > Print > Delivery Slip.

### Expected behavior
The kit from which the components belong should be indicated somewhere on the slip.

### Unexpected behavior
The kit isn't indicated.

## Origin of the issue
When we print a delivery slip without putting in pack, we can see on the slip that the first line, in bold, corresponds to the kit name. However, after putting in pack, the first line, in bold, indicates the Package id:
https://github.com/odoo/odoo/blob/80b602f2fa82366280f9beaa3414c27293bdc4f6/addons/stock/report/report_deliveryslip.xml#L116 Thus, the lines after will correspond to the components, of which we retrieve the details with:
https://github.com/odoo/odoo/blob/80b602f2fa82366280f9beaa3414c27293bdc4f6/addons/stock/report/report_deliveryslip.xml#L125 However, in `_get_aggregated_product_quantities`, we set the description of the components to an empty string under that case: https://github.com/odoo/odoo/blob/80b602f2fa82366280f9beaa3414c27293bdc4f6/addons/mrp/models/stock_move.py#L180-L181 leaving us with no description for the components, and therefore not indicating the kit to which they belong.

__
opw-6006514

Forward-Port-Of: odoo/odoo#264159
Forward-Port-Of: odoo/odoo#254200

This PR introduces a comprehensive revamp of the Frontdesk module
to improve usability, simplify configuration, and remove redundant
features from both frontend and backend.

***Frontend Improvements***
---------------------
- Merged the visitor form and host selection screens into a single
  welcome screen to streamline the check-in process and reduce clicks.
- Removed filters and the create option from the "Host Search" dialog.
- Removed the "Create" button from the company "Search More" dialog.
- Removed Install, Statistics, and Kiosk actions from the station
  kanban card to declutter the UI.

***Model & Field Changes***
---------------------
- Removed the `frontdesk.drink` model along with all related views
  and JavaScript logic.
- Converted `ask_email`, `ask_phone`, and `ask_company` fields from
  boolean to selection fields to support required/optional behavior.
- Simplified visitor state management by removing extra selection
  values and defaulting the state to `checked_in` upon check-in.
- Set the check-in date to use the record creation date.
- When creating a visitor from the backend, automatically assign
  the station if only one station exists; otherwise, leave it empty.

***Configuration & Navigation Cleanup***
-----------------------------------
- Renamed "Options" page to "Settings".
- Moved the hosts field to the Settings page for better organization.
- Renamed "Authenticate Guest" to "Guest Details" for clarity.
- Removed Reporting and Configuration menus.
- Removed "Add/Edit Properties" from the cog menu.
- Added chatter to the station form view for better tracking.

***Notifications***
-------------
- Set default email and SMS templates under Host Notifications.

Overall, these changes modernize the check-in flow, reduce complexity,
and provide a cleaner and more intuitive experience for users and
administrators.

Task-5421138

## Issue
When generating a DMFA report with a working schedule with more or less than 5 days a week, the *Days Per Week* value in the report is still appearing as 5.

## Steps to reproduce
1. Install *Belgium - Payroll* (`l10n_be_hr_payroll`)
2. In Payroll's Settings:
    - set *ONSS Registration Number* to `0830123456`
    - set *DMFA Employer Class* to `083`
    - create a *Work Address DMFA code* (any name, any numeral code, but set the *Working Address* to the Belgian company used for the rest of the steps)
3. In Employees' Settings, set the *Company Working Hours* to a new Working Schedule, with 9 hours/day, 4 days/week. E.g from Monday to Thursday included:
    - Work from 8:00 to 12:00
    - Lunch from 12:00 to 13:00
    - Work from 13:00 to 18:00
4. Create an Employee E for the Belgian company:
    - In the *Payroll* tab, set the start date of the contract to 01/01/2026.
    - In the *Personal* tab, set the *NISS Number* to `85073003328`
5. Create the payslip for January 2026 for the Employee E.
6. In Payroll > Reporting > Belgium > DMFA, create a new DMFA for the first quarter of 2026 and generate the PDF report
7. **In the generated PDF report, the _Days per Week_ line is set to 5.**

## Cause
The number of days was calculated by multiplying `5` with the `work_time_rate` of the related calendar. This is inaccurate in the case of a company where employees are only expected to work 4 days a week.

opw-6103934

Forward-Port-Of: odoo/enterprise#117116
Forward-Port-Of: odoo/enterprise#113804

__

## Short functional explanation of the error
When for an employee with a Flexible schedule, we set a shift overlapping on two days. The attendance report displays twice the worked hours.

## Reproduction Steps
1. Create an employee with a flexible schedule and with Work Entry Source set at Planning.
2. Go to Planning. Create a Planning Slot for this employee from 9 pm to 5 am, then Send and Publish it.
3. Click on the Reporting tab > Planning / Attendance Analysis.

### Expected behavior
The total for this Month for this employee under the Planned Time field should be equal to 8 hours, which is the duration of the planning slot.

### Unexpected behavior
The total for this Month for this employee under the Planned Time field is equal to 16 hours.

## Origin of the issue
This report is a view, for which the SQL is defined starting this line: https://github.com/odoo/enterprise/blob/7362f1c5be7f496bdab660ed8fad37a6dd283616/planning_attendance/report/planning_attendance_analysis_report.py#L27 the issue stems from here:
https://github.com/odoo/enterprise/blob/7362f1c5be7f496bdab660ed8fad37a6dd283616/planning_attendance/report/planning_attendance_analysis_report.py#L56 where we don't select distinct the planning entries based on their ID. As our shift overlaps 2 days, there will be only one entry for this shift in the `planning_slot`, but because of that, it will be duplicated.

__
opw-6146052

Forward-Port-Of: odoo/enterprise#117276
Forward-Port-Of: odoo/enterprise#115447

Steps to reproduce
1. In a French company with Intrastat enabled, set up a product whose commodity code has a CN supplementary unit (e.g. 8802 30 00, "p/st") and set `intrastat_supplementary_unit_amount` on it.
2. Post EU customer invoices for that product.
3. Export the DEBWEB2 XML from the Intrastat report.

Issue
The FR export collapses engine rows a second time in `_group_items`, because the DEBWEB2 format groups more aggressively than the SQL. The aggregator only declares `value` and `weight`: https://github.com/odoo/enterprise/blob/6ae5d3df6e9305416e4d6f74259cd01753025f42/l10n_fr_intrastat/models/account_intrastat_report.py#L308-L313 Items are then rebuilt as `dict(zip(grouping_key, key_tuple)) | grouped_item_values`. `SU_code` survives (it is in the grouping key), but the numeric `supplementary_units` is in neither side and is silently dropped as soon as two engine rows merge. The template then skips the element because of its `t-if="item.get('supplementary_units')"` guard: https://github.com/odoo/enterprise/blob/6ae5d3df6e9305416e4d6f74259cd01753025f42/l10n_fr_intrastat/data/intrastat_export.xml#L61

opw-6139657

Forward-Port-Of: odoo/enterprise#117033

### Steps to reproduce:

- Install delivery_envia
- Website > Configuration > eCommerce > Delivery Methods > Envia
- Enable the delivery method, sync the carrier and Publish it
- With a portal user > Shop > Add any product to your cart > Checkout
- Register an address a valid 'Chile' address and confirm say: 
    'street and Number': Avenida Providencia 1432, Depto 402
    'city': Santiago 'zip': 8320000
    'country': Chile  'state': Metropolitana
#### > Envia Error: Invalid Option - String is too long at #->properties:destination

### Cause of the issue:

The problem is caused by the fact that Envia's api expects a 2-3 digits to represent state codes: https://docs.envia.com/reference/state-by-code
The mapping from Odoo's code state representation to envia's one is expected ot be performed by this mapping:
https://github.com/odoo/enterprise/blob/75cba6d5a88ebc4e0f35040a173ac1c443638daf/delivery_envia/models/envia_request.py#L27-L43 when the address is converted here:
https://github.com/odoo/enterprise/blob/75cba6d5a88ebc4e0f35040a173ac1c443638daf/delivery_envia/models/envia_request.py#L535-L542 That being said, the `Chile`'s code states of have been changed in [6694a3942c58ff1a56c9e4b36edbe126dd1e66f8](https://github.com/odoo/odoo/commit/6694a3942c58ff1a56c9e4b36edbe126dd1e66f8) to match the official Iso but not in the Envia's mapping leading a failling match keeping the 4 charracter long `CL-RM` of the `Metropolitan` state provided in to the Envia's api as address data.

opw-6210007

**Steps to reproduce:**
* Install the *Accounting* module.
* Install localisation modules for two different regions:
  * *Belgium* (**l10n_be**)
  * *Luxembourg* (**l10n_lu**)
* Configure two companies, each assigned to one of the above regions.
* Create fiscal positions:
  * In the Belgium company, create a fiscal position for Luxembourg.
  * In the Luxembourg company, create a fiscal position for Belgium.
* Go to *Accounting > Configuration > Settings*. Enable *Inter-Company Transactions*. Enable synchronization of *Vendor Bills and Invoices* for both companies.
* Create an invoice in the Luxembourg company. Select a partner belonging to the Belgium company. Add a product with applicable taxes.

**Observed behavior:**
* A validation error is raised: 'This entry contains taxes that are not compatible with your fiscal position. Please check the country set in the fiscal position and in your tax configuration.'

**Cause:**
* During intercompany bill creation, a foreign fiscal position is applied before recomputing taxes.
* If no mapped foreign taxes exist, the system keeps domestic purchase taxes.
* This leads to a mismatch between taxes and fiscal position, triggering the validation error.

**Fix:**
* Add a safeguard in *_inter_company_create_invoices()*.
* After *_inter_company_sync_invoice_line_taxes()* recomputes taxes, *_inter_company_has_incompatible_fiscal_position_taxes()* checks whether the fiscal position is incompatible.
* If incompatible, the fiscal position is removed and taxes are recomputed without it.

opw-6103671

Forward-Port-Of: odoo/enterprise#116944
Forward-Port-Of: odoo/enterprise#115085

## Issue 1:

Backport of 7654c558c4d517807884b0a82323dd160feeda2a

For Colombia, Envia expects the municipality/DANE-style code in the address payload, not the raw postal code.
    
When `l10n_co_edi` was not installed, the Envia integration fell back to the partner zip code and padded it locally before sending it as both `postalCode` and `city`. This produced incorrect values such as turning the Ibagué zip code `730001` into `73000100`, while Envia geocodes resolves that zip code to `73001000`.
    
Use Envia geocodes to resolve the Colombia zip fallback and retrieve the `stat_8digit` code expected by Envia instead of deriving it locally.

## Issue 2:

### Steps to reproduce:

  - Install delivery_envia
  - Website > Configuration > eCommerce > Delivery Methods > Envia
  - Enable the delivery method, sync the carrier and Publish it
  - With a portal user > Shop > Add any product to your cart > Checkout
  - Register an address a valid 'Chile' address and confirm say:
      'street and Number': Avenida Providencia 1432, Depto 402
      'city': Santiago 'zip': 8320000
      'country': Chile 'state': Metropolitana
  > Envia Error: Invalid Option - String is too long at #->properties:destination
  
### Cause of the issue:
  
The problem is caused by the fact that Envia's api expects a 2-3 digits to represent state codes: https://docs.envia.com/reference/state-by-code
The mapping from Odoo's code state representation to envia's one is expected ot be performed by this mapping:
https://github.com/odoo/enterprise/blob/75cba6d5a88ebc4e0f35040a173ac1c443638daf/delivery_envia/models/envia_request.py#L27-L43
when the address is converted here:
  https://github.com/odoo/enterprise/blob/75cba6d5a88ebc4e0f35040a173ac1c443638daf/delivery_envia/models/envia_request.py#L535-L542
That being said, the `Chile`'s code states of have been changed in 6694a3942c58ff1a56c9e4b36edbe126dd1e66f8 to match the official Iso but not in the Envia's mapping leading a failling match keeping the 4 charracter long `CL-RM` of the `Metropolitan` state provided in to the Envia's api as address data.

opw-6083181
opw-6210007

The delivery transfer for a product tracked by serial number is not linked to the POS order when there is no available stock. When validating a POS delivery in real time, stock can split the transfer into a completed picking and a backorder (e.g. one line fully delivered with lots, another serial-tracked line with no stock and no serial number).

Steps to reproduce:
-------------------
* Setup two products: one tracked by qunatity with some quantity on-hand an other tracked by SN but no quantity on-hand
* Open Pos
* Sell in one order, both products without providing SN
* Validate payment
* Open Inventory: two deliveries sould exist under Inventory Overview of PoS Orders

> Observation:
The first picking shows the POS order as Source Document but the backorder has no source document and is not linked to the POS order.

Why the fix:
------------
Pos Origin (Source Document, POS order, session) was only written on the pickings returned by `_create_picking_from_pos_order_lines`, which did not include pickings created during `_action_done()`. Extend the write to the initial pickings and their backorders so every transfer stays tied to the originating `pos.order`.

opw-6090606

*: website_helpdesk_knowledge

Steps to reproduce:
---
- Install Helpdesk/Knowledge/Website apps
- Go to Knowledge
- Set up a Knowledge workspace root article with some child articles to it
- Go to Helpdesk > Configuration > Helpdesk Teams
- Open a Helpdesk team, and go to its Help Center config
- Check Knowledge and set a non-root article as main Article
- Go to Website > Help

- First issue (non-root main article):
    - Type a word which is present in both the article and one of its child articles
    - Only the given article match the word
    - If you use the root article it will match in any descendant

- Second issue (in every case):
    - Type a word in the search bar
    - Wait for the dropdown to appear
    - Click elsewhere, dropdown is properly hidden
    - Try to change the search > Traceback

Issue:
---
The domain used to find the articles to match the search uses the current id
as the `root_article_id``:
`['|', ('id', '=', team_article.id), ('root_article_id', '=', team_article.id)],`
which was previously working in every case as it was not possible to set
a non-root article in the team setting.

This was later changed to allow any article as the default website page.
As a result, when a non-root article is selected, the search domain only
applies to that specific article and no longer includes its descendants.

The other issue is related to the added boostrap attribute `data-bs-toggle="dropdown"`
which is not properly reset when the dropdown is removed, and triggers the creation
of an empty dropdown.

Fix:
---
Doesn't seem easy to fix to allow the search on all the descendants of
the given article as we can't use the article `root_article_id` and filter out
the unwanted results in a clean way (and it doesn't seem doable with a direct domain).
Instead clarify the situation in the help of the article.

Also manually reset the attribute when there is no results.

Backport of https://github.com/odoo/enterprise/pull/107438
task - 5360265

When computing `qty_to_order` 1-3 extra queries are made by `get_lead_days()`, which can cause performance issues when computing `qty_to_order` for a large number of orderpoints.

This commit aims to prevent these extra queries by returning early if the current product is not associated with a bom. The amount this commit speeds up the compute depends on how many of products passed into `_get_lead_days()` are associated with a bom.

`qty_to_order` is no longer a stored field after this commit: https://github.com/odoo/odoo/pull/159432
This benchmark was done in 18.0 on /stock.warehouse.orderpoint/search_panel_select_range. This call does not trigger the compute on all orderpoints in 17.0 as the field is stored but calling the compute directly on all orderpoints results in the same speed up as seen in 18.0.

| Orderpoints | % of products linked to a bom | Time before | Queries before | Time after | Queries After |
|-------------|-------------------------------|-------------|----------------|------------|---------------|
|         800 | 50%                           | 2.8s        |           1570 | 2.3s       |           818 |
|       8,000 | 0%                            | 28.2s       |         16,698 | 15.3s      |           242 |
|       8,000 | 25%                           | 29.6s       |         16,833 | 19.2s      |          4497 |
|       8,000 | 50%                           | 29.8s       |         16,925 | 23.2s      |          8693 |
|       8,000 | 75%                           | 31.6s       |         16,949 | 27.6s      |         12827 |

## **Issue**

When a cash basis tax is configured with a payable/receivable
transition account, tax journal items are generated on that account
without a due date.

Since payable/receivable accounts require a due date on journal
items, this leads to a validation error during move creation:

"Any journal item on a payable account must have a due date and vice versa."

## **Steps to reproduce:**

1. Install the Accounting and Inter-Company modules.
2. Create an additional company so that there are a total of two companies, then switch to Company 1.
3. Create a product with a price and assign a tax to it.
4. Navigate to Accounting → Configuration → Settings and enable Cash Basis accounting.
5. Go to Accounting → Configuration → Taxes and open the purchase tax (or the tax assigned to the product).
6. In the Tax Computation section, ensure that Group of Taxes is not selected.
7. Under the Advanced Options tab, set Tax Exigibility to Based on Payment.
8. Set the Cash Basis Transition Account to a payable account.
9. Open Company Settings, select Company 1, go to the Inter-Company Transactions section, and enable Synchronize invoices/bills.
10. Switch to Company 2 and create an invoice using the same product. Select the contact that is the partner of Company 1.
11. Confirm the invoice.

The following error is raised:

"Any journal item on a payable account must have a due date and vice versa."

## **With This Commit:**
Added a domain on the Cash Basis Transition Account field to prevent
users from selecting payable or receivable accounts, avoiding invalid
configurations and runtime validation errors.

opw-6189615

### Issue before this commit:
In the Italian Annual VAT Report, the balance (base amount) for line VF25 displays incorrect values. Instead of computing the sum of the taxable bases for the passive operations, the report erroneously mixes tax amounts into the balance column.

### Steps to reproduce the issue:
1. Download Accounting and l10n_it
2. Go to Tax Report and visualize the Annual Tax Report (IT)
3. Go to VF VAT Report
4. See the VF25 is mixing taxes and balances

### Cause of the issue:
The root cause lies in the aggregation_formula definition for the tax_annual_report_line_VF25 record. The formula was incorrectly configured to aggregate the .tax expressions for lines VF1 to VF13 (VF1.tax + VF2.tax + ...) instead of their respective .balance expressions, while correctly using .balance for the remaining lines (VF17 to VF24).
https://github.com/odoo/odoo/blob/878c08cf522a3278b4e6ff5f3d18444989e9998d/addons/l10n_it/data/tax_report/annual_report_sections/vf.xml#L286-L299

It's just a typo in this commit: https://github.com/odoo/odoo/pull/164064/changes/f292ba119d6376dbfb3c1fac4960c9c56a74d938

### Reason to introduce the fix:
From documentation https://www.agenziaentrate.gov.it/portale/documents/20143/9602686/IVA_ANNUALE_2026_istr.pdf/2a42fb92-1b76-229a-d0f5-06069d79b514?t=1768504755711 : 

> Rigo VF25, colonna 1, va indicato il totale degli imponibili determinato sommando gli importi riportati ai righi da VF1 a VF23, colonna 1, diminuito dell’importo di cui al rigo VF24. In colonna 2 va indicato il totale delle imposte determinato sommando gli importi delle colonne 2 dei righi da VF1 a VF13.

opw-6172791

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