[GNC-dev] tb, gnc or me? my trial balance is wrong and I think it is gnc not me

David Carlson david.carlson.417 at gmail.com
Sun Feb 10 23:03:17 EST 2019

Wm,  before you run off at the mouth with all your innuendos, look at facts.

Did you try running a test on one of your backups from around June 2016
using Gnucash 2.6.12 or earlier?  I think that if you do you will find that
the Trial Balance Report is correct if you scrupulously check the settings
to use the Average Price valuation method and check your price database to
be sure that the transaction generated prices are present.   John Ralls
alluded to that earlier today.

In fact, I bet you could try re-running the Trial Balance Report in release
3.4 on a current data file using the Average Balance method of valuation.
There was a period when GnuCash was not entering transaction generated
prices into the price database as Alex noted, but that was corrected some
time ago and recent prices from recent transactions are all entered in the
price database.  Granted, it will be difficult to find many of  those old
missing transaction generated prices that involve the base currency but
maybe they might get added back by using the trading accounts feature.  I
have not tried that, but it might be worth a try.   As Alex suggested,
transactions that do not involve the base currency would need to be dealt
with some other way.

David Carlson

On Sun, Feb 10, 2019 at 7:03 PM Wm via gnucash-devel <
gnucash-devel at gnucash.org> wrote:

> On 10/02/2019 19:46, Alex Aycinena wrote:
> > It is possible that Wm is noting a problem in gnucash that I'm trying to
> > address with my 'Book Currency' enhancement (unfortunately, a bit
> delayed).
> I am certainly interested.  I went to the end of your message and read
> that just in case you thought Brexit was a good idea:)
> I'm also not convinced that tricks are good and certainly wasn't
> expecting what I think you are proposing, Alex.
> > For most users who deal in a home currency most of the time and
> > occasionally buy a foreign currency, say on a trip, and spend it on
> > expenses, this deficiency won't show itself.
> I think gnc is not a one currency one country application any more and
> as a result I think the reporting needs to catch up.  Small expenses or
> income in another currency are normal as people trade on ebay and
> similar.  It seems to me the only people that don't realise this are the
> very particular small minded whites that voted for Trump and maybe some
> weird religious people in other parts of the USA.  Almost everyone I
> know has had an international transaction of some sort in the last year.
> > But for people who deal in
> > multiple currencies often, with complicated transactions, it may.
> I will see what you say below, I think the accounting basics are largely
> correct.  I wouldn't be here if I found them wrong.
> > Consider the following scenario:
> >
> > 1. A user is based in Europe and considers their home currency to be
> Euros
> following
> > 2. The user uses Euros to buy multiple lots of GBPs at different times.
> The
> > transactions each have different implicit exchange rates in the
> individual
> > splits, but gnucash doesn't do any automatic lot tracking.
> Are you sure gnc doesn't do lots, Alex?  My needs are modest, heh, maybe
> I'll look at lots when I've finished with this trial balance crap.  I'm
> sure gnc tracks my fx tx, Alex.
> If anyone is trading intra day they're on their own, I don't do that and
> I am certain if someone is taking that risk they should be able to bear
> the costs them self from available funds and never say to their partner
> or parents or anyone else, "I fucked up".
> Having said that, I'm benefiting on EUR:GBP because I'm in London and we
> are screwing Brexit up badly.
> > Some of the GBPs
> > are used for expenses expressed in EURs. The splits associated with these
> > expenses also have implicit exchange rates, but they don't have any
> > relationship to the purchased GBP's costs unless the user makes carefull
> > off-line calculations and enters the right amounts.
> that is what my northern relatives would call a red herring
> actually, I haven't phoned my aunt in Norway, but you're presenting a foil
> the used currency is between you and your tax people (presuming I
> understand your question).  nothing to do with gnc.
> > 3. The user then uses left-over GBPs to buy USDs. The split entered into
> > gnucash has an implicit exchange rate of USDs to GBPs but nothing
> expressed
> > in Euros.
> this is sounding like a 1970's communist theoretical play to me, have
> you been reading either Chekhov or McCarthy? :)
> Ummm, basically the current gnc TB has no clue about any movements, it
> makes a guess at best.  It is functionally broken because it starts as a
> balance sheet rather than a trial balance and cannot be fixed until our
> seniors kill it, replace it or otherwise retire Scheme as the main
> reporting sub optimal system.
> We all know it is wrong, no one can fix it!
> Yay :(
> > If you want to run a report representing these transactions in Euros
> there
> > is no way to do so unless you use an externally supplied exchange rate
> > (e.g., from the price db) because the splits themselves don't have all
> the
> > required information.
> Nope.  The right way to do it is to use the tx values and ignore prices
> altogether.
> What you end up with is amounts of stuff in your accounts without the
> report forcing the idiocy of a price change.
> If you want to see the value at a point in time?  That is called a
> Balance Sheet.
> A trial balance is a different thing.
> > If you want to run a report 'at cost', you also can't do this because
> item
> > 3, above, doesn't contain the right information (so you have to 'fudge
> it'
> > with an amount from the price db).
> Ah, I think I see your point now
> > This can be overcome procedurally in
> > gnucash by using the trick of entering the #3 transaction in a register
> of
> > an account denominated in Euros even if that account isn't involved in
> the
> > transaction. One split will sell the GBPs in EURs, the other will buy
> USDs
> > in EURs and as soon as you hit the enter key, the transaction will
> > 'disappear' from the register it was entered in (since neither of the
> > splits were for that account). The transaction, however, will show up in
> > the registers for the accounts involved and they will contain the
> implicit
> > exchange rates that were missing above (but not necessarily with any lot
> > tracking and still requiring a lot of off-line calculations to figure out
> > the right numbers to enter into the splits).
> Alex!  You are a very naughty person!  I think if we ever meet in person
> I will hug you if only because you are doing sums about and even within
> gnc and I sometimes do that too.
> > Now a report 'at cost' could
> > be run, but only if the trick was used procedurally for every transaction
> > not involving the home currency. Of course, this can't be assumed to be
> the
> > case.
> I think if we took that to a logical end it would be too expensive for
> most people, to the extent they'd stop using gnc.
> > The 'book currency' feature is intended to deal with this by, if the
> 'book
> > currency' feature is selected, forcing every non-book-currency split to
> be
> > denominated in book-currency (i.e., like the trick, above, but without
> > having to use a third account register) and enforcing lot tracking for
> each
> > of these transactions (to get rid of all the off-line calculations), thus
> > providing a basis for tracking cost and eliminating the need for an
> > external price reference (unless you want to see an estimate of current
> > value).
> >
> > I don't know if this is related to the problem Wm is seeing, but it might
> > be.
> Alex, you're addressing different stuff.  I am interested but, to be
> honest, I think the chances of gnc implementing your ideas soon are
> remote.  I'm struggling to get the gnc team to get a basic accounting
> report done.  I'm struggling to get gnc to get one of their actual
> reports fixed or removed.
> Oddly enough very few people seem to mention accounting these days.
> Wonder why that is?
> --
> Wm
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel

More information about the gnucash-devel mailing list