Stock trades and realized gains/losses

[Matthew Vanecek]

--=-+xTdP5JurDet0CJG/LYd
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

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 re=
mark:
> > 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...
>=20
> OK.   I don't understand.  How do you propose to record a temporary change
> in value?=20
>=20

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
>=20
> open     100     $1      $100      #2
>=20
>=20
> One handles an unrealized gain/loss by selling and then buying back
> immeidately the smae amount.
>=20

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.
>=20
> 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.
>=20
> yes, and 'double-balancing' the lots would provide this, and
> enforce the balance.
>=20
> > 	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;
>=20
> 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,=20
> which is fine by me,  although there are again some subtle=20
> differences betweeen the two that will keep gnucash-user mailing
> list lively for years to come.
>=20

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?


--=20
Matthew Vanecek
perl -e 'print $i=3Dpack(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...

--=-+xTdP5JurDet0CJG/LYd
Content-Type: application/DEFANGED-1144; name="signature_asc.DEFANGED-1144"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQA+HzhXi/CNzDSN0RIRAtBMAJ4xuS52qw2iFque1o13q3FxLdnlUwCfWc+G
fqb3a+C7hmke7StixacTnRA=
=FRoR
-----END PGP SIGNATURE-----

--=-+xTdP5JurDet0CJG/LYd--