Hi,
Carl <[EMAIL PROTECTED]> 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
[EMAIL PROTECTED] PGP key available
_______________________________________________
gnucash-devel mailing list
[EMAIL PROTECTED]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
