Check Printing

Carl gnucash at
Mon Apr 26 13:01:25 EDT 2004

--On Friday, April 23, 2004 14:56 -0400 Derek Atkins <warlord at MIT.EDU> 


Carl <gnucash at> 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.

How about separating check printing from the check register? One of the 
other annoyances of check printing is that checks are printed one at a 
time. What would be useful for personal or business users is to select 
"Print Checks" from a menu and you are presented with a list of checks that 
have not yet been printed. You select which checks you want to print now, 
enter the number for the first one, select the check format to use and hit 

The check number can be set to "TBP" when you pay a bill or otherwise 
create a check transaction and don't want to immediately print the check. 
The check printing code would then search the check register for checks 
with that "number" to create the list of which checks need printing. It 
would also have access to any other information it needed either from the 
check register or any other register. It would update the check number and 
possibly the date in the check register after printing each check.

This is more ambitious than we were planning for but it wouldn't require 
changing a lot of existing code since the only thing needed is to use a 
special check "number" when creating a check to be printed later. The 
current method of check printing would not be changed at all. This could be 
called a "business" feature but I think it would be desirable to home users 
as well.

>> 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.

I agree with that philosophy but I don't necessarily see keeping a list of 
payees (anyone you write a check to or anywhere you use your credit card) 
as a business feature. Don't home users want to generate a report showing 
how much the pay for water, phone, gas, etc? Even if they don't put in 
addresses for each payee they can make sure that the names they put on the 
checks are they same each time they do it so the reports are correct.

>> 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.

Paying a vendor bill is only one type of check we print. There are also 
checks to employees, donations to charities and probably others. They are 
all possible payees. That's why I thought that a tag in the check register 
identifying the payee would be useful.

> -derek

Carl Schmidtmann
Faultline Software Group, inc.

More information about the gnucash-devel mailing list