Re: postgresql and business features
On Sunday 17 April 2005 4:01 am, Brian wrote: On Sat, 2005-16-04 at 17:03 +0100, Neil Williams wrote: On Saturday 16 April 2005 4:41 pm, Brian wrote: So far I have found that in entering a new vendor bill that the descriptions have a short term memory. It is only for the current bill! Rarely would I have to enter the same description twice in the same bill, but would enter the same descriptions for the same vendors regularly. I have the opposite - I regularly enter exactly the same description for consecutive dates in one invoice covering, usually, a week. I find it quite useful when Mileage pops up just by typing M. Since the two methods are mutually exclusive, there would have to be a checkbox/option somewhere to toggle between the two modes of operation. Not necessarily - the main Register windows have the auto-fill feature that simply allows matching with any entered data. You type enough to identify one particular string and the rest could auto-complete. If a single wheel could be used between business windows, both methods would be supported. Why should a config option be required to disable searching within the current window? The above could be implemented in an xml database for smaller requirements but would be more suitable to a regular database for larger numbers of vendors/items to remember. Why should it be saved externally at all? If you want that kind of functionality, it'd be best to not have to type anything and use the new XML to create the invoice / bill for you. I thought a separate file would make it easier to edit if changes were made to a supplier product line. That way the database would not grow too large if a user had a fairly large number of products they purchased. No, I think you've missed the method here. The auto-fill is automatically generated from the contents of the appropriate windows and the data that created the window. You enter something once and then whenever you are in a suitable window, that entry is cached direct from the QofBook and used to populate the wheel. As soon as anything in the wheel is a unique match to what you have typed so far, it will be used to auto-complete the rest of the field(s) and the user can ignore such a tip or hit Tab or Enter to accept it. There is no need to save the data within the wheel - it is a cache of existing data that is already saved in the book itself. The auto-fill should almost never be fixed or set in code - it is user-specific and all the data it could ever need already exists in the current data file. What you are thinking of is a fixed inventory database where you are only able to make entries that match an existing inventory item - but inventory is not supported. The cache method is more flexible and allows all users to have a suitable auto-complete experience. If you want inventory, then IMHO, I think GnuCash should use some form of external inventory management that does not add huge amounts of code to the main codebase. What I've outlined below would actually add no code at all - it would simply use what will be available in G2. Use a separate program to make the data available to GnuCash (maybe through QSF) but don't do the actual inventory listings and stock listings within GnuCash. Maybe an external database that can be managed by a separate program - used to create new inventory items, add stock to the system, allocate stock to customers exported from GnuCash and export data that GnuCash can use to create invoices. There may well be an existing program that could do this, what I would envisage is the same kind of interface as I'm creating for GnuCash and pilot-link. When data is required, the two programs communicate using QSF XML. At other times, they are completely separate and can be installed independently. So GnuCash would export Customer data (and indeed import new or modified customer data) to/from this other program using QSF XML. The other program could use a QOF wrapper to parse and process the QSF into it's own data tree. GnuCash would then read data from the program, as XML, to create suitable invoices. Merging the GnuCash data into the existing data is also handled within QOF. My pilot-qof program is reading Expenses, Calendar and Contacts data from the Palm and creating data that GnuCash will be able to use to create invoices. This way, you'd never need access to the actual inventory listings within GnuCash - all the data would be exported direct from the supporting program. The other program would also be able to query Palm data - that could be handy! I feel it is important that users of GnuCash are not required to install inventory management when they don't need it. It should be available - there are queries about it quite often - but it does not need to be within GnuCash itself. (I'm all for making QOF standalone too - currently it's copied into GnuCash as a single lump of C.) AS for
Re: postgresql and business features
Neil Williams [EMAIL PROTECTED] writes: I think extending the auto-complete within the business code to re-use the cache between business windows would be a very useful addition to GnuCash. I think *IMPLEMENTING* autocompletion in the business ledger would be useful.. Right now it's not implemented at all. Personally I wish that the code-factoring between the 'generic' register and the 'object-specific' register were done differently. Right now you need a LOT of duplicated code and functionality to implement a register for a different set of data objects. :( This duplication includes the autocomplete, which is something I just never did for the business register. -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 gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
postgresql and business features
I am new to these lists, and fairly new to actually getting some work done on gnucash. My primary use is for a small retail kiosk business my wife and I bought last year. So far I have found that in entering a new vendor bill that the descriptions have a short term memory. It is only for the current bill! Rarely would I have to enter the same description twice in the same bill, but would enter the same descriptions for the same vendors regularly. What I would like for it to do would be: -- gnucash to have a per vendor database to store the descriptions as well as most of the other data for that entry such as [action,Expense account, Unit price, Taxable, Tax Included, Tax Table] info as most of it will remain constant from bill to bill. -- It should remember the last values entered rather than multiple variations of the same description. In my case I do not have a great number of different items, but other small businesses could. -- This leads up to an inventory module, is it planned? My inventory tracking needs are minimal as most of the products we purchase are used to produce our final saleable product. An inventory module would be usefull, but not critical. The above could be implemented in an xml database for smaller requirements but would be more suitable to a regular database for larger numbers of vendors/items to remember. This brings up the postgersql question. Is there still interest/work on bringing the postgresql integration up to date with the current business model/features? Thank you for all the work on gnucash up to date. -- Brian [EMAIL PROTECTED] ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: postgresql and business features
On Saturday 16 April 2005 4:41 pm, Brian wrote: So far I have found that in entering a new vendor bill that the descriptions have a short term memory. It is only for the current bill! Rarely would I have to enter the same description twice in the same bill, but would enter the same descriptions for the same vendors regularly. I have the opposite - I regularly enter exactly the same description for consecutive dates in one invoice covering, usually, a week. I find it quite useful when Mileage pops up just by typing M. However, more useful is an automated way of creating these objects and I'm working on that - by importing an XML file that contains the required data. I'm not too familiar with the auto-fill code already in GnuCash but I think this may be able to be used here. Patches are welcome! -- This leads up to an inventory module, is it planned? Not currently. The above could be implemented in an xml database for smaller requirements but would be more suitable to a regular database for larger numbers of vendors/items to remember. Why should it be saved externally at all? If you want that kind of functionality, it'd be best to not have to type anything and use the new XML to create the invoice / bill for you. -- Neil Williams = http://www.dcglug.org.uk/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgplKSpmRbmEL.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: postgresql and business features
On Sat, 2005-16-04 at 17:03 +0100, Neil Williams wrote: On Saturday 16 April 2005 4:41 pm, Brian wrote: So far I have found that in entering a new vendor bill that the descriptions have a short term memory. It is only for the current bill! Rarely would I have to enter the same description twice in the same bill, but would enter the same descriptions for the same vendors regularly. I have the opposite - I regularly enter exactly the same description for consecutive dates in one invoice covering, usually, a week. I find it quite useful when Mileage pops up just by typing M. Since the two methods are mutually exclusive, there would have to be a checkbox/option somewhere to toggle between the two modes of operation. However, more useful is an automated way of creating these objects and I'm working on that - by importing an XML file that contains the required data. I'm not too familiar with the auto-fill code already in GnuCash but I think this may be able to be used here. Patches are welcome! -- This leads up to an inventory module, is it planned? Not currently. The above could be implemented in an xml database for smaller requirements but would be more suitable to a regular database for larger numbers of vendors/items to remember. Why should it be saved externally at all? If you want that kind of functionality, it'd be best to not have to type anything and use the new XML to create the invoice / bill for you. I thought a separate file would make it easier to edit if changes were made to a supplier product line. That way the database would not grow too large if a user had a fairly large number of products they purchased. AS for submitting patches, The only recent coding I have been doing is in python/pygtk this past year. I never have actually done any c coding, although I did study it some, recently I have been studying a c++ book. The closest thing to this type of program I coded was specialized inventory/sales tracking programs that I did in a dbaseII compatible setup about 17 years ago. I did start looking thru some of the code, but it will take some time to figure out where to begin considering any changes. Hints are always welcome :) and don't expect anything quick. I would rather work on coding some changes, but I have a mountain of book keeping to catch up on. -- Brian [EMAIL PROTECTED] ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
