reporting currencies & integrity

[Linas Vepstas]

Dave, Bill, all,

Bill got me to think about the reporting currency & international accounting
issues again.  Here's a couple of simple proposals that seems to solve the
issues that I can think of.  Its probable that you've already discussed
these, but since I haven't ... :-)

Intro:
I made changes to the engine to store the "transaction valuation
currency" (aka common currency)  with the transaction.  If this ever
gets out of sync with the computed common currency, a warning is
printed.  As Bill points out, there are deep GUI issues with prpoagating
this further.

Plan X:
-- Store a single global 'reporting currency'.  The chart of accounts will use
   this currency to report account totals.  (its e.g. the euro).  
-- The user is allowed to create transactions whose 'valuation currency'
   is different than the 'reporting currency'.  However, if this is
   done, then a GUI window pops up with a question "how should this
   transaction be valued in 'reporting currency'"?  User types in
   some number, lets call it the 'valuation'.  This number, the
   'valuation', is stored in the price database, (where its specially 
   identified as being a valuation price, maybe by storing the
   transaction guid with it).  When preparing reports, it is used,
   from then-on-out, to compute the valuation for reports.

-- (critical side effect proposal for Bill): for *any* multi-currency 
   transaction/trade, we should store the 'valuation price' (and maybe 
   the transaction guid) in the price database.  Why?  This allows us to
   perform the integrity check that Bill has been missing so much.
   Q: How do we 'know' that a multi-currency transaction balances? 
   A: The 'valuation' is in the price database, and a comparison with 
   that assures us that the transaction balances.   And why should
   we beleive the price database? Because these special 'valuation'
   prices are auditable, are 'important', are verified by humans,
   rather than being some random numbers pulled down from yahoo.
   (A 'valuation price' might even have a 'reconciled' or a 'been
   audited already' flag stored with it).

Plan Y:
-- same as above, except we store the 'reporting currency' with 
   each account.  (i.e. we do a global search-n-replace of 
   xaccTransGetCurrency to xaccTransGetReportingCurrency.  I really,
   really think this simple name change will clear up lots of
   confusion).
-- Modify GUI as described above.  (i.e. as above, we store the 
   'transaction valuation currency' with the transaction.  Only when
   it is out of sync with the 'account reporting currency' do we insist
   on a valuation.   i.e. the checks that 'IsCommonCurrency()' performs
   are 'loosened', and the resulting holes pluged with the valuation 
   prices.  This allows the elimination of the currency trading accounts.


So, how does that sound?  It seems to kill two birds with one stone:
tbill's 'accounting equation' problem, and the 'currency trading account'
problem.  


--linas