Check Printing

[Derek Atkins]

Carl <gnucash at faultline.com> writes:

> How about separating check printing from the check register? 

Technically it already is separate.  There just isn't a UI
method to get to it from anywhere other than the register, and
it only prints one transaction at a time.

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

Well, it would require more code, because you'd still need a "work to
do" list to find the checks to print.  And then you'd need an
interface to update those transactions with check numbers.  And
through all of this you still need to create the interface to print
multiple checks (which may or may not be possible directly).

Also, I'm sure I like the "set the check number to 'TBP' to schedule
check printing" interface.  It seems a bit complicated to me, and
definitely confusing.

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

I don't need a list of payees to know how much I paid for water,
phone, gas..  I've got accounts for that!  If I want to know how much
I paid for water I look at my Expenses:Utilities:Water account.
Phone?  E:U:Phone.  Gas?  E:U:Gas.  I don't need to keep a list of
payees for that info.

You could tie a "payee" to the account and store the address in some
per-account data, but that doesn't work right either.  For example I
can buy "office supplies" from multiple vendors, Staples, Office Max,
etc., so I couldn't attach address information to the account.  Yet I
don't want to keep separate "office supplies" accounts, either.

Besides, I really don't see a personal user ever needing this
information.  I really think it's a business-specific feature to print
a payee address on a check.

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

Sure, but I was just using an example.  You could just as easily use
Employee -> Expense Voucher instead and the same thing holds.  As for
"donations to charity", I think you're stretching a bit.  And frankly
a donation like that could still be considered a Vendor.

I see nothing wrong with forcing the issue.  "If you want to get the
features of a payee address, you have to use the business features and
process a payment to the payee."  This works for both Vendors and
Employees, and IMHO covers 99% of the use cases.

-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