What's your favorite year end method?

[Andrew Sackville-West]

On Mon, Dec 17, 2007 at 01:24:59PM -0500, Donald Allen wrote:
> On Dec 17, 2007 12:57 PM, Andrew Sackville-West <ajswest at mindspring.com> wrote:
...

> 
> >
> > also, just out of curiosity, how are you computing your unrealized
> > gains above? I'm having a terrible time getting the information I want
> > out of gnucash without relying on the user behaving in specific
> > ways. I have avoided things like using the Action field, for example,
> > in stock transactions because they aren't required to enter the
> > txn.
> 
> I implemented it first without requiring anything in the action
> fields, using a simple heuristic to distinguish transactions that push
> a position in the same direction it's already gone (long or short)
> from those that go the opposite way (they need to be processed
> somewhat differently). But I decided to use the action fields instead,
> because it made a number of things cleaner, easier and more accurate.
> I did have to clean up my own data to fix the places where the actions
> were null or wrong. This is the kind of thing I can require of myself,
> but perhaps not of others.

Without heading further down the path of new report implementation...

It has become increasingly clear to me that in order to get any more
useful reporting (specifically around stocks, funds) there has to be a
requirement on the user to enter the information in some standardized
way. Part of me feels like this is just lazy coding, asking the user
to be specific and do things in a way that they might not find
natural. But, my limited skills (really really limited) suggests that
this is just the way it has to be. Still, I hesitate to go down
this road. I'm essentially waiting for someone with more authority and
experience to say "it's okay, just do it." 

The now classic example is the employer contribution to a stock or
mutual fund in a payroll transaction. The user invariably wants to
show that as income->buy-shares directly. Without examining the Action
field, there is no way, other than guessing, to determine that this is
a purchase without an associated dividend (a la reinvested
dividend). 

Now what the user is doing here is abstracting the actual
money flow. We all know, though the user might not see it, that the
money is actually flowing into a brokerage account of some kind and
that the buy is a separate transaction. If the user models it this
way, with that interim account, then the reporting is much easier, we
can rely on the fact that any income split that touches the account
directly is some kind of dividend or otherwise directly related income
event as opposed to the employer contribution. In a way, we already
need to user to follow specific guidelines for this case, so I don't
think it's too much to ask them to follow a different, more
information laden, guideline. 


> 
> For dividend accounts, I also want to relate them to a commodity, so
> that I can show dividends received in both an unrealized and realized
> gains report. For that, I enter security namespace:symbol in the
> income account's code field, to serve as a pointer to the commodity.
> Again, something I can require of myself.

I think this can already be done if you split the dividends into
separate sub-accounts. Then all the txn's will tie back to a specific
commodity and that information can be derived easily. It
requires the user to setup their accounts a specific way. But, as I
said above, it pretty much has to be that way. I think. 

ugh. my brain.

A
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.gnucash.org/pipermail/gnucash-user/attachments/20071217/0849af6b/attachment.bin