Issue:
----------------------------------------
There is a fiscal regime where the company is actually an individual but is authorized to generate documents.

Steps to reproduce:
----------------------------------------
- Install "l10n_mx_hr_payroll_account_edi"
- Change the current company fiscal regime to '621'
- Add an VAT of length 13 to the current company
- Add a CURP number on the current company
- In Payroll generate a payslip, validate it
- Post the Journal entry
- On the payslip, click "Generate CFDI"
- An error is returned, saying the Emisor:Curp applies to individuals

Cause:
----------------------------------------
An RFC of length 13 means that the sender is an individual. It's intended with the fiscal regime '621'.

We add the curp number in the CFDI XML only when `self.company_id.partner_id.is_company` is `False`. Since saas-19.1, `is_company` is computed to be truely if a VAT is present. So as soon as the VAT is entered, the CURP number is absent from the XML.

Solution:
----------------------------------------
We change the condition to add the CURP number in the XML: A VAT number of length 13 means the contact is an individual (12 for companies). This is what is used to validate the XML: if the vat is of length 13, then the curp number should be present.

opw-6351558

Forward-Port-Of: odoo/enterprise#124728
Forward-Port-Of: odoo/enterprise#124027

Steps to reproduce:
- install Timesheets
- create an employee for a user in company B
- switch to company A (where the user has no employee)
- the systray icon is hidden even though the user can
create timesheets in company B via the company selector

Current behavior:
the systray only checks the current company for a valid
employee, ignoring other selected companies.

Expected behavior:
the systray should be visible whenever the user can create
timesheets i.e. when they have an active employee in any
of the selected companies.

Issue:
the check used a stored boolean on `res.partner` that has no
company scope and becomes stale when an employee is archived
(the stored dependency does not re-fire). the timesheet
creation logic checks all selected companies for active
employees, but the systray did not mirror that.

Fix:
use `employee_ids` a `One2many` that checks all selected
companies and excludes archived employees, matching the
timesheet creation logic exactly.

task-6330539

Forward-Port-Of: odoo/enterprise#124761
Forward-Port-Of: odoo/enterprise#121730

Currently an error is generated when the user clicks on the AI
icon as per the below steps:

- Install `ai_app` 
- Go to `AI` > Configuration > Default Prompts
- Duplicate `Ask AI` record (`ai.composer`)
- An error occurs on clicking the `AI` icon on the navbar menu systray

Error: `ValueError: Expected singleton: ai.composer(4, 14)`

This issue was introduced during the refactoring in [1]. In the previous
implementation, the AI Composer search was executed with `limit=1` (see [2]),
ensuring that only a single composer record was returned. After the changes
in [1], the limit=1 constraint was removed (see [3]), causing the search to
return multiple composer records. As a result, the code now encounters
an error when it expects a single record.

This commit fixes the issue by adding `limit=1` to the AI Composer search,
ensuring that only a single record is returned.


[1]: https://github.com/odoo/enterprise/commit/800208fdc485b9e37f77648a01100b8eff118490
[2]: https://github.com/odoo/enterprise/blob/188dcc5078be7c7fee1a52f86505144d3b6309cf/ai/models/ai_composer.py#L71-L83
[3]: https://github.com/odoo/enterprise/blob/2972805fd1a4daacd7f1c47d5e3c7672e2aec61c/ai/models/ai_composer.py#L74-L77

Sentry-7549108967

Root cause:
WhatsApp reminders are logged as mail.message records on calendar.attendee, which is not a mail.thread. Deleting a calendar event or a partner removes the attendees through the database cascades on calendar.attendee.event_id and calendar.attendee.partner_id, which do not call calendar.attendee.unlink, so each reminder keeps a model and res_id pointing to an attendee that no longer exists.

mail.message access filters the related documents through exists() since https://github.com/odoo/odoo/commit/617d4a32409b730e0fb7d351553e4c6e10bf6c5f, so a reminder whose attendee is gone is no longer readable by anyone but its author or recipient. whatsapp.message.body reads mail.message.body without sudo, so opening WhatsApp > Messages raises an access error on the orphaned reminders, and the queue retry cron hits the same error and stops sending the rest of the queue.

Fix:
Read the related body with sudo. Orphaned messages are not specific to whatsapp, any model that is not a mail.thread keeps its messages after a record is deleted, so cleaning them up is a mail framework concern rather than a whatsapp one. One message the user cannot read should not block the whole message list. Who can read the body stays controlled by the access rights of whatsapp.message itself.

Steps to reproduce:
1. Install WhatsApp and configure an account
2. Create an Appointment Type with a WhatsApp reminder
3. Book an appointment to create the calendar event
4. Settings > Technical > Automation > Scheduled Actions > Calendar: Event Reminder > Run Manually so the reminder is sent
5. Open the calendar event and delete it with the trash icon, not Cancel
6. Open WhatsApp > Messages

=> Access error, the user has no access to the mail.message

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

**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) Create a company in Belgium
2) Instantiate its returns and review, submit and pay one of the VAT returns 3) Change the states_worklfow of the VAT return so that it only accepts "review" and "submit" stages, not "paid" anymore 4) Go to the list of returns, remove the TODO filter => traceback

The problem is here that the existing returns don't recompute their state when the workflow of the type is modified. In some cases, this is fine, but it others, it's annoying. In our example, the terminal state changed, so all the returns in that terminal stage should change their state to the new terminal one. "paid" is not an accepted value anymore, it should become "submitted".

Moreover, when the workflow is changed, the selection field actually containing the state must also change. As it is, it seems to work because "state" of account.return is stored, but the value it's based on (the workflow field) won't be consistent with it. It's not annoying now, but those inconsistencies could become a big source of trouble in the future (we know that from experience ... I'm looking at you, version 8 ! è-é).

This issue typically happens at upgrade. We had cases in FR and AE already. We solve that by a generic override of the write to sort things out when such change needs to happen. An upgrade PR will also be done to adapt the script so that we eventually solve the inconsistencies on dbs that have already migrated to 19.0.

Forward-Port-Of: odoo/enterprise#124144

Steps to reproduce:
1. Install Accounting and create an invoice for a customer which has a due date in the past
2. Make sure the payment term for the invoice is "Immediate Payment" and Send the invoice.
3. Open the contact form and click on the Customer Statement smart button
4. Exclude the invoice using the 'No Follow-Up' toggle
5. In the Accounting tab in the contact form, click on send
6. Open the internal link of the Content Template, go to the options tab and select
'Print Follow-up Letter' in Dynamic Reports
7. Save the configuration and send the email

Issue:
Excluded invoices still appeared as PDF attachments in the follow-up email and were merged into the printed follow-up letter PDF.

Why this happens:
Both `default_get` in `account_followup.manual_reminder` and `_get_invoices_to_print` in `res.partner` traversed `unreconciled_aml_ids` without filtering out lines where `no_followup = True`, so excluded invoices were included regardless.

opw-6310602

Forward-Port-Of: odoo/enterprise#124750
Forward-Port-Of: odoo/enterprise#122249

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

# How to reproduce
- Have a lot of reusable & locationless packages (e.g. > 10 000)
- Go to any transfer via the barcode application

# The issue
There is a very long loading time, even in local testing. The client of the tickets experiences loadings up to 120 seconds with 50k packages

# Cause
When opening a transfer, we load barcode data by doing an API call to `_get_stock_barcode_data` : https://github.com/odoo/enterprise/blob/fe058ef501767b7ed9758fc9264f664b32c6bae8/stock_barcode/models/stock_picking.py#L85

During this we preload a lot of records, notably packages : https://github.com/odoo/enterprise/blob/fe058ef501767b7ed9758fc9264f664b32c6bae8/stock_barcode/models/stock_picking.py#L128

The issue is that in the fields we read for the packages, two of them (`location_dest_id` & `contained_quant_ids`) have a `_read_group` in their compute (or in the compute of one of the fields they depend on) :
https://github.com/odoo/odoo/blob/625e6bcbd66c45ea2f699df14e2ea12e2e28a893/addons/stock/models/stock_package.py#L65 https://github.com/odoo/odoo/blob/625e6bcbd66c45ea2f699df14e2ea12e2e28a893/addons/stock/models/stock_package.py#L146

Fortunately, this does not mean that we make a query for every records. Instead, in Odoo, we fetch records in batch of 1000.

So, for the case of the client, every time he loads the database, the backend does 50 000 / 1000 x 2 = 100 queries, which hinders performance a lot

A [PERF] commit was done to limit the number of packages that are fetched base on a config parameter. The problem is that this parameter does not have a default value, so clients still end up with the problem.

[PERF]: https://github.com/odoo/enterprise/commit/efe18bc1ea479270e42846986d7ed449b0865617

# Proposed Solution
Add a default value for that config parameter. The exact value is up to discussion

opw-6200730

Forward-Port-Of: odoo/enterprise#123696

To reproduce the issue:

1) Create a company in Belgium
2) Instantiate its returns and review, submit and pay one of the VAT returns 3) Change the states_worklfow of the VAT return so that it only accepts "review" and "submit" stages, not "paid" anymore 4) Go to the list of returns, remove the TODO filter => traceback

The problem is here that the existing returns don't recompute their state when the workflow of the type is modified. In some cases, this is fine, but it others, it's annoying. In our example, the terminal state changed, so all the returns in that terminal stage should change their state to the new terminal one. "paid" is not an accepted value anymore, it should become "submitted".

Moreover, when the workflow is changed, the selection field actually containing the state must also change. As it is, it seems to work because "state" of account.return is stored, but the value it's based on (the workflow field) won't be consistent with it. It's not annoying now, but those inconsistencies could become a big source of trouble in the future (we know that from experience ... I'm looking at you, version 8 ! è-é).

This issue typically happens at upgrade. We had cases in FR and AE already. We solve that by a generic override of the write to sort things out when such change needs to happen. An upgrade PR will also be done to adapt the script so that we eventually solve the inconsistencies on dbs that have already migrated to 19.0.

Forward-Port-Of: odoo/enterprise#124144

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

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

Forward-Port-Of: odoo/enterprise#121377

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

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

Purpose: Implement the daily book export for Argentina which allows users to summarize and report journal entries of the same nature, such as all sales, to reduce
reporting every single invoice which incurs a cost per page.

Users can use the multi-ledger system to summarize the journal entries. Ledgers can be created and set on the journal. Journals of the same nature can share the same ledger. Then, the user can view and select which ledgers they want to export on the general ledger and then export. By default, all ledgers will be selected, until the user deselects ledgers.

A "Daily Book XLSX (AR)" button was added and
can be accessed in the dropdown of the cog menu.
Upon click, a wizard will pop up and it will display the starting entry number for the report. By default, it will display 1 if there's no history or the last entry number (that we store) + 1. The user can input their own number. Once the starting number is set, the XLSX file for the daily book will export.

task-5244083

Issue:
----------------------------------------
There is a fiscal regime where the company is actually an individual but is authorized to generate documents.

Steps to reproduce:
----------------------------------------
- Install "l10n_mx_hr_payroll_account_edi"
- Change the current company fiscal regime to '621'
- Add an VAT of length 13 to the current company
- Add a CURP number on the current company
- In Payroll generate a payslip, validate it
- Post the Journal entry
- On the payslip, click "Generate CFDI"
- An error is returned, saying the Emisor:Curp applies to individuals

Cause:
----------------------------------------
An RFC of length 13 means that the sender is an individual. It's intended with the fiscal regime '621'.

We add the curp number in the CFDI XML only when `self.company_id.partner_id.is_company` is `False`. Since saas-19.1, `is_company` is computed to be truely if a VAT is present. So as soon as the VAT is entered, the CURP number is absent from the XML.

Solution:
----------------------------------------
We change the condition to add the CURP number in the XML: A VAT number of length 13 means the contact is an individual (12 for companies). This is what is used to validate the XML: if the vat is of length 13, then the curp number should be present.

opw-6351558

Forward-Port-Of: odoo/enterprise#124868
Forward-Port-Of: odoo/enterprise#124027

Steps to reproduce:
- install Timesheets
- create an employee for a user in company B
- switch to company A (where the user has no employee)
- the systray icon is hidden even though the user can
create timesheets in company B via the company selector

Current behavior:
the systray only checks the current company for a valid
employee, ignoring other selected companies.

Expected behavior:
the systray should be visible whenever the user can create
timesheets i.e. when they have an active employee in any
of the selected companies.

Issue:
the check used a stored boolean on `res.partner` that has no
company scope and becomes stale when an employee is archived
(the stored dependency does not re-fire). the timesheet
creation logic checks all selected companies for active
employees, but the systray did not mirror that.

Fix:
use `employee_ids` a `One2many` that checks all selected
companies and excludes archived employees, matching the
timesheet creation logic exactly.

task-6330539

Forward-Port-Of: odoo/enterprise#124830
Forward-Port-Of: odoo/enterprise#121730

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