[GNC-dev] book currency is what ... question mark

classic Classic list List threaded Threaded
25 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[GNC-dev] book currency is what ... question mark

GnuCash - Dev mailing list
at the risk of appearing to be an imperialist, what is "book currency" ?

I think of "home currency" as whatever currency most people close to you
(the reader) use to buy and sell ordinary stuff like carbohydrate
staples (rice, bread, etc) and water

in the UK that is GBP, in the USA it is USD, in most of Europe it is
EUR, in other places, depending on government, it might be something else.

my point is, unless your government is failing, you should be able to
use the same currency for your home currency and your bookkeeping.

presuming I haven't gone insane yet, does anyone know what a "book
currency" is?

If someone really wanted to run a set of accounts in another currency
gnc isn't stopping them, the underlying transaction stream works
perfectly regardless.

Curious minds, etc.
--
Wm


















_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: [GNC-dev] book currency is what ... question mark

John Ralls-2


> On Feb 11, 2019, at 6:49 PM, Wm via gnucash-devel <[hidden email]> wrote:
>
> at the risk of appearing to be an imperialist, what is "book currency" ?
>
> I think of "home currency" as whatever currency most people close to you (the reader) use to buy and sell ordinary stuff like carbohydrate staples (rice, bread, etc) and water
>
> in the UK that is GBP, in the USA it is USD, in most of Europe it is EUR, in other places, depending on government, it might be something else.
>
> my point is, unless your government is failing, you should be able to use the same currency for your home currency and your bookkeeping.
>
> presuming I haven't gone insane yet, does anyone know what a "book currency" is?
>
> If someone really wanted to run a set of accounts in another currency gnc isn't stopping them, the underlying transaction stream works perfectly regardless.

Book currency is the currency of the book's root account, which you set when you created the book. For nearly everyone it is indeed their home currency, but that's immaterial to GnuCash.

Suppose, though, that while your book currency is GBP, you have accounts in EUR and RUB and you do a transaction between those two. The transaction will set the transaction currency to the account whose register you use to create it and will balance the transaction in that currency: If you start in the RUB account then it will convert the EUR amount to a RUB value and check that the credit and debit values are equal.

 What Alex is working on is to instead use the book currency for balancing: GnuCash would in this example convert both RUB and EUR amounts to GBP values and balance the transaction in GBP. It's an interesting idea but I suspect that it will be very difficult to get right, a suspicion at least somewhat borne out by the fact that Alex has been working at it for at least 3 years.

Regards,
John Ralls

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: [GNC-dev] book currency is what ... question mark

Alex Aycinena-2
In reply to this post by GnuCash - Dev mailing list
>
>
>
> ---------- Forwarded message ----------
> From: John Ralls <[hidden email]>
> To: Wm <[hidden email]>
> Cc: [hidden email]
> Bcc:
> Date: Mon, 11 Feb 2019 20:48:53 -0800
> Subject: Re: [GNC-dev] book currency is what ... question mark
>
>
> > On Feb 11, 2019, at 6:49 PM, Wm via gnucash-devel <
> [hidden email]> wrote:
> >
> > at the risk of appearing to be an imperialist, what is "book currency" ?
> >
> > I think of "home currency" as whatever currency most people close to you
> (the reader) use to buy and sell ordinary stuff like carbohydrate staples
> (rice, bread, etc) and water
> >
> > in the UK that is GBP, in the USA it is USD, in most of Europe it is
> EUR, in other places, depending on government, it might be something else.
> >
> > my point is, unless your government is failing, you should be able to
> use the same currency for your home currency and your bookkeeping.
> >
> > presuming I haven't gone insane yet, does anyone know what a "book
> currency" is?
> >
> > If someone really wanted to run a set of accounts in another currency
> gnc isn't stopping them, the underlying transaction stream works perfectly
> regardless.
>
> Book currency is the currency of the book's root account, which you set
> when you created the book. For nearly everyone it is indeed their home
> currency, but that's immaterial to GnuCash.
>
> Suppose, though, that while your book currency is GBP, you have accounts
> in EUR and RUB and you do a transaction between those two. The transaction
> will set the transaction currency to the account whose register you use to
> create it and will balance the transaction in that currency: If you start
> in the RUB account then it will convert the EUR amount to a RUB value and
> check that the credit and debit values are equal.
>
>  What Alex is working on is to instead use the book currency for
> balancing: GnuCash would in this example convert both RUB and EUR amounts
> to GBP values and balance the transaction in GBP. It's an interesting idea
> but I suspect that it will be very difficult to get right, a suspicion at
> least somewhat borne out by the fact that Alex has been working at it for
> at least 3 years.
>
> Regards,
> John Ralls
>
>
John - what you are saying is absolutely correct except for the part about
working on it for three years. I did start it a while ago, but then other
commitments have prevented me from working on it at all for a couple of
years. The part you describe above will not be hard since the logic already
exists; the integrated lot tracking, though, will be harder. I will shortly
be able to get back to it though. Alex
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: [GNC-dev] book currency is what ... question mark

GnuCash - Dev mailing list
In reply to this post by John Ralls-2
On 12/02/2019 04:48, John Ralls wrote:

>
>
>> On Feb 11, 2019, at 6:49 PM, Wm via gnucash-devel <[hidden email]> wrote:
>>
>> at the risk of appearing to be an imperialist, what is "book currency" ?
>>
>> I think of "home currency" as whatever currency most people close to you (the reader) use to buy and sell ordinary stuff like carbohydrate staples (rice, bread, etc) and water
>>
>> in the UK that is GBP, in the USA it is USD, in most of Europe it is EUR, in other places, depending on government, it might be something else.
>>
>> my point is, unless your government is failing, you should be able to use the same currency for your home currency and your bookkeeping.
>>
>> presuming I haven't gone insane yet, does anyone know what a "book currency" is?
>>
>> If someone really wanted to run a set of accounts in another currency gnc isn't stopping them, the underlying transaction stream works perfectly regardless.
>
> Book currency is the currency of the book's root account, which you set when you created the book. For nearly everyone it is indeed their home currency, but that's immaterial to GnuCash.
>

OK I'll think about that.

Thought about it. Invalid.

The value is the same.

Ummm, JohnR I should not be beating you up on simple stuff like this.

> Suppose, though, that while your book currency is GBP, you have accounts in EUR and RUB and you do a transaction between those two. The transaction will set the transaction currency to the account whose register you use to create it and will balance the transaction in that currency:

I don't think it does or should, I just want the tx recorded naturally,
I think John Ralls is a mildly naughty man making a point to a slightly
younger man about an obscure point.  consider if the book should record
ordinary numbers and currency

What do other people expect?

If you start in the RUB account then it will convert the EUR amount to a
RUB value and check that the credit and debit values are equal.

it may for *some* value of equal.

IT OFTEN GETS IT WRONG BECAUSE YOU DUMB AMERICANS DON'T UNDERSTAND
ANYTHING OTHER THAN USD

Since I have GBP, EUR and RUB it is ordinary for me to experience
exchanges rates but I think my point stands, gnc isn't doing the sums right.

>   What Alex is working on is to instead use the book currency for balancing: GnuCash would in this example convert both RUB and EUR amounts to GBP values and balance the transaction in GBP. It's an interesting idea but I suspect that it will be very difficult to get right,

Wouldn't that mean a book for each currency?

Umm, it is a nice idea and may work for some exchanges but near
impossible for me

>a suspicion at least somewhat borne out by the fact that Alex has been working at it for at least 3 years.

Indeed.

I think the main problem will be getting more than one book to work
together as one.  Easy if you know how.

--
Wm




_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: [GNC-dev] book currency is what ... question mark

David Cousens
Wm,

My apologies for being long winded in the following, but I think it is
necessary to achieve clarity in what is proposed or intended.

The "book currency" is the currency assigned as the default currency, i.e
the currency of the root account, when you create a new book or file  using
the File->New File. I can create a new file with a default currency of USD
even though my "home currency" i.e. the currency where I live, is AUD and I
may choose  maintain a separate book or file with AUD as its root or default
currency. I can't think of a good reason why unless I happen to commute
between the US and Oz on a regular basis but I could choose to do it. When
you create a new account, it will by default have that "book currency"
unless you change it to another currency.

In what way do you think what John said is invalid?

For a transaction crediting an account in RUB and debiting one in EUR for
100 EUR at an exchange rate
 of iEUR=75.30 RUB(e.g. asset saving) the register for Savings EUR appears
as

                                Debit         Credit
Savings EUR              100.00
Savings RUB                               100.00

and the register for Savings RUB as

Savings EUR            7530.00
Savings RUB                             7530.00

when the transaction is carried out from the Savings EUR register (with
presumably the description field linking the two to show they are one and
the same transaction.

If it is initiated from the Savings RUB account the transactions appear
exactly as above in each register (provided of course the same exchange rate
is used. The advantage of the above for me is that the value of the
transaction in each currency is clear and the exchange rate used is clear
and calculable from the balances (as well as being able to check the price
editor.) and it is clear that the transaction is balanced in both
currencies.

If I start in Savings RUB , select the Savings EUR account and enter 100 it
is assumed to be in RUB not EUR as GnuCash operates at present. This is
clear, both registers are balanced and it is clear that they are correct.

I am presuming what you would like is to be able to start in the Savings RUB
register, select the Savings EUR account, enter 100.00 as the amount and
have that interpreted as !00.00EUR, even though the register currency is RUB
and then when you tab to the next line select Savings RUB have the currency
dialog popup, enter or fetch the exchange rate, and then display the amount
against the Savings RUB account in RUB. And similarly if you start in
Savings EUR and repeat the procedure. I.e. no matter what register is in
use, the register would display the amount of a split in the currency of the
account that the split is being made to not the currency of the register .
e.g.  would appear in the entries for both registers

                               Debit                  Credit
Savings EUR             100.00                                     (EUR)
Savings RUB                                      7530.00          (RUB)                                  

I personally would be quite happy if this were the way GnuCash registers
behaved, particularly if the currency symbol were to appear at the end of
each line to indicate the currency applicable to the split, but I find the
current system of displaying amounts in the currency of the register being
displayed, equally as clear. When I made my first multicurrency transaction,
it took me all of 5 seconds to follow what was happening.

I have some reservations about Alex's proposal to convert the amounts to the
"book currency" to check the balance. I may be misunderstanding the
intention here but it is not reallynecessary to check the balance as long as
the amounts in the splits are in agreement with any exchange rates and their
respecive currencies. It is the equality of
amount in currency 1 = amount in currency 2

If the book currency is USD (or AUD or any other third currency) then the
currency conversion becomes EUR<->USD<->RUB. The double conversions involved
to the EUR and RUB may introduce scope for rounding errors to produce
slightly different results on conversion back.  

It also assumes that EUR->USD-> RUB will give the same result as EUR->RUB.
Where the exchange rates are good to 6 significant figures, this appears to
be OK using today's figures
(https://www.xe.com/currencyconverter):
1 EUR=75.3052 roubles
1 EUR =1.12958 USD
1 USD = 66.6667 RUB => 1 EUR = 75.3054 RUB.

If you transfer amounts of >10000 roubles or equivalent this could start to
introduce significant errors into what is recorded.

My view is that the recording of foreign currency transactions really needs
to follow and reflect the events associated with the transaction as they
occurred. I.e. no conversion to an intermediate currency unless that is what
actually occurred.  I do not see how converting a transaction between
accounts in EUR and RUB via a third currency affects any entries in the
"book currency" until such funds are actually converted to that "book
currency" in any case and it is the price of that conversion when that
conversion actually occurs which ensures the integrity of the book in the
"book currency".

Reports could/should report a foreign currency balance at either a specified
exchange rate or the current exchange rate but should make clear what that
is, but that is a separate issue.

I am not sure what
>IT OFTEN GETS IT WRONG BECAUSE YOU DUMB AMERICANS DON'T UNDERSTAND
>ANYTHING OTHER THAN USD
contributed to the discussion of this point though Wm.

David Cousens



-----
David Cousens
--
Sent from: http://gnucash.1415818.n4.nabble.com/GnuCash-Dev-f1435356.html
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
David Cousens
Reply | Threaded
Open this post in threaded view
|

Re: [GNC-dev] book currency is what ... question mark

GnuCash - Dev mailing list
On 15/02/2019 01:44, David Cousens wrote:
> Wm,
>
> My apologies for being long winded in the following, but I think it is
> necessary to achieve clarity in what is proposed or intended.

Not at all, I appreciate your effort and have read what you have written
more than once.

> The "book currency" is the currency assigned as the default currency, i.e
> the currency of the root account, when you create a new book or file  using
> the File->New File. I can create a new file with a default currency of USD
> even though my "home currency" i.e. the currency where I live, is AUD and I
> may choose  maintain a separate book or file with AUD as its root or default
> currency. I can't think of a good reason why unless I happen to commute
> between the US and Oz on a regular basis but I could choose to do it. When
> you create a new account, it will by default have that "book currency"
> unless you change it to another currency.

Starting a tx stream with an unadorned (no currency) number is normal
for most people, changing it part way through is never going to be
simple.  Obvious answer?  Start with a nominal currency tx.
1 [nothing] = 1 [Currency of Choice]
it really can be that simple, put that right at the beginning and every
unassigned number has a currency.

> In what way do you think what John said is invalid?

I don't really disagree with John much, he is just often the person
brave enough to reply.

> For a transaction crediting an account in RUB and debiting one in EUR for
> 100 EUR at an exchange rate
>   of iEUR=75.30 RUB(e.g. asset saving) the register for Savings EUR appears
> as
>
>                                  Debit         Credit
> Savings EUR              100.00
> Savings RUB                               100.00
>
> and the register for Savings RUB as
>
> Savings EUR            7530.00
> Savings RUB                             7530.00
>
> when the transaction is carried out from the Savings EUR register (with
> presumably the description field linking the two to show they are one and
> the same transaction.

Ummm, have you heard of Trading Accounts?  The splits show actual values
for each register.

> If it is initiated from the Savings RUB account the transactions appear
> exactly as above in each register (provided of course the same exchange rate
> is used. The advantage of the above for me is that the value of the
> transaction in each currency is clear and the exchange rate used is clear
> and calculable from the balances (as well as being able to check the price
> editor.) and it is clear that the transaction is balanced in both
> currencies.

Trading Accounts, again.  Plus, I find it useful to right click and
choose Edit Exchange Rate if I want to check (the tx rate not the price
file rate should be prime) [1]

> If I start in Savings RUB , select the Savings EUR account and enter 100 it
> is assumed to be in RUB not EUR as GnuCash operates at present. This is
> clear, both registers are balanced and it is clear that they are correct.
>
> I am presuming what you would like is to be able to start in the Savings RUB
> register, select the Savings EUR account, enter 100.00 as the amount and
> have that interpreted as !00.00EUR, even though the register currency is RUB
> and then when you tab to the next line select Savings RUB have the currency
> dialog popup, enter or fetch the exchange rate, and then display the amount
> against the Savings RUB account in RUB.

Nope.  I normally know the exact amounts at either end of significant
tx, the exchange rate is implied from the numbers.  That *is* the right
way of doing the accounting.

You start with 100 of some currency and end up with 2300 of some other
currency, the *valuation* is separate.

gnc doesn't seem to get into this muddle with other commodities, btw,
just currencies.

aside: There may be occasions when an approximate value may work fine
because the amount doesn't matter but commercial exchange rates as
fetched from AV or taken from a bank or credit card statement for
example will rarely match an actual tx for most people so one should
never start from there.

> And similarly if you start in
> Savings EUR and repeat the procedure. I.e. no matter what register is in
> use, the register would display the amount of a split in the currency of the
> account that the split is being made to not the currency of the register .
> e.g.  would appear in the entries for both registers
>
>                                 Debit                  Credit
> Savings EUR             100.00                                     (EUR)
> Savings RUB                                      7530.00          (RUB)
>
> I personally would be quite happy if this were the way GnuCash registers
> behaved, particularly if the currency symbol were to appear at the end of
> each line to indicate the currency applicable to the split, but I find the
> current system of displaying amounts in the currency of the register being
> displayed, equally as clear. When I made my first multicurrency transaction,
> it took me all of 5 seconds to follow what was happening.

I am not too troubled by that as I put the currency at the end of each
account name that isn't GBP out of habit and even add GBP if it often
interacts with other currencies.

> I have some reservations about Alex's proposal to convert the amounts to the
> "book currency" to check the balance. I may be misunderstanding the
> intention here but it is not reallynecessary to check the balance as long as
> the amounts in the splits are in agreement with any exchange rates and their
> respecive currencies. It is the equality of
> amount in currency 1 = amount in currency 2

I think (and I accept my understanding may be wrong) what Alex is
proposing is, errrm, wrong.

> If the book currency is USD (or AUD or any other third currency) then the
> currency conversion becomes EUR<->USD<->RUB.

No it does not!  That is a valuation (i.e. balance sheet time exercise).

The tx of currency to currency is an exact number of so many units of
one thing to so many units of another.  No value!  Yes there may be
expenses and so on but you start with 10 of one thing and end up with 21
of another.  THAT IS THE TRANSACTION.

> The double conversions involved
> to the EUR and RUB may introduce scope for rounding errors to produce
> slightly different results on conversion back.

If someone only made very occasional tx outside of their home currency
(I include any other commodity) that probably wouldn't be an issue.  It
does, however, raise problems for tx in non-currecy stuff too and it
seems to me Alex is trying to do something other than understanding the
scary Trading Accounts.

> It also assumes that EUR->USD-> RUB will give the same result as EUR->RUB.
> Where the exchange rates are good to 6 significant figures, this appears to
> be OK using today's figures
> (https://www.xe.com/currencyconverter):
> 1 EUR=75.3052 roubles
> 1 EUR =1.12958 USD
> 1 USD = 66.6667 RUB => 1 EUR = 75.3054 RUB.
>
> If you transfer amounts of >10000 roubles or equivalent this could start to
> introduce significant errors into what is recorded.

It works the other way, actually, the larger the amounts exchanged the
closer you get to commercial rates.  Try sending 1 AUD / USD / GBP / EUR
to any of the others and see how much it really costs.

The point is, and I repeat myself, the actual values are what counts,
the exchange rate for a tx should be calculated from the values and at
the end of the tx you do NOT have so-much-worth of foreign stuff any
more than when you buy some shares you have so-much-worth of that
company.  You have 123 of another commodity, just like you have 321 of
shares of a company, the value of which changes constantly.

> My view is that the recording of foreign currency transactions really needs
> to follow and reflect the events associated with the transaction as they
> occurred. I.e. no conversion to an intermediate currency unless that is what
> actually occurred.

Yes.

> I do not see how converting a transaction between
> accounts in EUR and RUB via a third currency affects any entries in the
> "book currency" until such funds are actually converted to that "book
> currency" in any case and it is the price of that conversion when that
> conversion actually occurs which ensures the integrity of the book in the
> "book currency".

You have a value at the time and a value at the report date, reporting
the later date is balance sheet stuff, reporting the difference is
income statement stuff.

> Reports could/should report a foreign currency balance at either a specified
> exchange rate or the current exchange rate but should make clear what that
> is, but that is a separate issue.

I am certainly sure the tb is wrong.

> I am not sure what
>> IT OFTEN GETS IT WRONG BECAUSE YOU DUMB AMERICANS DON'T UNDERSTAND
>> ANYTHING OTHER THAN USD
> contributed to the discussion of this point though Wm.

If your world view is USD prime (which has largely been the case since
WW2 for USA people) you don't care much about the rest of the world
regardless of numbers and money, you expect other people to fit into
your tax system, your tax system's valuation of assets, following from
that you impose your view of the value of fx tx on other people and so
on.  None of this tends to be a problem so long as people are aware of
it.  That changed with Trump, his election defined some USA people as
being proud of being ignorant of the rest of the world.

[1] the tb is where this gets confused, it is not meant to value stuff
at a date but at the time of the tx, or if it isn't doing that it is
doing other weird stuff we're still working out.  the current tb
starting point (balance sheet, value of things at a single point in
time) is wrong.

--
Wm

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: [GNC-dev] book currency is what ... question mark

Christian Kluge
Am 17.02.2019 um 19:58 schrieb Wm via gnucash-devel:
> On 15/02/2019 01:44, David Cousens wrote:

>> If I start in Savings RUB , select the Savings EUR account and enter
>> 100 it
>> is assumed to be in RUB not EUR as GnuCash operates at present. This is
>> clear, both registers are balanced and it is clear that they are correct.
>>
>> I am presuming what you would like is to be able to start in the
>> Savings RUB
>> register, select the Savings EUR account, enter 100.00 as the amount and
>> have that interpreted as !00.00EUR, even though the register currency
>> is RUB
>> and then when you tab to the next line select Savings RUB have the
>> currency
>> dialog popup, enter or fetch the exchange rate, and then display the
>> amount
>> against the Savings RUB account in RUB.
>
> Nope.  I normally know the exact amounts at either end of significant
> tx, the exchange rate is implied from the numbers.  That *is* the right
> way of doing the accounting.

> You start with 100 of some currency and end up with 2300 of some other
> currency, the *valuation* is separate.

What about the situations you don’t know the exact numbers or if you’re
allowed to usage average exchange rates for tax accounting. The real
amount exchanged doesn’t matter there/will be sorted out with correcting
expense/income transaction.

It might be your so called valuation exercise, but it annoys me very
much that Finance::Quote doesn’t fetch the daily average quotes from the
ECB yet.

Often times with cash transactions it happens that people use simple
exchange rates which are nowhere near the actual rates. So I might be
paying 5 EUR for a service worth 20 PLN according to the receipt, so you
might assume that the exchange rate is 1 to 4, but the actual rates are
in a range of 1 to 4.2/4.3.

So unless we’re talking about bank transfers or exchanging real currency
there are situations where you’d want rates instead of the actual
amounts exchanged.

I also wanted to add that the bug with not being able to see the
currency exchange rates in the price list also effects me running 3.4
with the sqlite backend.

I can however add the rates to the list and they’re used in transactions
and listed on balance sheets if requested.

Kind regards

Christian Kluge
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: [GNC-dev] book currency is what ... question mark

David Cousens
In reply to this post by GnuCash - Dev mailing list
Wm,

I must admit I don't use trading accounts much at present. I'll check out
how they handle it.

I take your point on the difference between amounts entered in a transaction
as distinct from the value at a specific point in time in a balance sheet or
even TB. you would want recording aof  a transaction to record the amounts
debited and credited to accounts as the values involved in the transaction
and not be subject to any sort of updating of their value with a change in
the price database. The amount recorded as the price in the transaction
price field should be calculated from the entered amounts and not from a
value in the price database, at least unless the person entering the
transaction specifically requests that a current on-line price or price from
the database be used explicitly. If it was used an extra confirmation from
the user that they are aware of the implications might be in order.

I don't think this is what Alex was proposing. My reading of a use case he
might be trying to address  is that in a case of a multisplit transaction
where more than two foreign currency accounts were involved, the balance
condition for the transaction would be checked in the book currency.  I will
have to check the data structures but I think from a brief look some time
ago there is only one price associated with a transaction, whereas if what
Alex is proposing is what I think he is, it would require a price from the
currency of the account the split is to to the register account currency to
be associated with each split to enable that transaction balancing to occur.

Ideally I would think a transaction should not be specifically associated
with any specific account other than through the splits to the accounts. I
think that is the case in GnuCash but I haven't explicitly checked the code
but a single price for a transaction if that is the case may break that.
Geert, John or Derek may be better able to comment on this

If you are recording a change in asset value in the register there should be
a specific transaction to do that. No problem perhaps for a report, but even
then  I would always prefer to know explicitly the basis for any difference
between what is in the register and what appears in a report, i.e. it should
be part of the report.

I think we all have a tendency to think the whole world runs the way things
are run in our local environment until we experience a situation that
disabuses us of this false notion, usually travel. I can't say that my
experience of the GnuCash development team indicates that that this
particularly a problem. When something new is developed it is likely to at
least initially reflect what the developer is most  familiar with and it
requires wider input to then generalize it to other requirements. GnuCash is
not a commercial effort where there is a definite financial incentive to
provide adaption to different jurisdictions so it gets down to individual
motivation and enough users with some development skill taking on the tasks
to do that adaption. That unfortunately is not that easy. I found it very
difficult to get to the point where I could even begin to develop any code.
My wife (who was the daughter of a USMC second lieutenant) but was brought
up in Australia is much tougher than I am on US cultural imperialism.

Unfortunately we are faced with governments being unnecessarily prescriptive
about how things should be done in cases where they have minimal expertise.
Making Tax Digital is a case in point in the UK. I am hoping the ATO here
does not catch a case of the HMRC bloody mindedness as we still have a fall
back to a web portal into which we can cut and paste the required
information.

David Cousens



David Cousens



-----
David Cousens
--
Sent from: http://gnucash.1415818.n4.nabble.com/GnuCash-Dev-f1435356.html
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
David Cousens
Reply | Threaded
Open this post in threaded view
|

Re: [GNC-dev] book currency is what ... question mark

Herbert Thoma-2
In reply to this post by Christian Kluge
Just my humble opinion, see below inline.

Am 17.02.2019 um 20:50 schrieb Christian Kluge:
> Am 17.02.2019 um 19:58 schrieb Wm via gnucash-devel:
> Often times with cash transactions it happens that people use simple
> exchange rates which are nowhere near the actual rates. So I might be
> paying 5 EUR for a service worth 20 PLN according to the receipt, so you
> might assume that the exchange rate is 1 to 4, but the actual rates are
> in a range of 1 to 4.2/4.3.

If you paid 5 EUR for that service, then this is the only fact that
matters for accounting. Some account (bank or cash) is decreased by
5 EUR and some expense account is increased by 5 EUR. Nobody (at least
not the german tax authorities, if you want to report this expense for
tax purposes) cares that the service might be worth 20 PLN. You paid
5 EUR for it and that you need to record.

> So unless we’re talking about bank transfers or exchanging real currency
> there are situations where you’d want rates instead of the actual
> amounts exchanged.

The only thing that matters for accounting are the actual amounts
exchanged.

> I also wanted to add that the bug with not being able to see the
> currency exchange rates in the price list also effects me running 3.4
> with the sqlite backend.
>
> I can however add the rates to the list and they’re used in transactions
> and listed on balance sheets if requested.
>
> Kind regards
>
> Christian Kluge
> _______________________________________________
> gnucash-devel mailing list
> [hidden email]
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: [GNC-dev] ECB Daily Average Quotes

John Ralls-2
In reply to this post by Christian Kluge


> On Feb 17, 2019, at 11:50 AM, Christian Kluge <[hidden email]> wrote:
>
> It might be your so called valuation exercise, but it annoys me very
> much that Finance::Quote doesn’t fetch the daily average quotes from the
> ECB yet.

Are they published on a website somewhere in a way that a computer can digest them? Screen-scraping is OK, several of the F::Q modules do that, it's just fragile.

Regards,
John Ralls
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: [GNC-dev] ECB Daily Average Quotes

Frank H. Ellenberger-3
Am 18.02.19 um 16:01 schrieb John Ralls:
>
>
>> On Feb 17, 2019, at 11:50 AM, Christian Kluge <[hidden email]> wrote:
>>
>> It might be your so called valuation exercise, but it annoys me very
>> much that Finance::Quote doesn’t fetch the daily average quotes from the
>> ECB yet.
>
> Are they published on a website somewhere in a way that a computer can digest them? Screen-scraping is OK, several of the F::Q modules do that, it's just fragile.

Yes
https://www.ecb.europa.eu/stats/policy_and_exchange_rates/euro_reference_exchange_rates/html/index.en.html
offers also several download formats

> Regards,
> John Ralls

Frankk

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: [GNC-dev] book currency is what ... question mark

Christian Kluge
In reply to this post by Herbert Thoma-2
Hello,

Am 18.02.2019 um 09:29 schrieb Thoma, Herbert:

> Just my humble opinion, see below inline.
>
> Am 17.02.2019 um 20:50 schrieb Christian Kluge:
>> Am 17.02.2019 um 19:58 schrieb Wm via gnucash-devel:
>> Often times with cash transactions it happens that people use simple
>> exchange rates which are nowhere near the actual rates. So I might be
>> paying 5 EUR for a service worth 20 PLN according to the receipt, so you
>> might assume that the exchange rate is 1 to 4, but the actual rates are
>> in a range of 1 to 4.2/4.3.
>
> If you paid 5 EUR for that service, then this is the only fact that
> matters for accounting. Some account (bank or cash) is decreased by
> 5 EUR and some expense account is increased by 5 EUR. Nobody (at least
> not the german tax authorities, if you want to report this expense for
> tax purposes) cares that the service might be worth 20 PLN. You paid
> 5 EUR for it and that you need to record.
>

There is one exception to this being VAT calculation.

Sect 16 Par 6 of the German VAT act stats that foreign currency amounts
should be converted with the monthly ECB averages or the actual daily rates.

https://www.gesetze-im-internet.de/ustg_1980/__16.html

Of course you’d record the full 5 EUR but a rate of 1 to 4.2 only 4.76
EUR would be subject to VAT.

Kind regards

Christian Kluge
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: [GNC-dev] ECB Daily Average Quotes

John Ralls-2
In reply to this post by Frank H. Ellenberger-3


> On Feb 18, 2019, at 7:34 AM, Frank H. Ellenberger <[hidden email]> wrote:
>
> Am 18.02.19 um 16:01 schrieb John Ralls:
>>
>>
>>> On Feb 17, 2019, at 11:50 AM, Christian Kluge <[hidden email]> wrote:
>>>
>>> It might be your so called valuation exercise, but it annoys me very
>>> much that Finance::Quote doesn’t fetch the daily average quotes from the
>>> ECB yet.
>>
>> Are they published on a website somewhere in a way that a computer can digest them? Screen-scraping is OK, several of the F::Q modules do that, it's just fragile.
>
> Yes
> https://www.ecb.europa.eu/stats/policy_and_exchange_rates/euro_reference_exchange_rates/html/index.en.html
> offers also several download formats

Including an XML one, so it would be possible to write an F::Q module that retrieves the current day's XML file and extracts a currency rate.

There's also a CSV download, but it would take some massaging to make it usable to be imported with the price csv importer.

Regards,
John Ralls


_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: [GNC-dev] book currency is what ... question mark

GnuCash - Dev mailing list
In reply to this post by David Cousens
On 15/02/2019 01:44, David Cousens wrote:

I haven't read all the recent list replies yet but I think this sort of
thing

> If the book currency is USD (or AUD or any other third currency) then the
> currency conversion becomes EUR<->USD<->RUB. The double conversions involved
> to the EUR and RUB may introduce scope for rounding errors to produce
> slightly different results on conversion back.
>
> It also assumes that EUR->USD-> RUB will give the same result as EUR->RUB.
> Where the exchange rates are good to 6 significant figures, this appears to
> be OK using today's figures
> (https://www.xe.com/currencyconverter):
> 1 EUR=75.3052 roubles
> 1 EUR =1.12958 USD
> 1 USD = 66.6667 RUB => 1 EUR = 75.3054 RUB.

is certainly part of the reason why the TB is going wrong.

Congratulations on your prescience :)

add yourself to
https://bugs.gnucash.org/show_bug.cgi?id=797097
if you're really interested.

--
Wm

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: [GNC-dev] book currency is what ... question mark

GnuCash - Dev mailing list
In reply to this post by Christian Kluge
On 17/02/2019 19:50, Christian Kluge wrote:

> Am 17.02.2019 um 19:58 schrieb Wm via gnucash-devel:
>> On 15/02/2019 01:44, David Cousens wrote:
>
>>> If I start in Savings RUB , select the Savings EUR account and enter
>>> 100 it
>>> is assumed to be in RUB not EUR as GnuCash operates at present. This is
>>> clear, both registers are balanced and it is clear that they are correct.
>>>
>>> I am presuming what you would like is to be able to start in the
>>> Savings RUB
>>> register, select the Savings EUR account, enter 100.00 as the amount and
>>> have that interpreted as !00.00EUR, even though the register currency
>>> is RUB
>>> and then when you tab to the next line select Savings RUB have the
>>> currency
>>> dialog popup, enter or fetch the exchange rate, and then display the
>>> amount
>>> against the Savings RUB account in RUB.
>>
>> Nope.  I normally know the exact amounts at either end of significant
>> tx, the exchange rate is implied from the numbers.  That *is* the right
>> way of doing the accounting.
>
>> You start with 100 of some currency and end up with 2300 of some other
>> currency, the *valuation* is separate.
>
> What about the situations you don’t know the exact numbers or if you’re
> allowed to usage average exchange rates for tax accounting. The real
> amount exchanged doesn’t matter there/will be sorted out with correcting
> expense/income transaction.

It is your (and my and everyone else's) personal responsibility to
account correctly. You give an example below.

> It might be your so called valuation exercise, but it annoys me very
> much that Finance::Quote doesn’t fetch the daily average quotes from the
> ECB yet.

Any F::Q valuations should not affect your day to day life, I am well
known for saying gnc is not suitable for trading.  Governments generally
don't care about one up or one down in decimal points for most people.

> Often times with cash transactions it happens that people use simple
> exchange rates which are nowhere near the actual rates. So I might be
> paying 5 EUR for a service worth 20 PLN according to the receipt, so you
> might assume that the exchange rate is 1 to 4, but the actual rates are
> in a range of 1 to 4.2/4.3.

My advice is to record the actual values, forget the theoretical
exchange rate as you are unlikely to get it.

> So unless we’re talking about bank transfers or exchanging real currency
> there are situations where you’d want rates instead of the actual
> amounts exchanged.

It seem stupid to me to account for what you wished rather than what
happened.

Did you eat 5EUR worth of some food or 20PLN of some food?  The food has
gone inside you and out by now :)

Accounting is not a youtube thing, you don't value something afterwards
unless it has residual value.  Your poo is just that, your poo, no value
in most currencies :)

> I also wanted to add that the bug with not being able to see the
> currency exchange rates in the price list also effects me running 3.4
> with the sqlite backend.

Most of that is fixed in the test version I am using.  There is a small
bug left over if you need to change a price after it has been fetched.
https://bugs.gnucash.org/show_bug.cgi?id=797046
for reference

> I can however add the rates to the list and they’re used in transactions
> and listed on balance sheets if requested.

That is normal service :)

--
Wm

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: [GNC-dev] book currency is what ... question mark

GnuCash - Dev mailing list
In reply to this post by Christian Kluge
On 18/02/2019 19:15, Christian Kluge wrote:

> There is one exception to this being VAT calculation.
>
> Sect 16 Par 6 of the German VAT act stats that foreign currency amounts
> should be converted with the monthly ECB averages or the actual daily rates.
>
> https://www.gesetze-im-internet.de/ustg_1980/__16.html
>
> Of course you’d record the full 5 EUR but a rate of 1 to 4.2 only 4.76
> EUR would be subject to VAT.

Herr Kluge, this is a user issue not a dev issue.  Have a look at
https://wiki.gnucash.org/wiki/Mailing_Lists
and work out which list you should be posting to.  Your english skills
are good so I'd suggest
https://lists.gnucash.org/mailman/listinfo/gnucash-user
and
https://lists.gnucash.org/mailman/listinfo/gnucash-de
for de specific stuff.

I notice in passing that we have language specific groups rather than
political orientation groups, I think we might need .EU .USA .GB soon :(

--
Wm

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: [GNC-dev] ECB Daily Average Quotes

GnuCash - Dev mailing list
In reply to this post by John Ralls-2
On 18/02/2019 15:01, John Ralls wrote:
>
>
>> On Feb 17, 2019, at 11:50 AM, Christian Kluge <[hidden email]> wrote:
>>
>> It might be your so called valuation exercise, but it annoys me very
>> much that Finance::Quote doesn’t fetch the daily average quotes from the
>> ECB yet.
>
> Are they published on a website somewhere in a way that a computer can digest them? Screen-scraping is OK, several of the F::Q modules do that, it's just fragile.

For most people ECB rates are just something you use to say what you
got, etc.  It isn't realistically tradeable for most people outside of
the futures, spread betting and similar markets.

Let me put it this way, no matter how much you try to affect the ECB by
buying or selling it, the ECB is probably just going to be the same anyway.

HTH

--
Wm

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: [GNC-dev] ECB Daily Average Quotes

GnuCash - Dev mailing list
In reply to this post by John Ralls-2
On 18/02/2019 21:15, John Ralls wrote:
>
>
>> On Feb 18, 2019, at 7:34 AM, Frank H. Ellenberger <[hidden email]> wrote:

>> Yes
>> https://www.ecb.europa.eu/stats/policy_and_exchange_rates/euro_reference_exchange_rates/html/index.en.html
>> offers also several download formats
>
> Including an XML one, so it would be possible to write an F::Q module that retrieves the current day's XML file and extracts a currency rate.
>
> There's also a CSV download, but it would take some massaging to make it usable to be imported with the price csv importer.

Sure, but you'd be left wondering "what am I going to do with these new
numbers".

--
Wm

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: [GNC-dev] book currency is what ... question mark

Christian Kluge
In reply to this post by GnuCash - Dev mailing list
Am 20.02.2019 um 14:09 schrieb Wm via gnucash-devel:
> On 17/02/2019 19:50, Christian Kluge wrote:

>> It might be your so called valuation exercise, but it annoys me very
>> much that Finance::Quote doesn’t fetch the daily average quotes from the
>> ECB yet.
>
> Any F::Q valuations should not affect your day to day life, I am well
> known for saying gnc is not suitable for trading.  Governments generally
> don't care about one up or one down in decimal points for most people.

Have I said anything about trading? Don’t try to interpret things. I
know that the ECB rates are suitable for this case however they are a
reference recording value.

>> Often times with cash transactions it happens that people use simple
>> exchange rates which are nowhere near the actual rates. So I might be
>> paying 5 EUR for a service worth 20 PLN according to the receipt, so you
>> might assume that the exchange rate is 1 to 4, but the actual rates are
>> in a range of 1 to 4.2/4.3.
>
> My advice is to record the actual values, forget the theoretical
> exchange rate as you are unlikely to get it.
>
>> So unless we’re talking about bank transfers or exchanging real currency
>> there are situations where you’d want rates instead of the actual
>> amounts exchanged.
>
> It seem stupid to me to account for what you wished rather than what
> happened.
>
> Did you eat 5EUR worth of some food or 20PLN of some food?  The food has
> gone inside you and out by now :)
>
> Accounting is not a youtube thing, you don't value something afterwards
> unless it has residual value.  Your poo is just that, your poo, no value
> in most currencies :)
>

Let me expand my example:

Let’s say I’m doing someone else’s accounts and going through the
liabilities first and see an invoice for 20 PLN.
Then I don’t go through the bank statements first and try to find this
transaction for the real value transferred but use the (monthly average)
ECB quote.

I don’t know how it’s done in the UK but in the end a balance sheet has
to be in Euro in Germany, so it has to be converted anyway.

Kind regards

Christian Kluge


_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: [GNC-dev] book currency is what ... question mark

GnuCash - Dev mailing list
In reply to this post by David Cousens
On 18/02/2019 06:43, David Cousens wrote:

> I must admit I don't use trading accounts much at present. I'll check out
> how they handle it.

I like trading accounts, they make sense to me.  If you don't do a lot
of stuff outside of your home currency you probably needn't bother
unless you are interested in the actual value of things.

have a look at
https://www.mathstat.dal.ca/~selinger/accounting/tutorial.html
gnc is but one implementation though we do get a mention! :)

[snip agreed]

> I don't think this is what Alex was proposing. My reading of a use case he
> might be trying to address  is that in a case of a multisplit transaction
> where more than two foreign currency accounts were involved, the balance
> condition for the transaction would be checked in the book currency.

If that is what is proposed it is bad thinking.  I do understand that
for people that rarely encounter anything outside their own bubble this
would be a convenience, but if, at the end of the tx there is something
left over (some shares, some currency, anything) then this is just
painting over the cracks.

> I will
> have to check the data structures but I think from a brief look some time
> ago there is only one price associated with a transaction, whereas if what
> Alex is proposing is what I think he is, it would require a price from the
> currency of the account the split is to to the register account currency to
> be associated with each split to enable that transaction balancing to occur.

I think we agree on the proposal, I think it is a bad idea.  I
specifically do not want all my tx rewritten into a single currency.

I really do have 1.00 ZAR and 2.00 USD and 3.00 GBP and 4.00 EUR.  I
only have some equivalent value in AUD when I report on it, my accounts
should recognize what I have and what I owe in real (i.e. world) terms,
e.g. I owe my girlfriend 100 EUR for dinner not however many GBP it was
at the moment I asked her to pay because they wouldn't accept my card.

> Ideally I would think a transaction should not be specifically associated
> with any specific account other than through the splits to the accounts.

It isn't, a transaction is the sum of the splits, the splits have
accounts, not the tx.  The tx is the human convenient glue that keeps
the splits (the actual transactions) together.

> I
> think that is the case in GnuCash but I haven't explicitly checked the code
> but a single price for a transaction if that is the case may break that.
> Geert, John or Derek may be better able to comment on this

I think I must be misunderstanding again.  In many cases there *can't*
be a single price for the tx.

> If you are recording a change in asset value in the register there should be
> a specific transaction to do that.

accounting practice allows for (usually non-traded or infrequently
traded) assets and liabilities to be valued and revalued by explicit tx,
that is never going to go away; in most jurisdictions there is a whole
bunch of tax related stuff saying when you should or shouldn't do this
but gnc isn't going to stop you :)

> No problem perhaps for a report, but even
> then  I would always prefer to know explicitly the basis for any difference
> between what is in the register and what appears in a report, i.e. it should
> be part of the report.

The general rule is that an actual price (i.e. that implied from the tx)
overrides a price from the prices db.  I think gnc does this correctly.

It is the reports that are getting muddled and not being examined
sufficiently because a diminishing number of people understand them.
They're in Scheme, a language that was old before my time and I am in my
50's.  <-- That's a fact not a crit of our seniors.  I know they want to
move on and allow people like me to write reports for others.

> I think we all have a tendency to think the whole world runs the way things
> are run in our local environment until we experience a situation that
> disabuses us of this false notion, usually travel.

A good observation.

> I can't say that my
> experience of the GnuCash development team indicates that that this
> particularly a problem.

I am not saying bad things about our seniors.  There are  number of them
that are aware of more than one currency and certainly not isolationist
people.  I think (someone may correct me) that most of the gnc trading
account stuff was implemented by a USA-ian [1]

[1] I might have made an enormous mistake by mixing Canadian and
American <-- joke!  USA is not America, duh!

> When something new is developed it is likely to at
> least initially reflect what the developer is most  familiar with and it
> requires wider input to then generalize it to other requirements. GnuCash is
> not a commercial effort where there is a definite financial incentive to
> provide adaption to different jurisdictions so it gets down to individual
> motivation and enough users with some development skill taking on the tasks
> to do that adaption.

I disagree with that slightly, there are definite jurisdictional
adaptations.  The good ones are generalized,

consider: there are only so many ways to add a tax to an invoice so
let's generalize it, this is progress, gnc does this well

and there are bad ones: Reports / Tax Schedule Report & TXF Export
this means nothing to me, should it be removed?  no; should it be put
somewhere less prominent? yes.  why should one country's tax filing be
OK and another country's not be allowed?

Some people have put some effort into tax filing in European (or soon to
be ex-European) countries, the general report would probably cover 90%
of the rest of the world.  The gnc seniors don't see this. Grrrr!

> That unfortunately is not that easy. I found it very
> difficult to get to the point where I could even begin to develop any code.
> My wife (who was the daughter of a USMC second lieutenant) but was brought
> up in Australia is much tougher than I am on US cultural imperialism.

Does she think of herself as an ex-pat or not? :)

> Unfortunately we are faced with governments being unnecessarily prescriptive
> about how things should be done in cases where they have minimal expertise.
> Making Tax Digital is a case in point in the UK.

Yup, other countries too, but making the report can be made easier.

> I am hoping the ATO here
> does not catch a case of the HMRC bloody mindedness as we still have a fall
> back to a web portal into which we can cut and paste the required
> information.

It gets worse in some places where you theoretically have to have been
using approved software to be able to file a report :(

--
Wm

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
12