ddmrp: about qualified demand computation and multi-steps delivery route

[sebalix]

Module

Question/issue about ddmrp module.

Bug description

Hi, we encountered an issue lately with the qualified demand computed on buffers. Right now - if I'm not wrong - it is computed from outgoing moves like delivery ones within a given horizon.

In standard Odoo this is working well with a "Ship only" delivery route, as goods are reserved as soon as SO are confirmed, so the reserved qties are removed from the qualified demand with this line in _get_demand_by_days:

            demand_by_days[date] += move.product_qty - move.reserved_availability

If the WH is configured with several delivery steps, this starts to give an unexpected qualified demand:

1. SO is confirmed, generating e.g. pick/ship transfers
2. Goods of PICK are reserved
3. Goods of OUT aren't reserved, as such they are include in the qualified demand computation

Expected behavior

We think the goods of outgoing moves having ancestors with reservation should not be part of the qualified demand as we are about to ship the goods, or at least they are reserved by ancestor moves on this purpose.

Additional context
In details we face this issue in the following scenario that implies the moves release mechanism:

1. SO is confirmed, OUT moves are generated (without ancestor moves nor reservation as it is not yet released)
2. OUT moves are then included in the qualified demand computation as expected
3. We release the OUT moves, and start to work on the PICK (goods reserved)
4. We refresh the buffer and its qualified demand still include the qty of the OUT move
5. We validate the PICK so the goods are now reserved on the OUT move
6. We refresh the buffer again and its qualified demand gets updated as the qty of the OUT has been removed

This behavior was quite confusing for users when they refresh the buffer manually during the working day. Generally buffers are automatically refreshed during the night, and operations released in the morning and processed during the day so in this case there it is working fine.

About solutions
I was thinking about a new module not tied to DDMRP that adds a computed field on stock.move to get the reserved qties based on the ancestor moves (let's call it reserved_availability_in_preparation, and use this field instead of reserved_availability in _get_demand_by_days to not include the reserved qty of ancestor moves in the qualified demand.

Or are we doing something wrong here?

cc @LoisRForgeFlow @JordiBForgeFlow

[LoisRForgeFlow]

Hi @sebalix

I'm not yet able to reproduce the issue. I focused on this:

We release the OUT moves, and start to work on the PICK (goods reserved)
We refresh the buffer and its qualified demand still include the qty of the OUT move

In the runboat I created a new product (qualified demand threshold 10), set up 2-step delivery, create a SO for 11 units and reserved the PICK. Result:

As soon as it is reserved, it is excluded from the qualified demand. As it is defined in the code:

ddmrp/ddmrp/models/stock_buffer.py

Line 1619 in 7223861

demand_by_days[date] += move.product_qty - move.reserved_availability

Also, the other move, the OUT is not considered because it is outside the WH/Stock location.

Can it be that in your case the buffer is placed at WH location? Before digging it more I prefer to confirm this with you, to be sure that I can reproduce your use case.

Thanks,

[sebalix]

Hello @LoisRForgeFlow, thank you for taking time to check this.

You are guessing right, in our case the majority of buffers are configured on the warehouse location, and those reported having this issue are configured with such location.

EDIT: if you arrive to the same conclusion, I can take care of the fix as I proposed, unless you have another solution in mind.

[LoisRForgeFlow]

Hi @sebalix

Perfect, I continued reproducing the issue and the critial point is indeed true:

We release the OUT moves, and start to work on the PICK (goods reserved)
We refresh the buffer and its qualified demand still include the qty of the OUT move

However, note one more effect that need to be considered: the On-Hand (unreserved) is unchanged and will only change when you reserve the final delivery (which will remove the spike too). Meaning that the NFP is correct at any time. Example:

• 30 OH, spike of 11 units, PICK reserved:
  
  

• Now PICK is validated and OUT reserved: 19 OH, 0 spike:
  
  

So, NFP is at all times correct and you won't reorder without need. At the end of the day, the PICK transfer is an internal move for a buffer set at "WH" location, so it is not really affecting the buffer at all, which seems correct to me.

Does this make sense to you?