The`SP` (Split Payment) taxes have incorrect configurations:
- **Tax Grid Tags on `SP` Taxes**: The ve38 grid tag was incorrectly assigned to the tax line instead of the base line.
- **`VE38` VAT Report Formula**: In Tax Report > VAT Report, the line `VE38 - Transactions with parties referred to in Article 17-ter` was using a negative formula `-ve38` and should be `ve38`
- **Tax Group Invoice Label**: Updated the default label on invoices for the SP tax group to display 22% SP instead of 22%.

Steps to reproduce:
- Install `account` and `l10n_it`
- Switch to IT company
- Go to taxes and filter for `SP` taxes
- The tax grid is wrong for the negative taxes since `ve38` should be in the base line instead of in the tax line
- Go in the Tax report > VE VAT Report
- The line `VE38 - Transactions with parties referred to in Article 17-ter` has a negative formula `-ve38`, should be positive `ve38`
- The label on invoices of the tax group should be `4% SP`, `5% SP`, `10% SP` not `4%` etc.

References:
https://www.informazionefiscale.it/IMG/pdf/dichiarazione_modello_iva_2026_agenzia_delle_entrate.pdf
<img width="1413" height="141" alt="immagine" src="https://github.com/user-attachments/assets/7fa15859-beaa-4345-bf81-fedc3f0af2fa" />
https://fiscomania.com/quadro-ve-della-dichiarazione-iva/
<img width="705" height="154" alt="immagine" src="https://github.com/user-attachments/assets/4f23b407-0e4d-4104-9695-f9891ccfd2f2" />

Ticket [link](https://www.odoo.com/odoo/project.task/6543520)
opw-6543520

Forward-Port-Of: odoo/odoo#287238

### Issue before this commit:
When generating a credit note for an invoice already accepted in the Polish KSeF system, the exported XML incorrectly includes the <NrKSeFN>1</NrKSeFN> tag. This tag falsely indicates that the original invoice was issued outside of KSeF, and the official KSeF number of the corrected invoice is entirely omitted from the file.

### Steps to reproduce the issue:
1. Download Accounting and l10n_pl
2. Go to Settings > Polish Localization > Insert certificate
3. Go to Invoices > Create an invoice > Send it to KSeF
4. Create a credit note for that invoice, reverse it and send it to KSeF
5. Tag <NrKSeFN>1</NrKSeFN> should not be there

### Cause of the issue:
The tag <NrKSeFN>1</NrKSeFN> is emitted in every case without any rule handling it.

### Reason to introduce the fix:
To comply with the official FA(3) logical structure rules. According to the specifications, if the corrected invoice was issued and accepted in KSeF, the XML must include the <NrKSeF>1</NrKSeF> flag and additionally provide the original KSeF number in the <NrKSeFFaKorygowanej> field. Otherwise, if the original invoice was issued outside of KSeF, the system must enter "1" in the <NrKSeFN> field and strictly omit the <NrKSeF> and <NrKSeFFaKorygowanej> fields.

<img width="866" height="981" alt="image" src="https://github.com/user-attachments/assets/53b42f9f-aaab-4642-be38-2a5abc1d8539" />

opw-6541941

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

Forward-Port-Of: odoo/odoo#288286

### Steps to Reproduce:
1. Activate Peppol
2. Create invoice for customer with Peppol
3. Add line without product name or label
4. Send invoice through Peppol and observe the Traceback error

### Issue:
When generating a Peppol invoice, there will be a Traceback error if an invoice line is missing both a product and a label. The XML builder evaluates the missing `cbc:Name` element as `None` instead of an empty dictionary. Therefore, attempting to directly subscript `['_text']` on it throws a TypeError traceback. This prevents the user from seeing the standard validation warning about the missing item data.

### Solution:
We can update the document node constraint check to safely access the dictionary keys using `.get()` with an empty dictionary fallback. This prevents the traceback and ensures that the system will correctly display the intended validation error to the user.

opw-6577441

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

Forward-Port-Of: odoo/odoo#288713

Which flag stands for a language is a presentation choice, not a property of its code. `_compute_field_flag_image_url` derives the URL from the country part of the locale, and a site that wants a different flag for a language it offers, a regional one or the flag of the country it actually serves rather than the one the code names, has to compute that URL its own way.

That is not possible today. The field passes the compute as the function object:

    flag_image_url = fields.Char(compute=_compute_field_flag_image_url)

`determine()` takes the `callable` branch and calls that object with the recordset. A plain function is not bound, so the implementation of `base` runs whatever class the record has: a module that inherits res.lang and defines `_compute_field_flag_image_url` changes nothing, and nothing says so. No error, no warning, and the field keeps answering the same URL. Getting around it means redeclaring the field only to replace its compute, which is more than the situation calls for.

Passing the method name puts the computation back on the MRO and costs nothing else: `Field.get_depends` resolves a string with `resolve_mro` and collects `_depends` from every implementation it finds, so the `@api.depends('code', 'flag_image')` declared here keeps applying, to this implementation and to an override alike.

This is the same kind of fix as #185419, which made the `domain` of a field reachable by an override for the same reason. Two field declarations in the codebase still pass a function object this way; the other is `website.menu.is_mega_menu`, which passes `inverse` the same way and is left alone here.

Forward-Port-Of: odoo/odoo#288686