Re: Proposal for handling different currencies

[Bob Gustafson <..hidden..>]

On Sat, 2007-12-01 at 10:53 -0500, Sean C. McCord wrote:
> On Fri, Nov 30, 2007 at 08:24:36PM -0800, Chris Travers wrote:
> > Hi Bob;
> > 
> > On Nov 30, 2007 7:39 PM, Bob Gustafson <..hidden..> wrote:
> > 
> > > This example is prompted by the need to:
> > >
> > > 1) Handle accounting in one currency (EUR), pay bills, receive rent,
> > > etc.
> > > 2) Make investments from one currency (USD) to the other (EUR)
> > > 3) Pay taxes on profits (if any) in USD.
> > >
> > > The Chicken Farm example shows two methods of getting the necessary view
> > > for paying taxes (item 3 above).
> > 
> > 
> > I think you detail the problem quite will.  Here is a far simpler (and more
> > common) example.
> > 
> > A Canadian user of LedgerSMB opens a USD account and deposits $1000 CAD into
> > the account.  Once the exchange rate and fees are taken out, one cannot just
> > track the amount in the account in CAD bacause the exchange rate varies
> > frequently.  Instead the amount has to "float" in USD relative to the CAD
> > books.  At the same time, the books always have to balance in CAD.
> > 
> > Suppose for argument's sake the CAD to USD rate is 1:1 with no transaction
> > fees when the account is opened.  The user no longer has $1000 CAD, but now
> > has $1000 USD.  However, when we want to check the trial balance it will
> > show as $1000 CAD.  Ok, now suppose that the individual pays me $200 USD for
> > services (now having $800 USD in the account).  Suppose that the USD is
> > still doing badly and that the rate is now 1.03 CAD = 1 USD.  Ok, now we
> > have to record the transaction correctly so we know how much money is in the
> > accont ($800 USD) but we also have to record the transaction so we know how
> > much was paid for the expense ($206 CAD).  Currently this is done by
> > recording the $206 and using a view approach to get it back to $200 (from
> > $1000 = $800).   I propose that we record authoritatively how much money was
> > withdrawn in the source currency as well for auditing purposes.
> > 
> > The major pieces of this puzzle we are lacking are not that major.  We need:
> > 1)  A way of enforcing a master currency on an account.
> > 2)  Better reporting of things like current balances.
> > 
> > Current balance reporting has a number of other challenges associated which
> > I think we need to tackle (especially for the midsize businesses in our
> > userbase) but that is another discussion.
> 
> Pardon me if this is what you are suggesting with the "master currency"
> concept, but it does not sound like it.
> 
> IANAA:  It would seem the simplest concept to declare with the creation
> of an account, the currency of that account.  Since a bank "account" or
> a credit card "account" or whatever external account may exist will be
> mapped to a particular (static) currency, your books will not need to
> worry about continuous updates and translations.  When a report is run,
> you should have the option to convert the figures (for display) at the
> present conversion rate to a different currency.  In this manner, the
> conversionis more trivial than the "Cash" or "Accrual" view system, all
> accounts would be correct for the currency in which they are stored (at
> all times), and reports can be generated (at any time) which would
> properly convert between the currencies.

YES, this is it. Use multiplication by conversion rate to get a view 'at
that moment'

To 'manage' the project, it is not necessary to have a ledger account
accurate to the penny (centime, pence, rappen), but a 'view' which shows
reality.


> 
> Additionally, if there is a conversion "fee" or "rate margin", these
> could be associated to a CoA exchange table, as well.
> 
> Is this what you are suggesting, or if not, what are the pitfalls of
> this concept?
>