Currently to exclude valuation accounts from the reconciliation we modify the domain by adding a second condition on the field account_id of the account_move_line table to exclude these accounts while including them in a first condition in the method we override.

This is not very efficient as it prevents the use of indexes on that second NOT IN condition.
Indeed PostgreSQL prioritizes the use of the index on the IN condition and then applies the NOT IN condition in a filtering step, which is very costly when there are many account_move_line records belonging to the inventory valuation accounts.

Here is an example of the before after on a database with 87 million account_move_line records total and 9.5 million account_move_line records matching the first IN condition via an index while only 1 million remain after applying the filtering of the NOT IN condition.

All measures are performed with a warmed up cache

[Explain Before](https://explain.dalibo.com/plan/d0d14efbe51ch359)

### Benchmark:
<table>
	<thead>
		<tr>
			<th># of aml</th>
			<th>Before</th>
			<th>After</th>
		</tr>
	</thead>
	<tbody>
		<tr>
			<td>87713812</td>
			<td>~9s</td>
			<td>~1.5s</td>
		</tr>
	</tbody>
</table>

[Explain After](https://explain.dalibo.com/plan/e882cf62d1ga6955)

## Potential further improvement:

Add a partial index: 
```SQL
CREATE INDEX CONCURRENTLY idx_aml_company_id_account_id_unreconciled_posted
ON account_move_line (company_id, account_id)
WHERE parent_state = 'posted' 
  AND (reconciled IS NULL OR reconciled = FALSE)
  AND (display_type IS NULL OR display_type NOT IN ('line_section', 'line_note'));
```

### Benchmark:
<table>
	<thead>
		<tr>
			<th># of aml</th>
			<th>Before</th>
			<th>After</th>
		</tr>
	</thead>
	<tbody>
		<tr>
			<td>87713812</td>
			<td>~1.5s</td>
			<td>~900ms</td>
		</tr>
	</tbody>
</table>

[Explain After + Index](https://explain.dalibo.com/plan/56dfdh554668ed43)

Part of https://github.com/odoo/odoo/pull/261931

Step to reproduce:
1. Install `web_studio`
2. Create two apps, one with upload image and one with fa icon
3. Both apps should have chatter
4. Now create activities from both apps
5. See Activity from the top right clock icon

Issue:
- Icons of studio apps are not rendered

Cause:
- As of now, we do not support studio app's icons to render in the activity tab

Solution:
- Fetch the studio_customisation app's icons from the menu

<table>
  <tr>
    <th colspan="2">Before</th>
  </tr>
  <tr>
    <td colspan="2">
      <img width="1127" height="289"
           alt="Before"
           src="https://github.com/user-attachments/assets/1c30a356-e752-4436-a429-1e0b4555045e" />
    </td>
  </tr>
  <tr>
    <th colspan="2">After</th>
  </tr>
  <tr>
    <td colspan="2">
      <img width="1152" height="295"
           alt="After"
           src="https://github.com/user-attachments/assets/a9981cd1-50f1-404b-8ff6-0b9e0f50a8bb" />
    </td>
  </tr>
</table>



opw-5848298

The method `_create_or_update_sequences_and_picking_types()` from model `stock.warehouse` is returning data for the newly set picking types. So if warehouse has already `{in,out}_type_id` set, [this] will not return data for those picking types. It means, we might get an issue while we try to read the `{in,out}_type_id` [here].

Issue discovered during upgrade.

Steps to reproduce:
1. Install `l10n_ro_saft` and `stock_account` in 17.0
2. Upgrade to 18.0

- `l10n_ro_saft_stock` is [auto_install], so it will be installed
- `_create_or_update_sequences_and_picking_types()` will get extension from `l1on_ro_saft_stack`
- during the upgrade in this [script] it will cause traceback like this

For fixing the issue, we check if the `{in,out}_type_id` are existing in warehous_data.

```
2026-04-22 07:15:39,016 3390451 CRITICAL romanian_warehouse_test odoo.service.server: Failed to initialize database `romanian_warehouse_test`.
Traceback (most recent call last):
  File "/home/odoo/src/odoo/18.0/odoo/service/server.py", line 1366, in preload_registries
    registry = Registry.new(dbname, update_module=update_module)
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/.pyenv/versions/3.12.2/lib/python3.12/site-packages/decorator.py", line 232, in fun
    return caller(func, *(extras + args), **kw)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/src/odoo/18.0/odoo/tools/func.py", line 97, in locked
    return func(inst, *args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/src/odoo/18.0/odoo/modules/registry.py", line 129, in new
    odoo.modules.load_modules(registry, force_demo, status, update_module)
  File "/home/odoo/src/odoo/18.0/odoo/modules/loading.py", line 523, in load_modules
    migrations.migrate_module(package, 'end')
  File "/home/odoo/src/odoo/18.0/odoo/modules/migration.py", line 222, in migrate_module
    exec_script(self.cr, installed_version, pyfile, pkg.name, stage, stageformat[stage] % version)
  File "/home/odoo/src/odoo/18.0/odoo/modules/migration.py", line 259, in exec_script
    mod.migrate(cr, installed_version)
  File "/home/odoo/src/upgrade/migrations/stock/saas~17.3.1.1/end-migrate.py", line 16, in migrate
    new_types_vals = warehouse._create_or_update_sequences_and_picking_types()
                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/src/enterprise/18.0/l10n_ro_saft_stock/models/stock_warehouse.py", line 15, in _create_or_update_sequences_and_picking_types
    PickingType.browse(warehouse_data['in_type_id']).write({
                       ~~~~~~~~~~~~~~^^^^^^^^^^^^^^
KeyError: 'in_type_id'

```

tbg-2609

[this]: https://github.com/odoo/odoo/blob/006367bed13a0145e81bf0f5105e8f51cd0610d5/addons/stock/models/stock_warehouse.py#L325 
[here]: https://github.com/odoo/enterprise/blob/5acaad71fd2b75ede9df8708e54e0f988522b58a/l10n_ro_saft_stock/models/stock_warehouse.py#L10 
[script]: https://github.com/odoo/upgrade/blob/4b74a6df5f3f725cbef1b9eb1d98c536ea228abe/migrations/stock/saas~17.3.1.1/end-migrate.py#L16
[auto_install]: https://github.com/odoo/enterprise/blob/a8eea67ba89bb8eb96d2843734a8e0f7f44547c9/l10n_ro_saft_stock/__manifest__.py#L25

**Issue**
Reducing the PO quantity after performing a partial receipt, in multi-step receipts warehouse
can incorrectly update the remaining receipt quantity.

**Steps to reproduce**
- Setup 2-route receipt warehouse (Inventory > Configuration > Warehouse Management > Warehouses)
- Create a PO for 35 units and confirm it
- Click on receive products, set received quantity to 10 and create a backorder
- Validate the next transfer
- Go back to the PO and change the quantity to 20
- Check the receipt demand
-> The backorder picking demand become 35 instead of 10

**Cause**
Updating the quantity of a purchase order line, also updates the related picking:
https://github.com/odoo/odoo/blob/5fc1e34d174f7f61d692d086d0ff65fbfc72b013/addons/purchase_stock/models/purchase_order_line.py#L120
It updates the picking associated to the backorder since the other one is done:
https://github.com/odoo/odoo/blob/5fc1e34d174f7f61d692d086d0ff65fbfc72b013/addons/purchase_stock/models/purchase_order_line.py#L185-L187
https://github.com/odoo/odoo/blob/5fc1e34d174f7f61d692d086d0ff65fbfc72b013/addons/purchase_stock/models/purchase_order_line.py#L197
This ultimately calls:
https://github.com/odoo/odoo/blob/5fc1e34d174f7f61d692d086d0ff65fbfc72b013/addons/purchase_stock/models/purchase_order_line.py#L228
To compute the new demand for the picking, it retrieves the `move_dest`:
https://github.com/odoo/odoo/blob/5fc1e34d174f7f61d692d086d0ff65fbfc72b013/addons/purchase_stock/models/purchase_order_line.py#L240
To compute `qty_to_push`:
https://github.com/odoo/odoo/blob/5fc1e34d174f7f61d692d086d0ff65fbfc72b013/addons/purchase_stock/models/purchase_order_line.py#L247-L249
However, since we are in a 2-route receipt setup, `move_dest` is the move from Input to stock for the done picking.
Thus, `qty_to_push` is `20 - 10 = 10` instead of `20 - 35 = -15`

**Solution**
The previous logic assumes a pull flow, where downstream (move_dest_ids) quantities are always up-to-date and can be used as the source of truth to recompute demand.
In push flows (e.g., multi-step receipts), this assumption does not hold. 
To fix this, we instead base the computation on the quantity of the current moves (qty) if nothing has to be attached. 

**Additional information**
Known limitation: this does not address inconsistencies in return flows. When there're returns, units 
define in the pol and the one define in the sum of the picking can diverge, thus this pr won't fix that.

opw-5512172

## Description

### Problem

[sale_product_domain](file:///home/imanie/Documents/IRC/18.0/odoo/addons/website_sale/models/website.py#367-376) uses `self.get_current_website()` for the website domain
but `self.company_id` for the company domain. This causes two issues:

1. **`company_id` is `False` when called from [models](https://github.com/odoo/odoo/blob/b011c1e3cc4597c713dfe7041c58dc224f8f758d/addons/website_sale/models/product_template.py#L278)**: Methods like
   [_get_website_accessory_product](file:///home/imanie/Documents/IRC/18.0/odoo/addons/website_sale/models/product_template.py#198-203) and [_get_website_alternative_product](file:///home/imanie/Documents/IRC/18.0/odoo/addons/website_sale/models/product_template.py#204-207) call
   `self.env['website'].sale_product_domain()` — an empty recordset where
   `self.company_id.id` evaluates to `False`. The resulting company domain
   [('company_id', 'in', [False, False])](file:///home/imanie/Documents/IRC/18.0/odoo/addons/website_sale/controllers/main.py#757-802) filters out all company-owned
   products.

https://github.com/odoo/odoo/blob/b011c1e3cc4597c713dfe7041c58dc224f8f758d/addons/website_sale/models/product_template.py#L279

2. **Inconsistent website references**: Even when `self` is a real website
   record, `get_current_website()` could return a different website, leading to
   the website domain and company domain referring to different websites.

### Steps to reproduce

1. Add accessory products to a product template
2. Visit the product page on the ecommerce shop
3. Accessory products belonging to the website's company may not appear

### Solution

Store the resolved website in a local variable (`self or self.get_current_website()`),
preferring `self` when it is a real record and falling back to
`get_current_website()` otherwise. Use this single variable for both the website
domain and the company domain.

```diff
 def sale_product_domain(self):
-    website_domain = self.get_current_website().website_domain()
+    website = self or self.get_current_website()
+    website_domain = website.website_domain()
     if not self.env.user._is_internal():
         website_domain = expression.AND([website_domain, [
             ('is_published', '=', True),
             ('service_tracking', 'in', self.env['product.template']._get_saleable_tracking_types()),
         ]])
-    company_domain = [('company_id', 'in', [False, self.company_id.id])]
+    company_domain = [('company_id', 'in', [False, website.company_id.id])]
     return expression.AND([self._product_domain(), website_domain, company_domain])
```


https://github.com/odoo/odoo/pull/260138

**Steps to reproduce:**
- On a new company, activate automatic valuation and anglo-saxon accounting.
- Create a new product, and set the cost to 5.
- On the product category, set the costing method to AVCO and the valuation to automatic.
- Create a Purchase Order for the product, confirm it and recieve it, but don't create a Bill yet.
- Create a sales order with the same quantity as the purchase order, and deliver it.
- Now create a bill for the original Purchase Order, and change the price to 6.
- Manually change the total tax amount on the Bill, and then post it.

**Issue:**
After posting the Bill, the value set manually on the total tax is recomputed and overwritten.
This is because the price difference between the bill and the original cost creates two new price difference lines on the bill, and this triggers the move sync to recompute the tax.

**Solution:**
Set the context `skip_invoice_sync` to True when creating the price difference lines.

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

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

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

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

opw-6103934

Forward-Port-Of: odoo/enterprise#113804

Steps to reproduce:
1. Create a Vendor Bill for 1000 ARS.
2. Register a payment using "Own Checks".
3. Add two checks (e.g., 500 ARS each).
4. Create and Post the payment.
5. Observe that the Bill ribbon immediately shows "Paid".

Cause:
When processing multiple own checks, Odoo creates a "Split Move" entry to handle individual check maturity dates. To balance the books, it reconciles the original payment liquidity line with a counterpart line in this split entry. Because Odoo's core payment state logic monitors this original liquidity line, it sees the reconciliation as a "clearing" event and incorrectly flips the bill status to "Paid" before the checks have actually cleared the bank.

Solution:
Override _seek_for_lines to redirect Odoo's "status sensor." By pointing the liquidity line target to the individual check lines in the split move instead of the original payment line, the payment state now correctly depends on whether those specific checks have been reconciled with a bank statement. A context guard (skip_check_search) is used during the split move creation to allow the builder to access the original payment line without interference.

opw-5482766

Steps to reproduce
------------------
1. Create a sale order with 2 products, confirm it
2. Cancel the SO, then click "Set to Quotation"
3. Open PoS, settle the order and pay
4. Check the delivery order linked to the PoS order

The delivery is empty, yet the products still show as "delivered" on
the sale order.

Why it's happening
------------------
When the SO is cancelled, its moves go to 'cancel' state. After
resetting to quotation, those moves stay cancelled. When PoS creates
the delivery, the filter in `_create_move_from_pos_order_lines` checks
`has_valued_move_ids()` which returns False (all moves are cancelled),
and `not move_ids` is also False (cancelled moves still exist). So the
lines coming from the SO are excluded from the delivery.

The fix
-------
We now also create deliveries for lines whose SO moves are all
cancelled. These are lines coming from a cancelled SO that now need
to be shipped after we have settled their order from PoS.

Note
----
The commit c0f338711f028088c98ea459f27c1669b29738d7 fixes this starting from saas-18.2, by introducing a separate `pos_repair` module which simplifies the main `pos_sale` code. In 18.2+, only the test will be forward ported.

opw-6055856

Issue
-----
If the account on which stock revaluation is registered has a default tax, the account moves generated by changing the price of the product include the tax.

For context, the issue was reported because some l10n modules use accounts with default taxes (eg l10n_de).

Steps to reproduce
-----
- Install a localisation to have default accounts set up
- Create a product category (Cat1)
	- Set Inventory Valuation to "Automated"
	- Set a default tax on the Expense Account
- Create a product Prod1
	- Storable
	- Category set to Cat1
	- Cost set to 500
- Update the on hand quantity of Prod1 to 1
- Change the price of Prod1 to 300
- Go to Accounting > Accounting > Journal > Journal Entries

--> There is an AM for 200 + tax instead of just 200

Discussion
-----
When manually changing the cost of the product, we call

https://github.com/odoo/odoo/blob/09c366dcfa5fe550a1afef813faa79f43767d0a5/addons/stock_account/models/product.py#L354

Where we create the AMs

https://github.com/odoo/odoo/blob/09c366dcfa5fe550a1afef813faa79f43767d0a5/addons/stock_account/models/stock_valuation_layer.py#L294

This creates the corresponding debit/credit AMLs. Afterwards, we go through

https://github.com/odoo/odoo/blob/09c366dcfa5fe550a1afef813faa79f43767d0a5/addons/account/models/account_move.py#L3210

Which calls `_sync_tax_lines` where AMLs are created for the taxes

https://github.com/odoo/odoo/blob/09c366dcfa5fe550a1afef813faa79f43767d0a5/addons/account/models/account_move.py#L3088

Solution
-----
The AML's `tax_ids` field is precomputed

https://github.com/odoo/odoo/blob/09c366dcfa5fe550a1afef813faa79f43767d0a5/addons/account/models/account_move_line.py#L192-L198

and takes the taxes from the account

https://github.com/odoo/odoo/blob/09c366dcfa5fe550a1afef813faa79f43767d0a5/addons/account/models/account_move_line.py#L894

By explicitly stating an empty value when we create the AM in `_change_standart_price_accounting_entries`, we avoid the compute so tax lines don't get created.

-----
Ticket:
opw-5929774

**Problem:**
When a project analytic budget is revised, the project update description shows an inflated total budget — the sum of both the original and the revised amounts — instead of reflecting only the active (confirmed) revision.

**Steps to reproduce:**
1. Create a project with an analytic account
2. Create an analytic budget of $10,000 and confirm it
3. Create a revision of that budget for $15,000 and confirm it
4. Create a new project update
5. The update shows "$25,000" as the total budget instead of "$15,000"

**Current behavior:**
The project update displays the sum of all budget revisions ($25,000), regardless of their state.

**Expected behavior:**
Only the active confirmed budget ($15,000) should be used.

**Cause of the issue:**
`_compute_budget` queries all `budget.line` records matching the project's analytic account without filtering by the parent `budget.analytic` state. When a budget is revised, the original transitions to state `revised` while the new one becomes `confirmed`. Because `_compute_budget` has no state filter, it sums both, producing an inflated `total_budget_amount`. This field is then used in the project update template to compute the displayed budget total and percentage. By contrast, `_get_budget_items` — used for the detail rows — already applies `state in ['confirmed', 'done']`, so the two methods were inconsistent.

**Fix:**
Applying the same state filter to `_compute_budget` as already present in `_get_budget_items` ensures both methods draw from the same set of active budgets, keeping the project update totals consistent with the budget detail rows.

opw-6128855