[GNC] Multiple Currency transaction with bank fee

Christian Kluge frakturfreak at gmail.com
Mon Nov 19 15:27:59 EST 2018


Am 19.11.2018 um 17:28 schrieb David T. via gnucash-user:
> 
> 
>> On Nov 19, 2018, at 2:09 AM, Christian Kluge <frakturfreak at gmail.com> wrote:
>>
>> Am 18.11.2018 um 17:50 schrieb David T. via gnucash-user:
>>> Hello,
>>>
>>> I am a longtime user (GC3.3, Mac OSX) trying to do something new in GnuCash, and I ran into a situation that I found rather confusing, and I’d like to share that with the group to see whether I have understood the situation correctly.
>>>
>>> Basically, I am transferring funds from a US dollar account to an Indian Rupee account. I have the USD account already, and created the INR account as an asset account: Assets:Current Assets:Checking Accounts:INR Checking. The account is denominated in INR, while the parent accounts are USD. I created the opening balance transaction using funds from my USD-denominated cash account. After tinkering around with the exchange rate dialog (God, the terminology used there is not understandable!), I got the numbers to be sane and based on the actual amounts involved.
>>>
>>> Then, I attempted to document a subsequent transfer I initiated using Xoom, and this is where things get messy. Xoom is an online funds transfer service that allows me to transfer this money to this INR account for a small fee.
>>>
>>> So, I opened the INR account and created the transfer for the base amount, and got a second sensible multicurrency transaction (again, after some tinkering. Did I mention that the terminology used in the dialog is confusing?).
>>>
>>> Then I remembered that Xoom charged me another $4.99, and I went to the Cash account and opened up the transaction in split mode. There, I changed the total amount charged to my origination account to $504.99, fully expecting to assign the extra $4.99 to Expenses:Bank Fees. Imagine my surprise when I received the Exchange Rate dialog again, which GnuCash would not let me dismiss. I could only adjust the numbers, and everything I did messed things up further.
>>>
>>> Knowing that many others are using GC for just this sort of use case, I deleted the transaction, and then read a bit in the Guide, but didn’t find anything to explain the odd situation I found myself in. I *did* notice that the example in the Guide started in the originating account and added splits as: Total Cost, Fee Charged, Net Transferred. When I tried THAT sequence, it all worked out.
>>>
>>> Here's, my question: Is this the *only* sequence a user should follow? It seems rather limiting for GC not to allow a user to add a new split to a multicurrency transaction, but I am unable to see any way to subsequently add a fee*. It’s not a big deal, but we should perhaps make it clear to users that they must follow this split sequence to enter such transactions.
>>>
>>> It occurs to me that part of the problem likely has to do with where the tranasction was originally entered. I entered this transaction in the INR account, and then attempted to change the USD figure from the USD account. Maybe this is why the exchange rate dialog triggers when I try to change that split. I surmise this because in further tests, I note that I could change the INR split without trouble. I would assume that the dialog would trigger based on the account in which the tranaction was edited (rather than whether the split is considered the “foreign” currency split), but that seems to be wrong.
>>>
>>> David
>>>
>>> * - I recognize that I could roll the fee into the exchange rate itself (similar to how some recommend rolling investment fees into the stock share prices), but I am glutton for punishment, and I like to see how much it is costing me to shift money around.
>>
>> What’s so confusing about the currency exchange rate window? I
>> understand it perfectly fine.
> 
> I’m sure you don’t intend for your comment to be dismissive, but it really comes across that way. 
> 

To be honest, I do a little, because I don’t understand why somebody can
get so worked up about simple number representation.

> For what it’s worth, I specifically find the Exchange rate portion extremely counterintuitive; most rates I see are described using whole number (or close to whole number) ratios—such as 72.1 Rupees per Dollar, or 8271 Soum to 1 dollar. Entering “.013963” is not particularly clear (I *could* always go and Google what 1/72.1 is, but that sort of removes the ease factor). And, while it may be a function of my feeble mind, “72.1 Rupees to the Dollar” sounds to me like “72.1:1”—which you really shouldn’t put into that box, unless you want to see sheer lunacy. (Really—I don’t know how the result occurs or what mathematical function is triggered)
> 
It’s just another way of formatting the number. As far as I remember,
this number format was chosen, because of better rounding options.
However I seem to remember that there was bug request to change the
representation to the user to just a decimal point number and use the
fraction for the internal calculations. This format that resembles your
description can also be seen right of the input fields. Even with one
line for each currency as base currency.

> 
> Now, it would in fact be preferable to enter the exchange rate as the ratio of the two sides of the transaction (500 USD divided by 35513 INR), since this will result in a more accurate reflection of the real world transaction you got. Indeed, this is rather what the second option seems focused on.
> 
>>

Kind regards

Christian Kluge



More information about the gnucash-user mailing list