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