How to work with prices in different currencies?

Question

Programming

Hey!
On the site, products with different price tags, prices are shown in the currency depending on the language .
If the Russian language is selected on my site, then the prices are in rubles, for English - dollars.
At the same time, prices in rubles depend on the dollar exchange rate (parsed every day).
Question : how to sort and filter products by price, given that the 1st user chose to display products from 100 rubles, and the second one entered "only with a price below $10"?
Does it even make sense to bother with ElasticSearch on this issue, especially since the rate changes every day?
How is this decided, for example, by eBay?

Answer 1

Store values ​​in one (universal) currency. Sorting shouldn't be a problem. As for filtering, it's simple to convert the filter value to the universal currency.
For example, prices are stored in US dollars. The client wants to see prices from 100 rubles, then 100 rubles needs to be converted into US dollars and substitute this value in the selection request.
When outputting, you can convert on the fly, because there will be few records. As a last resort, if there are performance problems, you can cache.

Answer 2

When asking a similar question, you need to remember that most programmers have never worked with finance and do not understand the reason for the appearance of the word "accounting" (which has its own rules for working with numbers).
There can be only one answer to this question: your code must completely repeat the real processes of working with finances in this service: when paying, the amount is recalculated at the rate - the code recalculates the numbers online, the financiers keep their own numbers for each currency - the code does not deal with gag.

Answer 3

To get started, you need to consult with your financiers/economists/accountants (who is in charge of pricing and is responsible for prices). Consultation is needed in order to find out whether it will be acceptable to store only one discount price in the accounting currency, provided that all other prices (in other currencies) will be formed on the fly by recalculating the discount price at the exchange rate.
In some cases, this is unacceptable, because. it may suddenly turn out, for example, that your price makers use their own ideas about how exactly they should be formed to form prices, and these ideas may differ from the logic of your software (for example, the rules for rounding when converting at the rate may differ, or not all received numbers can be explained in terms of the programmer's ideas about mathematics and / or about common sense).
It may also turn out that all prices in different currencies are fixed in paper documents (price lists, etc.) signed by some officials, and this fixation does not occur daily, taking into account the changing exchange rate, but, for example, once a month, or on the fact of a change in the discount price. If price fixing takes place, then most likely the prices on the site will always have to match the prices in the documents, and not just be calculated at the daily rate.
Further strategy needs to be built taking into account the emerging pricing circumstances. Ideally, no nuances will be found and you will be free to implement the work with prices at your own discretion.

Answer 4

store the price in one currency, recalculate with requests using scripts
https://www.elastic.co/guide/en/elasticsearch/refe...
https://www.elastic.co/guide/en/elasticsearch/refe ...
https://www.elastic.co/guide/en/elasticsearch/refe...

Answer 5

Usually the accounting currency appears in the system. Well, on the fly or a stationary calculated other currency. In certain situations, conversion to another currency may not be straightforward at cross rates, but also taking into account conversion costs. In the general case, this can be something like y=ax+b or even more complicated, taking into account (%, but not less than xx coins)

Answer 6

Use the Money pattern