Steps to reproduce:
- Argentinean company, Responsable Inscripto (l10n_ar_pos installed)
- A posted customer invoice with VAT, partially paid
- In the PoS, pick the customer, "Settle invoices", select that invoice, pay the balance by bank transfer and validate

Issue:
Validation fails with "There should be a single tax from the "VAT" tax group per line, but this is not the case for line ..." and the settlement cannot be recorded at all. The invoice being settled is correct; the rejected line belongs to a second invoice the PoS creates for the settlement itself.

Cause:
`setToInvoice` already refuses to invoice a settlement, but its condition, `is_settling_account and no line`, only describes a deposit: the deposit line is added at validation. When settling a due or an invoice, `is_settling_account` stays false and the order does carry lines - the settle lines - so the guard never fires. l10n_ar_pos then sets `to_invoice` on mount, as a sale must generate an electronic document in AR, and the settle line, untaxed on purpose since it pays an existing document rather than selling anything, reaches `_check_argentinean_invoice_taxes`.

Fix:
Refuse the flag as well when every line is a settle line. Such an order generates an empty document - all its lines, the receivable one included, have a zero balance - so it records nothing and only consumes a document number, which in AR means an AFIP number for a zero-amount invoice. An order that also sells something keeps its invoice, since the sale still has to be reported. Reconciliation is unaffected: it happens in `_reconcile_account_move_lines` at session close, and is already covered for both invoiced and non-invoiced settlement orders.

opw-6464675

Forward-Port-Of: odoo/enterprise#128975

Steps:
1. Turn on AvaTax for a company (connect it to Avalara).
2. In Settings > General Settings > Invoicing, set the Document Layout to Boxed (Box), just for a clear view.
3. Create a customer invoice:
   - Use the customer with an AvaTax fiscal position and proper address details.
   - Add a product with an AvaTax category.
   - Add a section line (a divider/heading row).
   - Compute Taxes for the AvaTax.
4. Print the invoice as a PDF.
5. Look at the section/divider row. Its cell border does not line up with the other rows. On longer invoices, this can also cause a big blank gap at the bottom of a page.

Cause:
When an invoice is computed by AvaTax, the Taxes column is hidden from the PDF (this is intentional, since AvaTax shows tax differently).

But a different part of the same template decides how wide the section row should be. This part does not know the Taxes column was hidden, so it still counts it. That makes the section row's width wrong by one column, which breaks the table layout in the PDF.

Fix:
Instead of hiding the Taxes column only in one place, fix it at the source: the variable that decides (does this invoice show a Taxes column) now also checks if the invoice is an AvaTax invoice. Every other part of the template that uses this variable (the header, the tax cells, and the section row width) automatically gets the right answer, since they all read from the same place.

Result:
- Section rows on AvaTax invoices now have the correct width.

opw - 6455674

Forward-Port-Of: odoo/enterprise#129097

Description of the issue/feature this PR addresses:

The unread counter feeding the PWA app badge is written to the `odoo-mail-unread-db`
IndexedDB database, through a connection opened once, at module load, and cached for the
life of the page by the bundled idb-keyval (3.2.0), which cannot reopen it. When the
browser drops the origin's storage (eviction under disk pressure, site data cleared, a
privacy extension purging it), that connection is closed for good, and as
`updateAppBadge()` discards the promise returned by `idbKeyval.set()`, the rejection
reaches the user as a client error dialog.

Reported in production on a backend tab left open overnight (Firefox, 19.0):

```
UncaughtPromiseError > InvalidStateError
Uncaught Promise > IDBDatabase.transaction: Can't start a transaction on a closed database
```

Reproduced on a demo database below, with `?debug=assets` so that the stack points at the
source: lines 23 and 24 of the vendored idb-keyval are the `db.transaction()` call of
`_withIDBStore`, on the connection cached at module load.

<img width="1600" height="590" alt="error-dialog-debug" src="https://github.com/user-attachments/assets/e2b1aa46-501a-43d4-b4c0-20def1f529ef" />

Current behavior before PR:

1. log into the backend and leave the tab open
2. in the devtools, Application > Storage, tick *only* "IndexedDB" and click "Clear site
   data", as the browser itself does when it evicts the origin (the session cookie is left
   untouched, so the tab keeps working)
3. receive a message, or do anything else that changes the unread counter

The dialog opens, and opens again on every counter update for the whole life of the tab,
since the dead connection is never replaced; the counter is not saved any more either.

Two variants of the same code: the write also rejects, without anything being cleared,
when the origin runs out of storage quota (`QuotaExceededError`), and when the browser
forbids storage for the origin, `indexedDB.open()` throws during module evaluation, so
`store_service_patch.js` fails to load entirely.

Desired behavior after PR is merged:

The store is opened lazily, dropped whenever saving the counter fails, and the write is
retried once on a new connection: a single counter update after the connection was closed
saves it again. Opening the database is guarded too, for the synchronous throw. When the
retry fails as well the error is ignored, the app badge being cosmetic.

`mail/static/tests/web/app_badge.test.js` covers the retry, the recovery of a permanently
closed connection, and the database that cannot be opened at all. The three tests fail on
the current code with the uncaught `IDBDatabase.transaction` error.

Introduced in 19.0 by c04c4cb715902fe95618a15e18233cd001bdb304, and identical from
saas-19.1 to master, hence this PR against 19.0.

The corporate CLA for ERPVibe Limited is submitted in #283477.

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

Forward-Port-Of: odoo/odoo#283480

**Problem:**
Deleting one task of a recurrence suite ends the recurrence, but the tasks that stay behind keep the "Recurrent" option ticked. They look recurrent while no recurrence exists any more, so closing one of them never produces the next occurrence.

**Steps to reproduce:**
1. Create a project with "Recurring Tasks" enabled
2. Create a task, tick "Recurrent" and mark it as done
3. Repeat on each generated occurrence until 3 or 4 tasks exist
4. Delete the last generated task
5. Open one of the tasks left in the suite

**Current behavior:**
The remaining tasks still show "Recurrent" ticked, but marking one as done creates no new occurrence and the recurring tasks smart button is empty.

**Expected behavior:**
Ending the recurrence should turn the "Recurrent" option off on every task that was part of it.

**Cause of the issue:**
`unlink` deletes the `project.task.recurrence` when the last task of the suite is removed, and `recurrence_id` is set to NULL on the other tasks by the database. Nothing resets their `recurring_task` boolean, so it stays `True` with no recurrence behind it. The two other places that end a recurrence, `write` and `action_unlink_recurrence`, already clear the flag on the whole suite.

**Fix:**
Aligning `unlink` with those two paths keeps a single meaning for `recurring_task`: it is only ticked while a recurrence actually exists. The suite has to be read before the recurrence is deleted, since the one2many is empty afterwards, and the tasks of the batch being deleted are left out so that no write lands on records that are about to disappear.

opw-6425292

Forward-Port-Of: odoo/odoo#282535

Issue
-----
When adding all of the catalog's suggestions at once, the uom specified on the product's vendor lines is not respected.

Steps to reproduce
-----
- Create a product
	- Add a vendor line in a different uom
- Create a past outgoing shipment of 100 of the product
- Create a PO (same vendor as vendor line)
	- Open the Catalog
	- Click "Add All" in the suggestion section on the left
- Go back to the PO

> The product is in units instead of the different uom

Cause
-----
Clicking the button calls `action_purchase_order_suggest` in Python directly

https://github.com/odoo/odoo/blob/3aec1c317aad547b1ad0c85a21cc53f735c5cbfd/addons/purchase_stock/models/purchase_order.py#L131-L134

whereas clicking on a product will go through `addProduct` in JS

https://github.com/odoo/odoo/blob/3aec1c317aad547b1ad0c85a21cc53f735c5cbfd/addons/purchase_stock/static/src/product_catalog/record/kanban_record.js#L20-L28

Which leads to `_update_order_line_info` where the purchase line is created

https://github.com/odoo/odoo/blob/f59783d43f891fea14d03f67d7c017d7ffbbe5a7/addons/purchase/models/purchase_order.py#L1322-L1328

The uom is then retrieved in the create call through `_suggest_quantity`

https://github.com/odoo/odoo/blob/f59783d43f891fea14d03f67d7c017d7ffbbe5a7/addons/purchase/models/purchase_order_line.py#L547-L549

Other issue
-----
The quantity of the product also doesn't match the suggestion since the product `suggested_qty` is in the product's uom and not the vendor ones.

-----
Ticket:
opw-6417665

Forward-Port-Of: odoo/odoo#280934

Currently, if you refund an order fro the backend it is possible to modify the qty as if to refund more than the original order qty.

Steps to reproduce:
-------------------
* Make an order from the shop (1 product, qty 1)
* Validate the order
* Go backend
* Find the order and select the refund button
* Change qty from -1 to -3
* Save and continue the refund process
> No problem refunding more than the original quantity

Why the fix:
------------
In the frontend we cannot refund more than the original quantity, we assume the same should be in the backend process.

The most simple way to do this is by doing a difference between the quantity from the original order and all the refund lines linked.

From `self.refunded_orderline_id.refund_orderline_ids` we need to exclude the line that represents self as it holds the quantity before the onchange and we care about the quantity we're trying to write not the previous (allegedly correct).

opw-6328635

Forward-Port-Of: odoo/odoo#281405

Steps to reproduce:
- Create a pricelist with a rule applied on a product category and make it available in the PoS
- Open a PoS session
- From the backend, create a product in a new category covered by such a rule
- Back in the PoS, find that product through Search > Search more and add it to the order

Issue:
The product is priced at its sale price, the pricelist rule set on its category is ignored.

Cause:
A product that is not part of the initial payload is loaded on the fly by load_product_from_pos, which sends back the rules returned by get_pos_ui_product_pricelist_item_by_product. That domain only matches the rules set on the template or on the variant, never the ones set on a product category, and the payload carries no product.category record either. The client therefore has neither the rule nor the category: parentCategories walks categ_id, which resolves to nothing, so getCategoryRulesIds returns no rule and getPrice falls back to the sale price.

This stayed unnoticed because product.category is fully loaded when the session starts, along with every category rule, so only the categories created after the session was opened are missing.

Fix:
Send the categories of the loaded products, since a rule set on a parent category applies to its children - along with the products, and match the rules set on those categories in get_pos_ui_product_pricelist_item_by_product.

The initial loading domain of product.pricelist.item no longer filters the category rules on the loaded categories: such a rule has to be loaded whatever the products sent to the client are, since a product of that category may be loaded later on.

opw-6477745

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

Forward-Port-Of: odoo/odoo#284660

### Issue before this commit:
When a CFDI invoice was sent through a mass action (Send & Print executed by OdooBot), the unit of measure in the generated CFDI appeared in English instead of the configured language (e.g. Spanish.

### Steps to reproduce the issue:
1.Download Accounting, Contacts and l10n_mx
2. Switch to Spanish (MX) language
3. Set the language of "Inmoviliaria CVA" and "XENON INDUSTRIAL ARTICLES" to Spanish (MX)
4. In contacts select Archived in filters and switch OdooBot language to Spanish (MX)
5. Create and confirm two invoices in the database, one for each customer but don't send these invoices
6. Go to the list view and select these two invoices, and click on "Send and print" and select CFDI
7. Check any of the XML files generated in any of the invoices (in the CFDI tab of the invoice)
8. See that the UoM in the XML file, will be set in english rather than Spanish (MX)

### Cause of the issue:
The context under which the batch action runs does not contain the lang key. As a result, translated fields (such as product_uom_id.name) were read in the source language (English) instead of the executing user's language, because nothing in the CFDI generation chain explicitly forced the correct lang into the context.

### Reason to introduce the fix:
A CFDI must always report translated fields in the correct language. The fix ensures the invoice is read with the executing user's language when the context doesn't already specify one, so translated fields are consistently correct across both flows.

opw-6399860

Forward-Port-Of: odoo/enterprise#125698

The "Import File" button on the dashboard card only shows up for bank
journals. Credit card journals are treated the same way as bank journals
pretty much everywhere else: the dashboard card itself, the statements list,
the "Transaction Feeds" setting on the journal form (where you can pick the
file import option), and even `create_document_from_attachment` in this
module, which already accepts them. So you end up with a credit card journal
set to import files but nothing on its card to actually do it, and people
assume the feature is simply not there.

Show the button on credit card journals too.

Steps to reproduce:
- Install account_bank_statement_import_csv (or any other import format)
- Create a "Credit Card" journal and set its Transaction Feeds to the file import option
- Go to the Accounting dashboard
- The bank journal card has an "Import File" button, the credit card one doesn't

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

Forward-Port-Of: odoo/enterprise#129546

**Steps to reproduce:**
- Install the `l10n_se` module and switch to a SE Company.
- Navigate to Invoicing > Configuration > Taxes.
- Create a tax and set the tax grid to `se_42`.
- Create and confirm an invoice for a Swedish customer using this tax.
- Navigate to Reporting > Tax Report.
- Check the amount of `Fält 42` under `Block E`.

**Observation:**
The `Fält 42 – Övrig försäljning m.m.` field shows the amount as negative 
instead of positive.

**Root Cause:**
At [1], the `se_42` formula is missing the negative sign.

These lines were missed by the `tax_tag_invert` revamp done in https://github.com/odoo/odoo/commit/17a6117ed88c29b5bc4db0c872bcdbc109a7d98b.

**Fix:**
This commit adds the missing negative sign to the `se_42` formula, 
ensuring that the amount for `Fält 42` is displayed as positive in the 
Swedish tax report, similar to [2].

[1]:
https://github.com/odoo/odoo/blob/a56038c97e807388772ccc3a794cf0bf658a2076/addons/l10n_se/data/account_tax_report_data.xml#L356-L368

[2]:
https://github.com/odoo/odoo/commit/b8125f38e80c1977eedda5fc6b9466ece5e9fd89

opw-6457529

Forward-Port-Of: odoo/odoo#281925

### Steps to Reproduce:
1). Install l10n_vn_edi_viettel ('Vietnam E-Invoicing') module in v18. 
2). Migrate the database in any version above v18. 
3). AccessError will appear while generating ('Send to SInvoice') on invoice for non-admin users.

### Issue:
- In v18, users were able to send and generate documents via (Send to SInvoice). Since v18.1 onwards, field access [check] is enforced during this flow, and since `l10n_vn_edi_username` is restricted to admin users only [here], non-admin users hit an AccessError as soon as
`_l10n_vn_edi_get_credentials_company` reads this field on`res.company`.

```py
You do not have enough rights to access the field "l10n_vn_edi_username" on Companies (res.company). Please contact your system administrator.

Operation: read
User: 12
Groups: allowed for groups 'Role / Administrator'
```

### Solution:
- This commit fixes the issue by adding a `sudo()` call on the company inside [_l10n_vn_edi_get_credentials_company] itself, so that non-admin users can successfully send and generate documents like in the previous version, without any hassle.

[check]: https://github.com/odoo/odoo/blob/5ca10578a2fd1b40cd371ed5ad20c1654dfe54d3/odoo/orm/models.py#L3384
[here]: https://github.com/odoo/odoo/blob/5ca10578a2fd1b40cd371ed5ad20c1654dfe54d3/addons/l10n_vn_edi_viettel/models/res_company.py#L9
[_l10n_vn_edi_get_credentials_company]: https://github.com/odoo/odoo/blob/ecc267a231958c2dd99a7287c6bd1adbdbd22965/addons/l10n_vn_edi_viettel/models/account_move.py#L885

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

Forward-Port-Of: odoo/odoo#281396

Currently, an error occurs when trying to fill in the company details from the General Ledger.

Steps to Reproduce:
 - Install `l10n_ae_faf` with demo data.
 - Switch to the `AE Company`.
 - Go to `Accounting` > `Reporting` > `Ledgers` > `General Ledger`.
 - Click on `your company` in the company details warning.

`AttributeError: The method 'account.report.action_fill_company_details' does not exist`

In this commit, the company details warning was added to the l10n_ae_faf module, similar to account_saft. 
However, the action_fill_company_details method is only defined in account_saft, which is not a 
dependency of l10n_ae_faf. Therefore, when the user clicks on "your company" to open the company 
form [1], the method is not available and an error is raised.

This commit ensures that action_fill_company_details is added to l10n_ae_faf so that clicking on 
`your company` opens the company form, as it does in account_saft.

[this commit]: https://github.com/odoo/enterprise/commit/dffc4412df42507457810a0895be3b8f4dc7ec3f

[1]- https://github.com/odoo/enterprise/blob/c8c2f13b7fd17e215044fc62774f2b4a378aaf8c/l10n_ae_faf/static/src/components/general_ledger/filters/warnings.xml#L3-L10

sentry-7676719103

Forward-Port-Of: odoo/enterprise#128327