Check Printing - Addresses

[Andrew Sackville-West]

On Thu, Jul 05, 2007 at 10:37:10AM -0400, Derek Atkins wrote:
> Andrew Sackville-West <ajswest at mindspring.com> writes:
> 
> >> 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.
> 
> I still don't see why it matters.  Something like the Payee should be
> tied to the Description, which is part of the Transaction object, not
> the Split object.  So it doesn't matter which is the "primary Split"
> in order to add ancillary information to the Transaction.
> 

I thought the business stuff was tied in through the a/p a/r register
and the owner information. And that getting to that split would get
you to that information thus eliminiating the need for some other
"payees" database as that information already exists in the business
features. 


> The main issue, tho, is that we just don't have a "Payees" database
> anywhere to tie into.  Sure, we could add an address to the
> transaction for printing on checks, but there's no good way to save
> that information in a way to reuse it again later.
> 
> I still don't see the need for a "primary split".

I won't bother you about it anymore until I go read the code... :)

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/20070705/82d1175b/attachment.bin