afadil
Use historical exchange rates to calculate balances
Description
This issue arises when the main currency is different from a holding's currency. The value of stock is compared in the account currency rate, then converted into the main currency. This ignores the change in currency between dates.
Probably would be part of the roadmap item - Enhance portfolio History calculation
Example
This issue is most visible when exchange rate and stock price move in different directions, especially if the stock price moves less than the currency.
The main currency is EUR. One of the accounts uses USD.
On date 2024-12-01 you buy 100 XYZ @ 150.00 USD - USD/EUR is 0.965. The holding is worth 14475 EUR On date 2024-12-10 the price XYZ is 151.00 USD - USD/EUR is 0.941 The holding is worth 14209.1 EUR
The dashboard shows an increase of 94.1 EUR (price difference * current exchange rate) despite the holding actually losing value relative to the main currency.
A real example would be INPST. 2024-04-12 -> 2024-10-12. Main account in PLN, trade in EUR
Proposed solution
Pull daily exchange rates, use for calculations at every data point(charts and balances)
Possible compromise
Display charts in the holding's currency as it is currently. Use the current exchange rate and the rate of the position opening to calculate balances. This way of calculating could be disabled by deafault and toggled by clicking on the balance or toggle next to it.
I am not sure about that. The issue you mentioned appears to be related to the wrong currency being assigned when the holding price is pulled from the API This one is related to the fluctuaction of currency exchange rates and how they affect the balance depending on which currency is the main for the account
I mean it's related in terms that both issues seem to result from mixing different currencies in the holding class. I think it would be easier to calculate holding values if the data model was more explicit about the currencies used for each value in the model.
Redesigning the model would help with both issues, but I agree that this one is different in a sense that it also requires gain/loss conversion for every data point.