[18.0][FIX] project_task_stock: Set picked = True for pending moves

[victoralmau]

Set picked = True for pending moves

You must set picked = True for pending moves to prevent the picking process from failing if there are moves with both picked = True and picked = False

Example use case:

• Add a line item for Product A, for which demand exceeds current stock
• Click the "Check Material Availability" button
• Click "Transfer Materials"
• Add more stock of Product A to meet demand
• Add a line item for Product B
• Click the "Check Material Availability" button
• Click "Transfer Materials"
• All line items will be completed

Please @pedrobaeza and @carlos-lopez-tecnativa can you review it?

@Tecnativa TT64069

[pedrobaeza]

Shouldn't be all put to picked=True instead if they are going to be validated?

[victoralmau]

Shouldn't be all put to picked=True instead if they are going to be validated?

I decided to leave False as is and let the validation process handle it accordingly (set it to True); besides, it's a compute. But if you'd prefer, I can change it.

[pedrobaeza]

It's a compute with an inverse, and what makes it is to set that value for the stock.move.line. I think we should set it as expected if you did the picking through the UI, which is True.

[carlos-lopez-tecnativa]

I tested it by following the steps, but it doesn't work as expected for me. The moves are not validated.

Could you please check this record: http://oca-project-18-0-pr1787-f9d3523de1c5.runboat.odoo-community.org/odoo/project/6/tasks/55, or let me know if I'm missing something?

I think you need to handle the response from button_validate when it needs to ask for a backorder, or call _action_done directly instead of button_validate.

[victoralmau]

I tested it by following the steps, but it doesn't work as expected for me. The moves are not validated.

Could you please check this record: http://oca-project-18-0-pr1787-f9d3523de1c5.runboat.odoo-community.org/odoo/project/6/tasks/55, or let me know if I'm missing something?

I think you need to handle the response from button_validate when it needs to ask for a backorder, or call _action_done directly instead of button_validate. <img alt="Image" width="1638" height="672" src="https://private-user-images.githubusercontent.com/174346082/633664374-113fe5e4-3f9d-4caa-9ed4-cc2936516bab.png?

We don't want to create backorders. If there isn't enough stock for what you're requesting, you'll need to increase the stock for that product in order to complete the transfer, cancel that line (stock.move) with button, or change the task stage and delete the line.

[carlos-lopez-tecnativa]

We don't want to create backorders. If there isn't enough stock for what you're requesting, you'll need to increase the stock for that product in order to complete the transfer, cancel that line (stock.move) with button, or change the task stage and delete the line.

There are too many steps for the user, and this limitation is not mentioned in the ROADMAP.

If you call _action_done() with the context skip_backorder=True, the moves should be validated with the specified quantities. Why not do it this way?

[carlos-lopez-tecnativa]

Additionally, when you create the task directly from the form view and add the moves, you cannot save it because the locations and operation types are not set.

You need to save the task first before you can edit the moves. Could you please check this as well?

project_task_stock.mp4

[victoralmau]

We don't want to create backorders. If there isn't enough stock for what you're requesting, you'll need to increase the stock for that product in order to complete the transfer, cancel that line (stock.move) with button, or change the task stage and delete the line.

There are too many steps for the user, and this limitation is not mentioned in the ROADMAP.

If you call _action_done() with the context skip_backorder=True, the moves should be validated with the specified quantities. Why not do it this way?

It doesn't currently behave that way, and users who follow these steps do NOT expect it to behave that way (in my opinion): creating extra lines to account for the difference will just make things more confusing.

[pedrobaeza]

For clarification, picked field is used to "sign" the lines that have been manually touched, and to force that quantities even if no quantities at hand. With that in mind, what is the problem that Carlos depicted?

[victoralmau]

For clarification, picked field is used to "sign" the lines that have been manually touched, and to force that quantities even if no quantities at hand. With that in mind, what is the problem that Carlos depicted?

The issue regarding #1787 (review) was explained at #1787 (comment) (you should not create a backorder).

The issue regarding #1787 (comment) was fixed at #1789

[pedrobaeza]

But please clarify me one thing: right now, if you have at hand 2 units of a product, and you put to consume 3 in a task, when doing the transfer, the stock at hand becomes -1, isn't it?

[victoralmau]

But please clarify me one thing: right now, if you have at hand 2 units of a product, and you put to consume 3 in a task, when doing the transfer, the stock at hand becomes -1, isn't it?

If there isn't enough stock, the move will not be done; therefore, you'll need to increase the stock to 3 or change the line item to 2 in order to complete it.

[pedrobaeza]

But is there any message saying that there isn't enough stock to fulfill the requirements?

[victoralmau]

But is there any message saying that there isn't enough stock to fulfill the requirements?

No, there is currently no message about this, nor is the line displayed differently; in any case, this could be addressed in another PR.

[pedrobaeza]

Then you click on the button... and nothing happens?

[victoralmau]

Then you click on the button... and nothing happens?

Without this PR:

• If 2 units were specified but only 1 was available, the stock.move line would remain as picked=False, meaning that even if it was later updated to 1 unit (or the stock was increased to 2), the picking could not be done. This is the use case explained in this PR that we aim to resolve.

Regardless of that, if there is a line item that does not have sufficient stock, a feature should be implemented in another PR to indicate this (a warning at the top, for example).

[carlos-lopez-tecnativa]

If you plan to improve this in another PR, that's OK; I won't block this PR on it.

Please take two things into account:

Once the stock.move is confirmed, you cannot edit the quantities. For example, if I have 2 units available in stock and set the required quantity to 3, I cannot change it back to 2. This means there are too many steps for the user: they have to cancel the line and create a new one.

My suggestion is not to create backorders. If 3 units are requested but only 2 are available, instead of calling button_validate(), which returns an action in the backend to display the backorder wizard, I suggest calling _action_done() directly. The backorder wizard is not displayed in this flow.

Alternatively, if you handle this in another way where the user is informed that the moves cannot be validated because there is not enough stock, please take the first comment into account and make it easy for the user to edit the quantity.

Regarding these changes, LGTM.

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