Before this commit, when using a product in a kit with a smaller unit of measure than the base product UoM, and the conversion resulted in a zero quantity, an unclear error message was displayed upon closing the PoS session: "Quantity or Reserved Quantity should be set." This error message lacked sufficient information, making it difficult to diagnose the issue, especially with multiple orders.

This commit enhances the error message to clearly indicate the cause of the problem, providing specific details about the UoM conversion that resulted in a zero quantity.

To reproduce the issue:
1. Create a product with a base UoM in kilograms (kg).
2. Include this product in a kit with a UoM of grams (g).
3. Set the rounding precision for both UoMs to 0.01.
4. Sell one kit through the PoS.

The error would occur due to the quantity conversion from grams to kilograms resulting in zero, given the rounding precision settings.

opw-4084783

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

Forward-Port-Of: odoo/odoo#175007

Currently, a traceback occurs when the user `posts journal entries` with `multiple expenses` 
in which one of the expense doesn't have a `date`.

To reproduce this issue:

1) Install `Expense`
2) Create an expense report(expense sheet) with multiple expense lines 
3) Remove one of the expense's date
4) Click Submit to Manager> Approve> Post Journal Entries

Error:
```
TypeError: '>' not supported between instances of 'datetime.date' and 'bool'
  File "odoo/http.py", line 2248, in __call__
    response = request._serve_db()
  File "odoo/http.py", line 1823, in _serve_db
    return self._transactioning(_serve_ir_http, readonly=ro)
  File "odoo/http.py", line 1843, in _transactioning
    return service_model.retrying(func, env=self.env)
  File "odoo/service/model.py", line 134, in retrying
    result = func()
  File "odoo/http.py", line 1821, in _serve_ir_http
    return self._serve_ir_http(rule, args)
  File "odoo/http.py", line 1828, in _serve_ir_http
    response = self.dispatcher.dispatch(rule.endpoint, args)
  File "odoo/http.py", line 2053, in dispatch
    result = self.request.registry['ir.http']._dispatch(endpoint)
  File "odoo/addons/base/models/ir_http.py", line 220, in _dispatch
    result = endpoint(**request.params)
  File "odoo/http.py", line 756, in route_wrapper
    result = endpoint(self, *args, **params_ok)
  File "addons/web/controllers/dataset.py", line 42, in call_button
    action = self._call_kw(model, method, args, kwargs)
  File "addons/web/controllers/dataset.py", line 34, in _call_kw
    return call_kw(request.env[model], method, args, kwargs)
  File "odoo/api.py", line 458, in call_kw
    result = getattr(recs, name)(*args, **kwargs)
  File "home/odoo/src/enterprise/saas-17.2/hr_expense_extract/models/hr_expense.py", line 199, in action_sheet_move_create
    return super().action_sheet_move_create()
  File "addons/hr_expense/models/hr_expense_sheet.py", line 558, in action_sheet_move_create
    self._do_create_moves()
  File "addons/sale_expense/models/hr_expense_sheet.py", line 119, in _do_create_moves
    return super()._do_create_moves()
  File "addons/hr_expense/models/hr_expense_sheet.py", line 700, in _do_create_moves
    moves = self.env['account.move'].create([sheet._prepare_bills_vals() for sheet in own_account_sheets])
  File "addons/hr_expense/models/hr_expense_sheet.py", line 700, in <listcomp>
    moves = self.env['account.move'].create([sheet._prepare_bills_vals() for sheet in own_account_sheets])
  File "addons/hr_expense/models/hr_expense_sheet.py", line 728, in _prepare_bills_vals
    **self._prepare_move_vals(),
  File "addons/hr_expense/models/hr_expense_sheet.py", line 749, in _prepare_move_vals
    'date': self.accounting_date or max(self.expense_line_ids.mapped('date')) or fields.Date.context_today(self),
```


When the user clicks on the `Post Journal Entries` Button, it tries to create an expense report in which `_prepare_move_vals` method triggers.

In this method, the `max` function is used to get the date from `expense_line_ids`. 
If any one of the expense lines doesn't have a date(date is not required) it leads to a traceback.

https://github.com/odoo/odoo/blob/607e454f65c2c60c4ee5169bc53706f24a8bc625/addons/hr_expense/models/hr_expense_sheet.py#L725-L732

After applying this commit, it will resolve this issue by filtering records with date and then the max function is used to get the maximum date.

sentry-5616738740

Forward-Port-Of: odoo/odoo#173613

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

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

Example of steps:

    - install `inventory`
    - Open a transfer/receipts
    - add a product
    - validate it
    - click on return
    - there is a modal with the product
    - double click quickly on remove button
    - click return
    - traceback

```
psycopg2.errors.InvalidTextRepresentation: invalid input syntax for type integer: "virtual_12"
LINE 1: ...ETE FROM "stock_return_picking_line" WHERE id IN ('virtual_1...
                                                            ^
```
When this modal is opened, a `one2many` is built with “virtual” records,
which are the products selected in the transfer.

These records are virtual because we don't know which ones the customer
will keep - we'll only know for sure when he clicks on “Return”.

So, when this o2m is loaded, the setup of the Record class populates it.

A first call to the `_applyCommands` function is made with a command to
create a record (product) (command 0/CREATE).

Once the o2m has been loaded, the customer (who quickly clicks to remove
several products) ends up at some point double-clicking on the remove
button of the same product will trigger two consecutive calls to `_applyCommands`.

The first call (which is the correct call)
will have the command: `[2, “virtual_12”]` which is a `DELETE`.

But as we've already asked to create the same “virtual_12” record,

we are here:

https://github.com/odoo/odoo/blob/7caddbb653aa8235725b48ff9f28d6119fdc3567/addons/web/static/src/model/relational_model/static_list.js#L580-L585

Here, given that we have a delete `virtual_12` command and that just before
the setup we asked to create `virtual_12`, this condition will just remove
the command that creates `virtual_12` to simplify the operation without
creating a `DELETE` command.

So instead of creating it and then deleting it, we just don't create it.

The problem arises with the second click, which triggers exactly the same
call to `_applyCommands`, asking to delete `virtual_12`.

As this time we don't have any more “record creation” pending, we'll
enter here


https://github.com/odoo/odoo/blob/7caddbb653aa8235725b48ff9f28d6119fdc3567/addons/web/static/src/model/relational_model/static_list.js#L583-L585


The second click will ask you to delete a record that never existed in
the `web_save`... so that's what the python server don't like!

To correct the problem, I apply a variable to the button in the dom,
which I set to true when the first click occurs, and which I check on
the second click to ignore it.

opw-[4043992](https://www.odoo.com/web#id=4043992&view_type=form&model=project.task)

Forward-Port-Of: odoo/odoo#173481

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

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

### Steps to reproduce:

- Create a fiscal position that converts 19% tax-inclusive into 19% tax-exclusive.
- Create a product with 19% tax inclusive.
- Create a contact and assign the above fiscal position.
- Navigate to a field service project and add an employee with a tax-included rate in the employee mapping.
- Create a new field service task for the customer with the assigned fiscal position and add one hour for the employee in the mapping.
- Add the product with 19% tax included to the task.
- Mark the task as done.

#### Current Behavior:

- The product unit price is calculated excluding tax.
- The service unit price remains calculated as tax-included.

#### Expected Behavior:

Both product and service unit prices should be calculated consistently as tax-excluded when the tax is set to 19% exclusive.

### Cause of the issue:

When creating a new sale order line if the unit price is not specified "product_id_change" is called which set the correct unit price after applying the fpos by calling `_update_taxes` on the line:
https://github.com/odoo/odoo/blob/a09e0c651ea54faa3b41e6012b6d62f143519f07/addons/sale/models/sale_order_line.py#L617-L628
But in our case we are setting the `unit_price` to the employee rate here:
https://github.com/odoo/enterprise/blob/e23e01337faeec652d400618cf14aaf3d6d47ef2/industry_fsm_sale/models/project_task.py#L408-L412
and the taxes are not taken into account.

### Fix:

The unit price of the employee rate should be updated to reflect the changed taxes from fpos. However, since `_update_taxes` relies on the unit price of the product rather than on the one given to the line:
https://github.com/odoo/odoo/blob/a09e0c651ea54faa3b41e6012b6d62f143519f07/addons/sale/models/sale_order_line.py#L685
we can not call the `_update_taxes` directly to update the sol.

opw-3853196

Co-authored-by: waha <waha@odoo.com>

Forward-Port-Of: odoo/enterprise#67730