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

[Wm]

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'm not antagonistic to your idea, Alex, just not sure I understand it.

> 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.

Agree, we've a person in devel yelling about just that.

> But for people who deal in
> multiple currencies often, with complicated transactions, it may.
> 
> 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. 

I think I have to intervene and say Trading Accounts is your fairy 
godmother.

If you aren't using them you are a silly boy, Alex.

> 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.

I think that is a broken example.  Small transactions are allowed to be 
discarded and joined into "we went out, bought a meal, had some some 
drinks with lovely people in a pub", I'm not a social media person 
(think it is all silly really) but don't have a problem with reality.

I think Alex is wanting to track lots when he shouldn't.

Alex: significant lots? sure; small amounts of spending? nope.  trading 
accounts do this for free anyway.

> 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.

You and I my be agreeing on a problem that I have noticed in the TB 
regarding presumed valuations.

> 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.

Yes!  I think you are a man so we will hug rather than kiss :)

All: I think I may have insulted Alex by not reading everything he said 
before.  It gets confusing sometimes.

Alex: you are allowed to say I am an idiot or fool.

> 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).

This is wrong, the cost is yours or mine, an actual cost not a price.db 
cost for a remote commodity.  I agree with Alex.

> 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. 

Why would you do that?  I am asking because I can't see the point.

> 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).

I wrote some stuff below and now I am asking, how do you get gnc to 
disappear splits?  I am in favour of gnc keeping them.

> 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 said something important there.  I'm sure I'm not fighting 
with you.

Thinking: there is something significant in Alex's para above, I think I 
need to read it again.  I may not reach the same conclusion but it would 
be stupid if I didn't understand.

> 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'm not convinced, if the report shows holdings in each commodity and 
currency and it works every time <-- it has to, there are some times 
pretending to be clever doesn't work, I think we are getting to that 
point with Alex's proposal.

> 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 

No!  No!  No!  Don't be aggressive towards good accounting!

> (i.e., like the trick, above, but without
> having to use a third account register) 

you don't need to

> and enforcing lot tracking for each
> of these transactions (to get rid of all the off-line calculations),

also superfluous (there are reasons to use lot tracking) but lot 
tracking *and* trading accounts leaves me thinking, hang on, maybe one 
person doesn't understand the other person?

> 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).

Why wouldn't someone want to know the current value of stuff?

Are you so involved with the tiny penis Trump thinking that your USD is 
worth a different amount to the USD I have?

> I don't know if this is related to the problem Wm is seeing, but it might
> be.

It looks like something no adult should implement unless explained better.

-- 
Wm