Check Printing - Addresses

[Andrew Sackville-West]

On Mon, Jul 02, 2007 at 04:43:31PM -0400, Derek Atkins wrote:
> Andrew Sackville-West <ajswest at mindspring.com> writes:
> 
> > ISTM that there are a number of situations where this issue comes up
> > with gnucash: "we don't know which split is the one to use for
> > <purpose x>". I guess it comes up in sched-x a bit and in other places
> > where the display of information is not necessarily done in a way that
> > people would expect. For example, a check with two splits: from
> > the data's perspective, no split is more important than any other. And
> > I think that's as it should be. And for most uses, its totally
> > appropriate. BUt for check printing, or deciding which split to
> > display in a register-neutral situation like displaying scheduled
> > transactions before commit, the splits do matter, at least
> > somewhat. In the check situation its obvious: the one that matters is
> > the "local" one; the one that relates to the checking account. 
> 
> What's the definition of "primary split"?  Is it the first split you
> create?  Is it the first split tied to the account register?  What
> about for transactions created through other methods, like the transfer
> dialog or an importer -- which split is "primary"?

This is based on my *very limited*
understanding, BTW, so feel free to educate me in whatever manner is
expedient... (including STFU...)

Its purely arbitrary in that for almost every purpose it doesn't
matter. But for some purposes -- specifically in this context for the
purpose of attaching additional information to a transaction, such as
an address -- it does matter. Simply use the register that is
used to create the transaction. For an invoice payment, the register the
transaction is entered into is A/{R,P} (but maybe my assumption is wrong
there). The other split is checking (could be others, I know). When
the payment is printed, the printing engine can look for a primary
split, and if that exists, and has additional information attached to
it, it could be printed as well. With an invoice payment, there is
owner information on the A/{R,P} side that could be used to grab that
address, or account number, or whatever.

It may be useful in other areas where there is a decision to be made
regarding which split to show, but I don't know. There was another
thread recently about "why do we see every split in the sched-x
dialog, why not just checking". In that situation, if the sched-x was
created within the context of the checking register, then the checking
split was marked as the primary and it would make sense to display
that one split only (unless the transaction was selected and
expanded).

> 
> > What is to prevent adding a "Primary split" field to transactions?

[...]
> 
> I still don't see how the "primary split" is useful.
> 

I honestly don't know either, but it was an idea. The other
alternative, for a more feature rich check printing option would be to
walk through *all* the splits looking for owner information so that it
could be incorporated into the print, but that moves the logic from
the data level to the printing engine, which may not be a good
thing. By attaching it to the data, you can say "this split has
additional information that may be useful for this transaction".
There might still (somehow?) be ambiguous situations. With a
"primary" split, then its easy: look at the primary split (if it
exists) and check for owner (is that the right term) information and
if that exists grab it and splat it onto the check. All other cases,
it simply prints a check as it currently is. 

Another possible added bonus of this idea: invoice numbers printed on checks
without editing the fields. 

the way I see it, it allows an opportunity to dis-ambiguate the data
if that's a benefit in a particular situation without having any
effect on the validity of the data. If the primary split is not set
(from old data, say) or there is no other information associated with
the primary split, then there is nothing lost. The bonus information
is simply not available.

thinking aloud

A

p.s. yes I'm aware that if this idea goes anywhere, I'd have to code
it... and I'm willing to learn. And I know it would a many tentacled
solution (Ramen).
-------------- 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-devel/attachments/20070703/80038626/attachment.bin