Currency conversion.

[Derek Atkins]

You can do that today.  You just need a different A/P per underlying
currency.

-derek

"EXT-Eggers, Peter M" <Peter.Eggers@PSS.Boeing.com> writes:

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

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