Check Printing - Addresses

[Andrew Sackville-West]

On Thu, Jun 28, 2007 at 05:18:40PM -0400, warlord at MIT.EDU wrote:

> Wow, that site's old!   Well, the check-printing HAS been re-written.

heh, with the wayback machine, you never know what will come back to
bite you. 

> It wouldn't be TOO hard to add more check-printing fields; the problem
> is storage of payee information (or tying into the Vendor subsystem).

This is something I've given some thought too, but if its been
previously addressed, dealt with, ruled out, etc, fine. 

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 is to prevent adding a "Primary split" field to transactions?
just a boolean associated with each split that is set true for one and
only one split in any transaction. Its something that could be ignored
in almost every situation, but in those handful where the ambiguity is
a problem. Then for check printing, you^Wone could figure out a way to
tie splits to addressbook entries and the like and in that situation a
"primary" split would be helpful. It could also be arbitrarily done:
the primary split is the one that ties back to the register used to
originally enter the transaction. If you want it different, you have
to change it. 

there could be a series of gnc:transaction-get-primary-split type of
functions etc. 


just an idea stemming from genuine curiousity.

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-devel/attachments/20070629/697cd499/attachment.bin