In short.  NO.  I'm not going to code that.

To be more explicit:

No, *I* am not going to change gnucash so radically just because a few
wacko's can't cope with regular currencies.  From historical
perspecitive, people get confused when accounts are denoted in
arbitrary currencies.  It's like this way FOR A REASON.

Stock/mutual are different because Quicken made them different.
Internally they are exactly the same.

They are useful SPECIFICALLY because the price (i.e. exchange rate) is
VISIBLE.

I don't care a rats ass about a potato farmer -- they aren't going to
use gnucash to keep track of how many potatoes they've got, and frankly
I don't care if they do.  They are not the target audience.

Anyways, I've lost personal interest in this conversation, so I'm
dropping out.  I'll look into adding a new currency type and I still
plan to go down that route.  I have absolutely no intention of
allowing arbitrary commodities.

-derek

PS: People who keep gold nuggets in their pocket are probably already
insane, and probably DO NOT use gnucash to keep track of it -- they
wouldn't trust the computer any more than they would trust a bank.
So, honestly, I don't care about them.  Sorry.  Gnucash is not all
things to all people.

"C. Gatzemeier" <[EMAIL PROTECTED]> writes:

> Gnucash has gained much with the new support for multi currencies. Currencies 
> can now be handled in an uncomplicated and consistent way throughout Gnucash.
>
> From what ever currency the user chooses as POV (report currency) other 
> currencies are not different from other commodities he can earn trade or 
> loose etc.
>
> But the very good job gnucash does with the currency subset of commodities  
> seems to be limited only to currencies unnecessary.
>
> All commodities should be handled like currencies are handled now, but at the 
> moment if one wants to account for another type of commody he is forced to 
> use a special stock/mutual (what's the difference?) account and define an 
> arbitrary commodity for it.
>
> Those stock/mutual accounts seem to be older than the currency support and 
> can't be used in many ways. Just like the old not-to-be-used-anymore 
> "currency account" type. Some aspects:
>
> o  A silly example: You work in your garden and earn potatos. (Well, maybe it
>    isn't silly at all sounds like a decent farming job.) The old GC way does
>    not allow you to earn other commodities than your current (and assumed to
>    be static) home currency. (Now, GC works fine with all commodies of type
>    ISO-Currency)
>
> o  With the current way of stock/mutual accounts it is not possible to
>    transfer stocks from one booker to another without "selling" them in GC.
>    (Just like it had to be done with currencies before)
>
>
> I would think the solution is to allow other commodity types than just 
> currencies in general accounts.
>
> As Derek pointed out if one wants to see the value of a commodity (i.e stocks) 
> in another commodity (i.e. USD/HKD) a report could be generated right away. 
>
> Another possibility is a new "view in report currency option" for registers 
> (like the old stock/mutual accounts) with both denominated commodity numbers 
> and values in report commodity.
>
>
> I had this backwards before and on 19/01/2004 16:20 Derek Atkins wrote:
>> Registers are already denominated
>> in the account-currency.  The only exception is stock/mutual accounts
>> which don't have a currency (so the "value" is denoted in whatever the
>> transaction is denoted).
>
> The accounts have a commodity! "Value" is always relative to another 
> commodity.
>
> I don't think stocks are an exception of commodities. They don't need to be 
> treated differnently. However no doubt that for some users reporting needs 
> for stocks may be higher than for other commodities or vs. versa. Those are 
> reporting needs on a level below the account-balance, based on transactions 
> (buy/sell) and time. This ties in with the proposed support for "lots" in  
> accounts and more complex transaction reports.
> http://linuxwiki.de/GnuCash/DevelTexts
>
>
>
>> This is because gnucash _does not support inventory_.
>>
>> FWIW, inventory accounts SHOULD be more similar to stock/mutual than
>> to Asset.  You want to keep track of the number of widgets in your
>> inventory, and AT THE SAME TIME you want to keep track of how much you
>> PAID for those widgets.  Stock/mutual accounts are exactly the right
>> abstraction.
>
> I think you always want your accounting program to keep track of those things 
> for any commodity, even or especially for currencies. And it is done by 
> recording the transactions (in the future optionally with lots in some 
> accounts).  However in some cases you might not want to always see how much 
> you paid for each transaction "AT THE SAME TIME". Which is now the default 
> behaviour.
>
>
>
>> We specifically limit it because we do NOT want to have (certain)
>> account types denominated in FooWidgets.  The fact that certain
>> accounts are limited to currencies is NOT a bug.
>
> Ok, as I propose the old stock/mutual account types should go too, along with 
> the currency type.
>
> If I take gold as an example for an arbitrary commodity:
> Some people do keep their gold nuggets in their pockets as cash, others prefer 
> to bring them to the bank, or loan them out for a while (to a dentist maybe).
> Of course one could earn and spend gold and have a lot of gold from past 
> accounting periods it is just a convention that we use USD gold or any other 
> commodity.
>
>
> Christian
>
>
> _______________________________________________
> gnucash-devel mailing list
> [EMAIL PROTECTED]
> http://www.gnucash.org/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.gnucash.org/cgi-bin/mailman/listinfo/gnucash-devel

Reply via email to