Relativedelta on UTC dates or time-zoned dates doesn't return the same result. 
In order to calculate consistent prices (price for 1 month in December = price for 1 month in January), we need to work on time-zoned dates.

Example: 
Consider a website in UTC+1 (Brussels timezone DST off).
And a rental from the 01/12/2025 to the 31/12/2025 = by design, from the 01/01/2025 00h00 (start_date) to the 31/12/2025 23h59 (end_date). 
Converted in UTC for the back-end, we have:
from the 30/11/2025 23h00 to the 31/12/2025 22h59.
relativedelta(end_date, start_date) = time between the 2 dates is calculated as follow:
30/11/2025  23h00 + 1 month = 30/12/2025 23h00 +23h59 = 31/12/2025 22h59. 
Time difference = 1 month, 23 hours, 59 minutes. 
Price = 2 months. 

Consider a second rental from the 01/01/2026 to the 31/01/2026. 
31/12/2025 23h00 + 30 days = 30/01/2026 23h + 23h59 = 31/01/2026 22h59. 
Time difference = 30 days, 23 hours, 59 minutes.
Price = 1 month. 

opw-5130762

Forward-Port-Of: odoo/enterprise#114212
Forward-Port-Of: odoo/enterprise#98571

Steps to reproduce
1. In a French company with Intrastat enabled, set up a product whose commodity code has a CN supplementary unit (e.g. 8802 30 00, "p/st") and set `intrastat_supplementary_unit_amount` on it.
2. Post EU customer invoices for that product.
3. Export the DEBWEB2 XML from the Intrastat report.

Issue
The FR export collapses engine rows a second time in `_group_items`, because the DEBWEB2 format groups more aggressively than the SQL. The aggregator only declares `value` and `weight`: https://github.com/odoo/enterprise/blob/6ae5d3df6e9305416e4d6f74259cd01753025f42/l10n_fr_intrastat/models/account_intrastat_report.py#L308-L313 Items are then rebuilt as `dict(zip(grouping_key, key_tuple)) | grouped_item_values`. `SU_code` survives (it is in the grouping key), but the numeric `supplementary_units` is in neither side and is silently dropped as soon as two engine rows merge. The template then skips the element because of its `t-if="item.get('supplementary_units')"` guard: https://github.com/odoo/enterprise/blob/6ae5d3df6e9305416e4d6f74259cd01753025f42/l10n_fr_intrastat/data/intrastat_export.xml#L61

opw-6139657

Forward-Port-Of: odoo/enterprise#117357
Forward-Port-Of: odoo/enterprise#117033

### Steps to reproduce:

- Install delivery_envia
- Website > Configuration > eCommerce > Delivery Methods > Envia
- Enable the delivery method, sync the carrier and Publish it
- With a portal user > Shop > Add any product to your cart > Checkout
- Register an address a valid 'Chile' address and confirm say: 
    'street and Number': Avenida Providencia 1432, Depto 402
    'city': Santiago 'zip': 8320000
    'country': Chile  'state': Metropolitana
#### > Envia Error: Invalid Option - String is too long at #->properties:destination

### Cause of the issue:

The problem is caused by the fact that Envia's api expects a 2-3 digits to represent state codes: https://docs.envia.com/reference/state-by-code
The mapping from Odoo's code state representation to envia's one is expected ot be performed by this mapping:
https://github.com/odoo/enterprise/blob/75cba6d5a88ebc4e0f35040a173ac1c443638daf/delivery_envia/models/envia_request.py#L27-L43 when the address is converted here:
https://github.com/odoo/enterprise/blob/75cba6d5a88ebc4e0f35040a173ac1c443638daf/delivery_envia/models/envia_request.py#L535-L542 That being said, the `Chile`'s code states of have been changed in [6694a3942c58ff1a56c9e4b36edbe126dd1e66f8](https://github.com/odoo/odoo/commit/6694a3942c58ff1a56c9e4b36edbe126dd1e66f8) to match the official Iso but not in the Envia's mapping leading a failling match keeping the 4 charracter long `CL-RM` of the `Metropolitan` state provided in to the Envia's api as address data.

opw-6210007

Forward-Port-Of: odoo/enterprise#117280

Steps to reproduce:
===================
1. Go to Event, open an event page
2. Click "Register" & Select a ticket and confirm
3. Switch to edit mode

=> crash.

Cause:
======
The cleanup callback called `hide()` followed immediately by `dispose()`.
Bootstrap's `hide()` is asynchronous — it registers a `transitionend`
callback that fires `_hideModal()` after the CSS transition. `dispose()`
nullifies `this._element` synchronously via `BaseComponent`, so when the
`transitionend` fires and `_hideModal()` tries to access
`this._element.style`, it crashes with:

  TypeError: Cannot read properties of null (reading 'style')

This happened when switching to edit mode while the event registration
modal was open: the `public.interactions` service stopped the interaction,
triggering the cleanup.

Solution:
=========
Listen for `hidden.bs.modal` (fired at the end of `_hideModal`)
and only `dispose()` inside that handler, ensuring `_element` is still
valid throughout the transition.

task-6133395

Forward-Port-Of: odoo/odoo#264365

Steps to reproduce:
===================
1. Configure website with at least 1 language installed different from English. ex: English and French.
2. As anonymous user, change wehbsite language and make a donation via the donation snippet.
3. Check the outgoing confirmation email.

=> Email body is rendered in English.

Cause:
======
The donation confirmation email rendered with `self.partner_id.lang`. For anonymous donors, `partner_id` is the website's shared public user partner, so every anonymous donor received the email in whatever language was set on that partner (or English if unset), regardless of the language they were browsing in.

Solution:
=========
`payment.transaction` already has a `partner_lang` field auto-filled from `partner.lang` at creation.
- override it in the `/donation/transaction` controller with `request.env.lang`
when the public partner is used, capturing the request language at donation time (also works later from `_cron_post_process`, which has no request context);
- render `_send_donation_email` using `self.partner_lang` instead of `self.partner_id.lang`.

opw-5875338


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

Forward-Port-Of: odoo/odoo#259351

Issue:
---
Due to this issue, in multi-company environment, wrong fiscal position might be assigned to the order, leading to `incompatible companies` error.

Steps to reproduce:
1- On multi-company setup, assign a website to the second company.
2- Configure pickup method for second company.
3- Configure fiscal positions for both companies.
4- Setup auto invoice for second company.
5- Using public user, add a product to cart and checkout.
6- Use pickup method, and pay.

The order is not confirmed. If you enable debug mode after payment, it will show an `incompatible companies` error.

Cause:
---
https://github.com/odoo/odoo/blob/43f5ceadbc1f7df9898c327bf65bffdbe9860c1c/addons/account/models/partner.py#L247-L279 `_get_fiscal_position` is using environment company to compute the fiscal position.

However, `_compute_fiscal_position_id` causing the issue here is triggered inside `report_saleorder` template with user set as odoobot when trying to to send the confirmation.

As a result, the odoobot company's fiscal position will be used causing this issue.

Fix:
---
We should ensure company from sale order is used by setting it as env company.

opw-6186296

Forward-Port-Of: odoo/odoo#264123

Steps to reproduce
1. Enable "Batch Account Move Lines" in the Payroll settings.
2. Configure two employees' versions with an analytic distribution on the
   same analytic account but with different percentages (e.g. {acc: 50}
   for the first employee and {acc: 70} for the second).
3. Generate a payslip run containing both employees and validate it.

Issue
The generated account move aggregates the two payslips into a single
line whose analytic_distribution matches only the last employee being
processed; the other employee's percentage is silently lost.

`_get_existing_lines` decides whether an incoming line can merge into an
already accumulated one. When the incoming line has an analytic
distribution, the merge condition delegates to
`_check_partially_matching_accounts`:

https://github.com/odoo/enterprise/blob/e4a1326c7a8a74da7970aeaa9900c19d01634e31/hr_payroll_account/models/hr_payslip.py#L254-L271
https://github.com/odoo/enterprise/blob/e4a1326c7a8a74da7970aeaa9900c19d01634e31/hr_payroll_account/models/hr_payslip.py#L273-L283

That helper returns True as soon as any analytic account of the new
line appears anywhere in the existing line's distribution dict, without
comparing percentages. Two distributions such as {acc: 50} and
{acc: 70} share the same account, so the helper returns True, the
lines are merged, and whichever distribution ends up on the merged line
overwrites the other — the total amount is correct but the analytic
split is wrong.

The logic introduced in commit https://github.com/odoo-dev/enterprise/commit/e40a3166286a6bc546e9543b935233d2a110dc52 successfully addressed merging for rule-level distributions
with composite keys (e.g., {'13,7,12': 40}). However, that implementation is overly inclusive for employee-specific distributions.
It fails to differentiate between cases where the same analytic account is utilized across various employees but with different percentage allocations.
Because it only checks for an account overlap rather than a perfect distributional match, it incorrectly aggregates distinct financial dimensions into a single journal line

Solution
Compare the full analytic_distribution dict by strict equality. Lines
merge only when the distribution is identical (same keys AND same
percentages), keeping the batch feature anonymizing identically
configured employees while preserving one line per distinct
distribution.

opw-6102508

Forward-Port-Of: odoo/enterprise#114156

When scraping the component of a MO created by another user you could get an access error saying you don't have write access on account analytic lines.

Steps to reproduce:
-------------------
* Install timesheet_grid and project_mrp_account
* Create product A, storable
* Create product B with a cost of 20 and also storable
* Update the available quantity of product B
* Create a BoM for product A, it should only require one product B
* Update Marc Demo access right and make sure he doesn't have access to any accounting stuff and he has atleast timesheet approver
* Create a first MO for 1 product A and produce it
* Create a second MO for 1 prodcuct A but just confirm it
* Login as Marc Demo and try to scrap the component of the second MO
> Observation: You get an access error here https://github.com/odoo/odoo/blob/d98afdc08b46bf458eaa287ea882cc7663286a59/addons/stock_account/models/analytic_account.py#L95

opw-5954989

Forward-Port-Of: odoo/odoo#261588
Forward-Port-Of: odoo/odoo#255824