-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Fri, Apr 02, 2010 at 10:18:24AM -0700, Chris Travers wrote:
> Suppose I live in Canada and I have two checking accounts for my
> business, one in CAD and one in USD. In essence I have to account for
> a floating balance of a foreign currency [...]
> there is no guarantee that the conversion
> rate when you enter the payment into your system as received and when
> you convert it is the same. The check could be deposited the next
> day, for example and converted at that point.
It isn't even clear that the exchange rate for a given point in time is
well-defined. Typically you get differing exchange rates depending on
where (and how much!) you try to realize the conversion.
> So conversion between currencies is something which has to be done at
> a specified point in time. While some of this could be automated to
> an extent, it would really be business-specific.
>
> In essence, I think you would need a function like
> convert_currency(source monetary, target curr, date) to do the
> conversion. Furthermore this would require currency tables, and would
> be probably outside the core data type definition.
>
> In essence, to handle exchange rates, I think you would need
> additional tables and the like, and UDF's to do the actual
> conversions. For simplicity's sake, I think this would be broken off
> into a separate module although I would be happy to collaborate on
> that as well.
Hm. An expert would have to decide whether such a simplification is
useful (it could, e.g. help in estimating the money amount held in
different currencies at some point in time) -- but some exchange rate
seems to be well-defined only when you actually *do* the conversion.
Regards
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFLtkjNBcgs9XrR2kYRAr++AJwKkDt6/RBbfK/KOz8ZNIK4RjYy6QCcCPPK
S+gOzayBMJh+2n9sFgbTI64=
=oeqv
-----END PGP SIGNATURE-----
