[FIX] stock,mrp: scrap kit

[adwid]

When scrapping a kit, it leads to incorrect behaviours

Case 01:

1. Create a storable kit with one storable component
2. Validate a scrap order with that kit
3. Open the product moves

Error: we moved the kit instead of its component

We first create a draft SM with its SML:

odoo/addons/stock/models/stock_scrap.py

Line 145 in 72c4a23

move = self.env['stock.move'].create(scrap._prepare_move_values())

odoo/addons/stock/models/stock_scrap.py

Line 112 in 72c4a23

def _prepare_move_values(self):

During the SML creation, we check if we should recompute the state
of the SM:

odoo/addons/stock/models/stock_move_line.py

Lines 344 to 355 in dc0917d

	move = move_line.move_id
	if move:
	reservation = not move._should_bypass_reservation()
	else:
	reservation = product.type == 'product' and not location.should_bypass_reservation()
	if move_line.quantity and reservation:
	self.env.context.get('reserved_quant', self.env['stock.quant'])._update_reserved_quantity(
	product, location, move_line.quantity_product_uom, lot_id=move_line.lot_id, package_id=move_line.package_id, owner_id=move_line.owner_id)
	if move:
	move_to_recompute_state |= move
	move_to_recompute_state._recompute_state()

reservation is True, the SML has a quantity -> we recompute the
state of the SM -> it is now assigned
Back to the scrap, we now _action_done the kit SM

odoo/addons/stock/models/stock_scrap.py

Line 147 in 72c4a23

move.with_context(is_scrap=True)._action_done()

which leads to

odoo/addons/stock/models/stock_move.py

Lines 1827 to 1830 in 6ed0d0c

	moves = self.filtered(
	lambda move: move.state == 'draft'
	or float_is_zero(move.product_uom_qty, precision_rounding=move.product_uom.rounding)
	)._action_confirm(merge=False) # MRP allows scrapping draft moves

Here is the problem: the SM has a demand, its state is not draft
-> we don't confirm it
-> we don't explode it
Hence the error. This is the reason why the commit stops providing
the scrap SM with an initial demand. That way, we will explode the
SM and everything will work as expected

Case 02:

1. Create a consumable kit with one storable component
2. Validate a scrap order with that kit

Error: a server error is raised "Missing record [...]"

This time, reservation is False (the diff comes from the kit
type, consu vs stor, c.f. _should_bypass_reservation). Therefore,
we explode it. Since we are in scrap mode, we generate SM with a
zero demand:

odoo/addons/mrp/models/stock_move.py

Lines 464 to 466 in 68f981d

	for bom_line, line_data in lines:
	if float_is_zero(move.product_uom_qty, precision_rounding=move.product_uom.rounding) or self.env.context.get('is_scrap'):
	phantom_moves_vals_list += move._generate_move_phantom(bom_line, 0, line_data['qty'])

odoo/addons/mrp/models/stock_move.py

Line 527 in 68f981d

def _generate_move_phantom(self, bom_line, product_qty, quantity_done):

Back to _action_done, we create the extra moves if needed:

odoo/addons/stock/models/stock_move.py

Lines 1847 to 1853 in 6ed0d0c

	# Create extra moves where necessary
	for move in moves:
	if move.state == 'cancel' or (move.quantity <= 0 and not move.is_inventory):
	continue
	if not move.picked:
	continue
	moves_ids_todo |= move._create_extra_move().ids

Here, our component SM has a done qty greater than its demand
(reminder: it demand is zero), so we will create the extra move,
confirm it and merge it with the initial one:

odoo/addons/stock/models/stock_move.py

Lines 1799 to 1802 in 6ed0d0c

	extra_move_vals = self._prepare_extra_move_vals(extra_move_quantity)
	self = self.with_context(avoid_putaway_rules=True, extra_move_mode=True)
	extra_move = self.copy(default=extra_move_vals)
	return extra_move.with_context(merge_extra=True, do_not_unreserve=True)._action_confirm(merge_into=self)

Buuuuut... Step 2 in the use case, we validate the scrap order.
Since we don't have such product on hand, we trigger a wizard with
some default values:

odoo/addons/stock/models/stock_scrap.py

Lines 204 to 219 in 72c4a23

	ctx.update({
	'default_product_id': self.product_id.id,
	'default_location_id': self.location_id.id,
	'default_scrap_id': self.id,
	'default_quantity': self.product_uom_id._compute_quantity(self.scrap_qty, self.product_id.uom_id),
	'default_product_uom_name': self.product_id.uom_name
	})
	return {
	'name': self.product_id.display_name + _(': Insufficient Quantity To Scrap'),
	'view_mode': 'form',
	'res_model': 'stock.warn.insufficient.qty.scrap',
	'view_id': self.env.ref('stock.stock_warn_insufficient_qty_scrap_form_view').id,
	'type': 'ir.actions.act_window',
	'context': ctx,
	'target': 'new'
	}

And... Now you see where I'm going: when we create the extra move,
we still have these default values in the context -> the extra move
has a demand and(!) a done qty to 1. We merge it with the initial
move: we are now scrapping a component with a demand equal to one
and a done qty equal to 2. It will later lead to other
inconsistencies (among them, the server error raised)

opw-4090951

[robodoo]

[Whenrow]

robodoo r+

[robodoo]

@Whenrow you may want to rebuild or fix this PR as it has failed CI.

[adwid]

robodoo r+

[robodoo]

@adwid you can't review+. Skill issue.

[adwid]

[Whenrow]

robodoo r+

[adwid]

Trop aimable

[robodoo]

@adwid @Whenrow 'ci/runbot' failed on this reviewed PR.

[adwid]

robodoo override=ci/style

[robodoo]

@adwid you are not allowed to override 'ci/style'.

[adwid]

We will never be friends, damn bot

[Whenrow]

robodoo override=ci/style

absolutelly not @adwid disguised as @Whenrow

[robodoo]

@Whenrow you are not allowed to override 'ci/style'.

[agr-odoo]

let's roll
@robodoo override=ci/style

[robodoo]

@agr-odoo you are not allowed to override 'ci/style'.

[d-fence]

robodoo override=ci/style

[Whenrow]

robodoo r+

[adwid]

Odoo 18 will shine thanks to you both