Steps to reproduce:
--------------------------
1. Install the Quality module.
2. Create a Quality Control Point with:
   * Control per: Control on Operation.
   * Operation: Receipts (set in the Operations field).
3. Create a Receipt containing one product.
4. Click the Mark as To Do button.
5. Add another product to the same Receipt and save it.

Observation:
--------------------------
Two quality checks are generated for the same picking, despite the tooltip indicating that only one check should be created per operation.

Issue:
--------------------------
No validation existed to verify whether an operation-based quality check had already been created for the picking when adding additional stock moves after confirmation.

Solution:
--------------------------
Add a check ensuring that if a quality check already exists for the same picking type and operation (with no product or category criteria), no additional operation-based quality checks are created.

opw-5249233

Forward-Port-Of: odoo/enterprise#101788
Forward-Port-Of: odoo/enterprise#100118

```
  File "/home/odoo/src/odoo/19.0/addons/account/models/ir_module.py", line 100, in _register_hook
    self.env.registry._delayed_account_translator(self.env)
  File "/home/odoo/src/odoo/19.0/addons/account/models/ir_module.py", line 90, in load_account_translations
    env['account.chart.template']._load_translations(langs=langs)
  File "/home/odoo/src/odoo/19.0/addons/account/models/chart_template.py", line 1449, in _load_translations
    ._get_chart_template_data(chart_template)
  File "/home/odoo/src/enterprise/19.0/account_accountant/models/account_chart_template.py", line 31, in _get_chart_template_data
    data = super()._get_chart_template_data(chart_template)
  File "/home/odoo/src/odoo/19.0/addons/account/models/chart_template.py", line 803, in _get_chart_template_data
    data = func(self, template_code)
  File "/home/odoo/src/odoo/19.0/addons/account/models/chart_template.py", line 59, in wrapper
    return func(*args, **kwargs)
  File "/home/odoo/src/enterprise/19.0/l10n_be_reports/models/account_chart_template.py", line 52, in _get_be_account_reconcile_model
    prepayment_communication = self.env['qr.code.payment.wizard']._be_company_vat_communication(self.env.company).replace('+++', '')
  File "/home/odoo/src/enterprise/19.0/l10n_be_reports/models/qr_code_payment_wizard.py", line 14, in _be_company_vat_communication
    number = int(vat)
ValueError: invalid literal for int() with base 10: 'LU19038918'
```
```sql
kmod_3311837=> select id,name,chart_template,parent_id from res_company;
 id |        name         | chart_template | parent_id
----+---------------------+----------------+-----------
  3 | C.R.O.Qu.E.T. S.A.  | be_comp        |
  2 | KG5380              | be_comp        |
  1 | KNOWLEDGE GATE S.A. | lu             |
(3 rows)

kmod_3311837=> select id,model,module,res_id from ir_model_data where name = 'main_company';
 id |    model    | module | res_id
----+-------------+--------+--------
  2 | res.company | base   |      1
(1 row)
```
```
> /home/odoo/src/enterprise/19.0/l10n_be_reports/models/account_chart_template.py(52)_get_be_account_reconcile_model()
-> if template_code in ['be', 'be_comp', 'be_asso']:
(Pdb) template_code
'be_comp'
(Pdb) self.env.company
res.company(1,)
(Pdb) self.env.company.chart_template
'lu'
(Pdb)
```
- The traceback occurs because during the translation loading process, the system calls [_get_chart_template_data](https://github.com/odoo/odoo/blob/38cffd1d1580693c56f0d897b8c8e60b938a8e85/addons/account/models/chart_template.py#L1465)
for all available template codes. In the customer’s database, there are three companies: Company 2 and Company 3 use the BE_COMP localization, while Company 1 uses the LU localization.
- When _get_chart_template_data is executed for the BE_COMP chart template, it eventually calls [_get_be_account_reconcile_mode](https://github.com/odoo/enterprise/blob/d13dc2d7b54d7e43f3b27b19131d0a277d0498b8/l10n_be_reports/models/account_chart_template.py#L49) During this call, the function receives the correct template code (be_comp) as an argument. However, self.env.company returns Company 1, because Company 1 is set as the main_company.
- As a result, [_be_company_vat_communication](https://github.com/odoo/enterprise/blob/d13dc2d7b54d7e43f3b27b19131d0a277d0498b8/l10n_be_reports/models/qr_code_payment_wizard.py#L14) is called with Company 1, even though this company uses the LU localization. Since LU localization does not support the BE VAT communication logic, an error is raised from this method.
- I have made a fix that uses the chart_template of self.env.company to avoid the blocking issue during the upgrade. However, I am not fully sure whether this is the correct solution. Since the load_translation method does not pass with_company when retrieving the chart template, this issue will always occur because the methods are executed in the context of the main company instead of the company that the chart template actually belongs to.

opw-5342498

[FIX] account_reports: returns: fix generations of files as attachments

_generate_submission_attachments does not exist anymore ; it's been renamed to _generate_locking_attachments. Because of that, some intended overrides were not executed properly, and several XML/CSV export files were not generated and added as attachments to the return.

Moreover, the functions generating export files used to be called by account.report's export_file function (from a button defined in options['buttons']). export_file always forced the 'export_mode' key into the options it passed tp those file generators; we reintroduce this behavior for consistency, to avoid messy situations due to forward-port or functions being converted from the former paradigm to the new one. Note, however, it's always better to fully regenerate the options from such a generator.


=================================================================================


[FIX] account_reports: returns: homogenize the reset behavior

Before this fix, resetting a tax report deleted all the attachments of the return, while resetting for example the Partner VAT Listing (in Belgium), left them untouched. We now introduce a common helper for all reset functions, defining the behaviors they should share.

**Steps to reproduce:**
* Install the **Accounting** and **l10n_br_edi** modules.
* Create and post a Brazilian customer invoice using an **Avatax fiscal position**
* [Guide to setup EDI for l10n_br](https://docs.google.com/document/d/1CSUKpnyhty5WBqUDBE-7dGvu0qxaC5vQ0loz0fYNg04/edit?tab=t.0)
* Confirm the invoice and **send it to e-invoice (Brazil)**.
* Confirm the **Brazil E-Invoice Status** shows **'Accepted'**.
* Click **Request Cancellation**, enter a cancellation reason, and submit the request.

**Observed behavior:**
* The invoice moves to **Cancelled** state.
* The cancellation XML is generated and attached in the chatter.
* SEFAZ returns a successful cancellation response.
* However, the **BR EDI Status** becomes **empty**, instead of reflecting **'Cancelled'**.

**Cause:**
* In the wizard `l10n_br_edi.invoice.update`, both `_finalize_update()` and `_submit_services()` assign `l10n_br_last_edi_status = 'cancelled'` **before** calling `button_cancel()`.
* `button_cancel()` internally triggers `button_draft()` for posted invoices.
* The Brazil EDI override of `button_draft()` resets `l10n_br_last_edi_status = False`.
* This clears the status that was just set, leaving the field blank.

**Fix:**
* move `l10n_br_last_edi_status = "cancelled"` to `button_cancel()` method.

opw-5378542

Forward-Port-Of: odoo/enterprise#101438

The test `test_shop_floor_my_wo_filter_with_pin_user` sometimes fails on these steps:
https://github.com/odoo/enterprise/blob/422ac3d5b10c44233321010b9ecb8e37735b3ea3/mrp_workorder/static/tests/tours/tour_shopfloor.js#L177-L190 https://github.com/odoo/enterprise/blob/422ac3d5b10c44233321010b9ecb8e37735b3ea3/mrp_workorder/static/tests/tours/tour_shopfloor.js#L196-L206 https://github.com/odoo/enterprise/blob/422ac3d5b10c44233321010b9ecb8e37735b3ea3/mrp_workorder/static/tests/tours/tour_shopfloor.js#L212-L221 This happends since changing the user requires some time to display the related shopfloor records, but the steps check the number of visible records as soon as it has switched rather than when it is sure that the records are displayed.

#### Fix:

Since switching employees will first empty the recordset and later display the related records, we can split the steps in two. We first check that we switched users, then we check the existence of a record that is not present for the previous user, and only then perform the related checks.

#### runbot-226734

Forward-Port-Of: odoo/enterprise#101268
Forward-Port-Of: odoo/enterprise#100746

We had a bug when attempting to refund orders that were created with the "Consumidor Final Anónimo" customer. The refund validation would crash with a TypeError instead of showing the proper error message.

Steps to reproduce:
-------------------
In POS with l10n_cl_edi module activated:
* Create a new order with "Consumidor Final Anónimo" as customer
* Add products and pay the order
* Validate the order
* Attempt to refund this order

> Observation:
The refund validation would crash with:
TypeError: Cannot read properties of undefined (reading 'add') at OrderPaymentValidation.isOrderValid

Why the fix:
------------
The code was trying to access `this.dialog` which is undefined in the OrderPaymentValidation class context. The dialog service should be accessed via `this.pos.dialog`, which is the correct pattern used throughout the base OrderPaymentValidation class. This fix ensures the error dialog is properly displayed when attempting to refund orders for the anonymous final consumer, instead of crashing with a TypeError.