Problem:
'tracker' object in response from GET /orders/:id request can sometimes be null. This means that when the mail template 'mail_template_data_delivery_confirmation' is sent, a traceback occurs with error: TypeError: 'NoneType' object is not subscriptable. As a result the picking is not validated in odoo but a shipping has succesfully been created in the easypost backend.

Solution:
Prevent traceback form happening, picking gets correctly validated and carrier_tracking_url field is empty.

Transcript from Easypost support:
<< I'm also seeing the tracker showing as null when reviewing the response. I'll go ahead and create a ticket for the engineering team to investigate. I can see that the tracking code is being returned in the request, but the full tracking object is not. Since this appears to be happening on a case-by-case basis, you may want to allow more time between the BUY and the GET requests, as I noticed they are being triggered very close together. I'm not certain if that's related, but it may be worth trying as a troubleshooting step while we have this under review. >>

opw-5402415

Forward-Port-Of: odoo/enterprise#111833

Steps to reproduce:
1. Install modules `account_batch_payment` and `l10n_ch`.
2. Configure SEPA Credit Transfer for a CH company.
3. Create a vendor bill with a reference containing `&` (e.g. "Net & Cost"), confirm it and register a payment using SEPA Credit Transfer.
4. Create a batch payment with the SEPA payment and validate it.

Issue:
The `&` character is exported as `&amp` in the generated PAIN XML,
while according to the SIX specification it should be replaced with `+`

Cause:
The payment reference is inserted into the PAIN XML file without replacing the '&' character. During XML generation this produces an invalid entity (`&`) which results in an `XMLSyntaxError` and prevents the payment file from being processed.

Solution:
Replace the `&` character with `+` when sanitizing the payment communication so that the generated value complies with the SEPA/SIX character set and produces valid XML.

Reference[Pg: 9]: https://www.europeanpaymentscouncil.eu/sites/default/files/KB/files/EPC217-08%20Draft%20Best%20Practices%20SEPA%20Requirements%20for%20Character%20Set%20v1.1.pdf

opw-5941724

Co-authored by @bhra-odoo

Forward-Port-Of: odoo/enterprise#110809

# How to reproduce
- Install the l10n_th module
- Use the demo TH company
- Ensure you have the demo invoices and credit notes associated to that company
- Go to the Tax Report
- Select Tax Report (TH)
- Click on "Sales Tax Report (xlsx)"

# The problem
The Credit Notes' Total Amount, Total Excl and Vat Amount are positives. They should be negative instead. The same issue appear for "Purchase Tax Report (xlsx)".
This issue also concerns Credit Notes created manually in the Journal Entries

# Why
The logic for the sign of the value fields in the reports is the following :

```py
sign = move.reversed_entry_id.payment_state == 'partial' and -1 or 1
```

This is unreliable because a Credit Note will not always have a reversed_entry_id associated or if it has one, it's payment_state may change

A refactor of theses reports has been made for versions 19.0+ but it seems too big to backport (https://github.com/odoo/enterprise/pull/75645/changes)

Instead, we just check if the current move's type is a refund. If yes, we reverse the sign.

opw-6006720

Forward-Port-Of: odoo/enterprise#110816

Steps to produce:
---
- Install `Sales` module.
- Create a sale order, set a product, and assign Marc Demo as salesperson in the Other Info tab.
- Confirm the sale order and create an invoice.

Issue:
---
- In the email notification sent to the salesperson, the record reference displays as False and the amount shows as 0.00.

Root cause:
---
- Here at [1], the record name is False because the invoice is still in draft state.
- In [18], _sync_invoice sets amount_currency = line.balance for new
  lines, but balance is precomputed as 0 before the INSERT because
  _compute_balance returns 0 for invoice lines. In [17] it read
  price_subtotal directly, which is always correct.
- In 17.0 the same mail fires at the same moment, but _sync_invoice
  had already set balance = −295 and amount_currency = −295 from
  price_subtotal, so the email reads the correct 295.00.

Solution:
---
- Use record.display_name instead of record.name, as display_name is always present regardless of the record state.
- Use the tax totals amount instead of amount_total, which is not yet computed on draft invoices.

[1]https://github.com/odoo/odoo/blob/0bcc34ec2f92b9b95cde321423d810002bb317ce/addons/account/models/account_move.py#L6478
[18]https://github.com/odoo/odoo/blob/b0a50104a12b205958316d382b4c7b2176395877/addons/account/models/account_move_line.py#L1566-L1610
[17]https://github.com/odoo/odoo/blob/73c076893de79df5a86aa970fde46a7aacbeaf3d/addons/account/models/account_move_line.py#L1536-L1585


Before:
---
<img width="400" height="175" alt="image" src="https://github.com/user-attachments/assets/48c2dc03-765a-49c3-bad3-fd0b14405786" />

After:
---
<img width="400" height="175" alt="image" src="https://github.com/user-attachments/assets/53682171-155f-46b3-85dd-0c7c98482067" />


opw-6023827
---

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

Issue:
--
The query created by the function '_compute_sale_order_ids' takes
around 20-40 seconds since its doing "WHERE" searches on millions
of stock.picking records

Fix:
--
Added an index to the "lot_id" field of the stock.move.line model.
(Already existing databases can be fixed by using the webshell)

Steps to recreate the issue:
--
1. Have around a million stock.picking records
2. Go to "Inventory/Products/Lots/Serial Numbers"
3. Select any existing record or create and save a new one
4. These actions will take around 20-40 seconds to complete

Before this commit:
--
Selecting or saving any 'stock.lot' takes around 20 seconds

After this commit:
--
Selecting or saving any 'stock.lot' takes around 1-4 second

Benchmark:
--
Benchmark test was done one a database with ~4000 stock.move records and
1.74 million stock.picking records
Opw-5459842
| Before this Commit | ~20 seconds
| After this Commit | **~1-4 seconds & Memory usage just a little bit higher

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

### Steps to reproduce:
- Download 'Sales', 'Project', 'Employees', and 'Timesheets' apps
- Create an employee and link them to a user that doesn't have any access rights except to 'Timesheets = User:own timesheets'
- In Sales, create a service with the following specifications:
    - 'Create on Order' is 'Project'
    - 'Invoicing Policy' is 'Based on Timesheets'
- Create a new quotation that requests this service and click 'Confirm'
- In 'Project' > 'Configuration' > 'Projects', choose the newly created project and add a line that has the new employee in the 'Invoicing' tab
- Log in as that employee and go to 'Timesheets'
- Create a new entry for the newly created project
- Click the project's name
> Access Error: You are not allowed to access 'Collaborators in project shared' (project.collaborator) records.

### Cause of Issue:
This happens because the user doesn't have access rights to the 'Project' app, hence they don't have access to `collaborator_ids` which are retrieved here. https://github.com/odoo/odoo/blob/3dfb2849acd899ccbf4048f2a15dff3c74aed96d/addons/project/models/project_project.py#L1113-L1120

### Fix:
Since an access to the 'Projects' app isn't necessary to view a project assigned to you, `sudo()` is used here to bypass the `collaborator_ids` check.

opw-6074833