Issue 10126

Title
Empty planned date for purchase backorders
Priority
bug
Status
chatting
Nosy list
ced, pokoli
Assigned to
Keywords

Created on 2021-02-23.14:45:34 by pokoli, last changed 1 month ago by pokoli.

Messages

Author: [hidden] (pokoli) Tryton committer Tryton translator
Date: 2021-02-25.12:32:47

El 25/2/21 a les 11:26, Cédric Krier ha escrit:

Receiving the move in the past have the same behaviour.
Receiving the move in the future makes the new move to be scheduled to the same date as I used despite being before the planned_delivery date.
OK so you would like that instead of the delivery date computed, it will
use a kind of "planned delivery date" without taking into account the
stock moves.
Maybe it is a risk that can be taken because I guess if the backorder is
no more at the planned date, the user will be warned and he will edit
it.

Exactly I want to exclude the current stock moves. At least the ones that are already done, we may keep the planned to be able to see the right date on purchase if the user has planned it.

Indeed I tested also partial delivery on sale and the behaviour is the same. I will put an example:

  • Create a sale with a lead time of 10 days.
  • Partially send the product (because we have some stock of it)
  • A new shipment is created and it's planned date is set to today.

For the sale case I think it makes more sense, specially with issue10065

Author: [hidden] (ced) Tryton committer Tryton translator
Date: 2021-02-25.11:26:03
On 2021-02-25 10:45, Sergi Almacellas Abellana wrote:
> El 25/2/21 a les 10:31, Cédric Krier ha escrit:
> >> No, backorder is not planned at the original delivery date. It's unplanned and this is wrong.
> > It is because you receive today.
> 
> Of course, because I receive part of the goods today and I will expect the latter to be in the future. 
> A partial delivery before the planned_date does not invalidate the I will receive the other products in the future. 

I think it creates enough uncertainty that the safer is to not guess.

> Receiving the move in the past have the same behaviour.
> Receiving the move in the future makes the new move to be scheduled to the same date as I used despite being before the planned_delivery date.

OK so you would like that instead of the delivery date computed, it will
use a kind of "planned delivery date" without taking into account the
stock moves.
Maybe it is a risk that can be taken because I guess if the backorder is
no more at the planned date, the user will be warned and he will edit
it.
Author: [hidden] (pokoli) Tryton committer Tryton translator
Date: 2021-02-25.10:45:15

El 25/2/21 a les 10:31, Cédric Krier ha escrit:

No, backorder is not planned at the original delivery date. It's unplanned and this is wrong.
It is because you receive today.

Of course, because I receive part of the goods today and I will expect the latter to be in the future.
A partial delivery before the planned_date does not invalidate the I will receive the other products in the future.

Receiving the move in the past have the same behaviour.
Receiving the move in the future makes the new move to be scheduled to the same date as I used despite being before the planned_delivery date.

Author: [hidden] (ced) Tryton committer Tryton translator
Date: 2021-02-25.10:31:41

No, backorder is not planned at the original delivery date. It's unplanned and this is wrong.

It is because you receive today.

Author: [hidden] (pokoli) Tryton committer Tryton translator
Date: 2021-02-25.09:46:18

No, backorder is not planned at the original delivery date. It's unplanned and this is wrong.

Here are the steps to reproduce it:

  1. Create a purchase with a delivery_date in the future (i tested setting supplier lead time to three days for example)
  2. Create a supplier shipment, add the purchase product and change the quantity to less than expected.
  3. Receive the supplier shipment.

If you go to the purchase you will see that the delivery_date is updated to today and if you open the Stock Moves and go to the From supplier waiting you will notice that a new move is created.

The planned date of this move is empty and it should be the while it should be the date in the future.

I tested the full procedure on latest trunk.

Author: [hidden] (ced) Tryton committer Tryton translator
Date: 2021-02-23.17:22:11

For me everything is working as expected:

  • early delivery change the delivery date
  • back order for delivery in the past or today are not planned
  • back order for partial cancellation is planned at the original delivery date (in the future)
Author: [hidden] (pokoli) Tryton committer Tryton translator
Date: 2021-02-23.16:29:38

Then we should revert changeset 75556470974c because it does not do anything.

Author: [hidden] (ced) Tryton committer Tryton translator
Date: 2021-02-23.16:25:04
On 2021-02-23 15:47, Sergi Almacellas Abellana wrote:
> We can not manage the number of shipments the supplier uses to delivers goods (that's the main reason to not create a supplier shipments by default). Indeed in case we agreed to have several orders we should always encode the last one as delivery date because it's when we agree to have all the ordered quantity. 

You can you have to fill one line with the proper delivery date.

> The problem is with current behaviour we lose the information if the supplier is still on time or not. 
> As far as the delivery date is still in the future the system should consider that the goods will be on time (because we do not have any information on the delays).

I do not agree. We never assume the best from supplier once they failed.
Author: [hidden] (pokoli) Tryton committer Tryton translator
Date: 2021-02-23.15:47:08

We can not manage the number of shipments the supplier uses to delivers goods (that's the main reason to not create a supplier shipments by default). Indeed in case we agreed to have several orders we should always encode the last one as delivery date because it's when we agree to have all the ordered quantity.

The problem is with current behaviour we lose the information if the supplier is still on time or not.
As far as the delivery date is still in the future the system should consider that the goods will be on time (because we do not have any information on the delays).

Author: [hidden] (ced) Tryton committer Tryton translator
Date: 2021-02-23.15:37:46

I do not agree. Once the supplier showed he does not respect the planned date, we can not make anymore any assumption on its words.

Author: [hidden] (pokoli) Tryton committer Tryton translator
Date: 2021-02-23.14:45:34

issue8284 added the feature to reuse delivery date for backorder moves but this is not working correctly (at least for purchases). Here is some scenario to reproduce the issue:

  1. Create a new purchase, add a new line and manually set a delivery date for the next week.
  2. Create a new shipment (use the same supplier for the purchase) and receive a partial quantity without setting any date (the shipment is received today).

Current behaviour:

  • A new move is created without any date

Expected behaviour:

  • The new move keeps the planned that for the next week (as set on the purchase line)

The problem comes from the fact that delivery_date reads the effective_date or planned date from the move which in case of backorder mean overriding the default definition with the first delivery date.

I think it will be less atonishing for the user to keep the delivery_date in case there are not draft moves.

History
Date User Action Args
2021-02-25 12:32:47pokolisetcomponent: + sale
messages: + msg64854
2021-02-25 11:26:03cedsetmessages: + msg64853
2021-02-25 10:45:15pokolisetmessages: + msg64850
2021-02-25 10:31:41cedsetmessages: + msg64849
2021-02-25 09:46:18pokolisetmessages: + msg64846
2021-02-23 17:22:11cedsetmessages: + msg64794
2021-02-23 16:29:38pokolisetmessages: + msg64791
2021-02-23 16:25:04cedsetmessages: + msg64790
2021-02-23 15:47:08pokolisetmessages: + msg64789
2021-02-23 15:37:46cedsetmessages: + msg64788
nosy: + ced
status: unread -> chatting

Showing 10 items. Show all history (warning: this could be VERY long)