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
"Peter M. Eggers" <[EMAIL PROTECTED]> writes:
> I am brand new to GnuCash, currently a Quick Books/Windows user looking
> to convert to GnuCash on my new Linux installation.
>
> In reviewing the documentation, I am very impressed! The one problem
> that I have with my old version of Quick Books is being able to treat
> amounts as simple units with a separate units type per account,
> preferably with a category override. This is so I can enter for
> instance 187.3, with default units of miles, and a current default
> conversion factor of $.325/mile applied to convert to the default
> currency for the account/category. The GUI would then display $60.87,
> but store 187.3, .325, and $/mile. The other common non currency amount
> that comes to mind is hours. If one was to enhance GnuCash later on do
> estimating (construction in particular with all of the different
> price/units), this feature would be invaluable.
>
> The whole concept of fluctuating price per unit for different time
> periods and/or entities (i.e. customers) encompasses the concept of
> currencies, securities, material costs, milage reimbursements, and
> billable time. To implement, it requires making all amounts a three
> field structure (amount, conversion factor, and enumerated conversion
> type (i.e. $/hour)). Actually, you could get by with an amount and
> enumerated type, but you lose some historical / auditing information.
>
> Peter M. Eggers
> _______________________________________________
> gnucash-devel mailing list
> [EMAIL PROTECTED]
> http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
--
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
