Keep preferred carrier service for a party

Rational

Each client can express a preference for a carrier service that would be selected as default in a sale. This module would give a way to store their choice.

Proposal

Could be a module named sale_shipment_cost_party that adds a field “carrier” on party, chosen among available_carriers (like in module sale_shipment_cost).
The Sale.on_change_party() from sale_shipment_cost would be modified to select the carrier from Party instead of the first available.

Implementation

We should consider whether it is the carrier of the party of the carrier of the shipment_party the one that should be used.

Sure if there’s a shipment_party defined on sale and a preferred carrier for the shipment_party, we should select it ; then teh preferred carrier of the sale’s party, and by default the first available carrier (as now).

Do you think its worth a new module or should it be a feature added to sale_shipment_cost?

For me, it makes sense to put in the existing module.

I do not think the proposal is mature enough. It does not propose a good behavior which works with the carrier selection.
Carrier are not always available for many reasons (work days, holidays, delivery address etc.).

ced:
I do not think the proposal is mature enough. It does not propose a good behavior which works with the carrier selection.

Indeed, if the Carrier Selection is changed, the prefered carrier on the Party could become invalid. Though with the design proposed, everything would work as now: the first available carrier would be selected in the Sale, hence the Party’s carrier would be ignored.

We could simply store the last carrier used for each Party (better, to each Party shipment address), to reuse it the next time if it’s still in the available carriers.

But I don’t undestand the point with the work days or holidays. If a Party prefers a Carrier service for delevering its purchases, I suppose it knows the limits and restrictions of this service.

The need to store Party’s prefered carrier is a real business case I encounter here: since the shipment cost is invoiced, the client wants to choose the carrier service for its orders. It’s not simple (and error prone) to maintain an offline (ie off-tryton) list of prefered carrier service for each party…

Indeed I do not think it is a real business case.
For me, we can divide the sale orders into two kinds:

  • Filled by customerw (usually via web shop)
  • Filled by salesmen (on a store, by phone call etc.)

The first case (by customers) does not need to store a preferred carrier because the customer will choose and confirm the selection.

In the second case (by salesmen), the salesman will have to ask or confirm the carrier out of the available (if there are more than one option).

So for me, there is no need to store an the party nor on the address a preferred carrier. But the default selection of the first one is probably the best behavior. I think the behavior could be improved like we did for the currency on purchase. We could pick the most used carrier by the customer out of the available ones. For me, it is a better behavior because it improves and help the user without requesting from him more actions. But also it makes the system a little bit smart as if the customer starts to request a new carrier, after sometimes the system will propose this new one automatically.

Sorry to be a contradictor: in my business use case (publisher and book distributor), orders come by email (from bookstores) with mostly the mention “same carrier as usual”. Once we asked the buyer what carrier they prefer (by email or phone), we do not ask again and we have to maintain our own list of preferred carriers. This is rather time costly: having a better default carrier selected would shorten the time to process an order.

I agree such a behaviour would be a good enhancement. Maybe we could limit the computation of the most used on a recent period for the customer (last 5 orders or all orders in the last 6 months for instance) so as a change for an old customer will be quickly visible.