[14.0][FIX] shopfloor_reception: Ensure state assign of remaining move

[mt-software-de]

If there is not all processed for one move, we have to ensure that the state of the remaining move is still assigned.
Otherwise the last remaining qty of this move will be not split into a own transfer.

wms/shopfloor_reception/services/reception.py

Line 1297 in c9cf770

return selected_line.move_id.extract_and_action_done()

wms/shopfloor/models/stock_move.py

Line 100 in c9cf770

moves = self.filtered(lambda m: m.state == "assigned")

cc @jbaudoux @TDu @mmequignon

[OCA-git-bot]

Hi @JuMiSanAr, @mmequignon,
some modules you are maintaining are being modified, check this out!

[mt-software-de]

@TDu @mmequignon @jbaudoux
why did we choose to call the recompute_state?
I think that's not necessary since we calling action_assign immediately afterwards.

wms/shopfloor_reception/services/reception.py

Line 1303 in c9cf770

new_move._action_assign()

[mt-software-de]

ping @jbaudoux @TDu

[jbaudoux]

It looks good according to the test but we need to be careful because all tests seem to rely on the fact that move lines are created by the picking type configuration.
In our case, the picking type is configured to not create move lines. The main difference is that the move line is created by the user and the quantity todo is 0. This could have an impact on partial processing.
Can you extend the tests to cover our real usage of the module ?

[github-actions]

There hasn't been any activity on this pull request in the past 4 months, so it has been marked as stale and it will be closed automatically if no further activity occurs in the next 30 days.
If you want this PR to never become stale, please ask a PSC member to apply the "no stale" label.

[github-actions]

There hasn't been any activity on this pull request in the past 4 months, so it has been marked as stale and it will be closed automatically if no further activity occurs in the next 30 days.
If you want this PR to never become stale, please ask a PSC member to apply the "no stale" label.

[OCA-git-bot]

Hi @mmequignon, @JuMiSanAr,
some modules you are maintaining are being modified, check this out!

[jbaudoux]

Cc @rousseldenis

[mt-software-de]

It looks good according to the test but we need to be careful because all tests seem to rely on the fact that move lines are created by the picking type configuration.
In our case, the picking type is configured to not create move lines. The main difference is that the move line is created by the user and the quantity todo is 0. This could have an impact on partial processing.
Can you extend the tests to cover our real usage of the module ?

I try to extend the Test this week. Then it could be merged and Forward ported.

[mt-software-de]

It looks good according to the test but we need to be careful because all tests seem to rely on the fact that move lines are created by the picking type configuration. In our case, the picking type is configured to not create move lines. The main difference is that the move line is created by the user and the quantity todo is 0. This could have an impact on partial processing. Can you extend the tests to cover our real usage of the module ?

I checked it again and i am now a little confused. I think the test reflects exactly what's happening. A purchase is created and confirmed, which creates a transfer with moves and move lines. The move line is then only partially processed, which creates a new completed move. The old move must then reflect the remaining quantity with the state assigned. Or am i wrong?

[jbaudoux]

It looks good according to the test but we need to be careful because all tests seem to rely on the fact that move lines are created by the picking type configuration. In our case, the picking type is configured to not create move lines. The main difference is that the move line is created by the user and the quantity todo is 0. This could have an impact on partial processing. Can you extend the tests to cover our real usage of the module ?

I checked it again and i am now a little confused. I think the test reflects exactly what's happening. A purchase is created and confirmed, which creates a transfer with moves and move lines. The move line is then only partially processed, which creates a new completed move. The old move must then reflect the remaining quantity with the state assigned. Or am i wrong?

@mt-software-de The question was what will happen if the picking type is configured to not create move lines which is your use case. As there are no tests with this configuration, you better ensure there are no regression

[github-actions]

There hasn't been any activity on this pull request in the past 4 months, so it has been marked as stale and it will be closed automatically if no further activity occurs in the next 30 days.
If you want this PR to never become stale, please ask a PSC member to apply the "no stale" label.