Currently, customers report errors when connecting or refreshing a
Shopee account through the `sale_shopee` module.

**Steps to reproduce:**
- Install and configure the `sale_shopee` module
- Attempt to connect a Shopee account via the onboarding flow
- Complete the authorization process

**Observed behavior:**
An error is raised during the authorization callback, preventing the
Shopee account from being connected or refreshed.

**Root cause:**
In `onboarding.py`, the `shopee_return_from_authorization` controller
incorrectly uses `utils.with_context(authorization_code=code)`. Since
`utils` is an imported Python module, calling `with_context` on it
attempts to set the context on the module itself rather than on a
model instance, which raises an error.

**Solution:**
Move the `with_context` call from the `utils` module to the `temp_shop`
record, which is the appropriate model instance that needs the context.

Additionally, this commit adds regression tests for the controller to
prevent future regressions, as this functionality was previously
untested.

opw-6092524

Forward-Port-Of: odoo/enterprise#113081

**Steps to reproduce**
- Create a first partner (name: "Partner", email: "partner@mail.com", phone: "123").
- Go to the website form of a helpdesk team, and submit a ticket using "Partner@mail.com" as email (notice the different capitalization) and "456" as phone number.

Behavior without this fix: a new partner is created, but the ticket is assigned to the orignal partner ("partner@mail.com") and its phone number is updated.

Behavior after this fix: no partner is created.

**Causes**
- the partner search was case sensitive
- the created partner was not used as the `partner_id` of the ticket as it was added to the params but needs to be in the kwargs passed to `handle_website_form` in order to be found used by `extract_data`. The original partner was found in `_find_or_create_partner` by the call to
`_mail_find_partner_from_emails` (case-insensitive)

Note: this commit also ensures consistency between the partner's company and the ticket's company (same as in `_find_or_create_partner` of `helpdesk.ticket`).
Also, avoid allowing modifying existing partner's phone via this form.

opw-5914064

Forward-Port-Of: odoo/enterprise#109393

Steps to produce:
---
- Install `Accounting` module.
- Create a new customer.
- From the gear icon, `grant Portal Access` to the customer.
- Create an invoice for this customer.
- Log in using the customer’s portal account.
- Navigate to `My Invoices`.

Issue:
---
```
You are not allowed to access 'Payment' (account.payment) records.

```

Root cause:
---
- After the [commit], the system attempts to compute the next payment values for display in the portal.
- This computation is triggered via `_get_invoice_portal_extra_values()`, which calls `_get_invoice_next_payment_values()`.
- During this process, the method iterates over `reconciled_payment_ids`. Accessing this field triggers its computation (`_compute_reconciled_payment_ids`), which depends on `matched_payment_ids`.
- Both `reconciled_payment_ids` and `matched_payment_ids` are relational fields pointing to `account.payment` records.
- Since portal users do not have read access to the `account.payment` model, attempting to access these fields results in an AccessError

[commit]: https://github.com/odoo/odoo/commit/b76836680540eb7687021f48b3532e8a495e771a

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

Pre-requisites:
------------------------------------------
1. Install `sale_project` and `project_account_budget` modules
2. Have two companies configured in the system
3. Enable Timesheets from the Settings app
4. Create two projects (one for each company)
5. Ensure the following settings are enabled on both projects:
     * Timesheets
     * Billable

Steps to Reproduce:
------------------------------------------
1. Switched to Company A
2. Create a product with:
    * Type: Service
    * Create on Order: Task
    * No company restriction
3. Set the product's `project_id` to Company A's project
4. Switch to the newly created company (Company B)
5. Set the product's `project_id` to Company B's project
6. Enable Analytic Distribution from SOL Optional
7. Create a sale order with the configured product, and delete the auto-fetched
Analytic Distribution account for the sale order (Company B's project)
8. Now confirm the sale order

Observation:
----------------------------------------
The SOL's analytic distribution uses the analytic account from Company A's project instead of Company B

Issue:
----------------------------------------
The `project_id` field on `product.template` is `company_dependent=True`, meaning it stores different values per company. However, in `_compute_analytic_distribution()`, the code accesses `line.product_id.project_id` without calling `with_company`, so it resolves the field using the wrong company context

Solution:
----------------------------------------
using `with_company()`, the correct company context is applied when accessing
`project_id`, preventing inconsistencies in multi-company environments and
ensuring the appropriate project is used for the corresponding company.


opw-5864452

Forward-Port-Of: odoo/odoo#257776

The _compute_cumulated_balance() method performs a query over every
existing move lines to get a dict associating the record id with
the cumulated sum at this point.

When there is a lot of move lines, the result returned by fetchall()
hits the memory limit and the server crashes.

We propose to encapsulate the original query to only return
the result for the account move lines present in self.

Benchmarks
---------------

The following benchmarks were generated with a customization of
the account.move.line list view to display the cumulated_balance
field.

Memory usage during the self.env.cr.execute and the dictionary
population:

|     Operation | Before the fix | After the fix |
|---------------|----------------|---------------|
| populate dict |         1.5 GB |       17.1 MB |
| execute query |         430 MB |        8.3 MB |

100 000 lines were displayed at the same time to get a significant
size.
So the number of records in self is more than 7 000 000 without
the fix and 100 000 with the fix.

Time spent in the _compute_cumulated_balance method:

| No of AML | Before the fix | After the fix |
|-----------|----------------|---------------|
| 7 000 000 |         10.4 s |         6.8 s |

opw-6053720

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

Forward-Port-Of: odoo/odoo#258207
Forward-Port-Of: odoo/odoo#255780

This forward port merges [PR1](https://github.com/odoo/odoo/pull/255043) (original PR from this forward port) 
and forward port of [PR2](https://github.com/odoo/odoo/pull/256383) which is improving the fix.

**Problems:**
1) cogs don't adapt to partially consigned quantities
2) no cogs at all if product partially delivered

**Steps to reproduce:**
Problem 1)
- enable 'consignment' setting
- create a tracked product with perpetual category
(bug happens with avco, fifo and standard price category)
- set a cost of 10 
- add a quantity of 1 without owner and a quantity of 
1 with an owner
- create a sale order for a quantity of 2 of your produce
- confirm, validate picking and confirm invoice

-> the cogs is 20
-> the cogs should be 10 because the consigned 
quantity shouldn't be taken into account in the cogs

Problem 2) 
- set the warehouse as 2 steps delivery
- create a tracked product avco perpetual
- set a cost of 10$ and a positive quantity
- create and confirm a SO for 1 quantity
- validate only the first picking
- create and confirm the invoice

-> there is no cogs lines in the invoice
-> there should be cogs line for a cost of 10$

**Cause of the issue:**
Problem 1) 
to compute the cogs line amount, we multiply the quantity 
of the line (2 in our case) by the price unit of the cogs.
To compute the price_unit we call _get_cogs_value()
https://github.com/odoo/odoo/blob/0dbc1c01c6b48d0a765391d5b6ab03b555440aef/addons/stock_account/models/account_move.py#L122-L123 
In our case the price_unit (so the 'price per cogs unit') should 
be 5 because we have 2 units, 1 valued at 10 and 1 valued 
at 0 (the consigned one).
But the value returned by _get_cogs_value() is 10.

The reason for this is that _get_cogs_value uses the return 
value of _get_cogs_price_unit() because the delivery is validated.
https://github.com/odoo/odoo/blob/0dbc1c01c6b48d0a765391d5b6ab03b555440aef/addons/stock_account/models/account_move_line.py#L67-L68

Inside get_cogs_price_unit, we use _get_valued_qty() to 
sum the valued quantity of each move. 
https://github.com/odoo/odoo/blob/0dbc1c01c6b48d0a765391d5b6ab03b555440aef/addons/stock_account/models/stock_move.py#L251
But inside get_valued_qty() for our second move, when 
calling get_out_move_lines(), no lines will be returned 
because should_exclude_for_valuation() will return True 
as the owner of the line is not the user.
So total qty will be 1.
https://github.com/odoo/odoo/blob/0dbc1c01c6b48d0a765391d5b6ab03b555440aef/addons/stock_account/models/stock_move.py#L529

If the product is fifo, we return the total value of the moves (10 + 0) 
divided by total quantity (1). 
If the product is standard or avco we return the standard price. 
In both cases the return value is 10.
But in both cases it should be 5.
https://github.com/odoo/odoo/blob/0dbc1c01c6b48d0a765391d5b6ab03b555440aef/addons/stock_account/models/stock_move.py#L251-L255

Problem 2)
Inside _get_cogs_value(), because there is done moves, 
we use _get_cogs_price_unit()
https://github.com/odoo/odoo/blob/5fd80a1fb8ef33cfa9261967cf14f6f0c421d45a/addons/stock_account/models/account_move_line.py#L67-L68
But because there is no valued quantity (because the done 
moves are internal), the return value will be 0.
https://github.com/odoo/odoo/blob/5fd80a1fb8ef33cfa9261967cf14f6f0c421d45a/addons/stock_account/models/stock_move.py#L251-L253
So the cogs will have an amount of 0 and no line will be created
https://github.com/odoo/odoo/blob/5fd80a1fb8ef33cfa9261967cf14f6f0c421d45a/addons/stock_account/models/account_move.py#L125-L126

**fix**
Prob 1) The first thing to change is to not use the standard price when 
some quantities are consigned. 
The other thing is to add the quantities that would have been 
used if they weren't consigned because in this case we need them 
in the computation. 
Indeed these quantities are included in the invoice line quantity. 
At the end we are multiplying the unit price by the invoice line quantity
which includes consigned quantity, so we need to take them into 
account also when computing the price per cogs quantity.

Prob 2) If there is no quantity to value (consigned + not consigned) 
we fallback on the standard price (just as if there is no move).
This solves the issue of partially delivered order because no moves
are valued moves in this use case.
If there is a quantity to value (and we're in a case where we want
the average move value), we use the average move value (which 
will be 0 if all the moves are consigned, so the consigned use case
is also ok)

opw-6030161
opw-6001694

Forward-Port-Of: odoo/odoo#256231
Forward-Port-Of: odoo/odoo#255043

## Issue
When logged as a portal user, clicking the *Edit* button on a message in the chatter does not do anything.

## Steps to reproduce
1. Install *Project* (`project`)
2. Create a Project P and a Task T
3. In the Setting of Project P, click *Share Project* and select a portal user
4. Logged as a portal user, open Task T, send a message in the chatter, then try to edit it by clicking the *Edit* (pencil) button.
5. **Nothing happens, but a traceback appears in the console: _Caused by: TypeError: Cannot read properties of null (reading 'id')_**

## Cause
The condition causing this error is the following:

https://github.com/odoo/odoo/blob/5cfdc9260653a2b22eb79b16702769928d450932/addons/project/static/src/project_sharing/chatter/composer_patch.js#L9-L13

where `this.thread` is not defined yet. Other conditions in this patch check for `this.thread` before trying to read its `id` [[1](https://github.com/odoo/odoo/blob/5cfdc9260653a2b22eb79b16702769928d450932/addons/project/static/src/project_sharing/chatter/composer_patch.js#L25), [2](https://github.com/odoo/odoo/blob/5cfdc9260653a2b22eb79b16702769928d450932/addons/project/static/src/project_sharing/chatter/composer_patch.js#L32)], which leads to believe that the check was simply forgotten in this condition.

opw-6072570

Forward-Port-Of: odoo/odoo#258234

Steps to reproduce:
--------------------------
1. Install Project and create a portal user.
2. Create a project and a task with tags added to it.
3. Share the project with the portal user (Edit access).
4. Log in as the portal user and open the task.
5. Click on the 'Tags' field and select 'Search More'

Issue:
----------
A traceback occurs:
```ValueError: Invalid field project.tags.display_in_project in condition ('display_in_project', '=', True)```

Cause:
----------
The [ProjectTaskRelationalModel](https://github.com/odoo/odoo/blob/75fd7b05766c6789bf311f6a8257b89ecf4f86de/addons/project/static/src/views/project_task_relational_model.js#L4-L7) calls `_processSearchDomain.`
This method automatically appends a domain when 'showSubtasks' is not enabled.
https://github.com/odoo/odoo/blob/75fd7b05766c6789bf311f6a8257b89ecf4f86de/addons/project/static/src/views/project_task_model_mixin.js#L5-L12

When clicking 'Search More' on the 'Tags' field, the same domain is
applied to the **project.tags** model. However, since **project.tags**
does not have the `display_in_project` field, the ORM raises a ValueError.

In portal, only `project.webclient` assets are loaded, causing
ProjectTaskRelationalModel to be used for all relational fields.
In contrast, internal users use the standard RelationalModel, so the
issue does not occur.

Solution:
-------------
Restrict the domain modification in _processSearchDomain to apply only
when the current model is `project.task` and `report.project.task.user`.


opw-5930427



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

Forward-Port-Of: odoo/odoo#258656
Forward-Port-Of: odoo/odoo#249282

### Steps to reproduce:

- Create a kit product with 6 bom lines (with a `cost_share` of `0.0%`)
- Create + confirm a purchase order for 1 unit of the kit product at 60
- Validate the delivery

#### > 6 layers were created with values 9.99, 10, 10, 10, 10 and 10

There are two issues with purchased kit valuation addressed in this PR:

### Issue 1:

Since 8c199f7783527735b35c9fbda334cbdcd55a004f, the product price unit is not supposed to be rounded anymore. However, kit products rely on the rounded `cost_share` field of the `mrp.bom.line` to determine which part of the price of the kit product is handled by which component: https://github.com/odoo/odoo/blob/591102ff37fef1f0b9a946fee3f9d85789653e65/addons/mrp/models/stock_move.py#L245-L246 https://github.com/odoo/odoo/blob/591102ff37fef1f0b9a946fee3f9d85789653e65/addons/purchase_mrp/models/stock_move.py#L28 https://github.com/odoo/odoo/blob/591102ff37fef1f0b9a946fee3f9d85789653e65/addons/purchase_mrp/models/stock_move.py#L38

This leads to inevitable rounding issues where `60/6` does not match `10`: https://github.com/odoo/odoo/blob/591102ff37fef1f0b9a946fee3f9d85789653e65/addons/purchase_mrp/tests/test_purchase_mrp_flow.py#L1273-L1275 simply because 1/6 is represented  as `16.67%` and not by `16.66666666666666%`. However, values such as 1/6 can be obtained if you do not set any `cost_share`, since the kit explosion will equidistribute its cost share:
https://github.com/odoo/odoo/blob/591102ff37fef1f0b9a946fee3f9d85789653e65/addons/purchase_mrp/models/mrp_bom.py#L42-L48

### Fix of this issue:

We set the digits to `False` for stability reason as the columns have 
been initiallised as "numeric" values and needs to stay numeric:
https://github.com/odoo/odoo/blob/b007b0a4f7e56f6dc44df3154e13745c9981eae3/odoo/fields.py#L1627-L1650

Note that when the digit is Falsy on the field, the field value is formatted to the second digit by the front end:
https://github.com/odoo/odoo/blob/3542c542eac5b204e69a8dd6ae1907cfcef60af3/addons/web/static/src/views/fields/float/float_field.js#L58-L76
https://github.com/odoo/odoo/blob/12e453302a950df4d9ee45954f54bdf610888eda/addons/web/static/src/core/utils/numbers.js#L214-L227

In particular, when we create the bom and set the `cost_share`, all possible values will be rounded to the second decimal just as before. This change will therefore only alter the rounding behavior in the DB for equidistributed values such as `16.66666666666666%`.

### Issue 2:

While the value of the kit product is exploded and distributed among components, the values of each individual `stock.valuation.layer` are themselves rounded before creation based on the company currency: https://github.com/odoo/odoo/blob/4188436a9e800b062bf9f3b0055cad86acc47e19/addons/stock_account/models/product.py#L240-L255 https://github.com/odoo/odoo/blob/4188436a9e800b062bf9f3b0055cad86acc47e19/addons/stock_account/models/stock_valuation_layer.py#L30

Now, this is problematic since the sum of the values of the layers is expected to match the total value of the purchase order line (that is, the non-rounded value of the components of the purchased kit).

### Fix of this issue:

We compute and distribute the rounding error among layers corresponding to the purchased kit product before creation (since layer values are not expected to be modified afterwards), based on the non-rounded computation, since this value should now be exact (as the unit cost is not rounded anymore).

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

Forward-Port-Of: odoo/odoo#257411
Forward-Port-Of: odoo/odoo#252034

**Problem:**
When creating a new stock.move.line in the moves view (accessed via smart button from a picking), the newly created line disappears after any refresh action (manual refresh or triggering "Put in Pack").

**Steps to reproduce:**
1. Open a receipt/picking operation
2. Click on the "Moves" smart button to open the detailed operations view
3. Create a new stock.move.line record
4. Click "Put in Pack" or manually refresh the page
5. Observe that the newly created line disappears

**Current behavior:**
The newly created stock.move.line disappears from the view after refresh, and only reappears if you navigate back to the picking and then return to the moves view.

**Expected behavior:**
The newly created stock.move.line should remain visible in the view after refresh or any action that triggers a view reload.

**Cause of the issue:**
  The action_detailed_operations method uses a static domain [('id', 'in', self.move_line_ids.ids)] that captures a snapshot of move line IDs at the moment the action is opened.
  https://github.com/odoo/odoo/blob/22ac818970f104a732cc7d24afc440cf0e6d74bd/addons/stock/models/stock_picking.py#L1204-L1212 When a new stock.move.line is created in this view, its ID is not included in the original static list. Any refresh (manual or triggered by operations like "Put in Pack") re-applies this static domain, filtering out the newly created lines because their IDs weren't captured in the initial list.

**Fix:**
Using a dynamic domain based on picking_id ensures all move lines belonging to the picking are always visible, regardless of when they were created. This aligns with the expected behavior of showing "all move lines for this picking" rather than "only the move lines that existed when the view was opened". The relational lookup [('picking_id', '=', self.id)] is re-evaluated on each refresh, automatically including any newly created lines that have the correct picking_id set.

opw-5398620

Forward-Port-Of: odoo/odoo#251619
Forward-Port-Of: odoo/odoo#247170

Currently, customers report errors when connecting or refreshing a
Shopee account through the `sale_shopee` module.

**Steps to reproduce:**
- Install and configure the `sale_shopee` module
- Attempt to connect a Shopee account via the onboarding flow
- Complete the authorization process

**Observed behavior:**
An error is raised during the authorization callback, preventing the
Shopee account from being connected or refreshed.

**Root cause:**
In `onboarding.py`, the `shopee_return_from_authorization` controller
incorrectly uses `utils.with_context(authorization_code=code)`. Since
`utils` is an imported Python module, calling `with_context` on it
attempts to set the context on the module itself rather than on a
model instance, which raises an error.

**Solution:**
Move the `with_context` call from the `utils` module to the `temp_shop`
record, which is the appropriate model instance that needs the context.

Additionally, this commit adds regression tests for the controller to
prevent future regressions, as this functionality was previously
untested.

opw-6092524

Forward-Port-Of: odoo/enterprise#113081

Steps to reproduce:
1. Upload an XML invoice (e.g., UBL) containing an embedded PDF into the Documents app.
2. Select the document to open the preview panel.
3. The viewer opens but shows a grey/empty PDF viewer.

Context:
Commit odoo/odoo@5035107e introduced an updated PDF viewer.js. Subsequently, commit d3481a5e removed the `download=0` query parameter from the viewer route to prevent `new URL()` parsing errors on relative paths.

However, the backend specifically relies on the `download=0` flag to intercept the request, extract the Base64 data, and serve the raw PDF binary. Without this parameter, the backend serves the raw XML string directly to the PDF viewer, causing the parser to crash.

Fix:
Restore the `download=0` parameter by using the core `url` utility to construct a safe, absolute URL before encoding it for the viewer. This satisfies the strict `new URL()` parsing in the updated PDF viewer while ensuring the backend correctly triggers the PDF extraction.

Task-6065246

Pre-requisites:
------------------------------------------
1. Install `sale_project` and `project_account_budget` modules
2. Have two companies configured in the system
3. Enable Timesheets from the Settings app
4. Create two projects (one for each company)
5. Ensure the following settings are enabled on both projects:
     * Timesheets
     * Billable

Steps to Reproduce:
------------------------------------------
1. Switched to Company A
2. Create a product with:
    * Type: Service
    * Create on Order: Task
    * No company restriction
3. Set the product's `project_id` to Company A's project
4. Switch to the newly created company (Company B)
5. Set the product's `project_id` to Company B's project
6. Enable Analytic Distribution from SOL Optional
7. Create a sale order with the configured product, and delete the auto-fetched
Analytic Distribution account for the sale order (Company B's project)
8. Now confirm the sale order

Observation:
----------------------------------------
The SOL's analytic distribution uses the analytic account from Company A's project instead of Company B

Issue:
----------------------------------------
The `project_id` field on `product.template` is `company_dependent=True`, meaning it stores different values per company. However, in `_compute_analytic_distribution()`, the code accesses `line.product_id.project_id` without calling `with_company`, so it resolves the field using the wrong company context

Solution:
----------------------------------------
using `with_company()`, the correct company context is applied when accessing
`project_id`, preventing inconsistencies in multi-company environments and
ensuring the appropriate project is used for the corresponding company.


opw-5864452

Forward-Port-Of: odoo/odoo#257776

This commit:
https://github.com/odoo/odoo/commit/ad6351c

Wrapped the invoice line table in a `<div class="table-responsive-sm">` to enable horizontal scrolling on mobile. However, Bootstrap's `table-responsive-sm` sets `overflow-x:auto` on the container, which prevents wkhtmltopdf from repeating the `<thead>` across page breaks. On pages 2+, the header row (Description, Quantity, Unit Price, Amount) renders on top of the first data row instead of appearing as a separate repeated header.

Made the `table-responsive-sm` class conditional on `report_type == 'html'` so it only applies in HTML views where mobile scrolling is needed, and is omitted for PDF rendering. This follows the same pattern already used throughout the invoice template for other responsive classes.

Steps to reproduce:
1. Create an invoice with enough lines to span multiple pages
2. Print the invoice as PDF

=> On page 2+, the table header overlaps with the first data row, making both unreadable.

Ticket [link](https://www.odoo.com/odoo/action-4043/5867972)
opw-5867972

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

## Issue
When logged as a portal user, clicking the *Edit* button on a message in the chatter does not do anything.

## Steps to reproduce
1. Install *Project* (`project`)
2. Create a Project P and a Task T
3. In the Setting of Project P, click *Share Project* and select a portal user
4. Logged as a portal user, open Task T, send a message in the chatter, then try to edit it by clicking the *Edit* (pencil) button.
5. **Nothing happens, but a traceback appears in the console: _Caused by: TypeError: Cannot read properties of null (reading 'id')_**

## Cause
The condition causing this error is the following:

https://github.com/odoo/odoo/blob/5cfdc9260653a2b22eb79b16702769928d450932/addons/project/static/src/project_sharing/chatter/composer_patch.js#L9-L13

where `this.thread` is not defined yet. Other conditions in this patch check for `this.thread` before trying to read its `id` [[1](https://github.com/odoo/odoo/blob/5cfdc9260653a2b22eb79b16702769928d450932/addons/project/static/src/project_sharing/chatter/composer_patch.js#L25), [2](https://github.com/odoo/odoo/blob/5cfdc9260653a2b22eb79b16702769928d450932/addons/project/static/src/project_sharing/chatter/composer_patch.js#L32)], which leads to believe that the check was simply forgotten in this condition.

opw-6072570

Forward-Port-Of: odoo/odoo#258234

__ISSUE__:
- FIFO balance miscalculation for non-overlapping allocations. cumulative_allocated_days was partitioned globally by (employee, leave_type), but taken_per_allocation scoped leaves to each allocation's date range. This caused the FIFO formula to silently absorb leaves from one period into another's allocation capacity.

ex:
    Alloc A (20 days) 2025, taken leaves 15 days
    Alloc B (20 days) 2026, taken leaves 5 days

    report: 2025: (15 taken), (5 left)
            2026: (7 taken), (20 left)

- Left" rows shifted by one year in non-UTC timezones. Allocation date_from/date_to (Date fields) were cast to timestamp as midnight UTC. In negative-UTC /positive-UTC timezones midnight UTC of Dec 31 renders as the prev/next day.

__FIX__:
- detect overlap groups using a running MAX(date_to) and partition the cumulative sums within each overlap group. This way non-overlapping allocations are treated as independent, while overlapping or open-ended allocations still share FIFO within their group.

- offset allocation dates by 12 hours so no timezone can shift them across a day boundary.

- opw-5169606
- opw-5352114

Forward-Port-Of: odoo/odoo#257873

### Issue before this commit:
When a sales order with a product invoiced on delivered quantities is fully delivered and then completely returned the delivered quantity is reset to zero. In this situation, where nothing has been invoiced and nothing remains to be invoiced, the invoice status of the sales order line is incorrectly set to "Fully Invoiced" instead of "Nothing to Invoice".

### Steps to reproduce the issue:
1. Create a new quotation for a storable product.
2. Confirm the order.
3. Validate the delivery of the product.
4. Perform a return for the product
5. Validate that return to simulate a customer return.
6. The sales order details correctly reflect that the delivered quantity and invoiced quantity are both zero. Despite these values—which indicate there is nothing to invoice—the invoice status on the quotation erroneously displays as "fully invoiced".

### Cause of the issue:
The invoice status computation includes a fallback logic that marks a sales order line as "invoiced" when all related stock moves are either done or cancelled. However, this logic does not verify whether any quantity remains effectively delivered. As a result, after a full return, even when qty_delivered = 0, the condition is still met and the line is incorrectly marked as fully invoiced.

### Reason to introduce the fix:
A fully returned sales order line with no delivered and no invoiced quantity should not be considered fully invoiced. The fix ensures that the fallback to "invoiced" only applies when there is a strictly positive delivered quantity, preventing incorrect invoice status after full customer returns.

opw-6014772

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

Forward-Port-Of: odoo/odoo#258589
Forward-Port-Of: odoo/odoo#254871

Currently, customers report errors when connecting or refreshing a
Shopee account through the `sale_shopee` module.

**Steps to reproduce:**
- Install and configure the `sale_shopee` module
- Attempt to connect a Shopee account via the onboarding flow
- Complete the authorization process

**Observed behavior:**
An error is raised during the authorization callback, preventing the
Shopee account from being connected or refreshed.

**Root cause:**
In `onboarding.py`, the `shopee_return_from_authorization` controller
incorrectly uses `utils.with_context(authorization_code=code)`. Since
`utils` is an imported Python module, calling `with_context` on it
attempts to set the context on the module itself rather than on a
model instance, which raises an error.

**Solution:**
Move the `with_context` call from the `utils` module to the `temp_shop`
record, which is the appropriate model instance that needs the context.

Additionally, this commit adds regression tests for the controller to
prevent future regressions, as this functionality was previously
untested.

opw-6092524

Forward-Port-Of: odoo/enterprise#113081

**Steps to reproduce**
- Create a first partner (name: "Partner", email: "partner@mail.com", phone: "123").
- Go to the website form of a helpdesk team, and submit a ticket using "Partner@mail.com" as email (notice the different capitalization) and "456" as phone number.

Behavior without this fix: a new partner is created, but the ticket is assigned to the orignal partner ("partner@mail.com") and its phone number is updated.

Behavior after this fix: no partner is created.

**Causes**
- the partner search was case sensitive
- the created partner was not used as the `partner_id` of the ticket as it was added to the params but needs to be in the kwargs passed to `handle_website_form` in order to be found used by `extract_data`. The original partner was found in `_find_or_create_partner` by the call to
`_mail_find_partner_from_emails` (case-insensitive)

Note: this commit also ensures consistency between the partner's company and the ticket's company (same as in `_find_or_create_partner` of `helpdesk.ticket`).
Also, avoid allowing modifying existing partner's phone via this form.

opw-5914064

Forward-Port-Of: odoo/enterprise#109393

Currently, customers report errors when connecting or refreshing a
Shopee account through the `sale_shopee` module.

**Steps to reproduce:**
- Install and configure the `sale_shopee` module
- Attempt to connect a Shopee account via the onboarding flow
- Complete the authorization process

**Observed behavior:**
An error is raised during the authorization callback, preventing the
Shopee account from being connected or refreshed.

**Root cause:**
In `onboarding.py`, the `shopee_return_from_authorization` controller
incorrectly uses `utils.with_context(authorization_code=code)`. Since
`utils` is an imported Python module, calling `with_context` on it
attempts to set the context on the module itself rather than on a
model instance, which raises an error.

**Solution:**
Move the `with_context` call from the `utils` module to the `temp_shop`
record, which is the appropriate model instance that needs the context.

Additionally, this commit adds regression tests for the controller to
prevent future regressions, as this functionality was previously
untested.

opw-6092524

Forward-Port-Of: odoo/enterprise#113081

Pre-requisites:
------------------------------------------
1. Install `sale_project` and `project_account_budget` modules
2. Have two companies configured in the system
3. Enable Timesheets from the Settings app
4. Create two projects (one for each company)
5. Ensure the following settings are enabled on both projects:
     * Timesheets
     * Billable

Steps to Reproduce:
------------------------------------------
1. Switched to Company A
2. Create a product with:
    * Type: Service
    * Create on Order: Task
    * No company restriction
3. Set the product's `project_id` to Company A's project
4. Switch to the newly created company (Company B)
5. Set the product's `project_id` to Company B's project
6. Enable Analytic Distribution from SOL Optional
7. Create a sale order with the configured product, and delete the auto-fetched
Analytic Distribution account for the sale order (Company B's project)
8. Now confirm the sale order

Observation:
----------------------------------------
The SOL's analytic distribution uses the analytic account from Company A's project instead of Company B

Issue:
----------------------------------------
The `project_id` field on `product.template` is `company_dependent=True`, meaning it stores different values per company. However, in `_compute_analytic_distribution()`, the code accesses `line.product_id.project_id` without calling `with_company`, so it resolves the field using the wrong company context

Solution:
----------------------------------------
using `with_company()`, the correct company context is applied when accessing
`project_id`, preventing inconsistencies in multi-company environments and
ensuring the appropriate project is used for the corresponding company.


opw-5864452

Forward-Port-Of: odoo/odoo#257776

__ISSUE__:
- FIFO balance miscalculation for non-overlapping allocations. cumulative_allocated_days was partitioned globally by (employee, leave_type), but taken_per_allocation scoped leaves to each allocation's date range. This caused the FIFO formula to silently absorb leaves from one period into another's allocation capacity.

ex:
    Alloc A (20 days) 2025, taken leaves 15 days
    Alloc B (20 days) 2026, taken leaves 5 days

    report: 2025: (15 taken), (5 left)
            2026: (7 taken), (20 left)

- Left" rows shifted by one year in non-UTC timezones. Allocation date_from/date_to (Date fields) were cast to timestamp as midnight UTC. In negative-UTC /positive-UTC timezones midnight UTC of Dec 31 renders as the prev/next day.

__FIX__:
- detect overlap groups using a running MAX(date_to) and partition the cumulative sums within each overlap group. This way non-overlapping allocations are treated as independent, while overlapping or open-ended allocations still share FIFO within their group.

- offset allocation dates by 12 hours so no timezone can shift them across a day boundary.

- opw-5169606
- opw-5352114

Forward-Port-Of: odoo/odoo#257873

### Issue before this commit:
When a sales order with a product invoiced on delivered quantities is fully delivered and then completely returned the delivered quantity is reset to zero. In this situation, where nothing has been invoiced and nothing remains to be invoiced, the invoice status of the sales order line is incorrectly set to "Fully Invoiced" instead of "Nothing to Invoice".

### Steps to reproduce the issue:
1. Create a new quotation for a storable product.
2. Confirm the order.
3. Validate the delivery of the product.
4. Perform a return for the product
5. Validate that return to simulate a customer return.
6. The sales order details correctly reflect that the delivered quantity and invoiced quantity are both zero. Despite these values—which indicate there is nothing to invoice—the invoice status on the quotation erroneously displays as "fully invoiced".

### Cause of the issue:
The invoice status computation includes a fallback logic that marks a sales order line as "invoiced" when all related stock moves are either done or cancelled. However, this logic does not verify whether any quantity remains effectively delivered. As a result, after a full return, even when qty_delivered = 0, the condition is still met and the line is incorrectly marked as fully invoiced.

### Reason to introduce the fix:
A fully returned sales order line with no delivered and no invoiced quantity should not be considered fully invoiced. The fix ensures that the fallback to "invoiced" only applies when there is a strictly positive delivered quantity, preventing incorrect invoice status after full customer returns.

opw-6014772

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

Forward-Port-Of: odoo/odoo#257942
Forward-Port-Of: odoo/odoo#254871

### Issue before this commit:
When generating the electronic invoice XML (FatturaPA) with units of measure containing non-standard Unicode characters (e.g. m², m³), the resulting XML fails validation, as these characters are not accepted by the SdI format.

### Steps to reproduce the issue:
1. Download Italian loc + electronic invoicing
2. Activate UoM option in settings
3. Set a product UoM in any unit that has an apex/power of (ex. m2, m3)
4. Invoice this product
5. Create the XML for SdI
6. Check format with Fex > apex is not recognised as a valid character

### Cause of the issue:
The UoM name is exported as-is into the XML. Non-standard Unicode characters are preserved during formatting and are not compatible with the allowed character set defined by the FatturaPA specifications.

### Reason to introduce the fix:
Ensure that units of measure are normalized into a compatible representation before being included in the XML, so that the generated file complies with SdI validation rules.

opw-6075119

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

Forward-Port-Of: odoo/odoo#258851
Forward-Port-Of: odoo/odoo#257012

**Steps to reproduce**
- Create a first partner (name: "Partner", email: "partner@mail.com", phone: "123").
- Go to the website form of a helpdesk team, and submit a ticket using "Partner@mail.com" as email (notice the different capitalization) and "456" as phone number.

Behavior without this fix: a new partner is created, but the ticket is assigned to the orignal partner ("partner@mail.com") and its phone number is updated.

Behavior after this fix: no partner is created.

**Causes**
- the partner search was case sensitive
- the created partner was not used as the `partner_id` of the ticket as it was added to the params but needs to be in the kwargs passed to `handle_website_form` in order to be found used by `extract_data`. The original partner was found in `_find_or_create_partner` by the call to
`_mail_find_partner_from_emails` (case-insensitive)

Note: this commit also ensures consistency between the partner's company and the ticket's company (same as in `_find_or_create_partner` of `helpdesk.ticket`).
Also, avoid allowing modifying existing partner's phone via this form.

opw-5914064

Forward-Port-Of: odoo/enterprise#109393

## Issue
When logged as a portal user, clicking the *Edit* button on a message in the chatter does not do anything.

## Steps to reproduce
1. Install *Project* (`project`)
2. Create a Project P and a Task T
3. In the Setting of Project P, click *Share Project* and select a portal user
4. Logged as a portal user, open Task T, send a message in the chatter, then try to edit it by clicking the *Edit* (pencil) button.
5. **Nothing happens, but a traceback appears in the console: _Caused by: TypeError: Cannot read properties of null (reading 'id')_**

## Cause
The condition causing this error is the following:

https://github.com/odoo/odoo/blob/5cfdc9260653a2b22eb79b16702769928d450932/addons/project/static/src/project_sharing/chatter/composer_patch.js#L9-L13

where `this.thread` is not defined yet. Other conditions in this patch check for `this.thread` before trying to read its `id` [[1](https://github.com/odoo/odoo/blob/5cfdc9260653a2b22eb79b16702769928d450932/addons/project/static/src/project_sharing/chatter/composer_patch.js#L25), [2](https://github.com/odoo/odoo/blob/5cfdc9260653a2b22eb79b16702769928d450932/addons/project/static/src/project_sharing/chatter/composer_patch.js#L32)], which leads to believe that the check was simply forgotten in this condition.

opw-6072570

Forward-Port-Of: odoo/odoo#258234

This commit refactors the import code of BIS3 Invoice to fix various issues about unsynchronized values between the imported invoice and the source XML file.

The new way we import BIS3 invoice can be categorized as:

- collecting all the values from the XML to a dictionary object
- prepare the values and amounts to write to the invoice in its entirety using the tax computation engine helpers
- write the whole processed values to the invoice (as a single write)
- (in 18.0 ~ 18.2) recalculate discrepancies and update the invoice lines (if needed) with the corrected amounts

This commit also includes a new test suite for BIS3 import, and a new approach of import testing, "Partial Imports", is introduced to better atomize the big import test files (and make it understandable). In the long term, `l10n_account_edi_ubl_cii_tests` will eventually be removed in favor of these small-but-many partial tests.

task-id: 5058687

Co-authored-by: Yosua Nicolaus <yoni@odoo.com>

Forward-Port-Of: odoo/odoo#257710
Forward-Port-Of: odoo/odoo#250160

**Description of the issue this PR addresses:**

On mobile devices, the chat composer becomes unresponsive when the navigation menu `navbar-toggler` is open.


https://github.com/user-attachments/assets/8ef01ec6-4a44-41d3-8b86-74f68caf47ef


Steps to reproduce:
1. Open the website in a mobile view.
2. Tap the navbar toggler to open the mobile menu.
3. Without closing the menu, open the chat window.
4. Tap on the message composer text area.

→ The composer is not accessible.

This happens because the bootstrap `Offcanvas` (used by the `navbar-toggler`) traps focus by listening for `focusin` events bubbling up to the document. When the composer is tapped, the Offcanvas intercepts the event and immediately steals focus back to itself, dismissing the virtual keyboard.

This commit stops propagation of the composer `focusin` event so the Offcanvas focus trap does not steal focus from the composer.

Thread focus state can also depend on `focusin` bubbling from the composer to the thread component. Since that bubbling is now stopped, the shared thread focus state is tracked through the JS models instead:

- composer focus updates the related thread through `composer.thread`
- thread component focus updates the thread model directly.

This keeps the composer accessible while preserving thread focus behavior.

Related: https://github.com/odoo/enterprise/pull/113763
Task-5954657

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

Forward-Port-Of: odoo/odoo#258713
Forward-Port-Of: odoo/odoo#250294

Currently, customers report errors when connecting or refreshing a
Shopee account through the `sale_shopee` module.

**Steps to reproduce:**
- Install and configure the `sale_shopee` module
- Attempt to connect a Shopee account via the onboarding flow
- Complete the authorization process

**Observed behavior:**
An error is raised during the authorization callback, preventing the
Shopee account from being connected or refreshed.

**Root cause:**
In `onboarding.py`, the `shopee_return_from_authorization` controller
incorrectly uses `utils.with_context(authorization_code=code)`. Since
`utils` is an imported Python module, calling `with_context` on it
attempts to set the context on the module itself rather than on a
model instance, which raises an error.

**Solution:**
Move the `with_context` call from the `utils` module to the `temp_shop`
record, which is the appropriate model instance that needs the context.

Additionally, this commit adds regression tests for the controller to
prevent future regressions, as this functionality was previously
untested.

opw-6092524

Forward-Port-Of: odoo/enterprise#113081

### **Overview**
The employee form view has become increasingly cluttered with benefit-related fields that are often irrelevant to specific company configurations. This PR introduces a dynamic mechanism to "lighten" the UI by linking views directly to specific benefits.

Key Change: Benefit-related views and salary rules are now conditional. If a benefit is deactivated, its corresponding fields and view elements will no longer appear on the employee form.

### **Technical Changes**
Several models and calculations have been moved:

`hr.contract.salary.benefit`: Moved from hr_contract_salary to hr_payroll.

Yearly Cost Calculation: Logic has been migrated to hr_payroll.

Payroll Properties : Activation is now based on the active field of the salary rule 

Signature & Configurator: The logic specifically tied to the salary configurator and document signing remains in hr_contract_salary.

### **2. Dynamic View Management**
view_ids Field: Added to hr.contract.salary.benefit.

Benefit-specific UI components are now defined in separate views, which are activated/deactivated based on the benefit's active field.

### 3. Module Consolidation & Cleanup
hr_contract_salary_payroll: Merged into hr_contract_salary to reduce module overhead.

hr_contract_salary_holidays: Removed. This module contained significant dead code and is no longer required.

Data Migration: Localized benefit data has been moved from l10n_be_hr_contract_salary to l10n_be_hr_payroll

Currently, customers report errors when connecting or refreshing a
Shopee account through the `sale_shopee` module.

**Steps to reproduce:**
- Install and configure the `sale_shopee` module
- Attempt to connect a Shopee account via the onboarding flow
- Complete the authorization process

**Observed behavior:**
An error is raised during the authorization callback, preventing the
Shopee account from being connected or refreshed.

**Root cause:**
In `onboarding.py`, the `shopee_return_from_authorization` controller
incorrectly uses `utils.with_context(authorization_code=code)`. Since
`utils` is an imported Python module, calling `with_context` on it
attempts to set the context on the module itself rather than on a
model instance, which raises an error.

**Solution:**
Move the `with_context` call from the `utils` module to the `temp_shop`
record, which is the appropriate model instance that needs the context.

Additionally, this commit adds regression tests for the controller to
prevent future regressions, as this functionality was previously
untested.

opw-6092524

Forward-Port-Of: odoo/enterprise#113081

Steps to reproduce:
1. Upload an XML invoice (e.g., UBL) containing an embedded PDF into the Documents app.
2. Select the document to open the preview panel.
3. The viewer opens but shows a grey/empty PDF viewer.

Context:
Commit odoo/odoo@5035107e introduced an updated PDF viewer.js. Subsequently, commit d3481a5e removed the `download=0` query parameter from the viewer route to prevent `new URL()` parsing errors on relative paths.

However, the backend specifically relies on the `download=0` flag to intercept the request, extract the Base64 data, and serve the raw PDF binary. Without this parameter, the backend serves the raw XML string directly to the PDF viewer, causing the parser to crash.

Fix:
Restore the `download=0` parameter by using the core `url` utility to construct a safe, absolute URL before encoding it for the viewer. This satisfies the strict `new URL()` parsing in the updated PDF viewer while ensuring the backend correctly triggers the PDF extraction.

Task-6065246

Forward-Port-Of: odoo/enterprise#112007

**Contract Amendment & Versioning Logic**

* When an offer's contract start date falls within an existing contract period, it is treated as a contract amendment (new version) rather than a new contract.
* For contract amendments, the offer's contract end date is read-only and automatically inherited from the existing contract.
* When creating a new offer, any existing versions with effective dates **on or after** the new offer's contract start date are automatically archived, as they likely contain outdated data.
* Added a warning to notify users when a new offer will replace existing future versions.

**Technical Refactoring**

* Simplified the `employee_version_id` computation by delegating to the existing `_get_version` method on the employee model. This ensures the selected employee version correctly matches the contractual state effective at the new offer's
* Ensured cache invalidation after rollback savepoints to prevent stale data. The overridden `_get_version` in `hr_contract_salary_payroll` writes to `employee.version_id` and the `contract_template_id`; although rolled back, it polluted the cache. We now always invalidate the cache after rollbacks to avoid inconsistencies, including later module installation.

**Simulation & Chatter**

* Inside the simulation, when calling `_get_version`, we need to adjust the contract dates of the version being simulated. The main challenge is allocating this simulated version between existing employee versions without creating contract overlaps, since overlaps raise validation errors.
* To avoid this issue, we move to a new approach. We archive all versions after `employee.version_id` and set `employee.version_id.contract_date_end = False`.
* Then, instead of replacing the active version, we create the simulation version as an amendment to `employee.version_id`. The amendment's effective date is set to `max(fields.Date.today(), employee.version_id.contract_date_start, self.contract_start_date)` + 1 day. This ensures the current version remains unchanged, avoids contract overlaps, and prevents chatter pollution.

task: 5408192

Currently when creating a subscription for a service product, if the minimal period is a multiple of the time unit: eg two week, three months, etc... The discount amount ends up wrongly computed.

The reason for that is that discounts for services are computed by taking the price of the minimal period and then comparing it to other prices, however that base price is not scaled down to single units of time like the compared prices are. https://github.com/odoo/enterprise/blob/9eac36e4d981fd6062702e7119c664ac7951d613/website_sale_subscription/models/product_template.py#L130-L135 https://github.com/odoo/enterprise/blob/9eac36e4d981fd6062702e7119c664ac7951d613/website_sale_subscription/models/product_template.py#L204-L205

**Steps to reproduce:**

- Create a service subscription product
- In Recurring Prices, select or create a recurring plan that is a multiple of a unit of time, ex 2 Months
- Create two entries, one with the created plan and one with a plan that spans a longer period, ex 1 Year
- Set the prices, ex 100 and 600
- Click 'Go to Website' and you'll observe that both are 50% off

opw-6107509

**Steps to reproduce**
- Create a first partner (name: "Partner", email: "partner@mail.com", phone: "123").
- Go to the website form of a helpdesk team, and submit a ticket using "Partner@mail.com" as email (notice the different capitalization) and "456" as phone number.

Behavior without this fix: a new partner is created, but the ticket is assigned to the orignal partner ("partner@mail.com") and its phone number is updated.

Behavior after this fix: no partner is created.

**Causes**
- the partner search was case sensitive
- the created partner was not used as the `partner_id` of the ticket as it was added to the params but needs to be in the kwargs passed to `handle_website_form` in order to be found used by `extract_data`. The original partner was found in `_find_or_create_partner` by the call to
`_mail_find_partner_from_emails` (case-insensitive)

Note: this commit also ensures consistency between the partner's company and the ticket's company (same as in `_find_or_create_partner` of `helpdesk.ticket`).
Also, avoid allowing modifying existing partner's phone via this form.

opw-5914064

Forward-Port-Of: odoo/enterprise#109393

Problem: When you confirm a rental order that has a kit product whose components use two different pack locations Odoo crashes with a singleton error. You get this singleton error because Odoo tries to assign both picks as the `return_id` because they share the same `sale.order.line` here: https://github.com/odoo/enterprise/blob/2212b3f3f3d90894dd6351defe0d3ca090584955/sale_stock_renting/models/sale_order_line.py#L404

Purpose: Use [:1] to safely handle the case where multiple pick transfers are created, avoiding a crash when assigning return_id which expects a single record.

Steps to Reproduce on Runbot:

1. Enable mutli-step routes and rental transfers.
2. Set the warehouse to 3-step delivery.
3. Copy the existing packing location.
4. Copy the existing pick operation type and set the destination location to the new packing location. 
5. Create a new route.
6. Create new rules on this new route with the following configurations:
   1. Rule 1
      1. Action: Pull
      2. Source location: WH/Stock
      3. Destination location: Partners/Customers
      4. Operation type: The new pick operation type
   2. Rule 2
      1. Action: Push
      2. Source location: New pack location
      3. Destination location: WH/Output
      4. Operation type: Pack
   3. Rule 3
      1. Action: Push
      2. Source location: WH/Output
      3. Destination location: Partners/Customers
      4. Operation type: Delivery
7. Create 2 component products tracked by inventory, and apply the new route on one of the component products.
8. Create a new rental product with a kit, which has the 2 component products.
9. Create a new rental order for the kit product and confirm it. 


opw-6026918

**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

Currently, payments may remain in the 'in_process' state even when the associated vendor bills are fully paid. This occurs primarily when using early payment discounts (EPD) and journals without outstanding accounts.

Steps to reproduce:
- Create an early payment term.
- Create a Vendor Bill with EPD and post it.
- Register a payment for this bill (no outstanding account set on journal => no move created).
- Create a bank transaction fully paying the bill.
- Reconcile the transaction with the bill.

Issue: Access the payment of the bill. The payment state remains 'in_process' instead of 'paid'.

Analysis: The issue occurs because the reconciliation process misses the trigger to set the payment state to 'paid'. Specifically:
- The payment amount does not match the bill total due to the EPD.
- The payment compute method does not monitor 'reconciled_bill_ids', causing it to ignore the status of linked vendor bills.

This change adds 'reconciled_bill_ids' to the compute dependencies and ensures that if a payment is reconciled with any moves (invoices or bills), their payment_state is considered to determine the final state of the payment.

opw-5881976

Backport of https://github.com/odoo/odoo/commit/4d84b961cdabd283e1acef6b487b2648bc543a5a

Steps to reproduce:
1. Create an invoice with a 0% tax (Exempt from VAT, category E)
2. Add two lines with 20% discount and fractional prices:
   - qty=4, price_unit=39.615 and qty=4 with price_unit=0.84
3. Send via Peppol
4. Peppol rejects with: [BR-E-08] VAT category taxable amount shall equal the sum of Invoice line net amounts

The TaxableAmount recalculation in _ubl_get_tax_subtotal_node was only applied for tax category 'S' (Standard Rate). However, Peppol schematron has identical rules for all tax categories: BR-E-08 (Exempt), BR-Z-08 (Zero), BR-AE-08 (Reverse Charge), etc.

When lines have discounts and fractional prices, the individually rounded LineExtensionAmount values can sum to a different total than the tax base_amount. This affects both rounding modes. For 'S' taxes this was already handled, but for 'E' (and others) it caused Peppol rejection.

Remove the 'S'-only filter and match dynamically against the actual tax category code so the recalculation applies universally.

opw-6093243

When a company has a shortened fiscal year defined via account.fiscal.year (e.g. May-December), the depreciation board computation for degressive assets incorrectly computes the start of the next fiscal year using `date_from + 1 year` instead of querying the actual next fiscal year. This causes entries for the months between the wrong and correct FY start (e.g. January-April) to be skipped entirely.

Step to reproduce:
- Create a company with a fiscal year starting in May (e.g. May 1st 2025 to 31st December 2025)
- Create an asset with a start date in the 1 December 2025, with a 24 months duration and degressive method
- Compute the board and observe that entries from January to April 2026 are missing

Fix the FY boundary detection in _recompute_board to query the fiscal year containing the day after the current period end, revert the effective_start_date logic in _compute_board_amount that was masking the root cause, and move the prorata date clamping to _create_move_before_date where it is needed for disposal.

opw-6016834

**Purpose:**
Since a stock.quant is a combination of the stock move lines of a product
and a location, it should be restricted by the product's company.

**Before this commit:**
In a multi-company environment. If a purchase order with product from
company 1 is being confirmed, received, and validated when company 2 is
being selected as the primary active company while company 1 is also
checked. It will create a stock.quant that is searchable for company 2.
However, it will raise an error when company 2 is trying to access it.

**After this commit:**
Even if the stock.quant is created when company 2 is the primary active
company, it will not be searchable for company 2 since the product's
company is company 1.

**Steps to Reproduce on Runbot:**

- Create a storable product exclusive to Company A
- Create & validate a receipt for that product in Company A.
- Switch to Company B -> Reporting > Locations > Remove all filters: The negative quant for the product in Partners/Vendors is visible.

opw-6082330

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