software defect on mixed currency splits

[Fred Bone]

On 13 September 2010 at 11:31, Wouter van Marle said:

> 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.

Why not? It is a value. Either it is a cost associated with the txn, in 
which case it should be attached as a split; or it isn't, in which case 
it should be kept separate. As I said, what do you want the EUR 
equivalent to show as? You can have anything you like (within reason: 
zero would imply an infinite exchange rate, which AFAICT isn't 
supported).

To put it another way, the costs incurred (in the example) came to 
USD714, which at the stated exchange rate is EUR557.81.

> 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.

One conversion rate per split, in my experience. (Of course I haven't 
tried v2.3.*)

> 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. 

It's already there.