I don’t want to know the risks that I already assumed.
What I argue is that I want the currency in the party for the same reason that I want the payment term in the party: it is part of the negotiation with the party and that is prior to the sale/purchase.
The question could be: why does Tryton have a default payment term?
It is not like this in all business. Often customer decides the currency.
As @2cadz the user may have no contact with customer.
Normally in other systems the currency is defined on party, but as Tryton does not do things as others … I wonder if the solution would be that currency on sales were proposed as in purchases (based on last orders).
What is the rational of define the currency on the party? Why it is usefull? Why we should do it the same way?
If we do the same way as other we will never make it better 
This makes sense for me until anyone give any good reason to add the currency on the party.
To get a default currency for the party, as another customer data such as payment term.
To load party currency when creating sale document.
Sorry but I didn’t say that we should do such thing.
I guess it is clear that in some businesses (mainly international traders), there is a need to define explicitly for a customer or a supplier a default currency. But we should keep the system simple to use for other cases. This means to keep the guessing of a good currency for the purchase and keep sale in the company currency.
So I think we could add currencies for customer and supplier (probably on the account_invoice module) but without default values. Those fields are used when they are not empty to fill the currency of invoices, sale, purchase, subscription etc. Otherwise we use the current guessing mechanism for purchase and company currency for sales.
That’s exactly what I thought when I started this thread : Issue 9305: Adding currency on party - Tryton issue tracker
Is the current guessing system that good that we want to keep it?
I mean it is something that is complicated to explain (not that complicated OK but still (and after reading the code I realize that it’s the 10 last orders created included the ones in canceled state or the ones with a future purchase date ; it could seem strange or surprising)), in a lot of cases it will guess the company’s currency and in the few cases it would guess differently my bet is that it will guess always the same currency which might as well be set on the party then.
I do get that it’s a clever way to adapt to a changing situation and that it removes a configuration option: people use a currency once and the system will correctly guess it 99% of the time (but I think it already does it 90% of the time by using the company’s currency).
So I wonder if we implement this proposition if the guessing system will not be extra complexity for little gain.
Yes because most of the time, user will not set a currency on the party. We know how ti works, the average user will change over and over the default currency without thinking to update it on the party.
So for me, it does not hurt to keep it and at best give some benefit.
The status it not a problem because we care only about the intent of the user.
Those are exactly my feelings as well. Instead of having an explicit setting on the party (in the same way as for other settings like payment term, tax rules…), the user can be somehow surprised by the results of a guessing system. The disadvantage of a guessing system is mainly, that the user must control the resulting setting on the sale/purchase/whatever. I would always favor the way of least surprise for our users.
The two options must not be mutually exclusive: a setting on the party should take precedence over the guessing system. That way we could profit from the advantage of both solutions.
It’s added complexity, not a big addition I agree but it’s there.
But if the intent of the user was to cancel the purchase because he used the wrong currency it will backfire by adding another case of bad currency 
.
That’s what @ced proposes. I think we should have one or the other.
First he can change the currency of an order instead of cancelling.
Second this currency will be used only if it is the majority currency in the last 10 orders.
So what would it be the default currency set if the party has no currency defined?
And how will it help the user experience?
Of course but sometimes users cancels orders instead of doing what’s right.
What is according to you the intent of a user that cancel a purchase?
The current default: the company’s currency.
My proposal is to have a stick to one system to make the system simple. So the benefit for the user is understanding the system.
They could not make the deal.
So you already have a complex flow with this proposal because the default value is taken from two different places: the party or the company.
If we go to simplify the system then we should not store any currency on the party and not use the company currency. So the simplest solution is to left the user set explicitly the currency.
But how does it help the user experience?
Tryton goal is to ease the work not to do the minimal stuff possible. We have plenty of places where we make decision for the user: set payment term when there is only one, set the warehouse also when only one, set the default company to the user company, fill the purchase date to today etc.
For me, the user does not need to understand the full system. He needs to know how to work with it. So in this case, if he does not like the default currency, it willbe easy for him to change that by setting a currency on the party. This is where the simplicity should be placed.
I agree with Nicolas. For me, the guessing system is surprising. We don’t do it anywhere else in the system. For example:
And I’m not advocating about using this in more places in the system but removing this exception.
Because payment term is not required. But also we set it if there is only one payment term.
But indeed I think we should probably also try to make this guessing. And also for the addresses if there are no default defined.
No, we do not require that.
Because it would make no sense to link the warehouse to the party.
In contrary we should add as much as possible. The point of having a system is that it does things for you, not that you have to do thing for it.
If we do not try to make a better system with Tryton, what is the point then?
For the record, this feature is there since 8 years without any complaint.
OK I’m not sure it’s always the case but OK.
It’s a question of degree of complexity. Two sources is OK, three it’s manageable, four is probably too much.
Those are sensible defaults when there is only one value to choose from.
But I like that when faced with ambiguity we refuse the temptation to guess.
This one follow the principle of least surprise (as would using the company’s currency in the documents)
My main issue is that having three sources of value is having one too many sources. So it makes the system complex and more difficult to understand for people.
So my guess is that if there is this new option added, people won’t be using it if wee keep both system. Let’s look at two scenarios:
In both cases the new option won’t be used.
A scenario where this option would be used is if someone else fill the party form with the information from the supplier before our user fills the purchase form. But then I guess that the party form will always be filled with the relevant information making the guessing system useless.
So in both case, either one of the sources for the default value is unused. Moreover if both system are used for different suppliers, I think that people will be surprised to see that it works (in fact they will realize the existing of the two systems when it won’t work I guess … it might not be that often though).
Which is why I think we should have one system and not two.
But with people circumventing its use in custom modules (I bet NanTIC has a module for that in addition to Saluc).
I didn’t mean to link the warehouse to the party but to the user. Instead of creating a default value for the user we could have guessed the warehouse from the user. But we didn’t.
Right. But we must think carefully how we manage those “guesses”. To make it intuitive for the user. One way, is to suggest guesses to the user. For example, gmail will suggest more recipients when you send an e-mail to a recipient that is usually accompanied with others in previous e-mails. But it is just a suggestion.
Not saying that’s the way to do it, finding the right solution it is probably out of the scope of this thread.
I don’t think that’s an argument. We’ve found bugs that have been there for 8 years too.
That’s the reason we had it for 8 years without the need of something else.
No it is not because it is filled for one supplier that it will be for all. So having a fallback is still good as you just showed how well it works.
And even it was the case, what is the problem.
Tryton is a general purpose software, it must be working for many use cases.
Some will be fine with the guessing, some will be fine by the default party value and some will be fine with a mix of both.
That’s the best thing that can happen. It means we succeed to make a feature that actually helps users.
I do not understand how to come to this conclusion after showing all the arguments in favor of both feature.
Also I think it is wrong to see that as two systems. It is only one system which has linear fallbacks.
And such module will no more be needed once we implement this option on the party.
It has nothing to do with intuition.
Exactly, you find this guessing nice even if you do not understand how it works (and probably nobody understand how it works except for the Gmail developers).
It is because features that stayed long should have massive argument to be replaced by something else (especially if it is not in conflict).
Because as I said above: either one of the sources for the default value is unused.
Both system works, I don’t argue with that. Moreover they will give more or less always the same result.
Thus if they both work, both give the same result and are both implemented then there’s one system too many in Tryton.
This should be also used as arguent against adding the new feature and keep only the current behaviour.
What we should note here is that Tryton is used by many many diferent companies, so their use cases are quite diferent. This means that there is no solution that works for all, so we need to have diferent paths for diferent use cases.
So if both system works and they are simple to maintain I will be in favour of adding the new feature and keep the current one for the ones that are using it.
This will make the system suite for both needs.