*: project_purchase, sale_project

---

Decription of the issue this commit addresses:

When confirming a sales order with a product-partner combination that has an Analytic Distribution Model assigned, any custom analytic distribution done on the line of the product will be lost, resetting the analytic distribution to the default value set on the Analytic Distribution Model.

---

Steps to reproduce:

1. Install sale_project,project_purchase.
2. Activate "Analytic Accounting" in the settings.
3. Create a new Product "test"; Type: Service, Create on Order: Project.
4. Create a new Analytic Distribution Models; Partner: Acme, Product: test, Analytic Distribution: anything but blank.
5. Create a new Quotation in the Sales apps; Partner: Acme.
6. Assign the Product test to the first order line. This will automatically set the analytic distrib of the Analytic Distribution Model.
7. In the Analytic Distribution cell, add a line with any non null distribution.
8. Confirm the Quotation.
9. The analytic distribution that was anually added has been removed. Only the default analytic distribution of the model remains.

---

Desired behavior after this commit is merged:

Any custom analytic distribution done on a line is never lost. The Analytic Distribution Model's distribution serves as a template but never overrides the values set by the user.

---

opw-4934291

---

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

Forward-Port-Of: odoo/odoo#249747

Accrual plan for leave days gets blocked, even when the remaining leave balance is below the cap. As a result, no additional leaves are accrued beyond a certain point, even though they should be.

# Steps to reproduce:
Go to time off app
* Create a new leave type.
* Create a new accrual plan with:
        - one milestone :
		- 2 days accrued per month
		- Cap: 10 days
		- start accruing 1 days after
		- No expiration
		- Carry over: All
* Create and validate a leave allocation 
       - 1 year ago
       - new leave type
       - new accrual plan
* Take the maximum number of leaves available.
* Advance the computer calendar by 1 year.
* Again, take the maximum number of leaves.
* Advance the computer calendar by another year.
* Try to take a future leave.
-> Issue: It’s not possible to take a future leave, the number of accrued days has stopped increasing. The accrual plan appears blocked.

Objective : The accrual plan should continue to allocate leave days even if leaves have been consumed regularly, as long as the remaining leaves are under the cap.

## Issue
Before going further: the property `leaves_taken` of the `hr.leave.allocation` is supposed to contain the number of leaves this allocation cover until "today".

In the `_test_get_allocation_future_leaves1` added test, in the last line of the test :
`assert_virtual_leaves_equal(self, leave_type_day, 2, self.employee_emp, date='2023-02-01')`

When calling `get_allocation_data` with a `target_date` set in the future, the result is wrong. Here is how it works :
`get_allocation_data`
...
.....`_get_consumed_leaves` (1)
...........`_get_future_leaves_on` (2)
...............`_process_accrual_plans` (3)
....................`_compute_leaves` (4)
.........................`_get_consumed_leaves` (5)
..............................`get_future_leaves_on` (6)
...................................`process_accrual_plans` (7)

**A)** The method **(2)** try to calculate the added number of days each allocation will have on `target_date`. So it creates a copy of the allocation in memory using the 'new' method:
`fake_allocation = self.env['hr.leave.allocation'].with_context(default_date_from=accrual_date).new(origin=self)`
It will then update it to `target_date` using `_process_accrual_plans` and will return the difference of days between the
updated `fake_allocation` and the current allocation (`self`)

**B)** Before iterating over each accrual date, the `_process_accrual_plans` **(3)** will get the `leaves_taken` property which is a computed field. It will trigger `_compute_leaves`.

**C)** The method **(4)** will call `_get_consumed_leaves`, and so the nightmare begins.

**D)** The method **(6)** will create a second `fake_allocation` based on the origin of the first `fake_allocation` (see **A)**).

**E)** This time, `_process_accrual_plans` **(7)** will also look at the `leaves_taken`, but won't trigger the `_compute_leaves` probably because the current allocation is a `fake_allocation` of a `fake_allocation`, and one property of the `new` method is that `Two new records with the same origin record are considered equal.`. Therefore, the `leaves_taken` is considered to be already computed (but it's not).

So `_process_accrual_plans` read the `leaves_taken` which is 0 (probably the default value of `leaves_taken`), but it should be 20 !

**F)** As the value of `leaves_taken` is wrong, the fake_allocation n°2 is also wrong, and its `number_of_day` is 10 but the `number_of_days` of the origin allocation is 20. So `get_future_leaves_on` **(6)** will return -10 which makes no sense, and all the previous calls computations will be wrong. And the final `virtual_remaining_leaves` value will be 0 instead of 2.

## Source of the issue
In the `_process_accrual_plans` method, for each allocation, `leaves_taken` is only computed once at the start of the loop over the allocation "important" dates (see `nextcall` property of `hr.leave.allocation`). At this moment, the method calculates the `leaves_taken` the allocation will have on the `accrual_date` parameter. Yet, this property can change depending on the date the allocation is on (`nextcall` property) which leads to some issues in the computation of the `allocation.number_of_days`.

## Solution
For each allocation, compute the `leaves_taken` at every iteration trough the values of `nextcall`. BUT, this can trigger an infinite loop as computing `leaves_taken` calls `_get_consumed_leaves` which calls `_get_future_leaves_on`, which calls `_process_accrual_plans` ... To avoid this, this PR add the context variable `precomputed_allocations` (will be converted into a function parameter in master) which will prevent `_get_consumed_leaves` from calling `_get_future_leaves_on` for the allocations already up to date (contained by this very `precomputed_allocations` context variable).

opw-4934391
opw-5226806

Forward-Port-Of: odoo/odoo#239836

Forward-Port-Of: odoo/odoo#249441
Forward-Port-Of: odoo/odoo#243812

**Problem:**
When using themes that define border-radius as unitless `0` (e.g., Anelusia theme) and attempting to modify the "Rounded Corners" value of any element through the website editor, the following error occurs: "Cannot convert 'px' units into '' units !"

**Steps to reproduce:**
1. Install and activate the Anelusia theme (or any theme with unitless border-radius: 0)
2. Open the website editor
3. Select any element (e.g., a table in the footer)
4. Try to change the "Rounded Corners" field to any non-zero value
5. Observe the error: "Uncaught Promise > Cannot convert 'px' units into '' units !"

**Current behavior:**
The website editor throws a JavaScript error and prevents changing rounded corners.

**Expected behavior:**
Users should be able to modify rounded corners values without errors, regardless of whether the theme uses unitless or unit-based zero values.

**Cause of the issue:**
Some themes define border-radius variables as unitless `0` (e.g., `$border-radius: 0`). When the website editor's areCssValuesEqual() function in utils_css.js compares the new value (e.g., "10px") with the existing computed value ("0" - unitless), it attempts to convert between units. The getNumericAndUnit() function extracts the unit from "0" as an empty string "", then convertValueToUnit() tries to convert "10px" to "" unit. Since there's no conversion defined for "px" to "" (empty unit), convertNumericToUnit() throws the error.

**Fix:**
Add a special case in areCssValuesEqual() to handle unitless zero values before attempting unit conversion. When the first value is unitless "0", we compare the numeric values directly using Number.EPSILON, avoiding the unit conversion entirely. This allows proper comparison between unitless "0" and values like "10px" or "0px" without errors, while maintaining correct equality checks (0 equals 0px, but 0 does not equal 10px).

opw-5412414

**Steps to reproduce:**
* Install the **product_unspsc** module.
* Create a product with a **UNSPSC category**.
* Create and post an invoice for this product.
* Send the invoice via **Peppol**.

**Observed behavior:**
* Peppol validation fails with error **[BR-CL-13]**: *“Item classification identifier identification scheme identifier MUST be coded using one of the UNTDID 7143 list.”*
* The XML uses `listID='UNSPSC'` in `cbc:ItemClassificationCode`.

**Cause:**
* The `listID` attribute was set to the literal string **'UNSPSC'**.
* According to the **UNCL7143** code list, the correct scheme identifier for UNSPSC is **'TST'**, not 'UNSPSC'.

**Fix:**
* Replace `listID='UNSPSC'` with `listID='TST'` when generating the commodity classification node.
* Update and extend tests to validate the correct scheme identifier.
* Same for CPV code from the documentation i's code is also changed to 'STI'.

ref: https://docs.peppol.eu/poacc/billing/3.0/codelist/UNCL7143/

opw-5948723

Forward-Port-Of: odoo/odoo#249788

This commit https://github.com/odoo/enterprise/commit/e8d2084369d58717c2294e023cbdfd60f713c334 removed the `pdf_options_header` wrapper.

18.3-:
https://github.com/odoo/enterprise/blob/ce67bf6fb4f694c25785580fe3ed290bcb8c92b5/account_reports/data/pdf_export_templates.xml#L151-L154

18.4+:
https://github.com/odoo/enterprise/blob/e3746aba3c334a628a15a4263ddfa08876d2a288/account_reports/data/pdf_export_templates.xml#L159-L160

This broke `l10n_be_reports` which uses `(//div[hasclass('row')])[last()]` to inject BE-specific fields:

https://github.com/odoo/enterprise/blob/e3746aba3c334a628a15a4263ddfa08876d2a288/l10n_be_reports/data/tax_report.xml#L9-L24

Without the wrapper, `[last()]` targets the conditional `aml_ir_filters` row instead, making BE fields invisible.

Steps to reproduce:
1. Create a Belgian company
2. Navigate to Accounting → Reporting → Tax Return
3. Create a VAT Return and submit it
4. Check the generated PDF in the attachment

=> The "Ask Restitution" and "Client Nihil" fields are missing from the PDF header.

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

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

**Steps to reproduce:**
- Install l10n_ro_saft
- Switch to a Romanian company (e.g. RO Company)

- Create an asset model:
  * Method: Straight Line
  * Duration: 12 Months
- Configure a "Fixed Assets" account:
  * Automate Asset: Create and validate
  * Asset Model: [the asset model created above]
- Create a bill:
  * Vendor: [create a new vendor]
  * Bill Date: [last month]
  * Invoice Line: [A line with the fixed asset account]
- Confirm the bill

- Go to "Accounting / Reporting / Audit Reports / General Ledger"
- Select the current month (The fixed asset account should be present)
- In the cog menu, select "SAF-T (D406 Asset Declaration)"

**Issue:**
A traceback is raised while trying to display the name of a supplier.

**Cause:**
To display the supplier name of an asset, a dict having the id of the customer or supplier as key (i.e. partner_detail_map) is used. This dict is build by getting the list of all partners linked to a posted journal item on an asset (or liability) account in the period of the report.
In this case, it's the current month.
However, the created bill has been posted the month before.
So no journal item is found for the vendor that has been created just for the bill and therefore there is no key for him in the dict, which leads to the error when trying to get the id of the supplier of the asset in the dict.

**Solution:**
Instead of just fetching the posted entries linked to a receivable or payable account in order to get the list of the potential customers and suppliers, we also fetch the depreciation lines that are linked to an asset account and can still be in draft.


opw-5499918

Forward-Port-Of: odoo/enterprise#105987

Steps to Reproduce: https://www.awesomescreenshot.com/video/49329263?key=2daddfb65e4ee8dcf1a047c09c6bd2b5
- Install l10n_uk_reports module
- Keep the VAT value empty for the UK Company
- On the Tax Report (GB), click Connect to HMRC
- Establish connection with HMRC
- After a successful connection, try to send the tax report to HMRC
- Traceback will appear

<details><summary>Exact Traceback</summary>
<p>

```
RPC_ERROR

Odoo Server Error

Occured on 100710704-master-all.runbot216.odoo.com on model account.report on 2026-02-11 12:50:03 GMT

Traceback (most recent call last):
  File "/data/build/odoo/odoo/http/requestlib.py", line 632, in _serve_db
    return retrying(serve_func, env=self.env)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/build/odoo/odoo/http/retrying.py", line 52, in retrying
    result = func()
             ^^^^^^
  File "/data/build/odoo/odoo/http/requestlib.py", line 687, in _serve_ir_http
    response = self.dispatcher.dispatch(rule.endpoint, args)
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/build/odoo/odoo/http/dispatcher.py", line 308, in dispatch
    result = self.request.registry['ir.http']._dispatch(endpoint)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/build/odoo/odoo/addons/base/models/ir_http.py", line 374, in _dispatch
    result = endpoint(**request.params)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/build/odoo/odoo/http/routing_map.py", line 207, in route_wrapper
    result = endpoint(self, *args, **params_ok)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/build/odoo/addons/web/controllers/dataset.py", line 32, in call_kw
    return call_kw(request.env[model], method, args, kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/build/odoo/odoo/service/model.py", line 57, in call_kw
    result = method(recs, *args, **kwargs)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/build/enterprise/account_reports/models/account_report.py", line 2825, in dispatch_report_action
    return report_to_call.dispatch_report_action(options, action, action_param=action_param, on_sections_source=False)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/build/enterprise/account_reports/models/account_report.py", line 2836, in dispatch_report_action
    return report_method(model, *args)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/build/enterprise/l10n_uk_reports/models/account_financial_report.py", line 30, in send_hmrc
    self.env['l10n_uk.vat.obligation'].import_vat_obligations(self.env.context['client_data'])
  File "/data/build/enterprise/l10n_uk_reports/models/hmrc_vat_obligation.py", line 124, in import_vat_obligations
    self._get_vat(),
    ^^^^^^^^^^^^^^^
  File "/data/build/enterprise/l10n_uk_reports/models/hmrc_vat_obligation.py", line 111, in _get_vat
    if vat.startswith(('GB', 'XI')):
       ^^^^^^^^^^^^^^
AttributeError: 'bool' object has no attribute 'startswith'

The above server error caused the following client error:
RPC_ERROR: Odoo Server Error
    RPC_ERROR
        at makeErrorFromResponse (https://100710704-master-all.runbot216.odoo.com/web/assets/0a37914/web.assets_web.min.js:3225:165)
        at XMLHttpRequest.<anonymous> (https://100710704-master-all.runbot216.odoo.com/web/assets/0a37914/web.assets_web.min.js:3231:13)
```

</p>
</details> 

Reason:
- No VAT set on the current company.

Solution:
- Blocking level error for the user to set VAT on the current company.

Task-5929908

Forward-Port-Of: odoo/enterprise#107150

#### Issues:
VAT Book should download for all selected companies with same CUIT as the current one.

#### Step to reproduce:
- In a company in Argentina ("Parent Company")
- Create a branch "Child Company A" with no CUID
- Create a branch "Child Company B" with a different CUID than parent
- Go to "Child Company A"
- Either:
  - i.  Select both "Parent Company" and "Child Company A" but not "Child Company B"
  - ii. Select all 3 "Parent Company", "Child Company A" and "Child Company B"
- In Accounting > Report > Tax Return :
- Download the VAT Book (wheel > "VAT book(ZIP)")

#### Current behavior:
i.  Get Invalid Operation
ii. Download the VAT Book for "Parent Company" only

#### Expected behavior:
- Download the VAT Book for both "Parent Company" and "Child Company A"

A previous call to get_options provide the client with the info about which selected companies have the same CUIT as the current company. Therefore companies in the options are the correct ones.

opw-5385585

Forward-Port-Of: odoo/enterprise#101898