**Steps to reproduce:**
* Install the **l10n_es_edi_sii** module.
* Create a **Portuguese customer**.
* Go to **Settings** and enable **EU Intra-community Distance Selling**, then refresh the tax mapping.
* Create a customer invoice with a **"No Sujeto por reglas de localización"** tax (e.g. **23.0% PT VAT**).
* Go to **Accounting → Reporting → Tax Report → OSS Sales**.
* Export the **VAT Record Books (XLSX)** file and open it.

**Observed behavior:**
* The "Clave de Operación" column shows "01" for lines with no_sujeto_loc taxes instead of "17".
* The SII JSON for the same invoice correctly shows "ClaveRegimenEspecialOTrascendencia": "17".

**Cause:**
* In `_l10n_es_libros_get_common_line_vals()`, `operation_code` was computed manually as `'02' if exempt_reason else '01'`, which only handled the E2 exempt case and defaulted everything else to "01".
* This missed OSS/no_sujeto_loc taxes (e.g. FR VAT, PT VAT) that should produce "17" per the Spanish VAT regime code table.

**Fix:**
* Extract operation code computation into a new dedicated method `_l10n_es_libros_get_operation_code()`.
* For customer invoices, delegate to the existing `_l10n_es_get_regime_code()` method already used by SII, which correctly returns "17" for OSS-tagged taxes, "02" for E2 exempt, and "01" otherwise.
* For vendor bills, mirror the SII logic by checking whether the invoice taxes include tags from `mod_303_casilla_10_balance` or `mod_303_casilla_11_balance` (intra-community indicators), returning "09" if so and "01" otherwise.

opw-6197141,6216485

Forward-Port-Of: odoo/enterprise#117236

[FIX] product_barcodelookup: avoid crash on invalid image URLs
**Steps to Reproduce:**
-  Install Sales module.
- Configure a valid Barcode Lookup API key.
- Create a product without an image.
- Set a barcode whose returned image URL is broken or returns HTTP 404
  (e.g. `8426904171073`).
- Select the product and trigger the server action:
  `Action -> Get Pictures from Barcode Lookup`

Issue:

**During image fetching:**

-  Barcode Lookup API successfully returns product data and image URLs.
- `_get_image_from_url()` attempts to download the image.
- The image URL responds with HTTP 404.
- `barcode_lookup_request()` returns a dict for non-200 responses.
-  `_get_image_from_url()` assumes the response is always a `requests.Response`
   object and directly accesses:  `response.status_code`
- This causes: `AttributeError: 'dict' object has no attribute 'status_code'`

**Root Cause:**
- `barcode_lookup_request()` returns inconsistent response types:
     - `requests.Response` for successful requests
     - `dict` for failed requests
- _get_image_from_url() does not handle the dict response before accessing
   response attributes.

**Solution:**
- Make barcode_lookup_request() always return a One Response
  object.
- Move the response validation to the callers instead of returning custom
  dict objects.

**Result:**
- No RPC crash when image URLs are invalid or return 404.
- Broken image URLs are safely ignored.

**OPW-6200749**

Forward-Port-Of: odoo/enterprise#116925

Currently, an error occurs when user tries to select a property field in auto field.

Steps to replicate:
- Install `sale_management` and `sign`.
- Open Sales > Products > Products > Open any product.
- From the Gear icon, Click Edit Properties and save the record.
- Enable Debug mode if you are using a version lower than 19.0 .
- Open Sign > Configuration > Field Types.
- Create a new Field > Give a name > Select model as `Product`.
- Select Field as `Property > Property 1` and click save.

Error:
- saas-18.3 and later:
```
  File '/home/odoo/odoo18/enterprise/sign/models/sign_item_type.py', line 57, in _check_auto_field_exists
    auto_field_value = record.mapped(sign_type.auto_field)
                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File '/home/odoo/odoo18/community/odoo/orm/models.py', line 5472, in mapped
    field = records._fields[field_name]
            ^^^^^^^^^^^^^^^
AttributeError: 'Property' object has no attribute '_fields'. Did you mean: 'field'?
```

- saas-18.2:
```
  File '/home/odoo/odoo18/enterprise/sign/models/sign_item_type.py, line 41, in _check_auto_field_exists
    auto_field_value = record.mapped(sign_type.auto_field)
                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File '/home/odoo/odoo18/community/odoo/orm/models.py', line 5744, in mapped
    if len(records) > PREFETCH_MAX:
       ^^^^^^^^^^^^
TypeError: object of type 'bool' has no len()
```

Cause:
- As the user gave auto fill field as a Property field the [line] called `mapped()` to access its value, this caused the error to occur.

- This occurs because `mapped()` expects a `recordset` (models.Model), but instead it receives a Property object, which does not have `_fields`.

Solution:
- Using `'allow_properties': 'False'`, the property fields wont appear in the list of field selection.

[line]: https://github.com/odoo/enterprise/blob/cdaeb79e1f623831fffa553dbb658698367c7e19/sign/models/sign_item_type.py#L41

sentry-7378769090

Forward-Port-Of: odoo/enterprise#113091

### Issue before this commit:
When reversing an invoice in a Peruvian company, the "Cancel Reason" entered in the credit note window is not propagated to the Peruvian EDI tab of the resulting Credit Note. Only the Credit Reason is successfully reported.

### Steps to reproduce the issue:
1. Download Accounting and l10n_pe
2. Switch to PE company
3. Create an invoice and confirm it
4. Create a credit note for the invoice with a cancel reason and a credit reason and click the reverse button
5. See that in the Peruvian EDI tab only the Credit Reason is reported but not the Cancel Reason

### Cause of the issue:
In the l10n_pe_edi module, the override of the _prepare_default_reversal method maps the l10n_pe_edi_refund_reason to the new move's values, but completely omits the mapping of the wizard's textual reason field to the l10n_pe_edi_cancel_reason field of the resulting credit note.

### Reason to introduce the fix:
To ensure the generated credit notes contain all required information for the Peruvian EDI (SUNAT). Mapping the cancel reason guarantees that the electronic document accurately reflects both the refund code and the descriptive cancellation text provided by the user.

opw-6238525

Forward-Port-Of: odoo/enterprise#118479

Issue:
Cancelled journal entries were visible in the "Journal Items to Reconcile" view (action_move_line_posted_unreconciled) because the action domain had no filter to exclude them. This caused reconciliation failures, no reconciliation happened, and the cancelled record remained in the view.

This regression was introduced during a refactor to allow draft entries in the reconciliation view, where the posted-state condition was removed from the domain:

Enterprise commit: https://github.com/odoo/enterprise/commit/003cffabda7d91a6d10d58942ed972ca5e17366d

As a result, cancelled journal items also became visible, causing reconciliation attempts to fail while the records remained in the view.

Also, we are not allowed to reconcile cancelled move lines, and we already
have the validation for this [here](https://github.com/odoo/odoo/blame/a236f67776616f6facdefb0117a6ffdde9b7c84c/addons/account/models/account_move_line.py#L2627)

Issue is reproducible on runbot. Here is the video reference: https://drive.google.com/file/d/1ojIDxHn5Yst8gVFy8JyhwtJoDSSSJsmK/view?usp=sharing

- OPW: 6247870

Forward-Port-Of: odoo/enterprise#118843
Forward-Port-Of: odoo/enterprise#118773