[16.0][ADD] stock_picking_backorder_reason

[rousseldenis]

In some flows, one may want to let the user have the choice on something more understandable in his context. So, instead choosing a backorder strategy, let him choose a 'reason'.

Let define some backorder reasons and associate the strategy on those reasons.

We define also a new strategy which is 'Use partner option' to delegate it on partner level.

[rousseldenis]

@lmignon Could you update your review ?

[lmignon]

Thank you @rousseldenis LGTM (Core review + functional tests)

[lmignon]

@rousseldenis The licence must be LGPL since this addon will be mixed with helpdesk.

[jbaudoux]

@rousseldenis @lmignon I don't like the module name and how the module solves the initial requirement.

Basically, we want to configure on the supplier if he supports backorder in his system or not, and this in order to not keep a reception backorder open in odoo for nothing as you will never receive the missing goods.

So mainly we need to configure a backorder strategy on the supplier.
Then we need to be able to process a reception, make intermediate validation while receiving (like when a pallet is received and you want to be able to put it away before continuing receiving, or like when you want to urgently receive a single product from the reception and continue later) and when everything is received, apply the supplier backorder strategy on the remaining backorder.
When you validate the picking, in standard you get a wizard asking if you want a backorder or not. Instead of asking if we want a backorder or not, you could ask if all received goods have been processed and if not then create a backorder (this could even be configured on the reception picking as backorder strategy to always), otherwise apply the supplier backorder strategy. If no supplier strategy is configured on the supplier, then we even don't need to ask anything, we just apply standard.
The reason basically serves this purpose of asking if all goods have been received.

Besides this, in my opinion, you cannot mirror this feature for sales in the same way. So all the code to try to be generic and cover sales looks useless to me.

I would simplify a lot this module to just keep the basic need regarding supplier and rename the module to reflect that it basically adds a supplier backorder strategy.

[rousseldenis]

Besides this, in my opinion, you cannot mirror this feature for sales in the same way. So all the code to try to be generic and cover sales looks useless to me.

We have flows where customer has particular requirement on this, so we need to keep that.

I would simplify a lot this module to just keep the basic need regarding supplier and rename the module to reflect that it basically adds a supplier backorder strategy.

From my preceding remark, I agree partly on this as this could be renamed 'backorder_partner_stragey' or 'backorder_third_party_strategy' to reflect a module centered on the 'partner' strategy, letting the 'reason' as accessory and not the main functionnality.

[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.

[rousseldenis]

I would simplify a lot this module to just keep the basic need regarding supplier and rename the module to reflect that it basically adds a supplier backorder strategy.

We have the case for customers too.