Stocks and Balancing Accounts

Charles Day cedayiv at gmail.com
Wed Jun 18 12:11:03 EDT 2008


On Wed, Jun 18, 2008 at 8:23 AM, Derek Atkins <warlord at mit.edu> wrote:

> Mike Alexander <mta at umich.edu> writes:
>
> > This was discussed on gnucash-devel last year and there was no
> > consensus that it was a good idea.  See, for example, the thread
> > starting with
> > <
> https://lists.gnucash.org/pipermail/gnucash-devel/2007-March/020071.html>.
> > Since it is a significant change it probably won't get done unless
> > there is a consensus that it is an improvement.
>
> For the record, I have (finally) read Peter Selinger's web page.
> I still disagree with many of his assumptions and some of his
> conclusions.  For example, I still completely disagree with his
> conflation of realized vs. unrealized gains.
>

Do you mean the way that realized and unrealized gains are lumped together
in the parent account? Because on every sale, even in GnuCash currently, the
lump sum of realized and unrealized gains must be entered in order for the
books to balance. You *could* break this out into realized vs. unrealized
when you key in the sale transaction, but you would have to know which
method of calculation to use for the realized gains. In a variety of
situations you may not be sure about which method is best until much later
(maybe even tax time).

I do see the value in keeping track of the commodities.  HOWEVER, I
> still maintain that those commodity accounts (be them Income or Equity
> accounts) should be HIDDEN from the user experience.  They should not
> show up in the CoA, and ideally they should not show up in a
> transaction view from the register, either.  But I do agree that
> GnuCash should track them as if they DO exist.
>

I agree about hiding them, at least by default. But I wonder if we could
avoid keeping all those accounts, and making all the necessary changes to
support them, if GnuCash would simply insist on keeping the books in balance
at the time of entry.  Peter Selinger's method of using strict double-entry
accounting seems like it would be the right way to go when doing things by
hand, but since we are computerized we might be able to force users to
remain in balance. GnuCash could do the gain/loss calculation automatically.

My reasoning is that when I go to a bank and exchange $100 for
> €74.29 I don't mentally consider it a split transaction, and indeed
> as far as *I* am concerned it ISNT a Split transaction.  The fact
> that it's an exchange should not MAKE it a split transaction.
> Now, if there were a commission fee associated, then obviously
> the commission could either be considered part of the exchange rate
> or it could be its own split.  Probably it should be its own split.
> But adding two additional "real" splits to account for the exchange
> just makes it visually messy.
>

Absolutely. The entry of these transactions should get easier, not harder.
The register would have to somehow take care of the messy bits. It would be
nice if you simply key in the amounts exchanged and the currencies involved,
then GnuCash does the rest.

But after reading Peter's document I do agree that it is necessary to
> maintain that extra information somewhere, somehow.
>

One thing I noticed about Peter's method is that the user must remember that
each exchange has to be recorded in a single transaction with four splits
together. It is possible to mistakenly record an exchange in two
transactions (one for each currency) but if you do that the exchange rate
can get lost. Of course, if split entry becomes automated then this problem
is avoided.

So let's move this discussion over to -devel and discuss the best
> way to present this in the UI in a clear, consise way that doesn't
> bloat the UI or add lots of additional cruft.
>

Sounds good.

-Charles


> > Please remember to CC this list on all your replies.
> > You can do this by using Reply-To-List or Reply-All.
>
> -derek
>
> --
>       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
>       warlord at MIT.EDU                        PGP key available
> _______________________________________________
> gnucash-user mailing list
> gnucash-user at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> -----
> Please remember to CC this list on all your replies.
> You can do this by using Reply-To-List or Reply-All.
>


More information about the gnucash-user mailing list