Accessing a linked repair record through Helpdesk can lead to a blocking bug where the user is unable to generate a quote through the repair record.

### Description of the issue :

1) When generating a `repair.order` record through a Helpdesk ticket or accessing an existing linked repair order through the smart button, the context key for `default_team_id` will be inherited. In this case referencing the id of the current `helpdesk.team` record.

2) When trying to generate a quote through the repair order, an edge case can happen where a ValidationError is triggered at sale order creation.
```
The operation cannot be completed: another model requires the record being
deleted. If possible, archive it instead.

Model: Sales Order (sale.order)
Constraint: sale_order_team_id_fkey
```
This is due to the fact that the `sales.order` also uses a `default_team_id` context key to designate the default sales team.

If by happen stance, the referenced `id` values does not match an existing `crm.team` record, you will hit the above foreign key constraint blocking the user from generating the quote.

### Proposed fix :

Functionally it makes no sense to pass the `default_team_id` context value from helpdesk to sales order, as both implicitly reference different models and functional entities.

Since the `_prepare_repairs_default_value` was already introduced in https://github.com/odoo/enterprise/commit/edd88ebdcc60b7c4d261bfb8755e910356684a3f to handle the context value preparation when using the repair smart button, the simplest solution is to set the `default_team_id` context key to `False`, thus not passing it later on to the sales order (i.e. the quote will not have a default sales team, but the user can still manually define one)

### How to reproduce:
1) Set up a DB with sales, helpdesk and repairs installed 
2) If using demo data, just create a handful of new helpdesk teams (`helpdesk.team`). The important part is that you have at least one record with an id that will not be present in the `crm.team` table
3) For the helpdesk team matching the above criteria, activate the Repairs option (`use_product_repairs`) in the team configuration 
4) Create a helpdesk ticket for that helpdesk team, create a repair order using the action button, then try using the Create Quotation action button (`action_create_sale_order`)

→ Validation Error is triggered

OPW-4123410

Forward-Port-Of: odoo/enterprise#68822

Fixes 2 bugs (2nd noticed while investigating the 1st bug):

1. When selecting `create_backorder="always"` for a manufacturing operation type, the auto-printing didn't work for the MOs after they were marked as done.

Steps to reproduce:
- create a new lot tracked product
- set the manufacture operation type `create_backorder="always"`
- set the operation type > Hardware > Print When Done > Lot/SN Labels to true
- create a MO for the lot tracked product with a product_qty > 1
- set a `lot_producing_id` and mark `qty_producing=1`
- click "Produce" button

Expected result:
MO is backordered + the lot label is auto-printed (i.e. generated and downloaded as a pdf if no iot printer is set up)

Actual result:
MO is backordered and has a status=Done, but nothing is printed + the values that should be written within `button_mark_done` are not written (i.e. `priority` is not set to 0 and `date_finished` is not set to now())

Issue was due to use of the backorder wizard without passing the MOs that are always backordered as `mrp_production_ids`, this resulted in the MOs being backordered due to the context logic within the backorder wizard, but not applying the rest of the logic within `button_mark_done` that is applied to the `self` records (i.e. the MOs being backordered)

2. If more than 2 manufacturing operation types were set, then depending on the combination of `create_backorder` values, the backordering mechanism might not work. E.g. if `always` + `ask`, the `always` backordering logic would return and ended the logic before the `ask` or `never` MOs backordering logic was ever reached.

Steps to reproduce:
- set up 2 manufacture operation types, one with `always` and one with `ask`/`never`
- set up 2 MOs with product_qty > 1 using the 2 different operation types
- mark `qty_producing=1` for each MO and then select both MOs in the list view + action > "Mark as Done"

Expected result:
the `always` MO is backordered automatically and the `ask` MO has the backorder wizard pop up for it

Actual result:
the `always` MO is backordered automatically and the `ask` MO does nothing (it is not even set to done)

opw-3987144

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Forward-Port-Of: odoo/odoo#174632

### Steps to reproduce:

- Create a storable product A
- Create and confirm a delivery order for 1 unit of A
- Add one unit of A in stock
- Inventory > Operations > Run Scheduler

#### > The reservation of the delivery order is not performed

### Cause of the issue:

The "reservation_date" of moves whose "picking_type" does not have a reservation method 'At Date' is removed each time it is computed because of these lines:
https://github.com/odoo/odoo/blob/17a18f9d065d25095f80e6982b6dc0673e5c382e/addons/stock/models/stock_move.py#L547-L553 However, during the `_run_scheduler_tasks` only the moves whose `reservation_date` is set will be reserved:
https://github.com/odoo/odoo/blob/17a18f9d065d25095f80e6982b6dc0673e5c382e/addons/stock/models/stock_rule.py#L549-L554 https://github.com/odoo/odoo/blob/17a18f9d065d25095f80e6982b6dc0673e5c382e/addons/stock/models/stock_rule.py#L572-L574

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

Forward-Port-Of: odoo/odoo#177612

**Version:**
16, 17, master

**Description of the issue/feature this PR addresses:**
Argentinean localization: if a customer invoice with partner with "IVA Responsable Inscripto" AFIP Responsibility is confirmed, then reset to draft and changed the partner to one with  "Responsable Monotributo" AFIP Responsibility, then "Document Type" field is changed and this is not the desired behavior because that field is readonly when the invoice was posted. Compute method should not overried the document type if the invoice was posted before. If it does then an incosistency will occurr because the name, document type and sequence will not match. A new sequence non-real will be used. Also the user it is not aware is happening because the field is readonly.
**But when a vendor bill with partner with "IVA Responsable Inscripto" AFIP Responsibility is confirmed then is needed to change "Document Type" field if that vendor bill is reset to draft and changed the partner to one with  "Responsable Monotributo" AFIP Responsibility.** --> we introduced this bug on this pr [https://github.com/odoo/odoo/pull/172003](https://github.com/odoo/odoo/pull/172003)

**Video showing how to replicate the bug:**
https://drive.google.com/file/d/1endivnZ3EEBVn4kzt0hIkR-a5tecYUR7/view

**Steps to reproduce:**
1. Log in with admin on runbot odoo enterprise 16 instance and install l10n_ar_edi (Argentinean Electronic Invoicing) module.
2. Take position on company "Responsable Inscripto".
3. Go to "Accounting / Vendor / Bills" and create a new vendor bill with vendor "ADHOC SA" (this partner has "IVA Responsable Inscripto" AFIP Responsibility), with a journal "Vendor Bills", add an invoice line and confirm it.
4. Reset to draft the vendor bill mentioned in step 3 (now journal and document type are readonly fields), change customer to "Gritti Agrimensura" (this partner has "Responsable Monotributo" AFIP Responsibility) and save. Check that the document type has not changed from "(1) FACTURAS A" to "(11) FACTURAS C" and this is not the desired behavior because is a readonly field now because the invoice was posted before.

**Current behavior before PR:**
When a vendor bill with partner with "IVA Responsable Inscripto" AFIP Responsibility is confirmed then "Document Type" field does not changes if that vendor bill is reset to draft and changed the partner to one with  "Responsable Monotributo" AFIP Responsibility.

**Desired behavior after PR is merged:**
When a vendor bill with partner with "IVA Responsable Inscripto" AFIP Responsibility is confirmed then "Document Type" field does changes if that vendor bill is reset to draft and changed the partner to one with  "Responsable Monotributo" AFIP Responsibility.

Ticket Adhoc side: 77058
Task latam: 1242

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

Forward-Port-Of: odoo/odoo#175855

This commit fixes an issue regarding global discount lines on invoices that should be represented as allowance charge elements on the UBL file sent to ZATCA. In V17 the structure of the dictionary passed to the XML template in charge of rendering AllowanceCharge changed and expects the value of the tax_scheme_id to be passed inside a dict called tax_scheme_vals, which was not the case previously.

Description of the issue/feature this PR addresses:
When trying to submit an invoice containing global discounts to ZATCA, the server throws an error since it expects a Tax Scheme ID on the Allowance Charge element linked to the global discount. This only happens on V17 as the structure of the data passed to the AllowanceCharge XML template changed

Current behavior before PR:
ZATCA servers return an error when submitting invoices containing a global discount line

Desired behavior after PR is merged:
ZATCA servers correctly process invoices containing global discount lines



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

Forward-Port-Of: odoo/odoo#177326