### Steps to reproduce:

- Create and confirm a delivery with 2 moves:
    - 1 x product 1
    - 1 x product 2
- Set the quantity of product 2 to 0 and mark it as picked
- Validate the transfer
#### > The backorder wizard open's even though there is nothing to validate. Creating a backorder does nothing.

#### Cause of the issue:

Since there is a picked move, the picking validation does not pick every moves in the `pre_action_done` hook keeping only moves with empty qty as picked:
https://github.com/odoo/odoo/blob/9b41eb38403e64091b74e1ae53c79488aa48b499/addons/stock/models/stock_picking.py#L1208-L1209 Then, only the picked moves are processed in there `_action_done`: https://github.com/odoo/odoo/blob/9b41eb38403e64091b74e1ae53c79488aa48b499/addons/stock/models/stock_move.py#L1914 https://github.com/odoo/odoo/blob/9b41eb38403e64091b74e1ae53c79488aa48b499/addons/stock/models/stock_move.py#L1929-L1937 Which leads to an empty picking validation.

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

Forward-Port-Of: odoo/odoo#227995

# Issue:
In a sale order, if any of the so lines contains the ID of a deleted analytic account in its analytic_distribution field, then updating the project_id field is impossible as it raises an error.

# Cause
This is caused because _compute_analytic_distribution() tries to retrieve 'root_plan_id' from all ids without checking if records exists.

# Fix
This commit add an exists() check on analytic.accounts retrieved from analytic_distribution field and clear the non-existing records ids from the field.

# Steps to reproduce
- Install sale_project and accountant modules
- Check "Analytic Accounting" in the Accounting settings
- Create a new project "Test P", set it up "Billable", with a new Analytic account "Test AC" (field "Project" tab "Analytic")
- Create a new sale order "Test SO", add a few products and set up the Project field to "Test P". Save the sale order.
- Delete the analytic.account "Test AC"
- Go back on "Test SO", try to change the field "Project" - a Missing error is thrown

---

Current behavior before PR: When creating a sale order and binding it to a project with an analytic account, then deleting the analytic account, the field "Project" on the sale order can't be updated anymore.

Desired behavior after PR is merged: When creating a sale order and binding it to a project with an analytic account, then deleting the analytic account, the field "Project" on the sale order can be updated.

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

After upgrading Odoo from earlier versions to versions >= Odoo 15.5, you
will notice that some fields that were translated before, are now in
English. This is likely because those translations were not marked as
`state='translated'` in the DB. However, the missing translations were
removed from the `_ir_translation` table during the upgrade.

With this patch, we still keep the conservative behavior of only
auto-translating fields marked as `state='translated'` in the DB (which
is still probably wrong, because user translations should remain the
same; if Odoo was displaying translated text before the upgrade and it
is not after it, that's probably a bug; but that's another story...),
but we no longer delete the other fields. This way, you can still mark
them as translated after the upgrade and use the new tooling provided in
https://github.com/odoo/upgrade-util/commit/fd578e31973596bf7f283ea5c6ebbdfd3314f8bc
to recover those translations after the upgrade.

@moduon MT-11570

cc @aj-fuentes

Forward-Port-Of: odoo/odoo#228404

Currently, an error occurs when archiving multiple helpdesk teams linked to 
different websites.

**Steps to reproduce:**
- Install the `website_helpdesk` module.
- Go to Website, Configuration > Websites and create two websites (`W1` and `W2`).
- Go to Helpdesk, Configuration > Helpdesk Teams > create two teams (`T1` and `T2`).
- Enable the `Website Form` (under `Help Center`), assign `W1` to `T1` and `W2` to `T2`.
- Return to the list view, select both teams, and attempt to `archive` them.

**Error:**
`ValueError: Expected singleton: website(3, 1)`

**Root Cause:**
At [1], the code incorrectly uses `with_website.website_id.id`, when 
`multiple websites` are involved, this leads to an `error`.

**Fix:**
This commit prevents errors and ensures that users can archive multiple helpdesk 
teams linked to different websites

[1]:
https://github.com/odoo/enterprise/blob/8b72fdef63f634ccf436b49adbac5c1f9358c127/website_helpdesk/models/helpdesk.py#L102

sentry-6867906123

The fields `quality_check_todo` and `quality_check_fail` are calculated for stock.picking records by iterating all checks of a stock.picking. This causes a problem when clicking the "To Receive" button for a warehouse in the inventory app, in case there are many transfers each with many quality checks. The function will default to loading all data associated with quality checks in memory through field prefetching. However, since quality checks have too much data (particularly because of the HTML fields) associated with them, the cache can quickly bloat causing an OOM error and crashing the worker.

This PR disables the prefetcher for quality checks before iterating them, preventing this issue from happening since we only need very light fields in the loop.

For a specific customer (opw-5025162), this was the case.

## Benchmarks:

| No. stock.picking | avg no. quality checks | peak memory before | peak memory after | 
| ----------------- | ---------------------- | ------------------ | ----------------- |
| 25                | 20                     | 2771 mb            | 235 mb            |

opw-5025162

**Steps to Reproduce:**
1. Install `l10n_mx_edi_extended` module without demo data.
2.  Set company's country to "Mexico" and switch Fiscal Localization.
3. Deactivate USD currency.
4. Configure CFDI Certificate and activate Testing mode in PAC.
5. Create a new product with "UNSPSC Category".
6. Create an invoice with CFDI to the public and "Definitive" in External Trade.
7. Confirm and send the invoice.

**Sample certificate:**
Certificate file: https://drive.google.com/file/d/1kklNGeRtR08erxWRPfIdeiwheDibcB8M/view?usp=drive_link 
Private key file: https://drive.google.com/file/d/1VJnKVo1doA4cCYPeZBHXKT4JGkbHhOhk/view?usp=drive_link 
Private key password: 12345678a

**Error:**
`ValueError - Expected singleton: res.currency()`

**Cause:**
When sending the invoice, the system attempts to retrieve the USD currency to compute exchange rates. Since the search only considers active currencies, this results in no record being returned, which raises an error in further computation.

**Fix:**
This commit handles the case when USD currency is deactivated.

sentry-6860601127

In the barcode application, scanning a picking order containing a kit product variant with packaging will raise a Traceback.

### Steps to reproduce:

1. Enable packagings on inventory configuration.
2. Create a product, that as a least 2 variants.
3. Add a packaging to one of the variants.
4. Create a BoM for created product (kit type).
5. Create a picking order for the variant with packaging.
6. Print the picking operation to scan the code through barcode.
7. Go to barcode and try to scan it, this will trigger the traceback.

### Cause of the issue:
Scaning a barcode will call get_barcode_data during this call it will retrieve the information about the picking order and call _get_stock_barcode_data:
https://github.com/odoo/enterprise/blob/f2dd6326c2084ed467c3e4c3e9d931f41309ad79/stock_barcode/controllers/stock_barcode.py#L91
_get_stock_barcode_data will obtain the packaging methode for the products.
https://github.com/odoo/enterprise/blob/f2dd6326c2084ed467c3e4c3e9d931f41309ad79/stock_barcode_mrp/models/stock_picking.py#L13-L16
since in our use case the product has variant the packaging information is not inside product_tmpl_id.packaging_ids and thereof it will not retrieve the packaging information.

### Fix:
We don't need to use product_tmpl_id.packaging_ids because of its compute and set methods (and the fact that the product_variant_ids field is required), the product_tmpl_id.packaging_ids will always be included in the product_tmpl_id.product_variant_ids.packaging_ids:
https://github.com/odoo/odoo/blob/eb88370e2fc1887e8c88dfd8dbeadce23bb7abe5/addons/product/models/product_template.py#L430-L441
our fix will allow for packaging in the variant to be considered when there is more than only one variant.

opw-4852875

This PR contains two commits, the first is a refactoring, and the second is the invoice printing itself.

- **[REF] iot: extract printer select into separate function**
  Before this commit, the printer selection wizard was tightly coupled to
  the IoT report handler, and the call to send to the printer was
  duplicated in the wizard and the handler.
  
  After this commit, the printer selection wizard is contained in a
  function that will always return the selected printers directly to the
  caller, whether the dialog needs to be opened or not. The wizard is
  simplified as a result and the print call always occurs in the handler.
  
  This refactoring will allow other places to use the printer selection
  wizard, namely for invoice printing.


- **[FIX] pos_iot: print invoices via IoT**
    In the commit https://github.com/odoo/enterprise/commit/07418d7544ceecfef38257db8f59bf845a0b0769, the invoice PDF downloading was refactored to
  bypass the `ir.actions.report` model, instead working directly via an
  action on the invoice model. A side effect of this is that it broke
  printing invoices via the IoT, as it relies on the report printing
  action to function.
  
  To fix this, this commit introduces an override in `pos_iot` for the
  `account_move_service`, which will print the invoice PDF via the IoT
  instead of downloading it directly (if a printer is associated with the
  report).
  
  
task-5109814

**Steps to reproduce:**
- enable multi-step routes setting.
- navigate to warehouse management/locations create a new location
(the "test location").
- select "internal location" for the location type.
- select WH for the parent location
- navigate to warehouse management/warehouses and select the warehouse
corresponding to WH.
- set the warehouse in 3 steps delivery.
- click on the routes smart button.
- click on the "deliver in 3 steps (pick+pack+ship)" route.
- add a rule, for the action select "push to", for the operation type 
select "internal transfers", for the source location select the "test 
location" you just created and for destination location select "WH/Output".
- save.
- create a storable product and set an on-hand quantity
- create a new sale order for 1 quantity of this product and confirm it
- click on the picking smart button, change the destination location to the
test location and validate
- open the sale order and change the quantity to 3


**Current behavior:**
A new picking is created from stock to packing zone (which is the 
expected behavior) but the quantity is 1 

**Expected behavior:**
The quantity should be 2.
If we only increase the quantity by 1 on the sale order it does not even 
create the new picking

**Cause of the issue:**
The warehouse_id field is invisible in stock.rule form view when the 
action is push. Therefore, the rule is created without a warehouse_id.
Also, moves created from a rule have the same warehouse_id as the rule. 
https://github.com/odoo/odoo/blob/a729578afb7fed79aac2d622aae4da4c0917f8e5/addons/stock/models/stock_rule.py#L275
So, when we validated our first move (from stock to the test location), 
this created a second move (from test location to output) that does not 
have a warehouse id (because it was created from our own push rule that
we created).
When we update the quantity of the sale ordre line, 
_action_launch_stock_rule calls _get_quantity_procurement to compute 
the current quantity on the moves.
This method then calls _get_outgoing_incoming_moves to get the initial 
move created from the rule. In this case this should return only the 
first move created.
But because the second move does not have a warehouse_id, it's rule.id
is added to triggering_rule_ids.
https://github.com/odoo/odoo/blob/a729578afb7fed79aac2d622aae4da4c0917f8e5/addons/sale_stock/models/sale_order_line.py#L315-L317
And the move is later added to the outgoing moves that will be returned.
https://github.com/odoo/odoo/blob/a729578afb7fed79aac2d622aae4da4c0917f8e5/addons/sale_stock/models/sale_order_line.py#L322-L329

So the two moves are returned and the sum of the quantities of the moves
is 2 instead of 1.
https://github.com/odoo/odoo/blob/a729578afb7fed79aac2d622aae4da4c0917f8e5/addons/sale_stock/models/sale_order_line.py#L292-L294
So the product quantity for the procurement will be 1 (3-2) 
instead of 2 (3-1).
https://github.com/odoo/odoo/blob/a729578afb7fed79aac2d622aae4da4c0917f8e5/addons/sale_stock/models/sale_order_line.py#L386

opw-5039249