On Fri, Jul 06, 2007 at 10:32:07AM -0400, Derek Atkins wrote: > Andrew Sackville-West <[EMAIL PROTECTED]> writes: > > >> 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. > > Nope, the business stuff isn't in the registers at all. This is > why you NEED to use the Invoice and "Process Payment" functions > through the menus and NOT use the registers.. The registers have > no clue about the business features.
yeah, okay. I knew that, but I thought, despite that, that there was some vaguelink back to the business features. thanks for the enlightenment. > > Now, it might be worth it to add a "contact database" and migrate > the customer and vendor list to a common "contacts DB". And then > we could tie the check-printing and register payees into the > contacts DB. that still requires putting additional data of some kind into the transaction. Unless you were to search the contactsDB everytime, which I would think is a less-than-ideal solution. What is your opinion about putting more data in the transaction? A
signature.asc
Description: Digital signature
_______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel