Currency conversion.

[EXT-Eggers, Peter M]

I will try your solution out when I get home, thanks!

Still, I think long term that for instance I could be doing contract programming here in the USA and Mexico for instance, with accounts in both countries.  My accounts receivable in the USA could be 250 hours @ $50.00/hour and in Mexico could be 75 hours @ 600 pesos/hour, which when combined give you dollars and pesos.  I could then calculate my net worth today in pesos or dollars, depending upon today's currency conversion rate.

Because storing amounts this way applies to accurately recording any kind of financial transaction I can think of, I think it is still the simplest universal long term solution.

> -----Original Message-----
> From: Derek Atkins [mailto:warlord@MIT.EDU]
> Sent: Wednesday, April 04, 2001 2:34 PM
> To: Peter M. Eggers
> Cc: gnucash-devel@lists.gnumatic.com
> Subject: Re: Currency conversion.
> 
> 
> I think that the current Gnucash commodity concept can handle this
> well.  You can create a commodity called "miles" or "hours".  Then you
> can have an equity account (well, actually a stock or MF account using
> the currently available account types) that is basically of the
> particular commodity.  Then for each transaction you can apply the
> number of "shares" (how many of the commodity) and the price per share
> (currency/commodity).
> 
> So, for your miles example, you could create a commodity of "miles",
> and insert a transaction:
> 
> 	shares	price	value	Buy	Sell	Total
> 	187.3	.325	<60.87>	XXX	XXX	XXX
> 
> Where the value (60.87) would get filled in automatically by Gnucash.
> Obviously this is a bit clunkly (you don't really Buy or Sell miles,
> or hours).  But this is just a cosmetic issue.
> 
> Also, now that we have a pricedb, we can store the price of the
> commodity over time.  Although I'm not sure that really applies here.
> Indeed, you really don't want to base you account value on the number
> of miles driven over the years, as the conversion factor really is on
> a per-transaction basis.  The fact that you drove while the conversion
> was .31 doesn't mean that you can recalculate the value of those miles
> when the conversion changes to .325.
> 
> So, perhaps what we do need is a 'non-real commodity' account type
> which looks like a stock or mutual fund account, but tallies the value
> based upon the value of the transaction when it is entered, rather
> than the total number of "shares" of the commodity multiplied by the
> current commodity value.
> 
> -derek
> 
> -- 
>        Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
>        Member, MIT Student Information Processing Board  (SIPB)
>        URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
>        warlord@MIT.EDU                        PGP key available
>