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#241436
Forward-Port-Of: odoo/odoo#236692

When creating a delivery slip, if the product sold is a kit and it's component doesn't have a description, the name will be repeated.

Steps to reproduce:
-------------------
* Create a product A with a bom of type kit
* Add a product "comp" in the bom (don't give it a description)
* Create a sales order with the product A and confirm it
* Go on the delivery and create a delivery slip
-> Issue, the name of the product "comp" appears twice.

Observation:
-------------
The name is added in description_picking field, since it is considered that the fallback for the description for outgoing deliveries should be display_name:
https://github.com/odoo/odoo/blob/584f94e3246b6b59641bf83d4e707f2e872bc1e8/addons/stock/models/product.py#L293-L301

In _compute_description_picking, information about the bom will be added :
https://github.com/odoo/odoo/blob/08c5fbbb5bc44c4810cd07188b29090c3060e14f/addons/mrp/models/stock_move.py#L235-L236

This causes the issue because the filter to prevent repeating the name on the delivery slip is implemented directly in the XML:
https://github.com/odoo/odoo/blob/08c5fbbb5bc44c4810cd07188b29090c3060e14f/addons/stock/report/report_deliveryslip.xml#L83-L85
However, since we have added elements to the description (the bom information), this filter will not be applied, leading to the repeated name.

opw-5265906

Forward-Port-Of: odoo/odoo#236948

Currently, an error occurs when a user attempts to pay an invoice.

**Steps to Reproduce ([Video](https://drive.google.com/file/d/1onmo1mxeZgH6fkQOoueGCgC67HPjYHX6/view)):**

 - Install the `Accounting` module.
 - Go to `Payment Terms` and create `a new Payment Term` with at `least two Due Term lines`.
 - Go to `Invoices` and `create a new Invoice`.
 - Add one invoice line and set the `Payment Term` to the `newly created payment term`.
 - In the `Journal Items` tab > `Enable the Due Date` column (optional hidden).
 - From the two `Receivable journal items`, remove the `Due Date` from one of the `receivable lines`.
 - Now `Confirm the invoice` and `Click on Pay`.

**Error:**
`TypeError: '<' not supported between instances of 'datetime.date' and 'bool'`

**Cause:**
This error occurs when the user clicks Pay, than it going to calculate the total amount to pay from here [1]. If the payment term has more than one term line, it creates more than one receivable invoice line, and the receivable invoice lines are sorted from here [2]. When two or more invoice lines have the same move_id, they are sorted based on the due date. However, if one of the receivable lines does not have a due date, the error is raised.
Similarly, as shown in [3], when the system retrieves the installment data, it sorts the lines based on the due date and raises the same error.

**Fix:**
This commit ensures that when there is no due date on any receivable invoice line and two lines belong to the same invoice, the comparison uses the maximum date as like here [4] and places that line at the end for that invoice, thereby maintaining the correct flow. The same fix is applied while retrieving the installment data, as described above.

[1]: https://github.com/odoo/odoo/blob/92a9f6b19670685dfe9fb1714bf01449768e5f62/addons/account/wizard/account_payment_register.py#L703

[2]- https://github.com/odoo/odoo/blob/92a9f6b19670685dfe9fb1714bf01449768e5f62/addons/account/wizard/account_payment_register.py#L635

[3]: https://github.com/odoo/odoo/blob/92a9f6b19670685dfe9fb1714bf01449768e5f62/addons/account/models/account_move_line.py#L3305

[4]: https://github.com/odoo/odoo/blob/92a9f6b19670685dfe9fb1714bf01449768e5f62/addons/account/models/account_move_line.py#L522

sentry-713241246

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

Forward-Port-Of: odoo/odoo#241744
Forward-Port-Of: odoo/odoo#241060

**Description of the issue this PR addresses:**
Clicking on join call does not open the corresponding thread, 
neither in the discuss app nor in the chat window.

**Steps to Reproduce:**
- Log in with Admin and Demo user
- From the Demo side, open the chat window/discuss app and call Mitchell Admin
- On the Admin Side, click Join the call from the call invitation preview
- Chatwindow/Discuss app does not open the corresponding thread automatically

Additionally, clicking on the `invitation avatar` does not focuses the composer as 
expected in the chat window.

**Desired behavior after PR is merged:**
- Clicking join call now opens the corresponding thread in both discuss and 
chat window, with the composer focused in the `chat window`.
- Clicking the avatar on a call invitation now focuses the composer when opened 
inside a chat window.

task-[5367781](https://www.odoo.com/odoo/project/1519/tasks/5367781)

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