The standard cron process reconciles batches of 100 bank statement lines at a time. In multi-company environments with large historical datasets, this query frequently timed out, exceeding the 15-minute execution limit. Even when throttled to a batch size of 10 records, the query required approximately 18.8 seconds to execute.

The performance degradation was driven by the following factors:

1. Suboptimal Lateral Filtering: The statement line batch array filter was placed inside the `LATERAL` block's `WHERE` clause. This prevented the query planner from optimizing the drive path effectively across iterations.
2. Inefficient Join Sequence and Filtering: The original join order scanned `account_move_line` before resolving the company hierarchy constraint. As a result, millions of rows across all companies were retrieved from the index, forcing repeated primary key lookups on `res_company` before ultimately discarding over 99.9% of the records via the late `parent_path` hierarchy filter.

This commit addresses these issues by:

1. Moving the `st_line.id` filtering constraint out of the lateral subquery and into the outer main query block to guide the execution path properly.
2. Reordering the inner `LATERAL` subquery to resolve the company hierarchy (`res_company`) prior to joining `account_move_line`. This constraints the scan boundaries early in the pipeline.

Performance Benchmarks (10 record batch):
- Before Execution Time: ~18,818 ms
- Before Shared Hit Blocks: 8,535,272
- After Execution Time: ~130 ms
- After Shared Hit Blocks: 67,204 ms

Before Plan: https://explain.dalibo.com/plan/h4739gh3519eaa43
After Plan: https://explain.dalibo.com/plan/5ebc5g8deff272gc

Forward-Port-Of: odoo/enterprise#125686
Forward-Port-Of: odoo/enterprise#125250

## Current behavior:
In Malaysia's Statement of Account, the total and total overdue amounts
dont consider the selected Statement Date, and will calculate all the
balances up until today in the generated PDF report

## Expected behavior:
The total and total overdue amounts should only sum the balances included
in the report up until the selected Statement Date

## Steps to reproduce:
1. Install l10n_my_reports module, switch to Malaysian company
2. Go inside Invoicing > Report > Aged receivable
3. Select a specific date in the past
4. Observe that the total amounts dont match with the balance column, and wont change regardless of the date selected

## Cause of the issue:
The template used o.total_overdue which ignores the report domain
and statement date

## Fix:
Accumulate overdue_total in the template loop with the same domain
and date_to cutoff as the balance lines, so it always matches
the displayed Balance lines for the selected Statement Date

opw-6332970

Forward-Port-Of: odoo/enterprise#125410
Forward-Port-Of: odoo/enterprise#123694

Currently, when users group accrual reports by dates, aggregated computed fields are not calculated correctly. As a result, values such as the total amount may be displayed as zero even when the grouped records contain non-zero amounts.

## Steps to produce:
- Install Purchase and Accounting
- Create a product `Energy drink Sample` with cost 10$
- Create and Confirm a PO with the energy drink sample with vendor as `Administrator`
- Set `Received` as 1.
- Go to Accounting > Review > Bill to Receive
- Search Filter> Remove vendor grouping > Use Custom Group `Order Date`
- Expand the group

## Observed Behavior
Although the grouped lines contain an amount of 10 dollars, the aggregated total displayed in the sum remains zero.

The total should reflect the combined value of the grouped lines.

## Root Cause:
This issue occurs because opening the view triggers `_read_group_for_accrual`, which overrides the `_read_group` method on purchase order lines. The purpose of this override is to support grouping on computed fields that are not stored in the database such as `amount_to_invoice_at_date (Amount)`, `qty_received_at_date (Received)`.

When `_read_group_for_accrual` is executed, it delegates grouping for non-computed fields to the parent `_read_group` implementation, as shown at [1].

The parent method returns results in `res` similar to: 
```
[(datetime.datetime(2026, 6, 1, 0, 0), 1.0, 10.0, 1)]
```
During iteration over res at [2], the code uses `group[0]` as the grouping key. In this example, group[0] is `datetime.datetime(2026, 6, 1, 0, 0)`, which represents the granularity date
(e.g., the first day of the month when grouping by month).

However, `records_by_group` is keyed by the actual purchase order line order dates rather than the granularity dates returned by `_read_group`. For example:
```
{datetime.datetime(2026, 6, 12, 0, 0): purchase.order.line(1,)}
```

As a result, the lookup performed using the granularity date (`datetime.datetime(2026, 6, 1, 0, 0))` does not find a matching entry in `records_by_group`. Consequently, records falls back to an empty `purchase.order.line()` recordset.

Later, at [3], the aggregation logic computes totals using this empty recordset. Since the required fields are evaluated on an empty set of records, the aggregated values are computed as zero.

This ultimately causes the method to return a total value of zero
[1]-
https://github.com/odoo/enterprise/blob/eeea1377a7d36d11e140c44dee30a45228e7b4a6/account_accountant/models/analytic_mixin.py#L9-L24 
[2]-
https://github.com/odoo/enterprise/blob/eeea1377a7d36d11e140c44dee30a45228e7b4a6/account_accountant/models/analytic_mixin.py#L40-L42 
[3]-
https://github.com/odoo/enterprise/blob/eeea1377a7d36d11e140c44dee30a45228e7b4a6/account_accountant/models/analytic_mixin.py#L44-L47

## Solution:
The issue can be resolved by grouping records using the same date granularity specified in the groupby, rather than using the field values.

By aligning the grouping logic with the granularity returned by `_read_group` (for example, grouping by the first day of the month when using monthly grouping ), the keys in `records_by_group` match the values returned in `res`. As a result, the corresponding records are correctly retrieved during aggregation.

This ensures that the aggregation is performed on the appropriate purchase order lines instead of an empty recordset, allowing the computed totals to be calculated correctly.

[opw-6261225](https://www.odoo.com/odoo/project/49/tasks/6261225)

Forward-Port-Of: odoo/enterprise#120369

Currently, an error occurs when the "Payroll: Update Data" scheduled action is run.

**Steps to Reproduce:**

 - Install `l10n_au_hr_payroll` with demo data.
 - Switch to `Australian Company`.
 - Go to `Payroll` > `Configuration` > `Salary` > `Rule Categories`. 
 - Delete all records related to the `Australian Company`. 
 - Go to `Scheduled Actions` and run `Payroll: Update Data`.

`ValueError: External ID not found in the system: l10n_au_hr_payroll.rule_category_ote`

After [this commit], the category_id field becomes non-required, allowing users to delete a rule 
category record even if it is linked to a salary rule. When updating the data file [1], an error is 
raised due to the missing rule category.

This commit ensures that when updating the salary rule data, it updates the category data 
beforehand as like [here]

[this commit]: https://github.com/odoo/enterprise/commit/c663fd2a81b7f6b34f8199fdbdc4a75c4f21379e

[1] https://github.com/odoo/enterprise/blob/b6612dd58276646b81a3a12cd48e8427ea5359c2/l10n_au_hr_payroll/models/hr_payslip.py#L76-L83

[here]: https://github.com/odoo/enterprise/blob/b6612dd58276646b81a3a12cd48e8427ea5359c2/l10n_ch_hr_payroll/models/hr_payslip.py#L1074-L1087

sentry-7349905716

Forward-Port-Of: odoo/enterprise#121167

In a [previous PR], a test was introduced to reject any `l10n_xx_hr_*` module that has a `countries` key in its manifest and depends on a module that also has that country key.

This test was too broad and rejected some valid cases:
1. A non-auto-install module can have a country key defined to add  flags in the apps kanban view. ([src])
2. A module that has a country-specific regular dependency, but not as an  auto-install condition.

The second case is illustrated by [l10n_us_hr_payroll], which should auto-install when `hr_payroll` is installed and a US company exists.
With the old test, achieving this required adding `l10n_us` to its auto-install dependencies. 
But, since `l10n_us` is not auto-installable, `l10n_us_hr_payroll` would not be installed if you create a DB with a US company and only install `hr_payroll`.

In practice, that module was still being installed via a [post-init hook] in `hr_payroll`. This hook was installing all `l10n_XX_hr_payroll` modules for each country where a company is located, which is the behavior of the `countries` parameter in the manifest.

This caused issues during upgrades as this runs late in the process: after the auto-discovery phase.
Modules installed by this hook would be considered as `uninstalled` until `hr_payroll` is loaded.


This commit narrows the check to only fail if:
- A module has a `country` key in its manifest, and
- It has a country-specific module in its **auto-install** dependencies.

Moreover, it modifies `l10n_us_hr_payroll` to correctly rely on the auto_install mechanism instead of the post-init hook.

[previous PR]: https://github.com/odoo/enterprise/pull/101843
[src]: https://github.com/odoo/odoo/blob/6df9f92a537aa4bb4ee5dc946fe31c4e56e6dfea/odoo/addons/base/models/ir_module.py#L271-L273
[l10n_us_hr_payroll]: https://github.com/odoo/enterprise/blob/24a33ffb769557be498d61328522bb77f68d3a5a/l10n_us_hr_payroll/__manifest__.py
[post-init hook]: https://github.com/odoo/enterprise/blob/85185595cfd1ee5310ceb9dc80c0589accad2f19/hr_payroll/__init__.py#L21

Forward-Port-Of: odoo/enterprise#120279

Steps to reproduce:
- Set the database language to Spanish (Latin America).
- Create a customer invoice, confirm it and send it to the SII.
- Print it using Print > Invoice PDF copy (Chile).
- Scroll to the CEDIBLE section at the bottom of the PDF.

Cause of the issue:
The CEDIBLE footer is merged into l10n_cl.report_invoice_document, which account.report_invoice (odoo/addons/l10n_cl/views/report_invoice.xml) renders with t-lang set to the invoice partner's lang, not the database/user language. The disclaimer text was hardcoded in English and relied on the regular translation to be shown in Spanish, so as
soon as the partner's lang field isn't Spanish, the translation lookup falls back to the untranslated English source, regardless of the database language.

Solution:
This disclaimer is boilerplate mandated by Chilean law: it must always be printed in Spanish, independently of the invoice partner's or current user's language. The same template already follows that rule a few lines above for the SII stamp block ("Timbre Electrónico SII..."), which is hardcoded in Spanish instead of relying on translation.

opw-6390207

Forward-Port-Of: odoo/enterprise#124916

Steps to reproduce the bug:
- Create a BOM for product P1 with one work order WO1
- Create 3 quality points linked to WO1 via the `operation_id` field
- Confirm a manufacturing order for P1:
    - 3 quality checks A → B → C are generated
- Open the shop floor for the work order:
    - Observe that all 3 quality checks are displayed
- Delete quality check B (the middle one)
- come back to the shop floor for the work order:
- Observe that quality check C is no longer displayed in the shop floor

Problem:
After deleting check B, check C disappeared from the shop floor. Quality checks are stored as a doubly-linked list via the `next_check_id` and `previous_check_id` fields on `quality.check`. The shop floor JS (`mrp_display_record.js`) traverses this list starting from the check with no `previous_check_id`, then follows `next_check_id` until the chain ends. When check B was deleted, it nullified the FK references pointing to it, leaving check A with `next_check_id = False` and check C with `previous_check_id = False`. The traversal from A therefore stopped immediately, and C was never reached.

No `unlink` override existed on `quality.check` to repair the chain before deletion.

Solution:
Added an `unlink` override that, before deleting each check, reconnects its predecessor and successor: if the deleted check has both a previous and a next, `prev.next_check_id` is set to `next` and `next.previous_check_id` is set to `prev`, preserving a valid chain for the remaining checks.

opw-6369298

Forward-Port-Of: odoo/enterprise#124118

### Steps to reproduce:
- In a database with Switzerland localization, install 'Accounting' and 'Payroll'
- Manually change the debit and credit accounts on the Swiss ELM salary rules (rule code 1000)
- Install 'POS'
- Check the accounts you configured on the salary rules
>The accounts are reset to their default values

### Cause of Issue:
POS depends on the module `stock_account`. When `stock_account` is installed, the `_configure_journals` method in its `__init__.py` creates a new `account.journal` for inventory valuation. To apply default values to this journal, the method retrieves data from the chart template.
https://github.com/odoo/odoo/blob/7d16ef88784e18e885b97dbded3231775f1349d2/addons/stock_account/__init__.py#L41

The `hr_payroll_account` module overrides `_post_load_data` and unconditionally calls `_load_payroll_accounts(template_code, company)`. https://github.com/odoo/enterprise/blob/fcf06997a0eb999af86e4b6917311a86f04a390e/hr_payroll_account/models/account_chart_template.py#L16-L18

This triggers the reinstallation of the default payroll accounts, which overwrites and discards any manual configuration changes the user has made to their salary rules.

### Fix:
Ensure that default payroll accounts are only reset during a genuine chart of accounts loading process, and not during localized post-load operations triggered by other modules.

opw-6251112

Forward-Port-Of: odoo/enterprise#121687

## Issue:
Exporting the general ledger as SIE4 set the duration of fiscal years to one year from the starting date of the fiscal year.

## Steps to reproduce:
- Create a fiscal year A of one month for year X-1 (December 1st to December31th year X-1)
- Create a fiscal year B of 1 year and 1 month (January 1st Year X to January 31th year X+1)
- Create Invoices in November year X-1, December year X-1, year X and in January year X+1 and confirm them
- Go to General Leder
- Set date to the fiscal year B
- Export as SIE4

### Current behavior:
- **for previous fiscal year**
	- declared fiscal year (#RAR field) goes :
		- from fiscal year X date_from -1 year
		- to fiscal year X date_to -1 year
	- However data are computed:
		- from fiscal year X date_from -1 year
		- to fiscal year X date_from -1 day
- **for current fiscal year**
	- declared fiscal year (#RAR field) goes :
		- from fiscal year X date_from
		- to fiscal year X date_to
	- However data are computed:
		- from fiscal year X date_from
		- to fiscal year X date_from +1 year

### Expected behavior:
Declared fiscal year match the one that is use for computation.
- for previous fiscal year
	- from fiscal year X-1 date_from
	- to fiscal year X date_from -1 day
- for current year
	- from fiscal year X date_from
	- to fiscal year X date_to

Cause:
Current year length was wrong because it [relied on](https://github.com/odoo/enterprise/blob/22b4100006ec24bf6e4b64042cbfdba360fcf470/l10n_se_sie4_export/models/account_general_ledger.py#L139-L140) the next_date_from which was wrong.


opw-6264766

Forward-Port-Of: odoo/enterprise#125354

Issue
-----
International deliveries for fractions of items (eg 500g of a product sold by kg) are rejected by Sendcloud.

Steps to reproduce
-----
- Setup Sendcloud
	- Fedex international
- Create a product
	- weight: 1kg
	- valid hs code
- Create a contact (outside EU if the company is in EU)
- Deliver 0.5 of the product to the contact

> Error "... parcel not returned from Sendcloud"

Cause
-----
Sendcloud returns he folloing error:

> "The total weight for declared items exceeds the total weight set for the shipment."

This is because the `weight` set on the shipment

https://github.com/odoo/enterprise/blob/99a13453cac8a7a4677cef3df8896329c90c9e99/delivery_sendcloud/models/sendcloud_service.py#L449-L464

corresponds to the weight of the package, whereas the weight set on the description of the product in `parcel_items` corresponds to the weight of one "full" unit of the product.

https://github.com/odoo/enterprise/blob/99a13453cac8a7a4677cef3df8896329c90c9e99/delivery_sendcloud/models/sendcloud_service.py#L327-L335

We cannot change the quantity in `parcel_items` to match the actual delivered one because the field should be an integer.

https://sendcloud.dev/api/v2/parcels/create-a-parcel-or-parcels#body-one-of-0-parcel-parcel-items-items-quantity

The price is also off, because it gets taken from the `move_line`, so it reflects the price of the actual quantity and not a "full" item.

https://github.com/odoo/odoo/blob/208a8a6a5adb8ec1f2710453c2ee3b54c55a9f1e/addons/stock_delivery/models/delivery_carrier.py#L235

Note that this issue is common to **all UoM types**.

Solution
-----
Since we cannot change the quantity, we can instead adapt the description and weight sent in `parcel_items`. For example, sending 300g of sugar, we would send
- description: "Sugar (0.3 kg)"
- weight: "0.300"

-----
Ticket:
opw-6346330

Forward-Port-Of: odoo/enterprise#124686

### Problem

`Mail: Fetchmail Service` cron aborts with `AttributeError: 'NoneType' object has no attribute 'upper'` in `l10n_cl_edi/models/fetchmail_server.py::_process_incoming_customer_claim` when an incoming customer claim DTE has no `<RUTRecep>`:

```python
dte.findtext('.//ns0:RUTRecep', ...).upper() or
dte.findtext('.//ns0:RutReceptor', ...).upper()
```

`findtext()` returns `None` when the tag is missing, so `.upper()` blows up before the `or` fallback can run. Once the cron hits such a message it re-crashes on every subsequent run and blocks the whole mailbox until the offending mail is deleted.

### Fix

Guard each `findtext(...)` with `or ''` so the `or` chain actually falls through. Empty `partner_vat` is already handled by the existing "Partner … has not been found" branch a few lines below.

### Traceback (Odoo 19)

```
File "/mnt/extra-addons/enterprise/l10n_cl_edi/models/fetchmail_server.py", line 285, in _process_incoming_customer_claim
    dte.findtext('.//ns0:RUTRecep', namespaces=XML_NAMESPACES).upper() or
AttributeError: 'NoneType' object has no attribute 'upper'
```

### Ticket

No ticket open for this but opw-5257481 is related.

Forward-Port-Of: odoo/enterprise#123387

While trying to fix the SAT cron, we did not think it through
it could cause infinite cron triggering.
Indeed, the write_date is updated on every record that is handled.

Fix is manyfold:
- Avoid re-processing what we already check within the last 4 hours/12 hours
depending on the type of the document.
- The domain takes the *static* create date instead of the write_date
to make sure we don't endless re-process the same record and that
the window of 7/60 days applies.
- Limit the Vendor Bill to be checked only during 7 days after their creation.
- Use the create_date in the order of the search to ensure we process older
records first, before their time-window closes.
- Process the Vendor Bills last, this ensure Customer Invoices will be processed
in priority in case we are not able to process everything within the last 4/12 hours.

This is still imperfect and a little fragile, we will find a better solution
in master, most likely by adding a dedicated field to keep track of the
last SAT check.

See https://github.com/odoo/enterprise/pull/123213
See https://github.com/odoo/enterprise/pull/103272

task-none

Forward-Port-Of: odoo/enterprise#125598
Forward-Port-Of: odoo/enterprise#125317

**Issue**:
Even if the currency rate is changed on the invoice, the today currency rate is used
while generating stock landed cost.

**Steps to reproduce**:
- Enable two currencies (ex: Dollar and Euro)
- Enable Landed Costs on the settings
- Create a service product
- Create a bill for that product for 100 dollar and click the Landed Costs check box
- Change the currency rating (ex: 1 USD = 0.5 euro) and confirm the bill
- Click on "Create Landed Costs"
-> The cost is not 200

**Cause**:
While creating the landed cost:
https://github.com/odoo/odoo/blob/e906eb23d698061f146ba67aae420eb7bb5e8a68/addons/stock_landed_costs/models/account_move.py#L21
it uses `_convert` from the currency:
https://github.com/odoo/odoo/blob/e906eb23d698061f146ba67aae420eb7bb5e8a68/addons/stock_landed_costs/models/account_move.py#L35
which gets the `conversion_rate` defined on the currency, regardless whether `is_invoicing` is true:
https://github.com/odoo/odoo/blob/e906eb23d698061f146ba67aae420eb7bb5e8a68/odoo/addons/base/models/res_currency.py#L294
https://github.com/odoo/odoo/blob/e906eb23d698061f146ba67aae420eb7bb5e8a68/addons/account/models/account_move.py#L6350-L6351

**Solution**
It is safe to replace the `convert` calls by the `currency_rate` of the `Account.move.line` since:
https://github.com/odoo/odoo/blob/e906eb23d698061f146ba67aae420eb7bb5e8a68/addons/account/models/account_move_line.py#L735-L747
`currency_rate` will be set as `_get_conversion_rate` when not invoicing.
Also add rounding since `_convert` is called with `round=True` by default.

opw-6047031

Forward-Port-Of: odoo/odoo#256394

Steps to reproduce the bug:
- Run the product module test suite on a loaded/slow CI runner
- Observe test_get_first_possible_combination occasionally failing

Problem:
test_get_first_possible_combination asserts that
_get_first_possible_combination() completes in under 0.5 seconds on a template with 10 attributes x 50 values and exclusion rules. On a busy runner (Testing country uk build) it took 0.587s and the test failed with `0.5868358612060547 not less than 0.5`, even though the returned combination was correct. The 0.5s threshold is an arbitrary sanity check meant to catch a gross algorithmic regression (e.g. loss of early pruning of invalid combinations), not a strict performance SLA, so it is too tight to survive normal CI load variance.

Solution:
Raise the threshold to 2 seconds, keeping enough margin to absorb CI load variance while still catching a real performance regression, which would take far longer than the current computation.

runbot-243606

Forward-Port-Of: odoo/odoo#277986

[FIX] website_hr_recruitment: fix country filter

Bug reproduction:
    1 - Recruitment, you need to have 1 remote and 1 US jobs at least.
    2 - Go to job page in website, activate country filter.
    3 - Select US jobs and search for the remote job.
    4 - All countries filter is readonly and it is not pressable.

Bug cause:
    1 - Check is done with jobs value
        1.1 - If no matching, readonly button is displayed.

Bug solution:
    1 - count_per_filter is used instead of jobs
        1.1 - Even there are matchings for other countries, it shows.
    2 - Also, searched keyword is added to filter url
        2.1 - When there is search in other country and we click to it:
            2.2 - The searched keyword will be still there.

task-6284436

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#277726

The bugfix introduced in https://github.com/odoo/odoo/commit/01d11a770f89c391f7c6a2c46a3d770d10afb428 made it so that "personal" outgoing mail servers are blocked/ignored from being used in email marketing as dedicated servers.

In doing so, it missed the fact that while in *Email Marketing > Settings*, the "Dedicated Server" picker now correctly ignores personal OMS entries, the selection widget for `mail_server_id` in `view_mail_mass_mailing_form` still let's you manually select a OMS with an owner set. As there is not warning or an explicit error, this can lead to accidental miss configurations on an email marketing campaign, where the selected OMS will be actually ignored by the backend.

To align the changes introduced by the bugfix, we add a search domain to the selection field, so that only OMS with `('owner_user_id', '=', False)` will be presented as a choice.

OPW-6388562

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

Forward-Port-Of: odoo/odoo#278595

# How to reproduce
- Have two language in the db
- Create an e-Commerce category
- Have a different translation for each language for that category's name
- Copy the link to that category's name in one language (Should be something like /shop/category/name-x)
- Have two websites, each with a different default language
- Create a link to the shop category in each website.
> ! The link must be the exact same
> You can put it in the header menu for simplicity
- Open the website editor
- Do 2 or 3 times :
    - click on the category link and switch website

# The issue
A traceback is displayed

# Cause
This manipulation will make us enter an infinite redirect scenario described here :
https://github.com/odoo/odoo/blob/f8741728294a5147c7d2427d9997738096386262/addons/website/static/src/client_actions/website_preview/website_builder_action.js#L371-L384

The problem is that this commit introduced an assignation to `iframe.contentDocument.body` before the patch :
https://github.com/odoo/odoo/commit/89994eb7a54ca606bab26b6d579d03e86c11ba60

But in our case, iframe.contentDocument is null, so it throws an error before the patch can be applied

opw-6322115

Forward-Port-Of: odoo/odoo#276634

Steps to reproduce the issue easily:
- Remove the section in the footer.
- Drop enough snippets to have a scroll bar and to not see the footer when the scroll is at the top.
- Drop the "Pricelist" snippet at the bottom of the page and click on a column.
- Scroll up so the footer and the bottom of the snippet are not visible, and add a pricelist item with the "Add Product" option.
- => The page scrolls to the new item, but a big white space appears at the bottom of the screen, as if we scrolled too far.

The same issue happens with similar steps in the following cases:
- When using any option using the `addItem` action.
- When undoing/redoing a step that was done in an element not in the viewport (the screen will scroll to it and we will have the issue).
- When showing an invisible element (the screen will scroll to it if not in the viewport)
- Adding a grid item with the "Add Elements" option.
- Adding a new card in the "Floating Cards" snippet.

The common point to all these cases is that they all scroll to the added or shown element with the `scrollIntoView` built-in function, which scrolls everything, including the viewport. It also doesn't take into account the header that changes during the scroll, often ending with the element hidden by the header.

This commit fixes these issues by using the builder `scrollTo` util, which takes the header into account and only scrolls what needs to be. This function should always be preferred when scrolling in the builder.

task-6314322

Forward-Port-Of: odoo/odoo#277865
Forward-Port-Of: odoo/odoo#275686

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

When rendering floating-point numbers with high decimal accuracy (e.g., UoM quantities set to 10 decimals), the UI can occasionally display a trailing parasitic digit (such as 53000.0000000002 instead of 53000.0000000000).

This commit resolves the issue by backporting the formatting logic from master. The `maxDecDigits` calculation is moved outside the conditionals so it unconditionally caps precision for all numbers. Furthermore, the global significant digit ceiling is reduced from 15 to 14.

This 14-digit ceiling reserves a 1-digit buffer, allowing the newly introduced `formatFixedDecimals` utility to safely run `roundDecimals` on the float. This mathematically sanitizes the trailing corrupted digit before it is ever converted to a string.

opw-6313540

**Current behavior before PR:**
- With Product UoM set to 10 Decimal Accuracy, floats such as 53000 are displayed with a corrupted digit (e.g. 53000.0000000002)

**Desired behavior after PR is merged:**
- With Product UoM set to 10 Decimal Accuracy, floats such as 53000 are displayed without corrupted digits (e.g. 53000.000000000)

This PR is essentially a backport of https://github.com/odoo/odoo/commit/07da917f6e3319b4acde1029e77f69f1aba314b8 and https://github.com/odoo/odoo/commit/c4e7ba8d8fdfd7b0c442cf834f562ef8cedf019b for numbers.js

Forward-Port-Of: odoo/odoo#277898
Forward-Port-Of: odoo/odoo#272940

Error-1 :
```
raise ValueError('External ID not found in the system: %s' % xmlid)
ValueError: External ID not found in the system:
account.1_l10n_id_domestic_fiscal_position
```

Error-2 :
```
raise ValueError('External ID not found in the system: %s' % xmlid)
ValueError: External ID not found in the system: account.1_tax_luxury_sales
```

Reason-1 :
- In [this](https://github.com/odoo/odoo/commit/e342a45aceb60b44052c5d52e9ecc35a9a7340da) commit new account.fiscal.positions were added and linked to acc.tax using fiscal_position_ids .
- In [this](https://github.com/odoo/odoo/blob/saas-19.2/addons/l10n_id/migrations/1.3/end-migrate_update_taxes.py) migration script, while creating taxes it didnt find fiscal positions, so need to create them first.

Reason-2 :
- original_tax_ids was also added in same commit, if client deleted those tax(ie tax_luxury_sales) will fail while creating `tax_luxury_sales_pemungut_ppn`, It needs to be created first too.

- upg : [4341887](https://upgrade.odoo.com/odoo/upgrade.request/4341887)
- opw : [6285978](https://www.odoo.com/odoo/project/70/tasks/6285978)

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

Description of the issue this commit addresses:

When a member of the Invoicing group tries to create a payment trough the L10nPlAccountPaymentRegister wizard, upon clicking "Create Payment", an AccessError is thrown. Invoicing group members should be able to handle payments so this is an issue.

---

Steps to reproduce:

1. Make sure sale_management and l10n_pl_bank_verification are installed.
2. Create a new user with "Invoicing" Accounting group.
3. Create a new sales order with said user (any customer, any product)
4. Confirm the quotations and, from its form view, "Create Invoice".
5. Confirm the invoice and, from its form view, "Pay".
6. Upon clicking "Create Payment", an Access Error is thrown.

---

Desired behavior after this commit is merged:

This commit makes sure an Invoicing group member is able to create the payment withtout AccessErrors being thrown.

---

task-none
feedback from: https://github.com/odoo/odoo/pull/267992

---

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

Forward-Port-Of: odoo/odoo#278688
Forward-Port-Of: odoo/odoo#270008

### Steps to reproduce:

- Create 2 companies: c1, c2
- Create 2 storable products: P, Comp
- In c1 update the available qty of P to 10 units and its cost to 50
- In c2 create a kit bom for P: 1 x Comp
- With c1 > Accounting > Review > inventory > Inventory Valuation
#### > The total value of Super product is 0 instead of 500

### Cause of the issue:

The total value of the product will be set to 0 since the `qty_available` of the product is incorrectly computed to be 0:
https://github.com/odoo/odoo/blob/cb7b3de6cea07464bcadd1325f52533d34ce09bc/addons/stock_account/models/product.py#L240-L243
This happens because the `_find_bom` used in the override of the `_compute_quantities_dict` in mrp does not consider take the contextual company into account:
https://github.com/odoo/odoo/blob/cb7b3de6cea07464bcadd1325f52533d34ce09bc/addons/mrp/models/product.py#L271-L289 and hence considers incorrectly that the product is a kit.

### Note:

We make the same company dependency as in the `is_kits` computation: https://github.com/odoo/odoo/blob/cb7b3de6cea07464bcadd1325f52533d34ce09bc/addons/mrp/models/product.py#L41-L47

opw-6361690

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

Forward-Port-Of: odoo/odoo#276306

Issue
-----
International deliveries for fractions of items (eg 500g of a product sold by kg) are rejected by Sendcloud.

Steps to reproduce
-----
- Setup Sendcloud
	- Fedex international
- Create a product
	- weight: 1kg
	- valid hs code
- Create a contact (outside EU if the company is in EU)
- Deliver 0.5 of the product to the contact

> Error "... parcel not returned from Sendcloud"

Cause
-----
Sendcloud returns he folloing error:

> "The total weight for declared items exceeds the total weight set for the shipment."

This is because the `weight` set on the shipment

https://github.com/odoo/enterprise/blob/99a13453cac8a7a4677cef3df8896329c90c9e99/delivery_sendcloud/models/sendcloud_service.py#L449-L464

corresponds to the weight of the package, whereas the weight set on the description of the product in `parcel_items` corresponds to the weight of one "full" unit of the product.

https://github.com/odoo/enterprise/blob/99a13453cac8a7a4677cef3df8896329c90c9e99/delivery_sendcloud/models/sendcloud_service.py#L327-L335

We cannot change the quantity in `parcel_items` to match the actual delivered one because the field should be an integer.

https://sendcloud.dev/api/v2/parcels/create-a-parcel-or-parcels#body-one-of-0-parcel-parcel-items-items-quantity

The price is also off, because it gets taken from the `move_line`, so it reflects the price of the actual quantity and not a "full" item.

https://github.com/odoo/odoo/blob/208a8a6a5adb8ec1f2710453c2ee3b54c55a9f1e/addons/stock_delivery/models/delivery_carrier.py#L235

Note that this issue is common to **all UoM types**.

Solution
-----
Since we cannot change the quantity, we can instead adapt the description and weight sent in `parcel_items`. For example, sending 300g of sugar, we would send
- description: "Sugar (0.3 kg)"
- weight: "0.300"

-----
Ticket:
opw-6346330

Forward-Port-Of: odoo/odoo#277440

When a bus process restarts, every client on every database it serves loses its websocket at the same instant and immediately schedules a reconnection. Each database that comes back triggers a registry recompute server-side, so a tight reconnection window makes all of those recomputes land together and pile up on the freshly started process.

The jitter added to each reconnection delay was only one second, far too narrow to break up that wave. Widen it to thirty seconds so the retries of the many clients fan out over a much wider window and the registry recomputes spread over time instead of colliding.

Raise the ceiling on the retry delay to two minutes to match that wider spread, and drop the exponential growth factor: with a thirty-second jitter accumulating on every attempt, the delay already climbs on its own, so scaling it further only pushed clients toward the ceiling sooner without spreading them any better.

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#278599
Forward-Port-Of: odoo/odoo#276869