Make sale warehouse not required until processing

Feature
#1

Rational

We have a case where a company has diferent warehouses which can send products to any locations. Most of the time they produce on demand (but they may have some products on stock) so after the customer order is received they decide from which warehouse they will send (and produce if required) the goods.

Currently an error is raised then a warehouse is not set on quotation but AFAIU it is not required until the sale is proceesed because at this time the shipments (which are related to the sale are processed).

Proposal

I think we should allow to create a sale without warehouse, and prevent confirming them if the warehouse is not set. The user will be able to search the confirmed sales, set it’s warehouse and then process them manually.

Implementation

#2

I think it makes sense.

#3

I do not agree. It is use to determine which carrier can be used depending on the address of the warehouse.
Also in the future we may make the shipping date depend on the warehouse.

So for me it is good that a quotation has a default warehouse because it allows to compute many things needed for a quote.

Indeed this could be managed automatically with a feature that compute the best warehouse for a line.

But what we are missing is a tool to change the warehouse of an existing shipment with moves. I think we could have a wizard similar to the “Modify Header” on sale which will ensure that the location of the moves are correctly updated for the new warehouse.

#4

So we should make it required only when the sale_shipment_cost is activated. Also this is only required when using multiple carriers on when the carrier depend on the source location, if it only depends on the target location the warehouse won’t be needed also.

I’m wondering if it won’t be better to make a function field to decide when the warehouse is required or not. This will also ease the customization for thir party modules.

Changing the warehouse may be usefull but not for our current problem. Our problem is that at the moment of confirming the sale we do not know which warehouse will produce and deliver them. If we set a warehouse at this point the user will not know which sales have been already assigned to a warehouse and which ones have a value that should be changed.

#5

I do not see the point to make such complex requirement. Also there are probably many other cases where it is needed.

I do not see why.

This does not imply that the Tryton design is wrong.
For me your proposal is just based on a single need and not a general need. You imply that the planning of the shipments will only be done at one point in time (the validation) which is very doubtful as we already know Manage planning issues with stock quantity and Improve delivery time.

A general solution is one that permit to adapt the planning any time and based on actual data.
So the wizard I proposed is part of the needed tools but also probably the similar reports as those developed for a warehouse but cross-warehouses.

#6

I agree that both proposals should improve the planning once the sale ir processed. We may use it latter but what are discussing here is before processing the sale so we need another solution.

The problem is clear:

  • The person confirming the sales will not now the warehouse so he can not encode it.
  • Once the order is confirmed another user (maybe automated but is not our current case now) will set the warehouse and process the shipment.

The current sale workflow (with the separation of confirmed and processing) suits perfectly for this use case, we are only missing to allow customization of the warehouse required.

I may understand that our use case is not desired for everybody, that’s why I suggested to allow extension on third-party (which is not easly doable now).

#7

Not knowing does not prevent to fill a default value.

It is not necessary to be this way. The planning/management of the shipment can be done after its creation. And more over each product could need to be shipped from a different warehouse.
Finally your proposal does not permit to manage mistakes.

For me you are creating a problem in Tryton because it does not fit your solution. But I’m trying to say that your solution is not the only one and that a more general solution would be better to enter in Tryton.

#8

I prefer to have and empty value than a default value which I not that is wrong.

Creating a warehouse that does not exist in the reallity does not sound like a good solution. Bacause it will lead to the creation of supply requests that do not need to be managed (yet) because they should be move latter when the right warehouse is set.

The problem will be worst if the users sets the wrong warehouse because the goods will be supplied to the wrong place.

Of course this should be solved by your proposals.

But we want to avoid the supply problem I mentioned above. If you have another solution that avoid the supply of goods to the wrong warehouse I will be happy to implement it.

#9

You could simply have a wizard instead of the confirm button that ask for the warehouse again.

#10

No because the person confirming the sale does not know the warehouse.
The warehouse should be assigned latter when the sale is confirmed.

#11

As the confirmation requires a warehouse to create the shipments, a warehouse is required. So I see nothing that could be changed in standard. Your requirements are too specific and wobbly to be considered as common need.

It is clear that the proper workflow is to have a default warehouse on the sale (which can be modified up to the confirmation). After that we should plan the shipment as usual (and have tools to change the warehouse if needed).

#12

It is the process of the sale which creates the shipment not the confirmation. Otherwise the confirmed state is useless.

#13

A confirmed sale is automatically passed passed to processing. It is wrong to use error in this transition as a way to collect data.
You may add an extra step if you want to validate the warehouse before the confirmation/processing (or even rewrite the confirm method to not call process but do it on another step). But this should not influence the general design of the sale in Tryton.

#14

Ok so here is our discrepancy. For me not all confirmed sales should not be automatically processed and this is our case that we want to support.

Are you saying that Tryton does not support to manually process confirmed sales?

For me it’s hard to find a name for this extra step which is diferent that “Confirmed”

#15

Indeed we find in most of our customers that the automatic processing while confirm is an undesired behaviour.

1 Like
#16

We also have some cases about it and we implemented by not adding to the queue the process method called from confirm.

Could you share the reasons why they need this feature?

Here are some of the ones that we have:

  • Double checking the sale before processing them. Sales in confirmed state can go back to draft to be updated if something is wrong
  • Manually setting the shipping date before processing the sale.
#17

Mainly this point, fixing user errors or last moment customer/supplier changes (in purchases as well). But also to distinguish confirmed sales (customer gives the OK) from processed ones (company hast started stock/invoicing workflows).

1 Like
#18

In our case I wouldn’t say in most customers but it certainly has some issues:

  • If there’s a misconfiguration in product accounting the invoice may not be created and the user not notice so you may never create the invoice for that sale or do it too late.
  • If you want some extra checks after confirmation it is no longer possible (as Sergi explains). As we understand “Confirmated” means “The customer accepted the order” so the job of the sales person is done but there may need to be some administrative tasks yet (such as obtaining the customer VAT, for example).
Improve processing errors
#19

We use the same Workflow. Sale’s persons create the sales, they turn it to qoutation while are talking with the customer, and they turn it to confirmed when the customer gaves the OK. Once the sale is confirmed just the people wich manages the credits can process it.
This way of working is very useful for us. I had never understand the difference betwen confirmed and process in Tryton Standard.
Cheers!

#20

Can be done using button rule by requiring 2 clicks.

This must be done before confirmation anyway.

This is managed by the graceful delay.

This is any way not a problem that salesmen will solve.
This should be solved by watching the log for errors.

You can always put such check on the confirmed transition with a button rules.

This is managed by the sale_credit_limit module. Also the salesmen will want to warn directly the customer confirming his order that his credit limit is reached.

To all, the “confirmed” and “processing” states must be considered as the same state. It is just a technical distinction to manage the loop in the workflow.