Steps to reproduce:
- Configure a bank journal with Outstanding Receipts/Payments accounts
- Create two customer invoices for the same partner (e.g. 1000 and 2000)
- Select both, Register Payment, enable Group Payments, pay 1500 so that the first invoice is fully paid and the second remains partially paid (1500 due)
- Validate and reconcile the payment, then open the Customer Follow-up Report

Issue:
The fully paid invoice still shows up in the Follow-up Report, alongside the partially paid one.

Cause:
The report's 'unreconciled' domain (account.report. _get_options_unreconciled_domain) filters on full_reconcile_id, which is set per matching-number group rather than per line: when several invoices are settled together through a grouped payment, they all share the same matching number, and the group only gets a full_reconcile_id once *every* line in it is fully paid. Since the second invoice is still open, the group stays without a full_reconcile_id, so the first invoice is wrongly treated as unreconciled too, even though its own residual amount is zero.

Fix:
Override _get_aml_values on the Follow-up report handler to drop lines that are individually reconciled (amount_residual = 0), instead of relying on the group-level full_reconcile_id. The generic unreconciled domain is left untouched since Partner Ledger and Aged Receivable also rely on it and may depend on keeping partially settled matching groups grouped together.

opw-6323401

**_Steps to reproduce :_**

-  Install l10n_it_riba.
-  Configure a company with a San Marino (SM) IBAN as the bank account for the
   journal used for Ri.Ba.
-  Create a customer payment and add it to a Batch Payment using the Ri.Ba.
   payment method.
-  Validate the Batch Payment.

**_Observed behavior :_**

 The validation fails with the error:
   `Only bank accounts with an Italian IBAN are allowed to use Ri.Ba. payments`

**_Cause :_** 

 The Ri.Ba. validation logic only accepts IBANs with the IT country code and incorrectly rejects valid San Marino (SM) IBANs.

**_Fix :_**

-  Update the Ri.Ba. IBAN validation to accept both Italian (IT) and San Marino (SM) IBANs when generating Ri.Ba. payment files.

-  While validating Batch Payments for SM IBANs, we observed that the extracted value could overlap with the branch code portion, causing the generated RIBA record to exceed the expected 120-character length. This change updates the extraction logic to prevent overlap and ensure compliance with the required record format.

**_opw_** - 6303820

Before this commit, the down payments line of the project profitability panel had no drill down action for salespersons and billing users without accounting access, because the group references were written with a trailing comma inside the XML id, making the two checks silently fail for everyone. Only the accounting read group check, written correctly, was effective.

Steps to reproduce:
- create a service product with "Create on Order: Project & Task", sell it on a sale order and confirm it
- create a down payment invoice from the sale order and post it
- create a user with Sales "User: All Documents" access, Project "User" access and no accounting access
- as that user, open the dashboard of the generated project and look at the Down Payments line of the profitability panel

The Down Payments amount is displayed as plain text, while a user with accounting access can click it to open the related invoices, as intended for the salesperson too.

Solution:
Move the commas out of the group references.

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

Seven entries of the Mexican chart of accounts template carry a name belonging
to a **different** group, copied from a neighbouring entry. Each record's XML ID
still states the intended name, which is what this restores.

| Code | Field | Before | After |
|---|---|---|---|
| `6` | `name@es` | Gastos generales | Gastos |
| `252.07` | `name@es` | `account_subgroup_hipotecas_por_pagar_a_largo_plazo_nacional` | Hipotecas por pagar a largo plazo nacional |
| `602` | `name`, `name@es` | Cost of sales / Costo de venta | Selling expenses / Gastos de venta |
| `613` | `name@es` | Amortización contable | Depreciación contable |
| `614` | `name` | Accounting depreciation | Accounting amortisation |
| `701.06` | `name`, `name@es` | Interest on foreign bank charges / Intereses a cargo bancario extranjero | Interest payable by national natural persons / Intereses a cargo de personas físicas nacional |
| `702` | `name@es` | Utilidad cambiaria | Productos financieros |

### Why it is not cosmetic

The electronic accounting Chart of Accounts XML takes the `Desc` attribute of
every `<Ctas>` element from the *account group name* — `cfdicoa.xml`
(`t-att-Desc="account.get('name')"`), fed by `trial_balance.py`
`_l10n_mx_get_coa_values()`. Any `es_*` database therefore declares:

```xml
<catalogocuentas:Ctas CodAgrup="702" NumCta="702" Desc="Utilidad cambiaria" Nivel="1" Natur="A"/>
```

whereas the SAT catalogue (Anexo 24) publishes `702` as *Productos financieros*,
with `702.01 Utilidad cambiaria` … `702.10 Otros productos financieros` beneath
it. `CodAgrup` comes from `code_prefix_start` and stays correct, so the file
still validates against the XSD, but the declared description does not match the
official nomenclature. Trial Balance and Pólizas are unaffected — neither
exports group names.

### Evidence

- `252.07` contains its own XML ID as the Spanish name.
- `602` duplicates `501.01`, yet its children are `Sueldos y Salarios`,
  `Compensaciones`, `Tiempos extras`.
- `613` and `614` are swapped in one language each: `613`'s children are
  depreciations, `614`'s are amortisations.
- `701.06` duplicates `701.05` in both languages; the correct name is symmetric
  to `701.07` and to `702.06`.
- `6` is the only single-digit root group whose Spanish name does not match its
  XML ID (`account_group_gastos`).

### Notes

Introduced in d782b8b92557; correct in 15.0, where the names lived in
`account.account.tag.csv`. Still present in 18.0, 19.0 and master, hence
targeting 17.0. Template data only — existing databases are unaffected until the
chart is (re)installed, and renaming a group moves no balance.

Forward-Port-Of: odoo/odoo#277426

## Steps to Reproduce:
1. Install the Sales and Studio modules.
2. Create a new menu for "**Sales Order Line**".
3. Open the menu in list view and group by "**Order**".
4. Sort by "**Order Reference**".

## Issue:
Sale order lines appear to be sorted randomly when grouped by Order and sorted
by Order Reference.

## Cause:
When sorting on a many2one field, the `_order_field_to_sql()` method uses the comodel's default `_order` to generate the SQL query. - [1]
Since `order_id` is a many2one on `sale.order.line` model, sorting by the `order_id` (Order Reference) also applies this default ordering of `sale.order` model, which is `date_order desc, id desc`.

As a result, sale order lines are not ordered by SO name, but also by the corresponding sale order's order date. This ordering changes the order of the records, making the result appear random from the user's perspective, even though they explicitly sorted by Order Reference.

## Fix:
This commit removes the `date_order` from the default ordering of the sale order and keeps only ordering by id. This prevents the sale order's order date (date_order) from affecting the ordering of sale order lines.

This follows the same approach previously accepted for purchase orders.
Task: https://www.odoo.com/odoo/project/49/tasks/2367965
PR:  https://github.com/odoo/odoo/pull/60542

[1] - https://github.com/odoo/odoo/blob/16a1a545e2809a2172053f4db6193f425900e4ec/odoo/models.py#L5652-L5671

opw-6348322

Description of the issue this commit addresses:

When a member of the Invoicing group tries to create a payment trough the L10nPlAccountPaymentRegister wizard, upon clicking "Create Payment", an AccessError is thrown. Invoicing group members should be able to handle payments so this is an issue.

---

Steps to reproduce:

1. Make sure sale_management and l10n_pl_bank_verification are installed.
2. Create a new user with "Invoicing" Accounting group.
3. Create a new sales order with said user (any customer, any product)
4. Confirm the quotations and, from its form view, "Create Invoice".
5. Confirm the invoice and, from its form view, "Pay".
6. Upon clicking "Create Payment", an Access Error is thrown.

---

Desired behavior after this commit is merged:

This commit makes sure an Invoicing group member is able to create the payment withtout AccessErrors being thrown.

---

task-none
feedback from: https://github.com/odoo/odoo/pull/267992

---

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

### Issue before this commit:
When importing an electronic invoice from SDI that is failing with an exception, the resulting account.move record was saved in the "Miscellaneous Operations" journal instead of the correct one (Vendor Bills), even though the move_type itself was correct.

### Steps to reproduce the issue:
Pre steps: you need to have access to https://iap-services-test.odoo.com/odoo
1. Download Accounting and l10n_it
2. Go to Settings > Companies and set the VAT of IT company the same as the one in the xml
3. Go to Settings > Italian Electronic Invoicing and select Test
4. Go into the code and insert an Exception inside the function _l10n_it_edi_import_invoice after self.move_type = move_type (or create any type of exception from the user interface)
5. Go to IAP service into IT EDI app and see that your company is there as user
6. Click into the record > receive move button > upload your xml > create
7. Go to your DB > Scheduled Actions > filter with IT > IT EDI: Receive invoices from the SdI > Run Manually
8. Go to Journal entries, remove the filter and find your imported bill
9. You can see it was inserted into the Miscellaneous Operations Journal instead of a Vendor Bill Journal

### Cause of the issue:
The move is created inside a savepoint context manager, designed so that even if parsing fails, an empty move with the attachment still remains. The problem is that if the exception is raised, the savepoint rollback undoes everything that follows, but the journal was already determined before the correct move_type was known, leaving the move in the wrong default journal.

### Reason to introduce the fix:
The fix is needed to ensure that, regardless of where parsing fails, the move's journal is correctly set even if an exception occurs so that it is possible to find the move in the correct section even if not imported correctly.

opw-6397712

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

Forward-Port-Of: odoo/odoo#278111

Steps to reproduce the problem:

* Create a SO line by code setting a specific unit price.
* Modify afterwards the quantity.

Result: The unit price is reset.

Expected behavior: The unit price is kept.

You can exercise it with this code in the shell:

```python
from odoo import Command
partner = env["res.partner"].create({"name": "Test partner"})
product = env["product.product"].create({"name": "Test product", "list_price": 60.0})
order = env["sale.order"].create(
    {
        "partner_id": cls.partner.id,
        "order_line": [Command.create({"product_id": cls.product.id, "price_unit": 100})],
    }
)
print(order.order_line.price_unit)  # It's 100
order.order_line.product_uom_qty = 2
print(order.order_line.price_unit)  # It's 60!
```

This is because when the technical price is not set on SO line creation, the value is set on precompute as the unit price, thus being considered non manually modified, and consequently being reset.

It can be fixed setting a different value from the unit price. For not conflicting with any of the creation possible values, a high negative number is set.

@Tecnativa