**Steps to reproduce:**
1. Install l10n_din5008 and purchase modules.
2. Switch the Document Layout template to DIN 5008.
3. Create or open an existing Purchase Order.
4. Print the Purchase Order report.

**Issue:**
The Expected Arrival Date does not appear on the DIN 5008 Purchase Order report. Both functional experts and PO (CHKL) confirmed that the Expected Arrival Date should appear by default on the Purchase Order report in DIN 5008.

**Cause:**
The date_planned (Expected Arrival) field was introduced in standard Purchase
 Order report in v18.0, but DIN 5008 report template was not updated accordingly

**Fix:**
Add the Expected Arrival information to the DIN 5008 Purchase Order template.

Before:
<img width="606" height="162" alt="image" src="https://github.com/user-attachments/assets/e11f5b1f-5898-4ec9-a4f2-087db5dfeced" />

After:
<img width="605" height="147" alt="image" src="https://github.com/user-attachments/assets/57419d00-50c9-4508-9bfc-307c0a54dc67" />


**opw-5376176**

Forward-Port-Of: odoo/odoo#239619

**Steps to reproduce:**
1. Create a product with a trailing space at the end of its name.
2. Create a quotation and confirm it.
3. Open the delivery through stat button.

**Observation:**
- The picking description displays the product name twice when the product name ends with trailing spaces.

**Cause:**
 The duplication occurs due to a combination of two issues:

1. **In sale_stock** 
https://github.com/odoo/odoo/blob/ac6d4f0211e7680b5f5b41537b1e2eb2c9efb239/addons/sale_stock/models/stock.py#L32
products without attributes, `_get_sale_order_line_multiline_description_variants()`  returns an `empty` string, yet the code still prepends a newline before the existing picking description. When the product name contains trailing spaces, this newline `+` trailing-space combination causes Odoo to interpret the description as multiple lines, resulting in the product name being duplicated on the picking.

2. **In web,**
the char field with `widget="text"` did not trim trailing spaces when saving the value.
This allowed product names such as `"Test  "` to be stored.

**Fix:**
- Trim the value entered in `char` fields using `widget="text"` when the field has `trim=True`, preventing trailing spaces from being saved and ensuring consistent description generation.

**opw-5351356**

When combining a Reverse Charge tax (e.g., Intra-Community Acquisition) with a Non-Deductible tax configuration (e.g., 60% Professional Use), the resulting accounting entry for the VAT Payable (Output Tax) was incorrect.

Steps to reproduce:
1. Create a Vendor Bill.
2. Use a Tax configured as both Reverse Charge (e.g., 21%) and partially Non-Deductible (e.g., 40% non-deductible).
3. Set the price to 100.00.

Observed behavior:
- VAT Deductible (Input): 12.60 (Correct: 60% of 21).
- Non-Deductible Expense: 8.40 (Correct: 40% of 21).
- VAT Payable (Output): 12.60 (Incorrect: it was reduced by the non-deductible part).

Expected behavior:
- VAT Payable (Output) should be 21.00. In a Reverse Charge mechanism, the full tax amount must be declared as due, regardless of the deductibility on the input side.

Solution:
Post process the taxes_data in case of professional with reverse-charge so wie will have the Payable part with the hole amount 21 in the previous example


task-5418096

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

To reproduce:
=============
- Create an accrual plan:
    - Carryover date: allocation
    - One level:
        - Accrues 2 days.
        - Accrual date: monthly on 1st of each month - Starts immediately on allocation start date - Carryover policy: all days carry over - Carried over days validity: 3 months.
- Create an allocation that uses the above accrual plan on 23/09/2025:
    - Starts on 01/07/2024

We should have 30 days in total with 24 expiring on 01/10/2025 but we only have 22 expiring on 01/10/2025.

Problem:
========
When `accrued_gain_time` of the accrual plan is 'start', in the `_process_accrual_plans` method, the property `expiring_days` is set when the first accrual still hasn't been added to the `number_of_days` (it is usually added at the [end of the loop](https://github.com/odoo/odoo/blob/18.0/addons/hr_holidays/models/hr_leave_allocation.py#L596)).

Solution:
=========
In the `_process_accrual_plans`, add the accrued days to the `number_of_days` before the `expiring_days` is set.

[opw-4963163](https://www.odoo.com/odoo/all-tasks/4963163)

Forward-Port-Of: odoo/odoo#233424

Steps to reproduce the flow:
- Create an expensable product “Hotel” that can be reinvoiced to a customer
- Create an analytic distribution model that automatically applies the analytic account “Commercial &Marketing” to the previous created product “Hotel”
- Create an SO for a customer “Gilles”. The SO is linked to the analytic account “Home Construction”
- Create an expense which category is “Hotel”. The analytic distribution is automatically set to “Commercial & Marketing”
- Reinvoice this expense to “Gilles”. The analytic distribution automatically changes to “Home Construction”. -> Wrong. We lose part of the information
- When posting the expense report, the expense is added in the SO through a dedicated SO line. The analytic account previously set as “Home Construction” is now transformed, for an unknown reason, into “Commercial & Marketing”. -> Wrong.
- On the vendor bill, the analytic distribution is “Home Construction”

Now:
1. The analytic plans from the expense and from the SO are different. Simply add the analytic account from the SO
2. The analytic plans are the same. There are conflicts. In this case, the analytic distribution set on the SO is prioritary. We ensure that costs incurred or sales generated from the expense are reflected in the SO's analytic plan rather than the generic one. In the previous example, Home Construction is the only analytic account that should be considered on the expense, bill and SO.

task-4564463

Forward-Port-Of: odoo/odoo#240762
Forward-Port-Of: odoo/odoo#233794