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