Improve delivery time

Feature
#1

Rational

In Manage planning issues with stock quantity we managed the planning issue of delivery. But another point in the stock management is to reduce the quantities in the warehouse -to reduce the cost). This is already done by default with the supply computation which schedule the replenishment to be just in time.
With the same logic as for quantity issue when the supplier is late, the supplier (or the production) could also be in advance on the planning. In this case it may be good to try to deliver the customer or the produce (or even to ship internally) earlier.

Proposal

We create a new module stock_xxx
We create a scheduled job that loop over all the outgoing moves from a warehouse and we find for each move the earliest date it could be done without altering the stock (see below). This quantity is stored on a generic model.
Once we have those dates for every outgoing moves, we can compute for each outgoing shipment and production the earlier date possible (max earliest date of each move) and the earliest date possible (min earliest date of each move) and the percentage of “quantity”. We store on the same generic model this information.

From this list the user will be able to take action as the list will be ordered by the gain.
The user may decide to ignore a possible optimization such that it will no more be recomputed.
From the record, the user will be able to open the graph of product quantity for the warehouse and the products. This will help to choose an action like a date or split the order etc.

The model stock.xxx:

  • origin: Reference field of stock.shipment.out, stock.shipment.in.return, stock.shipment.internal, production, stock.move
  • planned_date: Computed from the origin
  • earlier date
  • earliest date and percentage
  • active

The computation of the earliest date of a move

The earliest date can be computed for a move as following the quantity for the product from the planned date of the move back in time as long as the quantity is growing or not going below the quantity at the planned date.

Implementation

#2

I think that is interesting but I usually find this kind of required linked with the fact that the company cannot plan the outgoing date at the moment the sale is created.

So for these customers, the ideal workflow seems:

  1. Process sale creates outgoing moves only (symmetric to what is done in purchases)
  2. Use the process you propose to improve delivery time
  3. Create customer shipments out of the decisions the user did

What do you think?

#3

I do not see why you should not create the shipment. Latter it can be split if some products can be delivered earlier.

1 Like
#4

I think we should have a wizard and the ability to schedule it (but disabled by default) like we do for Stock Supply. This way the user may manually execute it when desired.

I’m missing a possitive action, something like:

  • Update the planned date of source documents to follow the recomended
  • Assing the moves to ensure that the planning is enforced.

We should allow customization of the actions to do.

Indeed for this kind of customers I think it makes sense to have all the shipments in waiting state but allowing them to discover what is ready to ship. This way the user can decide if they want to split the shipment or take a partial delivery without the need of opening the sale order.

#5

What about stock_delivery_plan

and stock.delivery.plan ?

1 Like
Make sale warehouse not required until processing
#6

I choose on purpose to not include actions because they are infinite possibilities. Indeed the actions are available on the shipment like update the planned date, split etc.
What the system will propose may probably not be what the user wants because he has external constraint from the customer or the production capacity etc.

#7

Of course, That’s why we allow everyone to create it’s own actions.

The main problem here is that the number of documents will be high so having to manually edit the planned date (or performing another action) of big number of documents is boring and error prone for the end user. That’s why I think we should have an action which launches a wizard to ask the user the action to perform and do it for them.

We should support by default to at least update the document date, other actions can be added latter or by custom modules.

Of course the user can always ignore the contraint or even modify the planned date latter manualy.

Inded if we have as much as information on Tryton (like production capacity for example) it will be possible to better fine tune the computed dates on the system to provide better proposals.

#8

Maybe but each document must be analyzed one by one as the user needs to evaluate the opportunity and confirm the feasibility with the customer.

I do not see any action doable like this that will be better then editing the related document.

I do not see how such action is better than editing the document. It requires the same or more effort:

  • Launch wizard -> Select action -> fill the date -> validate
  • Open document -> edit date -> validate

No it will not. You can have all the information you can imagine, it is not possible in a reasonable time to provide the best proposal. This is a NP-complex problem.

#9

It’s more something in the line of “why should we create a shipment if we don’t yet know how it’s going to be shipped”.