reporting currencies & integrity

[Dave Peticolas]

Linas Vepstas writes:
> 
> Yes, I have already made this change to the engine. The "transaction
> valuation currency" aka "common currency" is stored in the  
> "common_currency" field in TransactionP.h.  It is not is not really
> 'used' anywhere, but it is set, and tested, and a warning is printed
> if it gets out of sync with the "IsCommonCurrency()" routines.
> 
> > I think the problem you are trying to address with your mention of the
> > reporting currency is how to find values for all these things at
> > report-generation time in terms of the reporting currency.  It's a
> > real problem, but I don't think you're making a 100% solution.
> 
> Re-read the note. I'm proposing several things.   One of them is 
> what to do if the "transaction valuation currency" is not equal
> to the "reporting currency".   This is one of the showstoppers
> for the change-over, as you yourself had pointed out earlier.

Is this what you are proposing:

Account Security stays the same, with the same meaning.

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

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

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


> > I agree that we want to make an entry in the price database for any
> > user-specified exchange rates (between Account security and
> > Transaaction currency) 
> 
> Yes, but its not just 'some price', its an explicitly auditable
> price.  I think that's a critically important part of it.

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

The price for transaction currency in account security
      ""      reported currency in transaction currency
      ""      reported currency in account security

all? others?


> > I think all we need to ask is the value in the
> > Transaction common currency, and we figure out the rest at report
> > generation time.
> 
> ?
> Yes, but the 'report generation time' is "right now" (you make it
> sound like its the distant future or something).  The main gnucash 
> window is a kind of report.  When I get done with entering the 
> transaction, I expect the main window to instantly update & reflect 
> the new value.  So that GUI popup is gonna pop up anyhow, anyway,
> in fractions of a sub-second.  I'm not sure that I care if its the 
> 'register' that caused it to happen, or the 'main window'.   

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

Register
Transaction Dialog
QIF Import

One day that may include:

OFX download
Scheduled Transactions
Palm Pilot Sync
etc.

In particular, bulk imports like QIF will be a challenge since
there could be thousands of transactions to value.


> You are free to argue back that this idea is overkill.  But it does
> solve the accounting equation problem of 'how do I know that the sum
> of the splits ==0 when the splits are in different currencies'.

I thought that was the purpose of the transaction currency. Is that
still the case? Is this how it will work:

A transaction is balanced and 'integrity checked' if the
'value' members of the splits sum to 0 and, for each split,
the value member equals the damount member multiplied by
the price stored in the database for that split.


> I assume that means you prefer Plan X to Plan Y. 
> 
> In plan X, there is one (or a collection) of globally-applied
> reporting currencies.   In plan Y, there is one (or a collection)
> of reporting currencies stored with each account. 
> 
> Plan Y is essentially how gnucash works today. 
> 
> I claim that Plan Y has a certain advantages, but this email is long
> enough already.

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

dave