…tion

### Issue:

Creating a new picking from the barcode app and scanning products in order to generate new move lines related to that pikcing will result in a "draft" picking/moves state if the the picking type was a receipt and in an "assigned" picking/moves state for other picking types such as "Delivery" or "Internal Transfer".

### Steps to reproduce the discrepancy:

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: "your operation type"
4. Go to the barcode app > Operations > Receipts > New
5. Scan your product
6. trigger a "save_barcode_data" to create the associated move line for instance by clicking on the pencil icon.
> If your operation type is receipt, the picking, move and move lines
> will be in draft state.
> If your operation type is DElivery or "Internal Transfer" the picking,
> move and move lines will end up being assigned without ever triggering
> any confirmation process.

### Cause of the discrepancy:

The `save_barcode_data` will launch the creation of the move line related to the barcode line you edited from the barcode app. During the create of this 'stock.move.line', an associated move will be created and its initial "state" will be the current state of the picking: https://github.com/odoo/odoo/blob/ba799a020dd2b07c9d6c379e23acee1e6fcc5e0a/addons/stock/models/stock_move_line.py#L354-L356 https://github.com/odoo/odoo/blob/ba799a020dd2b07c9d6c379e23acee1e6fcc5e0a/addons/stock/models/stock_move_line.py#L942 At this point the picking state is "draft" and the move will be correctly created in draft.
However, just a few lines after its creation, we will check if a reservation should be done with that move and if its state should be recomputed:
https://github.com/odoo/odoo/blob/ba799a020dd2b07c9d6c379e23acee1e6fcc5e0a/addons/stock/models/stock_move_line.py#L379-L396 the discrepancy is caused by the fact that
`move._should_bypass_reservation` will be true if the picking is a receipt and false for the other types because you should bypass reservation for moves whose source is not an internal location but you should not for others. This will leave the moves and picking in draft state if its a receipt and update it for other types.

### Example of problematic consequences:

1 -> 5 with "Delivery" picking type.
6. Validate the "Delivery"
> No quality check was created using your quality point.
#### Note: it would trigger a QC if the picking type was a receipt.

### Cause of the issue:

In case of a delivery, the state of the move is assigned without ever passing through an `_action_confirm` see above. This is problematic as quality checks are preceisly created during the confirmation of that move:
https://github.com/odoo/enterprise/blob/954e2110c4f9cbb0a221f644754a71416a485dc4/quality_mrp/models/stock_move.py#L12-L16

### Fix:

Moves created in "draft" state from the barcode app should bypass the reservation process during this creation as the reservation will be done by the confirmation process anyway.

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

### Issue:

Creating a new picking from the barcode app and scanning products in order to generate new move lines related to that pikcing will result in a "draft" picking/moves state if the the picking type was a receipt and in an "assigned" picking/moves state for other picking types such as "Delivery" or "Internal Transfer".

### Steps to reproduce the discrepancy:

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: "your operation type"
4. Go to the barcode app > Operations > Receipts > New
5. Scan your product
6. trigger a "save_barcode_data" to create the associated move line for instance by clicking on the pencil icon.
#### > If your operation type is receipt, the picking, move and move lines will be in draft state. If your operation type is DElivery or "Internal Transfer" the picking, move and move lines will end up being assigned without ever triggering any confirmation process.

### Cause of the discrepancy:

The `save_barcode_data` will launch the creation of the move line related to the barcode line you edited from the barcode app. During the create of this 'stock.move.line', an associated move will be created and its initial "state" will be the current state of the picking: https://github.com/odoo/odoo/blob/ba799a020dd2b07c9d6c379e23acee1e6fcc5e0a/addons/stock/models/stock_move_line.py#L354-L356 https://github.com/odoo/odoo/blob/ba799a020dd2b07c9d6c379e23acee1e6fcc5e0a/addons/stock/models/stock_move_line.py#L942
At this point the picking state is "draft" and the move will be correctly created in draft.
However, just a few lines after its creation, we will check if a reservation should be done with that move and if its state should be recomputed:
https://github.com/odoo/odoo/blob/ba799a020dd2b07c9d6c379e23acee1e6fcc5e0a/addons/stock/models/stock_move_line.py#L379-L396 the discrepancy is caused by the fact that
`move._should_bypass_reservation` will be true if the picking is a receipt and false for the other types because you should bypass reservation for moves whose source is not an internal location but you should not for others. This will leave the moves and picking in draft state if its a receipt and update it for other types.

### Example of problematic consequences:

1 -> 5 with "Delivery" picking type.
6. Validate the "Delivery"
#### > No quality check was created using your quality point.
Note: it would trigger a QC if the picking type was a receipt.

### Cause of the issue:

In case of a delivery, the state of the move is assigned without ever passing through an `_action_confirm` see above. This is problematic as quality checks are preceisly created during the confirmation of that move:
https://github.com/odoo/enterprise/blob/954e2110c4f9cbb0a221f644754a71416a485dc4/quality_mrp/models/stock_move.py#L12-L16

### Fix:

Moves created in "draft" state from the barcode app should bypass the reservation process during this creation as the reservation will be done by the confirmation process anyway.

opw-4266053