On Fri, 2003-01-10 at 13:23, Linas Vepstas wrote: > On Fri, Jan 10, 2003 at 11:43:44AM -0600, Matthew Vanecek was heard to remark: > > Yes you're right, yes, you're right, no, you misunderstand. Net worth > > is *not* quantity * price. Net worth uses current balance, in general > > accounting. If you *want* quantity * price, I'm certainly not opposed, > > and would probably use it. However, both methods should be supported, > > with the account balance measured in dollars (sum of purchases +/- sum > > of adjusting transactions). As it stands now, there is no way to > > logically put in an adjustment transaction, which comes from the > > insistence of price * quantity, rather than actual cash expenditure. I > > can't record an other than temporary change in the value without > > recording a buy/sell, which is just... > > OK. I don't understand. How do you propose to record a temporary change > in value? >
It's not a the temporary change in value I'm concerned with. It's the *other* than temporary change (i.e., presumably permanent). These are typically recorded in adjustment transactions, and generate an unrealized gain or loss. We don't currently have the capability to make a single adjustment transaction. Instead, we have to use the work-around you describe below. Temporary changes (e.g., today's price fluctuations) would be (are) retrieved dynamically for reporting purposes. They are typically not recorded as a change in the account. Gnucash already behaves this way in practice--the price displayed in the register is, I believe, retrieved from the pricedb. I'm not suggesting we change anything in this area (I don't think I am, anyhow). > note shrs price value lot-id > --------------------------------------- > open 100 $10 $1,000 #1 > value -100 $1 -$100 #1 > unreal -- -- -$900 #1 > > open 100 $1 $100 #2 > > > One handles an unrealized gain/loss by selling and then buying back > immeidately the smae amount. > So you want two transactions instead of one? If you do it the accounting way, you have one transaction: an adjustment. If we do it the above way, we have two transactions: a sell and a buy. The above method does not reflect reality. Reality is that the price just dropped dramatically because ABC, LLC. just lost its patent on Wonder drug, and doesn't have a new Wonder2 drug in sight. We're not going to sell the stock, but we still need to record an adjustment to account for the permanent value change. I've never heard of selling and the re-buying (on paper) a stock to generate an unrealized gain transaction. Do you have a reference for doing it that way, or was it just the most expedient thing at the time? > > To sum up: > > 1) The current storage format seems OK, esp. since balances are > > calculated dynamagically. At most, I think an additional > > field in Split would be useful--shareBalance or > > purchaseBalance, depending on how this discussion goes. > > I want to have a 'reporting currency' used in ledgers and reports. > Each leger/report could have a different reporting currency. Is reporting currency equivalent to account currency? Is that just the currency in which the account is displayed, or is it also measured using the reporting currency? > > 2) We definitely need a split for realized gains/losses. > > yes, and 'double-balancing' the lots would provide this, and > enforce the balance. > > > 3) I would like to see a stock account balance measured in > > dollars, not quantities. This does not mean quantities > > should be hidden. Perhaps an option to control this > > would be acceptable. [if (x) calculateShareQtyBalance; > > else calculatePurchaseAmtBalance; > > Measured in, or displayed in? I think there's a real difference > here, and it affects things. Well, when I look at the Balance column, I want to see dollars, where dollars is a sum of all the purchase splits (and hopefully adjustment splits, sometime in the future). Optimally, I'd be able to switch between dollars and shares, depending on my personal accounting preferences. To ease that transition, it may be good to add a field to Split, which could hold the purchase balance (currency), and use the existing field for share balance. Or, we could just recalculate the balance if the preference gets changed in the middle of a session. I don't much like the idea of having to sell and then immediately re-buy to generate an unrealized loss/gain. That could definitely confuse reports!! and would need very careful manipulation re Lots, I think. It may be as close as we can get for the immediate future, but I really wish adding capabilities for an adjustment transaction could be fully considered (and implemented!). > Note in earlier email, I distingusihed the transaction-balancing > currency C from the reporting currency R. I think that you are > requesting that the ledger display a balance using C, not R, > which is fine by me, although there are again some subtle > differences betweeen the two that will keep gnucash-user mailing > list lively for years to come. > Let me see if I understand this correctly, according to the current implementation for Stock accounts. In a Stock account, the reporting currency R is quantity of shares. A Stock Transaction, OTOH, has a transaction currency C, which is DM, dollars, pounds, etc.. Is my understanding? If so, then yes, I would like to see the balance as C, although on occasion I may want R (although R only in a report would be sufficient for me personally). And yes, that refers to the display balance. I've said before, I don't think there's a real need to change the data in the back-end, since quite a bit of what we are discussing is dynamically calculated anyhow. Are we making progress toward an understanding and solution? -- 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-1144.DEFANGED-249860
Description: application/defanged-249860
