- Install stock
- Go to Inventory > Configuration > Settings and enable "Lots" and "Storage Locations"
- Create a Product tracked By Lots (i.e. Product X)
- Go to Inventory > Operations > Inventory Adjustments
- Create an Inventory Adjustment for Product X:

     Product   |   Location   |   Lot/SN   |   Real Quantity
 -------------------------------------------------------------
    Product X  |   WH/Stock   |   LOT 01   |       20
    Product X  |   WH/Stock   |            |       10

- Validate Inventory
- Go to Inventory > Operations > Transfers and create one:
  * Source Location: WH/Stock
  * Destination Location: WH/Stock/Shelf1
  * Operation Type: Internal Transfers
  * Operations:
    [Product: Product X, Initial Demand: 25]
- Save Transfer, Mark As Todo and Check availability
- Click on list icon of Operation line for Product X to display Detailed Operations
- 20 units of LOT 01 and 5 units without lot have been reserved
- Set LOT 01 for the 5 reserved units without lot and confirm
- Open Detailed Operations again
- There are now 20 units of LOT 01 and 5 units of LOT 01
- Remove the row with 5 units and confirm
- Check availability and open Detailed Operation
- There is now only a row with 25 reserved units of LOT 01
- Unreserve
The following errror is raised:
"It is not possible to unreserve more products of P than you have in stock."

It happens because the system is not able to manage quants with lots and
wihtout lots at the same time. When modifying the move line to 25
reserved units. It's composed of 20 quants with lot and 5 quants without
lot. And when unreserving it will check if there is a quants with 25
units with the lot and if it's not found 25 units without lot. But never
25 units of quants with lots and without lots.

opw-2419444

Close odoo#64497

closes odoo#66347

X-original-commit: 3b59d0b
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>

It happens that the `stock.quant.reserved_quantity` and `stock.move.line.product_qty`
for the same parameters are not equals (due to some bugs in the past)

It could implies that it doesn't exist enough reserved quantity on the
quant when a user try to unreserve a stock.move.line resulting in the
UserError 'It is not possible to unreserve more products of %s than you
have in stock'

However on current stable version (13.0 and 14.0) a lot of PR already
fixed a lot of issue as:
odoo#69377
odoo#66347
odoo#61758
odoo#54355
odoo#43180
odoo#70975
for example (there is more than that)

So the idea is to provide a way to unlock the database manually for
stable but not in the new version to be able to analyse them and find
possible bugs responssible for the desynchronization.

The server action check all the quants and their relative move line
to check if match correctly. If not it will remove the reservation
from both. It could remove the reservation from some `pickings` and
`stock.move`

related to odoo#62139

It happens that the `stock.quant.reserved_quantity` and `stock.move.line.product_qty`
for the same parameters are not equals (due to some bugs in the past)

It could implies that it doesn't exist enough reserved quantity on the
quant when a user try to unreserve a stock.move.line resulting in the
UserError 'It is not possible to unreserve more products of %s than you
have in stock'

However on current stable version (13.0 and 14.0) a lot of PR already
fixed a lot of issue as:
odoo#69377
odoo#66347
odoo#61758
odoo#54355
odoo#43180
odoo#70975
for example (there is more than that)

So the idea is to provide a way to unlock the database manually for
stable but not in the new version to be able to analyse them and find
possible bugs responssible for the desynchronization.

The server action check all the quants and their relative move line
to check if match correctly. If not it will remove the reservation
from both. It could remove the reservation from some `pickings` and
`stock.move`

related to odoo#62139

It happens that the `stock.quant.reserved_quantity` and `stock.move.line.product_qty`
for the same parameters are not equals (due to some bugs in the past)

It could implies that it doesn't exist enough reserved quantity on the
quant when a user try to unreserve a stock.move.line resulting in the
UserError 'It is not possible to unreserve more products of %s than you
have in stock'

However on current stable version (13.0 and 14.0) a lot of PR already
fixed a lot of issue as:
odoo#69377
odoo#66347
odoo#61758
odoo#54355
odoo#43180
odoo#70975
for example (there is more than that)

So the idea is to provide a way to unlock the database manually for
stable but not in the new version to be able to analyse them and find
possible bugs responssible for the desynchronization.

The server action check all the quants and their relative move line
to check if match correctly. If not it will remove the reservation
from both. It could remove the reservation from some `pickings` and
`stock.move`

related to odoo#62139

It happens that the `stock.quant.reserved_quantity` and `stock.move.line.product_qty`
for the same parameters are not equals (due to some bugs in the past)

It could implies that it doesn't exist enough reserved quantity on the
quant when a user try to unreserve a stock.move.line resulting in the
UserError 'It is not possible to unreserve more products of %s than you
have in stock'

However on current stable version (13.0 and 14.0) a lot of PR already
fixed a lot of issue as:
#69377
#66347
#61758
#54355
#43180
#70975
for example (there is more than that)

So the idea is to provide a way to unlock the database manually for
stable but not in the new version to be able to analyse them and find
possible bugs responssible for the desynchronization.

The server action check all the quants and their relative move line
to check if match correctly. If not it will remove the reservation
from both. It could remove the reservation from some `pickings` and
`stock.move`

related to #62139

closes #79180

Signed-off-by: William Henrotin (whe) <whe@odoo.com>

It happens that the `stock.quant.reserved_quantity` and `stock.move.line.product_qty`
for the same parameters are not equals (due to some bugs in the past)

It could implies that it doesn't exist enough reserved quantity on the
quant when a user try to unreserve a stock.move.line resulting in the
UserError 'It is not possible to unreserve more products of %s than you
have in stock'

However on current stable version (13.0 and 14.0) a lot of PR already
fixed a lot of issue as:
odoo#69377
odoo#66347
odoo#61758
odoo#54355
odoo#43180
odoo#70975
for example (there is more than that)

So the idea is to provide a way to unlock the database manually for
stable but not in the new version to be able to analyse them and find
possible bugs responssible for the desynchronization.

The server action check all the quants and their relative move line
to check if match correctly. If not it will remove the reservation
from both. It could remove the reservation from some `pickings` and
`stock.move`

related to odoo#62139

X-original-commit: d99e173

It happens that the `stock.quant.reserved_quantity` and `stock.move.line.product_qty`
for the same parameters are not equals (due to some bugs in the past)

It could implies that it doesn't exist enough reserved quantity on the
quant when a user try to unreserve a stock.move.line resulting in the
UserError 'It is not possible to unreserve more products of %s than you
have in stock'

However on current stable version (13.0 and 14.0) a lot of PR already
fixed a lot of issue as:
#69377
#66347
#61758
#54355
#43180
#70975
for example (there is more than that)

So the idea is to provide a way to unlock the database manually for
stable but not in the new version to be able to analyse them and find
possible bugs responssible for the desynchronization.

The server action check all the quants and their relative move line
to check if match correctly. If not it will remove the reservation
from both. It could remove the reservation from some `pickings` and
`stock.move`

related to #62139

closes #81127

X-original-commit: d99e173
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Arnold Moyaux <arm@odoo.com>

It happens that the `stock.quant.reserved_quantity` and `stock.move.line.product_qty`
for the same parameters are not equals (due to some bugs in the past)

It could implies that it doesn't exist enough reserved quantity on the
quant when a user try to unreserve a stock.move.line resulting in the
UserError 'It is not possible to unreserve more products of %s than you
have in stock'

However on current stable version (13.0 and 14.0) a lot of PR already
fixed a lot of issue as:
odoo#69377
odoo#66347
odoo#61758
odoo#54355
odoo#43180
odoo#70975
for example (there is more than that)

So the idea is to provide a way to unlock the database manually for
stable but not in the new version to be able to analyse them and find
possible bugs responssible for the desynchronization.

The server action check all the quants and their relative move line
to check if match correctly. If not it will remove the reservation
from both. It could remove the reservation from some `pickings` and
`stock.move`

related to odoo#62139

closes odoo#81127

X-original-commit: d99e173
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Arnold Moyaux <arm@odoo.com>

It happens that the `stock.quant.reserved_quantity` and `stock.move.line.product_qty`
for the same parameters are not equals (due to some bugs in the past)

It could implies that it doesn't exist enough reserved quantity on the
quant when a user try to unreserve a stock.move.line resulting in the
UserError 'It is not possible to unreserve more products of %s than you
have in stock'

However on current stable version (13.0 and 14.0) a lot of PR already
fixed a lot of issue as:
odoo#69377
odoo#66347
odoo#61758
odoo#54355
odoo#43180
odoo#70975
for example (there is more than that)

So the idea is to provide a way to unlock the database manually for
stable but not in the new version to be able to analyse them and find
possible bugs responssible for the desynchronization.

The server action check all the quants and their relative move line
to check if match correctly. If not it will remove the reservation
from both. It could remove the reservation from some `pickings` and
`stock.move`

related to odoo#62139

closes odoo#79180

Signed-off-by: William Henrotin (whe) <whe@odoo.com>

It happens that the `stock.quant.reserved_quantity` and `stock.move.line.product_qty`
for the same parameters are not equals (due to some bugs in the past)

It could implies that it doesn't exist enough reserved quantity on the
quant when a user try to unreserve a stock.move.line resulting in the
UserError 'It is not possible to unreserve more products of %s than you
have in stock'

However on current stable version (13.0 and 14.0) a lot of PR already
fixed a lot of issue as:
odoo#69377
odoo#66347
odoo#61758
odoo#54355
odoo#43180
odoo#70975
for example (there is more than that)

So the idea is to provide a way to unlock the database manually for
stable but not in the new version to be able to analyse them and find
possible bugs responssible for the desynchronization.

The server action check all the quants and their relative move line
to check if match correctly. If not it will remove the reservation
from both. It could remove the reservation from some `pickings` and
`stock.move`

related to odoo#62139

closes odoo#81127

X-original-commit: d99e173
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Arnold Moyaux <arm@odoo.com>

It happens that the `stock.quant.reserved_quantity` and `stock.move.line.product_qty`
for the same parameters are not equals (due to some bugs in the past)

It could implies that it doesn't exist enough reserved quantity on the
quant when a user try to unreserve a stock.move.line resulting in the
UserError 'It is not possible to unreserve more products of %s than you
have in stock'

However on current stable version (13.0 and 14.0) a lot of PR already
fixed a lot of issue as:
odoo/odoo#69377
odoo/odoo#66347
odoo/odoo#61758
odoo/odoo#54355
odoo/odoo#43180
odoo/odoo#70975
for example (there is more than that)

So the idea is to provide a way to unlock the database manually for
stable but not in the new version to be able to analyse them and find
possible bugs responssible for the desynchronization.

The server action check all the quants and their relative move line
to check if match correctly. If not it will remove the reservation
from both. It could remove the reservation from some `pickings` and
`stock.move`

related to odoo/odoo#62139

closes odoo/odoo#79180

Signed-off-by: William Henrotin (whe) <whe@odoo.com>