[17.0][MIG] repair_picking_after_done: Migration to 17.0

[ppyczko]

Module migrated to version 17.0

cc https://github.com/APSL 162593

@miquelalzanillas @lbarry-apsl @mpascuall @peluko00 @javierobcn @BernatObrador please review

• Issue Migration to version 17.0 #36

Depends on:

• [repair_stock] [17.0][MIG] repair_stock: Migration to 17.0 #63

An [IMP] has been added to prevent the creation of transfers exceeding remaining quantities in repair orders.

[mpascuall]

LGTM, tested in runboat

[peluko00]

LGTM, code review

[ppyczko]

Hi @LoisRForgeFlow, sorry to ping directly. Could you please review this module and the dependency (#63) when you have a moment? Thank you!

[BernatObrador]

LGTM

[LoisRForgeFlow]

/ocabot migration repair_picking_after_done

[LoisRForgeFlow]

@ppyczko Dependency merged, you can remove the requirements commit

[ppyczko]

@ppyczko Dependency merged, you can remove the requirements commit

Done! Thank you @LoisRForgeFlow

[LoisRForgeFlow]

Overall looks good! One detail that I realized while testing (probably hapening in previous versions) is that when creating a backorder of one of these repair after done transfers, the backorder is not linked to the reapair order and you cannot find it navigating with the smart button.

[OCA-git-bot]

This PR has the approved label and has been created more than 5 days ago. It should therefore be ready to merge by a maintainer (or a PSC member if the concerned addon has no declared maintainer). 🤖

[ppyczko]

Overall looks good! One detail that I realized while testing (probably hapening in previous versions) is that when creating a backorder of one of these repair after done transfers, the backorder is not linked to the reapair order and you cannot find it navigating with the smart button.

Thank you for taking the time to review this module and for your feedback @LoisRForgeFlow!

While reviewing your input, I found out that these backorders are not only not linked to the repair order, but they actually aren’t created at all. This is due to this piece of code in core of Odoo:

• When creating a 'stock.move', the '_action_done' method checks if it has to create any backorders and, if it does, it eventually calls the '_split' method: https://github.com/odoo/odoo/blob/17.0/addons/stock/models/stock_move.py#L1900
• This '_split' method prevents stock moves from being split when they’re associated with a repair order, meaning that no backorders will be created: https://github.com/odoo/odoo/blob/17.0/addons/repair/models/stock_move.py#L189

This behavior seems intentional and aligns with the idea that, once a repair is marked as done, the items are fully ready and available, not partially available.

In my view, this makes sense -- backorders after a completed repair could cause confusion. In my opinion, when a repair is completed, it implies that all items in that order are ready to be returned to the customer. A backorder might imply partial availability, which doesn’t seem to fit with the concept of a finished repair.

That said, I may be missing some use case or context here, so I’d really appreciate any thoughts or perspectives you might have on this. If there’s a scenario where backorders after a repair could add value, I’d love to understand it better.

After all, if you think we do need backorders, it would be as easy as overriding this _split method, and we could make that adjustment quickly.

[LoisRForgeFlow]

@ppyczko Thanks for investigating and for the detailed feedback.

For me, Odoo has decided that they do not want to handle backorders of repairs, I am not against that as long as the code is consistent with that idea and it seems so, as you pointed out in the code. That part is fine, but here we are talking about an additional operation/transfer that takes places just after the repair is done, this operation is not anything else than an internal operation or a delivery like any other, it is just linked to the repair order for traceability purposes. Therefore from my perspective, this post-repair operation should allow backorders as any other, whatever the reason, I don't see why we should not allow that.

In short, I would keep restriction to split stock moves of the repair order and I would allow split in this related post-repair operations.

Does this make sense to you?