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.
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 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.
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. 408.736.9655
_______________________________________________ gnucash-devel mailing list [EMAIL PROTECTED] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
