Currently, a typo appears in the `Pending Message` shown in the 
SEPA Direct Debit payment provider configuration.

**Steps to reproduce:**
- Install the `payment_sepa_direct_debit` module.
- Navigate to Invoicing > Configuration > Payment Providers > SEPA Direct Debit.
- Open the `Messages` tab and observe the `Pending Message`.

**Observation:**
The message uses "an unique" instead of the grammatically correct "a unique".

**Fix:**
This commit corrects the message by replacing "an" with "a" at [1].

Before:
<img width="1903" height="606" alt="typo_before" src="https://github.com/user-attachments/assets/df4f658b-9f4c-4e68-b8cb-a1bdc2253fc3" />

After:
<img width="1900" height="609" alt="typo_after" src="https://github.com/user-attachments/assets/e9192d70-b343-4e4e-9e21-281a93d4d71e" />

[1]:
https://github.com/odoo/enterprise/blob/6c3692d85bf1ef7b14d930d9a1ed244cf8aa851b/payment_sepa_direct_debit/data/payment_provider_data.xml#L13

opw-5373274

Forward-Port-Of: odoo/enterprise#100983

BUG 1:
---------
**steps to reproduce**:
1. Install documents
2. Open any document
3. Go to Action > Rename
4. Rename the document
5. Preview it and read the name showed there

**issue**:
When previewing the document, it still shows the old attachment name.

**observation**:
When renaming a document, only the document name was updated. The attachment name remained unchanged, which caused inconsistencies:

1. In the All Records section, the document name is displayed correctly. https://github.com/odoo/enterprise/blob/459e8ddaf6f67a556d35bf00e0fbb68eb1500a94/documents/views/documents_document_views.xml#L130

2. But in the Preview, the old attachment name was still shown, as it is taken from the attachment:
https://github.com/odoo/enterprise/blob/459e8ddaf6f67a556d35bf00e0fbb68eb1500a94/documents/static/src/views/hooks.js#L373-L383

**solution**:
Use the document name when previewing it

BUG 2:
---------
**steps to reproduce**:
1. Install Documents.
2. Open any document.
3. Rename it via the chatter.
4. Try renaming it again via the details panel.

**issue**:
After renaming a document twice through the details panel, the preview still displayed the old document name.

**cause**:
On the first rename, the [insert](https://github.com/odoo/enterprise/blob/691115d8a0b31322f64d35d82dc8c9ddbfcd39b0/documents/static/src/core/document_service.js#L96-L129)) method creates a new [store.Document](https://github.com/odoo/enterprise/blob/691115d8a0b31322f64d35d82dc8c9ddbfcd39b0/documents/static/src/views/hooks.js#L367-L393) record with the updated attachment name. However, The write method (used by chatter) skips reloading the record and linked attachment data on the second rename.

Unlike the Rename button, which uses web_save (and triggers a record reload via web_read), the chatter directly calls write without refreshing the attachment.

**Solution**:
Ensure the preview uses the document name from the document record, keeping it consistent after multiple renames via the details panel.


**Example:** Try to rename a "Invoice.pdf" document to "Invoice_rename.pdf"
<details>
    <summary>Click here to see the results:</summary>
    Before:
    <img src="https://github.com/user-attachments/assets/563b7fb9-709c-4651-8492-032a7f353730"/>
    After:
   <img src="https://github.com/user-attachments/assets/6fc6bdfe-dd1e-4f3c-aaf7-821c44fd135d"/>

</details>

opw-5065433

Forward-Port-Of: odoo/enterprise#95111

Steps to reproduce:
1. Install 'hr_contract_salary_payroll'
2. Create three benefits from Payroll > Configuration > Benefits

      - Basic:
      Salary Structure Type: US Employee
      Contract Related Field: Health Benefits Dental
      Display Type: Slider (1500, 6000)      
      - Housing:
      Salary Structure Type: US Employee
      Contract Related Field: Health Benefits Vision
      Display Type: Always Selected
      
      - Transport:
      Salary Structure Type: US Employee
      Contract Related Field: Health Benefits Vision
      Display Type: Manual
      Mandatory Benefits: Basic, Housing

3. Go to Employees > Contracts
4. Create a new contract:
   Set an employee
   Salary Structure Type = US Employee
   HR Responsible = Mitchell Admin

5. Click the Generate Offer smart button.
6. Open the link
7. Adjust the sliders

Issue: it gives a traceback
`TypeError: Cannot read properties of undefined (reading 'type')`

Cause:
https://github.com/odoo/enterprise/blob/cc3fe89528a143cff3ab03e1654755c34eaac112/hr_contract_salary/static/src/js/hr_contract_salary.js#L480-L482
In checkInputSelected, the target array is empty when an Always Selected benefit is present, causing an attempt to read target[0].type.

Solution:
Add a guard to check that target is not empty before accessing its elements.

opw-5058994

Forward-Port-Of: odoo/enterprise#94881

The `test_bill_state_change_on_payment_state` is throwing an exception.

```
self.assertEqual(payment.invoice_ids.payment_state, 'not_paid')
AssertionError: 'paid' != 'not_paid'
- paid
+ not_paid
```

The test was incorrectly expecting invoice `payment_state` to always be `not_paid` when payment is reset to draft, but behavior differs based on whether  `accountant` module is installed or not.

- With `accountant`: Payment has no move_id (no journal entry created by default), so when drafted, `invoice.matched_payment_ids` filters exclude it, resulting in 'not_paid' state.

- Without `accountant`: Payment has move_id (journal entry auto-created) so filter conditions fail (`not p.move_id` is `False`), and invoice stays `paid` due to existing reconciliations in `draft` state.

Test was introduced here:  https://github.com/odoo/enterprise/pull/100834/commits/402bd85af79fa68fa2cb957d40307edf62f7525c
Commits that introduced the behavior change:
https://github.com/odoo/odoo/pull/182390/commits/b572fcd78289013f28f11157b1bfbb75c9ea7344
https://github.com/odoo/odoo/blob/57f1053b031f293c6cd8dc8f590dccda4fb3e665/addons/account/models/account_move.py#L1308-L1314

Runbot [link](https://runbot.odoo.com/odoo/error/234573)
runbot error: 234573

The EFT file format BNZ is exported as a text file. As such, any commas in the field contents will be treated as a new field, resulting in incorrect formatting and a rejected batch file.

This behavior is due to the Odoo community commit [3082d3b](https://github.com/odoo/odoo/commit/3082d3bd0d7a8b45e647c441ba48adcb84a7a070), which partially reversed an improvement to the group payment memo field.

- The original behavior was to concatenate the included invoices with spaces (e.g. 'INV/123 INV/124').
- The improvement replaced this with the batch payment reference (e.g. 'BATCH/IN/002').
- The behavior after 3082d3b is to concatenate the included invoices with a space and a comma (e.g. 'INV/123, INV/124'

This commit strips the commas from all generated EFT files, instead of further altering the group payment memo field. It also alters existing unit tests to check that commas are removed from payment memo fields.

While a fix that changes the memo generation would resolve some issues, this commit ensures that manually added commas will not cause rejected payments. 

[Ticket link](https://www.odoo.com/odoo/unassigned-tasks/5099220)
opw-5099220

Forward-Port-Of: odoo/enterprise#100670
Forward-Port-Of: odoo/enterprise#98613

In the POS of a Mexican company, when requesting an invoice, the user is asked to set the invoice to public or not. If the customer does not have a recognized ZIP code or country, setting the invoice to public **should not** raise an error, but it does. This is because the `l10n_mx_edi_cfdi_to_public` field is not correctly updated in the ORM, which leads to the UserError below being triggered, as `l10n_mx_edi_cfdi_to_public` is always set to `False` if it's not updated by its `_compute` method.

https://github.com/odoo/enterprise/blob/dd89c2c72039c9910cc0a303bca332f4103c08f6/l10n_mx_edi/models/account_move_send.py#L54-L55

The said field is not properly updated because it is a compute field.
Such fields are not transferred to the ORM because of the two following
conditions from the POS: [[1](https://github.com/odoo/odoo/blob/5c2280d089f248dff67df980bee1ce6a4156f2c9/addons/point_of_sale/static/src/app/models/related_models.js#L205-L206), [2](https://github.com/odoo/odoo/blob/5c2280d089f248dff67df980bee1ce6a4156f2c9/addons/point_of_sale/static/src/app/models/related_models.js#L895-L896)]

To minimize behavioral changes, the required field (`l10n_mx_edi_cfdi_to_public`) is simply added at the end of the serialization process.

Once this field is correctly shared with the ORM, the UserError is not longer raised when the *Invoice to Public* field is set to "Yes" in the POS.

Steps to reproduce the initial error:
1. Install the following app and module:
    - Point of Sale (`point_of_sale`)
    - Mexican Localization for the Point of Sale (`l10n_mx_edi_pos`)
2. Set the company to a Mexican one (e.g., *ESCUELA KEMPER URGATE*)
3. Open the POS app
4. Open a register
5. Select a product and click *Add*
6. Click *Payment*
7. Set the Customer to a new customer with only a name (no Country/ZIP Code)
    - Click "Cash" to set the Remaining to 0
8. Toggle the *Invoice* button, set the *Invoice to Public* to *"Yes"* and click *Ok*
9. Click *Validate*.
10. An error *"Invalid Operation, CFDI not set to Public"* appears.

opw-5171035

Forward-Port-Of: odoo/enterprise#99871