While thinking about stock splits, I actually checked out the current
"action field". In truth, I have never paid it any attention before.
The first question is, what are they for? As it stands right now, it
looks like they're really just another memo field that happens to have
some default (account-type specific) suggestions for the value.
What might they be for? Well, let's take the security account case.
In security accounts, there are going to be special "actions" that
you'll take. These are things that the engine really needs to know
about in order to DTRT with respect to reports and other activities.
For example, it seems like you should be able to mark certain
transactions as a "split" (in the stock split sense of the word), and
others as buys and sells. In fact, it seems like perhaps you should
be *required* to mark these transactions as such. Otherwise, how does
the engine know what's a sale event, and hence a subject to consider
in tax computations?
One counterproposal would be that the engine should just infer the
nature of the transaction in accordance with some fairly generous
pattern matching rule, something like "all security account
transactions going to/coming from a bank account are a sell/buy", but
this approach seems fraught with potential for error, and it gets
really messy if the event is non-standard and involves some activity
that's not strictly related to the event that the action field would
have recorded. Imagine for example that youv'e got a stock split that
involves you trading X shares for Y new shares with Z fractional
shares given back to you in the form of cash. This might be hard to
recognize as a stock split with a pattern matching rule, but it would
be easy if it were annotated with per-split actions like this:
Action desc/memo transfer-from
2000-03-04 another pesky split
split-out some-security X 21 $2.00
split-in some-securtiy Y 40 $1.00
fractional sale brokerage-acct 1 $2.00
So I'd say that we need to use an action field for this. However, as
it stands now, we probably can't use the one we've already got.
Problems include:
- the values in the action field are free-form, the user can put
whatever they want in there. We need something more like an
account-type specific enumeration for the engine to use.
- the values are not only arbitrary strings, but they're
internationalized, so (I think) they vary when stored (or are they
internationalized at display time, but stored as english?)
- Since people have been using the action field for a while, so we
have no idea what they've been doing with it.
Given these problems, I suppose we may not be able to just convert our
current action field to the rigorous, engine/reports relevant field we
need. So perhaps we have to just keep it around and add a new field,
though I wish we could avoid that. Since the current action field
really is just user-defined memo field, I'd rather just integrate it
into a broader user-defined "key/value" memo system, and take over the
action field for the functional purposes described here.
In any case, there is still the question of which structure should own
the field we need? Should it be a split field (as it is now), or
should it be a transaction field? I'm fairly certain we'll still need
a per-split action field, so the main question is, do we need a
per-transaction split field? Even though I was initially advocating
it, I suspect not. I had originally thought you'd want
per-transaction action fields so that you could just say "this
transaction represents a stock split", but I think it's probably much
better to just have the finer grained "split-in" and "split-out"
actions on a per-split basis...
Finally, if we do start using a new action field for important things,
then we're going to have to try and make sure the user uses it. This
might mean putting one on the main line in single-line mode.
--
Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930
