[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Proposal for handling different currencies



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.

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?

-- 
Seán C. McCord
CyCORE Systems
(706) 995-2101 (office)
(404) 992-4070 (cell)
..hidden..

Attachment: pgpD2AQi02n1B.pgp
Description: PGP signature