Current behavior:
-
Creating an SO with negative quantities for a storable product with an invoicing policy of type "delivered quantities" automatically generates a return move for the stocks. However, when this delivery is validated, the delivered quantities are not updated on the SO. This is problematic as these quantities are therefore not taken into account on the associated invoice.

Expected behavior:
-
The delivered quantities should be updated negatively on the SO to enable the invoicing of these lines.
This is already the behavior in the POS application and when you create an SO with positive quantities followed by a return for a larger quantity than the one delivered.

Steps to reproduce:
-
Create a storable product with an invoicing policy of type "delivered quantities".

Create an SO with 2 lines:
   - a line with positive quantities for any other product.
   - a line with negative quantities for the product you created.

Confirm and validate the corresponding deliveries. Return to the SO. The quantities for the second line are not updated.

Create an invoice. The second line is not taken into account.

Cause of the issue:
-
The to_refund field of the stock.move model defined in the stock_account module enables a decrease of the delivered quantities in the associated Sale Order. This field is set to True for "classic" returns but not for the stock.move generated from sale.order.line with negative quantities.

Fix:
-
We rely on the _get_custom_move_fields method to add the to_refund field in the procurement 'values' arguments in case the stock_account module is not installed. It is then available to use in the _get_stock_move_values method where we set its value to True if the quantity is negative (so that the move should be considered as a refund).

opw-3676045
-

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

Forward-Port-Of: odoo/odoo#154496
Forward-Port-Of: odoo/odoo#152466

This commit fixes a pretty specific issue within autocomplete behavior where the change event after clearing the value is prevented. Steps to reproduce:
- go to an empty autocomplete and click on it
- start typing a search with results
- click on the first result
- without focusing out, clear the input and finally click out 

No change event is triggered on click out in this case so the cleared value is not updated in the end and saving the record will keep the non cleared value.
The t-on-mousedown.prevent in the dropdown was mainly used to keep the focus on the input after selecting a value for the autocomplete. This introduces a side effect: when one starts typing on the initially empty autocomplete, the browser keeps the initial value of the input in memory until it is focused out (and therefore blurred). When the input is focused out, it will compare the current value of the input with the stored initial value and decide to trigger a change event based on the comparison between the two values: if these are different, the change will trigger. In our case, since the mousedown event on a search result is prevented, no focus out will happen and therefore the browser will still wait for the next focus out to trigger the eventual change event. But since we clear the input before focusing out, the two values are empty and no change event is triggered which introduces the issue. To fix it, we remove the t-on-mousedown.prevent of the template and manually avoid triggering the onInputBlur method with a flag to keep the previous behavior and we finally focus on the input programatically after selecting a value.

task-3734818

Forward-Port-Of: odoo/odoo#154448
Forward-Port-Of: odoo/odoo#154203

### Steps to reproduce issue:

1. Create Draft invoice with no Invoice Date
2. Set payment terms with multiple due dates (e.g.: "30% Now, Balance 60 Days)
3. Make sure "Show installment dates" is ticked in the payment terms form
4. Print invoice
5. Receive traceback with main message:

>     odoo.addons.base.models.ir_qweb.QWebException: Error while render the template
>     ValueError: The value send to monetary field is not a number.
>     Template: account.report_invoice_document
>     Path: /t/t/div[2]/div/div[3]/div[2]/t/div/div/t[1]/td/span[1]
>     Node: <span t-options="{&quot;widget&quot;: &quot;monetary&quot;, &quot;display_currency&quot;: o.currency_id}" t-out="o.invoice_payment_term_id._get_amount_due_after_discount(o.amount_total, o.amount_tax)"/>

### Explanation:

`_is_eligible_for_early_payment_discount` will normally return `True` only if every condition is fulfilled. In previous fix odoo@9b20af823d3d2d8c3c70fd016d71448caa039958, we bypassed all of them if `reference_date` had no value.
https://github.com/odoo/odoo/blob/4b744c82c3f902448a5c89c4711eccfeb1b548b8/addons/account/models/account_move.py#L1910-L1918
The method is called here, leading to the field that triggers the traceback.
https://github.com/odoo/odoo/blob/8f3c0b218eb9ea725995d716e97999556ce74578/addons/account/views/report_invoice.xml#L230-L236
The reason it only blocks with multiple due dates is because of the first line: `payment_term_details` is true when there are multiple due dates or an early discount, the latter being the concern of the previous fix.
The second one is true if "Show installment dates" is ticked.

### Suggested fix:

`reference_date` should not take priority. Therefore, we will only override its own condition when it has no value.

opw-3726968

Forward-Port-Of: odoo/odoo#153401