Am 19.11.2018 um 17:28 schrieb David T. via gnucash-user: > > >> On Nov 19, 2018, at 2:09 AM, Christian Kluge <frakturfr...@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 _______________________________________________ gnucash-user mailing list gnucash-user@gnucash.org To update your subscription preferences or to unsubscribe: https://lists.gnucash.org/mailman/listinfo/gnucash-user If you are using Nabble or Gmane, please see https://wiki.gnucash.org/wiki/Mailing_Lists for more information. ----- Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All.
