reporting currencies & integrity

[Bill Gribble]

On Tue, Jan 23, 2001 at 10:22:59AM -0600, Linas Vepstas wrote:
> Store a single global 'reporting currency'.  The chart of accounts
> will use this currency to report account totals.  (its e.g. the
> euro).

I think you are saying 'the Chart of Accounts and reports will use
this currency to report monetary values, in addition to the "native"
denomination of the value'.  If so, I agree.  

However, that's not a complete solution; you still have to know how to
convert the amounts to the reporting currency.  To do this correctly,
we need to implement at least a subset of the FASB 59 standards for
conversion of amounts to a reporting currency and allow the user to
select which method they wish to use.  In short, for each value in a
"foreign" (WRT the reporting currency) currency, you have to decide
whether to convert the amount at the current exchange rate, whether to
convert component amounts at their historical exchange rate and sum
them, or to use a weighted-average exchange rate for the entire
reporting period.  You need to make this decision on a per-account
basis based on the type of the account.

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

I disagree with most of this.  I think the right approach is to store
the valuation in the transaction currency with the split.  Right now,
each split stores 2 monetary values: the 'damount' denominated in the
account's security and the 'value' denominated in the account's
currency.  What Dave and I were talking about is eliminating the
'currency' from the account, moving it into the Transaction structure,
and having each split have a 'damount' (still in the account's
security) and a 'value', now in the Transaction's currency.

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.

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) but that doesn't really solve the reporting
problem, because you could specify after the fact that you want to use
a valuation strategy that requires different exchange rates than the
ones you enter at the time of the transaction (i.e. you might want to
use current-value for all cash assets, and that's value as of report
generation time), or in fact a different reporting currency entirely.
We'll need the ability to go out and fetch currency quotes for
historical dates at report generation time.

In any case, if we have a Transaction currency that's not the
reporting currency (pretty likely) that means we have to ask the user
for possibly two different exchange rates for a single entered value
(one for the value of the split in the Transaction currency, one for
the value of the split in the reporting currency) and that's way too
much to ask.  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.

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

I'm not sure what you're talking about here.  What integrity check do
you mean, and why do you think I'm missing it?  (later) Oh, I see.
You're talking about the "accounting equation" discussion we had
several months ago.  I think we resolved that just fine; we have to
implement FASB-compliant historical/current valuation policies, and
make a report that takes unrealized gains/losses into account as part
of the Equity term of the accounting equation.  We will never be able
to "check" this during normal operation, because generating the info
you need to run the accounting equation is more of a pain in the butt
than you want to incur for normal operation.  It may make sense to
have this as a "Scrub" type option.

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

The problem with this is that the "valuation" of a transaction is
always 0.  It's splits that need to have values expressed in the
Transaction (not reporting) currency, and those values have to add up
to 0 (well, debits == credits). 

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

I don't think the reporting currency and the Transaction balancing
currency are the same thing at all.  You can change the reporting
currency from Euros to Dollars to Yen on the fly and it just changes
the denomination of the "extra" column in reports and the main window.
The Transaction balancing currency is determined by the user at
transaction entry time.

b.g.