GNUCash Import QIF - Help Please!

[GT-I9070 H]

Hi Edward Doolittle,

You are welcome!


2015-07-06 22:14 GMT-04:00 Edward Doolittle <edward.doolittle at gmail.com>:

>
>
> On 6 July 2015 at 00:47, GT-I9070 H <gti9070h at gmail.com> wrote:
>
>> 2015-07-05 13:20 GMT-04:00 Wm <wm+gnc at tarrcity.demon.co.uk>:
>>
>>
>> >   What I think you do is this:
>> >>  Buy X100 for Y50 and then reprice everything you buy in X in terms
>> >>  of Y.
>> >>
>> >> Yeah. Now I have X100 for spending. When I spend all X100 I will have
>> >> spent all Y50.
>> >>
>> >
>> > This is an extremely simplistic view and probably only works if you only
>> > or mainly work in cash.
>>
>> "probably"?
>> Or works or does not work. Nothing needs to be complicated to work, if it
>> works better if it is simple. Geniality is work with simply.
>
>
> GTI, there is a difference between "simple" and "simplistic". Your view of
> currency exchange is not rocket science, so it is simple, but it neglects
> important considerations, which makes it simplistic.
>

OK, I understand.

Of course, Mathematics and accounting has its approaches philosophies also
which should seek mathematical support, but Mathematics and accounting are
exact sciences, are rocket science.

Maybe my currency exchange vision is not. I will not be sad if I'm wrong I
want is to understand the advantages and disadvantages of this models for
multi currency approach and where I can be wrong. Maybe have no errors.

Someone defending someone's ideas told me "Is it possible" is the same
thing as "I Want" in English.
You tell me that "Simplistic" is different from "Simple". I agree with you.
That there is a difference I know, but until you tell me what the
difference is in this context (What important considerations I neglects) I
will think of you trying to manipulate the right and wrong.



> > I, and I expect most other people here, have access to credit and foreign
>> > currency accounts.  Essentially I am saying many of us don't carry great
>> > big wadges of real live cash around in our pocket most days so the USD
>> or
>> > YEN in my pocket changes value over time to me.
>> >
>> > Dunno about anyone else but I can't afford the bodyguards for lots of
>> cash
>> > these days!
>>
>>
>> Any commodity can be treated like that. Everything has its purchase price,
>> its valuation price and the selling price.
>> Only are real transactions that have been completed. If the purchase of
>> the
>> currency has been performed, then the purchase price is real. The
>> valuation
>> price is just a "valuation" that serves to determine the selling price.
>> You
>> will only have the REAL selling price after you make the sale before that
>> these prices are hypothetical and not real.
>>
>> I prefer to work with the purchase price (REAL PRICE), would you rather
>> work with the valuation price (HYPOTHETICAL PRICE).
>>
>>
>> GTI, the purchase price is only "real" at the moment of purchase. It
> doesn't
> continue to be real for an indefinite time afterward. The only real things
> in all
> of this are the transactions.
>

I agree with you.
The transaction has date and the purchase price refers to this date. This
informations should be registered together. It is real on this date.
Nothing prevents us from using the online current rates to evaluate our
asset at later dates of the date of purchase.

The motivations for adopting the purchase price (exchange rate) set in
purchasing for the entire volume of purchased currency are:

* Do not produce errors of fluctuations in assets. If I bought X100 by Y50,
when I spend the Y50 I will have spent the X100 and not a different value
that.

* No need of online exchange rates for transactions, only for evaluations.



> I paid X dollars Canadian to get Y dollars US:
> all that matters as far as accounting goes are the X and Y. Price is an
> abstraction.
>

Yeah. I agree.
Floating price is a abstraction FIXED price T (Rate) is:  T = X/Y (rate of
all that matters)



> Now if I start buying things in US dollars, the transaction I record
> is "Z US dollars for lunch".
>

The motivation to keep expenses only in standard currency is to reduce the
number of expense accounts otherwise our expense accounts have multiplied
to the extent that we expenditures in other currencies to a very large
number.



> To translate that back into Canadian is to me
> nonsensical.
>

The motivation to translate that back to default currency is the reason
immediately above and be able to make a "approximate" prices comparison of
products bought in another country with the products you could have bought
in your country on the same date and still be able to use for comparison in
the transaction the current online rate obtained at a click for this
comparison without register this new rate on this transaction.


> Perhaps what I bought simply cannot be purchased in Canadian
> dollars.
>

Yes, perhaps, but most can be purchased in the default currency.



> Perhaps the exchange rate is fluctuating wildly.
>

Nothing prevents you from using the current rate to see the actual exchange
with a few clicks on that transaction.



> Perhaps I made
> several purchases of US dollars at different prices: then is my exchange
> rate some kind of average? Or am I paying with the oldest US dollars first?
> Or the newest?
>

Yes again. Your rate will be the purchase price for that amount purchased.
This information (purchase price) should be kept in GnuCash prices editor
and to facilitate on the purchase currency transaction (Memo or
Description) in its exclusive account for control this amount and in each
transaction of course.

The motivation to spent the old or the new rate first (What account control
to use) is subjective and could be the discretion of each one.
You might find more interesting to spend the oldest first or you might find
it interesting to use the cheapest first because you intuitively want to
pay less in your default currency. You might find more interesting to spend
more closer to the atual online rate for a "more accurate" comparison with
the prices of the products in your country.

Remember that all your asset may be evaluated by the current online rate.

The important thing is not to generate fluctuations in assets and know just
what you have in the accounts can be converted to the default currency
generating profit or loss.



> You say you ignore valuation price, which may be fine for you, but if I
> were to
> find that my Y dollars US had suddenly doubled in valuation I would be
> tempted to do something about it: "rebalance" or something of that nature.
> Unless I misunderstand, your proposed system neglects that kind of
> situation.
>

I do not ignore the evaluation price I just do not use it in transactions,
I use it only for what it serves, for evaluation.
As I said above, nothing prevents you from using the evaluation price to
evaluate all your asset and make decisions.



> >  What we have here is a simple and common transaction between two
>> >> different currencies AND an exchange rate, so I record X, Y and the
>> >> rate.
>> >>
>> >
>> > But the rate isn't true as it will have changed.  You're fooling
>> yourself
>> > and, I think, this is why no-one else wants to do this.  It is weirdly
>> > artificial, people know you're fooling yourself so why formalise it.
>> >
>>
>> You is that this fooling yourself.
>> Only are REAL transactions that have been COMPLETED, PERFORMED, MADE,
>> EXECUTED, TERMINATED. Valuations (floating rates) are speculations.
>>
>
> I agree that real transactions are the only ones of interest. And the only
> transactions
> that have been completed in my example above are Y USD for X CAD and then
> lunch for Z USD. Those are the only transactions that should be recorded.
> In fact,
> they are the only transactions that are recorded in GnuCash, which means
> it's working
> exactly as it's supposed to. The price business is artificial. I certainly
> have no interest
> in struggling with your proposed system when there is something better,
> and as you
> say REAL already. Just record the transactions then figure out a way to
> generate
> whatever reports you want. I will generate a different set of reports for
> my transactions,
> and we can both be happy.
>

I agree with you too.

Some of the advantages of this system that I propose were exposed above.
Each system has its advantages and disadvantages and we are all free to
choose, what they cannot have is: Failures.

I did not say that the systems we have currently in GnuCash are not real.
What I said was that to keep spending accounts only in the default currency
and does not produce artificial fluctuations in our assets is better to use
the fixed practiced rate than the online flutuate current rate.


> You should investigate the currency XXX with which gnc allows you
>> > (relatively) open exchange, it might suit you as an intermediate
>> currency.
>>
>>
>> I've looked and did not serve me.
>>
>>
>>
>> >   Until you get some more of X at a slightly different rate at which
>> >>  point the same snack now costs Y.54132
>> >>
>> >> No, maybe Yes. I spent all the X money in your rate (1/2), buy more
>> >> X money in your new rate and follow spending. eg. X=Y*1/3.
>> >>
>> >
>> > This is where your model collapses, unless you maintain cash amounts in
>> > varying currencies which, if I recall correctly, was what you didn't
>> want
>> > to do.
>>
>>
>> We buy and sell none, one or several currencies and not see any problem in
>> controlling my stock of merchandise (currency).
>> I do not know if my model is perfect, but it certainly did not collapse
>> anywhere yet.
>> if I spend Y100 I will pay with Y50 (rate: 1/2) more Y50 (rate: 1/3) where
>> X = Y50 *1/2 + Y50*1/3 (split). This is a REAL transaction.
>>
>> If you want to do these kinds of calculations, no one can stop you, but
> they
> are not real. You have to make an arbitrary decision about how to value the
> commodity if you have made multiple purchases. Oldest first, newest first,
> or
> some kind of average (of which there may be many). You also have to keep
> a record not only of how many Y you have, but also how many you purchased
> in each transaction in the past. Not so simple any more.
>

Ok, literally, it is not real. By this shall all the current methods are
equal. That I explained above, but it is simple it is. Just more work.
Everything has a cost, advantages and disadvantages. If the advantages
interest you it's you decide.



> > When I asked for your help in this thread I meant a way to *import*
>> >> transactions WITH off-line exchange rate from an Excel spreadsheet
>> >>
>> >
>> > OK, I'll say it is not possible.  You wanted an answer, now you have one
>> > and a why...
>>
>>
>> To strengthen: Are you saying that GnuCash can not import offline exchange
>> rates from Excel or any other place because of this approach to
>> multicurrency we discussed here now?
>>
>>
>> GnuCash imports transactions. Prices and everything you discussed can be
> calculated given the transactions. Go ahead and write routines to
> calculate and
> report what you want. There's no need to import prices because they can be
> calculated. No?
>

No. far as I know, GnuCash import transactions with only one currency (a
value) how do we calculate the rate? Impossible.



> If prices could be imported it would open the door to inconsistencies...
>

No. That would not happen because I currently use this system and just need
a way to enter with the rates in my transactions without having to type
them.

Imports only would automate what we can already do manually.


> (what if
> the calculated price is different from the recorded price?) ...
>

Overwrite the old and calculate one of the new value.


> and would require a
> different number format (rational numbers rather than decimal fractions). A
> huge mess for what is (in my opinion) no gain whatsoever.
>

No. That would not happen as explained above.


Thanks Edward Doolittle!


Regards
GTI