### Issue: 

MO with a tracked finished product are actually splited at validation. However, the qties of the MO are usually set by default to fulfill the maximal demand. As such, component registrations performed form the shopfloor might be completely override by the MO split.

### Steps to reproduce:

- Create 2 storable products tracked by SN: FP and COMP
- Create a BOM for you final product FP:
    - 1 x COMP
    - 1 operation with an instruction of type "Register Consumed Materials" for COMP
- Put 2 serial numbers in WH/Stock for COMP: SN01, SN02
- Create and confirm an MO for 2 units of FP using that BOM
> SN01 and SN02 should be reserved on the move raw
- Go to the shopfloor to the MO
- Click on Register component SN02 > Validate
- Click on the [+] button of the register Production
- Mark the MO as Done > Close Production
> You trigger a consumption warning dialog telling you that you registered more consumed quantity than expected (2 instead of 1) This dialog should not appear in the first place as you registered only 1 unit but suppose it is ok and continue
- Click on "Set quantities and validate"
- Go back to your MO in the back end
#### > It was closed using SN01 rather than the SN you registered.

### Cause of the issue:

Confirming the MO confirmed the move raw and a reservation was made for 2 units as the MO is not splitted yet. However, since the final product is tracked this MO will end up splitted. When you register consumption, the serial number of one of the move line related to the raw move will be updated and the line will be picked:
https://github.com/odoo/enterprise/blob/d4ff42fbcfa3dd297c6cb838b5b03955f12f02a4/mrp_workorder/models/quality.py#L519-L525 However, since at least one of the move line of the move raw is picked the move its self will become picked:
https://github.com/odoo/odoo/blob/f9e362c45414001077738c2462e9e030f865ec36/addons/stock/models/stock_move.py#L208-L212 This is problematic as picked picked move by pass the set_qty_producing so from now if you were to adapt the qty producing of the MO you would not affect the quantity of the raw move (which is currently at 2: one unpicked move line with SN01 and one picked with SN02): https://github.com/odoo/odoo/blob/f9e362c45414001077738c2462e9e030f865ec36/addons/mrp/models/mrp_production.py#L1218-L1228 Finally, when you click on the Close production, a `_split_productions` process will be started and adpat the demand of the move raw to 1: https://github.com/odoo/odoo/blob/f9e362c45414001077738c2462e9e030f865ec36/addons/mrp/models/mrp_production.py#L1831-L1832 Since the quantity set on the move exceeds this new demand the consumption warning. Note that at this point the backorders of the initial MO were already created and confirm without you dialog to be resolved so that the reservations of these splitted MO could not reserve the SN01 that is still used by your move. Finally, when you "Set quantities and validate" it will adpat the quantity and unreserve the picked move line as this decrease process does not prioritise to unlink unpicked move lines first:

### Fix:

Since registration process through shopfloor and barcode are expected to create picked move lines which will adpat the picked state of the move and since picking the move will automatically pick all the move line, a move line that is not picked in a picked move is a move line that is not expected to be kept. We therefore unlik these move_lines before adapting the demand of the move_raws in the split production.

### Note:

We also tried 2 other fixes of the issue but aborted these other ideas: 
1) try to keep only picked move line at the Validation of the registration component process but this change of behavior was aborted since if instead of clicking on validate you click on "Continue consumption and then on the top right cross button", you would technically have registered only the first SN but you would fall in the situation as above and trigger the same issue.
2) Adapt the condition of that makes a move raw by pass the _set_qty_producing:
https://github.com/odoo/odoo/blob/f9e362c45414001077738c2462e9e030f865ec36/addons/mrp/models/mrp_production.py#L1219-L1221 Since the move is picked for the wrong reason we would instead use: `all(ml.pikced for ml in move.move_line_ids)`
However, this would also require to change the process decrease to unreserve picked move last here:
https://github.com/odoo/odoo/blob/f9e362c45414001077738c2462e9e030f865ec36/addons/stock/models/stock_move.py#L361-L365 Changing the loop to
`reversed(move.move_line_ids.sorted(lambda ml: (not ml.picked, ml.id))` And this would not solve the issue starting post 17.0 since we would still bypass the set_qty producing on the next lines:
https://github.com/odoo/odoo/blob/f9e362c45414001077738c2462e9e030f865ec36/addons/mrp/models/mrp_production.py#L1223-L1225

Enterprise: https://github.com/odoo/enterprise/pull/79591

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

Forward-Port-Of: odoo/odoo#198599
Forward-Port-Of: odoo/odoo#198175

### Issues:

Creating and validating a picking from the barcode app does not behave correctly with respect to quality check trigger and creation. Depending on your flow, you might end up with QC created twice or with QC not being triggered before validation.

### Cause of the issues:

The quality checks are created during the "_action_confirm" of moves: https://github.com/odoo/enterprise/blob/dd4a1ec4aaa7cbb95d6e40a8bb6ab1d6c88fc7b7/quality_control/models/stock_move.py#L12-L15 
However, depending on where you click in the barcode app, the moves might end up being assigned and hence skip the "_action_confirm" of the picking (which is computed to be assigned) prior to the `_pre_action_done_hook` of the `button_validate` of the picking wich is suppose to return already created quality check:
https://github.com/odoo/odoo/blob/08f0c6481a190349369ead5ab9328886392ddbeb/addons/stock/models/stock_picking.py#L1145-L1147 
In which case, the quality check is not triggered (Issue 1). Furthermore, since  the `_action_confirm` of moves can also be applied to extra moves created to update the demand and to be merged to the initial move during the validation, the quality check creation might be called twice on a move once during its own `action_confirm` and once during the `_action_confirm` of its extra move (Issue2).

### Issue 1:

1. Create a storable product P with a barcode: XXX
2. Go to Quality > Quality Control > Quality Points > New
3. Create a new quality point for your product:
    - Control per: "Operation"
    - Operations: "Receipts"
4. Go to the barcode app > Operations > Receipts > New
5. Scan your product
6. Click on the pencil (key step)
7. Either edit the quantity from the digipad and confirm or go back to the picking and edit it from there.
8. Validate the receipt

#### > Even thought a quality check was created using your quality point for your receipt, it was not triggered before validation.

### Cause of the Issue:

Clicking on the pencil will trigger a call of the `save_barcode_data` which will in turn create a stock move line related to the picking during the write performed on the picking:
https://github.com/odoo/enterprise/blob/dd4a1ec4aaa7cbb95d6e40a8bb6ab1d6c88fc7b7/stock_barcode/controllers/stock_barcode.py#L68-L74 
After this edition of the quantity of the picking will write on the `qty_done` dummy field of that move line which will in turn trigger a call of its inverse method and modify its quantity: https://github.com/odoo/enterprise/blob/dd4a1ec4aaa7cbb95d6e40a8bb6ab1d6c88fc7b7/stock_barcode/models/stock_move_line.py#L58-L61 
Changing the quantity of the ml will then update the state of the move to "assigned" because of these lines:
https://github.com/odoo/odoo/blob/a74684777c27e26639b75b0668bb15afadb78c4f/addons/stock/models/stock_move_line.py#L487-L488 https://github.com/odoo/odoo/blob/a74684777c27e26639b75b0668bb15afadb78c4f/addons/stock/models/stock_move_line.py#L530-L531 https://github.com/odoo/odoo/blob/08f0c6481a190349369ead5ab9328886392ddbeb/addons/stock/models/stock_move.py#L2022-L2023 In turns, the state compute method of the picking will determine that the picking is assigned and the picking will not be confirmed during its `button_validate` prior to the `_pre_action_done_hook` of the `button_validate` as it is not in draft anymore.

### Fix:

The state of the move should stay as draft just as if we didn't created the move line through the pencil if we were to edit the qty_done via the barcode app.

### Note:

The inverse method of the "qty_done" computed field was introduced in 17.0+ by commit: 4f19668c51a90e8c12e57b6353bbe5194f83ca10 during the quantity refactoring so that the issue is not reproducible prior to that version.

### Issue 2:

Same steps 1 -> 5.
6'. click on the +1 button.
7'. Validate > this opens the quality check
8'. Pass the quality check > Validate again
9'. Go to Quality > Quality Control > Quality check

#### > Two quality checks were created isntead of one for your receipt

### Cause of the issue:

At some later point in the button validate of the picking, an `_action_done` is called to put the pickings and its move in done state: https://github.com/odoo/odoo/blob/a74684777c27e26639b75b0668bb15afadb78c4f/addons/stock/models/stock_picking.py#L1157

However, during the `_action_done` of the moves if the quantity of the move exceeds its `product_uom_qty`, extra moves will be created, confirmed and merged back to the move in order to update its `product_uom_qty`:
https://github.com/odoo/odoo/blob/607d63fd4d9c07bac9cb68b2d31d86551e93d5b1/addons/stock/models/stock_move.py#L1885-L1890 https://github.com/odoo/odoo/blob/607d63fd4d9c07bac9cb68b2d31d86551e93d5b1/addons/stock/models/stock_move.py#L1823-L1832 However, the action confirm of this extra move will trigger the same override of the `_action_confirm` that creates a quality check and it will even be called on the original move that was already confirmed and already created its QC since the extra move was merged into it: https://github.com/odoo/enterprise/blob/dd4a1ec4aaa7cbb95d6e40a8bb6ab1d6c88fc7b7/quality_control/models/stock_move.py#L12-L15 
As a result we end up with an extra quality check creation.

### Fix:

We avoid quality check creation during extra move confirmation.

Enterprise: https://github.com/odoo/enterprise/pull/76301

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

Forward-Port-Of: odoo/odoo#199233
Forward-Port-Of: odoo/odoo#192034

### Steps to reproduce:

- Create a storable product FP tracked by SN with a BOM:
    - 1 Operation: - instruction: Register Production type (per product)
    - 1 x Comp (storable product in stock)
- Create and confirm an MO for one unit of FP.
- Go to the shopfoor app > open the instruction of your operation
- Type a non-existing serial number in the search bar > Create "new_sn"
> This opens a form view of the stock.lot model
- Save and close the new stock.lot
> Invalid operation: You are not allowed to create or edit a lot or serial number for the components with the operation type
> "Manufacturing". To change this, go on the operation type and tick the box "Create New Lots/Serial Numbers for
> Components"

#### Expected behavior:

The invalid operation should not be raised as the "required" option concerns only componenets and not final products.

### Cause of the issue:

Creating a stock lot will first launch a call of the `_check_create`: https://github.com/odoo/odoo/blob/c25d71f14fa168807f07cd88bed805d15db8add5/addons/stock/models/stock_lot.py#L150-L153 However, since this check does not verifies that the product for which we create the lot is indeed related to a component of the MO it will raise the invalid operation even for final products: https://github.com/odoo/odoo/blob/c25d71f14fa168807f07cd88bed805d15db8add5/addons/mrp/models/stock_lot.py#L11-L17

### Issue 2:

Currently, the `quickCreate` ("Create *sn_name*") option of the lot field of te "register production" dialog calls a `name_create` that will set an error message in the logs as the product_id required field can not be provided neither in the vals or the context of the `name_create`.  You then fall back on the same form dialog than the "Create and edit".  The `quickCreate` option should therefore just be disabled.

Enterprise: https://github.com/odoo/enterprise/pull/77265

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

Forward-Port-Of: odoo/odoo#197372
Forward-Port-Of: odoo/odoo#193965

*: web_editor

Before this commit, there was two cases where we forced the backend to reload using a website domain:

1. When trying to enter the website app, and reaching the default website's preview. Ensuring edition of that website is made while being on the right website domain.

2. When switching website using the website switcher (multi-websites case).

This commit removes the redirection in the first case. It might lead to unexpected behavior in some specific/advanced cases, but it was decided it was worth the risk, to improve the QoL of users reaching their backend by explicitly typing their `<database>`.odoo.com URL. Even though this is not supposed the case anymore as soon as their website is properly configured.

At the same time, this commit strengthens (hopefully) link edition. In the past, we suggested users to automatically strip the domain part of the URL they added in their website if it matches the current domain used while being in edit mode. Now we still do that and two more checks:

- If the added URL is using `<dbname>`.odoo.com, suggest to strip the domain too. It might not be right, but it's a good guess. And the user can still opt-out.

- If the added URL uses the website domain, suggest to strip the domain.

Related to task-4069779

Forward-Port-Of: odoo/odoo#200227

Steps to reproduce the bug:
- Create a cash or bank account journal
- Archive it (you will have an error, because it is associated with a payment method)
- Delete it (it will be deleted normally)

Problem:
The problem is because of added constraint on the archival of account journal, that wasn't added to the deletion as well. The constraint on the archival was too strict after discussion with accounting team, it should be reverted and a new constraint will be added from the pos side.
Now, the journal can't be archived nor deleted if it has at least one payment with payment method for that journal in an active session, because the journal items are written when the session is closed only. So, if the journal is archived with some active payments before closing the session, the journal entries are lost because it fails to write them in archived journal.
The constraint is added to both archival and deletion to prevent the possibility of deletion while we can't archive.

Testing:
A performance testing was held on the new constraint, and based on the profiling the execution time was 0.00 seconds, and the pos.payments test passed successfully.

Commits that added the constraint:
d430231
5722d52

Tickets that required that constraint:
opw-4070620

-------------------------------------------

opw-4554961
opw-4438601

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#200156
Forward-Port-Of: odoo/odoo#199009

Behaviour Before the Commit:

When an invoice pdf has more than 1 page and legal notes(multiline notes) section is the first thing on next page, wkhtmltopdf fails to handle page-break for legal notes text. First line of legal notes overwrites on the total amount section resulting in overflow of contents. It works fine if legal notes are not the first thing on page.

Behaviour After the Commit:

Legal notes(multiline notes) text does not overwrite on total payment summary anymore.

Fix:

Add 'overflow-auto' class to div with id='payment-term' and has clearfix class to ensure it handles overflow.

Steps to reproduce:

1. Create a multiline legal notes for any tax.
2. Open Customer-Invoices, create an invoice by adding multiple products with the tax which has multiline legal notes.
3. Make sure to add specific number of products/sections so that invoice expands to 2 pages.
4. Legal notes section must be the first thing on second page, otherwise it will not overwrite text.

Feel free to look at the ticket number 4416845 for detailed understanding of the bug.

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

Forward-Port-Of: odoo/odoo#193399

Steps to reproduce:

1. Install l10n_ar_edi
2. Use an Argentinian company
3. Go to the "Argentinean Localization" section of the settings
4. Make sure "Private Key" and "Certificate" are empty. Save.
5. Click on "Generate Request".
6. A key has been created but looks like it's not set on the company.

---

Description of the issue this commit addresses:

When generating a certificate request without selecting a private key to generate the certificate request with, a private key is generated by the system but in the settings windows, the field remains empty.

Also, later, after retrieving the certificate from the official platform and trying to insert it in the database, it is required to link it with the private key that was used for its generation but since all automatically generated keys share the same name, this can be quite hard.

---

Desired behavior after this commit is merged:

When using the "Generate Request" button with no private key selected, the Private Key fields is populated with the key that was created for the generation of the request.

Also, the names of the automatically generated keys use the current time for differenciation purposes.

---

Note on the fix:

The error happened because when using the Generate Request button, the key is created by a method called via another request so virtually, the assignment happens in another window. To fix that issue, the key has to be created and assigned before making any other request.

---

task-4393259

Forward-Port-Of: odoo/enterprise#79253

### Issue: 

MO with a tracked finished product are actually splited at validation. However, the qties of the MO are usually set by default to fulfill the maximal demand. As such, component registrations performed form the shopfloor might be completely override by the MO split.

### Steps to reproduce:

- Create 2 storable products tracked by SN: FP and COMP
- Create a BOM for you final product FP:
    - 1 x COMP
    - 1 operation with an instruction of type "Register Consumed Materials" for COMP
- Put 2 serial numbers in WH/Stock for COMP: SN01, SN02
- Create and confirm an MO for 2 units of FP using that BOM
> SN01 and SN02 should be reserved on the move raw
- Go to the shopfloor to the MO
- Click on Register component SN02 > Validate
- Click on the [+] button of the register Production
- Mark the MO as Done > Close Production
> You trigger a consumption warning dialog telling you that you registered more consumed quantity than expected (2 instead of 1) This dialog should not appear in the first place as you registered only 1 unit but suppose it is ok and continue
- Click on "Set quantities and validate"
- Go back to your MO in the back end
#### > It was closed using SN01 rather than the SN you registered.

### Cause of the issue:

Confirming the MO confirmed the move raw and a reservation was made for 2 units as the MO is not splitted yet. However, since the final product is tracked this MO will end up splitted. When you register consumption, the serial number of one of the move line related to the raw move will be updated and the line will be picked:
https://github.com/odoo/enterprise/blob/d4ff42fbcfa3dd297c6cb838b5b03955f12f02a4/mrp_workorder/models/quality.py#L519-L525 However, since at least one of the move line of hte move raw is picked the move its self will become picked:
https://github.com/odoo/odoo/blob/f9e362c45414001077738c2462e9e030f865ec36/addons/stock/models/stock_move.py#L208-L212 This is problematic as picked picked move by pass the set_qty_producing so from now if you were to adapt the qty producing of the MO you would not affect the quantity of the raw move (which is currently at 2: one unpicked move line with SN01 and one picked with SN02): https://github.com/odoo/odoo/blob/f9e362c45414001077738c2462e9e030f865ec36/addons/mrp/models/mrp_production.py#L1218-L1228 Finally, when you click on the Close production, a `_split_productions` process will be started and adpat the demand of the move raw to 1: https://github.com/odoo/odoo/blob/f9e362c45414001077738c2462e9e030f865ec36/addons/mrp/models/mrp_production.py#L1831-L1832 Since the quantity set on the move exceeds this new demand the consumption warning. Note that at this point the backorders of the initial MO were already created and confirm without you dialog to be resolved so that the reservations of these splitted MO could not reserve the SN01 that is still used by your move. Finally, when you "Set quantities and validate" it will adpat the quantity and unreserve the picked move line as this decrease process does not prioritise to unlink unpicked move lines first:

### Fix:

Since registration process through shopfloor and barcode are expected to create picked move lines which will adpat the picked state of the move and since picking the move will automatically pick all the move line, a move line that is not picked in a picked move is a move line that is not expected to be kept. We therefore unlik these move_lines before adapting the demand of the move_raws in the split production.

### Note:

We also tried 2 other fixes of the issue but aborted these other ideas: 
1) try to keep only picked move line at the Validation of the registration component process but this change of behavior was aborted since if instead of clicking on validate you click on "Continue consumption and then on the top right cross button", you would technically have registered only the first SN but you would fall in the situation as above and trigger the same issue.
2) Adapt the condition of that makes a move raw by pass the _set_qty_producing:
https://github.com/odoo/odoo/blob/f9e362c45414001077738c2462e9e030f865ec36/addons/mrp/models/mrp_production.py#L1219-L1221 Since the move is picked for the wrong reason we would instead use: `all(ml.pikced for ml in move.move_line_ids)`
However, this would also require to change the process decrease to unreserve picked move last here:
https://github.com/odoo/odoo/blob/f9e362c45414001077738c2462e9e030f865ec36/addons/stock/models/stock_move.py#L361-L365 Changing the loop to
`reversed(move.move_line_ids.sorted(lambda ml: (not ml.picked, ml.id))` And this would not solve the issue starting post 17.0 since we would still bypass the set_qty producing on the next lines:
https://github.com/odoo/odoo/blob/f9e362c45414001077738c2462e9e030f865ec36/addons/mrp/models/mrp_production.py#L1223-L1225

Community: https://github.com/odoo/odoo/pull/198175

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

Forward-Port-Of: odoo/enterprise#80727
Forward-Port-Of: odoo/enterprise#79591

### Issues:

Creating and validating a picking from the barcode app does not behave correctly with respect to quality check trigger and creation. Depending on your flow, you might end up with QC created twice or with QC not being triggered before validation.

### Cause of the issues:

The quality checks are created during the "_action_confirm" of moves: https://github.com/odoo/enterprise/blob/dd4a1ec4aaa7cbb95d6e40a8bb6ab1d6c88fc7b7/quality_control/models/stock_move.py#L12-L15 
However, depending on where you click in the barcode app, the moves might end up being assigned and hence skip the "_action_confirm" of the picking (which is computed to be assigned) prior to the `_pre_action_done_hook` of the `button_validate` of the picking wich is suppose to return already created quality check:
https://github.com/odoo/odoo/blob/08f0c6481a190349369ead5ab9328886392ddbeb/addons/stock/models/stock_picking.py#L1145-L1147 
In which case, the quality check is not triggered (Issue 1). Furthermore, since  the `_action_confirm` of moves can also be applied to extra moves created to update the demand and to be merged to the initial move during the validation, the quality check creation might be called twice on a move once during its own `action_confirm` and once during the `_action_confirm` of its extra move (Issue2).

### Issue 1:

1. Create a storable product P with a barcode: XXX
2. Go to Quality > Quality Control > Quality Points > New
3. Create a new quality point for your product:
    - Control per: "Operation"
    - Operations: "Receipts"
4. Go to the barcode app > Operations > Receipts > New
5. Scan your product
6. Click on the pencil (key step)
7. Either edit the quantity from the digipad and confirm or go back to the picking and edit it from there.
8. Validate the receipt

#### > Even thought a quality check was created using your quality point for your receipt, it was not triggered before validation.

### Cause of the Issue:

Clicking on the pencil will trigger a call of the `save_barcode_data` which will in turn create a stock move line related to the picking during the write performed on the picking:
https://github.com/odoo/enterprise/blob/dd4a1ec4aaa7cbb95d6e40a8bb6ab1d6c88fc7b7/stock_barcode/controllers/stock_barcode.py#L68-L74 
After this edition of the quantity of the picking will write on the `qty_done` dummy field of that move line which will in turn trigger a call of its inverse method and modify its quantity: https://github.com/odoo/enterprise/blob/dd4a1ec4aaa7cbb95d6e40a8bb6ab1d6c88fc7b7/stock_barcode/models/stock_move_line.py#L58-L61 
Changing the quantity of the ml will then update the state of the move to "assigned" because of these lines:
https://github.com/odoo/odoo/blob/a74684777c27e26639b75b0668bb15afadb78c4f/addons/stock/models/stock_move_line.py#L487-L488 https://github.com/odoo/odoo/blob/a74684777c27e26639b75b0668bb15afadb78c4f/addons/stock/models/stock_move_line.py#L530-L531 https://github.com/odoo/odoo/blob/08f0c6481a190349369ead5ab9328886392ddbeb/addons/stock/models/stock_move.py#L2022-L2023 In turns, the state compute method of the picking will determine that the picking is assigned and the picking will not be confirmed during its `button_validate` prior to the `_pre_action_done_hook` of the `button_validate` as it is not in draft anymore.

### Fix:

The state of the move should stay as draft just as if we didn't created the move line through the pencil if we were to edit the qty_done via the barcode app.

### Note:

The inverse method of the "qty_done" computed field was introduced in 17.0+ by commit: 4f19668c51a90e8c12e57b6353bbe5194f83ca10 during the quantity refactoring so that the issue is not reproducible prior to that version.

### Issue 2:

Same steps 1 -> 5.
6'. click on the +1 button.
7'. Validate > this opens the quality check
8'. Pass the quality check > Validate again
9'. Go to Quality > Quality Control > Quality check

#### > Two quality checks were created isntead of one for your receipt

### Cause of the issue:

At some later point in the button validate of the picking, an `_action_done` is called to put the pickings and its move in done state: https://github.com/odoo/odoo/blob/a74684777c27e26639b75b0668bb15afadb78c4f/addons/stock/models/stock_picking.py#L1157

However, during the `_action_done` of the moves if the quantity of the move exceeds its `product_uom_qty`, extra moves will be created, confirmed and merged back to the move in order to update its `product_uom_qty`:
https://github.com/odoo/odoo/blob/607d63fd4d9c07bac9cb68b2d31d86551e93d5b1/addons/stock/models/stock_move.py#L1885-L1890 https://github.com/odoo/odoo/blob/607d63fd4d9c07bac9cb68b2d31d86551e93d5b1/addons/stock/models/stock_move.py#L1823-L1832 However, the action confirm of this extra move will trigger the same override of the `_action_confirm` that creates a quality check and it will even be called on the original move that was already confirmed and already created its QC since the extra move was merged into it: https://github.com/odoo/enterprise/blob/dd4a1ec4aaa7cbb95d6e40a8bb6ab1d6c88fc7b7/quality_control/models/stock_move.py#L12-L15 
As a result we end up with an extra quality check creation.

### Fix:

We avoid quality check creation during extra move confirmation.

Community: https://github.com/odoo/odoo/pull/192034

opw-4266053
---

Forward-Port-Of: odoo/enterprise#80142
Forward-Port-Of: odoo/enterprise#76301

Currently, an error was occurring when a user tried to reverse a journal entry by following these steps:
- Install ``Accounting`` and ``Payroll`` module
- Enabled payroll entries in Payroll > Configuration > Settings.
- Created a new employee and its corresponding contract in payroll > Create a bank account and enable ``Send Money`` in 
 ``Private Information``
- In ``Contract`` change state from `New` to `Running` > Click on `Payslips`
- Computed the payslip > generated draft journal entries > add lines in journal items and click `Pay` in payslip.
- Go to ``Journal Entry`` and make a ``Reverse Entry``.

ValueError: Expected singleton: res.currency()

The issue occurs at [1] because, when a user makes a payment from a payslip after posting journal entries, the ``currency_id`` is not available.

[1] - https://github.com/odoo/odoo/blob/0583db332efdc884975da1a074c91981d2865c9d/addons/account/wizard/account_payment_register.py#L972

This commit will fix the above issue by providing default company currency when currency is not available.

sentry-6207053954

Forward-Port-Of: odoo/enterprise#77334

### Steps to reproduce:

- Enable "Multi-Steps Routes" in the settings
- Inventory > Configuration > Warehouse Management > Warehouses
- Put your warehouse in manufacturing in 2 steps
- Create an MO for a product and add an operation (no need of component)
- Confirm the MO and go to your operation in the shopfloor
- Click on the 3 dots > Add component > add any component
#### >  Back to the MO: No transfer was created from stock to pre-prod

### Cause of the issue:

When you add component from the shopfloor, you will trigger a call of the `add_product` method to create and confirm the raw move associated to the MO:
https://github.com/odoo/enterprise/blob/2e2efe8421b2f85950e50ff102cdabf98d2d91ab/mrp_workorder/wizard/additional_product.py#L36-L37 However, if the `procure_method`` of this move is not set to mto/mtso it will not trigger other rules in order to generate the other transfers

### Note:

A priori, the issue should not be reproducible in 18.0+ as this part of the code was refactored and the issue was fixed by 235047b68e6a24a14e32b94b1d4a15a580dc5ad2

opw-4236272

Forward-Port-Of: odoo/enterprise#75583
Forward-Port-Of: odoo/enterprise#74178

### Steps to reproduce:

- Create a storable product FP tracked by SN with a BOM:
    - 1 Operation: - instruction: Register Production type (per product)
    - 1 x Comp (storable product in stock)
- Create and confirm an MO for one unit of FP.
- Go to the shopfoor app > open the instruction of your operation
- Type a non-existing serial number in the search bar > Create "new_sn"
> This opens a form view of the stock.lot model
- Save and close the new stock.lot
> Invalid operation: You are not allowed to create or edit a lot or serial number for the components with the operation type
> "Manufacturing". To change this, go on the operation type and tick the box "Create New Lots/Serial Numbers for
> Components"

#### Expected behavior:

The invalid operation should not be raised as the "required" option concerns only componenets and not final products.

### Cause of the issue:

Creating a stock lot will first launch a call of the `_check_create`: https://github.com/odoo/odoo/blob/c25d71f14fa168807f07cd88bed805d15db8add5/addons/stock/models/stock_lot.py#L150-L153 However, since this check does not verifies that the product for which we create the lot is indeed related to a component of the MO it will raise the invalid operation even for final products: https://github.com/odoo/odoo/blob/c25d71f14fa168807f07cd88bed805d15db8add5/addons/mrp/models/stock_lot.py#L11-L17

### Issue 2:

Currently, the `quickCreate` ("Create *sn_name*") option of the lot field of te "register production" dialog calls a `name_create` that will set an error message in the logs as the product_id required field can not be provided neither in the vals or the context of the `name_create`.  You then fall back on the same form dialog than the "Create and edit".  The `quickCreate` option should therefore just be disabled.

Community: https://github.com/odoo/odoo/pull/193965

opw-4452747
---

Forward-Port-Of: odoo/enterprise#79109
Forward-Port-Of: odoo/enterprise#77265