## Current behavior:
When rescheduling a task in Project's Gantt chart view, if user switches to a different browser tab using the Ctrl shortcuts (either Ctrl + Tab, Ctrl + Shift + Tab or Ctrl + PgUp / PgDn), and navigate back to Gantt chart view, the task will get duplicated unexpectedly when getting dragged around even when the Ctrl button is released

## Expected behavior:
Dropping a task without Ctrl held should reschedule even after a tab switch using the Ctrl shortcuts

## Steps to reproduce:
1. Install `project` module
2. Create a project and switch to Gantt chart view
3. Hold Ctrl and start dragging a task while switching browser tab with Ctrl+Tab, Ctrl+Shift+Tab, or Ctrl+PgUp/PgDn
4. Return to the Gantt tab and drop the task without holding Ctrl
5. The task is duplicated instead of rescheduled

## Cause of the issue:
Copy and reschedule actions are tracked internally via interaction.dragAction, updated only on window keydown/keyup for Control. Currently, we're not keeping track of the `visibilitychange` event when switching tabs, causing the state of `ctrlPressed` to stale after a tab change, causing the dragAction to stay on copy mode

## Fix:
Reset `dragAction` and `ctrlPressed` on document's `visibilitychange` when the tab has been changed

opw-6298440

Marketplace orders with discount lines could not match the
platform total: Odoo accumulated a small rounding residue vs Shopee's
total_amount / Lazada's order price.

sale_shopee
-----------
Changes:
- Fetch buyer-side escrow amounts via `_fetch_order_income` and pass them
  through `self.env.context` (`order_income`).
- Build item lines from the buyer-paid item price with `discount=0` and a
  recomputed tax-exclusive `price_unit`.
- Distribute order-level discounts (seller/platform vouchers and coins) as
  dedicated negative lines per product tax group via
  `_prepare_discount_lines_values`.
- Append a shipping line from `buyer_paid_shipping_fee` with fiscal-position
  mapped taxes.
- Reconcile any leftover residue with `_adjust_order_total` using a single
  tax-free amount-adjustment line.
- Register `default_discount_product` and configure it on upgrade (v1.1).


sale_lazada
-----------
- Port the same reconciliation model as shopee: reconciled line specs, discount=0 with
  discounted unit from paid_price, shipping line from shipping_fee, order-level
  "Discount line" distributed at order-level.

task-6112062

Steps to reproduce:
-------------------
1. Install pos_avatax.
2. Enable Avatax in accounting, and use the testing credentials of Odoo.
3. Enable "Use AvaTax API" and "Detect Automatically" on the default fiscal position (or another fiscal position available in PoS).
4. In a PoS shop, enable "AvaTax PoS Integration"
5. Find a product sell in that PoS, and assign it an "Avatax Category"
6. Open that PoS, add the prodct of step 5, and choose a customer (make sure the fiscal position of step 3 is being used).

Observation: Error modal "Error while loading Avatax taxes", and error
in the terminal `KeyError: 'base_line'`.

Why it's happening:
-------------------
Commit 0404086db567 changed the return of
`_get_line_data_for_external_taxes`. Before, pos was returning something with `id`, `qty`, `price_subtotal` etc. After the commit the return should have a `base_line` key (the accounting base line we get from `_prepare_base_line_for_taxes_computation`).

But that commit forgot to update the override in pos. So when avatax tries to read `line_data['base_line']` we get the KeyError.

The fix:
--------
Update the override in pos to return the new format, same way `sale_external_tax` is already doing it for sale orders.

opw-6244141

After applying the community fix, a new issue appears in enterprise.

**Steps to reproduce:**
- Install the `l10n_ar_edi` module.
- Go to Customers and create a new customer with:
  - Country: Argentina
  - Identification Type: `Passport`
  - Identification Number: `1234567890a`
  - AFIP Responsibility Type: `Consumidor Final`
- Create a new invoice for this customer with:
  - Journal: `Electronic Invoice (FE)`
  - Document Type: `(6) INVOICES B`
- Try to confirm the invoice.

**Error:**
ValueError: invalid literal for int() with base 10: '1234567890a'

**Expected behaviour:**
For Argentinean contacts with AFIP Responsibility Type `Consumidor Final`, 
the identification type must be `DNI` or `CUIL/CUIT`. If another 
identification type is used, the user should receive a proper warning 
instead of a traceback. (see [1])

**Root Cause:**
After the community fix, `_get_id_number_sanitize()` can return an alphanumeric 
value, which is later converted with `int()` at [2] and [3], causing an error.

**Fix:**
This commit adds an explicit validation for Argentinean contacts with 
AFIP Responsibility Type Consumidor Final before converting the 
identification number to an integer, ensuring the user receives the 
proper warning message.

[1]:
https://www.odoo.com/mail/message/1118392033

[2]:
https://github.com/odoo/enterprise/blob/064812dd9f1074f287fee677ba35ea4aeef3ab3f/l10n_ar_edi/models/account_move.py#L780-L798

[3]:
https://github.com/odoo/enterprise/blob/064812dd9f1074f287fee677ba35ea4aeef3ab3f/l10n_ar_edi/models/account_move.py#L927-L931

Related community PR: https://github.com/odoo/odoo/pull/272651

opw-6333998

Forward-Port-Of: odoo/enterprise#123729

**Problem:**
When a template is restricted to a department, appraisals for employees of that department do not use it — a generic (global) template is used instead.

**Steps to reproduce:**
1. Create an appraisal template and restrict it to a department.
2. Make sure at least one global (no department) template also exists.
3. Open a new appraisal and select an employee of that department.
4. Observe the appraisal template stays on the global one.

**Current behavior:**
The global template that was auto-selected before an employee was chosen is kept, ignoring the department-restricted template.

**Expected behavior:**
The template restricted to the employee's department is selected.

**Cause of the issue:**
On a new appraisal the template is computed before an employee (and therefore a department) is set, so a global template is pre-selected. When the employee is then chosen, `_compute_appraisal_template` reruns but the `appraisal.appraisal_template_id or ...` clause short-circuits on the already set global template and never falls through to the department's template.

**Fix:**
Evaluating the department's template before the existing value ensures a department-restricted template takes precedence over a template that was only auto-selected as a default. The existing value is still preserved when the department has no template of its own, so deliberate choices are untouched.

opw-6293936

**Steps to reproduce:**
* Configure a Swiss company with the Swiss accounting localization.
* Install `account_sepa`.
* Configure a bank journal with a valid Swiss **QR-IBAN**.
* Create a vendor with a valid Swiss bank account.
* Under **Accounting -> Configuration -> Settings** enable QR Payments.
* Go to the vendor and enter the correct QR-IBAN number under the Accounting Section.
* Navigate to **Accounting -> Configuration -> Journals** and in the **bank** journal, add the 
  account number of  QR-IBAN.
* Create and post a vendor payment using the bank journal.
* Set the payment reference (`ref`) to contain the `°` character.
* Add the payment to a batch payment and generate the ISO 20022 payment file.
* Inspect the generated XML.

**Observed Behaviour:**
 The `°` character is preserved in the payment reference for QR-IBAN payments, producing an ISO 20022 file that 
 may be rejected by Swiss banks because it does not comply with the EPC minimum character set.

**Cause:**
 The QR-IBAN branch validates the structured reference before sanitizing it,
 allowing unsupported characters to remain in the generated XML.

**Fix:**
 Sanitize the payment reference before validating it as a QR structured reference, ensuring invalid characters 
 are removed while preserving valid QR references.

opw - 6350931

Forward-Port-Of: odoo/enterprise#124299
Forward-Port-Of: odoo/enterprise#123267

To reproduce the issue:

1) Initialize a company in Belgium, create the tax returns 2) Submit the VAT return from January
3) Open the lock date wizard. The tax lock date is January 31st. 4) Add a lock date exception removing the tax lock date just for you, for 5 min. 5) Reset January's return
6) Reopen the lock date wizard.
    ====> Your exception is still there, but the tax lock date for everyone has been reset to December 31st.

This is plain wrong. Resetting a return should not automatically reopen the period for everyone. Lock dates exceptions/modifications are anyway required to reset the return ; they should pilot the whole flow. Nothing being magically hidden from the user means there can't be someone else mistakenly encoding something into the reopened period.

Another fix was required to make this one work: setting the tax lock date before submitting the return should work. In bigger environments, users might want to do that as a first step to reduce the number of people encoding data before actually doing the submission of the return. Therefore, the case where the tax lock date is already set at the date_to of the return when submitting it was supposed to be already supported, and allow the creation of the closing entry for that return, despite it being on the tax lock date. The test ensuring this was however badly written, and the feature didn't work: the closing was created at a later date than the lock date automatically, due to the Bills' Algorithm.

Forward-Port-Of: odoo/enterprise#124811

**Steps to reproduce:**
* Install the **l10n_pe_edi** module.
* Change the company currency to **USD**.
* Configure **Peruvian detraction** settings:
  * Set a **withholding percentage** on a product.
  * Set a **withholding code** on the same product.
* Create a customer invoice in **USD**.
* Set the **Operation Type** to **[1001] Operation Subject to Detraction**.
* Add the configured product to the invoice.
* Confirm the invoice, **send it to SUNAT** by *process now**, and generate the ZIP which has XML.

**Observed behavior:**
* The generated XML contains: `<cbc:Amount currencyID="PEN">116.82</cbc:Amount>` The `currencyID` is `PEN` but the amount is the raw USD value instead of being converted to PEN using the exchange rate.
* The PDF report also shows the withholding amount with the wrong currency symbol.

**Cause:**
* `_l10n_pe_edi_get_spot()` computed `spot['amount']` as `amount_total_signed * percent`, where `amount_total_signed` is stored in the **company currency**. When the company currency is PEN this works correctly, but when it is changed to USD the value is in USD while the XML node hardcodes `currencyID="PEN"`.
* `spot['currency']` was also set to `company_id.currency_id`, so the PDF rendered the amount with the wrong currency symbol.
* In `_add_invoice_payment_terms_nodes`, `spot_amount` was selected via `spot['amount'] if invoice.currency_id == invoice.company_id.currency_id` which relied on company currency being PEN as a proxy for the invoice being in PEN, breaking when company currency is USD.

**Fix:**
* In `_l10n_pe_edi_get_spot()`, compute `spot['amount']` by explicitly converting `amount_total` from the invoice currency to PEN using `currency_id._convert(..., env.ref('base.PEN'), ...)`, ensuring the detraction amount is always in PEN regardless of the company currency.
* Set `spot['currency']` to `env.ref('base.PEN')` so the PDF report always displays the withholding amount with the correct PEN symbol.
* In `_add_invoice_payment_terms_nodes`, always use `spot['spot_amount']` (invoice currency amount) for the `FormaPago`/`Cuota` arithmetic, since `spot['amount']` is now exclusively the PEN amount for the detraction XML node.

opw-6327571

Steps to reproduce:
- Post a Peruvian invoice so it is sent to SUNAT (directly or through Estela/Digiflow).
- SUNAT's sendBill call hangs and Odoo's request times out (ReadTimeout / ConnectionError), even though SUNAT actually finishes registering the document on its side a moment later.
- Odoo retries sending the same invoice (either automatically through the EDI cron, or manually). SUNAT now replies with a "document already exists" SOAP fault (code 1033/4000), since it processed the previous attempt.
- Odoo tries to recover from this by fetching the CDR through getStatusCdr, but SUNAT has not finished generating it yet, so the lookup also fails.

Cause of the issue:
_l10n_pe_edi_post_invoice_web_service() already has recovery logic for error codes 1033/4000: it calls _l10n_pe_edi_retrieve_cdr() to fetch the CDR and treat the invoice as sent. But when that lookup itself fails (CDR not generated yet), the resulting error keeps the 'blocking_level' set to 'error' from the original SOAP fault. Documents with blocking_level 'error' are excluded from the automatic EDI cron retries (see account.edi.document._cron_process_documents_web_services), so the invoice gets stuck needing a manual retry, which can lose the same race against SUNAT again and again.

Solution:
When the CDR can't be retrieved yet after a 1033/4000 duplicate error, mark the result as 'blocking_level': 'warning' instead of leaving it at 'error'. This keeps the invoice eligible for the automatic EDI cron retries, so Odoo keeps polling SUNAT until the CDR becomes available, instead of requiring manual intervention every time this race is lost.

opw-6393231