Scenario:

- paste "język việt" (polish + vietnamese) in a page
- change website font to not be "Noto Sans", for example: Raleway
- open the page on Edge Browser on Android

Result: polish and vietnamese characters are using different font and
are visually different than latin character.

Cause: google fonts is serving for nearly all browsers font
configuration with woff2 files and unicode-range so the user only loads
the part of the font that will be used on the website. For Edge browser
on android, based on the user-agent chrome is serving only a TTF file
without unicode-range because it is thinking that unicode-range is not
supported. These files only contain basic latin characters, so extended
latin and vietnamese characters are being rendered with fallback "Odoo
Unicode Support Noto" that has a different weight and style for the same
weight.

Fix:

For the browser not supporting unicode-range (desktop edge before 2020,
Edge on android, …), in addition to latin we ask google fonts to
provide([1]) latin-extended and vietnamese subsets in TTF/WOFF files if
available. For other subset (hebrew, arabic, cyrillic, …) the intent is
to fallback on "Odoo Unicode Support Noto" since they should usually not
be mixed with latin characters.

Note: Edge on android in reality support unicode range, so this would be
solved if google fonts just served the unicode range font configuration
for that user-agent.

[1]: https://developers.google.com/fonts/docs/getting_started#specifying_script_subsets

opw-4642242

Forward-Port-Of: odoo/odoo#267798

Currently, if there's no receipt/delivery/internal description,
a move description will use a product internal note as a fallback.
The issue is that this is an html field and it doesn't show its
content correctly.

This PR aims to remove this fallback. If no description is found,
then it proposes to use the display_name of the product, which is
later ignored in `stock_move_product_label.js` anyway.

Second, if a picking is created manually, the description_picking
is in the vals, which triggers `_inverse_description_picking`.
This is different if the picking is created by a SO, PO, MO, etc.
We're unifying the behavior by making sure to remove `description_picking`
from the create vals. However once a move is done, the description
should be immutable. So we're also adding a call to
`moves_todo._inverse_description_picking` to for a write on
`description_picking_manual` when marking a move as done.

task 6131699

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

Issue:
---
Due to this issue, in multi-company environment, wrong fiscal position might be assigned to the order, leading to `incompatible companies` error.

Steps to reproduce:
1- On multi-company setup, assign a website to the second company.
2- Configure pickup method for second company.
3- Configure fiscal positions for both companies.
4- Setup auto invoice for second company.
5- Using public user, add a product to cart and checkout.
6- Use pickup method, and pay.

The order is not confirmed. If you enable debug mode after payment, it will show an `incompatible companies` error.

Cause:
---
https://github.com/odoo/odoo/blob/43f5ceadbc1f7df9898c327bf65bffdbe9860c1c/addons/account/models/partner.py#L247-L279 `_get_fiscal_position` is using environment company to compute the fiscal position.

However, `_compute_fiscal_position_id` causing the issue here is triggered inside `report_saleorder` template with user set as odoobot when trying to to send the confirmation.

As a result, the odoobot company's fiscal position will be used causing this issue.

Fix:
---
We should ensure company from sale order is used by setting it as env company.

opw-6186296

Forward-Port-Of: odoo/odoo#264123

### Description of the issue/feature this PR addresses:
Prevent Out of Memory (OOM) crashes and drastically improve execution speed when generating the Swedish SIE4 verification export for massive datasets.

### Current behavior before PR:
When exporting a large volume of journal entries (e.g., 190,000+ account moves), the `_export_l10n_se_sie4_verification` method relies on iterating through heavy ORM recordsets and accessing relational child fields (move.line_ids) inside a loop. This triggers a severe N+1 query problem, maxing out server RAM and causing an OOM crash.

### Desired behavior after PR is merged:
The method now utilizes a hybrid data extraction approach:
- The ORM is used strictly to safely evaluate domains (multi-company rules, dates, states) and fetch a lightweight list of valid move_ids.
- A single SQL query with JOIN statements fetches all parent moves, child lines, and account codes in exactly one database query.
- itertools.groupby chunks the flat, lightweight dictionary results back into their respective journal entries.
The export now handles massive datasets in seconds with minimal memory overhead, while remaining perfectly secure.

### Benchmark:

For Memory:
| # Input Data | Before PR | After PR |
| -------- | -------- | -------- |
| ~190,000 moves | MemoryError | 407MB|
| ~200,000 moves | 1.8GB | 174.8 MB|

For Speed:
| # Input Data | Before PR | After PR |
| -------- | -------- | -------- |
| ~190,000 moves | MemoryError | 5.10s |
| ~200,000 moves | 1m29s| 5.3s|

### Reference:
opw-6067999

Forward-Port-Of: odoo/enterprise#118849
Forward-Port-Of: odoo/enterprise#113227

<h2>Context</h2>

Clients can have some existing accounts with `reconcilable` flag set as True. Some of these accounts also have partially reconcilated transactions. In Odoo 19.0, it is not authorized to toggle the `reconcilable` flag from True to False on accounts that contain partially reconcilated transactions.

When the migration script `l10n_pl/migrations/2.1/end-migrate.py` is executed, it tries to update the CoA by adding/updating accounts, using the accounts in the file `l10n_pl/data/template/account.account-pl.csv`. This CSV file contains a reconcilable flag per account.

<h2>Problem</h2>

Before this modification, the upgrade script was trying to update the CoA using `_load_data`, which tries to overwrite the reconcilation flag of accounts in the client DB. A traceback occurs during the upgrade if an account's `reconcilable` flag is toggled from True to False during the update of the CoA, while it still contains partially reconciled transactions.
<details>

<summary>Traceback</summary>

```
File "/home/odoo/src/odoo/19.0/addons/l10n_pl/migrations/2.1/end-migrate.py", line 8, in migrate
    Template._load_data({'account.account': Template._get_account_account('pl')})
  File "/tmp/tmpm8z3nlb0/migrations/account/0.0.0/pre-ensure-deferred-accounts.py", line 36, in _load_data
    return super()._load_data(data, *args, **kwargs)
  File "/home/odoo/src/odoo/19.0/addons/account/models/chart_template.py", line 697, in _load_data
    created_records[model] = self.with_context(lang='en_US').env[model]._load_records(all_records_vals)
  File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 5171, in _load_records
    data['record']._load_records_write(data['values'])
  File "/home/odoo/src/odoo/19.0/addons/account/models/account_account.py", line 1122, in _load_records_write
    super()._load_records_write(values)
  File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 5092, in _load_records_write
    self.write(values)
  File "/home/odoo/src/odoo/19.0/addons/account/models/account_account.py", line 1045, in write
    self.filtered(lambda r: r.reconcile)._toggle_reconcile_to_false()
  File "/home/odoo/src/odoo/19.0/addons/account/models/account_account.py", line 975, in _toggle_reconcile_to_false
    raise UserError(_('You cannot switch an account to prevent the reconciliation '
odoo.exceptions.UserError: You cannot switch an account to prevent the reconciliation if some partial reconciliations are still pending.
```

</details>

<h2>Solution</h2>

I have sanitized the dict `data` using the `_pre_reload_data` method, so that the traceback does not appear anymore when upgrading. 

<h3>Notes</h3>

`_pre_reload_data` method sanitizes the dict `data` by avoiding the creation of duplicated accounts, the creation of duplicated fields for a given record, the toggling of the `reconcilable` flag, etcs.


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

Forward-Port-Of: odoo/odoo#257006

Scenario:

- paste "język việt" (polish + vietnamese) in a page
- change website font to not be "Noto Sans", for example: Raleway
- open the page on Edge Browser on Android

Result: polish and vietnamese characters are using different font and
are visually different than latin character.

Cause: google fonts is serving for nearly all browsers font
configuration with woff2 files and unicode-range so the user only loads
the part of the font that will be used on the website. For Edge browser
on android, based on the user-agent chrome is serving only a TTF file
without unicode-range because it is thinking that unicode-range is not
supported. These files only contain basic latin characters, so extended
latin and vietnamese characters are being rendered with fallback "Odoo
Unicode Support Noto" that has a different weight and style for the same
weight.

Fix:

For the browser not supporting unicode-range (desktop edge before 2020,
Edge on android, …), in addition to latin we ask google fonts to
provide([1]) latin-extended and vietnamese subsets in TTF/WOFF files if
available. For other subset (hebrew, arabic, cyrillic, …) the intent is
to fallback on "Odoo Unicode Support Noto" since they should usually not
be mixed with latin characters.

Note: Edge on android in reality support unicode range, so this would be
solved if google fonts just served the unicode range font configuration
for that user-agent.

[1]: https://developers.google.com/fonts/docs/getting_started#specifying_script_subsets

opw-4642242

Forward-Port-Of: odoo/odoo#267798

Issue:
Sending payments to SAT before its full amount is reconciled allow sending the same invoice payment several times to CFDI.

Steps to reproduce:
- In a Mexican company
- Create an invoice A of $40 to Inmobiliaria CVA
- Confirm and send to CFDI
- Go to bank, create a new Bank transaction of $80
- reconcile with Invoice A
- Go to invoice A => click on button "Update payments" (it doesn't appear in previous versions)
- Then sheet CFDI and Download There is the first XML sent to CFDI with payment for invoice A
- Create an invoice B of $40 to Inmobilira CVA
- Confirm and send to CFDI
- reconcile the transaction with Invoice B
- Go to invoice B
- Click on button "Update payments"
- Then sheet CFDI and Download There is the second XML sent to CFDI with payment for invoices A and B

Invoice A payment was sent twice to CFDI

Expected behavior:
- The "Update payment" button should appear only once the invoice payment is fully reconciled.

Current behavior:
- The update payment button appear once the invoice is reconciled with a payment.

The method `_l10n_mx_edi_cfdi_invoice_get_payments_diff` is called twice, once to check whether it's needed to display the "Update button" and once when you try to update the payment (called only after clicking on said button).

opw-5432421

Forward-Port-Of: odoo/enterprise#118850
Forward-Port-Of: odoo/enterprise#108355

**Problem:**
If a vendor bill associated with a project through its analytic distribution has lines with negative subtotals, those lines are not considered in the project profitability report. An example use case is a downpayment invoice, followed by a final invoice with the downpayment amount deducted.

**Steps to Reproduce:**
- Ensure project_purchase is not installed
- Create a new project with "Billable" enabled
- Go to the project settings and create an analytic account
- Create and post a vendor bill with a line labeled "downpayment", the analytic account set, and a unit price of 5
- Duplicate the vendor bill, set the "downpayment" line unit price to -5, add a line labeled "product" with the analytic account set and a unit price of 10, and post the bill

-> Go to the project updates and see that the vendor bill costs is wrong (15)

**Solution:**
A similar bug affecting customer invoices was resolved in PR #130992. AMLs with non-zero subtotals should be considered, so the domain is adjusted accordingly.

opw-6172523

Forward-Port-Of: odoo/odoo#265378

<h2>Context</h2>

Clients can have some existing accounts with `reconcilable` flag set as True. Some of these accounts also have partially reconcilated transactions. In Odoo 19.0, it is not authorized to toggle the `reconcilable` flag from True to False on accounts that contain partially reconcilated transactions.

When the migration script `l10n_pl/migrations/2.1/end-migrate.py` is executed, it tries to update the CoA by adding/updating accounts, using the accounts in the file `l10n_pl/data/template/account.account-pl.csv`. This CSV file contains a reconcilable flag per account.

<h2>Problem</h2>

Before this modification, the upgrade script was trying to update the CoA using `_load_data`, which tries to overwrite the reconcilation flag of accounts in the client DB. A traceback occurs during the upgrade if an account's `reconcilable` flag is toggled from True to False during the update of the CoA, while it still contains partially reconciled transactions.
<details>

<summary>Traceback</summary>

```
File "/home/odoo/src/odoo/19.0/addons/l10n_pl/migrations/2.1/end-migrate.py", line 8, in migrate
    Template._load_data({'account.account': Template._get_account_account('pl')})
  File "/tmp/tmpm8z3nlb0/migrations/account/0.0.0/pre-ensure-deferred-accounts.py", line 36, in _load_data
    return super()._load_data(data, *args, **kwargs)
  File "/home/odoo/src/odoo/19.0/addons/account/models/chart_template.py", line 697, in _load_data
    created_records[model] = self.with_context(lang='en_US').env[model]._load_records(all_records_vals)
  File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 5171, in _load_records
    data['record']._load_records_write(data['values'])
  File "/home/odoo/src/odoo/19.0/addons/account/models/account_account.py", line 1122, in _load_records_write
    super()._load_records_write(values)
  File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 5092, in _load_records_write
    self.write(values)
  File "/home/odoo/src/odoo/19.0/addons/account/models/account_account.py", line 1045, in write
    self.filtered(lambda r: r.reconcile)._toggle_reconcile_to_false()
  File "/home/odoo/src/odoo/19.0/addons/account/models/account_account.py", line 975, in _toggle_reconcile_to_false
    raise UserError(_('You cannot switch an account to prevent the reconciliation '
odoo.exceptions.UserError: You cannot switch an account to prevent the reconciliation if some partial reconciliations are still pending.
```

</details>

<h2>Solution</h2>

I have sanitized the dict `data` using the `_pre_reload_data` method, so that the traceback does not appear anymore when upgrading. 

<h3>Notes</h3>

`_pre_reload_data` method sanitizes the dict `data` by avoiding the creation of duplicated accounts, the creation of duplicated fields for a given record, the toggling of the `reconcilable` flag, etcs.


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

Forward-Port-Of: odoo/odoo#257006

**Steps to reproduce:**
- Install Accounting and l10n_ro_edi
- Switch to a Romanian localization (e.g. RO Company)
- Configure Romanian E-Factura

- Create an invoice with a product having a name longer than 100 chars
- Confirm the invoice
- Send E-Factura to SPV
- Fetch E-Factura status

**Issue:**
The invoice is rejected with the following error:
"[BR-RO-L100]-The allowed maximum number of characters for the Item name (BT-153) is 100."

**Similar issue with the product description:**
"[BR-RO-L200]-The allowed maximum number of characters for the Item description (BT-154) is 200."

**Similar issue with the note (i.e. Terms and Conditions):**
"[BR-RO-L300]-The allowed maximum number of characters for the Invoice note (BT-22) is 300."

**Solution:**
Truncate the name of the product to 100 chars in the electronic invoice, the description of the product to 200 and the note to 300.

opw-5964904




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

Forward-Port-Of: odoo/odoo#267850
Forward-Port-Of: odoo/odoo#265811

Scenario:

- paste "język việt" (polish + vietnamese) in a page
- change website font to not be "Noto Sans", for example: Raleway
- open the page on Edge Browser on Android

Result: polish and vietnamese characters are using different font and
are visually different than latin character.

Cause: google fonts is serving for nearly all browsers font
configuration with woff2 files and unicode-range so the user only loads
the part of the font that will be used on the website. For Edge browser
on android, based on the user-agent chrome is serving only a TTF file
without unicode-range because it is thinking that unicode-range is not
supported. These files only contain basic latin characters, so extended
latin and vietnamese characters are being rendered with fallback "Odoo
Unicode Support Noto" that has a different weight and style for the same
weight.

Fix:

For the browser not supporting unicode-range (desktop edge before 2020,
Edge on android, …), in addition to latin we ask google fonts to
provide([1]) latin-extended and vietnamese subsets in TTF/WOFF files if
available. For other subset (hebrew, arabic, cyrillic, …) the intent is
to fallback on "Odoo Unicode Support Noto" since they should usually not
be mixed with latin characters.

Note: Edge on android in reality support unicode range, so this would be
solved if google fonts just served the unicode range font configuration
for that user-agent.

[1]: https://developers.google.com/fonts/docs/getting_started#specifying_script_subsets

opw-4642242

Forward-Port-Of: odoo/odoo#267798

When creating a credit note, it is possible for the compute method _compute_partner_bank_id to be called in a context where active_test is falsy, leading to moves that cannot be validated because it would raise with the following error message:
> The recipient bank account linked to this invoice is archived.
So you cannot confirm the invoice.

The state of the 'active_test' ctx key cannot be known in advance in a compute and should not be assumed as True; according to the framework team:
> In practice, a compute method cannot expect active_test to have
> a particular value. It may be invoked with any context. There is no
> "context purge" done by the ORM. The computation may be "prepared"
> with a context (the one of modified()) and actually done with another
> context (code accessing the field before some explicit flush). In
> other words, if the compute method searches for a record that matches
> some conditions, and if that record cannot be inactive, then this
> condition must be explicit in the search domain (or in the context).

opw-6229286

Forward-Port-Of: odoo/odoo#267398

**Problem:**
If a vendor bill associated with a project through its analytic distribution has lines with negative subtotals, those lines are not considered in the project profitability report. An example use case is a downpayment invoice, followed by a final invoice with the downpayment amount deducted.

**Steps to Reproduce:**
- Ensure project_purchase is not installed
- Create a new project with "Billable" enabled
- Go to the project settings and create an analytic account
- Create and post a vendor bill with a line labeled "downpayment", the analytic account set, and a unit price of 5
- Duplicate the vendor bill, set the "downpayment" line unit price to -5, add a line labeled "product" with the analytic account set and a unit price of 10, and post the bill

-> Go to the project updates and see that the vendor bill costs is wrong (15)

**Solution:**
A similar bug affecting customer invoices was resolved in PR #130992. AMLs with non-zero subtotals should be considered, so the domain is adjusted accordingly.

opw-6172523

Forward-Port-Of: odoo/odoo#265378

<h2>Context</h2>

Clients can have some existing accounts with `reconcilable` flag set as True. Some of these accounts also have partially reconcilated transactions. In Odoo 19.0, it is not authorized to toggle the `reconcilable` flag from True to False on accounts that contain partially reconcilated transactions.

When the migration script `l10n_pl/migrations/2.1/end-migrate.py` is executed, it tries to update the CoA by adding/updating accounts, using the accounts in the file `l10n_pl/data/template/account.account-pl.csv`. This CSV file contains a reconcilable flag per account.

<h2>Problem</h2>

Before this modification, the upgrade script was trying to update the CoA using `_load_data`, which tries to overwrite the reconcilation flag of accounts in the client DB. A traceback occurs during the upgrade if an account's `reconcilable` flag is toggled from True to False during the update of the CoA, while it still contains partially reconciled transactions.
<details>

<summary>Traceback</summary>

```
File "/home/odoo/src/odoo/19.0/addons/l10n_pl/migrations/2.1/end-migrate.py", line 8, in migrate
    Template._load_data({'account.account': Template._get_account_account('pl')})
  File "/tmp/tmpm8z3nlb0/migrations/account/0.0.0/pre-ensure-deferred-accounts.py", line 36, in _load_data
    return super()._load_data(data, *args, **kwargs)
  File "/home/odoo/src/odoo/19.0/addons/account/models/chart_template.py", line 697, in _load_data
    created_records[model] = self.with_context(lang='en_US').env[model]._load_records(all_records_vals)
  File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 5171, in _load_records
    data['record']._load_records_write(data['values'])
  File "/home/odoo/src/odoo/19.0/addons/account/models/account_account.py", line 1122, in _load_records_write
    super()._load_records_write(values)
  File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 5092, in _load_records_write
    self.write(values)
  File "/home/odoo/src/odoo/19.0/addons/account/models/account_account.py", line 1045, in write
    self.filtered(lambda r: r.reconcile)._toggle_reconcile_to_false()
  File "/home/odoo/src/odoo/19.0/addons/account/models/account_account.py", line 975, in _toggle_reconcile_to_false
    raise UserError(_('You cannot switch an account to prevent the reconciliation '
odoo.exceptions.UserError: You cannot switch an account to prevent the reconciliation if some partial reconciliations are still pending.
```

</details>

<h2>Solution</h2>

I have sanitized the dict `data` using the `_pre_reload_data` method, so that the traceback does not appear anymore when upgrading. 

<h3>Notes</h3>

`_pre_reload_data` method sanitizes the dict `data` by avoiding the creation of duplicated accounts, the creation of duplicated fields for a given record, the toggling of the `reconcilable` flag, etcs.


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

Forward-Port-Of: odoo/odoo#257006

**Problem:**
If a vendor bill associated with a project through its analytic distribution has lines with negative subtotals, those lines are not considered in the project profitability report. An example use case is a downpayment invoice, followed by a final invoice with the downpayment amount deducted.

**Steps to Reproduce:**
- Ensure project_purchase is not installed
- Create a new project with "Billable" enabled
- Go to the project settings and create an analytic account
- Create and post a vendor bill with a line labeled "downpayment", the analytic account set, and a unit price of 5
- Duplicate the vendor bill, set the "downpayment" line unit price to -5, add a line labeled "product" with the analytic account set and a unit price of 10, and post the bill

-> Go to the project updates and see that the vendor bill costs is wrong (15)

**Solution:**
A similar bug affecting customer invoices was resolved in PR #130992. AMLs with non-zero subtotals should be considered, so the domain is adjusted accordingly.

opw-6172523

Forward-Port-Of: odoo/odoo#265378

Currently, if you refund an order made on the customer account with the customer account as well, you can still see the order in the list of orders to settle.

Steps to reproduce:
-------------------
* Open shop
* Make an order using the customer account for a customer, don't invoice it
* Refund one of the order using the customer account, don't invoice it
* Make a new order using the customer account
* In the customer list, find the customer used and select "Settle Orders"
> The 2 orders are present in the list

Why the fix:
------------
Originally the list would only show the orders for chich the customers have due (>0).
https://github.com/odoo/enterprise/commit/bf4b6043b999b4a081b1afa73fc4113bf4db28f8

But recently the code we also see the refunds in the list as well.
https://github.com/odoo/enterprise/commit/12af23d5382e972facfaa999e4c5ab30c97e8d1f

However this new behavior is not visible if, with the refund, the customer account temporarily falls to 0.

So currently we have some refunds that impact the amount to settle and some that don't. Originally we were thinking that either we should show all refunds in that list (given they use the customer account) or we shouldn't show any as it was previously. Both solutions are not ideal.
* Showing them all would get the list bigger than it is and would require the customer to select the order and its refund(s) and settle them together. Since refunds are not usually done right after the order they would not be close it that list. However this solution would enable the option to remove the orders from the list requiring a few step from the customer.
* Showing none isn't idea either with this use case as it means that we still see orders that were cancelled out by their refunds. To remove to order the customer has two options. Either going backend and searching the order and its refund(s)
and invoice them, either settling the order but that means that now there's money deposited on the customer account.

Any of the two option isn't perfect a it still requires manual intervention from the customer and wouldn't work on previous data. Creating a server action to correct those data wouldn't have been feasible either.

Instead, the approach we're taking is the following: When loading the list of order to settle we want to remove the orders and the potential refunds were the customer account is evened out.

We only need to look at the orders of the partners that contains refunds for which the customer account was used. If the sum of the transactions made on the customer account is 0 we can say that the order and its refunds have cancelled out each other (in terms of customer account) and we don't show them if the list of orders remaining to settle.

opw-6170830

Description:

- The `.o_sign_template_tags_and_save` container relied on a hardcoded vertical offset (`top: 65px`) while being absolutely positioned. This assumed a fixed control panel height and caused the tags container to overlap with the header content when the neutralized red header bar expanded to multiple lines due to longer translated strings.
- Replaced `top: 65px` with `top: auto` to remove the dependency on a fixed vertical offset and allow the element to be positioned according to its computed static position.
- Reduced the height of `.o_field_widget.o_field_many2many_tags` from `50px` to `35px` to better fit the available space within the header area and prevent visual overlap between tag rows and surrounding elements.
- This change preserves the existing positioning strategy while making the layout resilient to variable header heights caused by translations and other content-dependent UI variations.

19 - https://github.com/odoo/enterprise/blob/3db8db2eac3dff1485c6a1c977c80e573bfe6cab/sign/static/src/scss/sign_backend.scss#L486

Before fix:
<img width="1874" height="443" alt="image" src="https://github.com/user-attachments/assets/196feab3-3460-4ed9-9f57-d7744e9c4e4b" />

After fix:
<img width="1319" height="412" alt="image" src="https://github.com/user-attachments/assets/93ae5bcd-f0f0-4999-9cf7-f83b82d689ac" />

### 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

**Step to reproduce :**

1. Create a deliverable product with a sales tax.
2. Create another product with a different sales tax.
3. Publish both products on the eCommerce website.
4. Create a discount program.
5. Add both products to the shopping cart.
6. Apply the discount code.
7. Proceed to checkout.

**Issue :**

Applying a discount on multiple products with different taxes causes an infinite reload cycle during checkout.

**Reason :**

The reload is supposed to sync the discount lines in the back-end with the discount lines displayed during checkout. If the number of lines don't match, a reload is triggered.
https://github.com/odoo/odoo/blob/18.0/addons/website_sale_loyalty/static/src/js/checkout.js#L22-L24

After the fix introduced in:
https://github.com/odoo/odoo/pull/248215

However, when a discount is applied to products with different taxes, the corresponding reward lines are still categorized as `discounted_lines` instead of `groupable_lines`. As a result, they continue to be processed individually rather than being grouped by reward.
    
This leads to a mismatch between the backend, which generates one discount line per tax combination, and the frontend, which expects a single discount entry per reward. Consequently, the checkout page continuously reloads while attempting to synchronize both states.
    
**Solution:**
    
When a discount applies to products with different tax configurations, the corresponding reward lines should be included in `groupable_lines` rather than `discounted_lines`. This ensures that discount lines are grouped by
`reward_id` consistently on both the frontend and backend, preventing the checkout reload loop.

opw-6210411

**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

**Problem:**
If a vendor bill associated with a project through its analytic distribution has lines with negative subtotals, those lines are not considered in the project profitability report. An example use case is a downpayment invoice, followed by a final invoice with the downpayment amount deducted.

**Steps to Reproduce:**
- Ensure project_purchase is not installed
- Create a new project with "Billable" enabled
- Go to the project settings and create an analytic account
- Create and post a vendor bill with a line labeled "downpayment", the analytic account set, and a unit price of 5
- Duplicate the vendor bill, set the "downpayment" line unit price to -5, add a line labeled "product" with the analytic account set and a unit price of 10, and post the bill

-> Go to the project updates and see that the vendor bill costs is wrong (15)

**Solution:**
A similar bug affecting customer invoices was resolved in PR #130992. AMLs with non-zero subtotals should be considered, so the domain is adjusted accordingly.

opw-6172523

Forward-Port-Of: odoo/odoo#265378

**Problem:**
If a vendor bill associated with a project through its analytic distribution has lines with negative subtotals, those lines are not considered in the project profitability report. An example use case is a downpayment invoice, followed by a final invoice with the downpayment amount deducted.

**Steps to Reproduce:**
- Ensure project_purchase is not installed
- Create a new project with "Billable" enabled
- Go to the project settings and create an analytic account
- Create and post a vendor bill with a line labeled "downpayment", the analytic account set, and a unit price of 5
- Duplicate the vendor bill, set the "downpayment" line unit price to -5, add a line labeled "product" with the analytic account set and a unit price of 10, and post the bill

-> Go to the project updates and see that the vendor bill costs is wrong (15)

**Solution:**
A similar bug affecting customer invoices was resolved in PR #130992. AMLs with non-zero subtotals should be considered, so the domain is adjusted accordingly.

opw-6172523

**Steps to reproduce:**
- In the contact app, chose your company
- Go to the Accounting tab
- Create a bank account and check "Send Money"
- Create a partner, create a bank account for it
- Do not Check the "Send Money"
- Go to the POS, click on a product and refund it 100% to make the price 0
- Chose the partner we created as the client and ask for an invoice
- Try to pay, the account is not trusted

**Why the fix:**

With this same steps, if we make a normal order with a price different than zero, it will work. But if the price is negative,
we will get the same error.

This happens because the *partner_bank_id* is chosen depending on if this is a refund or not. With an amount of zero, the order is considered to be a refund, and we chose the partner's partner_bank_id, which is not trusted.

On a normal positive flow, we chose the company's which is trusted, so we can send the money and it works.

This does not make sense to assume a zero amounted order is a refund, because when we invoice something that is zero or greater, we get an invoice, but only for the *partner_bank_id* we chose it as if it was a credit note.

So we should take the partner's *partner_bank_id* for every order that has a strictly negative amount, and take the company's for every order that is zero or positive.

Another way to fix this would be to backport this commit that also resolves this issue starting in 18.0 by adding a fallback to the company's *partner_bank_id*, but it might be a bit much of a change for version 17.0 https://github.com/odoo/odoo/commit/7e63991dceb6e443b950e6a1b94454a82d5668c7

opw-6005384

**Problem:**
On the /shop page, the "Fill" option in the web editor (cover/contain toggle on product card images) appears clickable but has no visible effect on the product thumbnails.

**Steps to reproduce:**
1. Install website_sale and open /shop.
2. Open the web editor and select the shop page.
3. Locate the "Fill" button group in the right panel (with the two svg icons).
4. Click the alternate option to switch between cover and contain.
5. Observe that the product card thumbnails do not change appearance.

**Current behavior:**
The toggle flips the `o_wsale_context_thumb_cover` class on the products table (and the activation of the `products_thumb_cover` view), but the product images keep rendering with `object-fit: contain` regardless of the toggle state.

**Expected behavior:**
The image fill mode follows the toggle:
- "cover" option active   → product image uses `object-fit: cover`
- "cover" option inactive → product image uses `object-fit: contain`

**Cause of the issue:**
The product image template renders the img with the `object-fit-contain` utility class, and the local SCSS rule declares
`.object-fit-contain { object-fit: contain !important; }`. The CSS variable `--o-wsale-card-thumb-fill-mode` (set to `cover` by `.o_wsale_context_thumb_cover`) does cascade down to the img, but the non-variable, `!important` rule on the utility class always wins, so the variable-driven rule
`object-fit: var(--o-wsale-card-thumb-fill-mode, contain)` is silently overridden and the toggle becomes inert.

**Fix:**
Making the `.object-fit-contain` rule read the same CSS variable lets the existing toggle mechanism take effect without changing any template or removing the utility class. Outside the `.o_wsale_context_thumb_cover` context the variable is undefined, so the `var(..., contain)` fallback preserves the prior `contain` behavior for any other consumer of the class. This keeps the change to a single SCSS line, with no XML touched and no other CSS class semantics altered.

opw-6231432