Check Printing

[Derek Atkins]

Hi,

Carl <gnucash at faultline.com> writes:

> 1. Using the Payee name, search the list of vendors and employees for
> a match. If found, use that as the address to print on the check. If
> not found, leave the address area blank or bring up a window that
> allows the user to find the correct name, add a new vendor or employee
> name or print the check as is without an address.

This shouldn't be too hard..  Except that the current check-printing
code does not have access to ANY of the business features.  What I
would recommend is a scheme plug-in architecture that allows you to
register check formats.  This way you could define the various
"business checks" in the business features and register it with the
basic check-printing engine.  This way the basic check-printing will
continue to work without the business features, but at the same time
you can "plug in" code that accesses the business features.

> 2. Change the check register to store a vendor or "payee" id instead
> of a string name so that the we can get the address info without doing
> a string matching search. This would require that anytime you write a
> check the payee must exist or be added as you write the check. This is
> how QuickBooks seems to do it. I know home users will consider this
> excessive because they would need to add their friends and relatives
> as "vendors". But in practice it wouldn't be a big impact. The default
> behavior when writing a check to an "unknown" payee would be a pop up
> that uses the entered name to search the known payees and give a list
> of possible matches along with an "Add" button that would add the name
> into the list of payees but not require any further info. In QB terms
> this is a "Quick Add". It could be looked at as a spell checker for
> writing checks.
>
> As much as I believe the second option is better we are leaning
> towards the first option because the first option is much more
> contained in its scope. Making changes to the check register and any
> other function that might conceivably generate a check sounds like a
> large project that could be very ugly. The second option may be more
> appropriate for inclusion in GC version 2.

I don't agree that the second option is better, because the core code
should work without the business features loaded.  I can certainly see
a situation where there is a "gnucash-business" package that installs
the business features into the runtime, and a user can choose not to
install those features.

Therefore, all the code in the non-business section of gnucash should
stand by itself and make no dependencies on the business features.

> What will probably end up happening is we do the minimum part of
> option one needed now (if no match, don't print the address) with a
> vague plan to go back and add the window to select a vendor later.

Well, anytime you use the "Vendor -> Process Payment" there is a
reference to the Vendor in the transaction.  For example you can try
using gnc:owner-from-split or gnc:owner-from-lot to get the "owner" of
a transaction/split/lot.  That might be a bit easier than trying to
string-match the vendor.

> Carl Schmidtmann
> Faultline Software Group, Inc
> 408.736.9655

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available