> *** Regarding Re: Transfer between bank accounts with different
> currencies; [EMAIL PROTECTED] adds:
>
> linas> Yep, that's a bug ... any suggestions on how to fix this? How
> linas> do other packages do this?
>
> I don't know the correct accounting way to handle this. The problem
> is due to currency trades. For example, when I exchange USD 100 for
> DKK 700 by wiring money from a US bank account to a Danish bank
> account, the net effect is -$100 on the USD side and +DKK 700 on the
> DKK side, so that the accounts on the two sides no longer balance.
> The solution must be to treat these currency transfers special in the
> reports. One way would be to take them out, but that does not seem
> correct. Another way would be to add a virtual expense of USD 100 on
> the USD side and a virtual income of DKK 700 on the DKK side. This
> should only be done when calculating the profit and asset totals.
>
> What do you think?
The problem is that there is more than one possible valid policy.
The above doesn't represent it well.
The issue is that you really need to have a "native" currency
in which everything else is to be denominated, and then have some way
of representing the discrepancies that come from shifts in currency
exchange rates.
Thus, with 7 DKK = 1 USD, and assuming that $USD is the "base currency,"
the above transfer would be treated as:
Debit Danish Bank account $100 (with parenthetic DKK 700 amount)
Credit US Bank $100 (no parenthetic amount).
That Danish transaction simultaneously has two amounts; one in the
"base" currency, and one in the "true" currency.
If, the next month, the exchange rate changes to 8 DKK = $1 USD, then
there needs to be a currency exchange transaction that lowers the
value from $100 (still with DKK 700) to $87.50.
Thus, there's a *third* account involved, the "Currency Exchange
Gain/Loss" account, which takes up the slack between any differences
between "base" and "actual" currency for the account.
The point here is that in order to manage this, you need to have two
values for each transaction, where one of those values can fluctuate
based on exchange rates, and where the other is permanently fixed.
The determination of which is fixed and which fluctuates depends on the
native currency of the account with which the transaction is associated.
Note that the difference doesn't appear until there is a change in the
exchange rate.
R/3 handles this by having two values on each transaction line item,
one for the local currency, and one for the company currency.
--
Christopher B. Browne, [EMAIL PROTECTED], [EMAIL PROTECTED]
Web: http://www.ntlug.org/~cbbrowne SAP Basis Consultant, UNIX Guy
Windows NT - How to make a 100 MIPS Linux workstation perform like an 8 MHz 286
----- %< -------------------------------------------- >% ------
The GnuCash / X-Accountant Mailing List
To unsubscribe, send mail to [EMAIL PROTECTED] and
put "unsubscribe gnucash-devel [EMAIL PROTECTED]" in the body
