Maintain historic rate conversions

[jjdelc]

When keeping historic data it is necessary to keep the rate at which an operation was made so we don't do past conversions using current rates.

I normally handle this outside of the currencies app, but I lose the ability to use its convert util.

[racitup]

I can't help but feel you should store the conversion at that time in your application? For example if it were an e-commerce platform and you have sold an item to the customer in their currency, you should store the price that you told them in the order/invoice and not do the conversion all over again at a later date.

[jjdelc]

I've done that, storing the original transaction currency and the converted to uniform currency I want for other operations. But then I felt that I kept the rate in disguise and denormalized among all the transactions, where the same rate info matched the date for all those. Being able to specify the rate for a date range would have saved me from storing converted values, but then again, I can understand the querying for that join of multiple ranges would be quite a headache, but I could still use the converted rate as a proper denormalized value and keep the historic rate info as source of truth.

It's just a nice to have, I can perfectly keep finding ad-hoc tailored solutions on each use case.

[racitup]

So modifying the model (or adding a new one more likely) to allow storing historical rates would not be a trivial task, and I don't believe is really the intention of the project or would be used that much, especially since it sounds like this would largely be a double-check for the data you already have stored. I can't help but feel you're looking at the problem from a purely data/software perspective, where "there is only one source of the truth". If you look at it more from an accounting perspective your problem goes away. A table of transactions is there to allow you to keep a log of exactly what happened and be able to easily filter/sum/report it. An auditor is not going to understand or like a heap of code that magics up values each time. The only option I think we have available to us would be to pass through the live historical rates from oxr, which the built-in client already has support for. It would drag all the rates down for that date live each time you wanted a conversion. This isn't ideal since you can't just query individual rates. And also from what I recall oxr limits the number of requests per day/month unless you have a paid account. But to be honest, this project needs a few other things (integration with a proper Money class for example) before we could think about a feature like this sorry. But of course you're more than welcome to submit a PR!