Before this commit, the SQL query generated in `_get_aal_query` utilized a `LEFT JOIN` with a complex `OR` condition on the join clause: `(bl.company_id IS NULL OR bl.company_id = al.company_id)`.

Because this condition lacks a strict equality constraint, the planner cannot build a hash table for the join. Consequently, it is forced to fallback to a Nested Loop Join strategy, evaluating the condition as a filter for every row pair. This results in significant performance degradation on large datasets.

This commit optimizes the query by splitting the logic into two separate `SELECT` statements combined with a `UNION ALL`:
1. Matches where `company_id` is explicitly equal.
2. Matches where `company_id` is NULL.

By separating these conditions, the planner can now prioritize a Hash Join for the equality check and handle the NULL join separately, significantly reducing execution time.

References:
- Original PR introducing the logic: https://github.com/odoo/enterprise/pull/82955
- Plan Before (Join Filter): https://explain.dalibo.com/plan/a55476hgb73ea7g6#plan
- Plan After (Hash Cond): https://explain.dalibo.com/plan/3b9g484569a86efb#plan

opw-5460862

Forward-Port-Of: odoo/enterprise#104663
Forward-Port-Of: odoo/enterprise#104299

**Issue**:
The displayed available quantity on the ecommerce product page is incorrect for rental products when "continue selling" is enabled.

**Steps to reproduce**:
- Create a rental product tracked in stock with a quantity of 5
- Enable "continue selling" and "show available quantity below 10"
- Go to the ecommerce page of this product
- Rent 3 units for a given period, confirm and pay
- Return to the ecommerce product page
-> Whatever the selected renting period, the displayed quantity is always 2

**Cause**:
The website displays `free_qty`:
https://github.com/odoo/enterprise/blob/41c729e22c5fd1abb690f8335e933f793be0b319/website_sale_stock_renting/static/src/xml/website_sale_stock_renting_product_availability.xml#L15

`free_qty` is computed in:
https://github.com/odoo-dev/odoo/blob/0935829ddaecd7b2b6eec9157f8f790b546d06ff/addons/website_sale_stock/models/product_template.py#L36

which leads to:
https://github.com/odoo/enterprise/blob/41c729e22c5fd1abb690f8335e933f793be0b319/website_sale_stock_renting/models/website.py#L10

and ultimately relies on:
https://github.com/odoo/odoo/blob/37bf1703c7478a3010b71cd60bbb43b3295a605b/addons/stock/models/product.py#L213

This computation does not take the selected renting period into account.

There is a period-aware computation here:
https://github.com/odoo/enterprise/blob/41c729e22c5fd1abb690f8335e933f793be0b319/website_sale_stock_renting/models/website.py#L15C17-L21C1

but it is only triggered when `product.allow_out_of_stock_order` is False (i.e. when "continue selling" is disabled).

opw-[5354163](https://www.odoo.com/web#id=5354163&view_type=form&model=project.task)

Forward-Port-Of: odoo/enterprise#103333

[FIX] l10n_ma_reports: tax report: properly consider cash basis taxes in the XML export

Moroccan taxes are cash basis by default. The former version of the XML generation completely disregarded that, and always reported all bills in the period. Solving this requires using an SQL query so that cash basis can be properly computed, like in the report. This also makes the export much more efficient, and resilient to bigger amount of data.

Steps to reproduce:
- Install `l10n_ma_reports` and switch to the MA company
- Create and confirm a bill:
	Bill Date: 10/01/2025
	Vendor: Azure Interior
	Invoice Lines: Price 100, Taxes 20% (S 140)
- Go to `Bank Reconciliation`
- Add a transaction (Vendor: Azure Interior, Amount: -120 DH, any Memo)
- Select the transaction and the invoice, then click Validate
- Open the Tax Return for November.
	Section D should show data linked to the created invoice
- Export the XML using the Gear → XML
	The created bill is missing in the XML and others may be present, showing inconsistent data

opw-5002779


[IMP] l10n_ma_reports: call the report to compute the prorata value

Searching explicitly for external values is a bad practice ; calling the report ensures consistency between the data displayed, and the one exported into the file.

Forward-Port-Of: odoo/enterprise#104619

**Issue**:
The displayed available quantity on the ecommerce product page is incorrect for rental products when "continue selling" is enabled.

**Steps to reproduce**:
- Create a rental product tracked in stock with a quantity of 5
- Enable "continue selling" and "show available quantity below 10"
- Go to the ecommerce page of this product
- Rent 3 units for a given period, confirm and pay
- Return to the ecommerce product page
-> Whatever the selected renting period, the displayed quantity is always 2

**Cause**:
The website displays `free_qty`:
https://github.com/odoo/enterprise/blob/41c729e22c5fd1abb690f8335e933f793be0b319/website_sale_stock_renting/static/src/xml/website_sale_stock_renting_product_availability.xml#L15

`free_qty` is computed in:
https://github.com/odoo-dev/odoo/blob/0935829ddaecd7b2b6eec9157f8f790b546d06ff/addons/website_sale_stock/models/product_template.py#L36

which leads to:
https://github.com/odoo/enterprise/blob/41c729e22c5fd1abb690f8335e933f793be0b319/website_sale_stock_renting/models/website.py#L10

and ultimately relies on:
https://github.com/odoo/odoo/blob/37bf1703c7478a3010b71cd60bbb43b3295a605b/addons/stock/models/product.py#L213

This computation does not take the selected renting period into account.

There is a period-aware computation here:
https://github.com/odoo/enterprise/blob/41c729e22c5fd1abb690f8335e933f793be0b319/website_sale_stock_renting/models/website.py#L15C17-L21C1

but it is only triggered when `product.allow_out_of_stock_order` is False (i.e. when "continue selling" is disabled).

opw-[5354163](https://www.odoo.com/web#id=5354163&view_type=form&model=project.task)

Forward-Port-Of: odoo/enterprise#103333

Currently, follow-up levels display an `activity` in the list view even 
when the `Schedule Activity` option is not enabled on the record.

**Steps to reproduce:**
- Install the `account_followup` module.
- Navigate to Accounting > Configuration > Invoicing > Follow-up Levels.
- Click `New` and enter a `description`.
- Open the `Activity tab`, `enable` Schedule Activity, set an Activity Type and Summary, then `save`.
- `Disable` Schedule Activity, `save` the record again, and return to the `list view`.
- Observe the `Activity` for the newly created follow-up level.

**Observation:**
The Activity column still shows a value in the list view, even though Schedule Activity is unchecked.

**Root Cause:**
At [1], `activity_type_id` is always shown in the list view without 
considering `create_activity`, causing the `activity` to remain visible 
even when `Schedule Activity` is `disabled`.

**Fix:**
This commit ensures that the `Activity` is displayed in the list view only 
when `Schedule Activity` (`create_activity`) is enabled for the record.

[1]:
https://github.com/odoo/enterprise/blob/d7882a8f97802d7302d81c1fa375a81bb4ca4717/account_followup/views/account_followup_line_views.xml#L13

opw-5476176

Forward-Port-Of: odoo/enterprise#104427

**Steps to produce:**
- Install `appointment,website_sale` modules.
- Go to website > appointment > Online Cooking Lesson.
- Book a slot > Proceed to payment.
- Open the cart.

**Issue:**
- The appointment dates are displayed in an incorrect order in the cart.

**Root cause:**
- In the linked commit, the logic reverses the `self.name` lines to fix a display issue.
- However, since appointment dates are split across multiple lines, reversing the list also unintentionally reverses the appointment date order.

**Solution:**
- Ensure that the appointment dates are formatted to appear on a single line, preventing them from being split into multiple list entries and incorrectly reordered when the lines are reversed.

[commit]: https://github.com/odoo/odoo/pull/223433/changes/5b69176e64e6a4cc46966a8c41b675ed3d98dd0a

Before:
<img width="554" height="138" alt="image" src="https://github.com/user-attachments/assets/3e13a2a5-61d5-48c5-8e6a-85f313f7b6ca" />

After:
<img width="566" height="120" alt="image" src="https://github.com/user-attachments/assets/f0b04592-7fd4-4104-b200-cf9b6f080962" />

opw-5420805
---

Forward-Port-Of: odoo/enterprise#104536
Forward-Port-Of: odoo/enterprise#104100

Currently, follow-up levels display an `activity` in the list view even 
when the `Schedule Activity` option is not enabled on the record.

**Steps to reproduce:**
- Install the `account_followup` module.
- Navigate to Accounting > Configuration > Invoicing > Follow-up Levels.
- Click `New` and enter a `description`.
- Open the `Activity tab`, `enable` Schedule Activity, set an Activity Type and Summary, then `save`.
- `Disable` Schedule Activity, `save` the record again, and return to the `list view`.
- Observe the `Activity` for the newly created follow-up level.

**Observation:**
The Activity column still shows a value in the list view, even though Schedule Activity is unchecked.

**Root Cause:**
At [1], `activity_type_id` is always shown in the list view without 
considering `create_activity`, causing the `activity` to remain visible 
even when `Schedule Activity` is `disabled`.

**Fix:**
This commit ensures that the `Activity` is displayed in the list view only 
when `Schedule Activity` (`create_activity`) is enabled for the record.

[1]:
https://github.com/odoo/enterprise/blob/d7882a8f97802d7302d81c1fa375a81bb4ca4717/account_followup/views/account_followup_line_views.xml#L13

opw-5476176

Forward-Port-Of: odoo/enterprise#104427

When a bounce is received for one recipient of a message sent to multiple partners, notifications for other recipients can be incorrectly marked as “bounced”.

Reproduction Steps:
1. Configure an incoming mail server with a bounce alias.
2. Create multiple contacts with different email addresses.
3. Send a message that notifies multiple contacts.
4. Process a bounce email related to only one recipient.
5. Observe that notifications for other recipients of the same message are also marked as “bounced”.

Root Cause:
During bounce processing, `MailThread._routing_handle_bounce` builds a search domain to identify which `mail.notification` records should be updated.

The original implementation constructed an `OR` domain that could include empty domain elements (`[]`) when some bounce identification data was missing. In Odoo’s domain logic, an empty domain represents a constant “match all” condition. When such a domain is included in an `OR`, the entire expression can match all notifications linked to the message, rather than only those related to the bounced recipient.

Fix:
The domain used to select bounced notifications is now built dynamically. Criteria are only added when the corresponding bounce identification data is present.

opw-5349170

Forward-Port-Of: odoo/odoo#242650

Step To Reproduce:
- create a loyalty of type "loyalty card", that grants 1 point  per $ spent
- configure pos for global discounts
- start pos, select a product (say price_with tax is 100)
- select a customer
- apply a discount of 10%, price should be 90

refer image 
<img width="1367" height="687" alt="image" src="https://github.com/user-attachments/assets/37709299-b377-4eee-95af-e857b19c7671" />

Observation:
- the loyalty gained stays 100, even after we applied discount, it should be 90

<img width="257" height="587" alt="pos loyalty issue" src="https://github.com/user-attachments/assets/772821c2-dc06-4dfc-8d4c-ab00de209ce8" />


Cause:
- the recent commit [1], `applyDiscount` uses `addLineToOrder`, which bypasses `addLineToCurrentOrder`.
- This skips `updateRewards` and other module-level extensions defined on `addLineToCurrentOrder`

[1] https://github.com/odoo/odoo/commit/b63c7c28cfe6d59888982d58b8e9d99ea62281f4

https://github.com/odoo/odoo/blob/5d91798f0f5f712bf5210edd0bf6788f32d0c316/addons/pos_loyalty/static/src/app/services/pos_store.js#L439-L448

Fix:
- Replace `addLineToOrder` with `addLineToCurrentOrder` to ensure rewards and programs are properly updated

opw-5437844

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

Forward-Port-Of: odoo/odoo#243548
Forward-Port-Of: odoo/odoo#242740

Problem:
When computing the price difference on a vendor bill for a subcontracted product, the component cost is considered in the company's currency regardless of the currency of the invoice. This means the price difference calculation directly compares two different currencies without converting them, resulting in some incorrect values for the price difference invoice lines.

Solution:
We will convert the component cost to the invoice currency when computing price difference.

Steps to reproduce (runbot 18):
- Product with
	- Standard price auto
	- BoM: sbc, one component with nonzero value (e.g. $1)
	- Nonzero value (e.g. $5)
- Another currency
1. Create a PO for the subcontracted product
2. Set the Invoice currency to something other than the company default
3. Confirm the PO and validate the sbc and receipt
4. Create the vendor bill, and bill for the correct value (Whatever $4 is in the invoice currency)

A price difference line will be erroneously generated for some nonsense value, when we expect 0 price difference.

opw-5232917

Forward-Port-Of: odoo/odoo#243941
Forward-Port-Of: odoo/odoo#238428

**NOTE** the problem regarding the auto-vacuum was fixed in 18.3 and above (including master) at https://github.com/odoo/odoo/pull/216483, this PR now solely exists for branlette intellectuelle. 

Have a ir cron action with the following code:

	time.sleep(MIN_TIME_PER_JOB)
	self.env['ir.cron']._commit_progress(remaining=1)
	return

The code looks stupid, but we tracked down a bug we had in the autovacuum cron in 18.3, and the minimum code to reproduce the problem is that above line of code.

Since there are remaining stuff to do, the cron worker should report a `PARTIALLY_DONE` status, and reschedule to call the cron action asap. But the system currently determine a `FULLY_DONE` status and reschedule the cron action *later* (next day for a cron with an interval of 1 day).

It is pretty bad for the autovacuum cron in 18.3

We used the opportunity to rework the `status` computation to one big match-case, for extra readability.

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

Forward-Port-Of: odoo/odoo#216116

Issue:
Inconsistent use of line ID in the general ledger between account_move_line.id and account_analytic_line.id

Step to reproduce:
- Activate analytic accounting
- Go to Accounting Report -> General Ledger -> Options
- Activate "Analytic Group By"
- Create an invoice
- add a line with an analytic account
- Confirm the Invoice
- Duplicate the invoice
- Confirm the second invoice
- Go to the General Ledger
- Group By the analytic account you used

Current Behavior:
General Ledger display 2 lines per journal entry being part of the analytic distribution used for the group by. The first line displays the part related to the analytic group by, while the second line display infos for global general ledger.
Clicking on the dots of the first line -> "View Journal Entry" send you to an unrelated entry.

Expected behavior:
- "View Journal Entry" should send to the right entry

Proposed Solution:
To proceed to the group_by, `_prepare_lines_for_analytic_groupby` create a temporary SQL table. This table uses the account_analytic_line.id as if it was the account_move_line.id. This commit fixes this and goes back to account_move_line.id.

However, lines are merged into only one single line.

opw-5267981

Forward-Port-Of: odoo/enterprise#104314
Forward-Port-Of: odoo/enterprise#103169

Before this PR:

Everything works fine, but if the user change the decimal precision for foreign currency (i.e. USD, usually needed for export invoices, for example to three decimals), the SII system rejects the invoice. The rejectment cause is cryptic, and difficult to undertand, since it says: That is expecting a `<Documento>` tag, while this tag is not used in Exports invoices (the correct tag is `<Exportaciones>`.

The real cause of the error is that if the `<TotClauVenta>` tag has more than 2 decimals is ignored, and if it is ignored, the SII system assumes that the invoice is not an export invoice, and that's why an incorrect tag is expected by the validator.

After this PR:

We simply forced the decimals of the tag `<TotClauVenta>`to 2. This definitely solves the issue.

Source:

https://www.sii.cl/factura_electronica/formato_dte.pdf

Capture of this portion of the normative:

<img width="626" height="118" alt="Captura de pantalla 2026-01-07 a la(s) 18 21 06" src="https://github.com/user-attachments/assets/3b9ec8f0-d343-4819-8589-67afeeeba807" />

Forward-Port-Of: odoo/enterprise#103600

Before this commit, the SQL query generated in `_get_aal_query` utilized a `LEFT JOIN` with a complex `OR` condition on the join clause: `(bl.company_id IS NULL OR bl.company_id = al.company_id)`.

Because this condition lacks a strict equality constraint, the planner cannot build a hash table for the join. Consequently, it is forced to fallback to a Nested Loop Join strategy, evaluating the condition as a filter for every row pair. This results in significant performance degradation on large datasets.

This commit optimizes the query by splitting the logic into two separate `SELECT` statements combined with a `UNION ALL`:
1. Matches where `company_id` is explicitly equal.
2. Matches where `company_id` is NULL.

By separating these conditions, the planner can now prioritize a Hash Join for the equality check and handle the NULL join separately, significantly reducing execution time.

References:
- Original PR introducing the logic: https://github.com/odoo/enterprise/pull/82955
- Plan Before (Join Filter): https://explain.dalibo.com/plan/a55476hgb73ea7g6#plan
- Plan After (Hash Cond): https://explain.dalibo.com/plan/3b9g484569a86efb#plan

opw-5460862

Forward-Port-Of: odoo/enterprise#104531
Forward-Port-Of: odoo/enterprise#104299

Issue:

When using negative amounts, for example to explicitly show a discount, the tax calculation is incorrect due to the application of the `abs` function. Furthermore, the way to find out if a tax is of the withholding type is based on the sign of the value, which can lead to error in these cases.

Cause:

A previous change (#237235) added the `abs` function so the 'TotalTaxesWithheld' would be always with positive value. But this also affects the calculation of taxes 'TotalTaxOutputs' in some cases, such as if the invoice line has negative values.

Steps to reproduce:

- Install `l10n_es_edi_facturae`
- With the ES company, create an invoice with some standard lines and one line with negative amounts, as an explicit discount
- Confirm the invoice and send (facturae)
- Open the XML attached in the chatter
- Observe that the taxes amounts (VAT and WITHHOLDING) are erroneous

A correct invoice should be for example:

```
Product        Price       Taxes       Amount
---------------------------------------------
PRODUCT-A       1000    21%VAT 15%WHI    1000
Discount        -100    21%VAT 15%WHI    -100
---------------------------------------------
                       Untaxed amount     900
                      Withholding 15%    -135
                              VAT 21%     189
                      -----------------------
                                 TOTAL    954
```

---
I confirm I have signed the [CLA](https://github.com/odoo/odoo/pull/157955) and read the PR guidelines at www.odoo.com/submit-pr

Currently, follow-up levels display an `activity` in the list view even 
when the `Schedule Activity` option is not enabled on the record.

**Steps to reproduce:**
- Install the `account_followup` module.
- Navigate to Accounting > Configuration > Invoicing > Follow-up Levels.
- Click `New` and enter a `description`.
- Open the `Activity tab`, `enable` Schedule Activity, set an Activity Type and Summary, then `save`.
- `Disable` Schedule Activity, `save` the record again, and return to the `list view`.
- Observe the `Activity` for the newly created follow-up level.

**Observation:**
The Activity column still shows a value in the list view, even though Schedule Activity is unchecked.

**Root Cause:**
At [1], `activity_type_id` is always shown in the list view without 
considering `create_activity`, causing the `activity` to remain visible 
even when `Schedule Activity` is `disabled`.

**Fix:**
This commit ensures that the `Activity` is displayed in the list view only 
when `Schedule Activity` (`create_activity`) is enabled for the record.

[1]:
https://github.com/odoo/enterprise/blob/d7882a8f97802d7302d81c1fa375a81bb4ca4717/account_followup/views/account_followup_line_views.xml#L13

opw-5476176

Forward-Port-Of: odoo/enterprise#104427