Most of the below concerns were addressed in other posts, but what the heck...as always, the good conciliatory stuff is at the bottom. ;)
On Fri, 2003-01-10 at 12:39, Linas Vepstas wrote: > Hi, > > caution: very long note. that, and I was rather irritated as I wrote it. > NP > > > > > Assets > > > > Cash > > > > COI > > > > > > > > Income > > > > RG(L) > > > > > > > > Account Debit Credit Bal > > > > ------------------------------------------ > > > > Cash 100 (100) > > > > COI 100 100 <--- 10 shares @ $10 > > > > ------------------------------------------ > > > > RG(L) 100 100 > > > > Cash 200 100 <--- 10 shares @ $20 > > > > COI 100 0 > > > > > The above example misrepresents how gnucash currently works. > It's not a representation of how Gnucash works. It's a representation of how (simplistically) to account for stock purchases/sales. > > > The problem with this model is that while you can easily track the > > > gains/losses, you cannot track the "current value" of your holdings. > > Huh? the current value of your holdings equals the number of shares > times the current price. > > value = quantity * price. That equation is incorrect in accounting terms, unless you're getting very quick turnaround on the stock (e.g., day traders). I've explained that in other mails. > The quantity of shares that you own is the balance of the account! > That's what the words 'current balance' mean! That is also incorrect in accounting terms. For longer-term holdings (months, quarters, years), the balance of the account is the sum of the purchases + sum of the adjustments. That's proper accounting, also addressed in other posts. > ?? This is off topic. Gnucash doesn't condon C++ style subclassing > because C++ subclassing is a massive headache for the writers of > the storage backends, never mind for the writers of the scheme reports. > We provided the key-value pair mechanism precisiely to avoid the > problems of C++ subclassing. > I disagree, but like you say, off-topic. > > Or extend the Lot instead of the Split (probably an > > easier direction, but I haven't looked at it too hard). Create a > > StockLot, and InventoryLot, etc. The Lot has some basic functionality: > > extend it. That's one of the key principles in OO A & D. > > No. This is one of the key reasons why languages like C++ are broken. > Again, I disagree. For development, OO is a great wonderful thing. Not necessarily C++, of course, but OO itself. I prefer Java to C++, as it avoids mostly the "recompile and reinstall a million clients" problem you mention (which part I deleted). Anyhow, different philosophy and off-topic. Still interesting, though. :) > > you do. The values used in net worth should be based on the recorded > > purchase cost, plus or minus any adjusting transactions for unrealized > > gains (loss). > > I don't get this. How do you plan to record a transaction for > unrealized gain? > Simple: Decrease dollar value of stock account, increase dollar value of unrealized loss account, or vice versa for a gain. This is where the adjustment transaction comes in. Standard accounting practice, according to gaap. Of course, this is currently impossible to do in Gnucash. > Stock accounts do not have currencies. This is an old and broken > pradigm left over from gnucash-1.2/1.4 which is supposed to be > eradicated real soon now. > They *should* have currencies. It's not broken at all. What's broken is that I cannot look at my stock account and see how much money I've invested in that account. I can look at my bank account and see the balance, as well as at my House asset account. Shares * price does NOT give me an idea about how much I've invested--it only tells me that at this particular time, if I sold my stock, I could get (shares * price) money for them. > > Each transaction should be balanced monetarily. This is possible if you > > track the balance in currency instead of shares, and track the purchase > > cost vs. today's volatile market price. > > Which balance? the account balance or the transaction balance? the > account balance is always expressed in shares. The transaction balance > is always valued 'monetarily', in the transaction currency. > The GUI register should show balances in *both* shares, and in some > arbitrary currency R, the 'reporting currency'. That would be great, if the register showed both balances. It doesn't, though, which is one reason this whole discussion is happening (along with the lack of a split for gains/losses). > > Record the number of shares and > > price as we do now, and offer a warning if price * share != > > debit/credit. > > ??? why is this a warning?? This is eactly the definition of unrealized > gain/loss ! Because, as I've said before, the current implementation prevents me from entering an adjustment transaction and maintaining an unrealized gains/loss account. If I have an unrealized loss, it means that the value of the shares has decreased, not the quantity. And I cannot show that currently. This seems to all be based on differing philosophies about stock valuation. You and a some others wish to see a minute-by-minute valuation of stock, and to always see the most current monetary value in the reports. Others (like myself, but I know I'm not alone) wish to see a more gaap-aware method of maintaining the purchase balance, and making occasional adjustments when a permanent value change has occurred (for example, like when Enron bailed). I don't think it would be too difficult to do both. I mean, we already have to implement the gain/loss split and Lots GUI--going a little further wouldn't hurt. And like you mentioned in another post, it's more about presentation than about the data itself (with the exception of adjustment transactions that aren't available). -- Matthew Vanecek perl -e 'print $i=pack(c5,(41*2),sqrt(7056),(unpack(c,H)-2),oct(115),10);' ******************************************************************************** For 93 million miles, there is nothing between the sun and my shadow except me. I'm always getting in the way of something...
signature_asc_DEFANGED-28204.DEFANGED-2464
Description: application/defanged-2464
