You can do that today. You just need a different A/P per underlying
currency.
-derek
"EXT-Eggers, Peter M" <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED]]
> > Sent: Wednesday, April 04, 2001 2:34 PM
> > To: Peter M. Eggers
> > Cc: [EMAIL PROTECTED]
> > 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
> > [EMAIL PROTECTED] 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
[EMAIL PROTECTED] PGP key available
_______________________________________________
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
