**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 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#240267
Forward-Port-Of: odoo/odoo#233794

When exporting invoices, the VAT number of the company could be wrong if the fiscal position of the invoice defines a foreign VAT number. In that case we need to use it.

Steps to reproduce:
1. Install a European localization (ex: l10n_at)
2. Enable EU Intra-community Distance Selling. You should now have new OSS fiscal positions. Update the one you want to use with a foreign VAT.
3. Create a valid foreign customer. (within the EU)
4. Create and send an invoice for this customer.
5. In the PDF, there is an embedded factur-x file. Notice how the VAT number under the SellerTradeParty corresponds to the company's VAT, not the foreign VAT number defined on the fiscal position.

This is more apparent because we use the correct VAT number in the PDF file but not in the corresponding XML.

This commit fixes this issue by first checking if we have a foreign VAT number defined on the fiscal position of the invoice. If so, we use it.

opw-5182837

Forward-Port-Of: odoo/odoo#237580
Forward-Port-Of: odoo/odoo#236692

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

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