software defect on mixed currency splits

[Wouter van Marle]

On Sun, 2010-09-12 at 21:53 +0100, Fred Bone wrote:
> On 12 September 2010 at 17:32, cognitive.libertarian+ml at gmail.com said:
> 
> > I'm running into a problem when a split transaction involves both
> > mixed currencies, and like currencies.
> > 
> > Here's the scenario.  Rent is €500, and utilities is €50.  The bill is
> > paid on a USD-denominated credit card.  The credit card has a FX
> > commission cost to account for.  So here's what the transaction *should*
> > look like (assuming the realtime market FX rate is 1.28 EURUSD, for
> > example):
> > 
> > [liabilities:credit card:usd] 
> > 
> >   rent  $640  --->  500 [expense:rent:eur]
> >   utils $ 64  --->   50 [expense:utils:eur]
> >   FX    $ 10  --->   10 [expense:banking:forex:usd]
> > 
> >   total USD debited: 714
> >   total EUR costs:   550
> > 
> > The above entry is impossible because of a software defect that forces all
> > transactions in the group to do a currency conversion, even when the
> > accounts at both ends are in the same currency (in this case, the FX line
> > item that does not involve euros).
> > 
> > So GC does this:
> > 
> > [liabilities:credit card:usd] 
> > 
> >   rent  $640  --->  500    [expense:rent:eur]
> >   utils $ 64  --->   50    [expense:utils:eur]
> >   FX    $ 10  --->    7.81 [expense:banking:forex:usd]
> > 
> >   total USD debited: 714
> >   total EUR costs:   557.81 <- false amount
> > 
> > This means the euro costs are 7.81 in excess of the actuals.  GC
> > actually forces an exchange rate to be entered on the FX cost, even
> > when both accounts involved are USD accounts.  
> > 
> > The workaround is to enter all the non-mixed currencies as separate
> > transactions from the group of splits.  It's messy, but seems like the
> > only option.
> 
> I fail to see the problem. What do you expect the EUR equivalent of the 
> USD10 to come to? 

As OP says, the problem is that this USD 10 amount should not be
converted in the first place. There is the problem.

And indeed a transaction like this is afaik not possible to do in
GnuCash. You will either have to add separate transactions on your USD
credit card account, or add a transfer account where you book the full
USD credit card amount and then split it in EUR and USD amounts.

GnuCash supports only one conversion per transaction (split transactions
apparently count as one; I have tried what you did above before and
failed as well). So USD to EUR. Or invoice to payment. Or share units to
cash units.

I have similar issues regularly: issue USD invoice and get paid in HKD.
Make EUR remittance to pay a bill but pay from a USD account. Both can
not be done directly.
Transaction 1: AR --> transfer account for USD payment
Transaction 2: transfer account --> HKD bank account for conversion HKD
to USD.

Bills payments go similar.

Selling/buying stocks or other funds denominated in a foreign currency
also have to be done that way.

It's a limitation but I can very much imagine that supporting more than
one exchange per transaction can lead to a programmatic nightmare. 

Wouter.


> If something other than EUR7.81, you can enter it at 
> the time you enter the FX charge - at least, you can every way I've tried 
> entering such a txn (though there may be procedures I haven't thought of, 
> but I'd be surprised if you can't enter different exchange rates).
> 
> _______________________________________________
> gnucash-user mailing list
> gnucash-user at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> -----
> Please remember to CC this list on all your replies.
> You can do this by using Reply-To-List or Reply-All.