This commit fixes various issues when using Viva Wallet, including the following:
- When two Viva Wallet terminals had a payment in process at the same time in the same POS, one of the payments would fail on Odoo even when it succeeded on the terminal.
- When a previous Viva Wallet payment was stuck (never completed or failed), trying to make a new payment would mistakenly affect that previous order instead of the new order.
- When refreshing the page during a payment, it becomes stuck and never confirms or fails.

To fix these issues, there are two main changes:
1. Stop using the `getPendingPaymentLine` method to retrieve the Viva Wallet payment line. This method is flawed as it assumes there is only one pending payment at a time.
2. Store the Viva session ID for a payment in the payment line's UI state, instead of on the plain JS object. This allows it to persist after a refresh.

opw-5226966
opw-5248178

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

Forward-Port-Of: odoo/odoo#236004
Forward-Port-Of: odoo/odoo#235695

When a FEC file imports journal items, it will create them to draft with reconciliations stated by a matching number starting with "I" (also the case for other some types of imports). Once the entries are posted, the system will create odoo reconciliation records for those journal items.

The issue lies in this part of the code removing the matching when performing reconciliations for the same matching number
https://github.com/odoo/odoo/blob/9d34c7ee85d105a56c3393a3dbb3e5d62d4d634a/addons/account/models/account_partial_reconcile.py#L206

Most of the time it's not a problem for the auto reconcile mechanism of FEC. However since this mechanism reconciles grouped on matching + account, we can end up in a case where a first reconciliation on account A will remove all matching number similar but on account B leading to no automatic reconciliation for them.

This commit aims to fix that by removing amls imported matching number (starting with "I") from the reconciled amls to consider.

opw-5086823

Forward-Port-Of: odoo/odoo#234481

When paying with Bancontact, in case a 3DS validation is required (challenge flow), Wordline will send a webhook (see below) to indicate that an external (asynchronous) validation was requested.

Example of recevied webhook:
```
{
  'apiFullVersion': 'v1.1',
  'apiVersion': 'v1',
  ...
  'payment': {
     'status': 'AUTHORIZATION_REQUESTED',
      'statusOutput': {
        'isAuthorized': False,
        'isCancellable': False,
        'isRefundable': False,
        'statusCategory': 'PENDING_CONNECT_OR_3RD_PARTY',
        'statusCode': 51
      }
   },
 'type': 'payment.authorization_requested'
}
```

Since efc2788dfccd, when receiving such webhook we set the transaction as error then force the user flow to `redirect`; this was done to handle payment w/ token (`online_token`) where a 3DS challenge is still required.

But for Bancontact - which is non-tokenizable - we will always be in the "redirect" mode, so we must keep the transaction as `pending`.

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

Forward-Port-Of: odoo/odoo#235847

*: {stock_barcode_,}quality_control
#### There are two issues addressed in this PR:

1) In the barcode app, quality checks triggered at validation includes quality checks related to unpicked products.
2) Quality check related to product without set lots are triggered.

### Steps to reproduce:

- Create a storable products product A tracked by SN
- Create a control points of type pass/fail on receipts control by
  quantity on product A
- Create and confirm a receipt with a move 2 x product A
- Open the receipt in the barcode app
- Scan product A > Scan SN001
- Click on Quality Check
#### > Both QC's are displayed to be processed

### Expected behavior:

Only the QC related to the scanned SN should be processed as it is the only unit that will be moved at validation.

### Cause of the issue:

Only picked move lines are considered to be processed in the barcode app. However, the `check_quality` triggered by clicking on the quality check button only check if the move related to the move line is picked:
https://github.com/odoo/enterprise/blob/9fe45b673c02a98e6dd6b3997f19a2018a76df09/quality_control/models/stock_picking.py#L64-L72

### Fix:

Relying the `barcode_trigger` context key will ensure a uniform behavior between the QC's displayed to be processed directly from the QC button and from these displayed at validation since this context key is already used at validation:
https://github.com/odoo/enterprise/blob/9fe45b673c02a98e6dd6b3997f19a2018a76df09/stock_barcode/static/src/models/barcode_model.js#L581-L590

Note we all changed the default return value of the `check_quality` from `False` to `True` here:
https://github.com/odoo/enterprise/blob/9fe45b673c02a98e6dd6b3997f19a2018a76df09/quality_control/models/stock_picking.py#L71-L73
because this method is called in the `pre_action_done_hook` during the `button_validate` of the picking:
https://github.com/odoo/odoo/blob/a97d3c772001f4f0b9df66d28c1c8f19358898e0/addons/stock/models/stock_picking.py#L1415-L1421
https://github.com/odoo/enterprise/blob/9fe45b673c02a98e6dd6b3997f19a2018a76df09/quality_control/models/stock_picking.py#L91-L96
and since a result that is not `True` is expected to be an action that should be processed prior to validation, returning `False` would make it impossible to proceed with a validation in case the `check_quality` is called and there is no check to process.

Task: 4716252
opw-5010764

Forward-Port-Of: odoo/enterprise#99565

When you have a vendor bill with an invoice line linked to a journal item with the display type "non_deductible_product", if you modify the account_id of the invoice line, then the account_id of the linked line should change to have the same value.

How to reproduce?
  1. Create an asset model (Accounting > Configuration > Accounting > Asset Models)
  2. Set the asset_model_id on an account (on the tab "Automation", set "Automate Asset" as "Create in draft" then set the "Asset Model" field with the created asset model
  3. Duplicate the account having the created asset model
  4. Create a vendor bill with an invoice line having:
    - A strictly positive price unit
    - A deductible_amount (Professional %) lower than 100 (this field is hidden by default)
  5. Modify the account_id of the invoice line
  6. Observe the journal items: the line with the non- deductible product should have the same account_id than the invoice line but it's not the case.

task-5156256

Forward-Port-Of: odoo/odoo#232121

**Steps to reproduce:**
- Install base_automation, sale_management, and stock.
- Create an automation rule for the Transfer model (stock.picking) that creates an activity 
when the state is set to Ready.
   - User type → Dynamic user (based on record)
   - User field → Responsible
- Confirm a Sale Order and open the related delivery.
- Move delivery to the Ready state.
- Notice that the created activity has no assigned user.

**Issue:**
- The activity is created without a user_id.

**Cause:**
- Since user_id is no longer a required field on mail.activity, when creating an activity through automation, 
if the related record (e.g., stock.picking) does not have a responsible user, and activity type dose not have 
`default_user_id  the user_id` remains unset.

https://github.com/odoo/odoo/blob/7ced429ff54c9670f2ff1b1866ecfb01f49ad50d/addons/mail/models/mail_activity_mixin.py#L408-L409

- Previously, the creation logic would fall back to using either a default user from the activity type 
or the current environment user (env.uid). This fallback no longer occurs in all cases.

https://github.com/odoo/odoo/blob/279504268e1c4b57f26543db1c7da9a709fea350/addons/mail/models/mail_activity_mixin.py#L401-L402

**Solution:**
- If no user_id is determined (either from the record or activity type), explicitly assign
the current logged-in user (env.user) as the activity’s responsible user during creation.
- This ensures that every activity created through automation has a valid assignee

opw - 5213520

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

When paying with Bancontact, in case a 3DS validation is required (challenge flow), Wordline will send a webhook (see below) to indicate that an external (asynchronous) validation was requested.

Example of recevied webhook:
```
{
  'apiFullVersion': 'v1.1',
  'apiVersion': 'v1',
  ...
  'payment': {
     'status': 'AUTHORIZATION_REQUESTED',
      'statusOutput': {
        'isAuthorized': False,
        'isCancellable': False,
        'isRefundable': False,
        'statusCategory': 'PENDING_CONNECT_OR_3RD_PARTY',
        'statusCode': 51
      }
   },
 'type': 'payment.authorization_requested'
}
```

Since efc2788dfccd, when receiving such webhook we set the transaction as error then force the user flow to `redirect`; this was done to handle payment w/ token (`online_token`) where a 3DS challenge is still required.

But for Bancontact - which is non-tokenizable - we will always be in the "redirect" mode, so we must keep the transaction as `pending`.

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

Forward-Port-Of: odoo/odoo#235847

*: {stock_barcode_,}quality_control
#### There are two issues addressed in this PR:

1) In the barcode app, quality checks triggered at validation includes quality checks related to unpicked products.
2) Quality check related to product without set lots are triggered.

### Steps to reproduce:

- Create a storable products product A tracked by SN
- Create a control points of type pass/fail on receipts control by
  quantity on product A
- Create and confirm a receipt with a move 2 x product A
- Open the receipt in the barcode app
- Scan product A > Scan SN001
- Click on Quality Check
#### > Both QC's are displayed to be processed

### Expected behavior:

Only the QC related to the scanned SN should be processed as it is the only unit that will be moved at validation.

### Cause of the issue:

Only picked move lines are considered to be processed in the barcode app. However, the `check_quality` triggered by clicking on the quality check button only check if the move related to the move line is picked:
https://github.com/odoo/enterprise/blob/9fe45b673c02a98e6dd6b3997f19a2018a76df09/quality_control/models/stock_picking.py#L64-L72

### Fix:

Relying the `barcode_trigger` context key will ensure a uniform behavior between the QC's displayed to be processed directly from the QC button and from these displayed at validation since this context key is already used at validation:
https://github.com/odoo/enterprise/blob/9fe45b673c02a98e6dd6b3997f19a2018a76df09/stock_barcode/static/src/models/barcode_model.js#L581-L590

Note we all changed the default return value of the `check_quality` from `False` to `True` here:
https://github.com/odoo/enterprise/blob/9fe45b673c02a98e6dd6b3997f19a2018a76df09/quality_control/models/stock_picking.py#L71-L73
because this method is called in the `pre_action_done_hook` during the `button_validate` of the picking:
https://github.com/odoo/odoo/blob/a97d3c772001f4f0b9df66d28c1c8f19358898e0/addons/stock/models/stock_picking.py#L1415-L1421
https://github.com/odoo/enterprise/blob/9fe45b673c02a98e6dd6b3997f19a2018a76df09/quality_control/models/stock_picking.py#L91-L96
and since a result that is not `True` is expected to be an action that should be processed prior to validation, returning `False` would make it impossible to proceed with a validation in case the `check_quality` is called and there is no check to process.

Task: 4716252
opw-5010764

Forward-Port-Of: odoo/enterprise#99565

When a FEC file imports journal items, it will create them to draft with reconciliations stated by a matching number starting with "I" (also the case for other some types of imports). Once the entries are posted, the system will create odoo reconciliation records for those journal items.

The issue lies in this part of the code removing the matching when performing reconciliations for the same matching number
https://github.com/odoo/odoo/blob/9d34c7ee85d105a56c3393a3dbb3e5d62d4d634a/addons/account/models/account_partial_reconcile.py#L206

Most of the time it's not a problem for the auto reconcile mechanism of FEC. However since this mechanism reconciles grouped on matching + account, we can end up in a case where a first reconciliation on account A will remove all matching number similar but on account B leading to no automatic reconciliation for them.

This commit aims to fix that by removing amls imported matching number (starting with "I") from the reconciled amls to consider.

opw-5086823

Forward-Port-Of: odoo/odoo#234481

During the rework of the follow-up report, we removed the
"No Follow-Up" field from journal items, making it impossible to exclude
individual journal items from triggering a follow-up.

In this commit we do the following:
-  Re-introduce a field for that, since it is a common
   requirement to be able to exclude individual items from the follow-up
   reports.
   The field is stored on the journal item, but can also be toggled from
   the journal entry. In case of multiple installments on the invoice,
   toggling the field on one installment will toggle it for all
   installments.
-  Adapt the Follow-Up Report and Customer Statement variants of the
   Partner Ledger to add a toggle for the "No Follow-Up" field on each
   report line, that toggles the field on the corresponding journal
   item(s).
-  Prevent the follow-up status on the partner to change when all of the
   overdue journal items are marked as "No Follow-Up".
-  Make sure users can toggle the "No Follow-Up" setting on the invoice
   level when opening the "Overdue Invoices" view from the partner's
   "Accounting" tab.
-  Make sure all receivable/payable lines without a due date (either
   from a manual miscellaneous entry or a PoS entry) are put under the
   "Due" section in the Follow-Up Report instead of the "Overdue"
   section. Since there is no due date, they can't be overdue.
-  Make sure the PDF and XLSX exports of the Follow-Up Report don't
   include the "No Follow-Up" lines, and the customer follow up email
   only includes the amount of the other lines.

Backport of https://github.com/odoo/enterprise/commit/74b9d2ef17e4f9a217db8432d886de2eca4baef9
and https://github.com/odoo/odoo/commit/2789a0fbfa358c5c164e44380c2a4a10e5679615
Task: 5138378

Upgrade PR → https://github.com/odoo/upgrade/pull/8864

Forward-Port-Of: odoo/enterprise#96627

*: {stock_barcode_,}quality_control
#### There are two issues addressed in this PR:

1) In the barcode app, quality checks triggered at validation includes quality checks related to unpicked products.
2) Quality check related to product without set lots are triggered.

### Steps to reproduce:

- Create a storable products product A tracked by SN
- Create a control points of type pass/fail on receipts control by
  quantity on product A
- Create and confirm a receipt with a move 2 x product A
- Open the receipt in the barcode app
- Scan product A > Scan SN001
- Click on Quality Check
#### > Both QC's are displayed to be processed

### Expected behavior:

Only the QC related to the scanned SN should be processed as it is the only unit that will be moved at validation.

### Cause of the issue:

Only picked move lines are considered to be processed in the barcode app. However, the `check_quality` triggered by clicking on the quality check button only check if the move related to the move line is picked:
https://github.com/odoo/enterprise/blob/9fe45b673c02a98e6dd6b3997f19a2018a76df09/quality_control/models/stock_picking.py#L64-L72

### Fix:

Relying the `barcode_trigger` context key will ensure a uniform behavior between the QC's displayed to be processed directly from the QC button and from these displayed at validation since this context key is already used at validation:
https://github.com/odoo/enterprise/blob/9fe45b673c02a98e6dd6b3997f19a2018a76df09/stock_barcode/static/src/models/barcode_model.js#L581-L590

Note we all changed the default return value of the `check_quality` from `False` to `True` here:
https://github.com/odoo/enterprise/blob/9fe45b673c02a98e6dd6b3997f19a2018a76df09/quality_control/models/stock_picking.py#L71-L73
because this method is called in the `pre_action_done_hook` during the `button_validate` of the picking:
https://github.com/odoo/odoo/blob/a97d3c772001f4f0b9df66d28c1c8f19358898e0/addons/stock/models/stock_picking.py#L1415-L1421
https://github.com/odoo/enterprise/blob/9fe45b673c02a98e6dd6b3997f19a2018a76df09/quality_control/models/stock_picking.py#L91-L96
and since a result that is not `True` is expected to be an action that should be processed prior to validation, returning `False` would make it impossible to proceed with a validation in case the `check_quality` is called and there is no check to process.

Task: 4716252
opw-5010764

Forward-Port-Of: odoo/enterprise#99565

When a FEC file imports journal items, it will create them to draft with reconciliations stated by a matching number starting with "I" (also the case for other some types of imports). Once the entries are posted, the system will create odoo reconciliation records for those journal items.

The issue lies in this part of the code removing the matching when performing reconciliations for the same matching number
https://github.com/odoo/odoo/blob/9d34c7ee85d105a56c3393a3dbb3e5d62d4d634a/addons/account/models/account_partial_reconcile.py#L206

Most of the time it's not a problem for the auto reconcile mechanism of FEC. However since this mechanism reconciles grouped on matching + account, we can end up in a case where a first reconciliation on account A will remove all matching number similar but on account B leading to no automatic reconciliation for them.

This commit aims to fix that by removing amls imported matching number (starting with "I") from the reconciled amls to consider.

opw-5086823

Forward-Port-Of: odoo/odoo#234481

When paying with Bancontact, in case a 3DS validation is required (challenge flow), Wordline will send a webhook (see below) to indicate that an external (asynchronous) validation was requested.

Example of recevied webhook:
```
{
  'apiFullVersion': 'v1.1',
  'apiVersion': 'v1',
  ...
  'payment': {
     'status': 'AUTHORIZATION_REQUESTED',
      'statusOutput': {
        'isAuthorized': False,
        'isCancellable': False,
        'isRefundable': False,
        'statusCategory': 'PENDING_CONNECT_OR_3RD_PARTY',
        'statusCode': 51
      }
   },
 'type': 'payment.authorization_requested'
}
```

Since efc2788dfccd, when receiving such webhook we set the transaction as error then force the user flow to `redirect`; this was done to handle payment w/ token (`online_token`) where a 3DS challenge is still required.

But for Bancontact - which is non-tokenizable - we will always be in the "redirect" mode, so we must keep the transaction as `pending`.

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

Forward-Port-Of: odoo/odoo#235847

This commit contains 2 things:
- an helper to extract any tax_data and move it to another base_line
- the usage of this helper in UBL to turn emptying taxes into additional base_lines

== Add helpers to turn tax_data into new base_lines easily ==

With this helper, you can now exclude any tax from any base line and turn
them into new base lines.

Also, I changed a bit the smooth distribution of rounding because the math.ceil
is sometimes too greedy and make the whole results to be less accurate.

== Make a different behavior between recycling contribution taxes / emptying taxes ==

In UBL, all fixed taxes are treated as allowances/charges.
In this commit, we make a clear distinction between recycling contribution taxes
that are treated as allowances/charges and emptying taxes that are exempted of tax
and are treated as addition invoice lines in the document.

== Fix a small issue with aggregate_function passed to reduce_base_lines_with_grouping_function ==

The aggregator wasn't called when setting the 'target_base_line' at the very first time.

task_id: 5182783

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

Forward-Port-Of: odoo/odoo#235580
Forward-Port-Of: odoo/odoo#234489

When you have a vendor bill with an invoice line linked to a journal item with the display type "non_deductible_product", if you modify the account_id of the invoice line, then the account_id of the linked line should change to have the same value.

How to reproduce?
  1. Create an asset model (Accounting > Configuration > Accounting > Asset Models)
  2. Set the asset_model_id on an account (on the tab "Automation", set "Automate Asset" as "Create in draft" then set the "Asset Model" field with the created asset model
  3. Duplicate the account having the created asset model
  4. Create a vendor bill with an invoice line having:
    - A strictly positive price unit
    - A deductible_amount (Professional %) lower than 100 (this field is hidden by default)
  5. Modify the account_id of the invoice line
  6. Observe the journal items: the line with the non- deductible product should have the same account_id than the invoice line but it's not the case.

task-5156256

Forward-Port-Of: odoo/odoo#232121

### Issue:
In a certain case, the div `journal_div` has nothing inside and is displayed. This causes the form view to be offsetted.

### Steps to reproduce:
- Install "l10n_ar" and switch to an Argentinian company
- The user must not have the group `base.group_multi_currency`
	- Settings > Currencies and deactivate the USD
- Make sure you only have one Sales journal
- Create an invoice
- The field 'Result' is offsetted

### Cause:
The div `journal_div` is constructed like this:
```xml
<div name="journal_div" class="d-flex">
    <field name="journal_id"
           invisible="not show_journal"/>
    <div name="currency_div"
         groups="base.group_multi_currency">
       ...
    </div>
</div>
```
In the case `show_journal = False` and the user doesn't have the group `base.group_multi_currency`, then `journal_div` is empty, but it's still displayed.

It will take the place of a label, this means that the next field label will be in the "input" column and its input in the "label" column.

### Solution:
We need to not display the `div` when `show_journal = False` AND the user doesn't have the group `base.group_multi_currency`. This is not possible.

A possible fix would be to add a non-stored computed field just like `show_journal` to show or not the div.

This commit chose to fix this with CSS: do not display `journal_div` if it's empty. This is also more secure in the case where a customization added things in the div.

Before this commit:
<img width="1048" height="273" alt="image" src="https://github.com/user-attachments/assets/04062527-ee8d-463c-9768-72f0680c922d" />

After this commit:
<img width="1052" height="221" alt="image" src="https://github.com/user-attachments/assets/30b4f169-f4c0-485f-b895-b8d33bfd1fa6" />


opw-5221931

Since PR [1], there was an issue with the statusbar field and the way it put overflowing items into dropdowns (cf. adjust function). Have a form view with a statusbar field and enough items s.t. they don't all fit in the screen. The widget implements a logic to put the first and/or last overflowing items into dropdowns (one before the displayed items, one after).

Before this commit, if the user clicked on an item to select it as new value, the state of the widget was incorrect, leading to dropdowns being displayed, but empty (and items being unavailable, as they are hidden, but not displayed in the dropdown).

This was due to a `useEffect` with an incorrect dependency: if two consecutive renderings were done with the `shouldAdjust` status (which is possible since [1] and the introduction of the `forceRecomputeItems` flag), the dependency didn't change and the callback of `useEffect` was not called, leading to items not being processed.

[1] https://github.com/odoo/odoo/pull/230548

opw~5232448

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Before this commit:
- The `.dat` export adjusted its date based on the selected export type’s periodicity (quarterly or annually) using the report filter's date_to.
- This caused mismatches where the `.dat` file showed a different period than the report data.
- The adjustment only changed the date in header of `.dat` file but did not restrict data accordingly, leading to inconsistencies when exporting reports with different filter and periodicity types.
- Example: If the report filter is set to 'October 2025' month and the export type's periodicity is 'Annual', the `.dat` file would show 12/31/2025 even though the data in `.dat` file only covers 'October 2025'. Similar mismatch occurs for 'month & quarter' and 'annual & quarter' combinations.

After this commit:
- The `.dat` export date now fully depends on the report’s date filter, keeping report data and export date consistent.
- A non blocking warning is added in the `.dat` export wizard when the report period type is different from the export type's periodicity, helping users select the correct period type while still allowing export if intended.

task-5172259

Currently, an error occurs when user removes value from `Based On` field and saving.

Steps to replicate:
- Install `website_sale` with demo and enable pricelists from settings.
- Open pricelists and Open any Pricelist.
- Under the pricelist rules, make sure `Price Type` is selected as Formula.
- Remove value from `Based Price` and click elsewhere.

Error:
`KeyError: False`

Cause:
- As the `base` field was changed the compute was called and `item.base` was passed on as 'False' at line [1] and caused the Keyerror.

Solution:
- The code skips execution when `item.base` is False, as there is no point in making the `item.rule_tip` [2] if we dont have all the values.

[1]: https://github.com/odoo/odoo/blob/257537584bedc1ab7db1bdc700f89145a3bb6095/addons/product/models/product_pricelist_item.py#L287

[2]: https://github.com/odoo/odoo/blob/257537584bedc1ab7db1bdc700f89145a3bb6095/addons/product/models/product_pricelist_item.py#L284-L296

sentry-6948941509

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

Versions
--------
- 19.0+

Steps
-----
1. Have a browser open with a side-bar or that isn't full-screen;
2. open website editor on a product page;
3. enable zoom-on-click;
4. replace the main image;
5. save changes;
6. click on the new image to zoom in;
7. download the image.

Issue
-----
The image is too small & low quality.

Cause
-----
The `this.dependencies.media_website.replaceMedia(image)` call is meant to be used along with an html editor widget to select size & quality. As we have a custom widget to handle product images, the image that ends up getting uploaded is one that's been optimized for the current viewport size.

Solution
--------
Replace the `replaceMedia` call with custom logic similar to that used for extra media, drawing the image to a `canvas` element, and then saving it as the product's `image_1920` field.

Additionally, enable extra media to get saved as in 1920 size, and remove the hardcoded `0.75` image quality value, as a value this low easily leads to visible compression artifacts.

opw-5088032

This fix a traceback:
- Create a report "A" with Period Comparison set to True
- Create a report "B" with Period Comparison set to False
- Create a composite report with report "B" inside.
- Use the variant filter to switch from report "A" to the composite report

This happens because of a UI refresh in `loadReportOptions` trigged by:
- delete this.reportOptionsMap[cacheKey];
- delete this.loadingCallNumberByCacheKey[cacheKey];

When refreshing the UI, it will start with the cachedOption set to the value of the displayed report (report "A"), and is able to pass the condition inside `filters.xml`: `<t t-if="controller.filters.show_period_comparison">`.

While this is happening, the loading of the new report "composite" reaches `this.cachedFilterOptions = options;`. However, the UI refresh is still ongoing, and when it reaches `<t t-if="controller.cachedFilterOptions.comparison.string">` in `filter_comparaison.xml`. If the new report doesn't have the comparaison filter enabled, cachedFilterOptions.comparison will be undefined triggering the traceback.

This is fixed by marking the objects, that would trigger this useless refresh, as raw preventing them from triggering a refresh.

This only happened on composite reports since the cacheKey used to load them is different from the one received by the call to get_options due to the sections.

task-5085985

### Description of the feature this PR addresses:
**Specific tax on withholdings for incapacity to work created to correctly reflect the amounts derived in Form 190 of the AEAT.**

A new tax called "**100% WHI monies**" has been created with the aim of correctly reflecting the income derived from incapacity for work in the AEAT's Model 190.

### Current behavior before PR:

Currently, Odoo does not allow automatic differentiation between monetary payments derived from work incapacity and those not derived from it.
This creates a problem when generating Model 190, as the Spanish Tax Agency (AEAT) requires both types of payments to be reported separately (according to the codes and subcodes established in the model).

**In practice, this separation is necessary because:**

- Income derived from incapacity for work (e.g., sick leave) is considered employment income with differentiated tax treatment.
- Withholdings made on these amounts must be declared in specific sections of Form 190.
- If they are not separated correctly, the totals on the form may be incorrect or incomplete, affecting the accuracy of the tax information submitted.

### Desired behavior after PR is merged:

A new tax has been added to represent “100% Withholding income tax (workers)”, allowing Odoo to:
- Correctly identify and calculate the related amounts.
- Report them separately in the AEAT Model 190.
- A new tax group has also been created to distinguish these withholdings from regular ones.

### Benefits:

- It allows you to correctly generate Form 190, separating income derived from and not derived from work disability.
- It facilitates the accounting and tax traceability of this type of income.
- It ensures consistency with the information structure required by the Spanish Tax Agency (AEAT), avoiding errors in the annual filing.
- It improves the flexibility of the Odoo tax system, adapting it to actual tax needs.

### Technical summary:

- A **new specific tax** has been created for withholdings associated with incapacity for work benefits.
- This tax **allows the amounts corresponding to these benefits to be identified, accounted for, and reported independently.**
- In addition, a **new tax group "Whitholdings IRPF Workers" has been added that groups these withholdings together**, allowing them to be clearly distinguished from other withholdings on earned income.

The related issue: https://github.com/OCA/l10n-spain/issues/4416

### Follow-up suggestion: adjust Odoo’s base tax “15% WHI monies”

**Proposal:** Change the base tax “15% WHI monies” to 100% and move it to the new “Whitholdings IRPF Workers” tax group.

**Why:** The current 15% rate is not aligned with how AEAT Model 190 requires amounts to be computed: the base should reflect 100% of the earnings derived from temporary incapacity, with the withholding rate applied on top of that base. Keeping 15% leads to misclassification and wrong totals in the "_percepciones_" and "_retenciones_" sections.

These are variable withholdings, not fixed taxes — each worker’s rate can change monthly depending on their income and number of days worked. Therefore, having a fixed 15% rate is conceptually incorrect and causes misclassified amounts and inaccurate totals, forcing users to adjust values manually after payroll.

Ideally, this tax should not have any fixed percentage defined. Since Odoo currently requires a rate, setting the base to 100% is a pragmatic workaround that ensures more accurate and flexible withholding calculations.

**Outcome:**

- Correct calculation and reporting of **_percepciones derivadas de incapacidad laboral_**.
- Clean separation from other withholdings via the new tax group.
- Consistency between accounting, payroll, and the 190 export.

Would you accept this change?


@moduon @rafaelbn @EmilioPascual @chklop @jco-odoo MT-11667 

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

**Steps to reproduce:**
- Create some activities which should not be accessible to a specific user (according to the `_search` filtering of `mail.activity`)
- Go to Activity Menu > View all activities as the given user
- Ensure that the limit (default: 80) is lower than the total number of activities which should be returned and that the new activities are in the returned elements
- On `web_search_read` some records are removed by the `_search` override
- The pagination navigation buttons are disabled as the returned number of records is lower than the limit
- This means that some activities are not accessible to the user (everything above the given limit)

**Issue:**
The issue comes from the `_search` override which checks the records available to the user. As it's done after fetching with the limit, the resulting number of records can be lower than expected and this breaks the `_format_web_search_read_results` which considers that we have all the possible records and doesn't try to fetch the total count of records.

**Fix:**
The main issue can't be directly fixed without modifying the way the access are checked in the `_search` override.

This could be mitigated by changing the search limit, making the search as superuser, or adding specific filtering but each has its own limitations.

Adding `force_search_count` should allow the user to navigate between pages anyway and see all the available activities. But the number displayed in the pagination will often be incorrect for the current and total count. (e.g. we can have 75 records but 1-80/150 is displayed out of 140 actually readable records)

opw-5046389

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

**Issue**
In replenishment, filtering with `to_order = 0` does not correctly exclude records where `to_order != 0`.

**Steps to reproduce**
1. Go to Inventory > Operations > Procurement > Replenishment
2. Create a replenishment with a forecast quantity smaller than the min and max quantity (without editing the To Order)
3. Apply a custom filter `to_order = 0` → Records with non-zero `to_order` are incorrectly included

**Cause**
`qty_to_order` was split into `qty_to_order_computed` and `qty_to_order_manual` in [this commit](https://github.com/odoo/odoo/commit/156bed3f430d706e13822bbd95d91c8dfd3ea42d#diff-0eb18a8d7773b5f99b402392188594178c3ba2004e4bcab26dbc84b1c8d7256a).

In the [`_search_qty_to_order` method](https://github.com/odoo/odoo/blob/322c6d0468bf79e9d29e1375c49aa13d4a7b7a67/addons/stock/models/stock_orderpoint.py#L338), all records with `qty_to_order_manual = 0` are included. Since `qty_to_order_manual` defaults to 0 when untouched by the user, this causes incorrect results.

Additionally, [`to_order`](https://github.com/odoo/odoo/blob/322c6d0468bf79e9d29e1375c49aa13d4a7b7a67/addons/stock/models/stock_orderpoint.py#L323) displays `qty_to_order_computed` if `qty_to_order_manual = 0`, creating inconsistency.

**Solution**
Fix the inconsistency by ignoring `qty_to_order_manual` when searching for zero `to_order` values.

opw-5150643

Initially, all errors emerging from the `action_pos_order_invoice` call were ignored through a `silentCall`.

https://github.com/odoo/odoo/blob/eac2a1132fd7a9a6ba51b87195c5f0b5a706b191/addons/point_of_sale/static/src/app/models/data_service.js#L638-L645

This prevents the user from being shown an error when they attempt to perform a forbidden action. An example of an error silenced by this issue is shown in https://github.com/odoo/enterprise/pull/98802, which was also the initial reason for this fix.

Replacing the `silentCall` by a `call` allows us to work with the RPCErrors raised from the `action_pos_order_invoice` call and show the users why their operations might be invalid. Other errors are only displayed as a warning, just like they would have been using a `silentCall`.

Steps to reproduce an error which required this fix:
- Install the POS app and the "_Mexican localization for the Point of Sale_" module (`l10n_mx_edi_pos`)
- Set the company to a Mexican one (e.g. _ESCUELA KEMPER URGATE_)
- Open the POS app
- **Sell a product**
    - Open a register
    - Select a product and click "Add"
    - Click "Payment"
    - Set the Customer to a new customer with only a name
    - Click "Cash" to set the Remaining to 0
    - Click "Validate"
- **Request an invoice**
    - Once the payment is done, get to the Orders tab (in the POS)
    - Set filter to "Paid"
    - Select the transaction at the top of the list
    - Click "Invoice"
    - Set "Invoice to public" to "Yes"
    - Click "Ok"
- An error should be displayed, because the selected customer does not have a country or zip code set. This error is prevented by the `silentCall` mentionned above.

opw-5171035

before this commit, when trying to reprint a past order it would not work. Instead it would print the last order no matter what order is selected.

Steps to reproduce:
1. setup an DB with an italian POS
2. make 2 sales with a different product (easier tracking)
3. open the "orders" view
4. try to reprint the ticket of the firt order result: the receipt of the second order is printed

the reason for this is that we were using the printer's built in command "printDuplicateReceipt" which is inteded for printing the very last receipt.

With this commit, we changed the behavior and invoke another printer command. That command is meant to reprint any receipt, based on the provided reference. After this commit, trying to print any past receipt will print that exact receipt.

IMPORTANT NOTE:
In theory, the printer command can reprint any number of receipts. We decide that we will only use it to reprint the one receipt selected by the user. This moves the complexity of parsing date strings and ranges to the command component and therefore will keep the rest of the code cleaner.

opw-5008702
opw-4882480

Steps to reproduce
-----
- Create a Sendcloud delivery method
- Select a delivery service with "Locker or service point" as "Last mile" (eg  "bpost @ bpack")

> "Use Sendcloud locations" is set to false

Cause
-----
There is a problem with the values retrieved from the Sendcloud API call, more specifically the `available_functionalities` > `last_mile` value.

The Sendcloud API (of both previous and current beta version) specifies the possible values to only be the following
- `home_delivery`
- `mailbox`
- `pobox`
- `service_point`
- null
https://api.sendcloud.dev/docs/sendcloud-public-api/shipping-options/operations/create-a-shipping-option
https://api.sendcloud.dev/docs/sendcloud-public-api/branches/v2/shipping-products/operations/list-shipping-products

However, it seems like they have added some new undocumented values `locker` and `locker_or_service_point`.

To detect whether to use drop-off locations, we do
https://github.com/odoo/enterprise/blob/5b64c63301bc814c7c9d99146af6a86d37563762/website_delivery_sendcloud/models/delivery_sendcloud.py#L51-L53

Where we compare the retrieved value with the string 'Service point'
https://github.com/odoo/enterprise/blob/5b64c63301bc814c7c9d99146af6a86d37563762/website_delivery_sendcloud/models/delivery_sendcloud.py#L13

In our "Locker or service point" case, this does not work because the `in` operator makes a case sensitive comparison.

Solution
-----
Functionally, both lockers and service points work the same. The user should be prompted a map on which they choose where the delivery should be dropped off.

So we can add `Locker` and `Locker or service point` as accepted values and enable the use of sendcloud locations for both.

-----
Ticket:
opw-5217796

### State of the art:

Control point for the manufacturing operation type are not expected to create QC when they refer to components.

### Steps to reproduce:

- Create a BOM for a final product FP:
    - 1 X COMP (consumable)
- Create a Quality Control Point:
    - Control: Quanity
    - Operations: Manufacturing
    - Product: COMP
- Create and confirm an MO for 1 unit of FP
#### > A QC is created for the component

### Cause of the issue:

Quantity quality checks related to MOs are expected to be created by `_create_quality_checks_for_mo`, which ensures that only moves referring to the production are considered:
https://github.com/odoo/enterprise/blob/931779b845291e1dc7efdea91d91bdfa5ab703d6/quality_mrp/models/stock_move.py#L23-L29
However, each time a `stock.move.line` is created, it triggers the related "quantity" control points if it is not filtered out of the applicable lines:
https://github.com/odoo/enterprise/blob/931779b845291e1dc7efdea91d91bdfa5ab703d6/quality_control/models/stock_move_line.py#L28-L35
The issue is that move lines related to `move_raw_ids` are always considered applicable:
https://github.com/odoo/enterprise/blob/931779b845291e1dc7efdea91d91bdfa5ab703d6/quality_mrp/models/stock_move_line.py#L31-L34
and that the `_create_check` triggers "quantity" control points that directly refer to the `product_id` of the move line:
https://github.com/odoo/enterprise/blob/931779b845291e1dc7efdea91d91bdfa5ab703d6/quality_control/models/stock_move_line.py#L79-L88

Note, however, that `_create_check` ignores control points of move lines related to a raw move if they do not refer to any product_ids, due to `_get_quality_points_all_products` (which is only called to find control points without a set `product_ids`):
https://github.com/odoo/enterprise/blob/931779b845291e1dc7efdea91d91bdfa5ab703d6/quality_mrp/models/stock_move_line.py#L20-L24
This explains why the test `test_04_quality_check_on_quantity` did not trigger the creation of quality checks for components.

### opw-5137594

In some customer databases, the `custom_handler_model_name` or its fallback `root_report_id.custom_handler_model_name` may point to a model that no longer exists (e.g. `l10n_il.tax.report.handler`). https://github.com/odoo/enterprise/blob/7410249cfdfaca19769e1c9aed813666af8eb19d/account_reports/models/account_report.py#L2578

The previous implementation returned this model name directly without checking if it was registered, which caused a KeyError during report access.

This fix validates the model presence in `self.env` before returning it, and falls back to None if missing. This ensures stable behavior when localization or custom modules are removed or renamed during upgrades.

```python3
Traceback (most recent call last):
  File "/home/odoo/src/odoo/17.0/odoo/service/server.py", line 1374, in preload_registries
    registry = Registry.new(dbname, update_module=update_module)
  File "<decorator-gen-16>", line 2, in new
  File "/home/odoo/src/odoo/17.0/odoo/tools/func.py", line 87, in locked
    return func(inst, *args, **kwargs)
  File "/home/odoo/src/odoo/17.0/odoo/modules/registry.py", line 110, in new
    odoo.modules.load_modules(registry, force_demo, status, update_module)
  File "/home/odoo/src/odoo/17.0/odoo/modules/loading.py", line 519, in load_modules
    migrations.migrate_module(package, 'end')
  File "/home/odoo/src/odoo/17.0/odoo/modules/migration.py", line 221, in migrate_module
    exec_script(self.cr, installed_version, pyfile, pkg.name, stage, stageformat[stage] % version)
  File "/home/odoo/src/odoo/17.0/odoo/modules/migration.py", line 239, in exec_script
    migrate(cr, installed_version)
  File "/home/odoo/src/odoo/17.0/addons/l10n_il/migrations/1.1/end-migrate_update_taxes.py", line 8, in migrate
    env['account.chart.template'].try_loading('il', company)
  File "/home/odoo/src/odoo/17.0/addons/account/models/chart_template.py", line 155, in try_loading
    return self._load(template_code, company, install_demo)
  File "/home/odoo/src/odoo/17.0/addons/account/models/chart_template.py", line 214, in _load
    self._post_load_data(template_code, company, template_data)
  File "/home/odoo/src/enterprise/17.0/account_reports/models/chart_template.py", line 31, in _post_load_data
    company._get_and_update_tax_closing_moves(fields.Date.today(), include_domestic=True)
  File "/home/odoo/src/enterprise/17.0/account_reports/models/res_company.py", line 163, in _get_and_update_tax_closing_moves
    report, tax_closing_options = tax_closing_move._get_report_options_from_tax_closing_entry()
  File "/home/odoo/src/enterprise/17.0/account_reports/models/account_move.py", line 272, in _get_report_options_from_tax_closing_entry
    report_options = tax_report.with_context(allowed_company_ids=company_ids).get_options(previous_options=options)
  File "/home/odoo/src/enterprise/17.0/account_reports/models/account_report.py", line 1670, in get_options
    initializer(options, previous_options=previous_options)
  File "/home/odoo/src/enterprise/17.0/account_reports/models/account_report.py", line 1619, in _init_options_custom
    self.env[custom_handler_model]._custom_options_initializer(self, options, previous_options)
  File "/home/odoo/src/odoo/17.0/odoo/api.py", line 550, in __getitem__
    return self.registry[model_name](self, (), ())
  File "/home/odoo/src/odoo/17.0/odoo/modules/registry.py", line 209, in __getitem__
    return self.models[model_name]
KeyError: 'l10n_il.tax.report.handler'

 select a.id,a.name,a.custom_handler_model_id,d.name,d.module,d.create_date,d.write_date from account_report a JOIN ir_model_data d on a.id = d.res_id where d.name = 'vat_report' and d.mod
 el = 'account.report';
+----+----------------------------------+-------------------------+------------+---------+----------------------------+----------------------------+
| id | name                             | custom_handler_model_id | name       | module  | create_date                | write_date                 |
|----+----------------------------------+-------------------------+------------+---------+----------------------------+----------------------------|
| 4  | {"en_US": "VAT Report (PCN874)"} | 770                     | vat_report | l10n_il | 2023-02-05 09:42:05.581858 | 2025-06-25 09:19:46.431141 |
+----+----------------------------------+-------------------------+------------+---------+----------------------------+----------------------------+
SELECT 1
Time: 0.106s
select m.id,m.model,m.name,d.name,d.module from ir_model m JOIN ir_model_data d on m.id = d.res_id where d.res_id = 770 and d.model = 'ir.model';
+-----+----------------------------+------------------------------------------------+----------------------------------+-----------------+
| id  | model                      | name                                           | name                             | module          |
|-----+----------------------------+------------------------------------------------+----------------------------------+-----------------|
| 770 | l10n_il.tax.report.handler | {"en_US": "Israely Tax Report Custom Handler"} | model_l10n_il_tax_report_handler | l10n_il_reports |
+-----+----------------------------+------------------------------------------------+----------------------------------+-----------------+
SELECT 1
Time: 0.009s
select id,name,author,latest_version,state,demo from ir_module_module where name='l10n_il_reports';
+-----+-----------------+-----------+----------------+-----------+-------+
| id  | name            | author    | latest_version | state     | demo  |
|-----+-----------------+-----------+----------------+-----------+-------|
| 997 | l10n_il_reports | Odoo S.A. | 16.0.1.7.2     | installed | False |
+-----+-----------------+-----------+----------------+-----------+-------+
SELECT 1
Time: 0.009s
```

**### There are some upgrade-specific PR**

<img width="1230" height="64" alt="2025-11-12_17-47" src="https://github.com/user-attachments/assets/0f75d3e0-1c95-48bf-adb6-41473f3f1da2" />


opw-5229611
upg-3258991

*(Tested with the `l10n_be` localization)*

1. Enable multicurrency. Set the main currency to EUR and create the following USD exchange rates:
   - **01/01/2025**: 1.1 USD per EUR
   - **06/30/2025**: 1.2 USD per EUR
   - **07/01/2025**: 1.3 USD per EUR

2. Create a new account in the Chart of Accounts:
   - **Code**: 550012
   - **Name**: Bank USD
   - **Type**: Bank and Cash
   - **Account Currency**: USD

3. Create a journal:
   - **Name**: Bank USD
   - **Bank Account**: 550012 Bank USD
   - **Currency**: USD

4. From the Accounting dashboard, create a bank transaction in Bank USD:
   - **Date**: 04/09/2025
   - **Amount**: 5000.0

5. Generate the adjustment entry in the *Unrealized Currency Gains/Losses* report:
   - **Journal**: Exchange Difference
   - **Expense Account**: 654000 Exchange Results
   - **Income Account**: 754000 Income Account

---

In the *Bank Reconciliation* report for Bank USD, a line appears under *Misc. operations* for an amount of **37.87**.
This line should not be there: clicking on it shows that it corresponds to exchange rate lines that fully cancel each other out and have a zero `amount_currency`.

---

In `_report_custom_engine_misc_operations`, the amount of misc. operation lines is computed by summing their balances converted to the company currency. However, even when `amount_currency` is 0, a conversion still occurs.

opw-4938249