reporting currencies & integrity

linas@linas.org linas@linas.org
Wed, 24 Jan 2001 16:50:41 -0600 (CST)


It's been rumoured that Dave Peticolas said:
> Is this what you are proposing:
> 
> Account Security stays the same, with the same meaning.

Yes. except maybe we should call it "account commodity".

> Account Currency becomes Account Reported Currency and is
> the currency used in the main window.

Changed my mind. Account currency should just be completely removed 
from the engine.    If this proves exceptionally hard, then
during the trransition period, it should be renamed as above.

> Transaction Currency is added and replaces the old
> account currency/security for determining the common
> currency of the transaction.

yes.

> split damount == amount in account security, same as before
> split value == amount in transaction currency

Yes.

> I'm not clear about the prices you propose to store:

The price of transaction currency in reported currency

So that when the transactions are walked, split values can be easily
and immediately converted to the reporting currency.

Basically, there is a pressing need for a 'fasb-0.0.1pre'  module,
because if the accounts no longer store the reporting currency ...
See below...

> I think we should care, because transactions can be entered in
> several different ways:

OK.

> A transaction is balanced and 'integrity checked' if the
> 'value' members of the splits sum to 0 

yes, exactly, and I think we're in harmonious agreement on that

> and, for each split,
> the value member equals the damount member multiplied by
> the price stored in the database for that split.

Yes, exactly.   It seems to me that this is an important additional
integrity check the we haven't talked about in the past.  But I'm 
happy to file this in the 'cool idea, some other day' file.

> So you are proposing Plan Y *in addition* to the ability to specify
> a single currency for a given report?

I'm now leaning towards plan X.
--------------------------------------------------------

Here's the real-life problem:
Today, the "reporting balance" is computed by engine code, it is 
stored with the split, and is returned to the register with the
xaccSplitGetBalance() routine.

If we are to remove reporting currencies from the engine, and put
them into the hypothetical FASB module, then we need to define the 
API for the fasb module, implement at least a version 0.0.1 version
that does what the engine does today.  Then we need to change the 
register, and the main window, to use it, instead of relying on the
engine. 

Does anyone have any proposed API's for the fasb module?   I suspect
that if I volunteer to write it in C, I'll be told that scheme would
be better ... to which, my defense is that it balances get recomputed
every time the register gets bumped, and this is frequent, and thus
needs to be fast.

--------------------------------------------------------
So, to reprise:

Plan X: 
Rip out any notion of "reporting currency" out of the engine.  
As discussed above, this is a lot of work.  Hard work, at that.

Plan Y:
Leave the reporting currency inside the engine, as it is today.
Maybe  even enhance it so that multiple reporting currencies
are supported, and can be switched bewteen quickly and easily.

There is a certain amount of intellectual clarity to Plan X that
Plan Y seems to lack.  At least, that's how I intepret Bill's 
pummelling.   However, Plan Y is easier to muddle one's way 
through, since that's how the code works today.  

I'm concerned that Plan X could be a lot of hard, burn-out work, 
only to get back to where we are right now in terms of function. 

--linas