Bank/CC to Expense, diff currencies

Christoph R subscriptions+listen at rohland.net
Wed Mar 29 11:23:26 EDT 2017 

And Apple Mail apparently always embeds them - even for text only emails. 

Cheers,
Christoph

> Am 29.03.2017 um 15:37 schrieb Derek Atkins <derek at ihtfp.com>:
> 
> Hi,
> 
> On Wed, March 29, 2017 9:29 am, Christoph R wrote:
>> Apparently one cannot send attachments to the list.
> 
> You can send an *attachment*.  You cannot send an embedded image.
> 
>> Here is a link to the screenshots:
>> https://www.dropbox.com/sh/q2wex56hud9p1nh/AACGcS9-euJaTR0n6dOvifvBa?dl=0 <https://www.dropbox.com/sh/q2wex56hud9p1nh/AACGcS9-euJaTR0n6dOvifvBa?dl=0>
>> 
>> Cheers,
>> Christoph
> 
> -derek
> 
>> 
>>> Am 29.03.2017 um 14:29 schrieb Christoph R
>>> <subscriptions+listen at rohland.net>:
>>> 
>>> Oops, apparently the pictures are missing. Trying again
>>> 
>>> 
>>> 
>>> Gruß,
>>> Christoph
>>> 
>>>> Am 29.03.2017 um 14:25 schrieb Christoph R
>>>> <subscriptions+listen at rohland.net>:
>>>> 
>>>> Hi Ken,
>>>> 
>>>> 
>>>>> In the end; however, this is all a moot point as I have concluded that
>>>>> except for the transfer of monies between balance sheet accounts, that
>>>>> is bank a/c to bank a/c or bank a/c to CC account, GC is unable to
>>>>> handle two currencies in the same transaction, such as the example
>>>>> noted above.
>>>> 
>>>> I am using multi-currency transactions with any kind of account. But I
>>>> know that the interface might be confusing. It especially depends if
>>>> you use trading accounts or not.
>>>> 
>>>> If you are using the default setting without trading accounts you have
>>>> to fill out all splits in the local currency. This means in the USD CC
>>>> account the transaction looks like this:
>>>> 
>>>> 
>>>> 
>>>> and in the Canadian espense account it looks like this:
>>>> 
>>>> 
>>>> 
>>>> 
>>>> If you enable trading accounts gc does behave nearly as you expect:
>>>> Every split has to be entered in the split currency and the transaction
>>>> is shown the same way in both accounts:
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> But in both cases gc will bring up the exchange rate window and you
>>>> have to enter that in addition.
>>>> 
>>>> HTH
>>>> 
>>>> Cheers,
>>>> Christoph
>>>> 
>>>>> Am 27.03.2017 um 00:38 schrieb Ken Runge <kr at bell.net>:
>>>>> 
>>>>> Thanks for your reply, I must admit after reading my previous late
>>>>> night rant born out of frustration I am pleasantly surprised you
>>>>> bothered. Also sorry for not replying earlier but ran into another
>>>>> problem which would have nixed my using GC at all, but that has now
>>>>> been resolved. So my reply to your reply much of it written last
>>>>> week...
>>>>> 
>>>>> _It sounds like you're not quite understanding the basics of
>>>>> double-entry accounting. _Please excuse my trumpishness, but, after 25
>>>>> years experience as the chief accountant in a multi-million dollar
>>>>> social service agency with 500+ employees using and supervising an
>>>>> accounting staff working with Microsoft Dynamics, which I initially
>>>>> evaluated, purchased, installed and trained others to use, not to
>>>>> mention instructing accounting at the local community college, I am
>>>>> pretty sure I have the hang of that 'double-entry' thingy you
>>>>> mentioned.
>>>>> 
>>>>> My problem is not understanding the concepts of accounting but how to
>>>>> implement those concepts with GU! This is, at its base, a technical
>>>>> issue wherein I would like to understand the work flow (order of key
>>>>> strokes if you will) of how to actually enter a multi-currency
>>>>> transaction. What I am after is an efficient method to get the
>>>>> following input starting with an entry from a Bank downloaded QFX
>>>>> file.
>>>>> 
>>>>> DB CND Expense $132.000
>>>>> 	CR USD Credit Card Account $100.00
>>>>> 
>>>>> In my dreams I would like to enter these two lines into, say the USD
>>>>> CC register, which is designated USD while the Exp. account is
>>>>> designated CDN and let the program fill in the blanks using the
>>>>> Trading Accounts for USD & CND. What I find is happening is a
>>>>> proliferation of unwanted 'out-of-balance' splits which I can't seem
>>>>> to get rid off and which I think should not even appear except perhaps
>>>>> if the entry, when finished, is not balanced. Of course, if the
>>>>> Trading Account function worked as it should the transaction, in its
>>>>> entirety, would never be out of balance. I think, or I thought at one
>>>>> time, I can get the transaction to balance but the process is
>>>>> difficult and cumbersome and frankly a pain-in-the-ass.
>>>>> 
>>>>> _When I travel to a foreign country I just manually convert the
>>>>> foreign transactions back into USD and use my USD Asset/Liability and
>>>>> Expense accounts. _But, of course, your example is not multi-currency
>>>>> but rather a 'back-of-an-envelope' example. If you had a actual EUR,
>>>>> GBP or CND account so designated in GC then your calculations would
>>>>> not work because you need to start with the non-USD amount as my
>>>>> example above outlines. If you charge the converted USD amount to the
>>>>> foreign currency account you would never be able to download and
>>>>> reconcile that account because your bank statement would report GBP
>>>>> 10.00 but your GC account would show something different. What I think
>>>>> you maybe referring to is what happens when your USA bank does the
>>>>> conversion for you and charges your USD account with the equivalent of
>>>>> the foreign purchase. From GC's point of view this is not
>>>>> multi-currency.
>>>>> 
>>>>> In the end; however, this is all a moot point as I have concluded that
>>>>> except for the transfer of monies between balance sheet accounts, that
>>>>> is bank a/c to bank a/c or bank a/c to CC account, GC is unable to
>>>>> handle two currencies in the same transaction, such as the example
>>>>> noted above. Accordingly, I have created a parallel set of expense
>>>>> accounts in USD and will record USD CC to USD exp. Still a major pain
>>>>> for a program which purports to support multi-currency but one has to
>>>>> work with what has available. Sure hope I don't open GBP or EUR bank
>>>>> accounts in the future!  With some experimenting I have got an I/E
>>>>> report to show what I am looking for.
>>>>> 
>>>>> Thanks again for your interest.
>>>>> 
>>>>> 
>>>>> 
>>>>> On 3/22/17 1:08 P, 13:8, Derek Atkins wrote:
>>>>>> Hi,
>>>>>> 
>>>>>> Ken Runge<kr at bell.net>  writes:
>>>>>> 
>>>>>>> Thanks for your input. Let me start by relating an experience from a
>>>>>>> training
>>>>>>> session I attended many years ago. At that event one of our group
>>>>>>> (me) was
>>>>>>> given a simple diagram and asked to describe it to the others of the
>>>>>>> group
>>>>>>> such that, unseen by them, they could draw it. It was a hopeless and
>>>>>>> utter
>>>>>>> failure! This is what is happening to me now. I simply have no idea
>>>>>>> what you
>>>>>>> are saying.
>>>>>>> 
>>>>>>> "Transfer" referes to the "Transfer Account".  In a basic register
>>>>>>> it's
>>>>>>> the "other" account (to balance the transaction).  If you're in an
>>>>>>> expanded transaction mode it referes to the account tied to the
>>>>>>> specific
>>>>>>> split on that line."
>>>>>> It sounds like you're not quite understanding the basics of
>>>>>> double-entry
>>>>>> accounting.  Every balanced transaction must have at least two
>>>>>> splits, a
>>>>>> Debit and a Credit, which balance out.  It models moving money from
>>>>>> one
>>>>>> place to another, e.g. you buy $100 of groceries with your credit
>>>>>> card,
>>>>>> so you Credit your Liabilities:Credit Card account $100 and then
>>>>>> Debit
>>>>>> Expenses:Groceries that same $100.
>>>>>> 
>>>>>> When you open an account register, you're tying all transactions back
>>>>>> to
>>>>>> that account.  It also hides the second split, since it can be mostly
>>>>>> inferred from the primary.  So when you enter a transaction you're
>>>>>> e.g. debiting the "register account" and then crediting the "Transfer
>>>>>> Account", which is the *other* account in the second split of the
>>>>>> transaction.
>>>>>> 
>>>>>>> If I use the basic register and select the expense account and enter
>>>>>>> CND
>>>>>>> amount as a debit on the single line of the register, the expense
>>>>>>> and USD cc
>>>>>>> amounts are reversed.
>>>>>> NOTE: It's possible this behavior has changed recently.  Historically
>>>>>> the register shows you values in the current account currency.  I.e.,
>>>>>> if
>>>>>> you have a USD account open, then it will show you all values in USD.
>>>>>> Then you need to use the exchange-rate dialog to convert that to any
>>>>>> foreign currency amounts.  It's POSSIBLE that this changed, however.
>>>>>> In
>>>>>> basic mode it definitely shows values in the local account currency.
>>>>>> 
>>>>>> What account register are you opening here?  Are you opening your USD
>>>>>> CC
>>>>>> account?  Or the CND Expense Account?  (Do I have that right -- you
>>>>>> haven't been completely explicit about what you're opening/doing).
>>>>>> The
>>>>>> register would give you values in that currency and expect you to
>>>>>> enter
>>>>>> them in that currency.
>>>>>> 
>>>>>> If the amounts are reversed then you're possibly entering them in the
>>>>>> wrong columns.  Are you doing that?
>>>>>> 
>>>>>>> Is there any reason not to just convert the expense into your local
>>>>>>> currency?
>>>>>>> 
>>>>>>> And just how do I do that?
>>>>>> Simple math.
>>>>>> 
>>>>>> When I travel to a foreign country I just manually convert the
>>>>>> foreign
>>>>>> transactions back into USD and use my USD Asset/Liability and Expense
>>>>>> accounts.  So let's say I pay €100 for a hotel room.  I'd figure out
>>>>>> exactly how much that is in USD (e.g. $125.34) and then I'd enter a
>>>>>> transaction for that USD amount.  I'd notate the transaction to
>>>>>> remind
>>>>>> me it was €100, but all *numbers* are all in USD.
>>>>>> 
>>>>>>> Thanks anyway
>>>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> 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.
>>>> 
>>>> _______________________________________________
>>>> 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.
>>> 
>>> _______________________________________________
>>> 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.
>> 
>> _______________________________________________
>> 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.
> 
> 
> -- 
>       Derek Atkins                 617-623-3745
>       derek at ihtfp.com <mailto:derek at ihtfp.com>             www.ihtfp.com <http://www.ihtfp.com/>
>       Computer and Internet Security Consultant

More information about the gnucash-user mailing list