Make sale warehouse not required until processing

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 - #5 by pokoli.

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.

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).

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.

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.

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

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

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).

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

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.

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”

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

1 Like

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.

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

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).

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!

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.

Sure but if it is the job of the administrative department to ensure that information is valid, then it is the administrative department that must click on the confirmed button. But in fact, then the workflow must look like:

  • the sales person receives the confirmation of the order
  • tries to click on confirm
  • an error tells there’s some missing information
  • sales person sends an email to the collegues in the administrative department
  • the sale is left as “quotation” until somebody acts

Previously, the workflow was cleaner because the sales person could confirm, and if he could not process the sale, at least the sale was already in “confirmed” state, so it clearly showed that the customer had approved the sale.

Of course it is stupid to put check on confirmation that are not for the one who is confirming.

Then where we should put the checks for processing?

This is our current case as we want to check that the order has a warehouse before processing.

The sale_amendment module can be used to change the warehouse once the sale is processed.