Issue:
After installing the US chart of accounts, a few accounts still receive numeric codes on new 19.3 SaaS databases, for example: Bank Suspense Account (1014) Bank journal default account (1015)
Outstanding Receipts (1016)
Funds in Transit (1017)
Outstanding Payments (1018)

The rest of the chart has no codes, as intended.

Steps to reproduce:
1) Create a clean database on 19.3
2) Install accounting with United States localization (l10n_us / l10n_us_account) 3) accounting > configuration > fiscal position set to US 4) Open Accounting > Chart of Accounts 5) Observe that some bank accounts (and the Bank journal account) have codes 1014–1018 while other accounts have no code

Cause:
this commit https://github.com/odoo/odoo/pull/253759/changes/45d29f576baea0f92552af04229e1049037f8271 removed US account codes from the US CSV and set `code_digits` to 0: https://github.com/odoo/odoo/blob/73252cd9bfaa07ea004f7ac82a68afa558c09e9c/addons/l10n_us_account/models/template_us.py#L9-L13

Those accounts are not in the US CSV, Core account still creates them using company bank/cash/transfer prefixes, so they were the only ones that kept getting codes, because `code_digits` is 0, `len(prefix) < 0` is always false, so the code becomes the prefix itself (1014, 1015, 1017, ...) https://github.com/odoo/odoo/blob/73252cd9bfaa07ea004f7ac82a68afa558c09e9c/addons/account/models/account_account.py#L1059

Solution:
- Set `bank_account_code_prefix`, `cash_account_code_prefix`, and `transfer_account_code_prefix` to `False` in the US chart template company data so those auto created accounts get no prefix and no generated code.

opw-6211806

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

The CTE `model_fees` is supposed to get the reconciliation models that match conditions that involves a join with the ir.model.data table. One of these conditions is filtering based on the `name` field with an `LIKE` operator.

On databases that has a GIST index on the field `name`, the planner will prefer to filter the records based using the GIST index and add the extra filters as a filtering criteria after the index condition if the index-condition wasn't possible to be switched to a range-query. The condition is supposed to be a prefix-matching, which can be evaluated directly by a B-TREE if the field had an index and the planner can convert the condition to a range-query.

Apparently the `_` in `account_reco_models_fees_%%` was evaluated as a wild-card, making the condition a substring-matching rather than direct prefix-matching. In this PR, I have modified the condition to escape the '_' wildcards.

The benchmark done below was on a database that has around **10^7** `ir.model.data` records and 1K `account.reconciliation.model` records. I have split the benchmark into two cases, a case where the buffer-pool of
postgres warmed-up and a case where it is not.

After Worst case -> https://explain.dalibo.com/plan/975geg1f1h109d5c
Before Worst case -> https://explain.dalibo.com/plan/0ce9bf3g0ad8f98b

After Best Case -> https://explain.dalibo.com/plan/1a77459dadb0gfc4

Definition of ir_model_data_name_idx2  -> CREATE INDEX ir_model_data_name_idx2 ON public.ir_model_data USING gist (name gist_trgm_ops)

Definition of ir_model_data_module_name_uniq_index -> CREATE UNIQUE INDEX ir_model_data_module_name_uniq_index ON public.ir_model_data USING btree (module, name)


| PostgreSQL Buffer Pool Status | Before | After |
| :--- | :--- | :--- |
| Not warmed up (Cold) | 11s | 130ms |
| Warmed up (Hot) | 0.022ms | 0.097ms |

Forward-Port-Of: odoo/enterprise#117746

### Issue
In the Italian annual tax report, both VL3/VL4 and VL32/VL33 values could be displayed at the same time

However, according to the report logic, only the positive balance should be shown for each pair:
- VL3 (Tax Due) or VL4 (Tax Credit)
- VL32 (Tax Due) or VL33 (Tax Credit)

The other one should stay 0
If the global balance is null, both can be 0

### Cause
The lines VL3, VL4, VL32, and VL33 were using the shortcut field `aggregation_formula` directly on the `account.report.line` record
This shortcut format does not evaluate or support conditional subformulas like `if_above(EUR(0))`
As a result, the report computed and displayed both lines of each pair without filtering out the negative or unwanted values

### Steps to reproduce
- Install `l10n_it` and `accountant` and switch to IT Company
- Create a balanced Journal Entry for any account
- Add the Tax Grid v20 on one of the lines to impact the annual report
- Open the `Annual Tax Report (IT)` 
- Go to the `VL` section
- Check the value of VL3/VL4 and VL32/VL33
After the fix, only one value can be positive and the other 0

Ticket [link](https://www.odoo.com/odoo/project.task/6212694)
opw-6212694

Forward-Port-Of: odoo/odoo#264294

*: html_editor, html_builder

### Commit 1:
[FIX] html_editor, website: improve helper util setSelection and tests
**Before this commit**: after the selection restriction commit (https://github.com/odoo/odoo/commit/d09c8fd428315b8c3bf08c43d55da50fcd77f2ae),
the tests have to dispatch events specifically to mimic the selection
made by mouse.

**After this commit:** we improve the setSelection helper to include a flag
isMouseEventSimulated and simplify the tests.

task-6143995


### Commit 2:
[FIX] html_builder*: improve selection correction for nested uncrossable
*: website

**Before this commit:** correctSelectionOnUncrossable is not exhaustive for
complex html snippets. When there are multiple uncrossable elements in
the selection, and there's a parent uncrossable element including other
uncrossable ones, the selection is only restricted on the parent
uncrossable element.

We had a fix for the select all behavior but not for mouse selection.
Reproduction:
- Have a blockquote snippet with some text around it
- Select the text from the blockquote to the text after it => it will
keep the authors info selected
- And then, if I click on the text, the selection will restrict to the
text without the author infos

**After this commit:** We now always correct the selection on uncrossable in
an iterative way, until the selection is not corrected anymore or a
maximum of attempts is reached.

We didn't use the loop condition like previously done. Because there can
still be an uncrossable inside the selection, when the closest
uncrossable elements of the focus node and anchor node are the same.
Instead, we stop the looping when the selection isn't being corrected
anymore.

task-6143995



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

Description of the issue/feature this PR addresses:

Prevent an internal server error when a customer cancels a Redsys payment
and returns to Odoo.

Current behavior before PR:

When the customer cancels the payment from the Redsys checkout page,
Redsys redirects back to Odoo without the `Ds_MerchantParameters`
parameter.

The payment flow assumes the parameter is always present and tries to
decode it unconditionally, causing an internal server error.

Desired behavior after PR is merged:

Odoo gracefully handles payment cancellations when
`Ds_MerchantParameters` is missing from the callback parameters.

The customer is redirected correctly without triggering a server error.

Steps to reproduce:

1. Install the Redsys payment provider.
2. Configure a test environment.
3. Create a sales order or invoice.
4. Start the payment process.
5. Cancel the payment from the Redsys checkout page.
6. Return to Odoo.
7. Observe the internal server error caused by the missing
   `Ds_MerchantParameters` parameter.


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

Forward-Port-Of: odoo/odoo#265655

### Issue
In the Italian annual tax report, both VL3/VL4 and VL32/VL33 values could be displayed at the same time

However, according to the report logic, only the positive balance should be shown for each pair:
- VL3 (Tax Due) or VL4 (Tax Credit)
- VL32 (Tax Due) or VL33 (Tax Credit)

The other one should stay 0
If the global balance is null, both can be 0

### Cause
The lines VL3, VL4, VL32, and VL33 were using the shortcut field `aggregation_formula` directly on the `account.report.line` record
This shortcut format does not evaluate or support conditional subformulas like `if_above(EUR(0))`
As a result, the report computed and displayed both lines of each pair without filtering out the negative or unwanted values

### Steps to reproduce
- Install `l10n_it` and `accountant` and switch to IT Company
- Create a balanced Journal Entry for any account
- Add the Tax Grid v20 on one of the lines to impact the annual report
- Open the `Annual Tax Report (IT)` 
- Go to the `VL` section
- Check the value of VL3/VL4 and VL32/VL33
After the fix, only one value can be positive and the other 0

Ticket [link](https://www.odoo.com/odoo/project.task/6212694)
opw-6212694

Forward-Port-Of: odoo/odoo#264294

Problem: When both line discounts and global discounts are applied on a product in an invoice, the method `_add_and_round_raw_gross_total_excluded_and_discount` does not return the exact raw_gross_total_excluded before the modification done by other AccountTax helper methods, such as dispatching and squashing global discount lines.

Current Behavior: The calculation is done in the wrong order of operations. For example, there is an invoice for Product A valued at $100 with a discount of 10% and a global discount of $10. The raw_total_excluded will be $80 after the both discounts. The discount_factor is based on only the line discount of 10%. The formula of the current calculation for raw_gross_total_excluded is: (raw_total_excluded / (1 - (line_discount / 100))) - global_discount = (80 / 0.90) - (-10)
= 98.889
This does not equal the expected outcome of $100.

Expected Behavior: Based on the previous example, the formula for the calculation should be:
(raw_total_excluded - global_discount) / (1 - (line_discount/100)) = (80 - (-10)) / 0.9
= 100
The global discount needs to be added back to the raw_total_excluded to get the line discounted amount in order to divide by the discount_factor to gain the expected raw_gross_total_excluded before taxes and discounts.

Steps to reproduce the issue:
- Bug was encountered when implementing a global discount solution for l10n_co_dian.
- Create an invoice with a product line and in-line discount and another line for global discount
- Setup the base lines for the invoice and attempt the following:
 - _dispatch_global_discount_lines
 - _squash_global_discount_lines
 - _add_and_round_raw_gross_total_excluded_and_discount

opw-5412446


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

Forward-Port-Of: odoo/odoo#266584
Forward-Port-Of: odoo/odoo#262137

Issue
Upon initialization of the pos a PaymentInterface is constructed for every pos_payment_method (even archived pos payment methods ?!). [As we allow only one WebSocket subscription per channel](https://github.com/odoo/odoo/blob/4e1c89890c5fd54a79dcf5bf20268e51d8fe6e69/addons/point_of_sale/static/src/app/utils/payment/payment_interface.js#L100) for the PaymentInterface, all webhook responses will be linked to only one PaymentInterface. Meaning that when you have two Mercado Pago pos_payment_method terminals configured, only the first pos_payment_method (id=1) will be subscribed to the WebSocket and all the webhook responses from the second pos_payment_method terminal (id=2) will arrive to the PayementInterface of the first pos_payment_method (id=1). Where payload.payment_method_id (id=2) != this.payment_method_id.id (id=1).

Solution
- Only iterate and create a PaymentInterface for compatible pos_payment_methods which are active
- Check if the webhook response is linked to the PendingPaymentLine

opw-6069455

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

Description of the issue/feature this PR addresses:

Prevent an internal server error when a customer cancels a Redsys payment
and returns to Odoo.

Current behavior before PR:

When the customer cancels the payment from the Redsys checkout page,
Redsys redirects back to Odoo without the `Ds_MerchantParameters`
parameter.

The payment flow assumes the parameter is always present and tries to
decode it unconditionally, causing an internal server error.

Desired behavior after PR is merged:

Odoo gracefully handles payment cancellations when
`Ds_MerchantParameters` is missing from the callback parameters.

The customer is redirected correctly without triggering a server error.

Steps to reproduce:

1. Install the Redsys payment provider.
2. Configure a test environment.
3. Create a sales order or invoice.
4. Start the payment process.
5. Cancel the payment from the Redsys checkout page.
6. Return to Odoo.
7. Observe the internal server error caused by the missing
   `Ds_MerchantParameters` parameter.


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

Forward-Port-Of: odoo/odoo#265655

Currently an error is generated when the user tries to cancel a
draft POS order as follows:

- Install the `pos_enterprise` module with demo data
- Open the register of `Furniture store` and select any product
- Click on the `Upload` icon to save the draft order and go to the backend.
- Navigate Orders > Orders > open Draft order
- Click the `cog` icon and click `Cancel Order` >>> Error occurs

This issue is caused by the recent refactor introduced in [1]. The
`action_pos_order_cancel` action now returns the `order`
(`pos.order` recordset) instead of default returning `None`.

As a result, the `action` variable contains a `pos.order` recordset, and
an error is raised at line [2] when `setdefault` is called on it, since
`setdefault` expects a dictionary-like object.

This commit fixes the above issue by removing the code that returns the
`pos.order` object from the action. As a result, the action now behaves
as expected and returns the default value (`None`).


[1]: https://github.com/odoo/enterprise/commit/27f57036a1d0468efe6e68d7aceafe0f01b21f93
[2]: https://github.com/odoo/odoo/blob/48f93ca056633bd5cba36b66ee1008fb57ca666c/addons/web/controllers/utils.py#L24

Sentry-7354160052

### Issue
In the Italian annual tax report, both VL3/VL4 and VL32/VL33 values could be displayed at the same time

However, according to the report logic, only the positive balance should be shown for each pair:
- VL3 (Tax Due) or VL4 (Tax Credit)
- VL32 (Tax Due) or VL33 (Tax Credit)

The other one should stay 0
If the global balance is null, both can be 0

### Cause
The lines VL3, VL4, VL32, and VL33 were using the shortcut field `aggregation_formula` directly on the `account.report.line` record
This shortcut format does not evaluate or support conditional subformulas like `if_above(EUR(0))`
As a result, the report computed and displayed both lines of each pair without filtering out the negative or unwanted values

### Steps to reproduce
- Install `l10n_it` and `accountant` and switch to IT Company
- Create a balanced Journal Entry for any account
- Add the Tax Grid v20 on one of the lines to impact the annual report
- Open the `Annual Tax Report (IT)` 
- Go to the `VL` section
- Check the value of VL3/VL4 and VL32/VL33
After the fix, only one value can be positive and the other 0

Ticket [link](https://www.odoo.com/odoo/project.task/6212694)
opw-6212694

Forward-Port-Of: odoo/odoo#264294

Problem: When both line discounts and global discounts are applied on a product in an invoice, the method `_add_and_round_raw_gross_total_excluded_and_discount` does not return the exact raw_gross_total_excluded before the modification done by other AccountTax helper methods, such as dispatching and squashing global discount lines.

Current Behavior: The calculation is done in the wrong order of operations. For example, there is an invoice for Product A valued at $100 with a discount of 10% and a global discount of $10. The raw_total_excluded will be $80 after the both discounts. The discount_factor is based on only the line discount of 10%. The formula of the current calculation for raw_gross_total_excluded is: (raw_total_excluded / (1 - (line_discount / 100))) - global_discount = (80 / 0.90) - (-10)
= 98.889
This does not equal the expected outcome of $100.

Expected Behavior: Based on the previous example, the formula for the calculation should be:
(raw_total_excluded - global_discount) / (1 - (line_discount/100)) = (80 - (-10)) / 0.9
= 100
The global discount needs to be added back to the raw_total_excluded to get the line discounted amount in order to divide by the discount_factor to gain the expected raw_gross_total_excluded before taxes and discounts.

Steps to reproduce the issue:
- Bug was encountered when implementing a global discount solution for l10n_co_dian.
- Create an invoice with a product line and in-line discount and another line for global discount
- Setup the base lines for the invoice and attempt the following:
 - _dispatch_global_discount_lines
 - _squash_global_discount_lines
 - _add_and_round_raw_gross_total_excluded_and_discount

opw-5412446


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

Forward-Port-Of: odoo/odoo#266584
Forward-Port-Of: odoo/odoo#262137

When having an horizontal group with domain including two companies that
share the same account codes, report lines with account codes engine
don't display the two companies values when both are selected in the
company selector.

Steps to reproduce:

- Install l10n_ch and create two CH companies (CH1 and CH2)
- Create an horizontal group with the field 'Company' and domain '["|",
  ("name", "=", "CH Company"), ("name", "=", "CH 2")]"
- Apply the Horizontal group to CH balance sheet report
- Select both companies in the company selector
- Open CH BS report and activate the horizontal group
-> Only the column of one company is filled

Fix:

https://github.com/odoo/enterprise/commit/9b775ed9d8b2a18e708219c72e95652571f3936a
was introduced in 19.0 to fix the same issue, we fix by backporting it
but we also need to backport this perf commit https://github.com/odoo/enterprise/commit/7da3123dc4487a7092deef8503a9791ceffddcfb
that refactored the code before in a first place

opw-6204601

Forward-Port-Of: odoo/enterprise#118544
Forward-Port-Of: odoo/enterprise#117103

### Issue
In the Italian annual tax report, both VL3/VL4 and VL32/VL33 values could be displayed at the same time

However, according to the report logic, only the positive balance should be shown for each pair:
- VL3 (Tax Due) or VL4 (Tax Credit)
- VL32 (Tax Due) or VL33 (Tax Credit)

The other one should stay 0
If the global balance is null, both can be 0

### Cause
The lines VL3, VL4, VL32, and VL33 were using the shortcut field `aggregation_formula` directly on the `account.report.line` record
This shortcut format does not evaluate or support conditional subformulas like `if_above(EUR(0))`
As a result, the report computed and displayed both lines of each pair without filtering out the negative or unwanted values

### Steps to reproduce
- Install `l10n_it` and `accountant` and switch to IT Company
- Create a balanced Journal Entry for any account
- Add the Tax Grid v20 on one of the lines to impact the annual report
- Open the `Annual Tax Report (IT)` 
- Go to the `VL` section
- Check the value of VL3/VL4 and VL32/VL33
After the fix, only one value can be positive and the other 0

Ticket [link](https://www.odoo.com/odoo/project.task/6212694)
opw-6212694

Forward-Port-Of: odoo/odoo#264294

**Problem:**
When a branch user with no access to the parent company tries to create a transaction for a parent company's journal with a foreign currency set, this will raise an access error.

**Steps to Reproduce:**
- Make a branch of "My Company (San Francisco)"
- Set user "Marc Demo" to only have access to the branch
- Add a new bank journal set to "EUR" currency
- Switch to Marc Demo
- Try to add a transaction in the new bank journal

**Root Cause:**
When a transaction is created, Odoo determines the amount in company currency by converting it from the foreign currency. The method to convert currency uses "with_company()" to use the company's rates, but the allowed companies of the branch user does not have access to the parent company, causing an access error.

**Solution:**
Call the currency conversion with sudo() to ensure access to the relevant companies.

Ticket [link](https://www.odoo.com/odoo/project.task/6186901)
opw-6186901

Forward-Port-Of: odoo/odoo#263668
Forward-Port-Of: odoo/odoo#263425

### Description of the issue/feature this PR addresses:
Prevent Out of Memory (OOM) crashes and drastically improve execution speed when generating the Swedish SIE4 verification export for massive datasets.

### Current behavior before PR:
When exporting a large volume of journal entries (e.g., 190,000+ account moves), the `_export_l10n_se_sie4_verification` method relies on iterating through heavy ORM recordsets and accessing relational child fields (move.line_ids) inside a loop. This triggers a severe N+1 query problem, maxing out server RAM and causing an OOM crash.

### Desired behavior after PR is merged:
The method now utilizes a hybrid data extraction approach:
- The ORM is used strictly to safely evaluate domains (multi-company rules, dates, states) and fetch a lightweight list of valid move_ids.
- A single SQL query with JOIN statements fetches all parent moves, child lines, and account codes in exactly one database query.
- itertools.groupby chunks the flat, lightweight dictionary results back into their respective journal entries.
The export now handles massive datasets in seconds with minimal memory overhead, while remaining perfectly secure.

### Benchmark:

For Memory:
| # Input Data | Before PR | After PR |
| -------- | -------- | -------- |
| ~190,000 moves | MemoryError | 407MB|
| ~200,000 moves | 1.8GB | 174.8 MB|

For Speed:
| # Input Data | Before PR | After PR |
| -------- | -------- | -------- |
| ~190,000 moves | MemoryError | 5.10s |
| ~200,000 moves | 1m29s| 5.3s|

### Reference:
opw-6067999

Forward-Port-Of: odoo/enterprise#117577
Forward-Port-Of: odoo/enterprise#113227

Issue:
Cancelled journal entries were visible in the "Journal Items to Reconcile" view (action_move_line_posted_unreconciled) because the action domain had no filter to exclude them. This caused reconciliation failures, no reconciliation happened, and the cancelled record remained in the view.

This regression was introduced during a refactor to allow draft entries in the reconciliation view, where the posted-state condition was removed from the domain:

Enterprise commit: https://github.com/odoo/enterprise/commit/003cffabda7d91a6d10d58942ed972ca5e17366d

As a result, cancelled journal items also became visible, causing reconciliation attempts to fail while the records remained in the view.

Also, we are not allowed to reconcile cancelled move lines, and we already
have the validation for this [here](https://github.com/odoo/odoo/blame/a236f67776616f6facdefb0117a6ffdde9b7c84c/addons/account/models/account_move_line.py#L2627)

Issue is reproducible on runbot. Here is the video reference: https://drive.google.com/file/d/1ojIDxHn5Yst8gVFy8JyhwtJoDSSSJsmK/view?usp=sharing

- OPW: 6247870

**Steps to reproduce:**
- Install documents_account
- Set up alias to catch incoming mails
- Receive a mail with xml attachement which can be previewed as pdf
- Go to Documents app
- Click on the document preview
- Preview is split in two iframes, both with the same content (pdf)

**Issue:**
Due to the `isPdf` patch the attachment can match multiple types for the preview (pdf and text) as both getter return `true`.
```
<iframe t-if="state.file.isPdf" ...
<iframe t-if="state.file.isText" ...
```

It also seems that xml received by mail are imported as text, which is why the issue doesn't happen when manually uploading the same xml file.

**Fix:**
Ensure that if the document is matching `isPdf`, it doesn't trigger the second iframe with `isText`.

Also it seems fixed in 19.0 as the text iframe is replaced by this xpath: 
`<xpath expr="//iframe[@t-if='state.file.isText']" position="replace">`
which was added for https://github.com/odoo/enterprise/commit/de614ee5e9a087d49939c65c0118ae6164c7b31b

related patch: https://github.com/odoo/enterprise/commit/ffcdd2275c8bf564e15151ccbcaf3965ed968450

opw-6018536

Forward-Port-Of: odoo/enterprise#114759
Forward-Port-Of: odoo/enterprise#112041

Step to reproduce:
- install "pos_settle_due"
- create a pos order, set order price = 0, select a customer
- go to payment page, select "customer account" as payment method
- here you can set any amount to pay, ex 100$
- fulfill the  order.

Observation:
- the order amount is 0, if we pay 100$ using customer account, it is considered as change (which means we returned it to customer)
- As per PO, this flow doesn't make sense

Issue:
- customer has 100$ due for this order, but he won't be able to settle this as fetch order to settle with amount != 0, after commit [1] 
- [1] https://github.com/odoo/enterprise/commit/12af23d5382e972facfaa999e4c5ab30c97e8d1f

https://github.com/odoo/enterprise/blob/951e5f42884c898bc14d9c32ae6a8f08c31ff06d/pos_settle_due/static/src/app/screens/partner_list/partner_line/partner_line.js#L35

Fix:
- we hide payment method of type "pay_later" in case of 0 price order

opw-6123699

Forward-Port-Of: odoo/enterprise#118093
Forward-Port-Of: odoo/enterprise#116556

### Description of the issue/feature this PR addresses:
Prevent Out of Memory (OOM) crashes and drastically improve execution speed when generating the Swedish SIE4 verification export for massive datasets.

### Current behavior before PR:
When exporting a large volume of journal entries (e.g., 190,000+ account moves), the `_export_l10n_se_sie4_verification` method relies on iterating through heavy ORM recordsets and accessing relational child fields (move.line_ids) inside a loop. This triggers a severe N+1 query problem, maxing out server RAM and causing an OOM crash.

### Desired behavior after PR is merged:
The method now utilizes a hybrid data extraction approach:
- The ORM is used strictly to safely evaluate domains (multi-company rules, dates, states) and fetch a lightweight list of valid move_ids.
- A single SQL query with JOIN statements fetches all parent moves, child lines, and account codes in exactly one database query.
- itertools.groupby chunks the flat, lightweight dictionary results back into their respective journal entries.
The export now handles massive datasets in seconds with minimal memory overhead, while remaining perfectly secure.

### Benchmark:

For Memory:
| # Input Data | Before PR | After PR |
| -------- | -------- | -------- |
| ~190,000 moves | MemoryError | 407MB|
| ~200,000 moves | 1.8GB | 174.8 MB|

For Speed:
| # Input Data | Before PR | After PR |
| -------- | -------- | -------- |
| ~190,000 moves | MemoryError | 5.10s |
| ~200,000 moves | 1m29s| 5.3s|

### Reference:
opw-6067999

Forward-Port-Of: odoo/enterprise#117577
Forward-Port-Of: odoo/enterprise#113227

The "show only 1 month at a time" optimization computes the navigated month as datetime.now() + month_id, so the controller passes that (month, year) tuple to _get_appointment_slots:

https://github.com/odoo/enterprise/blob/57ec37b74a60c7e879a8afa66df5ab22a92c5bcd/appointment/models/appointment_type.py#L833

For a punctual appointment whose Allow Bookings range starts in a future month, the first displayed month is start_datetime.month, so the (month, year) tuple doesn't match the month the visitor is looking at. The model fills an empty month and the recovery loop refills the first displayed month (where slots actually live):

https://github.com/odoo/enterprise/blob/57ec37b74a60c7e879a8afa66df5ab22a92c5bcd/appointment/models/appointment_type.py#L973-L988

The calendar the visitor just navigated to comes back empty.

Compute the navigation base from start_datetime when it lies in the future and keep datetime.now() otherwise. month_id is added on top of that base so it always matches the displayed month index.

Introduced by https://github.com/odoo/enterprise/commit/664857dd2c4ae2bc0dde8f44cb94136659ed2fe2

Steps to reproduce:
1. Open the Appointments app
2. Open an appointment type and set Schedule to Weekly and Allow Bookings to On specific dates with a range starting in a future month (for example 1 September to 31 December)
3. Save and click the Preview button in the header
4. Pick a staff member to reach the calendar
5. Click the right arrow to navigate to the next month

=> the next month shows "Sorry, we have no more slots available for this month"

opw-6206293

France’s electronic invoicing reform : The tax administration  needs structured fiscal data for the transactions , either via E-invoicing for the nationals B2B or E-reporting for the international B2B and the B2C.

This creates two complementary obligations:

- **E-invoicing** for domestic B2B transactions, where the invoice itself is exchanged through the PA/Peppol flow.
- **E-reporting** for transactions outside that domestic B2B scope, mainly B2C and international B2B, where transaction and payment data must be reported to the tax administration through Flux 10 (period-based).

## Scope

Domestic B2B remains handled by the existing e-invoicing flow, because the invoice exchange already carries the required structured information.

Flux 10 is introduced for transactions that must be reported separately:

- B2C transactions, where there is no buyer-side e-invoice exchange.
- International B2B transactions, where the counterparty is outside the French domestic B2B mandate.
- Payment reporting when VAT exigibility depends on collection.

The reporting is period-based and keeps transaction reports separated from payment reports, because they answer different legal obligations and follow different timelines.

## Corrections and Lifecycle

Flux 10 supports both:

- **Initial reports**, for the first declaration of a period.
- **Rectificative reports**, when already reported data must be corrected or completed.

This distinction is needed so corrections remain traceable instead of silently mutating a report that may already have been transmitted.

## Security and Eligibility

This PR also enforces stronger safeguards before using PDP/PA services.

- **2FA is required** because PDP/PA actions expose regulated fiscal flows and should not be available from a simple password-only login. Email-based 2FA is available as a fallback when users have not configured an authenticator app.
- **KYC is introduced** because a company must be identified and validated before Odoo can transmit documents or reports on its behalf through the PDP/PA infrastructure.

Together, these changes make the French PDP/PA flow usable not only for invoice exchange, but also for the wider e-reporting obligations required by the French reform.


Task-4603708

### Description of the issue/feature this PR addresses: 
**Issue:** A recent update to support `certificateFingerprint` introduced a regression for existing users authenticating with standard certificates (AKA `certificateSubject`). Because the matching logic strictly checked for the company NIP within the certificate subject, it failed for users using personal PESEL certificates to act on a company's behalf. 

**Previous PR:** https://github.com/odoo/odoo/pull/264851 

**Solution:** Expanded the string-matching heuristic in the XML signer to strip formatting characters from the NIP and explicitly checks for standard Polish qualified certificate prefixes (VATPL and PNOPL) to accurately get the identifier type.

### Current behavior before PR: 
When a user logs in via a personal PESEL certificate for a company context, the NIP check fails and miscategorizes the payload as a `certificateFingerprint`. KSeF rejects this mismatch, causing a 400 error for previously working setups.

### Desired behavior after PR is merged: 
The authentication flow distinguishes between `certificateSubject` and `certificateFingerprint` by checking for valid Polish prefixes or exact cleaned NIP matches. Existing customers are restored to working order natively, and new customers using manual fingerprints are still supported without requiring any database or UI changes.

opw-6251153

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

**Steps to reproduce:**
1. Install l10n_es_edi_verifactu.
2. Switch to a ES company.
3. Create a customer invoice and send it to VeriFactu.
4. Enable Developer Mode.
5. Go to Settings > Technical > Sequences & Identifiers > Sequences.
6. Search for the `Sequence Code: l10n_es_edi_verifactu` and open it.
7. Set a prefix or suffix using any alphabetical character.
8. Create a new invoice and send it to VeriFactu

**Issue:**
Traceback on sending Veri*Factu:
`ValueError: invalid literal for int() with base 10: 'F260001'`

**Cause:**
The value returned by `ir.sequence.next_by_id()` may contain alphabetical characters (due to prefix/suffix), while the field `chain_index` expects an integer. The raw sequence value was directly assigned, causing the conversion to fail.

**Fix:**
Catch the ValueError raised by int() when the sequence value contains non-numeric characters (e.g. due to a prefix/suffix). Instead of crashing, surface a user-friendly error on the document telling the user to remove the prefix/suffix from the sequence configuration.

**opw-6037528**

**Issue:**
The printed receipt in Point of Sale displayed a negative change amount when the customer paid more than the order total.

**Before:**
The receipt showed the change as a negative value (e.g., `-$5,504.00`), which was misleading for customers.

**After:**
The receipt now correctly displays the change as a positive value (e.g., `$5,504.00`).

**Steps to Reproduce:**

1. Open a Point of Sale session
2. Add products to the cart (example total: `$49,496.00`)
3. Select the **Cash** payment method
4. Enter an amount greater than the order total (example: `$55,000.00`)
5. Observe that the **Change** field displays a negative value
6. Confirm the payment
7. Print the receipt and observe that the change amount is also negative

**Root Cause:**
The issue was caused by an unnecessary negation in the `export_for_printing()` method in `pos_order.js`.

The `get_change()` method already returns the correct positive change amount. However, the code applied an extra negation (`-this.get_change()`), which converted the value into a negative amount before rendering it on the receipt.

**Fix:**
Removed the unnecessary negation in `export_for_printing()` so the receipt now displays the correct positive change amount.

Video reproducing the issue: [[Click here to view the video](https://drive.google.com/file/d/1QnQ47qlTFvv98K0J_NzreBVeIh-J2XcF/view?usp=sharing)]

opw-6211988

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

### Issue
In the Italian annual tax report, both VL3/VL4 and VL32/VL33 values could be displayed at the same time

However, according to the report logic, only the positive balance should be shown for each pair:
- VL3 (Tax Due) or VL4 (Tax Credit)
- VL32 (Tax Due) or VL33 (Tax Credit)

The other one should stay 0
If the global balance is null, both can be 0

### Cause
The lines VL3, VL4, VL32, and VL33 were using the shortcut field `aggregation_formula` directly on the `account.report.line` record
This shortcut format does not evaluate or support conditional subformulas like `if_above(EUR(0))`
As a result, the report computed and displayed both lines of each pair without filtering out the negative or unwanted values

### Steps to reproduce
- Install `l10n_it` and `accountant` and switch to IT Company
- Create a balanced Journal Entry for any account
- Add the Tax Grid v20 on one of the lines to impact the annual report
- Open the `Annual Tax Report (IT)` 
- Go to the `VL` section
- Check the value of VL3/VL4 and VL32/VL33
After the fix, only one value can be positive and the other 0

Ticket [link](https://www.odoo.com/odoo/project.task/6212694)
opw-6212694

Forward-Port-Of: odoo/odoo#264294

### Steps to reproduce:

- In the settings enable: "Units of Measure & Packagings", "Storage Locations"
- Create a product in units and register 1 unit in stock
- Inventory > Operations > Adjustments > Physical Inventory
- Select your line and request a count > Set Current Value
- Inventory > Configurations > units of measures > UOM categories
- Select unit and archive it
- Go to the barcode app > Click Count inventory
### > Owl error: Uncaught promise

### Cause of the issue:

Since the uom used on the quant is archived, it is not found by the search used to fill the barcodeCache:
https://github.com/odoo/enterprise/blob/26546bcd3beebc7f65ce08385441b6284b46598e/stock_barcode/static/src/components/main.js#L209-L213 https://github.com/odoo/enterprise/blob/26546bcd3beebc7f65ce08385441b6284b46598e/stock_barcode/models/stock_quant.py#L104-L106 https://github.com/odoo/enterprise/blob/26546bcd3beebc7f65ce08385441b6284b46598e/stock_barcode/static/src/components/main.js#L229 https://github.com/odoo/enterprise/blob/26546bcd3beebc7f65ce08385441b6284b46598e/stock_barcode/static/src/models/barcode_model.js#L37-L39 However, if the uom is not present in the barcode cache the `BarcodeQautnModel` will fail to createLinesState whihc raises a missing error:
https://github.com/odoo/enterprise/blob/26546bcd3beebc7f65ce08385441b6284b46598e/stock_barcode/static/src/models/barcode_quant_model.js#L712 https://github.com/odoo/enterprise/blob/26546bcd3beebc7f65ce08385441b6284b46598e/stock_barcode/static/src/lazy_barcode_cache.js#L107-L110

opw-6250090

Steps to reproduce:
-------------------
1. Install `sale_project_stock` and Accounting.
2. Create a storable product with **Real-time valuation** and 
configure the COGS account in the product category expense account.
(Ensure you have enabled automatic & analytic accounting from accounting>config.)
3. Create a project with a specific analytic account and ensure the project is billable.
4. Create a sale order with the created product and set the same
analytic account in the analytic distribution.
5. Confirm the order, deliver the product, generate the invoice, and post it.
6. Open the project and go to the *Profitability* report.
7. Click on the **Cost of Goods Sold** dashboard item.
8. Repeat steps 4–7 with multiple invoices.

Issue:
------
When there is only one invoice, clicking the COGS dashboard item correctly
displays the related move lines. However, when there are multiple invoices,
the action opens with empty results.

Cause:
------
`_get_action_for_profitability_section` sets `res_id` only when a single record exists. 
When multiple records are present, `res_id` becomes `False`, which causes the action to open without results. https://github.com/odoo/odoo/blob/8f79d407724f40ba8e48f1747b2e87311b7fb49e/addons/project_account/models/project_project.py#L78-L83

Solution:
---------
When `res_id` is not set, search `account.move` records using the
domain to retrieve the relevant move IDs, then apply a proper domain
to display all related COGS journal items.


opw-5949261



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

**Issue**:
Non-purchasable products can still be found when searching using a vendor product code.

**Steps to reproduce**:
- Create a product
- Add a vendor with a vendor product code (use a code that does not match any product name)
- Untick the "can be purchased" box
- Create a PO with the same vendor
- Search for product using the vendor product code -> The product can be found while not purchasable

**Cause**:
While searching for a product, `_name_search` is called: https://github.com/odoo/odoo/blob/2083a2515c2855dd53991cbcc6e8b43c3e7f0256/addons/product/models/product_product.py#L543 If no product is found (which is very likely since we use vendor product code): https://github.com/odoo/odoo/blob/2083a2515c2855dd53991cbcc6e8b43c3e7f0256/addons/product/models/product_product.py#L580-L581 Then check all the vendor list associated to the vendor product code (`product_code`) and extract the associated product: https://github.com/odoo/odoo/blob/2083a2515c2855dd53991cbcc6e8b43c3e7f0256/addons/product/models/product_product.py#L582-L588 However, this fallback search does not reuse the original `domain`: https://github.com/odoo/odoo/blob/2083a2515c2855dd53991cbcc6e8b43c3e7f0256/addons/product/models/product_product.py#L543 therefore conditions such as `purchase_ok = True` are ignored.

**Solution**
Backport the fix from this commit: https://github.com/odoo/odoo/commit/c2d47b976d1ac0eba6bd16add3d54f84e5e2d3d3. And in particular:
https://github.com/odoo/odoo/blob/299b3b833a2198c6814141c037a9bd6c69f14ee3/addons/product/models/product_product.py#L647-L648

opw-6214085