#### Partner feedbacks

- Add small box notification in settings when NAV 3.0 authentication succeeds.
- Add warning if the user un-checks the 'NAV 3.0' checkbox in the Send & Print.
- Amend module manifest to clarify that we are electronically reporting paper invoices.
- Report the *date of payment*, not date of issue of advance invoices as `advancePaymentDate` when issuing the final invoice. In addition, advanceExchangeRate should be the HUF exchange rate used for the payment.
- Add a warning if not all advance invoices are paid when issuing the final invoice.
- Add more checks in tests that the invoice checks pass when opening the Send & Print wizard.
- Make the 'HU Tax Reason' field invisible if the tax has VAT type.

#### Bugfixes
- connection testing should be done on res.config.settings `create()`, not on `set_values()` because the related fields are written during the create, which is called in a prior transaction to the set_values. This ensures that if the connection cannot be established, the UserError causes the rollback of the transaction before the values are written to res_company.
- the parse_error_response method wasn't correctly parsing error results leading to empty error messages


Many thanks to:
- Eiler Attila (online-erp.hu)
- Geza Nagy (oregional.hu)

taskid: 3985127

Forward-Port-Of: odoo/odoo#168932

Currently, when various timestamps in Odoo are processed through the `DeserializeDate` function, the offset is being doubled by mistake. The Odoo timestamps are passed as strings which have already been converted to UTC. If a user inputs a `DateTime` on a pricelist for instance, that time will be converted to its UTC equivalent before being converted to a string. The issue arises when we try to parse that string in the frontend during a PoS session. Odoo will correctly parse the timestamp, however through the `DeserializeDate` function it calls the `FromSQL` function with the parameter 
`zone: 'default'` which makes Odoo process this timestamp as being in the `SystemZone` (which is used by default in Luxon) instead of correctly recognizing that it is already in UTC. Thus, it will offset it again, which causes the functionality to fail

This commit allows the timezone in `DeserializeDate` to be passed as a parameter, so in these cases we can pass the correct timezone and avoid this issue.

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

Forward-Port-Of: odoo/odoo#176866

Versions
--------
- 17.0+

Steps
-----
1. Have industry_fsm_sale from enterprise installed;
2. create a SO using a different `partner_id` for the shipping address;
3. add a product that uses timesheets without creating a task;
3. confirm the sale order;
4. in Field Service, create a new task;
5. set Customer to `partner_id` used for shipping address;
6. select the relevant Sales Order Item;
7. add a product in catalog.

Issue
-----
After adding a product to the field service task, a new SO is created instead of adding it to the existing SO (as would be the case if the task was created by the SOL).

Cause
-----
When computing a task's `sale_order_id`, it checks whether the task's `partner_id` matches that of the sale order. FSM tasks generally use the `partner_shipping_id` instead, so if this one is different, `sale_order_id` is set to `False`.

Solution
--------
Aside from  sale order's `partner_id`, also check its `partner_invoice_id` and `partner_shipping_id` when deciding whether the task should get linked to the SO.

Also changes one of the dependent fields of the compute method from `project_id` to `project_id.sale_order_id`, assuming that when a task's `sale_order_id` is derived from its project's, changing the project's SO should trigger a recompute for the task's as well.

opw-3901885

Forward-Port-Of: odoo/odoo#175658

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

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

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

**Current behavior:**
When a kit bom product move line is broken down into move lines
for its component products, changes written to the move line
(not on the move) will not carry over to the new move nor move
lines.

**Expected behavior:**
The change should be observed beyond the decomposition.

**Steps to reproduce:**
1. Create a new internal transfer in barcode

2. Add a product with some bom via form, also edit the
     destination location in the form to be something
     non-default.

3. Save the form, validate the transfer

4. See that the broken down move lines don't keep the changed
     destination location

**Cause of the issue:**
When the kit bom moves are exploded, the location information of
its move lines is not taken into account at any point- and thus
it's lost.

**Fix:**
For kit bom products, use a move line's location information
during creation of a move as opposed to the picking. Only link a
new move line for a kit bom product to an existing move if (in
addition to the product) the location source and destination
values match.

opw-4016702

Forward-Port-Of: odoo/odoo#173347

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

**Current behavior:**
In Barcode, it is possible for a split of incomplete moves to be
triggered which leaves the original move with a quantity and
demand of zero- effectively generating a superfluous record
value.

**Expected behavior:**
A split should not occur when the original line has
`quantity == 0`.

**Steps to reproduce:**
1. Create a transfer for 2 units of some product, assign it

2. Open the transfer in Barcode and use the form to add 1 unit

3. Use the back button within the Barcode app to return to the
     previous action

4. Reopen the transfer, set the quantity on the move to 0 from 1

5. Use the back button to exit the transfer again

6. Open the transfer in the backend to see there is a move with
     a line for 0 / 0 units.

**Cause of the issue:**
We split moves if their quantity is less than demand without
considering it may be zero.

**Fix:**
Reset the move in the case of `quantity == 0`- thus it will no
longer become a split candidate.

opw-4056241

Forward-Port-Of: odoo/enterprise#68554

**Current behavior:**
When a kit bom product move line is broken down into move lines
for its component products, changes written to the move line
(not on the move) will not carry over to the new move nor move
lines.

**Expected behavior:**
The change should be observed beyond the decomposition.

**Steps to reproduce:**
1. Create a new internal transfer in barcode

2. Add a product with some bom via form, also edit the
     destination location in the form to be something
     non-default.

3. Save the form, validate the transfer

4. See that the broken down move lines don't keep the changed
     destination location

**Cause of the issue:**
When the kit bom moves are exploded, the location information of
its move lines is not taken into account at any point- and thus
it's lost.

**Fix:**
For kit bom products, use a move line's location information
during creation of a move as opposed to the picking. Only link a
new move line for a kit bom product to an existing move if (in
addition to the product) the location source and destination
values match.

opw-4016702

Forward-Port-Of: odoo/enterprise#66746