During migration, the `l10n_pl` end-migrate script was loading
 for every company using the `pl` chart template, including child companies.

However, account codes must be [unique](https://github.com/odoo/odoo/blob/18.0/addons/account/models/account_account.py#L1033) across parent and child companies.
Since the chart is already loaded for the root company, reloading it for child companies cause duplicate account code errors during migration.

To prevent this, restrict chart loading to root companies only, which is consistent with how account code uniqueness is enforced.

**Steps to reproduce:**
1. Create a database in 17.0
2. Install `account_accountant` and `l10n_pl`
3. Create a child (branch) for the company using the `pl` chart template
4. Migrate the database to 18.0
5. Migration fails with duplicate account code validation errors

**Traceback**
```py
Traceback (most recent call last):
  File "/home/odoo/odoo18/community/odoo/service/server.py", line 1366, in preload_registries
    registry = Registry.new(dbname, update_module=update_module)
  File "<decorator-gen-13>", line 2, in new
  File "/home/odoo/odoo18/community/odoo/tools/func.py", line 97, in locked
    return func(inst, *args, **kwargs)
  File "/home/odoo/odoo18/community/odoo/modules/registry.py", line 129, in new
    odoo.modules.load_modules(registry, force_demo, status, update_module)
  File "/home/odoo/odoo18/community/odoo/modules/loading.py", line 523, in load_modules
    migrations.migrate_module(package, 'end')
  File "/home/odoo/odoo18/community/odoo/modules/migration.py", line 222, in migrate_module
    exec_script(self.cr, installed_version, pyfile, pkg.name, stage, stageformat[stage] % version)
  File "/home/odoo/odoo18/community/odoo/modules/migration.py", line 259, in exec_script
    mod.migrate(cr, installed_version)
  File "/home/odoo/odoo18/community/addons/l10n_pl/migrations/2.1/end-migrate.py", line 8, in migrate
    Template._load_data({'account.account': Template._get_account_account('pl')})
  File "/home/odoo/odoo18/upgrade/migrations/account/0.0.0/pre-ensure-deferred-accounts.py", line 36, in _load_data
    return super()._load_data(data, *args, **kwargs)
  File "/home/odoo/odoo18/community/addons/account/models/chart_template.py", line 677, in _load_data
    created_records[model] = self.with_context(lang='en_US').env[model]._load_records(all_records_vals, ignore_duplicates=ignore_duplicates)
  File "/home/odoo/odoo18/community/odoo/models.py", line 5531, in _load_records
    records = self._load_records_create([data['values'] for data in to_create])
  File "/home/odoo/odoo18/community/odoo/models.py", line 5435, in _load_records_create
    records = self.create(vals_list)
  File "<decorator-gen-196>", line 2, in create
  File "/home/odoo/odoo18/community/odoo/api.py", line 498, in _model_create_multi
    return create(self, arg)
  File "/home/odoo/odoo18/community/addons/account/models/account_account.py", line 987, in create
    records._ensure_code_is_unique()
  File "/home/odoo/odoo18/community/addons/account/models/account_account.py", line 1064, in _ensure_code_is_unique
    raise ValidationError(
odoo.exceptions.ValidationError: Account codes must be unique. You can't create accounts with these duplicate codes: 01.000.100, 01.000.200, 01.000.400, 01.000.900, 02.000.100, 02.000.200, 02.000.300, 02.000.900, 03.000.100, 03.000.200, 03.000.300, 03.000.400, 03.000.500, 03.000.600, 03.000.700, 03.000.800, 03.000.900, 03.050.100, 03.050.200, 03.050.300, 03.050.900, 07.010.200, 07.010.300, 07.010.400, 07.010.500, 07.010.600, 07.020.100, 07.020.200, 07.020.300, 07.030.100, 07.030.200, 08.000.100, 08.000.200, 08.000.300, 08.000.400, 08.000.500, 10.000.100, 10.000.200, 10.000.900, 13.000.100, 13.000.200, 13.000.900, 14.000.100, 14.000.200, 14.000.900, 14.050.100, 20.000.100, 20.000.200, 20.000.300, 21.000.100, 22.000.100, 22.010.100, 22.010.200, 22.010.300, 22.020.100, 22.020.200, 22.020.300, 22.030.100, 22.030.200, 22.030.300, 22.030.400, 22.030.500, 22.030.600, 23.000.100, 23.000.200, 23.000.900, 24.010.100, 24.010.200, 24.020.100, 24.020.200, 24.030.100, 24.030.200, 24.030.300, 24.030.400, 24.050.100, 24.090.100, 24.090.200, 24.090.300, 24.090.900, 28.000.100, 29.000.100, 29.010.100, 29.020.100, 30.000.100, 30.000.200, 30.000.300, 30.000.400, 30.000.500, 30.000.600, 30.000.700, 30.000.800, 30.000.900, 31.010.100, 31.060.100, 31.090.100, 33.000.100, 33.000.200, 33.000.300, 33.000.400, 33.000.500, 33.000.600, 34.010.100, 34.020.100, 34.020.200, 34.020.300, 34.020.400, 34.060.100, 34.070.100, 39.000.100, 40.000.100, 40.010.100, 40.010.200, 40.010.300, 40.010.400, 40.010.900, 40.020.100, 40.020.200, 40.020.300, 40.020.400, 40.020.500, 40.020.600, 40.020.700, 40.020.900, 40.030.100, 40.030.200, 40.030.300, 40.030.400, 40.030.500, 40.030.600, 40.030.700, 40.030.800, 40.030.900, 40.040.100, 40.040.200, 40.050.100, 40.050.200, 40.050.300, 40.050.900, 40.090.100, 49.000.100, 49.000.200, 49.000.300, 49.000.400, 50.000.100, 50.000.200, 50.010.100, 50.010.200, 52.010.100, 52.070.100, 53.000.100, 53.000.200, 55.000.100, 55.000.200, 58.000.100, 60.000.100, 60.010.100, 60.020.100, 62.000.100, 62.010.100, 64.000.100, 64.010.100, 65.000.100, 65.010.100, 70.000.100, 70.000.200, 70.000.300, 70.000.400, 70.010.100, 70.010.200, 70.010.300, 70.010.400, 73.000.100, 73.000.200, 73.000.300, 73.000.400, 73.010.100, 73.010.200, 73.010.300, 73.010.400, 74.000.100, 74.000.200, 74.000.300, 74.010.100, 74.010.200, 74.010.300, 75.000.100, 75.000.200, 75.000.300, 75.000.400, 75.000.500, 75.000.600, 75.000.700, 75.000.900, 75.010.100, 75.010.200, 75.010.300, 75.010.400, 75.010.500, 75.010.900, 76.000.100, 76.000.200, 76.000.300, 76.000.400, 76.000.900, 76.010.100, 76.010.200, 76.010.300, 76.010.900, 79.000.100, 79.000.200, 79.000.300, 79.000.400, 79.000.500, 80.000.100, 80.000.200, 80.000.300, 80.000.400, 81.010.100, 81.020.100, 81.030.100, 81.040.100, 82.000.100, 83.000.100, 83.000.200, 83.010.000, 83.010.100, 83.010.200, 84.010.000, 84.020.100, 84.020.200, 85.010.100, 85.020.100, 85.020.200, 85.020.300, 86.000.100, 87.000.100, 87.000.900
```

**Fix:**
- Load `account.account` records only for root companies during When the chart template loads for `pl` localization.

opw-5932421
upg-3895331

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

### Steps to reproduce:
	- Create a Overtime hours time off type
	- Create mutliple allocations with different start dates but no end date
	- Create some leaves for the created allocations one after each allocation start date
	- Compare the number of hours remaining for the allocations' employee in his time off dashboard and in the Balance report.

### Cause:
After this commit https://github.com/odoo/odoo/pull/245860/changes/d9bb4d206e91d10eac7311adede307b8c5019213 we changed the way we match leaves with allocations but we were strict that the leave has to lie in between the allocation dates and this created a wrong accumlated taken_hours in the taken_per_allocation subquery.

### Fix:
Following the same approach we use in  if
the allocation has no expiry date we don't check if the leave.date_to > allocation.date_from as we are going to treat all allocations as they form one big allocation that started in the earliest start date

opw-5474596

Forward-Port-Of: odoo/odoo#252349
Forward-Port-Of: odoo/odoo#250432

### 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#253451
Forward-Port-Of: odoo/odoo#252034

Versions:
---
Reproducible on 18.0+
Fix targets 16.0 to keep the code consistent across versions

Issue:
---
Due to this issue, a line with zero subtotal amount will be discarded
in quotation document upload.

Steps to reproduce:
---
1- In sale app, upload a quotation document without line amount. (You could use the one attached in the ticket)
2- As you see, lines are discarded.

Cause:
---
This regression is introduced in https://github.com/odoo/odoo/pull/245862, to prevent lines with zero amount in accounting. The https://github.com/odoo/odoo/pull/245862 targets 16.0. However, the `sale_edi_ubl` is introduced on 18.0.

Fix:
---
Instead of `_retrieve_line_vals` (`_import_fill_invoice_line_values` on 16.0) returning `None` when `price_subtotal` is not present, it can keep returning `dict` with an extra key `price_subtotal`, and filter out unwanted line in `_retrieve_invoice_line_vals` itself.

opw-5977735

Forward-Port-Of: odoo/odoo#253149
Forward-Port-Of: odoo/odoo#251463

Problem
------------------------
When an employee has approved leaves, and a group leave is created that overlaps with the approved leave and overrides it, the duration of the new group leave is not computed correctly. The duration does not include the overridden days. To reproduce:
1. Create allocated leave for employee and approve and validate it.
2. Go to Management > Time Off and create a group leave for the employee that includes the approved time off dates. The dates of all leaves are updated correctly, but the duration of the group leave is incorrect.

Objective
---------------------------
Even though conflicting leaves were correctly split in the multi leave generation wizard, the resource.calendar.leaves table was not synchronized within the same transaction. Because the leave types required allocation, the duration was computed by subtracting the old time off days from the new leave's duration, since they were treated as unavailable.

Solution
--------------------------
Manually unlink the resource.calendar.leaves records associated with the conflicting leaves before calculating the new duration. The clears the employee's schedule in the database so that the dates are correctly processed as available. The calendar blocks for the remaining days of the approved time off and the new group leave are generated when the leaves are created.

Task: 5911074





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

Forward-Port-Of: odoo/odoo#253425
Forward-Port-Of: odoo/odoo#249527

*: website_blog, website_event, website_sale

The interaction for filling the dynamic content of dynamic snippets did not run inside the iframe to preview the snippet to add. This is not an issue for the initial dynamic snippet, as they are filled with fake content. But when saving a custom snippet, the dynamic content is cleared, and they seem empty when previewed. This is the case since the [website builder refactor] as the previous builder re-used the preview of the initial snippet.

This commit adds the interaction to fill dynamic content in the preview iframe, and changes the interaction to avoid emptying the fake content from initial dynamic snippets during preview.

Steps to reproduce:
- Open website builder
- Add a dynamic snippet (for example "Events")
- Save the snippet as a custom snippet
- Click on "Custom" snippet category
- Bug: The preview for the custom snippet does not have the dynamic part (there is no event, just the title)

[website builder refactor]: 9fe45e2b7ddbbfd0445ffe25a859e67a316d02b2
task-5427353

When the company currency rounds on unit and we try to apply a reward on a sale order that uses another currency and that has a total of less than 0.5, no reward is applied

Steps to reproduce:
1. Install Sales app and l10n_cl and loyalty module
2. Switch to CL Company
3. Go to Sales > Products > Discount & Loyalty
4. Create a new program and change the rule's minimum purchase to 0.00
5. Go to Sales and create a new quotation for customer Acme Corporation and add any product
6. Change the sale order line unit price to 0.4 and click on Reward
7. No discount is applied

Problem:
The company currency is used to compute the discountable amount but when this currency rounds on unit, any amount that is less than 0.5 will be considered as zero so no discount will be applied. This is because the `compute_all` method is called without specifying the currency, so we fallback on the company currency.

Solution:
Pass the order currency when computing the discountable amount

opw-5946975

Forward-Port-Of: odoo/odoo#252756
Forward-Port-Of: odoo/odoo#250153

back port of #239539

The aim of this commit is to allow accountants to be able to reconcile legacy <account.move> linked to several expenses.

Context:
With the refactoring of the expense module, we made the assumption that an expense paid by the company will generate one <account.move>. This is True within the new system but is wrong regarding legacy data and those weren't adapted through an upgrade script.

Before this commit:
Trying to reconcile an <account.move.line> that is already linked to another one from which it's <account.move> is linked to several expenses will crash while we try to get the relevant account to compute the needed_terms on the <account.move>, even if all the expenses will result in giving back the same account.

After this commit:
We check if all the expense retrieve the same account. If they do, we just retrieve it. If not, we throw a UserError instead of a weird singleton error.

opw-5930789

Forward-Port-Of: odoo/odoo#253427
Forward-Port-Of: odoo/odoo#249132

This issue occurs on Single App and Single L10n, without demo data

### Summary
This part of the test verifies that the sub line totals are calculated correctly, which from 18.3 requires the stock.group_production_lot setting to be active. Specifically, it validates that the sum accurately reflects the Unit of Measure (UOM) across various packagings.
https://github.com/odoo/enterprise/blob/93e3c6f13fbab8d54694648d04908e451f1e97fc/stock_barcode/static/tests/tours/tour_test_barcode_flows_picking.js#L6472-L6498

### Observation
The grouping logic is contingent on the stock.group_production_lot setting. If this setting is inactive, the system fails to group lines, preventing the calculation of the aggregate total.

Without the production lot group active, the conditional checks will bypass the grouping process:
https://github.com/odoo/enterprise/blob/d664e1f97f6e7fa462b4cf1806322a54762c0de4/stock_barcode/static/src/models/barcode_model.js#L53 https://github.com/odoo/enterprise/blob/d664e1f97f6e7fa462b4cf1806322a54762c0de4/stock_barcode/static/src/models/barcode_model.js#L224-L225 

When the demo data are enabled [the group is implied](https://github.com/odoo/odoo/blob/8a7ca8beac521f41faf79a6022935fdbb605de76/addons/stock/data/stock_demo.xml#L185-L187)


### Impact
When stock.group_production_lot is disabled:
 - Lines remain ungrouped.
 - The total sum of the grouped line is never generated.
 - The test fails as it cannot find or validate the expected sub-line totals.

This issue originate from the 18.3 forward port of this [commit](https://github.com/odoo/enterprise/commit/84d4b1f144e8a437fe76ec5ef3bc9799cdf993b0) 
runbot-241109

Forward-Port-Of: odoo/enterprise#108908

The interaction for filling the dynamic content of dynamic snippets
did not run inside the iframe to preview the snippet to add. This is
not an issue for the initial dynamic snippet, as they are filled with
fake content. But when saving a custom snippet, the dynamic content is
cleared, and they seem empty when previewed. This is the case since the
[website builder refactor] as the previous builder re-used the preview
of the initial snippet.

This commit adds the interaction to fill dynamic content in the preview
iframe, and changes the interaction to avoid emptying the fake content
from initial dynamic snippets during preview.

Steps to reproduce:
- Open website builder
- Add a dynamic snippet (for example "Events")
- Save the snippet as a custom snippet
- Click on "Custom" snippet category
- Bug: The preview for the custom snippet does not have the dynamic part
(there is no event, just the title)

[website builder refactor]: 9fe45e2b7ddbbfd0445ffe25a859e67a316d02b2

task-5427353