Currencies: rework or remove?

[almet]

We currently use an external API to get conversion rates, and it went away. I think we should not rely on external services anymore to do these kind of tasks.

My proposal is to :

• Let the project owner select a default currency (as we currently do, but without a list) on project creation, or via the project settings ;
• When creating bills, users can specify the currency and a conversion rate of their choosing. We could eventually select the last conversion rate that was recorded if that makes things easier.

Would that be okay for you? (cc @Glandos as git blame points to you on this code / last changes).

Cheers :-)

[zorun]

I agree we should stop relying on an external service.

Your solution is probably the most reasonable but is still a bit complex. Let me try to widen the discussion by proposing more radical alternatives:

• Remove support for currencies. I'm only half-joking here, it's arguably the most complex and fragile part of Ihatemoney
• Keep currencies on bills, but only perform conversion when settling a project. This boils down to having a single manual conversion rate at the project level.
• Keep currencies on bills, but don't do any conversion. This probably means we have to show multiple balances and settling plans (one for each currency), which makes the UI more difficult to design

In any case, let's keep in mind the original use-case: handling bills in multiple currencies in a single project. For reference, here are the original discussion and pull request:

• Add ability to record expenses in different currencies #512
• Feature/currencies #541

[almet]

I actually would advocate for removing currencies all together. I'm not using this feature so I might be too optimistic, but I actually believe it's part of the features that we should have rejected at first to keep the codebase simple.

[dylanmorroll]

As a British person living in The Netherlands with a Swiss partner I find the multiple currencies super useful! So I would definitely advocate for keeping it in haha. Found this issue cause my ihatemoney project has fully stopped working.

Although yeah I generally do not really like the automatic currency conversion and would actually prefer just having the currencies separate. I generally have some of each currency in my Revolut/Wise/whatever at the same time, so sometimes settle up in other currencies. Or, when I do decide to settle it all up in euros or something, I just check the current exchange rate that's available to me and take that, so I don't really use the rate that ihatemoney is using anyway.

I guess the downside here is settling the bill could be a bit clunky. e.g. if I owed my partner 80 CHF and she owed me 100 EUR, settling the bill wouldn't be able to be reduced to a single transaction. But still, the maximum amount of different transactions you would have to do is one per currency. I think generally the number of different currencies would be 2 or 3, so it would still be fairly simple maths.

Ideally you could then have the option to manually put in some exchange rates that you and the other members agree on when settling the bill would be nice - but I would say this could be in the next iteration. I would say hitting an API for automatic exchange rates is overkill for a FOSS project and manually inputting them is fine.

[craiten]

Since the external service stopped working my project stopped working as well. On my MoneyBuster app on Android when updating my project or when adding a new item to my project I get the error "Project-Sync failed" with the following description:

"Syncing the project failed. Error message: 400 invalid request {"original_currency": ["Not a valid choice"]}
The Project might not be existing anymore."

I also can not add new bills on ihatemoney itself. When hitting the "Submit" button nothing happens.

I saw in my ihatemoney account that I can not choose any default currency (see screenshot below).

This might the problem?

I would really like to see the new feature but I would appreciate it more if the service would work again :-)

[almet]

Hi @craiten. This has been tracked in #1239 and a fix has been released. It's not deployed on the main instance yet though (will be this afternoon).

[kaiec]

I also think that supporting multiple currencies is crucial. Coming from Tricount, I always used this feature as my main use case is splitting money with other people while traveling. At least for this use case, fixed (but adjustable) rates would be perfectly fine. For longer projects where the rate can change significantly, it would be useful to have the exchange rate per entry, so your suggestion @almet would work.

I think, however, that it is crucial, that the original value with the associated currency, needs to be stored and also displayed, as in my experience this is the thing you check if you want to see if an entry is correctly entered. The converted values should only be shown for information and then used for settling.

[zorun]

Adding some input from #1263, apparently Splitwise uses the third approach I described (also explained in more details by @dylanmorroll above). They simply consider each currency separately when settling. It seems the most sensible approach to me, maybe with the addition of a manual conversion whenever needed.

[AsbjornOlling]

+1 love for the currency conversion feature. We're a group of people that exclusively use ihatemoney for travel, so it's super useful.
Manually inputting currency conversion rates would absolutely be fine.
(We mainly do DKK<-> EUR conversions anyway, which is a legally fixed rate).

[azertylr]

hello,
We could propose either :

• ask the user to get an API key and to add in the config file
• manually add the exchange rate

[azertylr]

there is this open API https://github.com/fawazahmed0/exchange-api

[almet]

After a discussion with @zorun, we're leaning towards keeping the support of multiple currencies, with conversion rates fixed in the per-project settings, with potentially some fixed rates in the code.

It's worth noting that we don't want to write this code ourselves (because we don't need it ourselves). We would gladly accept contributions on the matter, which we would review though.

In order to go forward on the matter, we are letting this task open to take for any volunteer for the next 6 month. If you want to code this, don't hesitate to chime in!

Passed October the 31th (of 2024), in the eventuality nobody implemented it, we would delete the feature all together.