The way I currently find out the price for a sale of a customer who has a custom price is to associate him with a price list using sale_price_list.
But this does not give me as much information regarding the terms of the sale as a Sale Quotation could: for example:
Who is the shipment party?
What is the delivery address? Maybe the customer has multiple delivery addresses. Maybe the customer will pick up at my warehouse.
What currency is the sale in?
What I could do is to duplicate the last sale for that customer, or keep one sale in quotation state, and duplicate that, but somehow it does not feel like a clean solution.
Also it would not work if I create a web portal for customers where they can order by them selves where a new sale would be created, price should be pre-completed and not editable and conditions such as delivery address and shipment party should be options. If I use the sale_price_list, then this will work, but I do not think it could work if I use sale quotation.
Also using quotation is only good for a customer who has a unique price, if multiple customers have the same negotiated price then sale_price_list would be the right solution.
I have a feeling that the right solution is to have a bunch of custom modules that associate the customer with the condition: ex. shipment party, sale currency, etc and set the associated condition as default in a new sale for that customer.
I apologize if the question is vague. I have the feeling that there is probably a better way to solve the problem.
PS: I understand that sale quotation is great if it is a one off order, if the customer orders, received a quotation, agrees and then the order continues. But for example for me I have many repeat customers, who will get annoyed if the order 5 times a year and they have to explain all the conditions over and over again.
You can define on the party the different default addresses.
For the currency there is a proposal to add it optionally on the party Issue 9305: Adding currency on party - Tryton issue tracker.
Now for the case of using a different invoice and/or shipment party, I’m not sure it is a frequent enough use case to get a dedicated configuration on the party. Maybe we could use like for the purchase a SQL query to get the most used value in the last 10 orders.
For delivery as pickup at the warehouse, I think this is a new feature that must be implemented. I guess we could allow to use the warehouse address as shipment address. But we will need a way to define this address as the default shipment address.
So for me it is wrong to use quotation for anything other than a quotation of a specific order.
But it should only be in Tryton if it is useful for many users, Tryton should not be bloated with code that only useful for one user. It could be useful to express if it is useful for anyone besides me so that we can determine if it has a place in the Tryton project, or as a custom module.
Maybe the user’s warehouse address should be the default delivery address if the customer Party does not have an address with the delivery usage.
I tested with 6.2 and the customer address is used as shipping address even if the customer Party does not have an address with delivery usage.
I have been thinking about this for a long time, and while I had the same idea you expressed I always had the feeling that I am missing the correct usage. Thank you for confirming!
I was thinking it could be a simple implementation of how to specify pick up at the warehouse instead of at the customer’s address.
If the fallback returns the warehouse address instead of the first customer address then we know that the customer wants to pick up from the warehouse.
Like this we don’t need to modify or add any new model, just change the code that returns the fallback address.
And if the customer wants delivery at their address the delivery usage should be checked.
Or maybe this is too counter-intuitive, and even if documented will cause more trouble than it solves.
Do you think this could be the right approach?
I do not think the fallback should be “warehouse pick up” because it is very rare use case.
So I guess we will need for example an option for address marked as for shipping to say that it should redirect to the warehouse address.
It surprises me that it is rare.
Approx. 30% of my sales are with warehouse pick up.
Also I feel like I have to give the customer an option, either you come and pick up, or you pay transport with my carrier, but the choice must be there for me.
This issue is more complex than it seems, as it could also involve carrier selectrion, incoterms.
If you think this needs to be an option in Tryton I am open for sponsoring its commissioning, if not I guess I should just make a custom which solves the problem for me.
Indeed we have this user case for one of our customers and what we do is just create a carrier that is named “Pick UP” and we keep the rest of the sale workflow as is.
Then the user processing shipments keeps the shipment on Packed state until the customer comes in for pick-up and it is marked as “Done”.
For me having to set a fake address is no good enough as it could lead to mistake and packages being actually sent. So we need either having an empty address or a warehouse address (of course allowing warehouse pick up should be a configurable option).
I think also that “Warehouse Pickup” should be forbidden to have a carrier (or only a special carrier only for this purpose).
Having a special carrier does not seem to be a problem for Incoterm as long as there is no shipment cost so EXW can be used. But maybe there should be some constraint to prevent using FCA.
We should also be careful that if a sale line is using a different warehouse then we should use for this shipment the address of the different warehouse instead of the one from the general order.
Thank you Sergi for the input. I already do something similar.
In addition to that I write in the name field (Building Name) of party.address how the customer would like pick-up, or if the customer prefers a special carrier.
This is first of all not pretty, and it is manual.
Just like we have the delivery usage for addresses, the shipment address of a sale automatically selects the address with delivery usage checked. I think something similar needs to happen for warehouse pick-up.
Another idea could be to associate the party with a preferred carrier, or lack thereof (implying warehouse pick-up).
But this means a new model and that in order to configure a customer for warehouse pick-up, you would need the have the carrier and the (yet not created) sale_carrier_customer modules activated.
I do not have any ideas other than assuming warehouse pick-up if the customer does not have a delivery address, and Cedric has rejected this idea.