postgresql and business features

Sun Apr 17 05:23:39 EDT 2005

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

Excellent! Could that be generalised and made into an inventory-for-anyone 
program? QOF can provide the generic data handling - all you need to do is 
decide what parameters unite all inventory objects.
http://code.neil.williamsleesmill.me.uk/pilot-qof-7.html
http://code.neil.williamsleesmill.me.uk/pilot-qof-5.html

"Existing objects need to describe themselves to QOF and this can be achieved 
by using QOF as an external framework around the existing structs. This is 
how pilot-link is now able to use QOF. "
http://code.neil.williamsleesmill.me.uk/pilot-link.html#CONVERSION

The actual C code can be done for you:
http://qof-gen.sourceforge.net/php/qof-generator.php

(It's early days for qof-gen, there may be a few glitches but it does produce 
usable code that compiles, at least on Debian.)

You can use qof-generator to create suitable objects in C that could either 
wrap around an existing free software program or be used within a new GPL 
program. 

> 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 :)

That's fine - at least you are open to learning the code!

Start with the doxygen output:
http://code.neil.williamsleesmill.me.uk/source.html#DOXYGEN

Also see my own site for a potted history of how I started with no knowledge 
of GnuCash (or GNU/Linux GUI's) just a year ago.
http://code.neil.williamsleesmill.me.uk/palm.html#BEGINNING
http://code.neil.williamsleesmill.me.uk/startqof.html

As Derek knows, I'm still learning - but that has not meant I am unable to 
contribute.
http://www.linux.codehelp.co.uk/

> and don't expect 
> anything quick.

Fine, it took me about four months to get under the skin of GnuCash and about 
8 months before I had anything useful to contribute. We all have other jobs, 
other demands, nobody here works on GnuCash fulltime.

> I would rather work on coding some changes, but I have 
> a mountain of book keeping to catch up on.

:-)

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.

If you are also willing to investigate inventory management "by proxy", I'll 
gladly work with you on the QSF communication. You can extend an existing 
application (as I have with pilot-link) or you can write a new program. Spend 
time investigating the options and come back to me when you've got a 
candidate.

If you are willing to put in the time on this one, I am sure we can add 
inventory management to GnuCash without any bloat. I'll help you in any way I 
can.

-- 

Neil Williams
=============
http://www.dcglug.org.uk/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20050417/5c3cfe36/attachment.bin