Allow to have multiple drop shipments from a single purchase

We are working on a project where the customer is ordering in a single order the needs of the next two weeks. This sale order may contain the same product with different shipping dates. This order will be sent using drop shipment, as the company does not have a warehouse to store stock.

In order to achieve that, we added a custom delivery date on sale lines and then group purchase lines based on the delivery date. Until here everything works well. But we found that the current design only allows to have a single drop shipment per purchase:

What is the rational about this design? I will expect to be able to group the same purchase shipments by the purchase delivery date. Maybe not by default by at least to be able to customize it in custom modules.

Do you think it is a good idea to allow grouping drop shipments?
If yes, what should be the default criteria? Does it make sense to group the with delivery date?

We probably will need to group purchase request by other criterias (delivery date) as for our use case it is very important to group all the purchases in a single one with bigger quantities to have the best price from supplier. As I understand this may be a special case and that’s why I’m asking what do you think what will be the default criteria.

We do not know how the supplier will ship.

It is the supplier that decide how he is doing the drop shipments.

There is no point as it depends how the supplier make the shipments.

You just record what the supplier said he has shipped and back-order drop shipment will be created for the remaining.

Of course, but now the API does not allow to have different grouping. It just assumes a single drop shipment is used, but does not allow to split them in several groups.

If you agree with the supplier to send them in two shipments splitted in two different weeks (for that reason we have the delivery date on purchase lines). Why we need to re-split it latter? This sounds like the Tryton is not smart enought to be able to follow it’s own planning.

You do not need to split because you do not know how the supplier will split them.

Agreement is not the reality. There is no point to split before actually know what happens in reality.

In our case we know that it will be split because we confirm before the purchase order confirmed that they will be able to fill the purchase request on the agreed date. If they are not able to fill it, the company uses another supplier.

So there is the point to split, another think is that you do not want to see it :thinking:

I think I understand what Ced tries to tell you.
If you plan splitting at order time, then it is just planning, because the reality will happen when the supplier actually ships.
Either I missed your use case, or it doesn’t make sens to pre-splitt upon order.

Use case is split at shipping time and we agree the delivery dates with customer and supplier at order time. Delivery date is moved from sale order to purchase order with the purchase request flow.

Once this planning its agreed we need to check that it was properly executed.
For this way, we want the system to create the shipments following the plan to make it easier to check if it was properly executed or not.

Planning and measuring distance to plan is a generic need. We might have a global thinking about this.

Indeed it is the goal of Draft: Display delay for stock move and shipment (!584) · Merge requests · Tryton / Tryton · GitLab

So I think we should remove the planned date on drop shipment and let manage it on each stock move.