**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. Upload more than 40+ files in a folder. (One page displays upto 40 docs)
2. Use the checkbox to select all files on the page (this selects only 40 files)
3. Click the 'Select All' button in the control panel to select all 40+ files.
4. Now, try duplicating or moving them to the trash.
=> Only the first 40 selected files (on the single page) are considered for
   action, not all the selected files.

Technical
==========
For documents control panel action we have custom handling for selecting records
and executing action. We use `model.root.selection` which only consider records
in current page, case of select all records from other pages is missed here.

After this PR
==================
- All selected records are considered for the actions
- Added custom `getResIds` method to get filtered `resIds` as per domain.

Note: `getResIds` in DynamicList doesn't have custom domain feature so create
our own as per use case

Task-4700841

Forward-Port-Of: odoo/enterprise#101996
Forward-Port-Of: odoo/enterprise#87634

Issue 1:
Steps to reproduce
===============
1. Go to the survey.
2. Create a live session for any survey.
3. On the session screen, click the copy button after the url. ------> Popover will show `Copied!` but nothing is copied.

Issue 2:
Steps to reproduce
================
1, 2: same as issue 1.
3. Click the copy button 2,3 times.
4. Click the button start survey. ------> TypeError: Cannot read properties of null (reading 'closest')

Technical
========
Issue 1: The event listener callback `onCopySessionLink` was using `event.target.textContent` to insert into clipboard of the browser. As the event.target is icon with no text content, the empty string is _copied_.

Issue 2: At each click of the copy button, we register cleanup to dispose the _same_ instance of `window.Popover` component. Therefore more than one click will register the cleanup each time. While cleaning, the second cleanup will actually dispose the already disposed instance raising an error at this [line] because the instance has `this._element` null.

This commit makes the `onCopySessionLink` to copy the text of the element with the url and makes sure the cleanup is registered only once.

[line]: https://github.com/odoo/odoo/blob/058212e12b5079eba870bde9775fe98f27928935/addons/web/static/lib/bootstrap/js/dist/tooltip.js#L173

Task-5347197r

Forward-Port-Of: odoo/odoo#239621

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

Steps to reproduce:
- Open the VoIP softphone on a mobile device
- Enter a number
- Place the cursor in the middle of the number
- Tap on the *odoo* backspace button
=> The character before the cursor is removed but then the cursor jumps
   to the end of the input.

Note: this also happens when trying to add a number in the middle of
the typed number, using the softphone buttons, but this message focuses
the explanation on the backspace button.

Commit [1] introduced the bug while revamping VoIP and its keypad.
Before that commit, there was a simple `t-on-click` defined on that
backspace button. After the update, that `t-on-click` is still there but
alongside a weird `t-on-touchend.prevent="(ev) => ev.target.click()"`,
which is actually there to prevent zoom-in behavior on double-tap,
although, retesting it does not seem necessary (at least on Android).
In any case, this is the original cause of the bug.
Since [2], the keypad input is using the mail's `useSelection` hook,
which, among other things, manages what happens on click outside of the
input. Before [1], this happened when clicking on the backspace button:

1. The click is handled during its *capture* phase by the `useSelection`
   hook. It checks if clicked location should be considered, the answer
   is yes.

2. The next part of the handler is done in the next microtask (as the
   check is done asynchronously (?? that looks like a bad idea, but
   that's another issue)).

3. That "in the next microtask" part occurs before the event starts
   bubbling: the capture handler saves the cursor position as being at
   the end of the input (?? not sure why, but that's another issue).

4. The click is handled during its *bubbling* phase by the backspace
   button's `t-on-click`, which removes the character before the cursor,
   and sets the cursor position accordingly for the `useSelection` hook.
   The actual cursor position is untouched since [3] on mobile "because
   otherwise it would open the mobile keyboard", but there are other
   ways that would have prevented that I think... to confirm later for
   master via task-5366961 (this actually causes issues in HOOT tests
   but that's another issue).

5. The dialer/numpad component handles the input's focus/cursor. For
   that, it forces a focus and ask the `useSelection` hook to "restore
   the selection", which "restores" it to what step (4) asked.

After [1], this changed to:

1'. Same as step (1)

2'. Same as step (2)

3'. As the click was simulated instead of being the "natural" one
    triggered by the browser touchend handling, the `t-on-click` handler
    is called now, before the "in the next microtask" part of the
    capture handler is done. That means what step (4) did happens now.

4'. Now what step (3) did happens now.

5'. Same as step (5)... but since step (3) and (4) were basically
    swapped, the cursor is now restored as the way it was last saved:
    at the end of the input (again don't know why step the
    `useSelection` hook would want to save it like that though).

There are multiple solutions to fix this:
A. Remove the `t-on-touchend` handler, letting the browser do what it
   naturally does. Although, it might be needed to prevent the mentioned
   zoom behaviors on some phones?
B. Review why the `useSelection` hook wants to save the cursor at the
   end of the input on external click, the point is valid but I am not
   sure that should be this hook's job to enforce it.
C. Review why the `useSelection` hook wants to check if the click has to
   be considered asynchronously, there should be a better way.
D. Configure the `useSelection` hook to consider a click on the
   backspace button as to be ignored, as handled manually by its own
   handlers anyway.

Option (A) should probably be done, by confirming zoom behaviors can be
prevented another way, but it cannot be done in stable anyway. The (B)
and (C) options should be investigated but would also not be stable to
change; also that would modify an exposed hook's behavior so more risky.
Option (D) can probably be done either way and is targeted on fixing the
bug described only, so this is the solution this commit went for.
In master, option (A) will be investigated in the forward-ported version
of this fix.

However... the bug was actually solved 3 months after [1], at [4] thanks
to secret option (E): not removing the `t-on-touchend` but changing it
entirely to call the same handler as the `t-on-click` one. A bit more
stable than option (A) but still not stable.
However... that solution (E) was broken 1 month later, again, by commit
[5] which destroyed step (5) while fixing an unrelated bug. Without that
step, the input cursor is not repositioned after OWL changes the value,
and by default OWL places it back at the end.

The solution is to restore step (5): the problem was that we were
checking if the user was not typing in another input before re-focusing
the keypad input... but the code considered the keypad input itself as
"another input". This commit still adds solution (D) on top of fixing
that, for good measures.

Note that in 19.0+, there is at least another cursor-related bugs,
related to commit [6]. It will be fixed in the forward-port of this one
as they need each other's fix to both work. Really there should be
better ways to handle that cursor position in OWL... might be done in a
future refactoring.

This commit adds a test to hopefully keep the bug fixed, as inspired by
commit [7].

[1]: https://github.com/odoo/enterprise/commit/52b3065993c41c6b7c65dda586a66fdd865b3afd
[2]: https://github.com/odoo/enterprise/commit/2e8f18801156a8069e26fb3d61d4f8d84893e891
[3]: https://github.com/odoo/odoo/commit/adc5448adf863b99b9b2be29985e560f5c12dbd4
[4]: https://github.com/odoo/enterprise/commit/668467678312632b5b9ecf234280690151bf3078
[5]: https://github.com/odoo/enterprise/commit/db82135fd73d5077fc26be7206105192a845c2bc
[6]: https://github.com/odoo/enterprise/commit/a06c02e8e163ed052c1c4d25a56bea9b6409abde
[7]: https://github.com/odoo/enterprise/commit/613ef7332b0d21e947871e9d33b68d069f1412c2

Related to task-5366961

Forward-Port-Of: odoo/enterprise#102728
Forward-Port-Of: odoo/enterprise#101856

**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

**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

Issue:
When entering a negative wage value and then modifying it before saving, the 
employer cost was not being recalculated. Additionally, when wage = 0 and the 
user changes it to a negative value, a validation error is correctly raised. 
However, when wage > 0 and the user edits it to a negative value, the system 
does not trigger the validation error.

Cause:
A negative wage makes the wage_on_payslip compute method return 0, because
_get_wage_from_yearly_costs applies max(0, value). Once wage and
wage_on_payslip differ, the inherited logic switches the input to
display_wage_on_payslip instead of the actual wage field.

Any further edits are therefore applied only to display_wage_on_payslip while
wage remains unchanged. Since the employer cost compute method depends on wage,
it is never triggered, leaving the employer cost incorrect.

Because wage_on_payslip becomes 0 while wage is negative, the condition:

    if abs(version.wage - wage) > 0.10:

evaluates to True, and the inverse method assigns:

    version.wage = wage

At this point, wage becomes 0. Since the ORM constraint checks `(wage >= 0)`,
the value is considered valid, so no validation error is raised.

Solution:
Remove the max() call in _get_wage_from_yearly_costs so that negative values
are kept instead of being coerced to zero. Replace:

    return max(0, remaining_for_gross / salary_costs_factor)

with:

    return remaining_for_gross / salary_costs_factor

This prevents wage_on_payslip from being forced to 0, avoids the UI from
switching to display_wage_on_payslip, allows the employer cost to recompute
correctly, and ensures that when wage and wage_on_payslip do not differ,
the condition `if abs(version.wage - wage) > 0.10` does not execute
`version.wage = wage`, allowing ORM constraints to be properly enforced.

task-5383750

**Steps to produce:**
- Install `website_sale` with demo data.
- Go to the shop page.
- Select product `Customizable Desk` > click `Add to cart`.
- In the wizard, change the quantity to 100 and directly click `Checkout`.

**Issue:**
- The cart shows the product with quantity = 1 instead of the edited value.

**Root Cause:**
- The template uses `t-on-change`, which only triggers when the input
  loses focus or is explicitly modified.
- When the user clicks `Checkout`, both `setQuantity` and `onConfirm`
  are executed in parallel.
- If `onConfirm` runs first, it reads the previously stored quantity
  (`1` from `this.state.products` initialized in `onWillStart`) before
  `setQuantity` has updated the value.
- Consequently, the checkout process proceeds with the stale quantity
  instead of the newly entered one.

**Solution:**
- Replace `t-on-change` with `t-on-input` so that the quantity is updated immediately when the user edits the field.
- This ensures the correct quantity is reflected in the cart even if the user proceeds directly to checkout.

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

Steps to reproduce:
===================
-  Add a product categories block with a search bar in the inner content of the block, like "s_product_list".
- Drag a "Search" snippet inside of the block in top of products categories
- Change the layout to "Grid" & Save.
- Type in the search bar to trigger autocomplete suggestions. -> The suggestions appear behind the product categories and are not visible.

Cause:
======
When a searchbar snippet is placed inside a section using grid mode, the autocomplete dropdown was hidden behind sibling grid items. This occurred because the grid layout applies inline z-index to each column (via `_placeColumns` `in grid_layout_utils.js` (See [1])), creating stacking contexts that trapped the dropdown.
So once you change to grid mode layout `_toggleGridMode` function will be triggered which will call  `_placeColumns` that will assign z-index; (See [2])

Solution:
=========
Override the inline z-index on grid items containing a searchbar

[1]: https://github.com/odoo/odoo/blob/d4411c27b469e5dcc526b5b1f8ea4498f2b08567/addons/web_editor/static/src/js/common/grid_layout_utils.js#L225

[2]: https://github.com/odoo/odoo/blob/d4411c27b469e5dcc526b5b1f8ea4498f2b08567/addons/web_editor/static/src/js/common/grid_layout_utils.js#L138

opw-5392011

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

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 (e.g. 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.

This is a backport of odoo/odoo#236692. Since this is a general fix, it is needed by customers using 17.0 and therefore necessary to add.

opw-5401880
opw-5182837

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/df7c781aa3 [REL] 17.0.82 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/45a24fdf1e [FIX] grid: close popovers on external clicks [Task: 5418367](https://www.odoo.com/odoo/2328/tasks/5418367)
https://github.com/odoo/o-spreadsheet/commit/05e6ca5026 [FIX] data validation: fix date criterion [Task: 5343580](https://www.odoo.com/odoo/2328/tasks/5343580)

Co-authored-by: Florian Damhaut (flda) <flda@odoo.com>
Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com>
Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com>
Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com>
Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com>
Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com>
Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com>
Co-authored-by: Rémi Rahir (rar) <rar@odoo.com>
Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com>
Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>