reporting currencies & integrity

[linas@linas.org]

OK,

This conversation has gotten to theoretical.  I was trying to solve
an immediate programming problem.   The SQL database stores
currencies the way we agreed they were soppused to work half a year
ago.  As a practical matter, this doesn't mesh well with what the
engine currently does.  So I was trying to fix that.

It's been rumoured that Bill Gribble said:
> 
> The reporting currency can change at any time, it's just a global
> preference setting determining what currency to convert to to total
> your assets liabilities etc.

Not in the main-window.c, not currently.  Right now, you get errors
is the account doesn't return a valid reporting currency.
I was thinking of fixing this, so that I could demo the sql code ...

> The transaction valuation currency is what used to be called the
> "common currency".  

Right, I hacked the engine to maintain this. The sql db stores this.
The sql db does not currently store the "account reporting currency",
whence all of my problems arise.

> The reporting currency is independent from this, and I think it's
> confusing the issue to be talking about them in the same thread if
> discussion.

except that they are intimately tied together in the current
implementation of the engine ...

> > Yes, but its not just 'some price', its an explicitly auditable
> > price.  I think that's a critically important part of it.
> 
> I don't know what this means.  Why is it important to audit the price
> in the price DB?  You should definitely be able to audit the amount
> that every split is valued at in the transaction's balancing currency,
> but the price is more of a side effect of that than a cause, AFAICT.
> If the number of dollars that you paid for some IBM shares is
> reasonable, and the number of shares is reasonable, and the
> transaction balances, the price/share is almost by definition
> reasonable.  If it was way off, either your share balance of IBM or
> your bank balance would be correspondingly off.

OK, it was an idea.  Part of the idea of double entry is not just
"the accounting equaition balances", but also that "the data is
duplicated in several places, and can thus be double-checked."

For example, the value of one split can always be computed
implicitly, since we know that the sum-total must be zero.  But we
don't do this.  We store all of the splits, and then occasionally
check that the sum total really is zero (and do something about
it when its not).   Similarly, I was suggesting that some
price-duplication is not a bad thing, as opposed to always depending
on implicitly computed prices.  I was proposing that some prices 
should be considered to be "accounting events",  with thier own
explicit audit trails that can be checked against actual purchases.

> To me it's burdensome just because it's not a permanent piece of
> information.  The reporting currency is something that might change
> several times in one session of using gnucash.  From my perspective
> the only right thing to do is go out on the net and get the relevant
> currency quotes from a server somewhere.
> 
> If you're off the net, the dialog makes sense, more as a way of
> informing the user that you're operating in a degraded mode; I would
> go so far as to say that if you're operating on historical prices for
> some asset (meaning you need a lot of date-specific price quotes) you
> might have an explicit threshold beyond which you show some "I can't
> compute this correctly" message.

OK, that works.  And as I was hinting to Rob some weeks ago, it would
be nice to tag some prices as "I really verified that these prices
are right", i.e. to say "this price is more important and is provably
more accurate than what yahoo is spewing today".   So that we don't 
get totally hosed when yahoo starts returning garbage.

> exclamation-point-to-content ratio of your last message shot through

Sorry.  I wrote most of the code we're discussing, I was miffed that 
you are implying that I don't know what it does.

--------------------------------------------------------------
Let me then shift the conversation to another related topic:
account balances.  

With the sql back-end, when you first power up, the engine is loaded
*ONLY* with the account info, and currencies, but no transactions
or splits.  This beacuse the sql db might have millions of splits, 
and you don't want to load all of them.   Instead, when a register is
opened, the query object fetches the relevent transactions out of
the sql db.   (and btw, this part now actually works in the sql db).

However, the sql db does not currently return the "current balance"
for an account.   This info will be needed for the main window. 
I'm using the checkpoint idea to maintain balances, but haven't yet
figured out how to poke this into the engine.  

When main-window.c runs, it calls xaccAccountGetCurrentBalance()
which (when doing sql) currently returns an incorrect value.  

I hope to fix the engine soon so that the the sql db will corectly
return the "commodity balances".   However, these need to be
converted into "reporting balances" by something, somehow.  
There are several options. Maybe more.

Option Y: rename xaccAccountGetCurrentBalance() to
xaccAccountGetCurrentReportingBalance() and try to hack it to make
it magically do the right thing.   Unfortunately, this hack is hard,
because without the price DB, and all the FASB baggage, its hard
to know how to compute this thing.

Option X: rip this out of the engine, put it somewhere else, 
make an ugly hack so that it just works for now, and deal with it
later, when the price DB and the FASB stuff comes on line.  


I'm now leaning towards option X. 


--linas