When sending an invoice by email template, dynamic report attachments do not use their configured Printed Report Name. Instead, they fall back to a default naming pattern (e.g. report name + invoice number).

This is due to a difference in flow: sales use the standard mail.compose.message wizard, which correctly applies each report’s print_report_name, while invoices use the dedicated account.move.send flow. In this flow, dynamic report filenames are not computed from the report itself.

To fix this, the send flow is updated so _get_placeholder_mail_template_dynamic_attachments_data computes the filename from each dynamic report. When a print_report_name is defined, it is used. Otherwise, the previous fallback behavior is preserved.

The fix will ensure extra dynamic reports follow their configured printed name.

Steps to reproduce:
1. Go to Settings > Technical > Reporting > Reports and duplicate the standard Invoice report.
2. In the duplicated report, set a custom value in Printed Report Name (e.g. 'CUSTOM_NAME_TEST').
3. Go to Settings > Technical > Email > Templates and open “Invoice: Sending”.
4. Add the duplicated report under Dynamic Reports.
5. Create a customer invoice and confirm it.
3. Click Send (or Send & Print) to open the email preview.

Related Ticket:
opw-6058716

Forward-Port-Of: odoo/odoo#259597
Forward-Port-Of: odoo/odoo#259267

Currently, when a subscription payment is processed through a provider
configured to use as outstanding account the bank default account,
the resulting invoice may remain in an 'open' state even though
the payment transaction is 'done'.
This type of configuration is usually done when users want to skip
the bank reconciliation process, and just create payments without
the need to reconcile the payments with transactions.

Steps to reproduce:
- In Settings, under Sales > Invoicing, disable Automatic Invoice
- Activate demo payment method
- In the main Bank account add the default account as outstanding
  account for demo payment method.
- Create a sales order with a subscription product
- Open Preview
- Pay
- Go back to the sales order and open the created invoice

Issue:
The invoice is created and the payment is registered, but
the invoice remains 'Not Paid'.

Analysis:
The invoice and the payment move lines are not automatically reconciled
during the post-processing of the transaction, leaving the invoice
unbalanced.

opw-5869303

**Steps to reproduce:**
* Install the **l10n_in** module.
* Create a **branch company** under an Indian company.
* Switch to the branch company only.
* Create a user with **Accounting Administrator** access (and bank validation rights) and also give permission of this branch company.
* Login from this user .
* Create and confirm a vendor bill in the branch company.
* Click **TDS Entry** and select any TDS section.

**Observed behavior:**
* An **AccessError** is raised when selecting the TDS section.

**Cause:**
* In `_compute_amount` (wizard), currency is taken from `tax_id.company_id`.
* For branch setups, taxes (and related accounts) belong to the **parent company**, so `tax_id.company_id` points to the parent.
* The user operating in the branch company does not have access to the parent company, triggering an access error.

**Fix:**
* Use the wizard’s `company_id` instead of `tax_id.company_id` when determining currency.
* The wizard `company_id` is correctly computed based on the active company, ensuring proper access rights.

**Note:**
* Regression test is not feasible due to ORM cache behavior:
  * In tests, `mock` environments share a transaction-level cache.
  * `compute_sudo=True` fields populate cache with superuser access.
  * By the time `_compute_amount` runs, values are already cached.
  * No database fetch occurs, so record rules are not evaluated and the AccessError cannot be reproduced.

opw-6095312

Forward-Port-Of: odoo/odoo#259091

Currently an error is generated when the user tries to save an
appointment as follows:
- Install the appointment_google_calendar module without demo data
- Create a new appointment as below:
      - Remove Organizer (user_id)
      - Set the Google Meet link inside VideocallURL, e.g., https://meet.google.com/aaa-aaa-aaa
- An error occurs in the log and a message is shown to the user when save the record
- Also, an error occurs when trying to preview `Appointment: Attendee Invitation`
  after creating appointment as follows:
      - Set the Google Meet link inside Videocall URL > save
      - Remove Organizer (user_id)

Error: 
```
test odoo.addons.mail.models.mail_render_mixin: Failed to render QWeb template for Mail Template: 'Appointment: Appointment Booked' (ID: 12) - Context language:en_US
Target Model: calendar.event
Error: Error while render the template
ValueError: Expected singleton: res.users()
```


This is because the method `is_google_calendar_synced` expected a single
record, but since we removed `user_id` from the event (appointment),
it will generate a singleton error.

This commit will fix the above issue by not calling `is_google_calendar_synced`
when the event does not have `user_id`.

sentry-7393595716

Forward-Port-Of: odoo/enterprise#113966

### **Description of the issue/feature this PR addresses:**

**Issue:** In Odoo 18/19, purchase move lines default to the WH's main stock location (`lot_stock_id`) as the `location_final_id`. However, when a user configures a sub-location on the Receipt Operation Type, the picking destination is correct, but the move lines are defaulted to the main warehouse. This mismatch causes the Forecasted Quantity to not increment for the intended sub-location

**Solution:** Prioritize the `default_location_dest_id` before falling back to the default stock location

opw-6032018

### **Current behavior before PR:** 
When confirming a PO, the `location_final_id` on stock moves defaults to the `lot_stock_id`, regardless of the specific destination set on the Operation Type. This causes a mismatch in 1-step receiving flows where a sub-location (e.g., WH/Stock/Test) is intended, since the move lines revert to the root warehouse location (WH/Stock). Thus, the forecasted quantity for the specific sub-location doesn't increment as expected.

### **Desired behavior after PR is merged:** 
The `_get_final_location_record` method will now evaluate if the Operation Type's `default_location_dest_id` is a child of the warehouse's main stock. If it is, the sub-location is used as the `location_final_id` for the moves and move lines. This ensures that the forecasted quantity reflects the intended destination upon PO confirmation while still maintaining the fallback to the warehouse root for standard multi-step routes.




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

Forward-Port-Of: odoo/odoo#256725
Forward-Port-Of: odoo/odoo#254527

Steps to reproduce:
Bug 1 (The Crash):
1. Open Documents app, select a PDF, and click Action > Sign.
2. In the Sign app, delete the newly created Sign Template.
3. Return to the Documents app.
4. A traceback occurs (`KeyError: <document_id>`) in `web_read`.

Bug 2 (The Broken Lineage):
1. Create two separate Sign Templates from the exact same Document.
2. Send a signature request from the second template.
3. The `reference_doc` on the signature request fails to link back to the original Document.

Current behavior:
When creating a sign template from a document, `documents_sign` intentionally unlinks the original `ir.attachment` (`res_model = False`) to pass custody to `sign.document`. If the template is deleted, the attachment is orphaned, permanently corrupting the original `documents.document` and crashing the UI. 
Furthermore, the lineage tracking (`reference_doc`) relies strictly on a 1:1 shared `attachment_id`. If a user creates multiple templates from one document, the system is forced to make a copy for the second template, natively breaking the lineage tracking because the IDs no longer match.

Expected behavior:
Documents should not be corrupted when generating or deleting sign templates. Furthermore, lineage tracking (`reference_doc`) should successfully link back to the original document regardless of how many templates have been generated from it.

Fix:
1. Replaced the `res_model = False` custody-handoff hack in `documents_sign` with a safe `.copy({'original_id': attachment.id})`. This sandboxes the Sign app's files, completely preventing the deletion crash and the multi-template conflicts.
2. Updated the `reference_doc` computation in `sign.request` to dynamically search for both the current `attachment_id` AND its `original_id` (utilizing a minimal-diff recordset union `|`). This perfectly preserves the lineage tracking for all templates without requiring database schema changes.

Task: 5432116

When sending survey invitations to a group of recipients with different language preferences, some recipients would receive the invitation in the incorrect language.

### Steps to reproduce

1. Install the "Surveys" module and activate a second language (e.g., Dutch).
2. Create a survey and ensure its invitation template has translations for both languages.
3. Create two contacts: one with English as their language and another with Dutch.
4. On the survey, click "Share" and add both contacts as recipients.
5. Send the invitations.
6. The contact with Dutch preferred language receives the email in English.

### Cause

By default, the wizard uses a single language for every email in a batch. While it can switch this language if everyone in the group speaks the same tongue, it fails to do so for mixed-language groups. Adding compute_lang=True fixes this by telling the system to look up and use the correct language for each recipient one by one.

opw-5868581

Forward-Port-Of: odoo/odoo#246778

Steps to reproduce:
-------------------
1. Activate JPY and create a JPY bank journal with ISO20022 as an
   outgoing payment method
2. Create a vendor (with a country) and add a trusted bank account
3. Create and confirm a vendor bill in JPY (e.g. ¥1000), and pay it
   using the ISO20022 method on the JPY journal
4. Create a batch payment containing that payment, with Batch Type
   Outbound, on the JPY journal, with ISO20022 as payment method
5. Validate the batch — the XML file is generated and attached
6. Download it

-> The `<InstdAmt Ccy="JPY">` node outputs `1000.00`, while JPY has
no decimals. The file is rejected by banks.

The fix:
--------

Backport of 8da91d94ed1e8fad0e827f96172e3785e9f0e28d:

> Generating the xml file for iso20022 always generates the amount with
two decimals which is hard coded and can cause error for currencies without decimals for example JPY.
> The fix is to have the currency decimal number dynamically set through
the currency decimal places field.

opw-6103849

Forward-Port-Of: odoo/enterprise#113296